방화벽·IPS·Snort

방화벽·IPS의 오탐이 운영을 잠식하는가

이 모듈은 방화벽 정책의 위험 6유형과 IPS 운영의 오탐·미탐 관리를 다룹니다. P2에서 본 계층별 솔루션 중 방화벽과 IPS가 운영 부채의 큰 몫을 차지합니다 — 방화벽은 정책이 자라면서 위험 정책이 누적되고, IPS는 오탐이 운영자를 무력화합니다. P3는 ①정책 위험 6유형 + 위험 3개 찾기 시연 ②IPS 탐지방식 4종과 오탐 관리 ③Snort 룰 구조와 시연 4단계를 차례로 보고, 관통축 #6(방화벽)과 #12(IPS 모니터모드 장기운영)을 닫습니다.

§2-4. 방화벽 심화

방화벽 정책은 다음 구성요소를 가집니다: Source · Destination · Service · Action(permit/deny) · 로깅 · 유효기간 · 신청자/사유. Stateful Inspection은 세션테이블로 반환 트래픽을 자동 허용하고, NAT는 SNAT(내부→공인 변환)과 DNAT(공인→내부 서버 포워딩)을 수행합니다.

위험 정책 6유형

정책 수명주기

시연 — 가상 정책 20행에서 위험 찾기

아래 위젯은 가상 정책 20행을 보여줍니다. 사용자는 “위험하다고 생각하는 행”을 토글하고 「판정 보기」를 누르면 실제 위험 플래그(Any-Any/광범위/유효기간 없음/장기 미사용/Shadow/중복)와 사유가 reveal됩니다. Doc 시연 “위험 3개 찾기”의 답이 위젯 안에 있습니다.

§2-5. IPS 이해

모니터모드(미러링)로 장기 운영하는 IPS는 결함 #12의 정체입니다 — “차단”이 없는 IPS는 탐지 결과를 운영자가 수동으로 반영해야 하므로, 오탐이 운영자의 신경을 무디게 하고 결국 룰을 꺼버립니다.

탐지방식 4종

오탐·미탐 관리 = IPS 운영의 전부

튜닝 프로세스

① 도입(모니터모드) → ② 오탐 정리 → ③ 고신뢰룰부터 차단 전환 → ④ 재검토.

모니터모드 장기운영이 결함인 이유: 모니터모드는 “차단”이 없으므로 운영자가 alert를 수동으로 반영해야 합니다. alert가 한 달에 수천 건이면 운영자는 “또 오탐”으로 판단하고 alert 자체를 무시하기 시작합니다. 룰을 disable하는 것은 그 다음 단계이며, 근거 기록 없이 disable하면 IPS의 가치가 0이 됩니다(결함 #12).

§2-6. Snort 원리·룰 구조

Snort는 패킷수집 → 디코더 → 전처리기 → 탐지엔진 → 출력의 파이프라인입니다. 전처기는 TCP 재조합·IP 조각 재조합·HTTP 정규화를 수행합니다. 룰은 Header와 Options 두 부분으로 구성됩니다.

alert tcp $EXTERNAL_NET any -> $HOME_NET 80 ( msg:"..."; flow:to_server,established;
       content:"/admin.php"; http_uri; nocase; sid:1000001; rev:1; classtype:web-application-attack; )
└──────── Rule Header ────────┘ └──────── Rule Options ────────┘

• Header: action(alert/drop/reject/pass) · protocol · src · src_port · direction(->,<>) · dst · dst_port.
• Options: 메타(msg·sid·rev·classtype·reference·priority) · 페이로드(content·nocase·offset·depth·distance·within·pcre) · 버퍼(http_uri·http_header·http_client_body·service) · 상태(flow:to_server,established) · 임계(detection_filter=탐지임계 · event_filter=알림억제).

시연 4단계 룰 (Doc 정본)

Snort 룰 해부

아래 위젯의 룰 해부 섹션은 s2(SQLi) 룰의 Header·Options 각 토큰을 클릭 가능한 span으로 보여주고, 각 토큰의 의미를 reveal합니다.

§2-7. Snort 시연

위 위젯의 시연 4단계 섹션은 ①②③④ + ④ 튜닝 후(before/after)를 스테퍼로 보여줍니다.

• ① 단순룰: ICMP 이벤트로 alert 1건.
• ② content: SQLi 시나리오로 alert 1건, 정상 트래픽 A(uri=“?tab=reunion”)는 alert 0건(AND-“select” + http_uri로 두 술어 모두 차단).
• ③ 임계치: SQLi 5회 반복으로 alert 1건(detection_filter count=5, 4회 미만은 0).
• ④ 오탐 튜닝 ★:
  • before: content "union" 단일 + buffer raw → FP-A(uri=“?tab=reunion”)와 FP-B(body=“union select”) 둘 다 오탐.
  • after: content "union" + "select" AND + buffer http_uri → FP-A는 “select 없음”으로, FP-B는 “uri 아님(body)“으로 각각 탈락 → alert 0. sqli는 여전히 alert(uri에 union·select 둘 다).
  • 교습 payoff: 튜닝이 오탐만 죽이고 진짜는 살립니다. AND-“select”는 FP-A를, buffer http_uri는 FP-B를 각각 잠그므로, 한 레버만 제거하면 정확히 그 FP가 재오탐됩니다.

관통축 닫기 — 결함 #6과 #12

매핑표 발췌 (P6 링크)