1. Wstęp.
2. Architektura Snorta.
3. Tryby pracy.
4. Preprocesory.
5. Moduł sygnatur.
6. Logowanie wyników.
7. Struktura plików konfiguracyjnych.
Rozpoczęty w roku 1998 projekt Snort, początkowo miał być tylko ulepszoną wersją znanego unixowego narzędzia Tcpdump (opartego o bibliotekę pcap, która pozwala na przechwytywanie pakietów z warstwy łącza danych). W zamierzeniach twórców miał umożliwiać wygodniejszą pracę niż z tcpdump (Rys. 2), generować dane wyjściowe bardziej przyjazne dla użytkownika, zapisane w jednolitym formacie (Rys. 1).
-------------------------------------------------------------------------- 20:59:49.153313 0:10:4B:D:A9:66 -> 0:60:97:7:C2:8E type:0x800 len:0x7D 192.168.1.3:23 -> 192.168.1.4:1031 TCP TTL:64 TOS:0x10 DF ***PA* Seq: 0xDF4A6536 Ack: 0xB3A6FD01 Win: 0x446A FF FA 22 03 03 E2 03 04 82 0F 07 E2 1C 08 82 04 .."............. 09 C2 1A 0A 82 7F 0B 82 15 0F 82 11 10 82 13 FF ................ F0 0D 0A 46 72 65 65 42 53 44 20 28 65 6C 72 69 ...FreeBSD (elri 63 2E 68 6F 6D 65 2E 6E 65 74 29 20 28 74 74 79 c.home.net) (tty 70 30 29 0D 0A 0D 0A p0).... ---------------------------------------------------------------------------Rys. 1 - Przykładowy pakiet z sesji telnetowej wyświetlony za pomocą Snorta.
---------------------------------------------------------------------------
20:59:49.153313 0:10:4b:d:a9:66 0:60:97:7:c2:8e 0800 125: 192.168.1.3.23 >
192.168.1.4.1031: P 76:147(71) ack 194 win 17514 (DF) [tos 0x10] (ttl 64,
id 660)
4510 006f 0294 4000 4006 b48d c0a8 0103
c0a8 0104 0017 0407 df4a 6536 b3a6 fd01
5018 446a d2ad 0000 fffa 2203 03e2 0304
820f 07e2 1c08 8204 09c2 1a0a 827f 0b82
150f 8211 1082 13ff f00d 0a46 7265 6542
5344 2028 656c 7269 632e 686f 6d65 2e6e
6574 2920 2874 7479 7030 290d 0a0d 0a
---------------------------------------------------------------------------
Rys. 2 - Ten sam pakiet wyświetlony za pomocą tcpdump.
Z czasem rozwinął się w dość złożony system detekcji nieprawidłowości w ruchu sieciowym, ewentualnych ataków i zagrożeń, zachowując przy tym pierwotny charakter narzędzia lekkiego, szybkiego i stosunkowo mało obciążającego zasoby systemowe (zasobożerność tego typu narzędzi zależy oczywiście w ogromnym stopniu od wielkości badanego ruchu sieciowego).
Przechwycone pakiety wędrują poprzez wewnętrzne moduły „preprocesory” w sposób zbliżony do wędrówki pakietu w górę stosu TCP/IP - po drodze poddane zostają rozmaitym testom, mającym wykryć podejrzane zachowanie, lub obróbce, której celem jest ułatwienie pracy modułom na wyższych warstwach. Na szczycie tej "drabinki" pakiety porównywane są z regułami, na których bazuje zastosowany w Snorcie mechanizm detekcji. Reguły te stanowią odpowiednik sygnatur ataków, określających w szczegółowy sposób charakterystykę pakietów (lub grup pakietów), na które należy zwrócić szczególną uwagę, a po wykryciu, których należy podjąć określoną akcję (zapis do pliku dziennika, powiadomienie administratora czy nawet zablokowanie usługi).
Cały system ma modularną budowę, umożliwiającą bardzo dokładne przystosowanie narzędzia do środowiska sieciowego, które ma być poddane analizie. Dane zbierane przez Snorta można przechowywać w bazie danych (MySQL, PostgreSQL, Oracle, MSSQL) do późniejszej obróbki przez rozmaite narzędzia raportujące, można też na ich podstawie generować i wysyłać odpowiednie pułapki (ang. traps) SNMP, lub nawet napisać własną wtyczkę (ang. plugin) do obsługi zebranych danych w sposób ograniczony jedynie fantazją administratora.
Szybkość pracy, bardzo duża elastyczność i możliwości dostosowania narzędzia do wymogów aktualnego środowiska sprawiają, że Snort zyskał sobie dużą popularność. Jest rozwijany na zasadach Open Source, dostęp do kodów źródłowych umożliwił jego obecność na większości popularnych systemów operacyjnych, zarówno wolnych (Linux, *BSD), jak i komercyjnych (Solaris, HP-UX, IRIX, MacOS X, Windows). Otwarte źródła stanowią też gwarancję, że Snort będzie wciąż doskonalony i wzbogacany o nowe funkcjonalności znane do tej pory jedynie z komercyjnych (i drogich) systemów NIDS, takich jak m.in. Network Flight Recorder (NFR) czy ISS RealSecure.
Snort jest tylko samym mechanizmem wykrywania ataków sieciowych, ale istnieje duża liczba programów wspomagających i ułatwiających z nim pracę. Mam na myśli generowanie raportów, statystyk, korelacji pakietów, konfigurowanie, zarządzanie licznymi sensorami, wspieranie budowania i aktualizacji sygnatur ataków. Dobierając wg własnych potrzeb, oprogramowanie wspierające Snorta, można uzyskać wysoce wartościowe środowisko służące za kompleksowy system wykrywania włamań. Przydatnymi narzędziami współpracującymi ze Snortem są m.in. następujące projekty wolnych źródeł.
Współpracującego ze Snortem oprogramowania, można wymienić jeszcze bardzo wiele. Obserwując znane w środowisku otwartych źródeł, serwisy http://www.freshmeat.net bądź http://www.sourceforge.net, należy zauważyć dużą liczbę zarejestrowanych projektów wspomagających, co udowadnia ciągle rosnące zainteresowanie wokół Snorta.
Snort to bardzo silny sieciowy system wykrywania intruzów, który może dać szeroki zakres mechanizmów detekcji, zabezpieczając zasoby - zarówno przed atakami z wewnątrz, jak i tymi pochodzącymi z sieci zewnętrznych. Dostarcza wszystkie niezbędne informacje o podejrzanych działaniach. Jest to bardzo wydajny sieciowy system wykrywania intruzów, mogący w czasie rzeczywistym dokonywać analizy ruchu i rejestrowania pakietów w sieciach opartych na protokole IP. Może przeprowadzać analizę protokołów sieciowych, wyszukiwanie i dopasowywanie treści, a także może być używany do wykrywania wielu ataków i anomalii, takich jak przepełnienia bufora, skanowania portów typu stealth, ataki na usługi WWW, SMB, próby wykrywania systemu operacyjnego i wiele innych.
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 (Rys. 3).
Rys. 3 - Budowa Snorta.
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.
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).
Tak jak przedstawia Rys. 3, 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.
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).
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 dentyfikowania 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.
Na wychwycone (przez preprocesory bądź przez testowanie reguł) nieprawidłowości, Snort reaguje w bardzo różny sposób. Istnieje możliwość wyboru metody zapisywania wyników używając parametrów umieszczonych w głównym pliku konfiguracyjnym snort.conf lub z linii poleceń przy starcie sytemu. Program udostępnia następujące metody logowania.
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: scieszka_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ą:
config classification: web-application-attack,Web Application Attack,1
config reference: bugtraq http://www.securityfocus.com/bid/
Główny plik konfiguracyjny snort.conf można podzielić na cztery sekcje. Pierwsza, odpowiedzialna jest za ustalanie zmiennych var, wykorzystywanych w składni reguł ataków, np.:
# Adres sieci lokalnej var HOME_NET xxx.xxx.xxx.xxx/xx # Adres sieci zewnetrznej var EXTERNAL_NET any # Lista adresow serwerow znajdujacych sie w strefie chronionej var DNS_SERVERS $HOME_NET var SMTP_SERVERS $HOME_NET var HTTP_SERVERS $HOME_NET (...) # Lista portow var HTTP_PORTS 80 (...) # Lista serwerow czat, komunikatorow var AIM_SERVERS [xxx.xxx.xxx.xxx/xx,xxx.xxx.xxx.xxx/xx,xxx.xxx.xxx.xxx/xx] # 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 (większość z nich można wywołać z linii poleceń), np.:
# Ustawienia dekodera Snorta # ============================ # Wylaczenie alarmow generowanych przez decoder #config disable_decode_alerts # Wylaczenie alarmow generowanych przez eksperymentalne opcje TCP config disable_tcpopt_experimental_alerts # Wylaczenie alarmow wywolywanych przez stare opcje TCP config disable_tcpopt_obsolete_alerts (...) # Ustawienia silnika detekcji # =============================== # Wybor opcji dla metody detekcji, # Oszczedne zarzadzanie pamiecia #config detection: search-method lowmem
Druga część głównego pliku konfiguracyjnego, zawiera ustawienia wcześniej opisanych preprocesorów. Format zapisu wygląda następująco:
preprocessor nazwa: zestaw_opcjiParametry zawierające wartości domyślne nie będą zawarte w poniższym opisie. Kompletną listę opcji, można znaleźć w dokumentacji Snorta.
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.
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ł.
Alert_syslog, Log_tcpdump, Unified, Database:
# zapis do demona lokalnie output alert_syslog: LOG_AUTH LOG_ALERT # zapis do demona zdalnie output alert_syslog: host=adres_serwera:port, LOG_AUTH LOG_ALERT output log_tcpdump: tcpdump.log # limit – maksymalna wielkosc pliku wynikowego w MB output alert_unified: filename snort.alert, limit 128 output database: alert, mysql, user=? password=? dbname=? host=adres_IP
Za pomocą reguł akcji można tworzyć własne rodzaje reakcji na wykryte zdarzenie, np.:
ruletype czerwony_alarm
{
type log
output log_tcpdump: czerwony_alarm.log
}
# 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 (...) 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ą:
uho(at)xhost.one.pl