티스토리 뷰
방화벽은 크게 상태를 저장하는 Stateful과 저장하지 않은 Stateless 두 가지 유형으로 나눠볼 수 있습니다.
여기서 상태를 저장한다는 뜻은 무엇일지, 또 두 방화벽이 패킷을 필터링하는 방법과 장단점은 무엇인지 지금부터 알아보겠습니다.
방화벽이란 ? Rule에 따라 들어오는 패킷의 Pass 또는 Drop 여부를 결정하는 필터링 서비스를 말합니다.
이 때 필터링을 결정하는 정책을 설정할 수 있고, 허용 목록을 설정하는 Whitelist (default: 차단)와 거부 목록을 설정하는 Blacklist (default: 허용)로 접근 제한을 할 수 있습니다.
Stateful 방화벽 - 동적 패킷 필터링
기본적으로 웹 요청과 응답은 클라이언트가 서버에 Request를 보내고, 서버가 이에 대응하는 Response를 보내는 것으로 이루어집니다.
우선, 방화벽 Inbound 규칙이 다음과 같이 설정되어 있다고 가정하겠습니다.
Inbound | 10.0.0.1 TCP/80 | Allow |
규칙에 따라 10.0.0.1 클라이언트의 패킷은 방화벽을 통과해 서버로 전달되고, 10.0.0.2 패킷은 허용하는 정책이 없으므로 drop 되는 것을 알 수 있습니다. 이렇게 Stateful 방화벽은 기본적으로 허용 규칙이 있어야 패킷이 pass되는 Whitelist 기반입니다.
그런데 들어온 요청에 대한 응답(Response)을 서버에서 보낼 때는 outbound 규칙이 없는데 어떻게 가능했을까요?
바로 방화벽이 상태를 저장하기 때문입니다. inbound로 패킷이 들어온 뒤 응답을 보낼 때, Stateful 방화벽은 다음과 같은 네 단계를 거칩니다.
1. inbound 패킷 진입 시 세션 생성
2. 이 세션에는 dest/src IP 주소와 Port가 기록되어 테이블에 저장
3. 서버로부터의 응답이 방화벽에 들어오면 세션 테이블에서 일치하는 정보를 검색
4. 해당 정보가 존재하는 경우 확인 후 전송
이 때, outbound 정책과 상관없이 항상 반드시 세션 테이블을 확인하게 됩니다. 따라서 outbound 규칙에 관계없이 세션 테이블에서 확인하는 정보를 기준으로 방화벽에서 필터링합니다.
이런 원리 때문에 Stateful 방화벽은 상대적으로 보안성이 우수하고, 네트워크 연결 상태를 추적할 수 있지만 속도가 느리다는 특징이 있습니다.
Stateless 방화벽 - 정적 패킷 필터링
위와 동일한 조건의 inbound 규칙을 가지고, 동일한 패킷을 Stateless 방화벽으로 필터링해보겠습니다.
그림과 같이 Stateless 방화벽은 inbound 규칙을 만족시키는 클라이언트 10.0.0.1/80 Request를 통과시키지만, 해당 패킷에 대한 서버로부터의 응답은 drop시킵니다. 이것이 Stateful과의 가장 큰 차이입니다. Stateless 방화벽은 상태를 저장하지 않기 때문입니다.
해당 패킷이 들어올 때, 들어온 요청 정보나 네트워크 정보를 따로 저장하지 않기 때문에, 반드시 응답에 대한 outbound 규칙이 있어야 통과시킬 수 있습니다. 따라서 10.0.0.1/80 에 대해 서버에서 응답을 보내려면, 아래와 같은 outbound 규칙을 추가해야 합니다.
Outbound | 10.0.0.1 TCP/80 | Allow | 우선순위 100 |
또한 Stateless는 규칙마다 우선순위가 지정되어야 하며, 이 우선순위에 따라 필터링 규칙을 순서대로 적용합니다.
📌 Tip. 우선순위는 어떻게 정해야 할까요?
우선순위는 보통 이후 추가하거나 삭제되는 것을 고려해 1부터 시작하기보다는 10 혹은 100 부터 정하는 것이 일반적입니다!
Stateless 방화벽은 outbound 규칙에 의존해 패킷을 필터링하기 때문에, 패킷을 전체 검사하지 않고 헤더만 검사해 속도가 빠릅니다.
상황과 특징에 따라 두 방화벽을 선택, 혼합하여 사용할 수 있습니다.
대표적으로 AWS에서는 Stateful인 보안그룹과 Stateless인 NACL을 통해 내부 네트워크 방화벽을 구축할 수 있습니다.
'Security' 카테고리의 다른 글
보안솔루션의 종류: SIEM과 SOAR 차이 알기 (0) | 2024.01.17 |
---|
- Total
- Today
- Yesterday
- rocky9
- IAM
- Vmware
- Linux
- kubectl
- Route53 비용 정책
- Google Cloud DNS
- 에티버스러닝
- EKS
- kubernetes
- vsphere
- AWS
- ycampus
- Git
- Local Zones
- Window Server Manager
- Windows Server
- IAC
- github
- Route53
- k8s
- RECA
- redhat
- aws cli
- 클라우드 DNS 서비스
- VM Tools
- Ansible
- Docker
- Azure DNS
- VPC
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |