📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 280편
이전 글: 279. Host-based IDS · 다음 글: 281. Anomaly Detection
1. 개념
Signature Detection(시그니처 탐지, 오용 탐지·Misuse Detection) 은 이미 알려진 공격의 특징을 패턴(시그니처) 으로 정의해 두고, 관찰한 트래픽이나 로그가 그 패턴과 일치하면 Alert를 만드는 방식입니다. 백신이 악성코드 패턴을 비교하는 것과 같은 원리입니다.
규칙 세트의 출처, 갱신 도구, 엔진 적재 방식은 04 영역 190. Signature Detection에서 다뤘습니다. 이 글은 "시그니처가 무엇을 비교하고, 왜 맞거나 틀리는가" 라는 탐지 논리를 다룹니다.
시그니처가 비교하는 대상은 크게 세 가지입니다.
| 비교 대상 | 예 | 특징 |
|---|---|---|
| 페이로드 내용 | 특정 문자열, 바이트 순서, 정규표현식 | 가장 흔함, 암호화되면 불가 |
| 프로토콜 필드 값 | HTTP 메서드·URI·헤더, DNS 질의 이름, TLS SNI | 프로토콜 해석 후 특정 필드만 검사해 정확도 향상 |
| 헤더·상태 조건 | 포트, TCP 플래그, 흐름 방향, 연결 상태 | 단독으로는 넓고, 내용 조건과 결합해 범위 축소 |
2. 동작 원리
시그니처 탐지는 "조건을 모두 만족하는가"를 차례로 확인하는 과정입니다.
패킷 / 재조립된 스트림 / 프로토콜 필드
↓
[1] 헤더 조건: 프로토콜·주소·포트·방향이 맞는가? ── 아니면 다음 규칙
↓
[2] 흐름 조건: 연결 성립 후 클라이언트→서버 방향인가? ── 아니면 다음 규칙
↓
[3] 빠른 사전 검사: 규칙의 대표 문자열(fast pattern)이 있는가?
↓
[4] 세부 조건: 모든 content 위치·순서, 정규표현식, 크기 조건
↓ 모두 만족
[5] 임계치 조건(있다면): 일정 시간 안에 N회 이상인가?
↓
Alert 생성 (sid, msg, classtype)조건이 많고 구체적일수록 오탐은 줄고, 대신 조금만 달라진 공격도 놓칠 가능성(미탐)이 커집니다. 시그니처 작성은 이 둘 사이의 균형을 잡는 일입니다.
3. 주요 특징
시그니처는 무엇을 기준으로 작성했는가에 따라 성격이 달라집니다.
| 유형 | 기준 | 장점 | 한계 |
|---|---|---|---|
| 공격 도구·익스플로잇 기반 | 특정 공격 코드에만 있는 문자열 | 오탐 적음, 정확함 | 코드가 조금만 바뀌어도 미탐 |
| 취약점 기반 | 취약점을 건드리려면 반드시 필요한 조건 (예: 비정상적으로 긴 필드) | 변형 공격에도 강함 | 작성이 어렵고, 정상 트래픽과 겹칠 수 있음 |
| 행위·정책 기반 | 특정 프로토콜·도구 사용 자체 | 정책 위반 파악 | 악성 여부와 무관 |
| 위협 정보(IOC) 기반 | 알려진 악성 IP·도메인·해시 | 즉시 적용 가능 | 인프라가 바뀌면 무효, 수명이 짧음 |
- 장점: 무엇을 탐지했는지 명확합니다. msg와 sid만 봐도 의미를 알 수 있어 분석과 설명이 쉽습니다.
- 한계: 알려지지 않은 공격(제로데이), 인코딩·분할·암호화로 모양을 바꾼 공격은 놓치기 쉽습니다. 이를 보완하는 방식이 281. Anomaly Detection입니다.
4. 예시
같은 목적(관리 페이지 접근 탐지)을 서로 다른 정밀도로 작성한 시그니처의 형식 예시입니다(Suricata 문법, 값은 환경마다 다름, sid는 로컬 범위).
# 형식 예시 — (A) 넓은 조건: 페이로드 어디든 "admin"
alert tcp any any -> $HOME_NET 80 (msg:"LOCAL admin string"; content:"admin"; sid:1000401; rev:1;)
# 형식 예시 — (B) 좁은 조건: 연결 성립 후 요청 방향, HTTP URI 필드 안의 특정 경로
alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL external access to admin setup page"; flow:established,to_server; http.uri; content:"/admin/setup.php"; startswith; nocase; sid:1000402; rev:1;)분석 방법 — (A)는 응답 본문, 쿠키, 이미지 파일명 등 어디에 "admin"이 있어도 일치하므로 오탐이 많습니다. (B)는 방향·연결 상태·필드·위치를 모두 지정해 의도한 요청만 잡습니다. 같은 탐지 목적이라도 조건의 구체성이 Alert 품질을 결정합니다. startswith는 Suricata 5 이후의 키워드이며, Snort에서는 depth 등으로 위치를 제한합니다.
5. 보안 관점
- 시그니처 탐지는 알려진 위협에 대한 기본 방어선입니다. 대량의 자동화 공격 대부분은 알려진 도구와 취약점을 사용하므로 시그니처로 걸러집니다.
- 공격자는 URL 인코딩, 대소문자 변경, 패킷 분할로 시그니처를 피하려 합니다. 엔진의 정규화(디코딩 후 검사)와 재조립이 이 회피를 줄입니다.
- 시그니처 공개 시점과 공격 발생 시점 사이의 공백 기간에는 탐지가 불가능합니다. 규칙 갱신 주기가 중요한 이유입니다.
- IOC 기반 시그니처는 오래 두면 오탐원이 됩니다(악성 IP가 정상 서비스로 재할당 등). 만료 관리를 합니다.
6. SOC 관점
관제자가 시그니처 Alert를 볼 때 확인할 질문
- 이 규칙은 무엇을 기준으로 작성되었는가? 도구 기반인지, 취약점 기반인지, 정책 기반인지 규칙 원문과 reference로 확인합니다.
- 일치한 내용이 어느 필드, 어느 방향에서 나왔는가? 요청이 아니라 응답에서 일치했다면 의미가 다릅니다.
- 대상 시스템은 그 시그니처가 노리는 취약점에 해당하는 환경인가?
시그니처 Alert
↓ 규칙 원문·reference 확인 → 탐지 의도 파악
↓ 일치한 필드·방향 확인 (페이로드 확인 가능하면)
↓ 대상 자산 환경과 비교 (OS·서비스·버전)
해당 없음 → 시도 수준 / 오탐 검토
해당 있음 → 응답·호스트 흔적으로 성공 여부 확인오탐 주의: 넓은 content 조건 하나로 된 규칙은 정상 문서·파일 전송에서도 쉽게 일치합니다. 규칙 문법은 282. Signature Rule, 오탐 판단은 285. False Positive에서 이어집니다.
7. 핵심 정리
- 시그니처 탐지는 알려진 공격의 특징을 패턴으로 정의해 일치 여부로 탐지하는 방식입니다.
- 비교 대상은 페이로드 내용, 프로토콜 필드 값, 헤더·흐름 조건이며, 조합할수록 정확해집니다.
- 도구 기반 시그니처는 정확하지만 변형에 약하고, 취약점 기반 시그니처는 변형에 강하지만 작성이 어렵습니다.
- 알려지지 않은 공격과 인코딩·암호화된 공격은 시그니처 탐지의 한계입니다.
- Alert 분석 시 규칙의 탐지 의도, 일치 필드·방향, 대상 자산의 해당 여부를 확인합니다.
