AWS re:Post을(를) 사용하면 다음에 동의하게 됩니다. AWS re:Post 이용 약관
AWS re:Postre:Post

규칙이 예상대로 작동하지 않을 때 네트워크 방화벽 관련 문제를 해결하려면 어떻게 해야 하나요?

6분 분량
0

규칙이 예상대로 작동하지 않을 때 AWS 네트워크 방화벽 관련 문제를 해결하고 싶습니다.

간략한 설명

다음과 같은 시나리오로 인해 네트워크 방화벽 규칙이 예상대로 작동하지 않을 수 있습니다.

  • 트래픽은 방화벽을 통해 대칭적으로 라우팅되지 않습니다.
  • 네트워크 방화벽 규칙이 잘못 구성되었습니다.

**참고:**네트워크 방화벽 문제를 해결하려면 먼저 다음 구성을 확인하세요.

  • 방화벽 엔드포인트는 전용 서브넷과 라우팅 테이블에 배포됩니다. 방화벽 서브넷에는 워크로드 리소스가 없어야 합니다.
  • 라우팅 테이블은 방화벽 엔드포인트를 통해 트래픽을 라우팅합니다. Amazon CloudWatch 지표 ReceivedPackets을 확인하여 네트워크 방화벽이 패킷을 수신했는지 확인하세요. ReceivedPackets 지표 값이 0인 경우 라우팅 테이블에 방화벽 엔드포인트를 가리키는 올바른 경로가 있는지 확인하세요.

해결 방법

참고: AWS Command Line Interface(AWS CLI) 명령을 실행할 때 오류가 발생하는 경우 최신 AWS CLI 버전을 사용하고 있는지 확인하세요.

트래픽이 방화벽을 통해 대칭적으로 라우팅되지 않음

중앙 집중식 네트워크 방화벽 배포 모델의 경우 검사 Virtual Private Cloud(VPC)의 Transit Gateway Attachment을 위한 어플라이언스 모드를 켜세요.

다음 AWS CLI 명령을 실행하여 어플라이언스 모드가 켜져 있는지 확인합니다.

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

다음 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로 바꾸세요.

퍼블릭 서브넷에 방화벽 엔드포인트를 배포할 때는 인터넷 게이트웨이의 인그레스 라우팅 테이블이 방화벽 엔드포인트를 통해 프라이빗 서브넷으로 라우팅되어야 합니다. 또한 프라이빗 서브넷의 라우팅 테이블은 인터넷 트래픽을 동일한 방화벽 엔드포인트로 라우팅해야 합니다. 자세한 내용은 인터넷 게이트웨이가 있는 간단한 단일 영역 아키텍처를 참조하세요.

다중 AZ 방화벽 배포 설정의 경우 인터넷 게이트웨이의 인그레스 라우팅 테이블은 동일한 방화벽 엔드포인트를 통해 프라이빗 서브넷으로 트래픽을 라우팅해야 합니다. 또한 라우팅 테이블은 프라이빗 서브넷과 동일한 가용 영역에 있어야 합니다. 자세한 내용은 인터넷 게이트웨이가 있는 다중 영역 아키텍처를 참조하세요.

네트워크 방화벽 규칙이 잘못 구성되었습니다.

네트워크 방화벽 규칙과 관련된 문제는 규칙을 구성하는 방법 때문일 수 있습니다.

스테이트리스 규칙

트래픽이 양방향으로 흐르려면 수신 및 송신 규칙에 스테이트리스 규칙을 적용해야 합니다. 수신 트래픽의 수신에 규칙을 적용하는 경우 응답 트래픽의 송신에도 규칙을 적용해야 합니다. 응답 트래픽의 송신에 규칙을 적용하는 경우 수신 트래픽에 대한 수신에도 규칙을 적용해야 합니다. 이 규칙 구성은 액세스 제어 목록(ACL)과 유사합니다.

다음 예제는 스테이트리스 규칙을 사용하여 들어오는 SSH 트래픽을 허용하는 방법을 보여줍니다.

우선순위프로토콜원본대상원본 포트 범위대상 포트 범위작업
1.TCP0.0.0.0/010.1.0.0/160:6553522패스
2.TCP10.1.0.0/160.0.0.0/0220:65535패스

 

**참고:**위 예에서는 들어오는 SSH 트래픽이 모든 IP 주소에서 CIDR 10.1.0.0/16을 통해 라우팅됩니다.

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

전체 패킷과 조각화된 패킷 모두에 대한 스테이트리스 기본 작업을 검토하세요. 기본 작업 설정은 개별 패킷이 스테이트리스 규칙과 일치하지 않을 때 방화벽 스테이트리스 엔진이 개별 패킷을 처리하는 방법을 결정합니다. 조각화된 패킷에 대한 스테이트리스 기본 작업을 UDP 전송 프로토콜을 사용하는 IPv4 패킷 조각에만 적용합니다.

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

스테이트풀 규칙

스테이트풀 규칙 엔진이 트래픽을 검사하려면 스테이트풀 규칙 엔진이 두 트래픽 흐름 방향을 모두 스테이트풀 규칙 그룹에 전달해야 합니다.

네트워크 방화벽 규칙은 프라이빗 IP 주소를 참조해야 합니다.

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

규칙 그룹 변수

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

중앙 집중식 네트워크 방화벽을 배포할 때는 규칙 그룹의 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의 기본 설정은 네트워크 방화벽 VPC CIDR로 설정됩니다.

규칙 평가 순서

TCP를 사용하는 애플리케이션은 애플리케이션 요청이 전송되기 전에 3방향 핸드셰이크가 성공해야 합니다. 방화벽이 연결에서 보는 첫 번째 패킷은 원본의 TCP SYN입니다. 충돌하는 규칙이 하위 수준 TCP 패킷을 차단하는 경우 3방향 핸드셰이크가 성공하지 못해 애플리케이션 시간 초과가 발생합니다.

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

애플리케이션 계층과 전송 계층이 모두 포함된 규칙을 사용하는 경우 애플리케이션에 필요한 TCP 포트에서 트래픽을 허용해야 합니다. 규칙 평가 순서를 검토하여 이전 규칙이 트래픽과 일치하는지 확인하세요.

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

규칙 구성 예제

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 연결의 올바른 구성

다음 예에서는 Drop 설정된 TCP:80 규칙이 TCP 연결을 먼저 설정합니다. 그런 다음 HTTP 호스트 이름 example.com과 일치하지 않는 추가 패킷은 모두 삭제됩니다.

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

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

엄격한 평가 순서에 따라 규칙 그룹은 가장 낮은 번호부터 우선 순위에 따라 평가됩니다. 각 규칙 그룹의 규칙은 정의된 순서대로 처리됩니다. 규칙의 구성과 수동 우선 순위가 올바른지 확인하세요. 우선순위가 낮은 규칙을 네트워크 트래픽에 맞추지 마세요. 또한 엄격한 방화벽 정책에서 선택한 기본 동작을 기반으로 규칙을 작성하세요.

잘못된 구성으로 인해 타임아웃 발생

다음 예에서는 방화벽이 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방향 핸드셰이크를 허용하는 올바른 구성

다음 예에서는 네트워크 방화벽을 통해 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의 스테이트풀 규칙 예를 참조하세요.

관련 정보

AWS 네트워크 방화벽 배포 모델

AWS 네트워크 방화벽에서 규칙 작업 정의

배포 VPC 외부에서 들어오는 트래픽에 대한 도메인 목록 검사

스테이트풀 규칙 그룹의 평가 순서

주제
보안, 신원 및 규정 준수
태그
AWS Network Firewall
언어
한국어
AWS 공식
AWS 공식업데이트됨 일 년 전
댓글 없음

관련 콘텐츠