📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 277편
이전 글: 276. IPS란 무엇인가 · 다음 글: 278. Network-based IDS
1. 개념
IDS와 IPS는 같은 탐지 엔진과 같은 규칙 문법을 쓰는 경우가 많습니다. Suricata와 Snort는 설정만 바꾸면 IDS로도 IPS로도 동작합니다. 두 시스템의 차이는 탐지 능력이 아니라 탐지한 뒤 무엇을 할 수 있는가, 그리고 그 결과 어떤 운영 원칙이 필요한가에 있습니다.
배치 위치(대역 외 / 인라인)와 장비 구조 비교는 04 영역 188. IDS 동작 구조, 189. IPS 동작 구조에서 다뤘으므로, 이 글은 탐지 결정과 Alert 해석의 차이를 비교합니다.
| 비교 항목 | IDS | IPS |
|---|---|---|
| 탐지 후 결과 | Alert만 생성 | Alert + 차단(규칙 조치에 따라) |
| 오탐(False Positive) 비용 | 분석 시간 낭비, Alert 피로 | 정상 서비스 차단, 장애 |
| 미탐(False Negative) 비용 | 공격을 모름 | 공격을 모르고 통과시킴 |
| 규칙 운영 방향 | 넓고 민감하게 | 좁고 정확하게 |
| 관제자의 첫 질문 | "이 공격은 성공했는가?" | "차단됐는가, 정상을 막진 않았는가?" |
| 판정 기록(Suricata 예) | alert.action: allowed | alert.action: blocked (drop 규칙 일치 시) |
2. 동작 원리
같은 규칙 한 줄이 두 모드에서 어떻게 다르게 처리되는지 보면 차이가 분명해집니다.
규칙: drop tcp any any -> $HOME_NET 445 (msg:"LOCAL SMB from untrusted"; ... sid:1000201;)
[IDS 모드 센서] [IPS 모드 센서]
복사본 패킷 수신 원본 패킷 수신(판정 전 보류)
↓ 규칙 일치 ↓ 규칙 일치
Alert 기록 (allowed) 패킷 폐기 + Alert 기록 (blocked)
↓ ↓
원본은 이미 목적지 도착 목적지에 도달하지 못함
↓ ↓
관제자: 성공 여부 확인 필요 관제자: 차단 정당성·우회 여부 확인즉 IDS 모드에서 drop 규칙은 사실상 alert 규칙처럼 동작합니다. 반대로 IPS 모드에서도 조치가 alert인 규칙은 차단하지 않습니다. 규칙 조치 × 센서 모드의 조합이 실제 결과를 결정합니다.
| 규칙 조치 | IDS 모드 결과 | IPS 모드 결과 |
|---|---|---|
| alert | Alert, 통과 | Alert, 통과 |
| drop | Alert(allowed), 통과 | Alert(blocked), 폐기 |
| reject | Alert, 응답 전송 여부는 구성에 따름 | Alert, 폐기 + RST/ICMP 응답 |
| pass | 이후 검사 생략 | 이후 검사 생략, 통과 |
IDS 모드에서 reject의 응답 전송은 엔진과 구성에 따라 다를 수 있으므로 사용하는 버전의 문서로 확인합니다.
3. 주요 특징
- 탐지 범위와 차단 범위를 분리하는 운영이 일반적입니다. 전체 규칙 세트는 alert로 넓게 탐지하고, 오탐 가능성이 낮고 영향이 큰 규칙만 drop으로 운영합니다.
- IDS는 사후 분석, IPS는 사전 차단에 강점이 있습니다. IDS는 공격이 지나간 뒤 성공 여부를 따져야 하고, IPS는 공격이 도착하기 전에 끊지만 그 판단이 틀릴 위험을 안습니다.
- 성능 요구가 다릅니다. IDS의 처리 지연은 Alert 지연일 뿐이지만, IPS의 처리 지연은 곧 서비스 지연입니다.
- 한 조직에서 둘을 함께 두는 경우가 많습니다. 경계 구간은 IPS, 내부 구간은 IDS처럼 위험도와 가용성 요구에 따라 나눕니다.
4. 예시
같은 사건이 IDS 모드와 IPS 모드에서 어떻게 다르게 기록되는지 보여 주는 형식 예시입니다(값은 환경마다 다름, Suricata EVE 기준).
# 형식 예시 — IDS 모드 센서 (탐지만)
{"timestamp":"2026-09-30T14:20:05.120001+0900","event_type":"alert","src_ip":"198.51.100.77",
"dest_ip":"192.168.10.30","dest_port":445,"proto":"TCP",
"alert":{"action":"allowed","signature_id":1000201,"signature":"LOCAL SMB from untrusted","severity":2}}
# 형식 예시 — IPS 모드 센서 (차단)
{"timestamp":"2026-09-30T14:20:05.120001+0900","event_type":"alert","src_ip":"198.51.100.77",
"dest_ip":"192.168.10.30","dest_port":445,"proto":"TCP",
"alert":{"action":"blocked","signature_id":1000201,"signature":"LOCAL SMB from untrusted","severity":2}}분석 방법 — 두 이벤트는 alert.action 한 필드만 다르지만 후속 분석은 완전히 다릅니다. allowed라면 대상 서버에 연결이 성립했는지(같은 flow_id의 flow 이벤트 바이트 수, 서버 로그)를 확인해야 하고, blocked라면 해당 출발지의 다른 시도와 정상 업무 여부를 확인합니다.
5. 보안 관점
- IDS만 있는 환경에서는 탐지 후 대응 속도가 방어 수준을 결정합니다. Alert를 확인하고 방화벽 차단까지 걸리는 시간 동안 공격은 계속될 수 있습니다.
- IPS만 믿으면 차단되지 않은 변형 공격을 놓치기 쉽습니다. 차단 규칙은 좁게 운영되므로 탐지 범위가 IDS보다 작을 수 있습니다.
- IPS 장애나 바이패스 전환 시각은 무검사 구간입니다. 이 시간대의 트래픽은 IDS나 흐름 기록으로 사후 확인해야 합니다.
- 공격자는 IPS의 차단 반응을 관찰해 규칙을 추정할 수 있습니다. 차단 방식(조용한 폐기 vs 응답)을 정책으로 정합니다.
6. SOC 관점
관제자가 확인할 질문
- 이 Alert를 만든 센서는 IDS 모드인가 IPS 모드인가? 센서 목록에 모드를 명시해 두면 판단이 빨라집니다.
- 판정이
allowed인 Alert는 성공 여부를,blocked인 Alert는 차단의 정당성과 재시도를 확인했는가? - 같은 사건을 IDS와 IPS가 모두 기록했다면, 두 이벤트를 하나의 사건으로 묶었는가?
Alert 수신
↓ 센서 모드 / alert.action 확인
allowed ─→ 대상 응답·세션 크기·서버 로그로 성공 여부 판단
blocked ─→ 정상 업무 차단 여부 / 같은 출발지의 다른 시도 확인
↓
판단 결과 기록 (정탐·오탐·차단 성공·우회 의심)오탐 주의: IPS의 오탐은 Alert 목록이 아니라 사용자 장애 신고로 먼저 드러나는 경우가 많습니다. 장애 신고와 차단 이벤트 시각을 대조하는 절차를 둡니다. 오탐 판단 기준은 285. False Positive에서 다룹니다.
7. 핵심 정리
- IDS와 IPS는 같은 엔진·규칙을 쓸 수 있으며, 차이는 탐지 후 차단 여부와 그에 따른 운영 원칙입니다.
- 실제 결과는 규칙 조치와 센서 모드의 조합으로 결정되며, IDS 모드의 drop 규칙은 Alert로만 동작합니다.
- IDS 오탐은 분석 비용, IPS 오탐은 서비스 장애라는 다른 비용을 만듭니다.
- 넓은 탐지는 IDS(alert), 확실한 차단은 IPS(drop)로 나누어 운영하는 방식이 일반적입니다.
- 관제자는 판정 필드로
allowed와blocked를 구분하고 각각 다른 후속 질문을 적용합니다.
