📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 284편
이전 글: 283. IDS Alert · 다음 글: 285. False Positive
1. 개념
IPS Alert는 IPS가 규칙과 일치하는 트래픽을 발견했을 때 남기는 기록으로, IDS Alert와 달리 "그 트래픽에 무엇을 했는가"(판정) 가 핵심 정보입니다. IDS Alert 분석 절차(283. IDS Alert)를 그대로 적용하되, 차단이 개입하면서 질문이 달라집니다.
| 질문 | IDS Alert | IPS Alert(차단) |
|---|---|---|
| 공격이 도달했는가 | 도달함, 성공 여부 확인 필요 | 차단 시점 이전 데이터만 도달 |
| 관제자의 주 관심 | 성공 여부 | 차단의 정당성, 재시도·우회 |
| 잘못된 판단의 결과 | 공격 방치 | 정상 서비스 차단 |
| 함께 볼 로그 | 방화벽 허용 로그, 서버 로그 | 방화벽 로그, 사용자 장애 신고, 엔진 상태 |
엔진 내부의 판정 처리(NFQUEUE·AF_PACKET)는 04 영역 189. IPS 동작 구조, 스캔 차단 이벤트는 05 영역 236. IPS에서 Scan 차단 이벤트 확인에서 다뤘습니다.
2. 동작 원리
IPS Alert를 해석할 때 가장 중요한 것은 차단이 흐름의 어느 시점에 일어났는가입니다.
TCP 연결의 진행
SYN → SYN/ACK → ACK → [요청 1] → [응답 1] → [요청 2: 공격 패턴] → ...
↓ drop 규칙 일치
요청 2 폐기 + Alert(blocked)
↓
이후 같은 흐름 패킷도 폐기(흐름 단위 차단 시)
→ 요청 1·응답 1은 이미 전달됨. 차단은 "그 이후"만 막는다.- 연결 초반(헤더 조건만으로 일치하는 규칙)에 차단되면 서버에는 사실상 아무것도 도달하지 않습니다.
- 스트림 중간(페이로드 조건)에 차단되면 앞선 데이터는 이미 전달되었습니다. 여러 단계로 나뉜 공격의 경우 앞 단계가 성공했을 수 있습니다.
- Suricata는 IPS 모드에서 스트림 처리 방식(
stream.inline)에 따라 재조립·검사 시점이 달라지며, 세부 동작은 버전 문서로 확인합니다.
3. 주요 특징
판정 기록 방식은 엔진과 설정에 따라 다릅니다.
| 엔진 | 차단 기록 | 참고 |
|---|---|---|
| Suricata | alert 이벤트의 alert.action: blocked, 설정 시 별도 event_type: drop | drop 이벤트 기록 여부는 eve-log 설정에 따름 |
| Snort 3 | alert_json 등의 action 관련 필드 | 값의 표기는 버전·모드별로 다르므로 출력 문서 확인 |
| 상용 IPS | 제품별 action 필드(blocked, dropped, reset 등) | 정규화 시 값 대응표 필요 |
- 차단 = 끝이 아닙니다. 차단은 공격 1회의 실패를 뜻할 뿐, 공격자가 다른 방법을 시도할 가능성은 그대로입니다.
- 오탐 차단의 신호는 IPS 로그가 아닌 곳에서 먼저 나타납니다. 사용자 "접속 불가" 신고, 애플리케이션 오류 증가, 특정 기능만 실패하는 현상이 대표적입니다.
4. 예시
차단 이후 같은 출발지의 행동을 확인하는 흐름을 보여 주는 형식 예시입니다(값은 환경마다 다름, Suricata EVE와 방화벽 로그 가정).
# 형식 예시 — 11:30:02 IPS 차단
{"timestamp":"2026-09-30T11:30:02.004511+0900","event_type":"alert","src_ip":"203.0.113.90",
"dest_ip":"192.168.20.10","dest_port":80,"alert":{"action":"blocked","signature_id":1000801,
"signature":"LOCAL web path traversal pattern in URI","severity":2}}
# 형식 예시 — 11:31~11:33 방화벽 허용 로그 (같은 출발지, 다른 포트)
action=allow srcip=203.0.113.90 dstip=192.168.20.10 dstport=8443 proto=6
action=allow srcip=203.0.113.90 dstip=192.168.20.11 dstport=80 proto=6분석 방법 — IPS는 80번 포트 요청을 차단했지만, 방화벽 로그를 보면 같은 출발지가 다른 포트(8443)와 다른 서버(.11) 로 연결을 이어 갔습니다. 해당 구간이 IPS 검사 대상인지(8443이 TLS라 내용 검사가 불가능한지, .11이 다른 경로인지) 확인해야 합니다. 차단 Alert 한 건이 우회 시도 분석의 출발점이 되는 경우입니다.
5. 보안 관점
- 차단 규칙이 있는 서비스라도 암호화 포트, 다른 경로, 검사 예외 대역으로는 같은 공격이 통과할 수 있습니다.
- 반복 차단되는 출발지는 방화벽이나 동적 차단 목록으로 출발지 단위 차단을 검토합니다. 다만 공유 IP(NAT, 프록시, 클라우드)는 정상 사용자를 함께 막을 수 있습니다.
- IPS가 재시작·바이패스된 시간대는 차단 기록이 없습니다. 차단 Alert가 갑자기 0건이 되면 공격 중단보다 엔진 상태를 먼저 의심합니다.
6. SOC 관점
관제자가 IPS Alert를 볼 때 확인할 질문
- 차단은 흐름의 어느 시점이었고, 그 전에 전달된 데이터는 무엇인가?
- 같은 출발지가 차단 이후 다른 포트·다른 대상·다른 방법으로 시도했는가?
- 차단된 트래픽이 정상 업무일 가능성은 없는가? 같은 시각의 장애 신고는?
- 오탐 차단이라면 누가, 어떤 범위로 예외를 승인하는가?
IPS 차단 Alert
├─ 정상 업무 의심 → 사용자·담당자 확인 → 오탐 확정 시 예외 요청(범위 최소화, 기한)
└─ 공격 의심 → 차단 전 전달 데이터 확인
↓ 같은 출발지의 후속 활동 (방화벽·다른 센서)
↓ 우회 성공 흔적 있으면 사건으로 전환오탐 주의: 오탐 차단을 해결하려고 규칙 전체를 끄면 같은 규칙이 막던 실제 공격도 통과합니다. 예외는 출발지·목적지·URI 등 가장 좁은 범위로 만들고 사유와 기한을 기록합니다. 오탐 처리 기준은 285. False Positive에서 다룹니다.
7. 핵심 정리
- IPS Alert의 핵심은 차단·통과 판정이며, 판정 필드와 기록 방식은 엔진과 설정에 따라 다릅니다.
- 차단은 일치 시점 이후만 막으므로, 그 이전에 전달된 데이터를 확인해야 합니다.
- 차단 후 같은 출발지의 다른 포트·대상·방법 시도를 방화벽 로그 등으로 확인합니다.
- 오탐 차단은 사용자 장애 신고로 먼저 드러나는 경우가 많아 시각 대조가 필요합니다.
- 예외는 가장 좁은 범위로, 사유와 기한을 기록해 적용합니다.
