📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 272편
이전 글: 271. Firewall Logging · 다음 글: 273. Firewall Log 분석
1. 개념
Firewall Log 구조는 방화벽 로그 한 줄이 어떤 필드로 구성되고, 각 필드가 무엇을 의미하는지를 말합니다. 제품마다 필드 이름과 순서가 다르지만, 담는 정보는 대부분 같은 필드 그룹으로 정리할 수 있습니다. 필드의 의미를 그룹으로 이해해 두면 처음 보는 제품의 로그도 빠르게 읽을 수 있습니다.
| 필드 그룹 | 대표 필드(의미 기준) | 답하는 질문 |
|---|---|---|
| 시각·장비 | 이벤트 시각, 장비 이름, 로그 유형 | 언제, 어느 장비에서 |
| 판정 | action(allow/deny/drop/reject), 규칙 ID·이름 | 무엇을, 왜 |
| 위치·방향 | 수신·송신 인터페이스, 출발·도착 Zone | 어디서 어디로 |
| 5-tuple | 출발지·목적지 IP와 포트, 프로토콜 | 누가 누구와 |
| NAT | 변환된 출발지·목적지 IP와 포트 | 외부에는 어떻게 보였나 |
| 세션 통계 | 송수신 바이트·패킷, 지속 시간, 종료 사유 | 얼마나, 어떻게 끝났나 |
| 확장 정보 | 애플리케이션, 사용자, URL 분류 | 무엇을 쓴 누구 (NGFW) |
2. 동작 원리
로그는 장비에서 생성되어 SIEM에 들어가기까지 여러 번 형태가 바뀝니다.
방화벽 내부 이벤트
↓ 장비 고유 형식으로 직렬화 (key=value, CSV, CEF 등)
↓ syslog 헤더 추가 (수신 시각·호스트명)
↓ 로그 수집기 파싱 → 필드 추출
↓ SIEM 정규화 (src_ip, dest_ip, action 같은 공통 이름으로 변환)
↓ 분석 화면 / 탐지 규칙이 과정 때문에 분석 시 주의할 점이 생깁니다.
- 시각 필드가 여러 개일 수 있습니다. 장비가 기록한 이벤트 시각과 수집기가 받은 시각이 다를 수 있으므로, 어떤 값을 기준으로 검색하는지 확인합니다.
- 정규화 과정에서 의미가 바뀔 수 있습니다. 예를 들어 제품의
deny,drop,reset을 모두blocked하나로 합치면 Drop과 Reject의 구분이 사라집니다. 원본 로그 필드를 함께 보관하는 것이 좋습니다.
3. 주요 특징
Linux 커널 방화벽 로그(iptables LOG / nftables log) 는 key=value 형태이며, 주요 필드는 다음과 같습니다.
| 필드 | 의미 |
|---|---|
| 접두어(prefix) | 규칙에서 지정한 문자열 — 규칙 식별 수단 |
| IN / OUT | 수신 / 송신 인터페이스 (OUT이 비면 장비 자신이 목적지) |
| SRC / DST | 출발지 / 목적지 IP |
| LEN, TTL, ID | IP 전체 길이, TTL, IP 식별자 |
| PROTO | TCP, UDP, ICMP 등 |
| SPT / DPT | 출발지 / 목적지 포트 (TCP·UDP) |
| SYN, ACK, FIN, RST 등 | 설정된 TCP 플래그 |
| TYPE / CODE | ICMP 유형·코드 |
커널 로그는 패킷 단위이고 판정(action) 필드가 따로 없습니다. 허용인지 차단인지는 접두어로 구분해야 하므로 접두어 이름 규칙이 중요합니다.
pfSense filterlog는 쉼표로 구분된 CSV 형식입니다. 앞부분은 규칙 번호, 하위 규칙, anchor, tracker ID, 인터페이스, 사유(reason), 동작(pass/block), 방향(in/out), IP 버전 순서이고, 이후 IP 버전과 프로토콜에 따라 필드 수가 달라집니다. CSV는 순서가 곧 의미이므로 버전별 필드 정의를 확인해 파싱해야 합니다.
4. 예시
같은 연결을 서로 다른 형식으로 표현한 형식 예시입니다(값은 환경마다 다르며 특정 제품의 실제 출력이 아님).
# 1) key=value 형식 (상용 방화벽에 흔함)
date=2026-09-30 time=15:20:11 devname=FW01 type=traffic action=deny policyid=99 srcintf=wan dstintf=dmz srcip=198.51.100.23 srcport=50110 dstip=10.30.0.10 dstport=22 proto=6
# 2) CEF 형식 (헤더는 파이프로 구분, 뒤는 확장 key=value)
CEF:0|ExampleVendor|ExampleFW|1.0|traffic-deny|Traffic denied|5|src=198.51.100.23 spt=50110 dst=10.30.0.10 dpt=22 proto=TCP act=deny cs1Label=rule cs1=99
# 3) JSON 형식 (SIEM 정규화 후)
{"@timestamp":"2026-09-30T06:20:11Z","observer.name":"FW01","event.action":"deny","rule.id":"99","source.ip":"198.51.100.23","source.port":50110,"destination.ip":"10.30.0.10","destination.port":22,"network.transport":"tcp"}분석 방법 — 세 로그의 시각을 비교해 보면, 1)·2)는 현지 시각(KST) 15:20이고 3)은 UTC 06:20입니다. 같은 사건입니다. 형식이 바뀌어도 시각·판정·규칙·5-tuple을 먼저 찾아 읽으면 구조를 빠르게 파악할 수 있습니다. 3)의 필드 이름은 Elastic Common Schema(ECS) 스타일의 예입니다.
5. 보안 관점
- 로그 형식 문서가 없으면 필드를 잘못 해석할 위험이 큽니다. 특히 NAT 전후 주소, 방향 필드, 바이트 수의 기준(송신·수신이 누구 기준인지)은 제품 문서로 확인합니다.
- syslog는 기본적으로 무결성 보장이 없습니다. 로그 위조·유실에 대비해 전송 보호와 원본 보관을 고려합니다.
- 로그 필드에 사용자 이름·URL 등 민감 정보가 포함되면 접근 권한 관리가 필요합니다.
- 파싱 실패로 필드가 비어 들어온 로그는 탐지 규칙에서 조용히 누락됩니다. 파싱 오류율을 정기적으로 확인합니다.
6. SOC 관점
관제자가 확인할 질문
- 이 로그의 시각 필드는 어떤 기준(장비/수집, UTC/현지) 인가?
- IP 필드는 NAT 전인가 후인가, 바이트 필드는 어느 방향 기준인가?
- 정규화된 action 값이 원본의 어떤 값에서 왔는가? Drop·Reject·상태 불일치가 한 값으로 합쳐지지 않았는가?
- 파싱 실패로 필드가 비어 있는 로그가 검색 결과에서 빠지지 않았는가?
| 필드 해석 실수 | 결과 |
|---|---|
| 시간대 혼동 | 다른 장비 로그와 9시간 어긋나 연결 실패 |
| NAT 전후 주소 혼동 | 엉뚱한 내부 호스트 지목 |
| 송수신 바이트 기준 혼동 | 다운로드를 유출로 오판 |
오탐 주의: SIEM 대시보드의 집계 값은 정규화 결과입니다. 이상해 보이는 값은 원본 로그 한두 줄을 직접 확인한 뒤 판단합니다. 포트 필드의 세부 해석은 95. Firewall Log의 Port를 참고합니다.
7. 핵심 정리
- 방화벽 로그는 시각·장비, 판정, 위치·방향, 5-tuple, NAT, 세션 통계, 확장 정보 그룹으로 읽습니다.
- Linux 커널 로그는 판정 필드가 없어 접두어로 허용·차단을 구분합니다.
- pfSense filterlog 같은 CSV 형식은 필드 순서가 곧 의미이므로 버전별 정의를 확인합니다.
- key=value, CEF, JSON 등 형식이 달라도 같은 필드 그룹을 먼저 찾아 읽습니다.
- 시간대, NAT 전후, 바이트 방향, 정규화 과정의 값 변환을 확인해야 해석 오류를 피할 수 있습니다.
