📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 283편
이전 글: 282. Signature Rule · 다음 글: 284. IPS Alert
1. 개념
IDS Alert는 IDS 규칙이 트래픽과 일치했을 때 생성되는 기록입니다. 275. IDS란 무엇인가에서 Alert의 형식과 "Alert는 의심이지 사건이 아니다"라는 원칙을 봤다면, 이 글은 Alert 한 건을 받아 판단을 내리기까지의 분석 절차를 다룹니다. Alert가 장비에서 SIEM까지 전달되는 경로는 04 영역 196. 보안장비 Alert에서 다뤘습니다.
Alert의 필드는 성격에 따라 두 묶음으로 나누어 읽습니다.
| 묶음 | 필드(Suricata EVE 예) | 답하는 질문 |
|---|---|---|
| 규칙 정보 | alert.signature_id, alert.rev, alert.signature, alert.category, alert.severity | 무엇이 의심되는가 |
| 트래픽 정보 | timestamp, src_ip, src_port, dest_ip, dest_port, proto, app_proto | 누가, 누구에게, 언제 |
| 연결 정보 | flow_id, community_id(설정 시), in_iface | 다른 로그와 어떻게 연결하는가 |
| 증거 정보 | payload, packet, http·tls 메타데이터(설정 시) | 실제로 무엇이 오갔는가 |
| 판정 정보 | alert.action | 통과했는가, 차단됐는가 |
2. 동작 원리
Alert 한 건의 분석 절차(트리아지, Triage)입니다.
[1] 규칙 확인 sid:rev → 규칙 원문, 탐지 의도, classtype
↓
[2] 방향·자산 확인 외부→내부 / 내부→외부 / 내부→내부, 대상 자산 역할·중요도
↓
[3] 반복·범위 확인 같은 sid·출발지의 건수, 대상 수, 첫 발생·마지막 발생
↓
[4] 증거 확인 페이로드, 같은 flow의 응답(HTTP 상태·바이트), 방화벽 허용 여부
↓
[5] 영향 판단 대상이 취약한 환경인가, 호스트에 흔적이 있는가
↓
[6] 판정·기록 오탐 / 정탐(시도·실패) / 정탐(성공 의심) → 종결 또는 에스컬레이션1~3단계는 수 분 안에 끝나는 1차 분류이고, 4~5단계는 필요한 Alert에만 적용하는 심층 확인입니다. 모든 Alert에 5단계까지 적용하면 처리량을 감당할 수 없으므로, 1차 분류에서 우선순위를 정합니다.
3. 주요 특징
Alert의 우선순위는 규칙의 심각도만으로 정하지 않습니다. 장비가 주는 severity는 규칙 분류의 값이고, 실제 위험은 환경에 따라 다릅니다.
| 판단 요소 | 우선순위를 높이는 경우 | 우선순위를 낮추는 경우 |
|---|---|---|
| 방향 | 내부→외부, 내부→내부 | 외부→내부 중 방화벽 외부 센서 |
| 대상 자산 | 인증 서버, DB, 외부 공개 서버 | 테스트 서버, 폐기 예정 장비 |
| 대상 환경 | 규칙이 노리는 OS·서비스와 일치 | 해당 서비스 없음 (예: Windows 공격이 Linux 대상) |
| 응답 | 200 응답, 큰 응답 크기, 연결 지속 | 연결 거부, 404, 즉시 종료 |
| 출발지 | 내부 호스트, 과거 사건 관련 IP | 등록된 취약점 스캐너 |
- 반복 Alert는 묶어서 봅니다. 같은 출발지·같은 sid의 Alert 500건은 대개 사건 1건입니다. 묶을 때는 첫 발생 시각, 마지막 발생 시각, 건수, 대상 수를 남깁니다.
- 서로 다른 sid가 순서대로 나타나면 의미가 커집니다. 스캔 → 취약점 시도 → 내부→외부 이상 통신 순서라면 단계가 진행 중일 수 있습니다.
4. 예시
같은 출발지에서 발생한 Alert를 묶어 요약하는 실습 예시입니다(Suricata 센서, Rocky/Ubuntu 공통, 값은 환경마다 다름).
# sid·출발지별 건수와 첫/마지막 시각 요약
sudo jq -r 'select(.event_type=="alert") | [.alert.signature_id, .src_ip, .timestamp] | @tsv' \
/var/log/suricata/eve.json \
| sort -k1,1 -k2,2 -k3,3 \
| awk -F'\t' '{k=$1" "$2; c[k]++; if(!(k in f)) f[k]=$3; l[k]=$3}
END {for (k in c) print c[k], k, f[k], l[k]}' | sort -rn | head# 형식 예시 — 요약 결과 (건수 sid 출발지 첫발생 마지막발생)
412 1000601 203.0.113.51 2026-09-30T02:10:04 2026-09-30T02:14:40
3 1000602 203.0.113.51 2026-09-30T02:15:12 2026-09-30T02:15:30
1 1000701 192.168.10.61 2026-09-30T02:20:01 2026-09-30T02:20:01분석 방법 — 첫 줄은 짧은 시간 대량 발생으로 자동화된 시도 패턴입니다. 둘째 줄은 같은 출발지가 다른 규칙을 3건 일으켰으므로 첫 줄 이후 단계가 바뀌었는지 확인합니다. 셋째 줄은 건수는 1건이지만 내부 출발지라 우선순위가 높을 수 있습니다. 건수가 많다고 중요한 것이 아닙니다.
5. 보안 관점
- Alert가 너무 많으면 관제자는 중요한 1건을 놓칩니다(Alert 피로). 튜닝과 묶음 규칙은 탐지 성능의 일부입니다.
- 공격자가 대량의 가짜 Alert를 유발해 진짜 공격을 묻으려 할 수 있습니다. 대량 Alert 발생 시간대의 다른 소량 Alert를 따로 확인합니다.
- Alert만으로 종결하지 않고, 판단 근거(규칙, 증거, 자산 정보)를 기록해야 이후 같은 Alert의 판단이 빨라집니다.
6. SOC 관점
관제자가 Alert 판단 결과를 기록할 때 포함할 항목
- 판정: 오탐 / 정탐-시도(실패) / 정탐-성공 의심 / 정상 업무(의도된 활동)
- 근거: 규칙 의도, 방향·자산, 응답·흔적 확인 결과
- 범위: 관련 IP, 대상 수, 기간, 묶은 Alert 건수
- 조치: 종결, 차단 요청, 에스컬레이션, 튜닝 요청
Alert 큐
↓ 1차 분류(규칙·방향·자산·반복)
낮음 → 묶음 처리·기록 후 종결
높음 → 심층 확인(증거·응답·호스트)
↓
성공 의심 → 에스컬레이션 (사건 분석 전환)
시도·실패 → 차단 검토·감시 강화
오탐 → 튜닝 요청 (오탐 처리 절차)오탐 주의: 정상 업무(취약점 점검, 모니터링)로 발생한 Alert는 "규칙은 정확히 일치했지만 위협은 아닌" 경우입니다. 오탐과 구분해 기록하면 튜닝 방향이 달라집니다. 이 구분은 285. False Positive, 출발지·목적지 분석은 295. IDS Alert의 Source/Destination 분석에서 이어집니다.
7. 핵심 정리
- IDS Alert는 규칙 정보, 트래픽 정보, 연결 정보, 증거 정보, 판정 정보로 나누어 읽습니다.
- 분석은 규칙 확인 → 방향·자산 → 반복·범위 → 증거 → 영향 → 판정·기록 순서로 진행합니다.
- 우선순위는 장비 severity가 아니라 방향, 자산, 대상 환경, 응답, 출발지를 함께 보고 정합니다.
- 반복 Alert는 묶고, 서로 다른 규칙이 순서대로 나타나는 흐름에 주목합니다.
- 판정 결과는 근거·범위·조치와 함께 기록해 이후 분석과 튜닝에 활용합니다.
