📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 296편
이전 글: 295. IDS Alert의 Source/Destination 분석 · 다음 글: 297. IDS Alert와 Packet 연계
1. 개념
Alert와 Firewall Log 연계는 IDS가 "무엇이 의심되는가"를 알려 준 Alert를, 방화벽이 기록한 "그 연결이 허용되었는가, 얼마나 오갔는가"와 연결해 판단하는 것입니다. 두 장비는 서로 모르는 것을 알려 줍니다.
| 정보 | IDS Alert | Firewall Log |
|---|---|---|
| 무엇이 의심되는가 | 규칙 sid·msg | 없음(정책 판정만) |
| 연결이 허용되었는가 | 센서 위치에 따라 불명확 | 허용·차단 판정 |
| NAT 전후 주소 | 센서가 본 한쪽만 | 변환 전·후 모두(설정 시) |
| 세션 전체 크기·지속 시간 | flow 이벤트(Suricata) | 세션 종료 로그의 바이트·시간 |
| 반복 시도 전체 규모 | 임계치 설정에 따라 일부 | 연결 단위 전체 |
방화벽 로그 필드 구조와 분석은 272. Firewall Log 구조, 273. Firewall Log 분석에서 다뤘습니다.
2. 동작 원리
두 로그를 잇는 연계 키와 순서입니다.
IDS Alert: 시각 T, src A:pa → dest B:pb, proto
↓
[1] 시각 맞추기 두 장비의 시간대(UTC/KST)·NTP 동기화 확인, T ± 수 초 범위로 검색
↓
[2] 주소 맞추기 센서 위치 기준으로 NAT 전/후 결정 → 방화벽 로그의 원래·변환 주소 중 해당 필드로 검색
↓
[3] 5-tuple 맞추기 출발지 포트까지 일치하면 같은 연결로 확정
↓
[4] 판정·통계 읽기 허용/차단, 송수신 바이트, 지속 시간, 종료 사유
↓
결합 판단: 시도 / 차단됨 / 통신 성립 / 대량 전송Community ID는 5-tuple을 정해진 방식으로 해시한 문자열로, 장비가 달라도 같은 연결이면 같은 값이 나옵니다. Suricata·Zeek 등은 설정으로 이 값을 기록할 수 있어, 지원하는 장비끼리는 복잡한 조건 없이 한 값으로 연결할 수 있습니다. 방화벽이 지원하지 않으면 SIEM에서 5-tuple로 계산해 붙이는 방식도 쓰입니다. 단, NAT로 주소가 바뀐 구간끼리는 값이 달라집니다.
3. 주요 특징
두 장비의 판정 조합에 따라 해석이 달라집니다.
| IDS Alert | Firewall 판정 | 해석 | 다음 확인 |
|---|---|---|---|
| 있음 | 허용 + 세션 바이트 큼 | 의심 트래픽이 실제로 오감 | 응답 내용·호스트 흔적 |
| 있음 | 허용 + 바이트 작음·즉시 종료 | 연결됐지만 교환 적음 | 서버 응답 코드 |
| 있음(방화벽 외부 센서) | 차단 | 경계에서 막힌 시도 | 반복·다른 포트 시도 여부 |
| 없음 | 허용 + 비정상 패턴 | IDS 미탐 또는 암호화 | 흐름 분석·호스트 로그 |
| 있음 | 로그 없음 | 센서와 방화벽 경로 불일치 또는 로그 누락 | 네트워크 경로·수집 상태 |
방화벽 로그의 장점은 전체 규모입니다. IDS는 임계치 설정 때문에 Alert를 1건만 남겼더라도, 방화벽 로그에는 같은 출발지의 연결이 모두 남아 있어 시도 횟수·대상 범위·기간을 복원할 수 있습니다.
4. 예시
같은 연결을 두 장비 로그에서 연결한 형식 예시입니다(값은 환경마다 다름, 센서는 방화벽 내부 DMZ 위치 가정).
# 형식 예시 — IDS Alert (KST, NAT 후 사설 주소)
{"timestamp":"2026-09-30T16:12:07.330100+0900","event_type":"alert","src_ip":"203.0.113.120","src_port":52110,
"dest_ip":"192.168.20.10","dest_port":443,"proto":"TCP","community_id":"1:(해시값)",
"alert":{"signature_id":1002001,"signature":"LOCAL suspicious TLS SNI to internal web"}}
# 형식 예시 — 방화벽 세션 종료 로그 (UTC, 원래 주소와 변환 주소 모두 기록)
2026-09-30T07:12:31Z action=allow srcip=203.0.113.120 srcport=52110 dstip=198.51.100.10 dstport=443
tran_dstip=192.168.20.10 duration=24 sentbyte=1840 rcvdbyte=2210500 policyid=12분석 방법 — 시각은 UTC 07:12 = KST 16:12로 일치하고, 방화벽의 변환 후 목적지(tran_dstip)와 출발지 포트 52110이 IDS Alert와 같으므로 같은 연결입니다. 방화벽 로그를 보면 연결은 허용되었고, 24초 동안 서버가 약 2.2MB를 보냈습니다. 바이트 방향의 기준(누가 보낸 것이 sent인가)은 제품 문서로 확인해야 합니다. 이 연결은 "시도"가 아니라 실제 데이터 교환이 있었다고 볼 수 있어 우선순위가 올라갑니다.
5. 보안 관점
- 연계 없이 IDS Alert만 보면 차단된 시도를 과대평가하거나, 성립된 통신을 과소평가하게 됩니다.
- 장비 간 시각이 맞지 않으면 연계 자체가 실패합니다. 모든 보안장비와 수집기는 같은 NTP 기준을 쓰고, SIEM은 시간대를 통일해 저장합니다.
- 방화벽 로그에 NAT 변환 정보가 없으면 내부 호스트를 특정할 수 없습니다. 로그 설정에 변환 필드 포함 여부를 확인합니다.
6. SOC 관점
관제자가 연계할 때 확인할 질문
- 두 로그의 시간대는 같은가? 몇 초 정도의 차이를 허용해 검색했는가?
- IDS의 주소는 NAT 전인가 후인가? 방화벽 로그의 어느 필드와 비교해야 하는가?
- 방화벽 판정과 세션 바이트·지속 시간은 IDS Alert의 의미를 어떻게 바꾸는가?
- 같은 출발지의 전체 연결 규모(대상 수·포트 수·기간)는?
IDS Alert
↓ 시각(시간대 보정) + 주소(NAT 보정) + 출발지 포트
Firewall 세션 로그 조회
├─ 차단 → 시도 수준, 반복·우회 확인
├─ 허용 + 작은 교환 → 응답 코드 확인
└─ 허용 + 큰 교환 → 호스트·응답 내용 확인, 우선순위 상향
↓
같은 출발지 전체 연결 집계 → 범위 기록오탐 주의: 방화벽 "허용"은 정책상 허용이라는 뜻이지 정상이라는 뜻이 아닙니다. 반대로 IDS Alert가 있어도 방화벽이 차단했다면 영향은 제한적입니다. 두 판정을 함께 적어 둡니다. 패킷 수준 확인은 297. IDS Alert와 Packet 연계에서 이어집니다.
7. 핵심 정리
- IDS Alert는 "무엇이 의심되는가", 방화벽 로그는 "허용되었는가, 얼마나 오갔는가"를 알려 줍니다.
- 연계 키는 시각(시간대 보정), NAT 전후 주소, 출발지 포트를 포함한 5-tuple이며, Community ID로 단순화할 수 있습니다.
- 두 장비의 판정 조합(Alert 유무 × 허용·차단 × 세션 크기)에 따라 해석과 우선순위가 달라집니다.
- 방화벽 로그로 IDS 임계치 때문에 줄어든 전체 시도 규모를 복원할 수 있습니다.
- 장비 간 NTP 동기화와 NAT 변환 필드 기록이 연계의 전제 조건입니다.
