개요

1998년 개발 이후 가장 유명한 NIDS툴이 되었음
제작자 Marty Roesch는 개인 용도로 네트워크 트래픽 분석을 목적으로 스노트를 개발 하였다.
초기 스노트는 바이너리 tcpdump데이터를 인간이 읽을수 있는 형태로 출력하는 형식이었다.
기능 : 스니퍼, 패킷 로거, NID
- 사실 스노트는 일종의 souped-up 스니퍼 모드로 작동하는 셈이다. 단지 차이가 있다면 스니핑한 패킷을 주어진 데이터와 연결된 작업을 한다.

1. Snort's Specifications

1.1 요구 사항

스노트는 generic sniffing interface(libpcap)를 사용하기 때문에 대부분으 시스템에서 동작한다.

다음은 스노트가 지원하는 아키텍쳐 들이다.
- i386
- Sparc
- Motorola 68000/PowerPC
- Alpha
다음은 스노트가 지원하는 OS이다.
- Linux
- OpenBSD
- FreeBSD
- Solaris
- HP-UX
- AIX
- Mac OS X
- Win32(Win9x/NT/2000/XP)

1.2 Bandwidth Consderations

100Mb : 빠른 속도로 일처리 가능

200 ~ 300Mb : 패킷 손실 발생

500Mb~ : 작동 하지 않음

1.3 Snort is an open source Application

스노트는 오픈소스 이다.

일부 상용버젼도 있다 : silicon Defense & sourcefire

2. Detecting Suspicious Traffic via Signatures

공격자 및 시스템을 탐지 해내는 가장 좋은 방법은 "시그네쳐 기반(signature-based) 탐지" 기법이다.

signature-based detection 기법은 악의적 네트워크 트래픽은 특정 패턴을 가지고 있다는 가정하에 있다.

이러한 특정 패턴을 이용하여서 signature를 생성 할수 있다.

alert icmp $EXTERNAL_NET any -> $HOME_NET any

(msg:"ICMP PING NMAP"; dsize: 0; itype:8; )

외부네트워크에서 들어오는 모든(ANY) ICMP + 데이타 페이로드 부분이 비어 있음 + ICMP 타입필드가 8일 경우 경고 메시지 출력

2.1 Detecting Suspicious Payloads

스노트는 패킷 해더 뿐만이 아니라..페이로드의 내용까지도 확인 할수가 있다.

alert tcp $EXTERNAL_NET any -> $HOME_NET 139

(msg: "DOS SMBdie atack" : flags: A+; content:"|57724c65680042313342577a|";)

외부 네트워크에서 내부 SMB서버로 들어 오는TCP패킷 중에서 페이로드에 "57724c65680042313342577a"가 들어 있을경우 경고 메시지 출력

2.2 Detecting Specific Protocol Element

성능과 정확도를 위해 스노트 시그네쳐는 특정 프로토콜의 한 요소에 국한 시킬수도 있다.

alert tcp $EXTERNAL_NEW any ->$HTTP_SERVERS $HTTP_PORTS

(msg : "WEB-IIS ISAPI .ida attempt"; uricontent:".ida?"; nocase; dsize:>239; flags:A+;)

외부에서 내부의 웹서버로 접근하는 트래픽 중에서 URI에 ".ida"가 들어 있다면 경고 메시지를 출력

2.3 Extending Coverage with Custom Rules

자신의 네트워크의 특성에 맞는 룰이나 새로운 룰들을 정의 할수도 있다.

alert tcp 192.168.1.1 any -> $HOEM_NET 22

(msg: "suspicious host SSH traffic";)

특정 사용자(192.168.1.1)의 IP를 쓰는 악의적 사용자가 ssh로 접속을 시도 할경우 경고 메시지 출력

더 자세한 내용은 12장의 "Basic Rule Writing" 부분을 살펴 보기 바란다.

3. Detecting Suspicious Traffic via Heuristics

시그네쳐 기반의 탐지 기법은 꽤 효과적이다. 하지만 이러한 시그네쳐가 항상 100%정확하지는 않다.
어떨때는 트래픽은 악의적인데 이에 맞는 시그네쳐가 없는 경우도 있다.
이를 위해 스노트 커뮤니티에서는 Statistical Packet Anomaly Detection Engine(SPADE)모듈을 개발 하였다.
- 이 모듈은 특정 시그네쳐가 없어도 수상쩍인 트래픽을 감지 할수 있다.
SPADE는 악의적 트래픽을 heuristic 패턴 매칭 방법으로 알아낸다.
- 이를 위해 SPADE는 네트워크 트래픽을 감시하면서 테이블을 생성한다. 이 테이블에는 일반적인 트래픽의 정보가 기록된다.
- 기록 내용 : 패킷 타입, 목적지, 발신지 주소
- 특정 양의 테이블이 생성되며 매 수신 패킷마다 테이블과 비교 하여...새로운 패턴의 패킷이면 높은 점수를 매기고..이 점수가 특정값을 넘기면 경고 메시지 출력

4. Gathering Intrusion Data

또다른 스노트의 주된 특징중 하나는 데이터 수집이다.

필요에 따라서 모든 페이로드를 로그화 할수 있따.

4.1 Assessing Treats

공격 데이터의 페이로드를 분석하는 것은 해당 공격의 성격을 알아 내는데 중요한 역할을 한다.

이렇게 분석한 정보를 이용하여서 정확한 방어및 공격자의 정보를 얻어 낼수 있다.

4.2 Preprocessors

스노트 개발팀은 유연성과 모듈 방식의 어플리케이션 지원을 위하여 Preprocessors 메커니즘을 도입 하였다.
정의 : A class of Plug-ins, 탐지 엔진이 동작전에 데이터와 상호 동작 목표
Preprocessors은 그 기능에 따라 크게 세 부분으로 나눌수 있다.
- Data Normalization
  - 새로운 공격이나 IDS 탐지 회피 공격은 스노트가 탐지 해내기 힘들다
  - 그래서 스노트에 Preprocessor를 더하여 데이터를 정규화 시킨다.
    - 그후 탐지 엔진이 해석 할수 있다.
- Protocol analysis
  - 탐지 엔진은 자신이 해석 가능한 프로토콜의 리스트를 가지고 있다.
  - 이 리스트 외에는 자주 사용되는 프로토콜이라 할지라도 해석이 불가능 하다.
- Non-signature-matching detection
  - 일부 악의적 노드는 딱 구별되는 시그네쳐가 없을수 있따다.
  - 이러한 의심 트래픽을 .....

Data Normalization
- e

5. Alerting via output plug-ins

Preprocessirs 처리 스노트 outputing 기능은 모듈화및 플러그인이 가능한다
- 서로 다른 기술 레벨, 네트워크 설정, 개인 취향에 따라 맞는 아웃풋 메커니즘을 선별 적용한다.
- 이러한 아웃풋은 인간이 알아 보기 쉽지는 않다.
- 다른 어플리케이션이나 툴들이 사용할수 있도록 아웃풋 한다.
  - Syslog
  - tcpdump
  - Text Logfile
  - XML
  - Relational database
  - SNMP
  - Snort Unified
- 이러한 다양한 포맷들은 사용자에게 선택의 자유를 준다.
- 또한 스노트는 여러 DB 플랫폼을 지원한다.
  - mysql
  - oracle
  - MS sql Server

5.1 Aggrefating Data

5.2 Logging with the Unified format and Baryard

기본적으로 DB연결 아웃풋 플러그인은 밴드위스에 따른 제약이 있다.
DB 플러그인 사용시 가장 빠른 방식인 tcpdump file로 로그를 남기는 것보다 40%의 성능 감소가 있다.
- 네트워크를 통한 저장시는 더 악화 된다.
이를 해결하기 위해 "Baryard를 개발 하였다.

Baryard설치시 스노트는 아웃풋 데이터를 빠른 속도로 Snort unified Format으로 디스크에 저장한다.
1. "경고"들을 저장후 스노트 데몬은 다른 팻킷 관리에 초점을 맞춘다
바이너리 데이터는 Baryard에 위해 여러 포맷으로 파싱된후 DB 플러그인이 저장된 Baryard에게 보내진다.

Baryard는 스노트와 완전 별개로 동작한다.
- 따라서 경고 메시지는 스노트의 패킷캡쳐 능력에 영향을 미치지 않고 DB에 저장이 가능하다.

고 밴드위스 상에서는 Baryard 사용은 필수 적이다.

5.3 Alerting

ID는 자동화 시스템이 아니라서 인간이 수신된 경고 메시지에 따라 제때에 조치를 취해야 한다. 이를 위해 "경고:Alert"이 존재 한다.
스노트로 부터 실시간으로 경고 메시지를 얻는데에는 여러 방법이 있다. (책에서는 2가지의 예를 들고 있다. )
- Real-time alerting with syslog & swatch
  - 간단하면서도 강력하다
  - 스와치는 시스로그 파일을 모니터링 하며 주어진 규칙에 맞는지 확인한다.
  - 맞으면 경고 메시지를 보낸다.
- Analysis console for Intrusion Database(ACID)
  - 웹어플리케이션으로써 DB에 저장된 침입정보를 읽고 브라우져를 통해 알려준다.
  - 인간이 보기 쉬운 포맷으로써 데이터를 표현한다.
  - 검색 기능도 제공한다.
  - 기능에 따라 논리적 카테고리별로 그룹 경고가 가능하다.
  - 인터넷을 통해 취약점을 알릴수 있다 (CVE)
  - Charting기능을 제공하여 통계 및 그래프로 표현 가능하다.

6. Prioritizing Alerts

IDS는 경고 메시지의 우선 순위에 따른 분류 작업이 필요하다.
모든 메시지가 동일한 관심(attention)이나 정밀 조사가 필요하지는 않다.

6.1 No prioritization

모든 경고 메시지가 동일한 레벨이다.
관리자는 모든 경고들을 살펴보며 꼭 위험한 경고가 무었인지 찾아야 한다.
자동 응급 상황 통보 메커니즘이 쓸모 없다.

6.2 Hard-coded Prioritization

No Prioritization 보다 약간의 장점만을 가지고 있다.
벤더가 어떤 경고가 중요한지 아닌지를 결정한다.
- 대부분 상.중.하 로 나눈다.
경고가 부적절하거나 상황에 맞지 않을 때가 많다.
- ex ) 웹서버를 돌리고 있지 않는데도 아파치 데몬 공격 트래픽에 대하여 경고 메시지를 받을수도 있다.

6.3 Customizable Prioritization

가장 좋은 방법으로써 사용자가 우선순위를 정하는 것이다.
오늘날 네트워크는 기능의 모듈화가 가능하기 떄문에 각자의 특성을 가지고 있다.
- 따라서 네트워크 특성에 맞게 경고 우선순위를 정하여야 한다.
경고는 사용자의 정의에 레벨지어지고, 사용자가 중요하다고 하는 경고만 알려 주게 된다.
스노트에는 32개의 미리 정해진 경고 카테고리가 존재 하며 위험도 레벨은 사용자의 목적에 따라 수정 가능하다.
- 필요하다면 32개 이외에 다른 경고 카테고리를 추가 할수도 있다.

Alert classification 도 아래의 룰을 이용해 정의 할수 있다.

config classification : trojan-activity, A Network Trojan was detected, 1

트로잔 공격을 1등급 경고로 지정

트로잔 공격인지 아닌의 classtype 지정은 아래와 같이 할수 있다.

alert tcp $EXTERNAL_NET 27374 -> $HOME_NET any

(msg : "BACKDOOR subseven 22"; flags: A+; content: "|0d0a5b52504c5d3030320d0a|"; classtype:trojan-activity;)

7. Distributed Snort Architecture

하나의 스노트가 설치된 NIDS가 수십 Gbyte의 데이터를 저장하고 처리 해야 한다면 문제가 발생할수 있다.
- 스노트는 다행히 분산 구조를 지원한다.

7.1 First Tier-The Sensor Tier

침입탐지를 목적으로 지나가는 트래픽 모니터링
일종의 진공 청소기 처럼 모든 데이터를 빨아 들여서 두번쨰 단계로 전달 한다.
스노트 어플리케이션은 센서위에서 동작하여 패킷의 속성을 해석한 다음 passing on alert한다.
센서도 같은 같은 네트워크 세그먼트들을 모니터링 하면서 침입자를 탐색한다.
센서에는 스노트와 이를 지원하는 어플리케이션만 들어 있다.
- 이는 성능과 보안의 목적 때문이다.
- IDS는 해커의 주 대상이 되므로 쓸때 없는 어플리케이션이 동작하여서 보안 취약성을 가지지 않도록 한다.
센서에는 두개의 네트워크 인터페이스가 존재 한다.
- 스니핑용, 관리용
- 이는 인풋은 스니핑용 인터페이스로, 아웃풋은 관리용 인터페이스에서만 처리 하기 위함이다.
- 스니핑용 인터페이스 (스텔스 모드로 동작)
  - IP주소 할당 안되어 있음
  - 모니터링 용도로 네트워크에 연결되어 있음
  - 따라서 트래픽은 한 방향으로만 흐르게 된다. (모니터 세그먼트 -> 센서)
  - promiscious 모드로 세팅한다.
  - 이렇게 하는 이유는 보안적인 이유가 크다...IP가 없으면 해커가 공격할수 있는 최선의 공격은 DoS이며..이것이 차라리 ..해킹 보다는 안전하기 때문이다.
- 관리용 인터페이스
  - 스니핑용 인터페이스와는 다른 네트워크에 연결되어 있다.
  - IP주소가 할당되어 있어서 2nd tier와 통신을 한다.
  - 경고 메시지는 이 인터페이스를 통하여 2nd tier로 전달된다.
  - 모든 센서 관리 또한 관리용 인터페이스를 통한다.
    - 센서를 업그레이드, 패치, roule & Preprocessor변경, 추가, 삭제
  - 관리 네트워크는 방화벽을 이용하여 외부와 보호된다.

7.2 Second Tier- The Sserver Tier

센서로 부터 경고 데이터를 수집하여 관리자에게 보기 좋은 형태로 변환하여 통보한다.
경고 데이터는 관련 DB에 보내 지게 된다.
- 스노트는 이런한 DB를 필요로 하지 않는다.
많은 양의 경고 데이터를 보관하는 가장 효과적인 방법은 관련 DB에 체계화 하여 저장하는 것이다.
- 이러한 관리를 통해 복잡한 검색도 가능하고 효과적인 경고 정보를 관리 할수도 있다.
- 다른 응용프로그램이 사용하기에도 편하다.
서버 tier역시 GUI기반의 사용자가 이해하기 쉬운 형태로 데이터를 보여 준다
- ex) demarc, snortsnarfm snortdbm ACID
서버는 여러 민간하고 극비의 정보를 저장하고 있다. 그렇기 때문에 필요한 서비스 들만 설치 하여 보안 위협을 줄여야 한다.

7.3 Third Tier - The Analyst's Console

관리자(Analyst)의 콘솔
이 콘솔의 요구사항은 단지 SSL을 지원하는 웹 브라우져만 깔려 있으면 된다.
- ACID는 익스플로어, 모질라, 네스케이프에서도 무난히 동작 한다.

8. Securing Snort

항상 패치를 실시 한다.
데이터 교환시의 보안도 중요하다.
- 모든 데이터는 암호화 되어서 전송되어야 하고 각 Tier들에 대한 인증절차도 필요하다.
stunnel(툴)을 이요하여서 센서와 서버사이에 암호화된 경고 메시지 전달을 할수 있다.
센서는 서버에 인증정보를 보내기 위해서 전자 인증서와 암호를 이용한다.
서버는 센서의 IP만 자신에게 접속 할수 있게 한다.
ACID 웹서버와 연결되는 브라우져는 SSL을 지원하고...해당 페이지는 패스워드로 보호 되어 있어야 한다.

9. Shortcoming

Flexibility Breeds Complexity
- 확장성에 초점을 맞추다 보니까..스노트를 제대로 깔기란 어렵다.
- Libpcap 기반이다 보니 100Mb 이상 처리가 힘들다 .
Problems with False Positives
- 규칙의 복잡성으로 인하여 선의의 트래픽도 악의적 트래픽으로 판단될수 있다.
Market Factors
- 일부 대형회사(Cisco)에서는 스위치에 직접 IDS장비를 연결하는 제품을 출시 하는데 이것 제품에 대항 하기 힘들다.

[세미나] Snort_ Network Intrusion Setection with Snort

개요