📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 285편
이전 글: 284. IPS Alert · 다음 글: 286. False Negative

1. 개념

False Positive(오탐) 는 실제로는 공격이나 정책 위반이 아닌 트래픽을 IDS·IPS가 공격으로 판단해 Alert를 만든 경우입니다. 오탐은 관제자의 시간을 소모하고, 누적되면 진짜 Alert를 묻어 버립니다. IPS에서는 정상 서비스를 끊는 장애가 됩니다.

실무에서는 오탐과 비슷하지만 다른 개념을 구분하는 것이 중요합니다.

구분규칙 일치가 정확한가위협인가예처리 방향
오탐(False Positive)아니오 — 의도와 다른 대상에 일치아님문서 파일 안의 문자열이 공격 패턴과 우연히 같음규칙 조건 수정
정상 업무 정탐(Benign True Positive)예 — 규칙 의도대로 일치아님(승인된 활동)승인된 취약점 점검 도구의 스캔출발지 단위 억제·예외
정탐(True Positive)예예외부의 실제 공격 시도대응

"규칙이 틀렸다"와 "규칙은 맞지만 이 활동은 괜찮다"는 다른 문제이므로, 처리 방법도 다릅니다.


2. 동작 원리

오탐은 대부분 다음 원인 중 하나에서 생깁니다.

오탐 원인
 ├─ 조건이 너무 넓음      content 하나, 위치 제한 없음, 방향 조건 없음
 ├─ 변수 설정 오류        HOME_NET에 내부 대역 누락 → 내부 통신이 "외부"로 판단
 ├─ 환경 불일치           Windows 대상 규칙이 Linux 서버 트래픽에 일치
 ├─ 정상 도구의 특성      모니터링·백업·보안 도구가 공격과 비슷한 패턴 생성
 └─ 프로토콜 해석 차이    비표준 구현 장비의 트래픽을 이상으로 판단

오탐 확정은 근거로 합니다. "평소에 많이 뜨는 Alert"라는 이유만으로는 오탐이라고 할 수 없습니다.

확인 항목오탐을 뒷받침하는 근거
페이로드·필드일치한 문자열이 공격 맥락이 아닌 위치(파일 본문, 정상 파라미터)에 있음
출발지·목적지자산 담당자가 확인한 정상 시스템 간 통신
대상 환경규칙이 노리는 제품·버전이 대상에 없음
반복 패턴정해진 주기·정해진 호스트에서만 발생, 업무 일정과 일치

3. 주요 특징

오탐을 줄이는 방법은 범위가 좁은 것부터 검토합니다.

방법범위예(Suricata·Snort 공통 개념)주의점
suppress특정 sid × 특정 IPthreshold 설정 파일의 suppress그 IP에서의 실제 공격도 안 보임
threshold·event_filterAlert 발생 횟수일정 시간 N건만 기록건수 정보가 줄어듦
규칙 수정규칙 조건 자체flow·위치·필드 조건 추가 후 rev 증가원본 규칙 갱신 시 덮어쓰기 주의
변수 수정모든 규칙HOME_NET 보완영향 범위가 넓어 검증 필요
규칙 비활성화규칙 전체disable 목록에 sid 추가최후 수단, 탐지 공백 발생
  • 가장 좁은 범위의 방법을 먼저 선택합니다. 규칙 비활성화는 해당 위협에 대한 탐지를 통째로 포기하는 것입니다.
  • 배포 규칙(ET Open 등)을 직접 수정하면 다음 갱신 때 되돌아갑니다. 갱신 도구의 수정 목록 기능이나 로컬 규칙으로 관리합니다(190. Signature Detection).

4. 예시

승인된 점검 서버에서만 반복되는 Alert를 억제하는 설정의 형식 예시입니다(값은 환경마다 다름, Suricata threshold.config 문법).

# 형식 예시 — 점검 서버 192.168.10.5에서 출발하는 sid 1000901 Alert만 억제
# 사유: 승인된 주간 취약점 점검(변경 요청 번호 기록), 검토 기한: 2026-12-31
suppress gen_id 1, sig_id 1000901, track by_src, ip 192.168.10.5
# 형식 예시 — 규칙 수정: 위치·방향 조건을 추가하고 rev 증가
# 수정 전
alert tcp any any -> $HOME_NET any (msg:"LOCAL cmd string"; content:"cmd"; sid:1000902; rev:1;)
# 수정 후
alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL cmd parameter in URI"; flow:established,to_server; http.uri; content:"cmd="; nocase; sid:1000902; rev:2;)

분석 방법 — 첫 번째는 "규칙은 맞지만 이 출발지는 승인됨"(정상 업무 정탐)에 대한 처리이고, 두 번째는 "규칙이 너무 넓음"(오탐)에 대한 처리입니다. 원인에 맞는 방법을 골라야 탐지 범위를 불필요하게 잃지 않습니다. 설정 파일 위치와 적용 절차는 04 영역 192. IDS Rule을 참고합니다.


5. 보안 관점

  • 억제·예외 목록은 공격자가 숨기 좋은 곳입니다. 억제된 IP가 침해되면 그 IP에서 나가는 공격은 보이지 않습니다.
  • 오탐 튜닝이 쌓이면 탐지 범위가 조용히 줄어듭니다. 억제 목록은 기한과 재검토 주기를 둡니다.
  • 오탐이 많다는 이유로 Alert를 무시하는 습관이 생기면, 같은 규칙의 실제 공격도 놓치게 됩니다.

6. SOC 관점

관제자가 오탐을 판단할 때 질문

  • 오탐이라고 판단한 근거(페이로드, 자산 확인, 환경 불일치)를 기록했는가?
  • 이것은 오탐인가, 정상 업무 정탐인가? 처리 방법이 다른가?
  • 제안하는 튜닝은 가장 좁은 범위인가? 무엇을 더는 탐지하지 못하게 되는가?
반복 Alert 발견
   ↓ 근거 수집 (페이로드·자산·환경·업무 일정)
   ↓ 분류: 오탐 / 정상 업무 정탐 / 정탐
오탐          → 규칙 조건 수정 요청
정상 업무 정탐 → 출발지 단위 suppress (사유·기한 기록)
   ↓ 적용 후 같은 규칙의 다른 출발지 Alert는 계속 발생하는지 확인

오탐 주의: "이 Alert는 늘 오탐이다"라는 경험은 대상이 바뀌면 틀립니다. 억제되지 않은 새 출발지·새 대상에서 같은 sid가 나오면 처음부터 판단합니다. 반대 방향의 오류는 286. False Negative에서 다룹니다.


7. 핵심 정리

  • 오탐은 실제 위협이 아닌 트래픽에 Alert가 생성된 경우이며, IDS에서는 분석 부담, IPS에서는 장애를 만듭니다.
  • 규칙이 틀린 오탐과, 규칙은 맞지만 승인된 활동인 정상 업무 정탐을 구분합니다.
  • 오탐은 넓은 조건, 변수 오류, 환경 불일치, 정상 도구 특성, 프로토콜 해석 차이에서 주로 생깁니다.
  • 튜닝은 suppress·threshold·규칙 수정·변수 수정·비활성화 중 가장 좁은 범위를 우선합니다.
  • 판단 근거와 억제 사유·기한을 기록하고 억제 목록을 주기적으로 재검토합니다.
profile
코드에 숨겨진 위협을 읽고 AI로 보안의 미래를 설계합니다. 프론트엔드 개발 경험을 자산 삼아 더 견고하고 지능적인 보안 운영 시스템을 구축해 나가는 과정을 기록합니다

0개의 댓글