AWS Network Firewall 의 Rule Evaluation Order 이해하기

1. 서론

Amazon Web Services(AWS)환경에서의 보안을 위하여 지난 10여년간 다양한 보안 서비스와 기능을 출시하고 고객들이 보다 안전하게 VPC 네트워크를 구성할 수 있도록 도움을 드리고 있습니다. 특히, 네트워크 방화벽이 필요했던 고객분들은 AWS Network Firewall 이 출시됨으로써 기존에 사용하던 Network Access Control List 나 Security Group 에서 구현하기 어려웠던 Host 기반 트래픽 통제나 TLS(Transport Layer Security)로 암호화되어 있는 데이터에 대한 통제가 가능하게 되었습니다. AWS Network Firewall 은 AWS 가 제공하는 관리형 방화벽 서비스로서 Virtual Private Cloud(VPC) 내에 배치되어 VPC 내/외부로 통신하는 트래픽에 대한 검사 및 차단 기능을 제공합니다. AWS Network Firewall 은 내부적으로는 AWS Gateway Load Balancer 와 통합되어 구성되어 있으며 별도의 AWS 관리형 VPC 내에 AWS Network Firewall 을 배치한 후 AWS 가 관리 및 운영하기 때문에 고객의 입장에서는 네트워크 방화벽 구성 시 발생할 수 있는 관리(예를 들어, 트래픽 증가에 의한 확장이나 OS 업그레이드 작업, 다수의 네트워크 방화벽에 대한 정책 동기화 등)에 대한 부담을 최소화할 수 있다는 장점을 제공하고 있습니다. 또한, 국내 고객의 경우 각종 인증 취득이나 내부 규정 준수를 위하여 IDS(Intrusion Detection System)이나 IPS(Intrusion Protection System)을 VPC환경에서 구성하기를 원하는 사례가 많았는데 AWS Network Firewall 의 출시 덕분에 파트너 솔루션 뿐만 아니라 AWS 서비스를 통해서도 IDS/IPS 를 구성할 수 있는 옵션을 제공할 수 있게 되어 고객의 상황에 따라 최적의 구성을 선택하실 수 있게 되었습니다.

이처럼 고객에게 새로운 보안 구성 옵션을 제공하고 있는 AWS Network Firewall 은 AWS 의 관리형 서비스로서, AWS 가 제공하는 또 다른 네트워크 보안 기능인 Security Group 과 Network Access Control List 와 비교했을 때 다음과 같은 장점들을 제공하고 있습니다.

IP 주소 + 포트 + 프로토콜 조합의 차단 뿐만 아니라 페이로드를 검사하여 위협을 탐지/차단 하는 기능을 제공합니다.
네트워크 트래픽에 대해 특정 규칙을 탐지 목적으로만 사용하거나 탐지 및 차단 목적으로 사용하실 수 있습니다.
IDS/IPS 로 사용하고자하는 경우 AWS 관리형 규칙을 무상으로 사용하실 수 있습니다.
AWS 파트너에서 제공하는 파트너 관리형 규칙을 유상으로 사용하실 수 있습니다.
AWS Certificate Manager 에서 발행한 TLS 인증서 기반의 암호화를 사용하는 경우 AWS Network Firewall 에서 암호화된 트래픽을 복호화한 후 IDS/IPS 기능 적용이 가능합니다.
VPC 자원에 대한 허용/차단 규칙을 자원에 부여된 Tag 를 기반으로 제어할 수 있습니다.
AWS Network Firewall 에서 차단된 트래픽에 대한 별도의 전용 로그가 제공됩니다. (AWS Network Firewall 에 의해 차단된 트래픽 검사를 위해 VPC Flow Log 를 사용하지 않아도 됩니다.)
AWS Network Firewall 은 AWS Gateway Load Balancer 와 통합되어 구성되므로 여러 VPC 에 대한 통합 네트워크 보안 환경을 구성하실 수 있습니다.
VPC 내부에서 외부로 향하는 HTTPS 트래픽에 대한 복호화 및 특정 패턴에 대한 탐지/차단이 가능합니다.
AWS Network Firewall 을 통과하는 트래픽에 대한 Netflow 정보를 수집하실 수 있습니다.

2. AWS Network Firewall 의 동작 방식

이렇게 다양한 장점들을 제공하고 있는 AWS Network Firewall 이지만 아직 AWS Network Firewall 의 동작방식에 익숙하지 않은 고객분들이 많고 이로 인해 방화벽의 규칙을 적용하는 과정에서 관리자의 의도와 다르게 동작한다는 오해 아닌 오해를 일으키는 것을 가끔 볼 수 있었습니다. 따라서 이 글에서는 AWS Network Firewall 의 동작 방식을 살펴보고 몇 가지 예제를 통해 이 동작 방식을 설명해 보도록 하겠습니다.

그림. AWS Network Firewall 의 정책 검사 흐름

3. 규칙 엔진

AWS Network Firewall 은 내부적으로 두 개의 서로 다른 규칙 엔진(Rule Engine)을 가지고 있습니다. Stateless Rule Engine 과 Stateful Rule Engine 이 바로 그것인데요. 이 두 규칙엔진은 기존에 여러분들이 VPC 내에서 사용하던 Network Access Control List, Security Group 과 비슷한 특성을 가지고 있습니다.

3.1 Stateless Rule Engine

Gateway Load Balancer 를 통해 트래픽이 AWS Network Firewall 로 유입되게 되면 가장 먼저 트래픽을 처리하게 되는 규칙엔진입니다. Stateless Rune Engine 은 이름에 나타나듯이 트래픽 플로우에 대해 Stateless 하게 처리하는 특징을 가지고 있습니다. 쉽게 설명드리면 Subnet 에 적용하는 NACL 처럼 Stateless Rule Engine 은 규칙 검사를 Packet 마다 수행하게 됩니다. 즉, TCP 트래픽의 경우 SYN 패킷이 Stateless Rule Engine 에 의해 허용되었다 하더라도 SYN/ACK 패킷 역시 Stateless Rule Engine 의 검사를 받게 되며 매칭되는 규칙의 액션이 Drop 인 경우 해당 패킷은 차단되어 결과적으로 TCP State 와 관계 없이 TCP 세션이 정상적으로 연결될 수 없게 됩니다.

그리고 Stateless Rule Engine 은 인입되는 트래픽의 정보 중 Layer 4 까지의 정보만 검사한다는 특징을 가지고 있습니다. 즉, AWS Network Firewall 의 관리자는 Stateless Rule Engine 을 이용하여 프로토콜, IP 주소, Port 번호, TCP Flag 등을 기반으로 인입되는 트래픽을 허용하거나 차단하는 규칙을 작성할 수 있습니다.

또 한 가지 Stateless Rune Engine 의 특징은 Forward 라는 Action Type 을 가진다는 것입니다. Forward 는 Stateless Rule Engine 에서 직접 트래픽에 대한 허용(Pass), 차단(Drop) 에 대한 의사 결정을 수행하는 것이 아니라 Stateful Rule Engine 으로 트래픽 정보를 전송하여 Stateful Rule Engine 에 의해 허용/차단이 수행될 수 있도록 하는 액션입니다. 관리자는 Stateless Rule Engine 에서 제공하는 규칙을 통해 인입되는 트래픽을 처리할 수 없는 경우, 예를 들어 도메인이나 패킷의 페이로드를 검사하여 특정 문자열이나 패턴을 매칭한 후 탐지 혹은 차단해야 하는 경우에는 Forward 액션을 통해 인입되는 트래픽을 Statefule Rule Engine 으로 전달하는 것이 가능합니다.

마지막으로, Stateless Rule Engine 은 트래픽을 허용/차단하는 경우(Forward 포함)에 별도의 로그를 남기지 않습니다. 이 부분은 AWS Network Firewall 을 운영하는데 있어 반드시 숙지하고 있어야 할 특징 중 하나인데요. Stateless Rule Engine 은 관리자가 지정한 규칙에 따라 트래픽을 처리(허용/차단/전달)할 수 있지만 이와 관련한 로그가 남지 않기 때문에 AWS Network Firewall 운영 환경에서 트래픽 처리 로그가 필수 요구 사항이라면 Stateless Rule Engine 이 아닌 Stateful Rule Engine 에서 트래픽을 처리(허용/차단)하도록 구성해야 합니다.

3.2 Stateful Rule Engine

Stateful Rule Engine 은 Security Group 과 유사하게 트래픽의 세션 연결 지향성에 대한 Stateful 한 특성을 가지고 있습니다. 즉, Stateful Rule Engine 규칙에 의해 한 번 허용된 트래픽은 해당 트래픽의 연결 정보에 따라 각 패킷들에 대해 모두 규칙 검사를 수행하는 것이 아니라 즉시 트래픽이 허용된다는 특징을 가지고 있습니다. Stateful Rule Engine 이외에도 다양한 특징들을 포함하고 있는데요. Stateful Rule Engine 의 주요 특징들을 살펴 보면 다음과 같습니다.

3.2.1 Rule Evaluation Order 옵션

Stateful Rule Engine 은 최초 AWS Network Firewall 의 정책을 설정 할 때 두 가지 종류 중 한가지 Rule Evaluation Order 를 선택해야 합니다. Stateful Rule Engine 에서 제공하는 Rule Evaluation Order 는 “Strict Order” 와 “Action Order” 이며 AWS 에서 권장하는 Rule Evaluation Order 옵션은 “Strict Order” 입니다. “Strict Order” 와 “Action Order” 는 Stateful Rule Engine 로 인입된 트래픽에 대한 규칙 검사 순서를 결정하는 중요한 설정 옵션이기 때문에 관리자는 이 두가지 옵션 중 하나를 선택할 때 각 옵션의 동작방식을 정확하게 이해한 후 선택해야 합니다.

3.2.2 Strict Order 의 규칙 적용 순서

Strict Order” 는 AWS 에서 권장하는 Rule Evaluation Order 이며 Stateful Rule Engine 로 유입되는 트래픽을 검사할 때 Stateful 규칙의 Priority 를 기준으로 검사를 수행하게 됩니다. 즉, 각 규칙의 Action 과 관계없이 Priority 가 높은(숫자가 낮은) 규칙을 먼저 검사하는 Rule Evaluation Order 방식입니다. 일반적으로 방화벽에서 사용하는 규칙 적용 방식과 유사한 방식이며 흔히 이야기하는 Top-Down 방식으로 AWS Network Firewall 의 규칙이 적용되기 때문에 관리자의 입장에서는 규칙 관리 및 문제 해결 시 직관적인 접근이 가능하다는 장점을 가지고 있습니다.

“Strict Order” 를 적용한 상태에서 인입된 트래픽에 대해 어떠한 Stateful Rule Group 의 어떠한 규칙도 매칭되지 않는 경우에는 Default Action 이 적용되게 됩니다. “Strict Order” 의 Default Action 은 선택 가능하며 아래와 같은 옵션을 제공하고 있습니다. 보다 자세한 사항은 링크를 참고하시기 바랍니다.

– Drop all

– Drop established

– Alert all

– Alert established

3.2.3 Action Order 의 규칙 적용 순서

“Action Order” 는 Stateful 규칙에 정의된 각 Action 유형에 따라 트래픽에 대한 규칙 검사 순서가 정해지는 방식입니다. Stateful Rule Group 의 Action 은 “pass”, “drop”, “reject”, “alert” 의 순서에 따라 트래픽을 검사하게 됩니다. 따라서, “Action Order” 를 사용할 때에는 각 Stateful Rule Group 이 가지고 있는 Priority 키워드의 값은 Action 순서에 따라 규칙 검사를 결정하는 단계에서는 무시되며 동일한 Action 을 검사하는 과정에서는 동일한 Action 을 갖는 Stateful Rule Group 의 Priority 키워드의 값에 따라 우선 순위가 달라지게 됩니다. Priority 키워드의 값은 1~255이며 낮은 숫자가 높은 Priority 를 의미합니다. 보다 자세한 사항은 링크를 참고하시기 바랍니다.

“Action Order” 를 적용한 상태에서 인입된 트래픽에 대해 어떠한 Stateful Rule Group 의 어떠한 규칙도 매칭되지 않는 경우에는 Default Action 이 적용되게 됩니다. “Action Order” 의 Default Action 은 Pass 입니다.

3.2.4 Pass 규칙 로깅

AWS Network Firewall 은 다양한 로깅 옵션을 제공하지만 Pass 규칙에 대한 로깅은 제공하지 않습니다. 따라서, 특정 트래픽 패턴에 대해 AWS Network Firewall 의 처리 유무를 확인하는 것이 목적이라면 Pass Action 보다는 Alert Action 을 사용하여 Alert 로그를 활용하시기 바랍니다.

4. AWS Network Firewall 규칙 적용 사례

그럼 이제 본격적으로 몇 가지 AWS Network Firewall 의 규칙 적용 사례를 통해 일반적으로 관리자가 실수할 수 있는 항목들을 살펴보고 어떤 식으로 규칙을 작성하는 것이 설정 실수에 의한 의도하지 않은 장애 혹은 오류를 최소화할 수 있는지 살펴보도록 하겠습니다.

4.1 규칙 적용 사례. Outbound Host 차단

4.1.1 보안 요구 사항

요구 사항 1. VPC 내부에서 외부로 향하는 HTTP/HTTPS 트래픽 중 도메인 네임이 “*.aws.amazon.com” 과 “*.amazon.com” 인 것을 제외한 모든 도메인에 대한 접근을 차단하세요.

요구 사항 2. “요구 사항 1″에 정의된 허용 정책 이외의 외부 접속은 모든 프로토콜에 대해 차단하세요.

4.1.2 관리자 설정

– Rule Evaluation Order = Strict Order 사용

– 도메인 네임 기반 트래픽 허용을 위해 Domain List Rule Group 을 아래와 같이 사용

그림. Domain List Rule Group 설정

– 모든 트래픽을 차단하기 위해 아래와 같이 Standard Rule Group 사용

그림. Standard Rule Group 설정

– 아래와 같이 2개의 Rule Group 을 Firewall Policy 에 적용

그림. Stateful Rule Group 설정 상세

4.1.3 적용 결과

위와 같이 Stateful Rule Group 의 규칙을 생성한 후 VPC Public Subnet 에서 외부로 테스트를 수행하게 되면 .aws.amazon.com 과 .amazon.com 을 포함한 모든 사이트에 대한 접근이 차단되게 됩니다.

관리자가 설정한 규칙에 따르면 Domain-Filtering 규칙에 의해서 특정 도메인에 대한 접근은 허용되어야 하고 IP-Filtering 규칙에 의해 다른 접근은 모두 차단되어야 하는데 왜 모든 접근이 차단되는 것일까요?

주의. 이 시나리오에서 IP-Filtering 규칙은 Strict Order 의 Default Action 이 Drop 혹은 Drop-Established 로 설정되어 있다면 불필요한 설정이며 AWS Network Firewall 의 동작방식을 설명하기 위해 추가한 규칙임을 참고하시기 바랍니다.

그 이유는 바로 각 Stateful Rule Group 이 검사하는 검사 대상 프로토콜에 있습니다. Domain List Rule Group 은 HTTP/HTTPS 프로토콜을 기반으로하여 트래픽을 검사하게 되며 Standard Rule Group 은 관리자가 지정한 프로토콜에 기반하여 트래픽을 검사하게 됩니다. 위 시나리오의 경우에는 관리자가 IP 프로토콜을 검사하도록 지정하였습니다.

즉, 위의 시나리오에서 관리지가 설정한 Rule Group 의 내용을 보면 Domain List Rule Group 의 Priority 는 높지만 Standard Rule Group 에서 검사하는 프로토콜이 하위 프로토콜이기 때문에 VPC 내부에서 외부로 트래픽이 향할 때 Domain-Filtering 규칙 검사 전에 IP-Filtering 규칙 검사가 먼저 수행되어 Domain-Filtering 규칙의 설정과 관계없이 IP-Filtering 규칙에서 모두 차단되게 된 것입니다.

그럼 Standard Rule Group 의 규칙을 어떻게 작성해야 요구 사항을 만족할 수 있을까요?(지정된 Host 에 대한 HTTP/HTTPS 접근은 허용하고 나머지 모든 프로토콜에 대한 접근은 차단)

첫번째 시도를 해보도록 하겠습니다. 아래 그림과 같이 Standard Rule Group 의 규칙에 적용되었던 IP 프로토콜을 제거하고 Domain List Rule Group 에서 트래픽을 검사하는 프로토콜인 HTTP 와 TLS 를 기반으로 트래픽을 차단하도록 규칙을 작성하였습니다.

그림. 수정된 Stateful Rule Group 설정 상세

이렇게 작성된 규칙을 기반으로 테스트를 해보면 Domain List Rule Group 에 정의된 도메인 에 대해서 HTTP/HTTPS 접속은 정상적으로 허용되고 다른 도메인에 대해서는 모두 차단이 되는 것을 확인할 수 있습니다.

그렇다면, 이처럼 작성된 Standard Rule Group 이 위 시나리오에서 요구하는 요구사항을 만족한다고 할 수 있을까요? 당연하게도 그렇지 않습니다. 왜냐하면 이렇게 작성된 Standard Rule Group 은 HTTP/TLS 프로토콜에 대해서만 검사를 수행하기 때문에 모든 프로토콜을 차단하는 것이 아니라 HTTP/TLS 프로토콜만 차단하게 됩니다.

참고. Domain List Rule Group 의 Action 이 Allow 로 설정된 경우에는 별도의 추가 Rule Group 설정이 없더라도 지정된 도메인 이외의 도메인에 접속하는 HTTP/HTTPS 트래픽은 차단되게 됩니다. 따라서, 위와 같은 Standard Rule Group 은 불필요한 설정이 되게 됩니다.

그러면 이제 다른 접근을 해보도록 하겠습니다. AWS Management Console 에서 편리하게 사용할 수 있는 Domain List Rule Group 을 사용하지 않고 Suricata Compatible Rule String Format 을 이용하여 요구 사항을 만족하는 규칙을 작성해보도록 하겠습니다.

시나리오에서 요구하는 요구 사항을 만족하기 위해 작성된 Suricata 규칙은 아래와 같습니다.

pass tls $HOME_NET any -> $EXTERNAL_NET any (tls.sni; content:".aws.amazon.com"; endswith; ssl_state:client_hello; nocase; flow: to_server; sid:202403011;)
pass tls $HOME_NET any -> $EXTERNAL_NET any (tls.sni; content:".amazon.com"; endswith; ssl_state:client_hello; nocase; flow: to_server; sid:202403012;)
pass http $HOME_NET any -> $EXTERNAL_NET any (http.host; content:".aws.amazon.com"; endswith; flow: to_server; sid:202403013;)
pass http $HOME_NET any -> $EXTERNAL_NET any (http.host; content:".amazon.com"; endswith; flow: to_server; sid:202403014;)
drop ip $HOME_NET any -> $EXTERNAL_NET any (flow: to_server, established; sid:202403015;)

이렇게 작성된 Suricata Compatible Rule Group 아래와 그림과 같이 모든 Rule Group 들을 분리하고 적용한 후 테스트를 진행해보도록 하겠습니다.

그림. 수정된 Stateful Rule Group 설정 상세

모든 설정이 정상적으로 되었다면 위처럼 적용된 Suricata Compatible Rule Group 은 시나리오에서 요구하는 것처럼 지정된 도메인에 대해서는 HTTP/HTTPS 프로토콜에 한하여 허용하고 나머지 모든 프로토콜에 대한 트래픽은 차단하는 것을 알 수 있습니다.

위와 같이 작성된 Suricata Rule Group 이 왜 시나리오에서 요구하는 보안 요구사항을 만족하도록 동작하는지를 이해하려면 1) Strict Evaluation Order 의 규칙 검사 순서 2) Suricata Rule 에서 사용하는 프로토콜의 용도 3) Suricata Rule 에서 사용하는 flow 의 용도 등에 대한 이해가 선행되어야 합니다.

작성된 Surlcata Compatible Rule Group 의 가장 아래에 위치한 IP 프로토콜의 규칙은 프로토콜 구조를 본다면 가장 먼저 검사가 되어야 합니다. 그리고 이 규칙의 내용이 모든 IP 에 대해 drop 하는 Action 으로 구성되었기 때문에 프로토콜 구조만 생각한다면 처음 관리자가 설정한 규칙과 마찬가지로 지정된 도메인을 포함한 모든 IP 통신을 차단해야 합니다. 하지만, 실제로 테스트를 진행하면 모든 IP 통신이 차단되는 것이 아니라 위쪽에 위치한 pass 로 허용되지 않은 트래픽에 대해서만 차단하는 것을 확인할 수 있습니다. 이 Suricata Rule Group 이 이렇게 동작하는 이유는 아래에 있는 flow 키워드에 그 비밀이 숨겨져 있습니다.

drop ip $HOME_NET any -> $EXTERNAL_NET any (flow: to_server, established; sid:202403015;)

이 규칙에 사용된 flow 키워드는 flow: to_server, established 입니다. 즉, Client 에서 Server 로 향하는 트래픽이며 이미 연결이 수립된 트래픽만 대상이 된다는 의미인데요. 만일 이 flow 키워드의 설정을 flow: to_server 처럼 바꿔버린다면 Stateful Rule Engine 은 트래픽의 세션 연결 상태를 고려할 필요가 없기 때문에 도메인을 검사하기 전단계인 IP 프로토콜 검사 단계에서 규칙을 적용하여 모든 IP 통신을 차단하게 될 것입니다. 하지만, 우리가 사용한 flow: to_server, established 키워드는 매칭된 트래픽을 차단하는 기준이 세션 연결이 수립된 트래픽에 한해서 적용되도록 설정되어 있기 때문에 타 프로토콜(이 시나리오에서는 HTTP/TLS 프로토콜)의 검사를 마친 후에 규칙이 적용되었다고 생각하시면 될 것 같습니다.

결과적으로 이 글에서 주어진 시나리오를 만족하기 위해서는 2가지 방법이 있음을 알 수 있었습니다.

방법 1. Strict Order 를 사용하되 Default Action 은 Drop-Established 를 사용하고 Domain List Rule Group 의 Allow Action 만 사용한다.

방법 2. Strict Order 를 사용하되 Suricata Rule Group 만으로 요구 사항을 구현한다.

참고. 주어진 시나리오를 만족하기 위한 AWS Network Firewall 의 Rule Group 설정 방법은 이 글에서 소개한 2가지 이외에도 Action Order 를 사용한 환경에서 구현하거나 혹은 이 글에서 언급되지 않은 방법을 통해서 구현될 수도 있습니다.

5. 마무리

우리는 지금까지 주어진 시나리오를 통해서 AWS Network Firewall 이 Stateful Rule Group 의 규칙을 적용할 때 어떤 원리(프로토콜의 우선 순위)를 가지고 트래픽을 검사하는지 살펴보았습니다. AWS Network Firewall 이 제공하는 다양한 옵션들을 모두 살피고 여러가지 시나리오에 대응하는 규칙들을 하나 하나 살펴볼 수는 없었지만 여러분들이 복합적인 요구 사항을 수용하는 규칙을 작성할 때 Stateful Rule Group 이 갖는 특징들을 조금이나마 이해하는데 도움이 되는 포스팅이 되었기를 바랍니다.

참고. AWS Network Firewall 규칙 작성 시 모범 사례

Stateless 규칙 보다는 Stateful 규칙을 사용한다.
Stateful Rule Group 의 Rule Evaluation Order 는 "Strict Order" 를 사용한다.
"Strict Order" 의 Default Action 은 "Drop Established" 를 사용한다.
Domain List 제어와 Suricata Compatible Rule 사용이 함께 적용되어야 하는 경우라면 Domain List 규칙을 Suricata Compatible Rule 에 정의하여 사용한다.
사용자 정의 Suricata Compatible 규칙을 적극적으로 사용한다.
사용자 정의 Rule Group 의 수는 최소한으로 유지한다.
$HOME_NET 변수 설정이 정확하게 되어 있는지 확인한다.
로그 확인이 필요한 경우 Alert 규칙을 Pass 규칙보다 우선하도록 Priority 를 조정한다.
사용자 정의 Suricata Compatible 규칙 생성 시 "flow:to_server, established" 키워드를 적극적으로 사용한다.
VPC Endpoint 를 적극적으로 활용하여 AWS Network Firewall 로 경유하는 트래픽의 양을 줄이고 비용을 절감한다.
로깅과 모니터링 설정을 활성화한다.
네트워크 연결 문제 발생 시 VPC Reachability Analyzer 를 활용하여 AWS Network Firewall 에 의해 차단되는 트래픽이 있는지 확인한다.

참고. Suricata 규칙 작성과 관련하여 보다 자세한 사항은 Examples of stateful rules for Network Firewall과 지난 AWS:reInforce 2023 의 발표 동영상을 참고하시기 바랍니다.

AWS 기술 블로그