Snort - Sieciowy System Wykrywania Włamań

Snort to bardzo silny sieciowy system wykrywania ataków (ang. Network Intrusion Detection System, NIDS), który daje szeroki zakres mechanizmów detekcji, mogących w czasie rzeczywistym dokonywać analizy ruchu i rejestrowania pakietów w sieciach opartych na protokołach IP/TCP/UDP/ICMP. Potrafi przeprowadzać analizę strumieni pakietów, wyszukiwać i dopasowywać podejrzane treści, a także wykrywać wiele ataków i anomalii, takich jak przepełnienia bufora, skanowanie portów typu stealth, ataki na usługi WWW, SMB, próby wykrywania systemu operacyjnego i wiele innych.

Wymagania

Przed instalacją Snorta warto zaopatrzyć się w bazę danych (w opisie wykorzystano MySQL) i serwer Apache z obsługą PHP. W bazie będą składowane logi, a za wygodny interfejs do przeglądania alarmów posłuży ACID (ang. Analysis Console for Intrusion Databases).

Instalacja Snorta i ACID

Gdy mamy już bazę danych i serwer WWW z PHP, instalujemy następujące pakiety.

poldek> install snort acid

Przed konfiguracja środowiska NIDS zakładamy dwie bazy, dla Snorta i dla archiwum alarmów.

# mysql -u mysql -p
Enter password:
mysql> create database snort_log;
Query OK, 1 row affected (0.01 sec)
mysql> create database snort_archive;
Query OK, 1 row affected (0.01 sec)
mysql> quit

Dodajemy tabele w taki sam sposób dla obu baz.

# gzip -d /usr/share/doc/snort-{wersja}/create_mysql.gz
# mysql -D snort_log -u mysql -p < /usr/share/doc/snort-{wersja}/create_mysql
# gzip -d /usr/share/doc/acid-{wersja}/create_acid_tbls_mysql.sql.gz
# mysql -D snort_log -u mysql -p < /usr/share/doc/acid-{wersja}/create_acid_tbls_mysql.sql

# mysql -D snort_archive -u mysql -p < /usr/share/doc/snort-{wersja}/create_mysql
# mysql -D snort_archive -u mysql -p < /usr/share/doc/acid-{wersja}/create_acid_tbls_mysql.sql

Następnie (najprościej przy użyciu popularnego narzędzia phpMyAdmin) tworzymy użytkownika i nadajemy mu prawa dla stworzonych baz.

Przechodzimy do edycji pliku /etc/acid_conf.php, w którym dodajemy parametry dla połączenia się z bazami.

[...]
/* Alert DB connection parameters */
[...]
$alert_dbname   = "snort_log";
$alert_host     = "localhost";
$alert_port     = "3306";
$alert_user     = "login";
$alert_password = "haslo";

/* Archive DB connection parameters */
$archive_dbname   = "snort_archive";
$archive_host     = "localhost";
$archive_port     = "3306";
$archive_user     = "login”;
$archive_password = "haslo";
[...]

Teraz strona z interfejsem jest dostępna pod adresem http://twoje_ip/acid. Oczywiście dla bezpieczeństwa zalecane jest zastosowanie protokołu SSL do komunikacji z zasobem i autoryzacji poprzez pakiet apache-mod_auth.

Snort zależnie od środowiska w jakim działa może generować dużą ilość zbędnych alertów, te bardziej istotne można przenosić do drugiej bazy za pomocą ACID, dla przejrzystości ogółu.

Konfiguracja Snorta

Do działania jako sieciowy system wykrywania włamań, Snort potrzebuję sprecyzowania zasad funkcjonowania całości w głównym pliku konfiguracyjnym snort.conf. W starszych wersjach systemu, wszystkie opcje, łącznie z regułami ataków znajdowały się w jednym pliku. Ciągła rozbudowa Snorta, rosnąca liczba sygnatur i ogólna funkcjonalność, wymusiła rozdzielenie niektórych części konfiguracyjnych, w tym reguł ataków. Przejrzystość i spójność snort.conf została przywrócona przy użyciu polecenia include, którym dołącza się odpowiednie zestawy sygnatur i inne części konfiguracyjne, np.:

include: ścieżka_do_pliku/nazwa

Bazy reguł charakteryzują się nazwą pliku z końcówką .rules, pierwszy człon nazwy zawiera rodzaj usługi lub typ ataku, którego dotyczy dany zestaw. Pozostałymi plikami konfiguracyjnymi są:

Pozostałymi plikami konfiguracyjnymi są:

classification.config - zawierający klasyfikatory rodzajów ataków z nadanym priorytetem zagrożenia, tak jak poniżej:

config classification: web-application-attack,Web Application Attack,1

reference.config - posiadający skróty adresów do stron organizacji z bazą opisów ataków, np.:

config reference: bugtraq http://www.securityfocus.com/bid/

threshold.conf - metody łagodzenia licznych, fałszywych alarmów,
unicode.map - zestaw kodowanych znaków unicode, na potrzeby preprocesora http_inspect.

Główny plik konfiguracyjny można podzielić na cztery sekcje. Pierwsza, odpowiedzialna jest za ustalanie zmiennych var, wykorzystywanych w składni reguł ataków.

Przyjmijmy że docelowo Snort ma monitorować dwie podsieci o adresach 192.168.1.0/24 i 192.168.2.0/24, jego pliki konfiguracyjne znajdują się bezpośrednio w katalogu /etc/snort, a regułki w /etc/snort/rules.

# Adres sieci lokalnej
var HOME_NET [192.168.1.0/24,192.168.2.0/24]
# Adres sieci zewnetrznej
var EXTERNAL_NET !$HOME_NET
# Lista adresow serwerow znajdujacych sie w strefie chronionej
var DNS_SERVERS $HOME_NET
var SMTP_SERVERS $HOME_NET
var HTTP_SERVERS $HOME_NET
var SQL_SERVERS $HOME_NET
var TELNET_SERVERS $HOME_NET
var SNMP_SERVERS $HOME_NET
# Lista portow
var HTTP_PORTS 80
var SHELLCODE_PORTS !80
var ORACLE_PORTS 1521
# Lista serwerow czat, komunikatorow
var AIM_SERVERS [64.12.24.0/24,64.12.25.0/24,64.12.26.14/24,64.12.28.0/24,]
# Scieszka do katalogu z regulami atakow
var RULE_PATH /etc/snort/rules

W tej samej sekcji znajduje się zestaw parametrów uruchomieniowych, zaczynających się od wyrażenia config (pełna ich lista znajduję się w dokumentacji):

# wybor interfejsu do nasłuchu (jeden demon Snorta moze obslugiwac tylko jeden
# interfejs sieciowy)
config interface: eth0

Druga część głównego pliku konfiguracyjnego, zawiera ustawienia preprocesorów. Parametry domyślne nie będą przedstawione w poniższym opisie. Kompletną listę opcji, można znaleźć w dokumentacji Snorta.
Oto przykłady ustawień preprocesorów:

Frag2:

# detect_state_problems – zwraca alarm przy pokrywaniu sie fragmentow.
preprocessor frag2: detect_state_problems

Stream4, Stream4_reassemble:

# disable_evasion_alerts – brak alarmow przy nakladaniu sie pakietow TCP,
# detect_scans – detektor prob cichego skanowania,
# detect_state_problems – detektor nienaturalnego zachowania pakietow.
preprocessor stream4: disable_evasion_alerts detect_scans detect_state_problems
# both – skladanie sesji TCP w obu kierunkach pomiedzy klientem i serwerem,
# ports – lista portow, na ktorych ma dzialac reasemblacja.
preprocessor stream4_reassemble: both ports [ 21 25 80 143 110 ]

Http_inspect:

# iis_unicode_map – wskazuje plik z kodowaniem unicode i wybiera standardowe.
preprocessor http_inspect: global is_unicode_map unicode.map 1252
# profile – wybor profilu ustawien dla serwerow typu iis, apacze i all.
preprocessor http_inspect_server: server adres_IP_serwera_MS_IIS \
    profile iis \
    ports { 80 }
preprocessor http_inspect_server: server adres_IP_serwera_Apache \
    profile apache \
    ports { 80 }

Powyższy przykład przedstawia możliwość profilowania ustawień dla poszczególnych serwerów, które podlegają ochronie. Serwery IIS i Apache, pracują w odmienny sposób, a zarazem posiadają inne słabe punkty wykorzystywane podczas ataków. Operacja dostosowania ustawień skupia mechanizmy ochronne na odpowiednich metodach ataków dla danego typu serwera bądź ich grupy w danej sieci objętej ochroną.

RPC_decode, Back Orfice, Telnet_decode, Arpspoof, Performance Monito:

# alert_fragments – wlacza alarm, przy fragmentowaniu pakietow RPC,
# Domyślne porty: 111 i 32771.
preprocessor rpc_decode: 111 32771 alert_fragments
preprocessor bo
preprocessor telnet_decode
preprocessor arpspoof
preprocessor arpspoof_detect_host: adresy_IP przypisane_do_nich_adresy_MAC
# console – wyswietlanie statystyk na ekranie,
# flow i events – statystyki badanego ruchu i ilosci dopasowanych regul,
# time – aktualizacja danych co 10s.
preprocessor perfmonitor: console flow events time 10

Flow i Flow-portscan:

# stats_interval – zapisywanie statystyk, 0 – wylaczone,
# hash – wybor metody mieszania.
preprocessor flow: stats_interval 0 hash 2
# server-watchnet – adresy IP, na ktorych flow bedzie prowadzic badania,
# server-learning-time – czas utrzymania punktow dla danego adresu IP,
# server-scanner-limit – ilosc zapytan decydujacych o przyznaniu statusu
#                        skanowania z danego adresu,
# src-ignore-net, dst-ignore-net – lista ignorowanych adresow docelowych
#                                  i zrodlowych.
preprocessor flow-portscan: \
        server-watchnet [xxx.xxx.xxx.xxx/xx] \
        server-learning-time 14400 \
        server-scanner-limit 10 \
        src-ignore-net [xxx.xxx.xxx.xxx/xx, xxx.xxx.xxx.xxx/xx] \
        dst-ignore-net [xxx.xxx.xxx.xxx/xx]

Trzecia sekcja snort.conf, zawiera metody konfiguracji modułów wyjściowych, czyli różnych sposobów logowania wyników i tzw. akcji reguł. Na potrzeby tego opisu wymieniony będzie tylko przykład logowania do bazy MySQL.

output database: alert, mysql, user=login password=haslo \ 
dbname=snort_log host=127.0.0.1

Za pomocą reguł akcji można tworzyć własne rodzaje reakcji na wykryte zdarzenie, np.:

ruletype czerwony_alarm
 {
     type log
     # zapis do demona syslogd, lokalnie
     output alert_syslog: LOG_ALER
 }
# Przykladowa regula:
czerwony_alarm $HOME_NET any -> $HOME_NET 6667 (msg:"Internal IRC Server";)

Czwarta, ostatnia część, głównego pliku konfiguracyjnego, zawiera odniesienia do zestawów reguł i wcześniej już opisanych plików, classification.config, reference.config, threshold.conf (przykład poniżej).

include classification.config
include reference.config

include $RULE_PATH/bad-traffic.rules
include $RULE_PATH/exploit.rules
include $RULE_PATH/telnet.rules
include $RULE_PATH/rpc.rules
include $RULE_PATH/dos.rules
(...)
# dodatkowy zestaw regul Bleeding Snort - http://www.bleedingsnort.com
include $RULE_PATH/bleeding.rules
include threshold.conf

Dostosowanie Snorta do swoich potrzeb obejmuje, obok konfiguracji preprocesorów przede wszystkim decyzje, jakie zbiory reguł mają być brane pod uwagę (czyli jakie pliki z regułami mają być dołączane za pomocą polecenia include). W środowisku, w którym wszystkie serwery WWW to Apache, reguły chroniące serwer IIS będą generowały zupełnie niepotrzebne alarmy. Jeśli nie udostępniamy FTP, reguły opisujące ataki na tę usługę będą tylko spowalniały pracę całego systemu. To sprawy oczywiste, jednak właściwe dostosowanie NIDS do swoich potrzeb wymaga wiele pracy. Dobranie odpowiednich dla danego środowiska reguł jest kluczowe dla działania całego systemu, duża ilość fałszywych alarmów nie tylko zużywa zasoby (każda z reguł musi być przecież przeanalizowana), ale może również bardzo skutecznie "zaciemnić" obraz, sprawiając, że prawdziwy atak może przejść niezauważony w zalewie informacji mało istotnych. Obecna baza sygnatur liczy sobie około 2500 reguł i jest praktycznie każdego dnia wzbogacana o nowe opisy ataków. Dla przybliżenia występujących w bazie kategorii sygnatur, opiszę jakiego rodzaju ataki wykrywają:

attack-responses – odpowiedzi usług na próbę ataku;
backdoor – działalność tzw. tylnych drzwi, trojanów, rootkitów;
bad-traffic – nieprawidłowy ruch, np. na port 0;
chat – aktywność różnego rodzaju komunikatorów;
ddod, dos – zmasowane ataki Distributed Denial of Service (rozproszony atak typu - blokada usługi);
deleted – regły przestarzałe, wykasowane;
dns – ataki na usługę Domain Name System;
experimental – zestaw eksperymentalnych reguł;
exploit – programy mające na celu wykorzystywanie błędów w oprogramowaniu;
icmp-info, icmp – komunikaty ICMP z różnych programów, testujących ruch;
imap, pop2, pop3, smtp – ataki na systemy pocztowe;
info – próby logowania na usługi Telnet, Ftp;
local – zestaw własnych reguł;
misc – różne, dotyczące usług CVS, MS Terminal, BOOT, UPnP itd.;
multimedia – strumienie audio, wideo;
mysql, sql, oracle – ataki na znane serwer baz danych;
netbios – anomalia związane z protokołem Netbios/SMB;
nntp – ataki na serwer grup dyskusyjnych;
other-ids – działalność innych systemów IDS;
p2p – aktywność programów Peer to Peer;
policy – próby ataków na usługi policy ftp itp.
porn – aktywność stron portnograficznych;
rpc – ataki na usługi Remote Procedure Call;
finger, rservices, telnet – ataki na dość słabo zabezpieczone usługi uniksowe: finger, rlogin, rsh, rexec, telnet;
scan – różnego rodzaju techniki skanowania portów;
shellcode – wykorzystanie nieprawidłowego kodu do prób przepełnienia bufora;
snmp – ataki na usługi SNMP;
tftp, ftp – zdarzenia związane z przesyłaniem plików poprzez serwer ftp;
virus – transfer poczty z podejrzanym załącznikiem;
web-attacks, web-misc, web-client, web-cgi, web-php, web-coldfusion, web-frontpage, web-iis – ataki na różnego typu serwery WWW, przeważnie z wykorzystaniem błędów w skryptach cgi, php;
x11- aktywności sesji serwera XFree86.

Aktualizacja reguł

Do aktualizacji sygnatur posłuży nam perlowy skrypt Oinkmaster. Ma on duże możliwości które pozwalają w prosty sposób zarządzać regułami Snorta. Wymagane pakiety do uruchomienia to: perl, perl-base, perl-modules i vixie-cron albo hc-cron .

Instalacja Oinkmaster

Ściągamy archiwum tar, rozpakowujemy, skrypt wgrywamy do katalogu /usr/local/bin, a konfig do /etc:

# wget --passive-ftp \
ftp://ftp.it.su.se/pub/users/andreas/oinkmaster/oinkmaster-1.0.tar.gz
# tar -zxvpf oinkmaster-1.0.tar.gz
# cp oinkmaster-1.0/oinkmaster.pl /usr/local/bin/
# cp oinkmaster-1.0/oinkmaster.conf /etc/

Operacja aktualizacji odbywa się po następującej sekwencji komend:

# /usr/local/bin/oinkmaster.pl -o /etc/snort/rules/

Dodanie innego źróła reguł:

# /usr/local/bin/oinkmaster.pl -o /etc/snort/rules/ -q -u \
http://www.bleedingsnort.com/bleeding.rules.tar.gz

Aby aktualizacja odbywała się automatycznie, w katalogu /etc/cron.daily tworzymy plik uprules.

# touch /etc/cron.daily/uprules
# chmod 700 /etc/cron.daily/uprules

I dodajemy do niego następującą zawartość, podając adres e-mail na który ma zostać wysłany raport z codziennej aktualizacji jeśli pojawia się coś nowego:

TMP=`mktemp /tmp/oinkmaster.XXXXXXXX` &&
(/usr/local/bin/oinkmaster.pl -o /etc/snort/rules/ -q > $TMP 2>&1;
if [ -s $TMP ]; then mail -s "Update Snort Rules" root@twoja_domena < $TMP; fi;
rm $TMP)

# dodatkowy zestaw regul Bleeding Snort - http://www.bleedingsnort.com
TMP=`mktemp /tmp/oinkmaster.XXXXXXXX` &&
(/usr/local/bin/oinkmaster.pl -o /etc/snort/rules/ -q -u \
http://www.bleedingsnort.com/bleeding.rules.tar.gz > $TMP 2>&1;
if [ -s $TMP ]; then mail -s "Update Bleeding Rules" root@twoja_domena < \
$TMP; fi; rm $TMP)

/etc/rc.d/init.d/snort restart

Warto przyjżeć się bliżej ciekawym funkcjonalnościom oinkmastera. W pliku konfiguracyjnym mamy możliwość wyłączania poszczególnych regułek po nr sid, dodawania do nich własnych modyfikacji itp. Wtedy jest pewność że po aktualizacji, nasze zmiany w plikach reguł nie będą nadpisywane.

Trochę teorii - Architektura Snorta

Snort jest logicznie podzielony na kilka komponentów, które współpracują ze sobą by wykrywać ataki i generować wyniki w odpowiednim formacie. Głównymi składnikami systemu są: dekoder pakietów (sniffer), preprocesory, silnik detekcji i moduł wyjściowy.

W swej najprostszej formie Snort może działać jako sniffer. Przechwytuje pakiety z warstwy łącza danych za pomocą biblioteki pcap. Rozpoznaje różne protokoły modelu OSI - Ethernet, 802.11, Token Ring oraz wiele protokołów działających w wyższych warstwach jak: IP, TCP, UDP i ICMP.
Surowe pakiety z warstwy łącza danych (np. ramki Ethernetowe) po zdekodowaniu wądrują do preprocesorów (warstwa transportowa), gdzie są testowane i w razie konieczności obrabiane na potrzeby silnika detekcji (warstwa sesji). Tam dokonywana jest analiza pakietów pod kątem zbioru zadanych reguł. Nastąpnie po wykryciu próby ataku bądź anomalii sieciowych, system przekazuje odpowiednie dane do modułu wyjściowego, który to decyduje o zapisaniu wyniku wykrycia w logach lub wszczęciu alarmu.

Tryby pracy

Snort umożliwia dużą swobodę konfiguracji, za pomocą wielu parametrów, które pozwalają kontrolować trzy podstawowe tryby pracy programu: sniffer, packet logger i network intrusion detection.

Sniffer Mode - wychwytuje wszystkie pakiety w danym segmencie sieci i przedstawia ich zawartość na ekranie. Najprostszym sposobem użycia tego trybu jest uruchomienie programu z parametrem -v w wyniku, czego Snort będzie wyświetlać informacje o nagłówkach IP, TCP/UDP/ICMP. Do uzyskania bardziej szczegółowych danych o wychwyconych pakietach, służą parametry -d (aby monitorować ładunek pakietów) i -e (dodatkowe nagłówki warstwy łącza danych). Parametry można łączyć razem, bez znaczenia jest ich kolejność (np. snort -ved). Aby zakończyć pracę w tym trybie należy użyć sekwencji klawiszy CTRL+C.
Packet Logger Mode - logowanie pakietów poprzez zapis na dysku. Czynność ta odbywa się po użyciu opcji -l, którą wskazujemy katalog, gdzie Snort będzie zapisywać w odpowiednio nazwanych podkatalogach i plikach, zawartość zebranych pakietów. Program potrafi także zapisywać dane w formie binarnej tak jak robi to znany sniffer tcpdump. Służy do tego opcja -b, po jej użyciu nie trzeba stosować dodatkowych kombinacji parametrów -ved, ponieważ format tcpdump, określa to, co ma być logowane (np. snort -b -l ./log). Uzyskane w ten sposób informacje, można wykorzystać do późniejszej analizy za pomocą programów rozpoznających format binarny tcpdump (np. Ethereal). Oczywiście można tą samą czynność wykonać z wykorzystaniem Snorta, używając opcji -r, po czym przetworzyć sczytane pakiety dostępnymi trybami.
Snort czytając swoje dzienniki (tak samo działając w trybie sniffera) przyjmuje parametry w formacie BPF (Berkeley Packet Filter), dzięki którym możemy sprecyzować (na podstawie nagłówków), jakie konkretnie pakiety chcemy obserwować (np. określić adres hosta, protokół, port). Jeśli np. interesuje nas tylko ruch na porcie 80 można uruchomić Snorta poleceniem: snort -r /var/log/snort/snort.log port www, jeśli chcemy wyświetlić tylko odpowiedzi serwera www: snort -vde src port www. Aby ignorować cały ruch z sieci np. 192.168.1.0 na port 80: snort -vde not ( src net 192.168.1 and dst port 80 ).
Połączenie Snorta z filtrami BPF znacznie zwiększa wydajność całego systemu, gdyż filtrowanie BPF odbywa się w warstwie łącza danych (a więc na poziomie biblioteki pcap). Określając w ten sposób, jakie pakiety nas interesują (lub jakie chcemy zignorować) można dość dokładnie "zawęzić" obszar poszukiwań. Filtry BPF można również zapisać w oddzielnym pliku i załadować w trakcie uruchamiania Snorta parametrem -F: snort -r snort.log -F plik_z_bdf. Więcej na temat możliwości oferowanych przez BPF można poczytać na stronach podręcznika zarówno Snorta, jak i Tcpdump.
Network Intrusion Detection Mode - sieciowy system wykrywania włamań. Jest najbardziej skomplikowanym trybem działania programu. Za pomocą parametru -c, wskazujemy plik konfiguracyjny, w którym określane są zasady badania przechwyconego ruchu sieciowego, ustawienia preprocesorów, a także zestaw sygnatur ataków. Aby program działał w tle jako demon, należy użyć opcji -D (np. snort -d -D -c snort.conf). Reszta operatorów i ich opisy, jakie można wykorzystać przy starcie programu, przedstawia parametr -h.

Preprocesory

Preprocesory zostały wprowadzone do Snorta w wersji 1.5. Pozwalają użytkownikom i programistom w prosty sposób na rozbudowę funkcjonalności całego systemu poprzez pisanie dodatkowych modułów (ang. plugins).

Preprocesory analizują pakiety przed wykorzystaniem ich przez silnik detekcji. W ten sposób zwiększają możliwości całego procesu wykrywania ataków sieciowych, wzbogacając go o zdolność składania (reasemblacji) pakietów, wykonywania specyficznych dla poszczególnych protokołów operacji (np. konwersja na ASCII znaków z URI zakodowanych szesnastkowo, usuwanie ciągów binarnych z sesji FTP czy Telnet, normalizacja żądań RPC), jak i wykrywania niezgodności z tymi protokołami.

Poniżej pozwolę sobie pokrótce opisać standardowy zestaw preprocesorów wchodzących w skład darmowej dystrybucji Snorta w wersji 2.1.3.

Frag2 - defragmentuje i normalizuje dane przychodzące w postaci fragmentów, co utrudnia ukrywanie ataków prowadzonych za pomocą nieprawidłowo sfragmentowanych pakietów IP. W tym celu wykorzystuje ustalony przez użytkownika bufor pamięci, w której przez określony czas przetrzymuje do badania pakiety z tablicy stanów połączeń. Im większa liczba sfragmentowanych pakietów tym wymagany jest większy bufor. Defragmentacja, układając datagramy IP w jedną całość, ułatwia dalszą analizę danych poprzez pozostałe preprocesory i silnik detekcji. Frag2 umożliwia wychwytywanie znanych ataków wykorzystujących zniekształcenia fragmentów pakietów np. teardrop, fragroute.
Stream4 - rozwija model detekcji oparty na testowaniu pojedynczych pakietów umożliwiając śledzenie sesji (stanu połączenia) TCP i składanie (reasemblacji) strumieni TCP, co nie byłoby możliwe w mechanizmie opartym na wyszukiwaniu wzorców. Na tym poziomie działa także wykrywanie niektórych prób skanowania portów, gdzie wymagane jest notowanie prób łączenia się z poszczególnymi usługami w określonych odstępach czasu oraz wykrywanie prób oszukania Snorta za pomocą narzędzi takich, jak np. Stick lub Snot, które generują pojedyncze (niewchodzące w skład poprawnych sesji TCP) pakiety mające za zadanie zalać mechanizm detekcji masą fałszywych alarmów (są to pakiety budowane na losowo wybranych sygnaturach). Snort broni się przed takimi technikami wykorzystując stream4 preprocesor - losowe pakiety są dość łatwo identyfikowane (i ignorowane), ponieważ nie należą do prawidłowej sesji TCP. Stream4 wychwytuje próby skanowania technikami: stealth, null, xmas, fin; wykrywanie systemu operacyjnego - fingerprint i inne anomalia związane z protokołem TCP.
Flow i Flow-Portscan - posiada mechanizm śledzenia połączeń, zapisując całość do tablicy stanów w celu dalszego przetwarzania. Na tej podstawie flow-portscan wykrywa próby skanowania w bardziej wyrafinowany sposób niż preprocesory stream4 i portscan. Celem wykrywania, są skany z jednego hosta do wielu i z jednego hosta na wiele portów. Flow-portscan prowadzi statystyki na podstawie punktacji różnych rodzajów połączeń, np. jeśli jakaś usługa jest popularna i na jej port przychodzi dużo zapytań, jednocześnie dostaje najmniej punktów w ogólnej skali. Preprocesor posiada bardzo wiele opcji za pomocą, których reguluje się skale punktacji, rozmiary tablicy wyników, tolerancję niepowtarzalności zdarzeń itp.
HTTP Inspect - jest ogólnym dekoderem protokołu HTTP na poziomie warstwy aplikacyjnej. Za pomocą ustalonego bufora wynajduje odpowiednią składnie HTTP i ją normalizuje. HTTP Inspekt działa w obydwu trybach jednocześnie: client requests (pol. zapytania klienta) i server responses (pol. odpowiedzi serwera). Mnoga liczba dostępnych opcji w konfiguracji preprocesora, umożliwia dostosowanie ustawień do konkretnego typu serwera WWW.
Głównymi zadaniami http_inspect jest przetwarzanie adresów URI, konwertując na ASCII znaki zakodowane w postaci szesnastkowej. Utrudnia to ukrycie ataku przed modułem wykrywającym sygnatury ataków przez zakodowanie typowych sekwencji. Dekoduje także znaki zakodowane jako Unicode, oraz wykrywa nielegalne kodowania, wykorzystywane m.in. w ostatnich dziurach MS IIS.
Portscan Detector - wykrywa próby skanowania portów, polegające na przekroczeniu pewnej progowej liczby prób połączeń z różnymi portami w określonym przedziale czasu. Ze względu na brak możliwości uniknięcia fałszywych alarmów w typowych przypadkach (np. obciążony serwer DNS), istnieje możliwość wyłączenia alarmów wzbudzanych przez określone adresy IP używając dodatkowego procesora portscan-ignorehosts. Pozwala także, zapisać wyniki w oddzielnym pliku dziennika.
Telnet Decode - usuwa z sesji TELNET i FTP binarne ciągi mogące utrudnić wyszukiwanie z udziałem sygnatur ataków.
RPC Decode - normalizuje żądania po protokole RPC, utrudniając ukrywanie podejrzanych pakietów za pomocą mniejszych operacji.
Back Orifice detektor - wyszukuje w pakietach UDP próby połączeń konia trojańskiego Back Orifice i próbuje złamać zabezpieczające je słabe kodowanie.
Arpspoof - wykrywa podejrzane pakiety ARP, mogące sygnalizować próby ARP spoofingu.
Performance Monitor - udostępnia wszelkiego rodzaju statystyki liczbowe, odnośnie ilości przeanalizowanych pakietów, zużycia procesora itp. Całość wyświetlana jest na ekranie konsoli lub zapisywana do pliku, wg ustalonych wcześniej wartości.

Zarówno preprocesory, jak i mechanizm detekcji mogą zareagować w określony sposób. Po wychwyceniu pakietów, spełniających warunki nadane konfiguracją preprocesorów lub regułami, podejmowane jest odpowiednie działanie (np. zapisanie pakietów bądź alarm).

Moduł sygnatur

Gółwny mechanizm systemu detekcji zagrożeń polega na dopasowaniu przetworzonych pakietów i ich zrekonstruowanych strumieni z bazą sygnatur. System detekcji porównuje cechy pakietu ze zbiorem reguł. Po dopasowaniu, zostaje podjęta odpowiednia akcja. Do porównywalnych cech należą atrybuty gółwne - adresy, porty źródłowe i docelowe oraz opcje pomocnicze: flagi TCP identyfikujące np. żądania związane z WWW, różne typy pakietów ICMP, opcje IP czy wreszcie sama treść pakietu. Na razie w gółwnej części reguł możliwe jest śledzenie protokołów IP, ICMP, TCP i UDP. Autorzy przewidują rozszerzenie Snorta o następne protokoły sieciowe, m.in. IPX, GRE, czy protokoły wymiany informacji między routerami - RIP, OSPF oraz IGRP.

Reguły identyfikowania ataku pozwalają na podjęcie pięciu rodzajów akcji: przepuszczenia pakietu (pass), zapisania informacji do dziennika (log), ogłoszenia alarmu (alert), alarmowania i podjęcia do działania innej dynamicznej reguły (activate) i pozostanie w spoczynku do czasu aktywowania przez regułę activate, po czym działanie jako reguła log (dynamic).

Sygnatury Snorta zazwyczaj składają się z dwóch głównych sekcji - nagłówka i ciała (treści). Nagłówek określa m.in., jaką akcję należy podjąć po przypasowaniu reguły, informacje o wykorzystanym protokole, adresy bądź porty źródłowe i docelowe. Ciało reguły pozwala rozwinąć informacje zawarte w nagłówku, tu także podaje sią treść wzbudzanych alarmów i różnego rodzaju informacje dodatkowe (np. odniesienia do bazy z opisami danego naruszenia, tzw. referencje - Bugtraq, CERT czy CVE).

Najprostsze sygnatury obejmują wskazanie akcji, protokołu, kierunku, adresów i portów będących przedmiotem obserwacji, jak np. poniższa reguła, stanowiąca reakcję na próbę skorzystania z usługi pop3 (port 110):

log tcp any any -> 192.168.1.0/24 110

W sygnaturach można umieszczać zmienne zdefiniowane jako adresy sieci (wg CIDR) lub porty zapisane w pliku konfiguracyjnym snort.conf:

log tcp $EXTERNAL_NET -> $HOME_NET 110

W podanych powyżej regułach wykorzystany był jednokierunkowy operator "->". Język sygnatur umożliwia zadeklarowanie reguły, który dopasuje pakiety poruszające się w obu stronach operatorem dwukierunkowym "<>", np.:

alert tcp any any <> $HOME_NET 23

Do zasadniczej części reguły można dodać ograniczone okrągłymi nawiasami pole opcjonalne (tzw. ciało), zawierające definicję bardziej złożonych i wyrafinowanych działań związanych z przejęciem danego pakietu. Użytkownik może także sformułować własny komunikat, np.:

log tcp $EXTERNAL_NET -> $HOME_NET 110 ("msg: Proba polaczenia z pop3";)

Podjęte działania nie muszą być ograniczone do pojedynczej czynności. Średnik separuje deklaracje poszczególnych działań, jak w poniższym przykładzie, w którym opcją content testowana jest treść przesyłanego strumienia TCP, a w razie odnotowania podejrzanego ciągu znaków generowany jest odpowiedni komunikat:

alert tcp any any -> 192.168.1.0/24 80 (content: "/cgi-bin/phf"; msg: "PHF probe!";)

Opcji content można użyć nawet kilka razy w jednej regule. Pozwala to na wyszukiwanie wielu różnych ciągów znaków w obrębie przesyłanych treści.

Warto nadmienić, iż do przeszukania treści pakietów i reasemblowanych strumieni używany jest obecnie najbardziej efektywny algorytm - Boyera-Moore'a, którego wydajność rośnie wraz z długością poszukiwanych ciągów. Możliwość rekonstrukcji całych strumieni transmisji TCP, wglądu w warstwę aplikacyjną i efektywne wyszukiwanie treści pozwala na walkę przy użyciu Snorta również z zainfekowanymi załącznikami elektronicznych listów. Oprócz przeszukiwania treści pakietów możemy badać pod różnymi kątami ich nagłówki, m.in. pola i kody ICMP, pole TTL, rozmiary fragmentacji czy numery sekwencji.

Bardzo silną konstrukcją w regułach Snorta jest możliwość aktywowania kolejnych reguł po pierwszym dopasowaniu. Konstrukcja ta nosi nazwę activate/dynamic rules i wygląda w następujący sposób:

activate tcp any any -> $HOME_NET 143 (flags: PA; content: "|E8C0FFFFFF|bin|;activates: 1; msg: "IMAP buffer overflow!";)
dynamic tcp any any -> $HOME_NET 143 (activated_by: 1; count: 50;)

Opcje activates i activated_by wiążą reguły activate i dynamic. W powyższym przykładzie wykrycie ataku typu buffer overflow na serwer IMAP powoduje uruchomienie kolejnej, dynamicznej reguły, która zbiera treść następnych 50 pakietów (opcja count) w celu późniejszej analizy. Druga opcja w reguły dynamicznej jest obligatoryjna - reguła zawierająca wyłącznie opcję dowiązania do innej, macierzystej konstrukcji jest bezużyteczna.

Następne godne uwagi parametry, to resp i react wspierają mechanizm elastycznego reagowania na atak. Opcja resp może doprowadzić do zerwania połączenia, np. poprzez wysłanie do atakującego komunikatu ICMP o niedostępności trasy do zaatakowanego komputera, natomiast react służy do blokowania dostępu do usług związanych z WWW.

Ciekawe projekty

Nessus – sieciowy tester bezpieczeństwa, przydatny do określania skuteczności skonfigurowanego przez nas Snorta.
SnortALog – skrypt Perlowy pozwalający na generowanie różnego rodzaju raportów, grafów i statystyk. Korzystając z logów Snorta, format wygenerowanych raportów może stanowić plik tekstowy, HTML, a nawet PDF.
Snort Inline – poprawka dla Snorta, umożliwiająca współprace z regułami firewalla IPtables, stosowanego w systemach opartych na jądrze Linux. Specjalnie sformułowane sygnatury Snorta, reagują na atak i blokują bądź przekierowują za pomocą ściany ogniowej drogę pakietów pochodzących od intruza.
SnortSam - jest to zestaw pluginów do Snorta pełniących podobną funkcje jak Snort Inline, ale wspomagająca większą liczbę różnego rodzaju zapór ogniowych (m.in. Checkpoint Firewall-1, Cisco PIX, Cisco Routers z ACL, Netscreen, IP Filter dla *BSD, Linux IPchains, Linux IPtables, WatchGuard Firebox).
FLoP – projekt ma na celu, przyspieszenie logowania w procesie wykrywania włamań. Do tego wykorzystuje odpowiednie bufory i możliwość szybkiego zapisu przez gniazdo unixowe do baz danych MySQL i PostgreSQL. Bardzo przydatne narzędzie przy pracy w sieciach o dużej przepustowości.

uho(at)xhost.one.pl