Azure Firewall 규칙 구성

Azure Firewall에서 클래식 규칙 또는 방화벽 정책을 사용하여 NAT 규칙, 네트워크 규칙 및 애플리케이션 규칙을 구성할 수 있습니다. 트래픽을 허용하도록 규칙을 수동으로 구성할 때까지 Azure Firewall은 기본적으로 모든 트래픽을 거부합니다. 규칙이 종료되므로 규칙 처리가 일치에서 중지됩니다.

클래식 규칙을 사용하여 규칙 처리

규칙 컬렉션은 규칙 유형의 우선 순위에 따라 낮은 숫자(100)부터 높은 숫자(65,000) 순서로 처리됩니다. 규칙 컬렉션 이름에는 문자, 숫자, 밑줄, 마침표 또는 하이픈만 포함할 수 있습니다. 규칙 컬렉션 이름은 문자나 숫자로 시작하고 문자, 숫자 또는 밑줄로 끝나야 합니다. 최대 이름 길이는 80자입니다.

처음에 규칙 컬렉션 우선 순위 숫자를 100 단위로(예: 100, 200, 300) 설정하는 것이 가장 좋습니다. 이렇게 하면 필요할 때 규칙 컬렉션을 추가할 수 있는 여유가 있습니다.

방화벽 정책을 사용하여 규칙 처리

방화벽 정책에서 규칙은 규칙 컬렉션 및 규칙 컬렉션 그룹 내에 구성됩니다. 규칙 컬렉션 그룹은 0개 이상의 규칙 컬렉션을 포함합니다. 규칙 컬렉션은 NAT, 네트워크 또는 애플리케이션 형식입니다. 단일 규칙 그룹 내에서 여러 가지 규칙 컬렉션 형식을 정의할 수 있습니다. 하나의 규칙 컬렉션에서 0개 이상의 규칙을 정의할 수 있습니다. 규칙 컬렉션의 규칙은 동일한 형식(NAT, 네트워크 또는 애플리케이션)이어야 합니다.

규칙은 규칙 컬렉션 그룹 우선 순위 및 규칙 컬렉션 우선 순위에 따라 처리됩니다. 우선 순위는 100(가장 높은 우선 순위)에서 65,000(가장 낮은 우선 순위) 사이의 숫자입니다. 우선 순위가 가장 높은 규칙 컬렉션 그룹이 가장 먼저 처리됩니다. 규칙 컬렉션 그룹 내에서 우선 순위가 가장 높은(숫자가 가장 작은) 규칙 컬렉션이 가장 먼저 처리됩니다.

방화벽 정책이 상위 정책에서 상속되는 경우 하위 정책의 우선 순위와 상관없이 상위 정책의 규칙 컬렉션 그룹이 항상 우선적으로 처리됩니다.

참고 항목

규칙 컬렉션 그룹 또는 규칙 컬렉션 우선 순위 및 정책 상속과 상관없이 애플리케이션 규칙은 항상 네트워크 규칙 후에 처리되며, 네트워크 규칙은 DNAT 규칙 후에 처리됩니다.

요약하면:

부모 정책은 항상 우선합니다.

  1. 규칙 컬렉션 그룹은 우선 순위에 따라 처리됩니다.
  2. 규칙 컬렉션은 우선 순위에 따라 처리됩니다.
  3. DNAT 규칙, 네트워크 규칙, 애플리케이션 규칙의 순서로 처리됩니다.

다음은 정책 예제입니다.

BaseRCG1은 DNATRC1, DNATRC3, NetworkRC1이라는 규칙 컬렉션을 포함하는 규칙 컬렉션 그룹 우선 순위(200)라고 가정합니다.
BaseRCG2는 AppRC2, NetworkRC2라는 규칙 컬렉션을 포함하는 규칙 컬렉션 그룹 우선 순위(300)입니다.
ChildRCG1은 ChNetRC1, ChAppRC1이라는 규칙 컬렉션을 포함하는 규칙 컬렉션 그룹 우선 순위(300)입니다.
ChildRCG2는 ChNetRC2, ChAppRC2, ChDNATRC3 규칙 컬렉션을 포함하는 규칙 컬렉션 그룹입니다.

다음 표에 따라:

속성 유형 우선 순위 규칙 다음에서 상속됨
BaseRCG1 규칙 컬렉션 그룹 200 8 상위 정책
DNATRC1 DNAT 규칙 컬렉션 600 7 상위 정책
DNATRC3 DNAT 규칙 컬렉션 610 3 상위 정책
NetworkRC1 네트워크 규칙 컬렉션 800 1 상위 정책
BaseRCG2 규칙 컬렉션 그룹 300 3 상위 정책
AppRC2 애플리케이션 규칙 컬렉션 1200 2 상위 정책
NetworkRC2 네트워크 규칙 컬렉션 1300 1 상위 정책
ChildRCG1 규칙 컬렉션 그룹 300 5 -
ChNetRC1 네트워크 규칙 컬렉션 700 3 -
ChAppRC1 애플리케이션 규칙 컬렉션 900 2 -
ChildRCG2 규칙 컬렉션 그룹 650 9 -
ChNetRC2 네트워크 규칙 컬렉션 1100 2 -
ChAppRC2 애플리케이션 규칙 컬렉션 2000 7 -
ChDNATRC3 DNAT 규칙 컬렉션 3000 2 -

초기 처리:

이 프로세스는 우선 순위가 200인 가장 낮은 RCG(규칙 컬렉션 그룹)인 BaseRCG1을 검사하는 것으로 시작됩니다. 이 그룹 내에서 DNAT 규칙 컬렉션을 검색하고 우선 순위에 따라 평가합니다. 이 경우, DNATRC1(우선 순위 600)과 DNATRC3(우선 순위 610)이 발견되어, 이에 따라 처리됩니다.
다음으로, 다음 RCG인 BaseRCG2(우선 순위 200)로 이동하지만 DNAT 규칙 컬렉션을 찾을 수 없습니다.
그다음에는 DNAT 규칙 컬렉션 없이 ChildRCG1(우선 순위 300)로 진행됩니다.
마지막으로 ChildRCG2(우선 순위 650)를 검사하여 ChDNATRC3 규칙 컬렉션(우선 순위 3000)을 찾습니다.

규칙 컬렉션 그룹 내 반복:

BaseRCG1로 돌아가서 반복 작업을 계속합니다. 이번에는 NETWORK 규칙에 대한 작업입니다. NetworkRC1(우선 순위 800)만 찾을 수 있습니다.
그런 다음 NetworkRC2(우선 순위 1300)가 있는 BaseRCG2로 이동합니다.
ChildRCG1로 이동하면 NETWORK 규칙으로 ChNetRC1(우선 순위 700)을 발견합니다.
마지막으로 ChildRCG2에서는 NETWORK 규칙 컬렉션으로 ChNetRC2(우선 순위 1100)를 찾습니다.

APPLICATION 규칙에 대한 최종 반복:

BaseRCG1로 돌아가서, 이 프로세스는 APPLICATION 규칙에 대해 반복되지만, 찾을 수 없습니다.
BaseRCG2에서는 AppRC2(우선 순위 1200)를 APPLICATION 규칙으로 식별합니다.
ChildRCG1에서 ChAppRC1(우선 순위 900)이 APPLICATION 규칙으로 찾을 수 있습니다.
마지막으로 ChildRCG2에서는 APPLICATION 규칙으로 ChAppRC2(우선 순위 2000)를 찾습니다.

요약하면 규칙 처리 시퀀스는 다음과 같습니다. DNATRC1, DNATRC3, ChDNATRC3, NetworkRC1, NetworkRC2, ChNetRC1, ChNetRC2, AppRC2, ChAppRC1, ChAppRC2.

이 프로세스에는 우선 순위에 따라 규칙 컬렉션 그룹을 분석하고, 각 그룹 내에서 각 규칙 유형(DNAT, NETWORK, APPLICATION)에 대한 우선 순위에 따라 규칙을 정렬하는 작업이 포함됩니다.

먼저 모든 규칙 컬렉션 그룹에서 모든 DNAT 규칙을 처리하고, 규칙 컬렉션 그룹을 우선 순위 순서대로 분석하고, 각 규칙 컬렉션 그룹 내의 DNAT 규칙을 우선 순위 순서대로 정렬합니다. 그런 다음 NETWORK 규칙에 대해서도 동일한 프로세스를 거치고, 마지막으로 APPLICATION 규칙에 대해서도 동일한 프로세스를 진행합니다.

방화벽 정책 규칙 집합에 대한 자세한 내용은 Azure Firewall 정책 규칙 집합을 참조하세요.

위협 인텔리전스

위협 인텔리전스 기반 필터링을 사용하는 경우 해당 규칙의 우선 순위가 가장 높고 항상 먼저(네트워크 및 애플리케이션 규칙보다 먼저) 처리됩니다. 위협 인텔리전스 필터링은 구성된 규칙이 처리되기 전에 트래픽을 거부할 수 있습니다. 자세한 내용은 Azure Firewall 위협 인텔리전스 기반 필터링을 참조하세요.

IDPS

IDPS가 경고 모드에서 구성된 경우 IDPS 엔진은 규칙 처리 논리와 병렬로 작동하고 인바운드 및 아웃바운드 흐름의 서명 일치에 대한 경고를 생성합니다. IDPS 서명 일치의 경우 경고가 방화벽 로그에 기록됩니다. 그러나 IDPS 엔진이 규칙 처리 엔진과 병렬로 작동하므로 애플리케이션/네트워크 규칙에서 거부 또는 허용된 트래픽은 여전히 다른 로그 항목을 생성할 수 있습니다.

IDPS가 경고 및 거부 모드로 구성된 경우 IDPS 엔진은 인라인 상태이며 규칙 처리 엔진 이후에 활성화됩니다. 따라서 두 엔진 모두 경고를 생성하고 일치하는 흐름을 차단할 수 있습니다. 

IDPS에서 수행하는 세션 삭제는 흐름을 자동으로 차단합니다. 따라서 TCP 수준에서 RST가 전송되지 않습니다. IDPS는 네트워크/애플리케이션 규칙이 일치(허용/거부)하고 로그에 표시된 후 항상 트래픽을 검사하기 때문에, IDPS가 서명 일치 때문에 세션을 거부하도록 결정하는 다른 삭제 메시지가 기록될 수 있습니다.

TLS 검사를 사용하면 암호화되지 않은 트래픽과 암호화된 트래픽이 모두 검사됩니다. 

아웃바운드 연결

네트워크 규칙 및 애플리케이션 규칙

네트워크 규칙과 애플리케이션 규칙을 구성하는 경우 애플리케이션 규칙 적용 전에 네트워크 규칙이 우선 순위에 따라 적용됩니다. 규칙은 종료됩니다. 따라서 네트워크 규칙에 일치하는 항목이 있으면 다른 규칙이 처리되지 않습니다. 구성할 경우 모든 트래버스된 트래픽과 서명 일치에 대해 IDPS가 수행되며, IDPS는 의심스러운 트래픽을 경고하거나 차단할 수 있습니다.

그런 다음, 네트워크 규칙 일치가 없고 프로토콜이 HTTP, HTTPS 또는 MSSQL인 경우 애플리케이션 규칙은 우선 순위에 따라 패킷을 평가합니다.

HTTP의 경우 Azure Firewall은 호스트 헤더에 따라 애플리케이션 규칙 일치 항목을 찾습니다. HTTPS의 경우 Azure Firewall은 오직 SNI에 따라 애플리케이션 규칙 일치 항목을 찾습니다.

HTTP 및 TLS에서 검사한 HTTPS 사례 모두에서, 방화벽은 패킷 대상 IP 주소를 무시하고 호스트 헤더의 DNS 확인 IP 주소를 사용합니다. 방화벽은 호스트 헤더에서 포트 번호를 가져올 것으로 예상합니다. 그렇지 않은 경우 표준 포트 80을 가정합니다. 실제 TCP 포트와 호스트 헤더의 포트가 일치하지 않으면 트래픽이 드롭됩니다. DNS 확인은 Azure DNS 또는 방화벽에서 구성한 사용자 지정 DNS를 통해 수행됩니다. 

참고 항목

HTTP 및 HTTPS 프로토콜(TLS 검사 포함)은 항상 원래 원본 IP 주소와 동일한 XFF(X-Forwarded-For) 헤더를 사용하여 Azure Firewall로 채워집니다. 

애플리케이션 규칙에 TLS 검사가 포함되어 있으면 방화벽 규칙 엔진은 SNI, 호스트 헤더 그리고 규칙과 일치하도록 URL까지 처리합니다.

여전히 애플리케이션 규칙 내에서 일치 항목을 찾을 수 없으면 인프라 규칙 컬렉션과 비교하여 패킷이 평가됩니다. 여전히 일치하는 항목이 없으면 패킷이 기본값으로 거부됩니다.

참고 항목

네트워크 규칙은 TCP, UDP, ICMP 또는 모든 IP 프로토콜에 대해 구성할 수 있습니다. Any IP 프로토콜에는 IANA(Internet Assigned Numbers Authority) 프로토콜 번호 문서에 정의된 모든 IP 프로토콜이 포함됩니다. 대상 포트가 명시적으로 구성된 경우에는 규칙이 TCP+UDP 규칙으로 변환됩니다. 2020년 11월 9일 이전에 모두는 TCP, UDP 또는 ICMP를 의미했습니다. 따라서 이 날짜 전에는 Protocol = Anydestination ports = '*'를 사용하여 규칙을 구성했을 것입니다. IP 프로토콜을 현재 정의된 대로 허용할 생각이 아니라면 규칙을 수정하여 원하는 프로토콜(TCP, UDP 또는 ICMP)을 명시적으로 구성합니다.

인바운드 연결

DNAT 규칙 및 네트워크 규칙

Azure Portal을 사용하여 인바운드 인터넷 또는 인트라넷 트래픽 필터링에 설명된 대로 인바운드 인터넷 또는 인트라넷 트래픽을 구성하여 인바운드 인터넷 또는 인트라넷(미리 보기) 연결을 사용하도록 설정할 수 있습니다. NAT 규칙은 네트워크 규칙보다 우선 적용됩니다. 일치하는 항목이 발견되면 트래픽은 DNAT 규칙에 따라 변환되고 방화벽에서 허용됩니다. 따라서 트래픽은 다른 네트워크 규칙에 의해 더 이상 처리되지 않습니다. 보안상의 이유로, 네트워크에 대한 DNAT 액세스를 허용하고 와일드카드를 사용하지 않도록 하기 위해 특정 인터넷 원본을 추가하는 것이 좋습니다.

인바운드 연결에는 애플리케이션 규칙이 적용되지 않습니다. 따라서 인바운드 HTTP/S 트래픽을 필터링하려면 WAF(Web Application Firewall)를 사용해야 합니다. 자세한 내용은 Azure Web Application Firewall이란?을 참조하세요.

예제

다음 예제에서는 이러한 규칙 결합의 결과를 보여줍니다.

예 1

일치하는 네트워크 규칙이 있으므로 google.com 연결이 허용됩니다.

네트워크 규칙

  • 작업: 허용
name 프로토콜 소스 형식 원본 대상 형식 대상 주소 대상 포트
허용-웹 TCP IP 주소 * IP 주소 * 80,443

애플리케이션 규칙

  • 작업: Deny
name 소스 형식 원본 프로토콜:포트 대상 FQDN
Deny-google IP 주소 * http:80, https:443 google.com

결과

패킷이 Allow-web 네트워크 규칙과 일치하므로 google.com 연결이 허용됩니다. 이 시점에서 규칙 처리가 중지됩니다.

예제 2

우선 순위가 더 높은 Deny 네트워크 규칙 컬렉션이 트래픽을 차단하므로 SSH 트래픽이 거부됩니다.

네트워크 규칙 컬렉션 1

  • 이름: 허용-컬렉션
  • 우선 순위: 200
  • 작업: 허용
name 프로토콜 소스 형식 원본 대상 형식 대상 주소 대상 포트
허용-SSH TCP IP 주소 * IP 주소 * 22

네트워크 규칙 컬렉션 2

  • 이름: 거부-컬렉션
  • 우선 순위: 100
  • 작업: Deny
name 프로토콜 소스 형식 원본 대상 형식 대상 주소 대상 포트
거부-SSH TCP IP 주소 * IP 주소 * 22

결과

우선 순위가 더 높은 네트워크 규칙 컬렉션이 연결을 차단하므로 SSH 연결이 거부됩니다. 이 시점에서 규칙 처리가 중지됩니다.

규칙 변경

이전에 허용된 트래픽을 거부하도록 규칙을 변경하면 관련된 모든 기존 세션이 삭제됩니다.

3방향 핸드셰이크 동작

상태 저장 서비스인 Azure Firewall은 시작점에서 대상까지 허용된 트래픽에 대해 TCP 3방향 핸드셰이크를 완료합니다. 예를 들어 VNet-A에서 VNet-B로의 경로에 대해 그렇습니다.

VNet-A에서 VNet-B로의 허용 규칙을 만든다고 해서 VNet-B에서 VNet-A로의 새로 시작된 연결이 허용되는 것은 아닙니다.

따라서 VNet-B에서 VNet-A로의 명시적 거부 규칙을 만들 필요가 없습니다.

다음 단계