[Network] 22. 방화벽은 편지의 무엇을 보고 문을 열어줄까?

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 7. 인터넷의 주소를 함께 쓰고 경계를 지키는 법

ㅁ 들어가며

Network 경계에 경비실을 세웠다고 하자.

경비원에게 “좋은 편지는 통과시키고 나쁜 편지는 막아 달라”고 말하면 Policy가 완성될까?

Packet에는 발신자의 의도가 적혀 있지 않다.

방화벽이 직접 관찰할 수 있는 것은 다음과 같은 정보다.

어느 Interface와 Zone에서 들어왔는가?
Source와 Destination IP는 무엇인가?
TCP, UDP, ICMP 중 어떤 Protocol인가?
Source와 Destination Port는 무엇인가?
TCP Flag와 연결 상태는 무엇인가?
기존에 허용한 대화의 응답인가?

 

방화벽은 이 증거를 미리 정의한 Rule과 비교해 ALLOW, DROP, REJECT 같은 결정을 내린다.

따라서 방화벽의 핵심은 “많이 막기”가 아니다.

누가
어디에서 어디로
어떤 Protocol과 Service를
어느 방향으로
왜 사용해야 하는가?

 

이 질문에 답할 수 있을 만큼 필요한 흐름을 정확히 정의하는 것이 핵심이다.

 

이번 글에서는 5-Tuple, Stateless ACL, Stateful Firewall, Connection Tracking, NEW, ESTABLISHED, RELATED, INVALID, Default Deny, Least Privilege를 하나의 TCP 연결로 추적한다.

---

ㅁ 방화벽은 Packet의 어느 층까지 볼까?

모든 방화벽이 같은 정보를 보는 것은 아니다.

단순한 Packet Filter는 주로 Network Layer와 Transport Layer Header를 본다.

Layer 3
├─ Source IP
├─ Destination IP
└─ IP Protocol

Layer 4
├─ Source Port
├─ Destination Port
└─ TCP Flag 등

장비가 배치된 위치에 따라 Incoming Interface, Outgoing Interface, VLAN과 Security Zone도 판단 기준이 된다.

더 높은 계층을 이해하는 Proxy, Web Application Firewall, IDS/IPS는 HTTP Method, URL, Protocol 문법 같은

Application 정보까지 분석할 수 있다.

Network Firewall
→ 주소, Protocol, Port, State 중심

Application-Aware Firewall / Proxy / WAF
→ Application Protocol과 요청 의미까지 추가 분석 가능

“방화벽”이라는 이름만으로 어떤 Field를 어디까지 해석하는지 단정할 수 없다.

제품의 처리 계층, 암호화 상태와 배치 방식을 확인해야 한다.

---

ㅁ 5-Tuple은 어떤 대화를 가리킬까?

Client가 Web Server에 연결한다고 하자.

Client 10.22.1.2:53000
Server 198.51.100.2:443
Protocol TCP

 

Flow를 구분하는 5-Tuple은 다음과 같다.

Source IP        10.22.1.2
Source Port      53000
Destination IP   198.51.100.2
Destination Port 443
Protocol         TCP

 

Return Packet에서는 Source와 Destination이 뒤집힌다.

Source IP        198.51.100.2
Source Port      443
Destination IP   10.22.1.2
Destination Port 53000
Protocol         TCP

 

두 Packet은 방향별 5-Tuple이 다르지만 하나의 양방향 대화다.

Stateful Firewall은 Original Direction과 Reply Direction을 하나의 Connection Tracking Entry로 연결한다.

---

ㅁ Stateless ACL은 어떻게 판단할까?

Stateless Access Control List(ACL)은 각 Packet을 독립적으로 Rule과 비교한다.

현재 Packet의 Header
        ↓
Rule 목록과 비교
        ↓
Permit 또는 Deny

 

이전에 Client의 SYN을 허용했다는 사실을 다음 SYN-ACK 판단에 자동으로 기억하지 않는다.

 

Client에서 Server의 HTTPS로 나가는 Rule을 생각해 보자.

Permit TCP
Source      10.22.1.0/24
Destination 198.51.100.2
Destination Port 443

이 Rule은 Client의 요청 방향에 맞는다.

 

그러나 Server의 응답은 다음과 같다.

TCP 198.51.100.2:443
→   10.22.1.2:53000

 

응답을 받으려면 반대 방향 Rule도 필요하다.

Permit TCP
Source      198.51.100.2
Source Port 443
Destination 10.22.1.0/24
Destination Port Ephemeral Range

Client의 Ephemeral Port가 연결마다 달라지므로 Stateless Rule은 Return 범위를 넓게 열거나

TCP Flag 같은 추가 조건을 사용할 수 있다.

각 방향을 명시적으로 설계한다는 장점이 있지만,

복잡한 동적 연결에서 Rule 범위가 커지고 요청과 응답의 관계를 정확히 표현하기 어려울 수 있다.

---

ㅁ ACK Flag만 있으면 정상 응답이라고 믿어도 될까?

과거의 단순한 Stateless Rule은 TCP ACK가 설정된 Packet을 “이미 만들어진 연결의 응답”처럼 허용하기도 했다.

TCP ACK=1
→ Established Traffic으로 간주

하지만 Packet Header의 ACK Bit는 누구나 만들어 보낼 수 있다.

방화벽이 실제 3-Way Handshake를 관찰하지 않았다면

해당 ACK가 정상 연결에 속하는지 ACK Flag 하나만으로 확정할 수 없다.

ACK Flag 존재
≠ 방화벽이 확인한 기존 Connection 존재

TCP Flag 검사는 유용한 조건이지만 Connection Tracking State를 그대로 대신하지는 못한다.

---

ㅁ Stateful Firewall은 무엇을 기억할까?

Stateful Firewall은 허용된 새 Flow의 Packet을 관찰하고 Connection Tracking State를 만든다.

Client의 SYN이 통과했다고 하자.

Original Direction
TCP 10.22.1.2:53000 → 198.51.100.2:443

Expected Reply Direction
TCP 198.51.100.2:443 → 10.22.1.2:53000

설명용 State Table은 다음처럼 보일 수 있다.

Protocol	Original Tuple	Reply Tuple	State
TCP	10.22.1.2:53000 → 198.51.100.2:443	198.51.100.2:443 → 10.22.1.2:53000	SYN 관찰

 

Server의 SYN-ACK이 돌아오면 Firewall은 5-Tuple을 뒤집어 기존 Entry의 Reply Direction과 맞는지 확인한다.

기존 요청의 정상 Reply로 확인
→ 별도의 넓은 Inbound Ephemeral Port Rule 없이 허용 가능

마지막 ACK와 Data, FIN/RST를 관찰하면서 State와 Timeout을 갱신할 수 있다.

---

ㅁ Conntrack의 NEW와 TCP의 SYN-SENT는 같은 상태일까?

Linux Netfilter 같은 환경에서는 Packet을 다음 Conntrack State로 분류할 수 있다.

NEW
ESTABLISHED
RELATED
INVALID

 

이 이름을 TCP State Machine의 SYN-SENT, ESTABLISHED, TIME-WAIT와 그대로 같은 것으로 이해하면 안 된다.

TCP State
→ Endpoint TCP Stack의 연결 상태

Conntrack State
→ 중간 장비가 관찰한 Packet 관계 상태

Firewall이 모든 Packet을 보지 못했거나 Timeout과 구현 방식이 다르면 두 상태가 일치하지 않을 수 있다.

---

ㅁ NEW는 반드시 첫 SYN만 뜻할까?

NEW는 기존 Conntrack Entry에 속하지 않으면서 새 Flow를 만들 수 있는 Packet을 뜻한다.

정상적인 TCP 연결의 시작에서는 보통 다음 SYN이다.

SYN=1, ACK=0
Conntrack State=NEW

하지만 구현과 Tracking 설정에 따라 SYN이 아닌 TCP Packet이 NEW로 분류될 수도 있다.

따라서 Internet에서 내부 Server로 들어오는 새 TCP 연결을 허용할 때 다음처럼 의도를 더 구체적으로 표현할 수 있다.

Protocol TCP
Destination Server와 Port 일치
Conntrack State NEW
TCP SYN 조건

NEW라는 이름만 보고 “정상적인 Handshake가 이미 검증됐다”고 생각하면 안 된다.

---

ㅁ ESTABLISHED는 Application 인증까지 끝났다는 뜻일까?

Conntrack의 ESTABLISHED는 일반적으로 양방향 Packet이 관찰되어 기존 Flow의 일부로 인식된다는 뜻이다.

Client SYN 통과
Server SYN-ACK 관찰
→ Reply Direction 확인
→ ESTABLISHED로 분류 가능

 

이는 다음 사실을 보장하지 않는다.

TLS 인증서 검증 완료
사용자 Login 성공
Application 요청이 안전함
Database 작업 성공

Firewall의 ESTABLISHED와 Endpoint TCP의 ESTABLISHED, Application Session의 인증 완료는 서로 다른 계층의 상태다.

Stateful Rule의 ESTABLISHED는 “이 Packet이 이미 추적 중인 양방향 Flow에 속한다”는 의미로 읽어야 한다.

---

ㅁ RELATED는 어떤 Packet을 가리킬까?

RELATED는 새 Flow 또는 Control Packet이 기존 Conntrack Entry와 관련된 것으로 식별된 상태다.

대표적인 예는 기존 Flow의 Packet을 인용한 ICMP 오류다.

기존 TCP Packet
→ Router에서 MTU 초과
→ ICMP Fragmentation Needed
→ 원래 Flow와 RELATED

Stateful Firewall은 ICMP 안에 인용된 원래 Header를 보고 기존 Flow와 연결해 필요한 오류를 허용할 수 있다.

일부 Protocol Helper는 Control Connection 안에서 협상된 별도 Data Connection을 RELATED로 연결할 수도 있다.

그러나 Helper가 Payload를 해석하고 동적으로 Pin Hole을 여는 기능은 공격 표면도 늘릴 수 있다.

필요한 Protocol에만 제한하고 암호화된 Payload에서는 해석할 수 없다는 점도 고려해야 한다.

---

ㅁ INVALID는 무조건 공격 Packet일까?

INVALID는 정상적으로 추적할 수 없거나 기대한 Connection State와 맞지 않는 Packet을 뜻할 수 있다.

가능한 원인은 다양하다.

• 기존 Conntrack Entry가 Timeout으로 사라진 뒤 늦게 온 Packet
• 비정상적인 TCP Flag 또는 Sequence 관계
• Fragment Reassembly나 Tracking에 필요한 정보 부족
• Asymmetric Path 때문에 Firewall이 한 방향만 관찰
• 손상되거나 해석할 수 없는 Packet

INVALID를 Drop하는 Policy는 흔하지만 INVALID라는 결과만으로 외부 공격이라고 단정하면 안 된다.

정상 Traffic이 INVALID로 분류되면 Path Symmetry, State Timeout, Fragment와 장비 Capacity를 함께 조사해야 한다.

---

ㅁ UDP에는 연결 상태가 없는데 Stateful Firewall은 어떻게 할까?

UDP Protocol에는 TCP Handshake와 FIN이 없다.

그래도 Stateful Firewall은 UDP Tuple과 시간을 바탕으로 임시 State를 만들 수 있다.

Client 10.22.1.2:54000
→ DNS Server 198.51.100.53:53

State 생성
Expected Reply
198.51.100.53:53
→ 10.22.1.2:54000

반대 방향 Packet이 일정 시간 안에 오면 기존 UDP Flow의 Reply로 허용할 수 있다.

Traffic이 없으면 UDP State는 Idle Timeout 후 사라진다.

UDP Conntrack State
≠ UDP Protocol이 TCP처럼 연결을 맺음

중간 장비가 편의를 위해 만든 Pseudo-State다.

Application의 응답이 NAT·Firewall Timeout보다 늦으면 정상 Reply도 새롭거나 Invalid한 Traffic처럼 처리될 수 있다.

---

ㅁ ICMP는 Port가 없는데 무엇으로 판단할까?

ICMP에는 TCP·UDP Port가 없다.

방화벽은 ICMP Type, Code, Source와 Destination, 인용된 원래 Packet과 Conntrack 관계를 사용할 수 있다.

Echo Request / Reply
Destination Unreachable
Time Exceeded
Fragmentation Needed

모든 ICMP를 하나의 Protocol 번호만 보고 허용하거나 차단하면 필요한 제어 기능까지 함께 영향을 받는다.

예를 들어 PMTUD에 필요한 Fragmentation Needed를 차단하면 MTU Black Hole이 생길 수 있다.

ICMP Type과 Code, 방향과 관련 State를 기준으로 필요한 메시지를 구분해야 한다.

---

ㅁ Rule은 어떤 순서로 읽힐까?

많은 ACL과 Firewall Rule Set은 위에서 아래로 평가해 처음 일치한 Action을 적용한다.

1. Allow TCP from Any to Server Port 443
2. Deny TCP from 203.0.113.0/24 to Server Port 443

첫 Rule이 먼저 일치하면 두 번째의 구체적인 Deny는 도달하지 못한다.

이를 Rule Shadowing이라고 한다.

더 구체적인 Rule과 예외를 앞에 두고 넓은 Rule을 뒤에 두는 방식이 흔한 이유다.

1. Deny 예외 Source
2. Allow 승인된 Source 범위
3. Default Deny

다만 모든 플랫폼이 단순한 First Match 방식인 것은 아니다. Cloud Security Group처럼 여러 Allow Rule을 합산하거나 별도의 우선순위를 사용하는 제품도 있다.

사용 중인 Policy Engine의 평가 순서와 기본 Action을 확인해야 한다.

---

ㅁ Default Deny는 왜 마지막에 필요할까?

필요한 Traffic을 하나씩 정의한 뒤 나머지를 허용하면 Policy의 빈틈을 예측하기 어렵다.

Default Deny는 명시적으로 허용하지 않은 Traffic을 기본적으로 차단하는 원칙이다.

Allow: 내부 Client → 승인된 DNS Resolver TCP/UDP 53
Allow: 내부 Client → Web Proxy TCP 443
Allow: 기존 Flow의 ESTABLISHED, RELATED Reply
Deny : 그 밖의 Traffic

새 Service가 생기면 자동으로 열리는 것이 아니라 필요성과 범위를 검토한 뒤 Allow Rule을 추가한다.

Default Deny가 곧 좋은 Policy를 보장하는 것은 아니다. Allow Any Any가 앞에 있으면 마지막 Deny는 의미가 없다.

기본 Action과 실제 Allow 범위를 함께 봐야 한다.

---

ㅁ 최소 권한은 Port 하나만 좁히는 것일까?

Principle of Least Privilege는 업무에 필요한 최소 범위만 허용하는 원칙이다.

다음 차원을 함께 좁힌다.

Source
Destination
Protocol
Destination Port
Direction
Interface 또는 Zone
Connection State
필요한 시간과 운영 주체

예를 들어 “Database Port 5432 허용”만으로는 부족하다.

Source      Application Subnet
Destination Database Server
Protocol    TCP
Port        5432
Direction   App → DB
State       NEW 허용, Return ESTABLISHED

필요한 Flow를 문장으로 설명할 수 있어야 Rule의 목적과 삭제 조건도 관리할 수 있다.

---

ㅁ Port 443이면 항상 HTTPS일까?

Port Number는 Application을 배치하는 관례이자 Socket 식별 정보다.

어떤 Application도 TCP 443에서 Listen할 수 있다.

Destination Port 443
≠ Payload가 반드시 정상 HTTPS
≠ 상대가 반드시 신뢰할 수 있는 Web Server

Layer 4 Firewall이 Port 443을 허용한다는 것은 해당 TCP Endpoint로 연결할 수 있게 한다는 뜻이다.

HTTP 문법, URL, 사용자 권한과 악성 Payload까지 검증하려면 Application 계층의 추가 통제가 필요하다.

Port 기반 Rule은 중요한 경계이지만 Application Identity의 완전한 증명은 아니다.

---

ㅁ Source IP를 알면 사용자를 믿을 수 있을까?

Source IP는 Routing과 Policy의 중요한 단서다.

하지만 사용자 Identity와 같지는 않다.

• NAT 뒤에서는 여러 사용자가 하나의 Public IP를 공유할 수 있다.
• DHCP와 이동 환경에서는 한 사용자의 IP가 바뀔 수 있다.
• 내부 Network에서도 Source Address Spoofing 가능성을 고려해야 한다.
• Proxy와 Load Balancer가 있으면 Server가 직접 보는 Source가 중간 장비일 수 있다.

Source IP Allowlist는 범위를 줄일 수 있지만 강한 사용자 인증을 대신하지 않는다.

서비스 계정, 인증서, Token, Application Authorization 같은 상위 계층 통제가 별도로 필요하다.

---

ㅁ DROP과 REJECT는 어떻게 다르게 보일까?

Policy에 맞지 않는 Packet을 조용히 버리면 DROP이다.

Client → Firewall : SYN
Firewall          : DROP
Client            : 응답을 기다리고 재전송
최종 결과         : Timeout 가능

거절 사실을 응답으로 알리면 REJECT다.

TCP 연결에는 RST를, 다른 Traffic에는 적절한 ICMP 오류를 돌려보낼 수 있다.

Client → Firewall : SYN
Firewall → Client : TCP RST
최종 결과         : Connection Refused처럼 빠른 실패 가능

REJECT 응답도 Return Route가 없거나 중간에서 차단되면 Client에 도착하지 않는다.

DROP이 항상 더 안전하고 REJECT가 항상 위험하다는 단순한 규칙은 없다.

• 내부 운영 환경에서는 빠른 REJECT가 장애 진단과 재시도 제어에 도움이 될 수 있다.
• 외부 경계에서는 정보 노출, 응답 증폭, 운영 요구를 고려해 DROP을 선택할 수 있다.
• PMTUD 같은 필요한 ICMP 오류까지 조용히 버리면 정상 통신이 깨진다.

Policy 목적과 Protocol 동작을 함께 봐야 한다.

---

ㅁ Ingress와 Egress Policy는 왜 둘 다 필요할까?

네트워크에서 Ingress(인그레스)는 외부에서 시스템 내부로 들어오는 트래픽(인바운드)을 의미하며,

Egress(이그레스)는 내부에서 외부로 나가는 트래픽(아웃바운드)을 뜻한다.

 

Ingress Filtering은 경계로 들어오는 Traffic을 통제한다.

Egress Filtering은 내부에서 외부로 나가는 Traffic을 통제한다.

외부 공격만 생각하고 Egress를 모두 허용하면 다음 문제를 놓칠 수 있다.

• 침해된 Host가 외부 Command Server에 연결
• Data Exfiltration
• 허가되지 않은 외부 DNS나 SMTP 사용
• 내부 Source Address를 위조한 Packet의 유출

Ingress: 외부에서 무엇이 들어올 수 있는가?
Egress : 내부에서 무엇이 나갈 수 있는가?

둘 다 Default Deny로 시작할 수 있지만 운영에 필요한 Update, DNS, NTP, Monitoring과 제어 Protocol을 정확히 식별해야 한다.

---

ㅁ Host Firewall과 Network Firewall은 무엇이 다를까?

Network Firewall은 여러 Network나 Zone의 경계에서 Transit Traffic을 통제한다.

Host Firewall은 개별 Server나 Client의 Network Stack 가까이에서 해당 Host의 Traffic을 통제한다.

Internet
   │
Network Firewall
   │
Server Network
   │
Host Firewall
   │
Application

Network 경계를 통과한 뒤 같은 Subnet의 다른 Host에서 오는 Traffic은 경계 Firewall을 다시 지나지 않을 수 있다.

Host Firewall은 최종 Workload 단위의 Policy를 추가한다.

한쪽이 다른 쪽을 무조건 대체하는 것이 아니라 서로 다른 관찰 위치에서 방어 계층을 만든다.

---

ㅁ NAT와 Firewall Rule은 어느 주소를 볼까?

같은 장비가 NAT와 Firewall을 모두 수행하면 Packet이 어느 처리 단계에서 Rule과 만나는지가 중요하다.

DNAT 전 Destination: 203.0.113.5:8443
DNAT 후 Destination: 192.168.10.50:443

Firewall Rule이 NAT 전 Public Tuple을 기준으로 쓰이는지,

변환 후 Private Tuple을 기준으로 쓰이는지는 플랫폼과 Hook 위치에 따라 달라질 수 있다.

Policy에는 Public IP를 적었는데 실제 Rule은 DNAT 후 Address를 평가
→ 예상과 다른 Match

Packet Processing Order를 확인하지 않고

NAT와 Firewall Rule을 별개 화면으로만 보면 허용과 차단 원인을 잘못 해석할 수 있다.

Capture도 NAT 전후 Interface에서 함께 해야 한다.

---

ㅁ Return Path가 다른 Firewall로 가면 어떻게 될까?

Stateful Firewall A가 Client의 SYN을 보고 State를 만들었다.

Forward: Client → Firewall A → Server

 

Routing이 비대칭이라 SYN-ACK이 Firewall B로 돌아온다고 하자.

Return: Server → Firewall B → Client

 

Firewall B가 A의 State를 공유하지 않으면 Reply Packet을 기존 Connection과 연결하지 못할 수 있다.

Firewall A: State 있음, Reply는 오지 않음
Firewall B: State 없음, SYN-ACK 도착
→ INVALID 또는 허용되지 않은 NEW처럼 처리 가능

고가용성 Firewall Cluster는 State Synchronization을 제공할 수 있지만

모든 State와 전환 순간이 완벽히 동기화된다고 가정하면 안 된다.

 

Stateful Middlebox가 있는 경로에서는 Routing Symmetry와 State Ownership이 설계 조건이 된다.

---

ㅁ State Table도 가득 찰 수 있을까?

Stateful Firewall은 Flow마다 Memory와 Timer를 사용한다.

동시 Connection 증가
Half-Open TCP 증가
UDP Mapping 증가
긴 Timeout
Fragment State 증가
→ State Table 자원 소비

State Table이 가득 차면 기존 Flow는 동작하지만 새 Connection이 실패하거나 장비 처리 성능이 급격히 떨어질 수 있다.

SYN Flood처럼 마지막 ACK를 보내지 않는 요청은 Half-Open State를 쌓을 수 있다.

Capacity Planning에는 최대 동시 Connection 수뿐 아니라

초당 새 Connection 수, Timeout, 평균 Flow 수명과 Failover 동기화 비용도 포함해야 한다.

Stateful이 항상 Stateless보다 우월하다는 뜻은 아니다. 필요한 Policy 표현력과 State 비용을 함께 고려한다.

---

ㅁ Fragment는 Port Rule을 어떻게 어렵게 할까?

IPv4 Fragment의 첫 조각에는 TCP 또는 UDP Header가 있지만 뒤 Fragment에는 Transport Port가 없을 수 있다.

Fragment 1: IP Header + TCP Header + Data
Fragment 2: IP Header + Data
Fragment 3: IP Header + Data

Port 기반 Rule이 뒤 Fragment만 독립적으로 보면 어느 Service에 속하는지 알기 어렵다.

Stateful Firewall은 Fragment를 추적하거나 Reassembly한 뒤 검사할 수 있지만 Memory와 처리 비용이 필요하다.

비정상 Offset과 겹치는 Fragment는 보안 장비와 Endpoint의 해석 차이를 만들 수 있어 엄격하게 차단될 수 있다.

“첫 Fragment가 허용됐으니 모든 뒤 Fragment도 무조건 안전하다”는 단순한 결론을 피해야 한다.

---

ㅁ 암호화된 Packet에서 방화벽은 무엇을 볼까?

TLS로 Application Payload가 암호화되면 중간의 일반 Network Firewall은 HTTP 본문과 Password를 읽을 수 없다.

그래도 다음 Metadata는 관찰할 수 있다.

Source와 Destination IP
TCP/UDP Port
Packet 크기와 시간
Connection State
일부 암호화되지 않았거나 별도로 노출되는 Handshake Metadata

TLS Inspection Proxy가 연결을 중간에서 종료하고 다시 암호화하면 Application 내용을 검사할 수 있지만 인증서 신뢰, Privacy, 성능과 Key 관리라는 새로운 책임이 생긴다.

방화벽이 허용한 경로의 내용을 누가 읽을 수 있고 상대를 어떻게 믿을지는 다음 글의 TLS에서 이어진다.

---

ㅁ IPv4 Rule을 만들면 IPv6도 함께 보호될까?

플랫폼에 따라 IPv4와 IPv6 Rule Set, Address Object와 처리 도구가 분리될 수 있다.

IPv4 Inbound Default Deny 구성 완료
≠ IPv6 Inbound도 같은 Policy 적용 완료

Host와 Network에 IPv6 Address와 Route가 있는데 IPv6 Policy를 확인하지 않으면 의도하지 않은 별도 경로가 열릴 수 있다.

반대로 IPv4에서 사용한 “ICMP는 모두 차단” 같은 Rule을 그대로 복사하면 IPv6의 정상 동작을 깨뜨릴 수 있다.

IPv6는 다음과 같은 ICMPv6 기능에 의존한다.

• Neighbor Discovery의 Neighbor Solicitation과 Advertisement
• Router Solicitation과 Advertisement
• Path MTU Discovery의 Packet Too Big
• Time Exceeded와 Parameter Problem 같은 오류 보고

각 메시지가 필요한 위치와 방향은 다르다.

예를 들어 Neighbor Discovery는 같은 Link의 Neighbor를 찾는 Control Traffic이고

Router를 넘어 그대로 Forward하는 일반 Application Traffic이 아니다.

IPv6 Firewall도 Default Deny와 최소 권한을 적용하되,

Protocol이 정상 동작하는 데 필요한 ICMPv6 Type과 Scope를 구분해 허용해야 한다.

---

ㅁ Logging은 모든 진실을 남길까?

Firewall Log는 Rule Match와 진단에 중요한 증거다.

유용한 항목은 다음과 같다.

Timestamp
Action
Rule ID
Ingress / Egress Interface 또는 Zone
Source / Destination IP와 Port
Protocol
Conntrack State
Packet와 Byte Counter

하지만 모든 Packet을 무제한 기록하면 Log 처리 자체가 병목과 저장 비용을 만든다.

공격자가 많은 Drop Packet을 보내 Logging 자원을 소모하게 할 수도 있다.

Rate Limiting, Flow 단위 Log, Sampling과 중앙 수집을 목적에 맞게 사용한다.

Log가 없다고 Packet이 통과했다는 뜻은 아니고, Log가 있다고 Endpoint Application이 처리했다는 뜻도 아니다.

Rule Counter, Multi-point Capture, Conntrack State와 Application Log를 함께 연결해야 한다.

---

ㅁ Policy를 작성할 때 어떤 질문을 남겨야 할까?

Rule 한 줄마다 다음 질문에 답할 수 있어야 한다.

1. 어떤 업무 Flow를 위해 필요한가?
2. Source와 Destination을 더 좁힐 수 있는가?
3. TCP와 UDP 중 어떤 Protocol인가?
4. 새 연결과 Return Traffic을 어떻게 구분하는가?
5. ICMP와 DNS 같은 보조 Flow도 필요한가?
6. Rule의 우선순위와 앞뒤 Shadowing은 없는가?
7. 언제 검토하고 삭제할 것인가?
8. Drop 시 어떤 Log와 Counter로 검증할 것인가?

좋은 Firewall Policy는 Rule 수가 많은 Policy가 아니다.

업무의 필요한 통신을 최소 범위로 설명하고, 나머지 Traffic이 왜 허용되지 않는지 예측할 수 있는 Policy다.

---

ㅁ 우편 비유를 네트워크 용어로 바꾸면

비유를 실제 Header와 State로 다시 연결해 보자.

우편 이야기	실제 용어	정확한 의미
봉투마다 주소표만 보고 독립 심사	Stateless ACL	이전 Packet을 기억하지 않고 현재 Header를 Rule과 비교
발신·수신 주소와 창구 번호	5-Tuple	Protocol과 양쪽 IP·Port로 Flow를 구분
처음 접수한 대화의 왕복표	Connection Tracking	Original과 Reply Tuple, State와 Timeout 저장
새 배송 요청	NEW	기존 Entry에 속하지 않는 새 Flow 후보
이미 왕복이 확인된 배송	ESTABLISHED	Conntrack이 양방향 Flow의 일부로 인식
기존 배송에서 생긴 반송 안내	RELATED	기존 Flow와 관련된 ICMP 오류나 보조 Flow
장부와 맞지 않는 봉투	INVALID	정상적인 State로 추적할 수 없는 Packet
명시하지 않은 배송은 기본 거절	Default Deny	Allow Rule에 없는 Traffic을 차단
필요한 주소와 창구만 최소 개방	Least Privilege	업무에 필요한 Source·Destination·Protocol 범위만 허용
말없이 편지를 폐기	DROP	응답 없이 Packet을 버려 Sender가 Timeout을 겪을 수 있음
거절 안내를 돌려보냄	REJECT	TCP RST나 ICMP 오류로 거절을 알림
앞의 넓은 규칙에 뒤 규칙이 가려짐	Rule Shadowing	평가 순서 때문에 뒤 Rule이 Match되지 않음
들어오는 문과 나가는 문을 따로 관리	Ingress / Egress Filtering	양방향 Traffic Policy를 각각 통제

 

TCP 연결 하나를 Stateful Policy로 판단하는 흐름은 다음과 같다.

Client SYN
NEW + 승인된 Destination:443
        ↓ Allow, State 생성

Server SYN-ACK
기존 Entry의 Reply Tuple + ESTABLISHED
        ↓ Allow

Client ACK와 Data
기존 Entry의 Original Tuple + ESTABLISHED
        ↓ Allow

FIN/RST 또는 Timeout
        ↓ State 정리

그 밖의 새 Inbound Packet
명시적 Allow 없음
        ↓ Default Deny

---

ㅁ Packet과 State를 직접 관찰해 보기

Wireshark나 tcpdump에서는 Firewall이 통과시키기 전과 후의 Packet을 비교한다.

Client 쪽 Capture : SYN 전송 확인
Firewall 입구     : SYN 도착 확인
Firewall 출구     : SYN 전달 여부
Server 쪽 Capture : SYN 수신 여부

한 지점에서 Packet이 보이지 않는다는 사실만으로 바로 그 지점이 Drop했다고 단정하지 않는다.

앞 구간에서 도착했는지 먼저 확인한다.

Linux에서 Rule과 Counter는 환경에 따라 다음처럼 확인할 수 있다.

sudo iptables -L FORWARD -n -v --line-numbers

 

Conntrack 도구가 있다면 다음처럼 State를 확인한다.

sudo conntrack -L -p tcp
sudo conntrack -L -p udp

Rule Counter가 증가하면 해당 Rule에 Packet이 Match됐다는 증거다.

그 뒤 Packet이 Destination Application에서 정상 처리됐다는 증거는 아니다.

---

ㅁ 격리된 Linux 환경에서 Stateful Policy를 관찰해 보기

다음 실습은 ip, iptables, tcpdump, nc가 있는 개인 Linux VM에서 수행한다. 실제 Host Firewall이 아니라 새 Network Namespace 안의 FORWARD Policy만 바꾼다.

fw-client                  fw-router                  fw-server
10.22.1.2 ────────── 10.22.1.1 | 198.51.100.1 ───── 198.51.100.2

 

Namespace와 가상 Link를 만든다.

sudo ip netns add fw-client
sudo ip netns add fw-router
sudo ip netns add fw-server

sudo ip link add veth-fc type veth peer name veth-fwi
sudo ip link add veth-fwo type veth peer name veth-fs

sudo ip link set veth-fc netns fw-client
sudo ip link set veth-fwi netns fw-router
sudo ip link set veth-fwo netns fw-router
sudo ip link set veth-fs netns fw-server

 

Address와 Interface를 설정한다.

sudo ip -n fw-client addr add 10.22.1.2/24 dev veth-fc
sudo ip -n fw-router addr add 10.22.1.1/24 dev veth-fwi
sudo ip -n fw-router addr add 198.51.100.1/24 dev veth-fwo
sudo ip -n fw-server addr add 198.51.100.2/24 dev veth-fs

sudo ip -n fw-client link set lo up
sudo ip -n fw-router link set lo up
sudo ip -n fw-server link set lo up
sudo ip -n fw-client link set veth-fc up
sudo ip -n fw-router link set veth-fwi up
sudo ip -n fw-router link set veth-fwo up
sudo ip -n fw-server link set veth-fs up

 

Route와 IPv4 Forwarding을 설정한다.

sudo ip -n fw-client route add default via 10.22.1.1
sudo ip -n fw-server route add default via 198.51.100.1
sudo ip netns exec fw-router \
  sysctl -w net.ipv4.ip_forward=1

 

새 Namespace의 FORWARD Chain을 비우고 Default Policy를 DROP으로 설정한다.

sudo ip netns exec fw-router iptables -F FORWARD
sudo ip netns exec fw-router iptables -P FORWARD DROP

 

INVALID를 차단하고, 기존 Flow의 ESTABLISHED·RELATED Packet을 허용한다.

sudo ip netns exec fw-router \
  iptables -A FORWARD \
  -m conntrack --ctstate INVALID -j DROP

sudo ip netns exec fw-router \
  iptables -A FORWARD \
  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

 

Client Network에서 Server의 TCP 8080으로 시작하는 새 연결만 허용한다.

sudo ip netns exec fw-router \
  iptables -A FORWARD \
  -i veth-fwi -o veth-fwo \
  -s 10.22.1.0/24 -d 198.51.100.2 \
  -p tcp --syn --dport 8080 \
  -m conntrack --ctstate NEW -j ACCEPT

 

Rule 순서와 Counter를 확인한다.

sudo ip netns exec fw-router \
  iptables -L FORWARD -n -v --line-numbers

 

Capture Terminal에서 Firewall 양쪽 Packet을 저장한다.

sudo ip netns exec fw-router \
  tcpdump -n -vv -i any -s 0 -w /tmp/firewall-state.pcap \
  'tcp port 8080 or tcp port 9090'

 

Server Terminal에서 8080을 Listen한다.

sudo ip netns exec fw-server nc -l 8080

 

Client Terminal에서 연결한다.

sudo ip netns exec fw-client nc 198.51.100.2 8080

Client의 SYN은 NEW Allow Rule과 Match한다.

Server의 SYN-ACK은 Source Port 8080에서 Client의 임시 Port로 돌아오지만

기존 Entry의 ESTABLISHED Reply이므로 허용된다.

 

conntrack이 설치되어 있다면 연결 중 Tuple과 State를 확인한다.

sudo ip netns exec fw-router conntrack -L -p tcp

---

ㅁ DROP과 REJECT를 같은 경로에서 비교해 보기

8080 연결을 종료한 뒤 Server가 9090에서 Listen하더라도 현재 Allow Rule에는 9090이 없다.

Server Terminal:

sudo ip netns exec fw-server nc -l 9090

 

Client에서 연결을 시도한다. nc Timeout Option은 구현마다 다를 수 있다.

sudo ip netns exec fw-client \
  nc -v -w 3 198.51.100.2 9090

SYN이 Default DROP에 걸리면 응답이 없어 재전송 후 Timeout으로 보일 수 있다.

 

이번에는 9090을 명시적으로 REJECT하는 Rule을 추가한다.

sudo ip netns exec fw-router \
  iptables -A FORWARD \
  -i veth-fwi -o veth-fwo \
  -p tcp --dport 9090 \
  -j REJECT --reject-with tcp-reset

같은 Client 명령을 다시 실행하면 Firewall이 보낸 RST 때문에 더 빠르게 실패할 수 있다.

 

Capture에서 다음 차이를 확인한다.

DROP   : Client SYN 반복, 응답 없음
REJECT : Client SYN 뒤 TCP RST 응답

 

Rule Counter와 순서도 다시 확인한다.

sudo ip netns exec fw-router \
  iptables -L FORWARD -n -v --line-numbers

 

실습을 마치면 Namespace를 삭제한다. 내부 Conntrack State와 Firewall Rule도 함께 제거된다.

sudo ip netns del fw-client
sudo ip netns del fw-router
sudo ip netns del fw-server

 

실제 Host의 기본 Firewall Policy를 실습 목적으로 바꾸지 않는다.

---

ㅁ 핵심 정리

• 방화벽은 Packet의 의도를 직접 아는 것이 아니라 Header, 방향, Zone, State를 Policy와 비교한다.
• 5-Tuple은 Protocol과 Source·Destination IP 및 Port로 Flow를 구분한다.
• Stateless ACL은 각 Packet을 독립적으로 판단하므로 요청과 Return Traffic을 양방향 Rule로 표현해야 한다.
• TCP ACK Flag 하나는 방화벽이 관찰한 기존 Connection의 증거를 대신하지 못한다.
• Stateful Firewall은 Original Tuple과 Reply Tuple, State, Timeout을 Connection Tracking Entry로 기억한다.
• Conntrack의 NEW·ESTABLISHED는 Endpoint TCP State나 Application 인증 상태와 같은 개념이 아니다.
• RELATED는 기존 Flow에 관련된 ICMP 오류나 보조 Flow를 표현할 수 있고 INVALID는 정상 추적이 어려운 Packet이다.
• UDP Conntrack은 Handshake가 아니라 Tuple과 Timeout을 바탕으로 만든 중간 장비의 Pseudo-State다.
• Default Deny는 명시적인 Allow가 없는 Traffic을 차단하며 Least Privilege는 필요한 Source·Destination·Protocol 범위를 최소화한다.
• Rule 순서와 평가 방식에 따라 넓은 Rule이 구체적인 Rule을 가리는 Shadowing이 생길 수 있다.
• DROP은 응답 없이 버려 Timeout을 만들 수 있고 REJECT는 RST나 ICMP로 빠르게 거절을 알릴 수 있다.
• NAT, Firewall, Application 인증과 TLS는 각각 주소 변환, 통신 허용, 사용자 권한, 내용 보호라는 다른 문제를 해결한다.
• Stateful 장비는 Asymmetric Path, State Table 고갈, Fragment와 Timeout의 영향을 받는다.
• Firewall Log와 Rule Counter는 Match 증거이며 Destination Application의 처리 완료 증거는 아니다.
• IPv6에서는 Address 공유 NAT가 없어도 Firewall Policy가 필요하고 필수 ICMPv6까지 IPv4 Rule처럼 일괄 차단하면 안 된다.

 

핵심 용어: Firewall, Packet Filter, Access Control List, ACL, Stateless Firewall, Stateful Firewall, 5-Tuple, Connection Tracking, Conntrack, NEW, ESTABLISHED, RELATED, INVALID, Default Deny, Principle of Least Privilege, Rule Order, Rule Shadowing, ALLOW, DROP, REJECT, Ingress Filtering, Egress Filtering, Host Firewall, Network Firewall, State Table, Asymmetric Routing

 

방화벽은 좋은 의도를 판별하는 심판이 아니다. 관찰 가능한 주소·Port·방향·연결 상태를 명확한 Policy와 비교하는 장치다. 그래서 보안은 “무엇을 막을까”보다 “어떤 업무 흐름을 왜 허용해야 하는가”를 설명하는 일에서 시작한다.

---

ㅁ 다음 이야기

Firewall은 필요한 통신 경로를 선택적으로 열었다.

그러나 통과가 허용된 Router와 ISP, Wi-Fi 운영자가 Packet 내용을 읽거나 바꾸지 않을 것이라고 믿을 수는 없다.

주소와 Port를 허용하는 것만으로 상대가 진짜 Server인지, 전달 중 내용이 바뀌지 않았는지 어떻게 확인할까?

다음 글에서는 「우체부를 믿지 않고도 편지 내용을 지킬 수 있을까?」라는 질문을 통해 TLS Handshake, Certificate, Authentication, Key Exchange, Encryption과 Integrity가 서로 다른 문제를 어떻게 함께 해결하는지 살펴본다.