반응형
- Microsoft Azure에서 제공하는 방화벽 서비스인 Azure Firewall에 대한 설명
- On-premise(이하 온프레미스)에서 사용하는 방화벽과 거의 동일한 기능을 제공함
- Azure에서 제공하는 방화벽인 만큼 Full-Managed 서비스로서 SaaS(Software as a Service)에 해당하므로 방화벽 자체에 대해 관리할 필요가 없음
- 네트워크 서비스인 Virtual Hub(이하 VHub) / Virtual Network(이하 VNet)에서 활용 가능하며 네트워크 서비스 내부에 위치하는 만큼 공인 IP와 사설 IP를 보유하고 이를 네트워크 통신에 활용함
- IDPS와 TLS Inspection 기능을 사용할 수 있음(Premium SKU 사용 시)
- Azure의 IP Grouping 서비스인 "IP 그룹"을 활용하여 정책 요소로 활용할 수 있음
Azure Firewall의 구성과 구조
- Azure Firewall은 Azure Firewall(이하 방화벽)과 Firewall Policy(이하 방화벽 정책)으로 나뉨
- 각각 리소스로서 존재하기 때문에 방화벽과 함께 방화벽 정책을 함께 생성하고 연결해야 활용 가능
- 방화벽은 VHub / VNet에 1개만 생성 가능함
- 1개의 방화벽은 1개의 방화벽 정책을 연결할 수 있음
- 방화벽 정책은 또 다른 방화벽 정책을 상위 정책으로 두어 상위 정책이 우선 적용되도록 설정할 수 있음, 이를 부모 정책이라 부름
- 방화벽은 최소 1개 이상의 Public IP(이하 공인 IP)를 가질 수 있으며 이를 SNAT와 DNAT에 활용할 수 있음
- 방화벽 정책의 구성은 다음과 같음
- Rule < RuleCollection < RuleCollectionGroup 3가지 요소로 구성되며 우측으로 갈수록 상위 개념에 해당함
- Rule(이하 규칙)이란 출발지, 목적지, 프로토콜, 포트로 구성된 1개의 정책을 의미하며 여기서 각 요소들은 여러 개로 구성될 수 있음, 예를 들어 출발지 IP를 10.0.0.1 - 10.0.0.27, 10.1.1.0/24 등으로 한 번에 넣을 수 있음
- RuleCollection은 Rule의 집합으로서 다수의 Rule로 구성되는 존재로 Rule들의 유형을 정의할 수 있는 리소스
- Rule Collection의 유형은 DNAT / Network / Application Rule로 나뉘며 유형별로 사용방법이 다름
- Rule Collection은 RuleCollectionGroup에 소속되며 RuleCollectionGroup 내에서 우선순위를 가짐
- 우선순위가 높을수록 우선적으로 적용되며 우선순위의 값은 100 ~ 65000로 값이 작을수록 우선순위가 높음
- RuleCollectionGroup은 RuleCollection의 집합으로 RuleCollection처럼 우선순위를 갖게 됨
- 우선순위의 값은 100 ~ 65000로 값이 작을수록 우선순위가 높음
- RuleCollection 개수의 제한은 없으나 Rule의 제한은 존재함
- 고유한(각기 다른) 출발지/목적지 IP의 Network Rule이 2만 개를 넘어갈 경우, 성능 저하가 발생할 수 있음
(https://learn.microsoft.com/ko-kr/azure/firewall/firewall-best-practices)
- 고유한(각기 다른) 출발지/목적지 IP의 Network Rule이 2만 개를 넘어갈 경우, 성능 저하가 발생할 수 있음
Azure Firewall의 RuleCollection의 종류
- 앞서 말한 것처럼 RuleCollection의 유형은 3가지로 DNAT / Network / Application Rule로 나뉨
- 여담으로 위 화면의 붉은색 박스는 유형별 RuleCollection을 모아둔 것으로 이름만 보면 Rule로 보일 수 있으나 RuleCollection이 나타남
- 첫 번째 유형, DNAT Rule (Collection)
- DNAT Rule은 이름 그대로 Destination NAT Rule로서 목적지 IP를 공인 IP에서 사설 IP로 변환해 주는 Rule
- Cloud Network(이하 클라우드 네트워크)에서 DNAT가 적용되는 경우는 오직 하나임
- Azure VNet에 공인 IP를 보유하지 않은 리소스로의 접근이 필요할 때 사설 네트워크 환경인 VNet에서 사설 IP를 목적지로 접근할 수 있도록 변환시켜 주는 것임
- 이는 온프레미스에서의 동일하게 사용되는 방법임
- 여기서 Azure Firewall은 자신이 보유한 공인 IP를 VNet 혹은 VHub 내부의 리소스의 사설 IP로 변환시켜 통신이 가능케 함(아래 그림 참조)
- 아래 그림에서는 방화벽이 보유한 공인 IP 4.230.42.3을 VNet 내부의 리소스의 사설 IP인 10.0.0.4 / Port 8080으로 변환시켜 주는 것을 볼 수 있음
- DNAT Rule을 활용해 VNet / VHub 내부에 사설 IP만 보유한 Load Balancer 혹은 VM 등에 접근하는 것이 가능
- 두 번째 유형, Network Rule (Collection)
- Network Rule은 온프레미스 방화벽의 기본적 동작과 매우 유사하며 5-Tuple(Source / Destination IP, Source / Destination Port, Protocol) 중 Source / Destination IP, Destionation Port, Protocol을 활용해 트래픽을 제어함
- 다만 외부 인터넷의 내부 네트워크 유입은 DNAT Rule이 담당하기 때문에 Network Rule로는 DNAT 역할을 수행할 수 없음
- IP뿐만 아니라 FQDN(Full Qualified Domain Name) 또한 목적지로 설정할 수 있지만 Asterisk(*)을 활용한 서브도메인 허용은 불가능함으로 주의해야 함
- Service Tag라 불리는 기능을 사용할 수 있음
- Service Tag는 Microsoft Azure의 서비스에 접근하기 위한 IP들을 모아둔 집합
- Azure의 서비스를 향하는 트래픽의 아웃바운드 통신 허용을 위해 IP를 일일이 허용하는 것이 아닌 Service Tag 활성화 하나로 간편하게 필요한 IP를 허용해 줄 수 있음
- 관리 또한 Azure에서 하므로 편리함
- Network Rule은 온프레미스 방화벽의 기본적 동작과 매우 유사하며 5-Tuple(Source / Destination IP, Source / Destination Port, Protocol) 중 Source / Destination IP, Destionation Port, Protocol을 활용해 트래픽을 제어함
- 세 번째 유형, Application Rule (Collection)
- Applicatoin Rule은 FQDN 혹은 URL로 이루어진 목적지로의 아웃바운드 통신을 허용하기 위한 Rule
- FQDN를 목적지로 설정할 수 있다는 점에서 Network Rule과 동일하나 허용 방식이 다름
- Network Rule은 FQDN에 대해 DNS 서버로의 질의를 통해 IP의 형태로 허용 여부를 판단하지만 Application Rule은 HTTP Request Header 내 Host Header에 기록된 FQDN / URL을 읽어 일치 여부를 통해 허용 여부를 결정함
- HTTP Request Header를 통해 판단해야 하는 만큼 Application Rule은 허용 여부와 관계없이 3-way handshake(SYN, SYN/ACK, ACK)를 통과시키게 되며 HTTP Request Header를 읽은 후에야 일치하는 Rule이 있는지 확인할 수 있음
- Rule이 없을 경우, 470 Response Code를 반환함
- 3-way handshake를 통과시키는 과정에서 사용자로 하여금 통신을 허용하는 Rule이 있는 것처럼 착각을 불러일으킬 수 있음
- HTTPS 사용 및 URL 목적지 설정 시, TLS Inpsection(이하 TLS 검사)을 사용해야 SNI(Server Name Indication)를 확인할 수 있으므로 주의
- FQDN Tag를 사용할 수 있음
Azure Firewall의 특징
- Azure Firewall은 내부적으로 Azure Load Balancer와 VMSS(Virtual Machine Scale Sets)로 구성됨
- Scale In/Out이 필요할 경우, 자체적으로 확장/축소하며 성능을 유지함
- TCP / UDP를 허용하는 Load Balancer를 사용하는 만큼 아래 조건에서 ICMP 처리가 불가능하다는 특징을 지님
- SNAT / DNAT(Public IP 활용)을 허용하는 Rule 사용 시 ICMP를 허용해도 작동하지 않음
- 기본적으로 Azure Public DNS를 사용하며 사용자 정의 DNS 서버 지정 가능
- FQDN Tag 사용 시 반드시 DNS Proxy 기능을 활성화시켜야 함
- 개인 IP 범위를 지정하여 Public IP / Private IP를 구분, 라우팅을 제어할 수 있음
- 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 등 RFC 상 명시된 사설 IP 대역에 대해 외부 인터넷으로 트래픽을 내보내지 않고 내부에서 처리하도록 기본 설정됨
- 이외의 대역에 대해 외부 인터넷으로 보내지 않고 내부에서 처리하도록 설정할 수 있음
- Azure Firewall의 성능은 SKU에 따라 달라지며 Premium 사용 시 최대 100 Gpbs(TCP/UDP, HTTPS)까지 처리량이 늘어나지만 TLS Inspection / IDPS 동시 사용 시 10 Gbps로 제한되므로 주의가 필요함
- 최대로 보유할 수 있는 공인 IP의 개수는 250개이며 이를 SNAT / DNAT에 모두 활용할 수 있음
- SNAT 활용 정책 사용 시, 공인 IP 1개당 최대 2492개의 SNAT Port를 제공할 수 있음
- Azure NAT Gateway가 공인 IP 1개당 64,512개의 SNAT Port를 제공하는 것과 비교해 보면 적은 숫자에 해당
- SNAT에 활용되는 공인 IP는 방화벽이 보유한 공인 IP 중 랜덤으로 선택되어 SNAT를 실시함
'Network Know-how 기록하기' 카테고리의 다른 글
[Secui Bluemax]방화벽 Session TCP Flag 설명 (0) | 2024.11.15 |
---|---|
[AWS / Palo Alto]Palo Alto Firewall(EC2) 설치 및 GWLB 연동 (0) | 2024.05.26 |
[AWS]Gateway Load Balancer #4(Idle Timeout & Failover) (4) | 2024.02.04 |
[AWS]Gateway Load Balancer #3(GENEVE Protocol) (0) | 2023.12.04 |
[AWS]Gateway Load Balancer #2(라우팅) (2) | 2023.08.06 |
댓글