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 설정을 운영 점검 항목으로 관리합니다.