271. Firewall Logging

📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 271편
이전 글: 270. DMZ와 Firewall · 다음 글: 272. Firewall Log 구조

1. 개념

Firewall Logging은 방화벽이 처리한 트래픽과 장비 동작 중 무엇을 기록으로 남길지 정하는 설계입니다. 로그가 어디서 생성되고 어디에 저장·전송되는지(커널 로그 경로, ufw·firewalld·pfSense 로그 위치, rsyslog 전송)는 04 영역 187. Firewall Log에서 다뤘습니다.

이 글은 "사고가 났을 때 필요한 질문에 답할 수 있는 로그가 남아 있는가" 를 기준으로 로깅을 설계하는 방법을 다룹니다. 로깅은 사후에 바꿀 수 없습니다. 사건 당시 기록하지 않은 것은 영원히 알 수 없습니다.

관제 질문	필요한 로그	로깅 설정
외부의 누가 공개 서버에 접속했는가?	Inbound 허용 로그	공개 서비스 허용 규칙 로깅
내부 호스트가 어디로 나갔는가?	Outbound 허용 로그	Outbound 허용 규칙 로깅(최소 세션 시작)
얼마나 많은 데이터가 오갔는가?	세션 종료 로그(바이트 수)	세션 종료 시 기록
정책에 없는 시도는 무엇인가?	기본 차단 로그	명시적 기본 차단 규칙 로깅
누가 정책을 바꿨는가?	관리(감사) 로그	기본 기록 + 원격 보관

---

2. 동작 원리

로깅 판단을 규칙 단위로 내리는 흐름입니다.

규칙 하나를 볼 때
   ↓
[이 규칙이 처리하는 트래픽이 사고 조사에 필요한가?]
   ├─ 아니오 (예: 대량의 알려진 정상 브로드캐스트) → 로깅 안 함 또는 집계만
   └─ 예
        ↓
   [기록 시점] 세션 시작 / 종료 / 둘 다
        ↓
   [양 조절] 속도 제한, 요약, 샘플링 여부
        ↓
   [보관] 로컬 + 원격(SIEM), 보관 기간

세션 시작 기록과 세션 종료 기록은 담는 정보가 다릅니다.

기록 시점	담기는 정보	장점	한계
세션 시작	5-tuple, 규칙, 시각	연결 즉시 기록, 실시간 탐지	바이트 수·지속 시간 없음
세션 종료	위 + 바이트 수, 지속 시간, 종료 사유	데이터 양 분석 가능	긴 세션은 끝날 때까지 기록 안 됨

장시간 유지되는 연결(C2, 터널)은 종료 기록만 쓰면 세션이 끝날 때까지 로그가 없습니다. 일부 제품은 긴 세션을 주기적으로 중간 기록하는 기능을 제공합니다.

---

3. 주요 특징

• 로그 양과 증거 가치는 반비례하는 경향이 있습니다. 외부 기본 차단 로그는 양이 가장 많고 개별 가치는 낮은 반면, 서버 Outbound 허용 로그는 양이 적고 가치가 높습니다. 저장 용량을 가치가 높은 로그에 우선 배분합니다.
• 속도 제한은 누락을 만듭니다. 제한을 넘은 이벤트는 기록되지 않으므로, 로그 건수를 공격 규모로 그대로 해석하면 안 됩니다.
• 시간 정확도는 로그의 일부입니다. NTP 동기화와 시간대 표기가 맞지 않으면 다른 장비와 연결할 수 없습니다.
• 로깅 수준 옵션은 도구마다 다릅니다. ufw는 off, low, medium, high, full 단계가 있고, 단계가 높을수록 더 많은 패킷을 기록합니다. firewalld는 --set-log-denied로 거부 패킷 기록 범위(all, unicast, broadcast, multicast, off)를 정합니다.

---

4. 예시

로깅 설정을 확인하고, 규칙별 로깅 여부를 점검하는 실습 예시입니다(값은 환경마다 다름).

# Ubuntu (ufw): 현재 로깅 수준 확인
sudo ufw status verbose | grep -i logging

# Rocky (firewalld): 거부 패킷 로깅 범위 확인
sudo firewall-cmd --get-log-denied

# 공통 (nftables): log 문이 있는 규칙과 없는 규칙 구분
sudo nft list ruleset | grep -c ' log '
sudo nft list ruleset | grep -E 'accept|drop|reject' | grep -v ' log '

점검 결과는 다음처럼 정리해 로깅 공백을 찾습니다.

# 로깅 점검표 형식 예시
규칙 이름               동작    로그     판단
WEB-IN-443              allow   시작     종료(바이트) 기록 추가 검토
SRV-EGRESS-UPDATE       allow   없음     ← 서버 Outbound 증거 공백, 로깅 필요
USERS-WEB               allow   없음     프록시 로그로 대체 가능 여부 확인
DEFAULT-DROP            drop    있음     속도 제한 값 확인

---

5. 보안 관점

• 로깅 설정 자체가 공격 대상입니다. 방화벽 관리 권한을 얻은 공격자는 로그를 끄거나 전송 대상을 바꿀 수 있습니다. 로깅 설정 변경은 알림 대상으로 둡니다.
• 로그는 장비 밖(SIEM·로그 서버)에 원격 보관해야 장비 침해·재부팅·저장 공간 부족에도 남습니다.
• 개인정보가 포함될 수 있는 URL·사용자 이름 필드는 보관 기간과 접근 권한을 정해 관리합니다.
• 보관 기간은 조사 가능 기간입니다. 침해는 발견까지 오래 걸리는 경우가 많아, 짧은 보관은 조사 불가로 이어질 수 있습니다.

---

6. SOC 관점

관제자가 확인할 질문

• 이 사건에 필요한 로그를 남기도록 설정된 규칙이 있었는가? "로그 없음"은 트래픽 없음인가, 기록 안 함인가?
• 수집 경로에 공백 구간은 없는가? 장비별 시간당 로그 건수를 기준선과 비교해 급감·중단 구간을 찾습니다.
• 속도 제한이나 요약 기록 때문에 건수가 실제보다 적게 보일 가능성을 결론에 반영했는가?

로그 수집 이상	가능한 원인
특정 장비 로그가 0건	전송 장애, 로깅 비활성화, 장비 장애
특정 규칙 로그만 사라짐	규칙 로깅 옵션 변경, 규칙 순서 변경
로그 시각이 몇 분씩 어긋남	NTP 미동기화, 시간대 설정 차이

오탐 주의: 로그 급감이 모두 공격자의 은폐는 아닙니다. 대부분은 수집 경로 장애나 설정 변경입니다. 다만 원인을 확인하기 전까지 그 구간은 "관제 공백"으로 기록해 둡니다.

---

7. 핵심 정리

• Firewall Logging은 사고 조사에 필요한 질문에서 거꾸로 설계합니다.
• 세션 시작 로그는 즉시성, 세션 종료 로그는 바이트 수·지속 시간을 제공합니다.
• 로그 양과 증거 가치를 따져 저장 자원을 배분하고, 속도 제한으로 인한 누락을 인지합니다.
• 로깅 설정 변경, 수집 공백, 시간 불일치는 그 자체로 관제 대상입니다.
• 원격 보관과 충분한 보관 기간이 있어야 사후 조사가 가능합니다.