📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 278편
이전 글: 277. IDS와 IPS 비교 · 다음 글: 279. Host-based IDS
1. 개념
NIDS(Network-based IDS, 네트워크 기반 침입 탐지 시스템) 는 네트워크 구간을 지나가는 패킷을 관찰해 공격을 탐지하는 IDS입니다. Suricata, Snort, Zeek(탐지보다 메타데이터 기록 중심) 같은 도구가 여기에 속합니다. 센서를 SPAN·TAP에 연결하는 방법과 센서 설치는 04 영역 188. IDS 동작 구조, 194. Suricata에서 다뤘습니다.
이 글은 "NIDS의 Alert가 무엇을 말해 주고, 무엇을 말해 주지 못하는가" 를 탐지 범위의 관점에서 정리합니다.
| NIDS가 볼 수 있는 것 | NIDS가 보기 어려운 것 |
|---|---|
| IP·포트·프로토콜, TCP 플래그 | 암호화된 페이로드 내용(TLS, SSH 등) |
| 평문 프로토콜의 요청·응답 내용 | 센서가 없는 구간의 통신(같은 스위치 내부 등) |
| DNS 질의, HTTP URL·User-Agent | 호스트 안에서 일어난 일(프로세스, 파일 변경) |
| TLS 핸드셰이크 메타데이터(SNI, 인증서) | 공격이 실제로 호스트를 장악했는지 여부 |
| 흐름의 크기·지속 시간 | 패킷 손실로 놓친 부분 |
2. 동작 원리
NIDS Alert의 의미는 센서가 어디에 있는가에 크게 좌우됩니다. 같은 공격이라도 센서 위치에 따라 기록되는 주소와 방향이 달라집니다.
인터넷
↓
[방화벽 외부] ── 센서 A: 방화벽이 막을 트래픽까지 모두 봄 (Alert 많음)
↓ 방화벽 (NAT)
[DMZ] ── 센서 B: 방화벽이 허용한 트래픽만 봄, 목적지는 NAT 후 사설 IP
↓
[내부망] ── 센서 C: 내부 호스트 간 이동(측면 이동)을 봄| 센서 위치 | Alert가 의미하는 것 | 주의점 |
|---|---|---|
| 방화벽 외부 | 인터넷에서 시도된 공격 | 방화벽에서 차단될 시도도 포함 — 긴급도 판단 시 방화벽 로그 확인 |
| 방화벽 내부·DMZ | 방화벽을 통과해 서버에 도달한 공격 | 목적지 IP가 NAT 변환 후 주소 |
| 내부망 | 내부 호스트의 이상 행위, 확산 | 출발지가 내부 IP이면 감염 호스트 가능성 |
3. 주요 특징
- 에이전트 설치가 필요 없습니다. 네트워크 한 지점에서 여러 호스트를 한꺼번에 관찰할 수 있어, 에이전트를 설치할 수 없는 장비(프린터, IoT, 네트워크 장비)까지 볼 수 있습니다.
- 호스트에 흔적을 남기지 않습니다. 대역 외 센서는 공격자에게 잘 드러나지 않습니다.
- 재조립 방식의 차이가 탐지 결과에 영향을 줍니다. 조각난 IP 패킷이나 겹치는 TCP 세그먼트를 센서와 목적지 OS가 다르게 재조립하면, 센서가 본 내용과 호스트가 받은 내용이 달라질 수 있습니다. 엔진은 대상 OS 유형별 재조립 정책을 설정할 수 있게 해 이를 줄입니다.
- 패킷 손실은 조용한 미탐을 만듭니다. 센서 처리량을 넘는 트래픽은 버려지고, 그 안의 공격은 Alert 없이 지나갑니다.
4. 예시
NIDS Alert와 같은 흐름의 메타데이터를 함께 본 형식 예시입니다(값은 환경마다 다름, Suricata EVE 기준, 센서는 DMZ 위치 가정).
# 형식 예시 — alert 이벤트
{"timestamp":"2026-09-30T09:12:40.551203+0900","flow_id":55501,"event_type":"alert",
"src_ip":"203.0.113.15","dest_ip":"192.168.20.10","dest_port":80,"proto":"TCP","app_proto":"http",
"alert":{"action":"allowed","signature_id":1000301,"signature":"LOCAL suspicious admin path request","severity":2}}
# 형식 예시 — 같은 flow_id의 http 이벤트
{"flow_id":55501,"event_type":"http","http":{"hostname":"www.example.com","url":"/admin/setup.php",
"http_method":"GET","status":404,"length":0}}분석 방법 — NIDS는 요청만이 아니라 응답도 봅니다. 위 예시처럼 같은 흐름의 응답 코드가 404라면 요청한 경로가 서버에 없었다는 뜻이므로 긴급도가 낮아집니다. 반대로 200 응답과 큰 응답 크기라면 추가 확인이 필요합니다.
실습 예시 — 센서의 패킷 손실 여부를 확인합니다(Rocky/Ubuntu 공통, 패키지 기본 경로 기준).
sudo grep -E "capture.kernel_(packets|drops)" /var/log/suricata/stats.log | tail -4capture.kernel_drops가 계속 증가한다면 그 시간대는 탐지가 불완전했을 수 있습니다.
5. 보안 관점
- 암호화 트래픽 비중이 커질수록 NIDS의 내용 기반 탐지 범위는 줄어듭니다. SNI·인증서·JA3 같은 메타데이터 탐지와 호스트 탐지를 함께 써야 합니다.
- 센서 위치 설계가 곧 탐지 범위 설계입니다. 서버 간 동서(East-West) 트래픽을 보지 못하면 내부 확산을 놓칩니다.
- 공격자는 조각화, 비표준 포트, 인코딩으로 NIDS 규칙을 피하려 할 수 있습니다. 엔진의 정규화·재조립 설정을 유지합니다.
6. SOC 관점
관제자가 NIDS Alert를 볼 때 확인할 질문
- 이 Alert를 만든 센서는 어느 구간에 있는가? 방화벽 외부라면 차단 여부부터 확인합니다.
- 목적지 IP는 NAT 전 주소인가, 후 주소인가? 실제 자산과 매핑했는가?
- 같은 흐름의 응답(HTTP 상태 코드, 응답 크기, flow 바이트)은 무엇을 보여 주는가?
- 해당 시간대에 센서의 패킷 드롭이나 재시작은 없었는가?
NIDS Alert
↓ 센서 위치 확인 → 외부 / DMZ / 내부
↓ 자산 매핑 (NAT 고려)
↓ 같은 flow_id의 응답·메타데이터 확인
↓ 호스트 로그(HIDS·서버 로그)로 실제 영향 확인오탐 주의: 방화벽 외부 센서의 Alert는 대부분 차단될 인터넷 배경 소음입니다. 긴급도는 내부 센서·호스트 흔적과 함께 판단합니다. 호스트 쪽 탐지는 279. Host-based IDS, Alert 필드별 분석은 02 영역 96. IDS Alert의 Port를 참고합니다.
7. 핵심 정리
- NIDS는 네트워크 구간의 패킷을 관찰해 공격을 탐지하며, 에이전트 없이 여러 호스트를 볼 수 있습니다.
- 센서 위치에 따라 같은 공격도 기록되는 주소·방향·긴급도가 달라집니다.
- 암호화 페이로드, 센서 밖 구간, 호스트 내부 행위는 NIDS가 보기 어려운 영역입니다.
- 재조립 차이와 패킷 손실은 NIDS 미탐의 대표 원인입니다.
- NIDS Alert는 같은 흐름의 응답과 호스트 로그로 실제 영향을 확인해야 합니다.
