Suricata 소스 특징정리

매뉴얼 -

스레드는 input / output 핸들러를 가짐.

이 스레드는 다른 스레드로부터 패킷을 전해 받거나, 패킷풀로부터 패킷을 받음.

이 Threading module 은 "ThreadVars" 구조체 내에 존재.

스레드는 'Detect1' 을 호출.

'Stream-queue1' 라는 큐에서 패킷 가져옴.

그리고 'simple' 이라는 큐 핸들러를 사용.

올라온 패킷은 'verdict-queue' 라는 큐 내부로 들어감. 이 큐는 'simple' 핸들러가 조작.

스레드는 하나의 슬롯, 즉 하나의 모듈만 사용 가능하며 'detect' 모듈이 slot 함수로 세팅된다.

스레드 모듈은 패킷 프로세싱 유닛으로 정의된다. 모듈은 패킷 탐지부터 경고 탐지까지 다양하게 쓸 수 있고, 하나 이상의 패킷을 생성할 수 있고. ~~ 뭐라뭐라.

큐 모듈

연속된 패킷을 위해 멀티스레드를 이용한다면, 이 큐는 패킷을 전송하기 위해 사용한다.

스레드는 큐 핸들러를 갖고 있으며, 여기서 패킷을 획득할지 버릴지 결정한다. FIFO 큐를 사용하며 첫 번째 큐와 마지막 큐는 항상 'packetpool' 이다.

큐 핸들러

큐 핸들러는 스레드에 의해 호출된다. 패킷을 얻거나 없애기 위해, 이전 스레드 혹은 다음 스레드의.

'simple'이 가장 간단한 큐 핸들러 형태이며 FIFO 방식이고, IPv4/v6 듀얼스택과 같은 복잡한 개발 가능케 한다.

표준 입력 방식Standard Input Method

세가지

NFQueue

IPF Ring

Libpcap

Flowint : 전역변수 작업 관련한 새로운 방식. 변수 내에서 데이터의 캡쳐, 저장, 비교 가능

코드 일부만 수정을 하는 경우 Unit test 가 가능하다.

코드의 작은 부분들을 ㅌ레스트 할 수 있으며 ./configure --enable-unittest 로 컴파일.

suricata -u U flowbit 로 실행 가능

Caveats

--enable-debug-validation

이것과 unittest 같이 하면 프로그램 깨질 수 있다.

커맨드 라인

-c : suricata.yaml 경로 지정

-i : 패킷 스니핑 할 인터페이스 카드 지정. 

-r : 패킷이 저장될 pcap 파일의 경로를 지정한다. 

-s : 파일 시그니처를 지정할 수 있다. yaml 의 룰 세팅과 함께 로드 가능. ??

-l : 디폴트 로그 디렉토리 지정하기. yaml 에 default-log-dir 이 지정되어있으면 별 필요는 없다. 

-D : 수리카타가 콘솔에서 돌아가고 있다면 

모르겠고 이거 데몬으로 돌리는것 같던데

Introduction

Signatures play a very important role in Suricata. In most occasions people are using existing rulesets. The most used are Emerging Threats, Emerging Threats Pro and source fire's VRT. A way to install rules is described in Rule Management with Oinkmaster.
This Suricata Rules document explains all about signatures; how to read-, adjust-and create them.

A rule/signature consists of the following:
The action, header and rule-options.

Example of a signature:

몇몇 사람들은 사용한다 존재하는 룰셋을. Emerging Threat 와 Emerging Thread pro 그리고 source fire의 VRT 를 가장 많이 사용한다. 룰을 설치하는 방법은 Rule Management with Oinkmaster 안에 잘 설명되어 있다

수리카타 룰 도큐먼트는 시그니처의 모든 것을 설명한다. 

Action

For more information read 'Action Order' in the suricata.yaml wiki.

Example:

In this example the red, bold-faced part is the action.

수리카타 yaml의 action order 발췌

Action-order

All signatures have different properties. One of those is the Action property. This one determines what will happen when a signature matches.

모든 시그니처는 서로 다른 속성들을 가진다. 그 중 하나가 Action 속성이다. Action 속성은 시그니처 매칭이 될 때 어떤 일을 할 것인지 결정한다.
There are four types of Action. A summary of what will happen when a signature matches and contains one of those Actions:

Action 에는 네 가지 타입이 있다. 

1) Pass
If a signature matches and contains pass, Suricata stops scanning the packet and skips to the end of all rules (only for the current packet).

패스. 만약 시그니처가 일치하고 패스에 포함되면, 수리카타는 패킷의 스캐닝을 멈추고 나머지 룰들을 스킵한다.

2) Drop
This only concerns the IPS/inline mode.
If the program finds a signature that matches, containing drop, it stops immediately. The packet will not be sent any further. 
Drawback: The receiver does not receive a message of what is going on, resulting in a time-out (certainly with TCP). Suricata generates an alert for this packet.

드랍. IPS/inline 모드에서만 포함되어 있는 기능이다. 만약 프로그램이 시그니처와 매치하는 패킷을 찾으면 즉시 패킷 전송을 멈춘다. 패킷은 어디로도 전송되지 않는다. 

Drawback: 패킷 받는 PC가 무슨 일이 일어났는지에 관한 패킷을 받지 못한다. 수리카타는 이 패킷에 대한 경고를 생성한다.

3) Reject
This is an active rejection of the packet. Both receiver and sender receive a reject packet. There are two types of reject packets that will be automatically selected. If the offending packet concerns TCP, it will be a Reset-packet. For all other protocols it will be an ICMP-error packet. Suricata also generates an alert. When in Inline/IPS mode, the offending packet will also be dropped like with the 'drop' action.

거부

아예 패킷을 거부한다. 송신자와 수신자는 reject 패킷을 받는다. reject 패킷에는 두 가지 종류가 있으며 자동으로 선택된다. 

4) Alert
If a signature matches and contains alert, the packet will be treated like any other non-threatening packet, except for this one an alert will be generated by Suricata. Only the system administrator can notice this alert.

Inline/IPS can block network traffic in two ways. One way is by drop and the other by reject.

Rules will be loaded in the order of which they appear in files. But they will be processed in a different order. Signatures have different priorities. The most important signatures will be scanned first. There is a possibility to change the order of priority. The default order is: pass, drop, reject, alert.

action-order: 
 - pass
 - drop
 - reject
 - alert

This means a pass rule is considered before a drop rule, a drop rule before a reject rule and so on.

Protocol