📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 276편
이전 글: 275. IDS란 무엇인가 · 다음 글: 277. IDS와 IPS 비교
1. 개념
IPS(Intrusion Prevention System, 침입 방지 시스템) 는 IDS처럼 트래픽을 검사해 공격을 탐지하고, 여기에 더해 탐지한 트래픽을 그 자리에서 차단하는 시스템입니다. 트래픽 경로 한가운데(인라인)에 놓여야 차단이 가능합니다. 인라인 배치 구조와 NFQUEUE·AF_PACKET 같은 엔진 내부 구조는 04 영역 157. IPS란 무엇인가와 189. IPS 동작 구조에서 다뤘습니다.
이 글은 06 영역의 관점, 즉 "IPS가 무엇을 근거로 차단을 결정하고, 그 결정이 로그에 어떻게 남으며, 관제자는 그것을 어떻게 읽는가" 에 집중합니다.
| 구분 | 방화벽 차단 | IPS 차단 |
|---|---|---|
| 판단 근거 | 주소·포트·프로토콜·연결 상태 | 페이로드 내용·프로토콜 필드·행위 패턴 |
| 판단 시점 | 연결 시작 시 정책 대조 | 허용된 연결 안에서 패킷·스트림마다 |
| 차단 이유 표현 | 정책(Rule) ID | 시그니처 ID(sid)와 메시지 |
| 잘못된 차단의 원인 | 정책 설계 오류 | 규칙 오탐(False Positive) |
방화벽이 문을 열어 준 트래픽이라도, 그 안에 공격 패턴이 있으면 IPS가 다시 막을 수 있습니다.
2. 동작 원리
IPS의 판단 흐름은 IDS와 같은 탐지 단계를 거친 뒤, 규칙의 조치(action) 에 따라 갈라집니다.
원본 패킷 도착 (인라인)
↓
[디코딩 → 흐름 추적 → 스트림 재조립 → 프로토콜 해석]
↓
[규칙 매칭]
├─ 일치 없음 ─────────────→ 통과(accept)
├─ alert 규칙 일치 ─────────→ Alert 기록 후 통과
├─ drop 규칙 일치 ──────────→ 패킷 폐기 + Alert(blocked)
├─ reject 규칙 일치 ────────→ 폐기 + RST/ICMP 응답 + Alert
└─ pass 규칙 일치 ──────────→ 이후 검사 없이 통과
↓
로그: 판정 결과(allowed / blocked)가 Alert에 함께 기록차단 단위도 중요합니다. 규칙 하나가 일치했을 때 무엇까지 막히는지는 엔진과 조치에 따라 다릅니다.
| 차단 단위 | 의미 | 예 |
|---|---|---|
| 패킷 | 일치한 그 패킷만 폐기 | 개별 패킷 drop |
| 흐름(Flow) | 해당 연결의 이후 패킷 전체 폐기 | Suricata drop(흐름 단위로 적용, 버전 문서 확인), Snort 3 block |
| 출발지 | 일정 시간 해당 IP의 트래픽 폐기 | 제품의 동적 차단 목록, 방화벽 연동 |
오픈소스 엔진의 규칙 조치 이름(drop, reject, pass 등)과 엔진별 차이는 189. IPS 동작 구조의 표를 참고합니다.
3. 주요 특징
- 차단은 되돌리기 어렵습니다. IDS 오탐은 관제자의 시간을 쓰지만, IPS 오탐은 정상 서비스를 끊습니다. 그래서 IPS 규칙은 IDS보다 좁고 정확하게 운영합니다.
- 단계적 전환이 일반적입니다. 새 규칙은 먼저 alert(탐지 전용)로 운영해 오탐 여부를 확인한 뒤 drop으로 바꿉니다.
- IPS 모드로 동작해야 차단됩니다. 센서가 IDS(복사본 관찰) 모드라면 drop 규칙도 Alert만 남깁니다.
- 장애 시 동작이 설계 대상입니다. 엔진이 멈추면 트래픽을 끊을지(Fail-closed), 검사 없이 통과시킬지(Fail-open)를 미리 정합니다.
규칙 도입 흐름 (예)
신규 규칙 → alert 모드로 1~2주 관찰 → Alert 검토(정탐/오탐)
↓ 오탐 없음 ↓ 오탐 있음
drop 전환 + 변경 기록 조건 수정 또는 예외 후 재관찰4. 예시
Suricata가 IPS 모드에서 남기는 차단 Alert의 형식 예시입니다(값은 환경마다 다름, 로컬 규칙 가정).
# 형식 예시 — 로컬 차단 규칙 (Suricata 문법)
drop tcp $EXTERNAL_NET any -> $HOME_NET 8080 (msg:"LOCAL block access to test admin port"; flow:to_server; sid:1000101; rev:1;)# 형식 예시 — eve.json alert 이벤트 (주요 필드만)
{"timestamp":"2026-09-30T11:04:22.310512+0900","flow_id":987654321,"event_type":"alert",
"src_ip":"203.0.113.40","src_port":51022,"dest_ip":"192.168.10.20","dest_port":8080,"proto":"TCP",
"alert":{"action":"blocked","signature_id":1000101,"rev":1,
"signature":"LOCAL block access to test admin port","severity":3}}분석 방법 — 같은 규칙이 IDS 모드 센서에 적재되어 있다면 동일한 Alert가 "action":"allowed"로 남습니다. 즉 규칙의 조치와 실제 판정은 다를 수 있으므로, 차단 여부는 규칙 원문이 아니라 Alert의 alert.action 값으로 판단합니다. 설정에 따라 폐기된 패킷이 event_type: drop 이벤트로 따로 기록되기도 합니다.
5. 보안 관점
- IPS는 알려진 공격을 실시간으로 무력화할 수 있어 패치가 늦어진 취약점의 임시 보호(가상 패치)로 활용됩니다.
- 차단 사실은 공격자에게도 정보가 됩니다. reject 응답이나 연결 끊김 패턴으로 IPS 존재를 추정하고 우회를 시도할 수 있습니다.
- 암호화 트래픽 안의 공격은 IPS도 볼 수 없습니다. TLS 복호화 구간이 없다면 차단 범위는 헤더·메타데이터 수준으로 제한됩니다.
pass규칙과 검사 예외 대역은 차단의 사각지대입니다. 예외 목록은 사유와 함께 관리하고 주기적으로 검토합니다.
6. SOC 관점
관제자가 IPS 이벤트를 받으면 확인할 질문
- 이 이벤트의 판정은
blocked인가allowed인가? 차단이 실제로 일어났는지부터 확인합니다. - 차단 단위는 패킷인가 흐름인가? 첫 패킷 이전에 이미 전달된 데이터는 없는가?
- 같은 출발지가 차단 이후 다른 포트·다른 경로로 재시도했는가? 방화벽 로그로 확인합니다.
- 차단 시각에 사용자 장애 신고가 있었는가? 있다면 오탐 차단 가능성을 먼저 검토합니다.
| 상황 | 해석 | 다음 조치 |
|---|---|---|
| blocked + 외부 출발지 + 알려진 공격 규칙 | 차단 성공 가능성 높음 | 반복 여부·다른 대상 시도 확인 |
| blocked + 내부 업무 시스템 간 통신 | 오탐 차단 의심 | 규칙 조건 검토, 예외 협의 |
| allowed + drop 규칙 | IDS 모드 또는 설정 문제 | 엔진 모드 확인 |
오탐 주의: "차단했으니 끝"으로 종결하지 않습니다. 차단된 요청이 여러 번의 시도 중 하나였다면, 차단되지 않은 다른 시도가 있었는지 확인해야 합니다. IPS Alert의 상세 분석은 284. IPS Alert, 스캔 차단 이벤트는 05 영역 236. IPS에서 Scan 차단 이벤트 확인에서 다룹니다.
7. 핵심 정리
- IPS는 트래픽 경로에 인라인으로 놓여 탐지한 공격을 즉시 차단하는 시스템입니다.
- 방화벽이 주소·포트로 판단한다면, IPS는 허용된 연결 안의 내용과 패턴으로 판단합니다.
- 규칙 조치(alert·drop·reject·pass)와 차단 단위(패킷·흐름·출발지)에 따라 차단 범위가 달라집니다.
- 오탐 차단은 서비스 장애로 이어지므로 탐지 전용 운영 후 차단으로 전환하는 단계적 도입이 일반적입니다.
- 차단 여부는 규칙 원문이 아니라 Alert의 판정 필드(
blocked/allowed)로 확인합니다.
