190. Signature Detection

Об этом предложении

📚 네트워크 · 패킷 분석 › 04. 네트워크 장비 실습 — 190편 이전 글: 189. IPS 동작 구조 · 다음 글: 191. Anomaly Detection 1. 개념 Signature Detection(시그니처 탐지) 은 알려진 공격의 특징(문자열, 바이트 패턴, 프로토콜 필드 값)을 규칙으로 만들어 트래픽과 비교하는 방식입니다. 탐지 원리, 장단점, 오탐·미탐의 성격은 06 영역 280. Signature Detection 에서 다룹니다. 이 글은 장비 운영 관점에서 "센서에 시그니처가 어떻게 들어오고, 갱신되고, 엔진에 적재되는가" 를 다룹니다. 시그니처 탐지 장비의 탐지 능력은 엔진보다 적재된 규칙 세트 에 의해 결정되기 때문입니다. 규칙 세트(예) 제공 특징 ET Open Proofpoint Emerging Threats 무료, Suricata·Snort용 제공, suricata-update 기본 소스 ET Pro Proofpoint 유료, 범위·갱신 속도 확대 Snort Community Rules Cisco Talos 무료, GPL 규칙 Snort Subscriber / Registered Rules Cisco Talos 유료 구독은 즉시, 등록 사용자는 일정 기간 뒤 제공 로컬 규칙 조직 자체 작성 내부 환경에 맞춘 탐지( 192. IDS Rule ) 제공 조건과 라이선스는 바뀔 수 있으므로 각 제공처의 최신 안내를 확인해야 합니다. 2. 동작 원리 시그니처가 센서에 적용되기까지의 흐름입니다. [규칙 제공처] ET Open / Talos / 로컬 규칙 ↓ 갱신 도구가 내려받기 (Suricata: suricata-update / Snort: PulledPork 등) ↓ 비활성화·활성화·수정 목록 적용 (disable.conf, enable.conf, modify.conf) ↓ 하나의 규칙 파일로 병합 (예: /var/lib/suricata/rules/suricata.rules) ↓ 설정 검사 (suricata -T) ↓ 엔진 재적재 (재시작 또는 무중단 reload) ↓ 탐지 엔진: 규칙들의 고정 문자열을 모아 다중 패턴 매칭 → 후보 규칙만 전체 검사 엔진은 수만 개 규칙을 패킷마다 하나씩 비교하지 않습니다. 각 규칙에서 고정 문자열 하나(fast pattern) 를 골라 다중 패턴 매칭(MPM)으로 한 번에 찾고, 그 문자열이 나온 경우에만 해당 규칙의 나머지 조건을 검사합니다. Suricata는 mpm-algo 설정으로 알고리즘을 고르며, Hyperscan 지원 빌드에서는 hs 를 쓸 수 있습니다. 3. 주요 특징 센서 운영에서 시그니처 관리 시 확인할 항목입니다. 항목 설명 확인 방법(Suricata 예) 규칙 개수 활성 규칙 수가 많을수록 메모리·CPU 사용 증가 시작 로그의 적재 결과 적재 실패 문법 오류·미지원 키워드 규칙은 적재 안 됨 suricata.log 의 오류 메시지 갱신 주기 신규 위협 반영 속도 결정 갱신 작업(cron·systemd timer) 기록 규칙 식별 gid·sid·rev로 규칙과 버전 식별 EVE alert.signature_id , alert.rev 변수 HOME_NET , EXTERNAL_NET 값이 규칙 적용 범위 결정 suricata.yaml 의 vars.address-groups 엔진별 갱신 도구입니다. 엔진 대표 갱신 도구 비고 Suricata suricata-update Suricata 4.1 이후 함께 배포되는 공식 도구 Snort 2 PulledPork(pulledpork.pl) 커뮤니티 도구 Snort 3 PulledPork3 Snort 3 규칙 형식 지원 4. 예시 실습 예시 — Suricata 센서 VM에서 규칙을 갱신하고 적재 상태를 확인하는 흐름입니다. 경로는 패키지 기본값 기준 예시(값은 환경마다 다름)입니다. # 사용 가능한 규칙 소스 목록 갱신 및 조회 sudo suricata-update update-sources sudo suricata-update list-sources # 규칙 내려받기·병합 (기본 소스 ET Open) sudo suricata-update ls -l /var/lib/suricata/rules/suricata.rules # 설정·규칙 문법 검사 후 적용 sudo suricata -T -c /etc/suricata/suricata.yaml -v sudo systemctl restart suricata # 무중단 재적재: 유닉스 소켓이 활성화된 경우 sudo suricatasc -c reload-rules 적재 결과는 suricata.log 에 기록됩니다. # 형식 예시 (값·문구는 버전과 환경마다 다름) <Info> - 1 rule files processed. 45210 rules successfully loaded, 0 rules failed 특정 규칙을 끄고 싶다면 규칙 파일을 직접 편집하지 않고 /etc/suricata/disable.conf 에 sid를 적은 뒤 suricata-update 를 다시 실행합니다. 직접 편집한 내용은 다음 갱신 때 덮어써지기 때문입니다. # /etc/suricata/disable.conf 예시 2100498 📷 [실습 화면 삽입 위치] suricata-update 실행 결과(내려받은 소스와 활성 규칙 수)와 재시작 후 suricata.log 의 규칙 적재 결과 줄 5. 보안 관점 적재되지 않은 규칙은 없는 규칙과 같습니다. 갱신 후 적재 실패가 있었는데 확인하지 않으면, 탐지하고 있다고 착각하게 됩니다. 갱신 작업이 멈추면 신규 위협 탐지가 점점 뒤처집니다. 갱신 성공 여부 자체를 모니터링 대상으로 둡니다. HOME_NET 값이 실제 내부 대역과 다르면 방향 조건이 있는 규칙이 동작하지 않거나 오탐이 늘어납니다. 시그니처는 알려진 패턴만 탐지하므로 변형·암호화된 공격에는 한계가 있습니다. 보완 방식은 191. Anomaly Detection 에서 다룹니다. 6. SOC 관점 관제자가 확인할 질문 이 Alert의 sid·rev는 무엇이며, 해당 규칙이 언제 추가·변경되었는가? 규칙 갱신 직후 Alert가 급증했다면 새 규칙의 영향일 수 있습니다. 알려진 공격인데 Alert가 없다면, 해당 sid가 disable 목록에 있거나 적재 실패한 것은 아닌가? 센서마다 규칙 세트 버전이 같은가? 센서별로 탐지 결과가 다르다면 갱신 상태를 먼저 비교합니다. Alert 급증 감지 ↓ 같은 sid 집중 여부 확인 ↓ 규칙 갱신 기록과 시간 대조 갱신 직후 → 규칙 변경 영향 가능성 → 정탐/오탐 판단 (06 영역) 갱신 무관 → 실제 트래픽 변화 → 출발지·목적지 분석 오탐 주의 : 규칙 세트 갱신으로 생긴 Alert 급증을 공격 캠페인으로 오판하지 않도록, 갱신 이력을 관제 대시보드에서 함께 볼 수 있게 하는 것이 좋습니다. 규칙 문법은 06 영역 282. Signature Rule 에서 다룹니다. 7. 핵심 정리 시그니처 탐지 장비의 탐지 능력은 적재된 규칙 세트에 의해 결정됩니다. ET Open, Snort Community·Subscriber 규칙, 로컬 규칙이 대표적인 규칙 출처입니다. Suricata는 suricata-update, Snort는 PulledPork 계열 도구로 규칙을 내려받아 병합합니다. 엔진은 fast pattern과 다중 패턴 매칭으로 후보 규칙만 전체 검사해 성능을 확보합니다. 갱신 성공, 적재 실패 여부, HOME_NET 설정을 운영 점검 항목으로 관리합니다.