📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 252편
이전 글: 251. 네트워크 보안장비의 역할 · 다음 글: 253. Packet Filtering Firewall
1. 개념
Firewall(방화벽) 은 서로 다른 신뢰 수준의 네트워크 사이에서, 미리 정한 정책(Policy) 에 따라 트래픽을 허용하거나 차단하는 접근 통제 장치입니다. 장비 형태(네트워크/호스트 방화벽)와 배치(경계·내부·DMZ)는 04 영역 155. Firewall이란 무엇인가에서 다뤘고, 이 글은 방화벽이 무엇을 근거로 판단하는가에 집중합니다.
방화벽의 판단은 한 문장으로 요약할 수 있습니다.
"이 출발지가 이 목적지의 이 서비스로, 이 방향으로 가는 것이 정책에 있는가?"
| 판단 요소 | 패킷에서 보는 위치 | 예 |
|---|---|---|
| 출발지 / 목적지 IP | IP 헤더 | 192.168.10.25 → 10.20.0.10 |
| 프로토콜 | IP 헤더의 Protocol 필드 | TCP(6), UDP(17), ICMP(1) |
| 출발지 / 목적지 포트 | TCP/UDP 헤더 | 51544 → 443 |
| 인터페이스·Zone | 패킷이 들어온/나갈 장비 포트 | users → servers |
| 연결 상태 | 세션 테이블 | 새 연결 / 기존 연결의 응답 |
앞의 다섯 요소 중 IP·프로토콜·포트를 묶어 5-tuple이라고 부릅니다.
2. 동작 원리
방화벽의 판단 흐름을 단순화하면 다음과 같습니다(세부 순서는 제품마다 다름).
패킷 도착 (인터페이스 A)
↓
[기존 세션의 패킷인가?] ─ 예 → 통과 (정책 재평가 생략)
↓ 아니오
[정책 1번부터 순서대로 비교]
↓ 첫 번째로 일치한 규칙의 동작 적용
[Allow] → 세션 생성 → 인터페이스 B로 전달 → 로그(설정 시)
[Deny ] → 폐기 또는 거부 응답 → 로그(설정 시)
↓ 끝까지 일치 없음
[기본 정책 적용 → 보통 Deny]이 흐름에서 관제에 중요한 사실 두 가지가 나옵니다.
- 규칙의 순서가 결과를 바꿉니다. 넓은 허용 규칙이 위에 있으면 아래의 차단 규칙은 영원히 적용되지 않습니다(256. Firewall Rule).
- 로그는 규칙에 달린 옵션입니다. 로그를 켜지 않은 규칙으로 처리된 트래픽은 기록되지 않습니다(271. Firewall Logging).
3. 주요 특징
방화벽은 판단에 사용하는 정보의 깊이에 따라 발전해 왔습니다.
| 유형 | 보는 정보 | 장점 | 한계 | 관련 글 |
|---|---|---|---|---|
| Packet Filtering | 패킷 한 개의 헤더 | 빠르고 단순 | 응답 패킷 허용 규칙이 필요, 위조에 약함 | 253. Packet Filtering Firewall |
| Stateful | 헤더 + 연결 상태 | 응답 자동 허용, 비정상 패킷 차단 | 내용은 보지 않음 | 254. Stateful Firewall |
| Application(프록시·WAF·NGFW) | 응용 계층 내용 | 앱·URL·명령 단위 통제 | 성능 부담, 암호화 트래픽 처리 필요 | 255. Application Firewall |
방화벽이 할 수 없는 것도 분명히 알아 두어야 합니다.
- 허용된 포트(예: 443) 안에서 일어나는 공격이나 악성 통신은 헤더만으로 구분하지 못합니다.
- 방화벽을 거치지 않는 경로(같은 세그먼트 내부 통신, 우회 회선)는 통제하지 못합니다.
- 정상 계정으로 로그인한 공격자의 행위는 네트워크상으로 정상 통신과 같아 보입니다.
4. 예시
Linux 호스트 방화벽에서 "지금 어떤 판단 기준이 적용되는가"를 확인하는 실습 예시입니다(값은 환경마다 다름). 설정 문법 자체는 04 영역 181. Firewall 정책을 참고합니다.
# Rocky (firewalld): 활성 zone과 허용 서비스·포트 확인
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all
# Ubuntu (ufw): 규칙 번호와 기본 정책 확인
sudo ufw status numbered
sudo ufw status verbose
# 공통 (nftables 백엔드): 실제로 적재된 규칙 전체 확인
sudo nft list rulesetufw status verbose 출력에는 Default: deny (incoming), allow (outgoing)처럼 기본 정책이 표시됩니다. 관제 관점에서는 허용 목록과 기본 정책을 먼저 확인하면 "이 통신이 왜 통과했는가"를 빠르게 설명할 수 있습니다.
5. 보안 관점
- 방화벽은 최소 권한 원칙을 네트워크에 적용하는 도구입니다. 필요한 출발지·목적지·포트만 허용합니다.
- 방화벽은 공격을 "탐지"하는 장비가 아니라 공격 표면을 줄이는 장비입니다. 열린 포트가 적을수록 스캔·공격 대상이 줄어듭니다.
- 정책은 시간이 지나면 느슨해집니다. 임시 허용, any 규칙, 퇴역 서버 규칙이 쌓이지 않도록 정기 검토가 필요합니다.
- 방화벽 관리자 권한은 네트워크 전체 통제 권한이므로 관리 접속과 변경 이력을 별도로 관리합니다.
6. SOC 관점
방화벽 로그는 "연결이 있었는가, 허용됐는가"에 대한 가장 기본적인 증거입니다.
| 관제 질문 | 방화벽 로그에서 보는 것 |
|---|---|
| 외부 IP가 내부 서버에 실제로 접속했는가? | 해당 5-tuple의 allow 로그, 세션 바이트 수 |
| 차단은 어느 규칙에서 일어났는가? | 규칙 ID·이름 필드 |
| 내부 PC가 외부 의심 IP로 나간 적이 있는가? | Outbound allow 로그 검색 |
| 스캔인가, 단발성 시도인가? | 같은 출발지의 목적지 포트 분포 |
관제자가 확인할 질문
- 이 연결을 처리한 규칙은 무엇이며, 그 규칙은 로그를 남기도록 되어 있는가?
- 차단 로그만 있고 허용 로그가 없다면, 공격은 실제로 도달하지 않았다고 볼 수 있는가?
오탐 주의: 방화벽 차단 로그는 대부분 인터넷의 자동화된 스캔입니다. 차단 자체보다 차단 뒤에 허용된 연결이 있는가를 봅니다. 스캔 흔적 분석은 05 영역 234. Firewall에서 Scan 흔적 찾기에서 다룹니다.
7. 핵심 정리
- 방화벽은 정책에 따라 출발지·목적지·프로토콜·포트·방향·상태를 보고 허용 또는 차단합니다.
- 새 연결은 규칙 순서대로 비교해 첫 일치 규칙을 적용하고, 일치가 없으면 기본 정책이 적용됩니다.
- 방화벽은 Packet Filtering → Stateful → Application 방식으로 판단 정보가 깊어져 왔습니다.
- 허용된 포트 안의 공격이나 방화벽을 거치지 않는 경로는 방화벽만으로 막을 수 없습니다.
- 관제에서 방화벽 로그는 "연결이 있었고 허용됐는가"를 증명하는 기본 자료입니다.
