방화벽에서의 Stateful VS Stateless
방화벽은 설정한 Rule에 따라 진입되는 패킷을 Pass할 것인지, Drop할 것인지 필터링해주는 유해한 트래픽을 차단하기위한 하드웨어 내지 서비스이다.
대부분의 방화벽은 정책 기반으로 트래픽을 필터링한다.
방화벽의 발전 과정이나 구조별 유형 등의 설명거리가 있지만, 여기서는 크게 다루지 않는다.
이번에 정리할 개념은 방화벽에서의 Stateful과 Stateless 유형이다. 이 둘을 각각 예시와 함께 비교하며 알아본다.
Stateful / Stateless
외부 네트워크(클라이언트)에서 내부 네트워크(서버)로 접속하는 트래픽을 가정해보자.
클라이언트가 서버로 요청을 날리는 Request와 해당 Request에 대한 클라이언트로 날라가는 Response가 존재할 것이다.
웹 서버로 들어오는 트래픽이 방화벽에 도착하는 경우, 해당 트래픽을 방화벽에 설정된 정책에 따라 확인한 후 ALLOW인 경우 내부 웹서버로 전송하고, DENY인 경우 해당 트래픽을 내부로 전송하지 않고 DROP한다.
위와 같이 Stateful 방화벽에 2.3.4.5의 출발지에서 온 TCP/80으로 도착하는 트래픽을 허용하는 정책이 설정되어있다고 가정한다.
2.3.4.5라는 IP를 가진 클라이언트가 80 포트로 접속을 시도하는 경우, 방화벽에 ALLOW하는 정책이 존재하므로 트래픽이 그대로 내부까지 전달되게 된다.
반면, 3.3.3.3 IP를 가진 클라이언트가 접근하는 경우, 방화벽에 이를 허용하는 정책이 없으므로 이 트래픽은 내부까지 전달되지 못하고 방화벽에 의해 DROP되게 된다.
(방화벽은 기본적으로 ALLOW하지 않은 경우, 차단한다. ⇒ 화이트리스트 방화벽)
그렇다면, Request를 받은 웹서버가 다시 클라이언트에게 Response하는 트래픽은 어떻게 될까?
Stateful 방화벽에서는 인바운드로 패킷(Request)이 들어올 때, 이에 대한 세션이 생성된다.
세션에 출발지/목적지 ip와 포트가 기록되어 테이블에 저장된다.
이후 Response 패킷이 방화벽으로 들어올 때, 세션 테이블에서 응답패킷과 일치하는 정보를 찾아 존재하는 경우 응답패킷을 바로 내보내준다.
아웃바운드 정책과 상관없이 세션테이블에 일치하는 정보가 있는지 확인한 후 응답을 내보내준다는 특징이 존재한다.
이러한 특징을 가진 Stateful 방화벽은 후술할 Stateless 방화벽보다 기본적으로 보안성이 우수하다고 여겨진다.
다음으로 Stateless 방화벽이 설치되어있는 환경을 구성해본다.
위의 예시와 마찬가지로 방화벽에 동일한 Rule을 설정하고 클라이언트에서 서버로 Request를 날리는 경우를 생각했을때,
응답이 오지 않는 것을 확인할 수 있다.
이렇게 되는 이유는 Stateless 방화벽에서는 들어온 요청 정보를 따로 저장하지 않아, 요청에 대한 응답에도 그 방향에 맞는 Rule을 적용하기 때문이다.
요청/응답 과정이 원활하게 이루어지기 위해서는 응답이 나가는 방향에 대해 Rule을 생성해주어야한다.
여기서는 아웃바운드의 TCP 트래픽을 ANY OPEN해주는 Rule 등을 생성해줌으로써 해결할 수 있을 것이다.
이러한 Stateless 방화벽은 패킷 전체를 검사하지 않고 패킷의 헤더만 검사해 Stateful 보다 처리속도가 빠르다.
또한 Stateful과는 달리 Rule이 적용될 순서, 우선순위를 지니고 있어 각 규칙 별 평가할 순서를 지정해야한다.
따라서 Stateless 방화벽은 특정 IP만 차단하는 방식의 블랙리스트 스타일 방화벽에 가깝다.
클라우드 환경에서의 방화벽
AWS에서도 이 2가지 형태의 방화벽을 찾아볼 수 있는데, 우선 Stateful한 형태의 방화벽으로는 Security Group(보안그룹, 이하 SG)이 있다.
보안그룹은 인스턴스를 생성할 때에 확인할 수 있듯이, 인스턴스에 연결되는 타입의 방화벽이고 SG내에 지정되지 않은 트래픽은 인스턴스 내부로 접근이 되지 않는 것을 알 수 있다.
또한, 상태를 저장하기 때문에 한 번 인바운드를 통과한 트래픽은 아웃바운드 규칙에 적용받지 않는다. (Stateful 방화벽의 특징)
물론 그 반대도 마찬가지다 (아웃바운드 → 인바운드)
Security group에서의 연결 관련 Docs를 첨부한다.
Security group connection tracking - Amazon Elastic Compute Cloud
Security group connection tracking Your security groups use connection tracking to track information about traffic to and from the instance. Rules are applied based on the connection state of the traffic to determine if the traffic is allowed or denied. Wi
docs.aws.amazon.com
다음으로 Stateless한 형태의 방화벽은 Network ACL이 있다.
Network ACL은 VPC의 서브넷에 적용되는 타입의 방화벽이고, 각 규칙별로 번호가 매겨져 트래픽의 허용/거부 결정 평가에 이용된다.
하지만, Network ACL은 이전 상태를 기억하지 않아(Stateless), 인바운드에서 ALLOW되었다고 하더라도 아웃바운드에서도 또 아웃바운드 정책을 확인한 후 ALLOW/DENY를 결정한다.
네트워크 ACL을 사용하여 서브넷에 대한 트래픽 제어 - Amazon Virtual Private Cloud
기본 네트워크 ACL의 인바운드 규칙을 수정한 경우 IPv6 블록을 VPC에 연결할 때 인바운드 IPv6 트래픽에 대한 ALLOW 규칙이 자동으로 추가되지는 않습니다. 이와 마찬가지로 아웃바운드 규칙을 수정
docs.aws.amazon.com
위 2개의 방화벽을 비교하면 아래 표와 같다.
| Security Group (보안그룹) | Network ACL (네트워크 ACL) | |
| 적용 대상 | 인스턴스(ELB,RDS,VPC endpoint 등) | 서브넷 |
| 방화벽 타입 | Stateful | Stateless |
| 적용되는 규칙 | ALLOW | ALLOW/DENY |
| 우선순위 | 없음 | 작은번호부터 평가됨 |