이름만으로 실제 차단 여부를 결론내릴 수 없습니다. 수동(passive) 센서는 트래픽 사본을 관찰하는 배치일 수 있고, 인라인(inline) 장비라도 예방 기능이 꺼져 있거나 simulation 모드면 실제 전달을 막지 않을 수 있습니다.
탐지 결과·배치·규칙의 action·예방 설정·트래픽 처리 증거를 따로 확인해야 합니다. NIST SP 800-94는 2007년 자료이며 2012년 Rev.1 초안은 최종본이 아니고 폐기됐다고 NIST가 알립니다. 예시는 직접 만든 교육용이며 특정 제품 설정을 뜻하지 않습니다.
탐지, 예방 기능, 네트워크 배치는 각각 다른 사실입니다
침입 탐지 시스템(IDS)은 의심 활동을 찾아 경고하는 기능에 초점을 두고, 침입 방지 시스템(IPS)은 정책에 따라 통신을 차단하는 예방 기능을 제공할 수 있습니다. 그러나 장비 이름이나 관리 화면의 제품 범주가 실제 패킷을 막았다는 증거는 아닙니다. NIST SP 800-94는 IDPS 기능을 설명하면서 탐지 기능과 예방 기능을 별도로 다루고, 각 경보 종류마다 예방을 켜거나 끄는 설정과 simulation mode가 있을 수 있다고 안내합니다. ‘IDS는 탐지만, IPS는 항상 차단’처럼 고정하면 구성 상태와 운영 증거를 놓칩니다.
네트워크 배치도 별도로 봅니다. Passive sensor는 미러 포트나 network tap에서 트래픽 사본을 감시합니다. NIST 2007 안내는 수동 센서가 보통 목적지에 도달하는 트래픽을 신뢰성 있게 차단할 방법이 없고, 예방 기능을 쓰려면 inline 배치가 일반적이라고 설명합니다. 하지만 inline은 단지 패킷 경로에 장비가 놓였다는 뜻일 뿐입니다. 룰이 alert만 내도록 설정되거나, 해당 경보의 prevention이 꺼져 있거나, simulation mode가 활성화됐다면 탐지 이벤트는 기록돼도 차단되지 않을 수 있습니다.
| 관찰된 상황 | 탐지 근거 | 차단을 입증하는가 | 추가 확인 |
|---|---|---|---|
| 미러 포트에 연결된 sensor가 의심 연결을 기록 | 패킷 복사본과 경보 로그 | 아니요. 관찰 경로가 원본 전송과 별개일 수 있음 | 원본 흐름의 수신 측 도달 여부와 네트워크 정책 |
| inline appliance에서 alert 발생, simulation mode 표시 | 분석 규칙이 조건을 탐지 | 아니요. 가상 예방 동작만 기록할 수 있음 | 해당 룰의 실제 action 및 예방 설정 상태 |
| inline 정책에서 특정 rule action이 drop으로 설정되고 counter가 증가 | 정책·패킷 처리 이벤트·counter | 차단 근거가 강해지나 종단 결과도 확인 필요 | 우회·재전송·다른 경로 및 수신 측 기록 |
경보 한 줄에서 실제 차단까지의 증거를 추적합니다
가상 서비스에서 스캐너가 의심 요청을 보냈고 관리 화면에 IDS 경보 하나가 나타났다고 합시다. 경보는 어떤 센서가 어떤 규칙으로 요청을 관찰했다는 증거입니다. 요청이 서버에 도달했는지 또는 서버 상태가 바뀌었는지는 별도 자료가 필요합니다. 장비가 switch mirror port에서 복사 패킷을 받고 있었다면 센서는 관찰을 했을 수 있지만, 그 위치만으로 원본 요청의 전송 경로에 개입했다고 볼 수 없습니다. ‘탐지됐다’는 문장을 ‘차단됐다’고 바꿔 쓰지 않습니다.
두 번째로 같은 장비가 inline이어도 rule action이 alert이거나 관리자 설정에서 prevention이 비활성화되어 있으면 경고만 남을 수 있습니다. 반대로 Suricata 공식 9.0.0-dev 문서의 IPS mode 예에서는 traffic filter처럼 동작하며 기본 허용 규칙에 더해 drop 또는 reject rule로 원치 않는 트래픽을 막는 사용을 설명합니다. 이는 특정 개발 버전 문서의 동작 예이지 모든 IPS 제품의 기본 정책은 아닙니다. 실제 판정에서는 적용 중인 버전, mode, 규칙, 예방 설정, bypass 여부와 처리 결과 로그를 함께 보세요.
차단을 보고하려면 신호의 경로를 하나씩 연결합니다. alert id와 원본 flow가 같은지, rule이 어떤 action을 갖는지, action이 활성 상태였는지, 장비 counter나 packet disposition 기록이 증가했는지 확인합니다. 가능하면 수신 서비스의 access log나 제한된 테스트 환경에서 관찰한 endpoint 결과와 맞춰 봅니다. 한 로그만으로 성공이나 실패를 단정하지 말고, 기록 범위와 수집 누락 가능성도 적습니다. 실제 운영 장비에 시험 패킷을 보내거나 정책을 바꾸지 않습니다.
차단 여부를 판단하는 순서
- 탐지 이벤트의 센서, 규칙, 원본 flow, 시간과 관찰 지점을 식별합니다.
- 센서가 passive인지 inline인지 실제 배선·라우팅·미러 구성으로 확인합니다.
- 해당 경보에서 prevention이 활성인지, simulation 또는 alert-only가 아닌지 확인합니다.
- 규칙의 drop/reject 등 action과 실제 패킷 처리·counter 기록을 대조합니다.
- 수신 측 또는 승인된 검증 환경의 후속 증거로 흐름이 차단됐는지 확인하고 한계를 남깁니다.
NIST 페이지가 알려 주듯 SP 800-94는 2007년 최종 간행물입니다. NIST는 2012년 Rev.1 초안을 공개 의견용으로 냈지만 해당 초안은 최종 출판이 되지 않았고 2022년에 retired 상태라고 공지했습니다. 이 글은 해당 문서의 passive/inline 및 예방 설정 개념을 인용하되 현재의 모든 제품 동작이나 권고 구성을 설명한다고 주장하지 않습니다. Suricata 설명도 9.0.0-dev 문서의 구현 사례에만 귀속했습니다. 특정 제품의 현재 설정은 그 제품의 적용 버전 공식 문서와 현장 구성으로 재확인해야 합니다.
탐지 경보를 차단 완료나 공격 성공으로 확정하지 않습니다
두 극단을 피하세요. 첫째, IDS라는 약어만 보고 어떤 배치에서도 차단할 수 없다고 단정하지 않습니다. 둘째, IPS라는 제품명이나 alert 화면만 보고 이미 패킷이 막혔다고 단정하지 않습니다. NIST는 IDPS 제품의 예방 설정이 경보별로 조정될 수 있다고 설명하고, inline 여부 또한 중요한 구조 조건이라고 안내합니다. 실제 사건의 영향 판단은 요청 관찰, 정책 실행, 목적지 도달, 자산 변화 증거를 나누어야 합니다. 이는 기존 공격 시도와 성공의 구분 글을 장비 배치·정책의 증거까지 확장하는 학습 주제이지 사고 대응 절차를 대체하지 않습니다.
차단 주장을 뒷받침하는 자료를 세 가지 말해 봅니다
회상 연습: 인라인 sensor가 탐지 이벤트를 만들었지만 prevention 설정은 simulation이고 rule action은 drop입니다. 실제 요청이 차단됐다고 답할 수 있나요? 아닙니다. simulation이면 예방 동작을 억제하고 예상 결과만 보여 줄 수 있습니다. 실제 mode와 prevention 활성 상태, 처리 결과·counter, 가능한 수신 측 후속 기록을 확인해야 합니다. 이 사례는 직접 작성한 교육용 자료로 실제 시험 문제나 집중 180제 카드가 아닙니다. 현재 상품 구성은 /decks/security#focus-180에서 확인하세요.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
인라인 sensor에서 탐지 이벤트가 발생했지만 prevention은 simulation이고 rule action은 drop이다. 실제 차단 여부를 결론낼 수 있는가? 필요한 후속 증거를 말하세요.
정답과 해설 확인
실제 차단을 결론낼 수 없습니다. simulation은 예방 동작을 억제할 수 있으므로 적용 mode와 prevention 설정, 실제 packet 처리·counter 및 수신 측의 후속 기록을 확인해야 합니다.NIST SP 800-94는 경보별 prevention 설정과 simulation mode를 설명합니다. inline 배치만으로 실제 drop을 보장하지 않으며 Suricata 예시는 특정 9.0.0-dev 문서의 구현 동작에 한정됩니다.