규칙이 예상대로 작동하지 않으면 Network Firewall 관련 문제를 어떻게 해결합니까?

7분 분량

규칙이 예상대로 작동하지 않을 때 AWS Network Firewall 문제를 해결하려고 합니다.

간략한 설명

다음 상황에서 Network Firewall 규칙이 예상대로 작동하지 않을 수 있습니다.

트래픽이 방화벽을 통과할 때 대칭되는 형태로 라우팅되지 않습니다.
Network Firewall 규칙이 잘못 구성되었습니다.

참고: Network Firewall 문제를 해결하기 전에, 다음 구성을 확인하십시오.

방화벽 엔드포인트가 전용 서브넷 및 라우팅 테이블에 배포되었습니다. 방화벽 서브넷에 워크로드 리소스가 없어야 합니다.
라우팅 테이블이 방화벽 엔드포인트를 통해 트래픽을 라우팅합니다. Amazon CloudWatch 지표 ReceivedPackets를 확인하여 Network Firewall이 패킷을 수신하는지 확인합니다. ReceivedPackets 지표 값이 0인 경우, 라우팅 테이블에 방화벽 엔드포인트를 가리키는 올바른 경로가 있는지 확인하십시오.

해결 방법

참고: AWS Command Line Interface(AWS CLI) 명령을 실행할 때 오류가 발생하면 AWS CLI 오류 문제 해결을 참조하십시오. 또한 최신 AWS CLI 버전을 사용하고 있는지 확인하십시오.

방화벽을 통과하는 대칭 라우팅 확인

중앙 집중식 Network Firewall 배포 모델의 경우, 검사 가상 프라이빗 클라우드(VPC)의 Transit Gateway Attachment에 대하여 어플라이언스 모드를 활성화합니다.

어플라이언스 모드가 활성화되었는지 확인하려면 다음 describe-transit-gateway-vpc-attachments AWS CLI 명령을 실행하십시오.

aws ec2 describe-transit-gateway-vpc-attachments \
    --filters Name=transit-gateway-attachment-id,Values=tgw-attach-example

어플라이언스 모드를 활성화하려면 다음 modify-transit-gateway-vpc-attachment AWS CLI 명령을 실행합니다.

aws ec2 modify-transit-gateway-vpc-attachment \
    --transit-gateway-attachment-id tgw-attach-example \
    --options ApplianceModeSupport="enable"

참고: tgw-attach-example을 검사 VPC의 Transit Gateway Attachment ID로 바꾸십시오.

방화벽 엔드포인트를 퍼블릭 서브넷에 배포하는 경우, 인터넷 게이트웨이의 Ingress 라우팅 테이블이 방화벽 엔드포인트를 통해 프라이빗 서브넷으로 라우팅되어야 합니다. 프라이빗 서브넷의 라우팅 테이블은 인터넷 트래픽도 동일한 방화벽 엔드포인트로 라우팅해야 합니다. 자세한 내용은 AWS Network Firewall을 사용한 인터넷 게이트웨이가 있는 단순한 단일 영역 아키텍처를 참조하십시오.

다중 AZ 방화벽 배포의 경우, 인터넷 게이트웨이의 Ingress 라우팅 테이블이 동일한 방화벽 엔드포인트를 통해 프라이빗 서브넷으로 트래픽을 라우팅해야 합니다. 라우팅 테이블이 프라이빗 서브넷과 동일한 가용 영역에 있어야 하기도 합니다. 자세한 내용은 AWS Network Firewall을 사용한 인터넷 게이트웨이가 있는 다중 영역 아키텍처를 참조하십시오.

잘못 구성된 Network Firewalll 규칙 수정

규칙을 구성하는 방식 때문에 Network Firewall 규칙 관련 문제가 발생할 수 있습니다.

스테이트리스 규칙

트래픽이 양방향으로 흐르게 하려면 Ingress 및 Egress 규칙 모두에 스테이트리스 규칙을 적용하십시오. 수신 트래픽의 Ingress에 규칙을 적용하는 경우, 응답 트래픽의 Egress에도 규칙을 적용해야 합니다. 응답 트래픽의 Egress에 규칙을 적용하는 경우, 수신 트래픽의 Ingress에도 규칙을 적용해야 합니다. 이 규칙 구성은 액세스 제어 목록(ACL)과 유사합니다. 자세한 내용은 AWS Network Firewall에서 스테이트리스 규칙 그룹 작업을 참조하십시오.

패킷에 대한 스테이트리스 기본 작업

방화벽 정책에서 전체 패킷 및 조각화된 패킷 모두에 대한 스테이트리스 기본 작업을 검토하십시오. 기본 작업 설정에 따라 개별 패킷이 스테이트리스 규칙과 일치하지 않으면 스테이트리스 엔진이 해당 패킷을 어떻게 처리하는지 결정됩니다. 조각화된 패킷에 대한 스테이트리스 기본 작업은 UDP 전송 프로토콜을 사용하는 IPv4 패킷 조각에만 적용하십시오. 자세한 내용은 AWS Network Firewall의 방화벽 정책 설정을 참조하십시오.

참고: IPv6 프로토콜은 네트워크에서 조각화를 지원하지 않습니다. 호스트가 수신 호스트의 MTU보다 큰 패킷을 보내면 수신 호스트는 해당 패킷을 삭제합니다. 경로의 디바이스도 디바이스의 MTUㅂ보다 큰 패킷을 삭제합니다.

스테이트풀 규칙

스테이트풀 규칙 엔진이 트래픽을 검사하려면 스테이트풀 규칙 엔진이 두 트래픽 흐름 방향을 모두 스테이트풀 규칙 그룹에 전달해야 합니다. 자세한 내용은 Network Firewall 스테이트리스 및 스테이트풀 규칙 엔진을 참조하십시오.

Network Firewall 규칙은 프라이빗 IP 주소를 참조해야 함

프라이빗 서브넷 또는 워크로드에 퍼블릭 IP 주소와 프라이빗 IP 주소가 모두 있는 경우, Network Firewall 규칙은 프라이빗 IP 주소를 참조해야 합니다.

규칙 그룹 변수

스테이트풀 네트워크 방화벽 규칙 그룹은 HOME_NET 변수를 사용하여 방화벽 검사 범위를 정의합니다. HOME_NET 변수를 명시적으로 지정하지 않는 경우 변수는 기본적으로 네트워크 방화벽이 배포된 VPC CIDR 범위로 설정됩니다. 이 기본 설정에서는 Network Firewall이 VPC 내 소스에서 발생한 트래픽을 검사합니다.

중앙 집중식 Network Firewall을 배포하는 경우, 규칙 그룹의 HOME_NET 변수에 원격 VPC를 포함하거나, 트래픽이 발생한 소스 CIDR을 포함해야 합니다. 자세한 내용은 AWS Network Firewall의 스테이트풀 도메인 목록 규칙 그룹을 참조하십시오.

VPC 전체가 아니라 특정 프라이빗 서브넷의 트래픽만 검사하려면 HOME_NET 변수에 소스 서브넷 CIDR만 포함해야 합니다. 다음 예시에서 HOME_NET 변수는 소스 서브넷 CIDR을 포함합니다.

"RuleVariables": {
        "IPSets": {
           "HOME_NET": {
             "Definition": [
               "10.0.0.0/16",
               "10.1.0.0/16",
               "192.168.2.0/24"
             ]
           }
        }
    }

DescribeRuleGroup API를 사용해 스테이트풀 규칙 그룹 세부 정보를 확인하십시오. 응답에 RuleVariables 객체가 없는 경우, 방화벽 규칙 그룹은 기본 설정을 사용합니다. HOME_NET에 대한 기본 설정은 Network Firewall VPC CIDR로 설정됩니다.

규칙 평가 순서

TCP를 사용하는 애플리케이션인 경우, 3방향 핸드셰이크를 완료해야 애플리케이션이 요청을 보낼 수 있습니다. 연결에서 방화벽에 처음 표시되는 패킷은 소스에서 보낸 TCP SYN입니다. 충돌하는 규칙으로 인해 낮은 수준 TCP 패킷이 차단되는 경우, 3방향 핸드셰이크가 성공하지 못하고 애플리케이션은 시간 초과됩니다.

예를 들어 도메인 목록 규칙 그룹은 호스트 이름을 감지하기 위해 HTTP 요청에서 Host 헤더를 사용합니다. 또한 TLS 핸드셰이크에서 서버 이름 표시(SNI) 확장도 사용합니다. HTTP 요청 및 TLS 협상이 이루어지려면 포트 80(HTTP) 및 443(HTTPS)에서 첫 3방향 TCP 핸드셰이크가 먼저 완료되어야 합니다.

애플리케이션과 전송 계층을 모두 포함하는 규칙을 사용하는 경우, 애플리케이션에 필요한 TCP 포트에서 트래픽을 허용하십시오. 앞의 규칙이 트래픽과 일치하는지 확인하려면 규칙 평가 순서를 참조하십시오.

기본 작업 순서를 사용해 평가 중에 다른 규칙이 트래픽을 차단하지 않는지 확인합니다. 규칙에서 흐름 키워드를 사용하면 상위 수준의 애플리케이션 프로토콜이 식별되기 전에 하위 수준 프로토콜 패킷에 대하여 매칭하지 않도록 방지할 수 있습니다.

규칙 구성 예시 검토

TCP 트래픽에 대한 잘못된 규칙 구성

다음 예시에서는 규칙이 잘못 구성되어 아웃바운드 TCP 연결을 모두 차단하고 example.com으로 HTTP 요청만 허용하게 설정되었습니다. TCP 트래픽이 모두 삭제되므로 소스 클라이언트가 HTTP 애플리케이션 요청을 보낼 수 없습니다.

pass http $HOME_NET any -> $EXTERNAL_NET 80 (http.host; dotprefix; content:"example.com"; endswith; msg:"Allowed HTTP domain"; sid:172191; rev:1;)
drop tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"Drop outbound TCP traffic"; sid:172192; rev:1;)

TCP 연결의 올바른 구성

다음 예시에서는 ‘TCP 허용’ 규칙으로 TCP 연결을 먼저 설정합니다. 그런 다음 ‘허용된 HTTP 도메인’ 규칙이 HTTP 호스트 example.com으로의 연결을 허용합니다. ‘다른 모든 HTTP 도메인 삭제’ 규칙은 나머지 HTTP 트래픽을 차단하고, ‘기본 Egress TCP 삭제’ 규칙은 HTTP 애플리케이션 계층 트래픽을 제외한 다른 모든 TCP 트래픽을 차단합니다.

pass tcp $HOME_NET any -> $EXTERNAL_NET 80 (msg:"Allow TCP"; flow: not_established; sid:172190; rev:1;)
pass http $HOME_NET any -> $EXTERNAL_NET 80 (http.host; dotprefix; content:"example.com"; endswith; msg:"Allowed HTTP domain"; sid:172191; rev:1;)
drop http $HOME_NET any -> $EXTERNAL_NET 80 (msg:"Drop all other HTTP domains"; sid:172192; rev:1; flow: to_server;)
drop tcp $HOME_NET any -> any any (app-layer-protocol:!http; msg:"Default Egress TCP Drop"; flow:to_server; sid:172193;)

참고: example.com을 대상 도메인으로 바꾸십시오.

TCP 허용(sid:172190) 규칙이 포트 80에서 TCP 연결 설정을 허용합니다. 이 규칙은 flow: not_established 키워드를 사용해 첫 연결 설정을 허용합니다. 허용된 HTTP 도메인(sid:172191) 규칙은 HTTP 호스트 헤더를 검사하여 example.com으로의 HTTP 트래픽을 허용합니다. 다른 모든 HTTP 도메인 삭제(sid:172192) 규칙이 flow: to_server 키워드를 사용해 example.com 이외의 도메인에 대한 HTTP 트래픽을 차단합니다. 기본 Egress TCP 삭제(sid:172193) 규칙은 app-layer-protocol:!http 키워드를 사용해 HTTP를 애플리케이션 계층 프로토콜로 사용하지 않는 모든 TCP 트래픽을 차단합니다.

기본 작업 순서는 정의된 규칙과 일치하지 않는 패킷을 자동으로 허용합니다.

규칙 그룹은 엄격한 평가 순서에 따라 우선순위 순서대로 평가되며, 번호가 가장 작은 것부터 시작합니다. 각 규칙 그룹의 규칙은 정의된 순서대로 처리됩니다. 규칙의 구성 및 수동 우선순위 순서가 올바른지 확인하십시오. 우선순위가 낮은 규칙을 네트워크 트래픽에 매칭하지 마십시오. 엄격한 방화벽 정책에서 선택한 기본 작업에 따라 규칙을 작성합니다. 자세한 내용은 AWS Network Firewall에서 Suricata 호환 규칙에 대한 평가 순서 관리를 참조하십시오.

잘못된 구성으로 인한 시간 초과 발생

다음 예시에서는 지정된 구성이 방화벽이 HTTP 애플리케이션 수준 요청을 감지하기 전에 기본적으로 모든 TCP 트래픽을 삭제합니다. 이 구성으로 인해 예기치 않은 시간 초과가 발생합니다.

Default Action: Drop all
Rule: pass http $HOME_NET any -> $EXTERNAL_NET 80 (http.host; dotprefix; content:"example.com"; endswith; msg:"Allowed HTTP domain"; sid:172191; rev:1;)

TCP 3방향 핸드셰이크를 허용하는 올바른 구성

다음 예시에서는 Network Firewall이 TCP 3방향 핸드셰이크가 완료되도록 허용하고, 도메인 example.com에 대한 HTTP 트래픽만 허용합니다.

Default Action: Drop established
Rule: pass http $HOME_NET any -> $EXTERNAL_NET 80 (http.host; dotprefix; content:"example.com"; endswith; msg:"Allowed HTTP domain"; sid:172191; rev:1;)

더 많은 방화벽 규칙 예시는 Network Firewall의 스테이트풀 규칙 예시를 참조하십시오.