📚 네트워크 · 패킷 분석 › 04. 네트워크 장비 실습 — 187편
이전 글: 186. Firewall NAT 정책 · 다음 글: 188. IDS 동작 구조
1. 개념
Firewall Log는 방화벽이 허용·차단한 트래픽과 장비 자체의 동작(설정 변경, 관리자 접속, 장애)을 기록한 로그입니다. 관제에서 가장 많이 조회하는 로그 중 하나지만, 방화벽은 기본적으로 모든 트래픽을 기록하지 않습니다. 어떤 규칙에서 로그를 남길지, 어디에 저장하고 어디로 보낼지를 장비에서 설정해야 합니다.
이 글은 로그가 생성·저장·전송되는 장비 측 구조를 다룹니다. 로그 필드의 의미와 분석 방법은 06 영역 271. Firewall Logging, 272. Firewall Log 구조, 273. Firewall Log 분석에서 다룹니다.
| 로그 종류 | 기록 내용 | 생성 조건 |
|---|---|---|
| 트래픽(정책) 로그 | 허용·차단된 세션의 주소·포트·규칙 | 규칙에 로깅 옵션을 켠 경우 |
| NAT 로그 | 주소 변환 생성·해제 | 장비가 지원하고 활성화한 경우 |
| 시스템 로그 | 부팅, 인터페이스 상태, HA 전환, 자원 부족 | 대부분 기본 기록 |
| 관리(감사) 로그 | 관리자 로그인, 정책 변경 | 대부분 기본 기록, 보관 설정 필요 |
2. 동작 원리
Linux 방화벽(netfilter)을 예로 들면 로그는 다음 경로를 거칩니다.
패킷이 LOG 규칙(또는 nftables log 문)에 일치
↓ 커널이 메시지 생성 (접두어 + IN/OUT/SRC/DST/PROTO/SPT/DPT ...)
↓ 커널 링 버퍼 → journald / rsyslog
↓ 로컬 파일 저장 (배포판별 위치)
↓ rsyslog 원격 전송 → 로그 서버 / SIEMLOG 규칙은 패킷을 기록만 하고 판정은 하지 않습니다. 그래서 보통 "LOG 규칙 → 같은 조건의 DROP 규칙" 순서로 둡니다. 상용 방화벽은 규칙마다 "로그 남김" 옵션이 있고, 세션 시작 시점에 기록할지 종료 시점에 기록할지(바이트 수 포함)를 고를 수 있는 제품도 있습니다.
3. 주요 특징
로그 저장 위치는 장비와 배포판에 따라 다릅니다.
| 환경 | 로그 생성 방식 | 기본 저장 위치(일반적인 경우) |
|---|---|---|
| Ubuntu + ufw | [UFW BLOCK] 등 접두어가 붙은 커널 로그 | /var/log/ufw.log, /var/log/kern.log |
| Rocky + firewalld | --set-log-denied 설정 시 거부 패킷 기록 | /var/log/messages, journalctl -k |
| iptables / nftables 직접 | LOG 대상, log prefix 문 | 커널 로그 경로(배포판별) |
| pfSense | filterlog 프로세스, 쉼표 구분 형식 | /var/log/filter.log, GUI Status › System Logs › Firewall |
운영에서 로그 설정 시 고려할 점입니다.
| 고려 사항 | 설명 |
|---|---|
| 로그 양 제한 | 차단 로그를 모두 남기면 스캔 한 번에 수천 줄이 생김. iptables -m limit처럼 기록 속도 제한을 쓸 수 있으나, 제한 초과분은 기록되지 않음 |
| 허용 로그 여부 | 허용 로그는 양이 많지만 "실제로 통과한 연결"의 증거가 됨 |
| 시간 동기화 | NTP가 맞지 않으면 다른 장비 로그와 연결 불가 |
| 원격 전송 | 방화벽이 침해·재부팅되면 로컬 로그가 사라질 수 있어 외부 보관 필요 |
4. 예시
실습 예시 — 방화벽 역할 Linux VM에서 차단 로그를 남기고 확인하는 흐름입니다. 인터페이스·IP는 예시(값은 환경마다 다름)입니다.
# iptables: SSH 신규 접속 시도 중 허용 목록 외 출발지를 기록 후 차단 (분당 5건까지 기록)
sudo iptables -A INPUT -p tcp --dport 22 -s 10.10.99.0/24 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -m limit --limit 5/min \
-j LOG --log-prefix "FW-SSH-DROP " --log-level 4
sudo iptables -A INPUT -p tcp --dport 22 -j DROP
# Ubuntu (ufw 사용 시): 로깅 활성화 후 로그 확인
sudo ufw logging on
sudo tail -f /var/log/ufw.log
# Rocky (firewalld 사용 시): 거부 패킷 기록 켜기
sudo firewall-cmd --set-log-denied=all
sudo journalctl -k -f커널 로그 한 줄의 형식은 다음과 같습니다.
# 형식 예시 (값은 환경마다 다름)
FW-SSH-DROP IN=ens33 OUT= MAC=00:0c:29:aa:bb:cc:00:0c:29:11:22:33:08:00 SRC=192.168.10.50 DST=192.168.10.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=40211 DF PROTO=TCP SPT=51514 DPT=22 WINDOW=64240 RES=0x00 SYN URGP=0IN=만 있고 OUT=이 비어 있으면 장비 자신으로 들어온(INPUT) 패킷이고, 둘 다 있으면 장비를 통과(FORWARD)한 패킷입니다.
로그 서버로 전송하려면 rsyslog 설정 파일을 추가합니다(Rocky·Ubuntu 공통, 로그 서버 주소는 예시).
# /etc/rsyslog.d/90-forward.conf — @@ 는 TCP, @ 는 UDP
kern.* @@10.10.99.10:514
sudo systemctl restart rsyslog📷 [실습 화면 삽입 위치] 다른 VM에서 방화벽 VM의 22번 포트로 접속을 시도한 직후,
/var/log/ufw.log(또는journalctl -k)에 차단 로그가 기록되는 화면
5. 보안 관점
- 로그를 남기지 않은 규칙은 증거를 남기지 않습니다. 사고 후 "그 연결이 허용됐는가"를 확인하려면 허용 규칙에도 필요한 범위의 로깅이 있어야 합니다.
- 로그 속도 제한은 장비를 보호하지만, 대량 스캔 중에는 일부 이벤트가 기록되지 않는다는 점을 알고 해석해야 합니다.
- 관리(감사) 로그는 정책 무단 변경을 확인하는 유일한 근거인 경우가 많습니다. 방화벽 관리자 계정이 탈취되면 공격자가 로그 설정을 끌 수도 있으므로, 원격 저장과 설정 변경 알림을 함께 둡니다.
- UDP syslog는 전송 중 유실될 수 있고 암호화되지 않습니다. 필요하면 TCP나 TLS 전송을 검토합니다.
6. SOC 관점
관제자가 확인할 질문
- 이 방화벽에서 해당 규칙은 로그를 남기도록 설정되어 있는가? 로그가 "없다"는 것이 "트래픽이 없었다"는 뜻인가, "기록하지 않았다"는 뜻인가?
- 로그가 장비 로컬에만 있는가, 로그 서버·SIEM에도 같은 시간대 로그가 있는가? 중간에 끊긴 구간은 없는가?
- 같은 시각 시스템 로그에 재부팅, HA 전환, 로그 설정 변경 기록은 없는가?
사건 시각 방화벽 로그 조회
↓ 로그 있음 → 허용/차단 확인 → 필드 분석 (06 영역)
↓ 로그 없음 → 규칙 로깅 설정 확인
→ 속도 제한 초과 여부 확인
→ 전송 경로(관리망·rsyslog) 장애 확인오탐 주의: 방화벽 차단 로그가 폭증했다고 해서 곧 침해는 아닙니다. 대부분은 인터넷의 자동화된 스캔이며, 스캔 흔적을 찾는 방법은 05 영역 234. Firewall에서 Scan 흔적 찾기에서 다룹니다.
7. 핵심 정리
- 방화벽은 모든 트래픽을 기록하지 않으며, 규칙별 로깅 설정이 있어야 트래픽 로그가 남습니다.
- Linux 방화벽 로그는 커널 로그로 생성되어 배포판에 따라
/var/log/ufw.log,/var/log/kern.log,/var/log/messages등에 저장되고, pfSense는/var/log/filter.log에 기록합니다. - 로그 속도 제한, 허용 로그 여부, 시간 동기화, 원격 전송을 운영 설계에 포함해야 합니다.
- 관리(감사) 로그는 정책 변경의 근거이므로 원격 보관이 중요합니다.
- 로그가 없을 때는 트래픽 부재와 기록 누락을 구분해서 판단합니다.
