2007.03_Detekcja anomalii ruchu sieciowego w programie Snort.pdf

Obrona

Detekcja anomalii

ruchu sieciowego

w programie Snort

Maciej Skowroński, Radosław Wężyk, Maciej Szmit

stopień trudności

O detekcji anomalii napisano całkiem sporo. Na przykład Google

znajduje bez większego trudu ponad milion stron poświęconych

temu zagadnieniu. Co jakiś czas pojawiają się też prace

poświęcone zastosowaniu do detekcji anomalii najdziwniejszych

technik i algorytmów poczynając od metod statystycznych a

kończąc na rozmaitych technikach sztucznej inteligencji.

tion jest próbą włączenia się w ten nurt

poprzez przygotowanie prostego pre-

procesora Snorta mierzącego ruch sieciowy i

generującego ostrzeżenia, jeśli jego natężenie

odbiega znacznie od typowego natężenia noto-

wanego w sieci o tej porze dnia.

liczba i zróżnicowanie rozmaitych eksploitów,

wirusów, robaków, rootkitów i innych złośli-

wych programów jest na tyle duża, że uak-

tualnianie w rozsądnym czasie baz sygnatur

jest bardzo trudne. Na dodatek nie wszystkie

ataki muszą być prowadzone metodami czy-

sto „informatycznymi”. Najprostszym przy-

padkiem jest sytuacja, w której komuś udało

się na przykład odgadnąć albo ukraść hasło

administratora routera i skierować kopię ru-

chu wychodzącego z sieci do własnego anali-

zatora. Oczywiście zdarzenia takiego nie wy-

kryje, ani nie zapobiegnie mu system opar-

ty na sygnaturach (no chyba, że – co w za-

Nieco zastrzeżeń

Detekcja anomalii to pojęcie bardzo szerokie.

Można – w systemach host-based IDS (HIDS)

– wykrywać nietypowe zachowania się urzą-

dzeń (na przykład dużą ilość danych odczyty-

wanych z dysku twardego), w systemach sie-

ciowych (network IDS, NIDS) próbować znaj-

dować koincydencje pomiędzy „podejrzanymi”

pakietami a atakami sieciowymi, czy wresz-

cie analizować ruch sieciowy poszukując nie-

typowego zachowania się poszczególnych ma-

szyn. To ostatnie podejście nazywane jest cza-

sem Trafic Anomaly Detection i właśnie na nim

opiera się przedstawione w artykule rozwiąza-

nie.

Detekcja anomalii wydaje się być metodą

bardzo obiecującą, wykrywanie ataku nie jest

w niej bowiem uzależnione od znajomości

konkretnej sygnatury. Jak dobrze wiadomo

Z artykułu dowiesz się...

• informacji o preprocesorach do Snorta bazują-

cych na detekcji anomalii,

Co powinieneś wiedzieć...

• podstawy komunikacji sieciowej TCP/IP

• podstawowe pojęcia dotyczące wykrywania in-

truzów

• znajomość jęzayka C++

hakin9 Nr 3/2007

www.hakin9.org

O pisany poniżej projekt AnomalyDetec-

Detekcja anomalii ruchu sieciowego w programie Snort

sadzie byłoby niezłym pomysłem

– zabroniliśmy zdalnego logowania

na router brzegowy i nakazaliśmy

informować o takich próbach), na-

tomiast prowadzona dowolną me-

todą analiza ruchu powinna zdecy-

dowanie zasygnalizować podwoje-

nie natężenia ruchu wychodzące-

go. Z drugiej strony detekcja ano-

malii nie może być uważana za pa-

naceum na ataki sieciowe. Przesła-

nie jednego pakietu (a tyle wystar-

czy niektórym robakom) czy za-

szyfrowanej wiadomości pomiędzy

masterem a zombi sieci DDoS mo-

że pozostać niezauważone zarów-

no przez system detekcji sygnatu-

rowej jak i detekcji anomalii.

du źródłowego zaimplementowa-

ny został preprocesor zapisujący

parametry przechwyconego ruchu

do pliku w określonych interwałach

czasowych. Struktura pliku została

dobrana tak, aby łatwo można było

go zaimportować do Excela w ce-

lu dalszej analizy zapisanych para-

metrów.

Eksperymentalnie program uru-

chomiony został w osiedlowej sie-

ci komputerowej w celu analizy za-

leżności i powtarzalności monitoro-

wanych zjawisk. Można się spodzie-

wać, że charakterystyka ruchu bę-

dzie inna w przypadku sieci osiedlo-

wej, inna w sieci biurowej, a jeszcze

inna w sieci w irmie zajmującej się

hostingiem. Analiza zebranych da-

nych pokazała, istnienie podwójnej

okresowości (dobowej i tygodnio-

wej). Można spodziewać się także,

że w sieci wystąpi okresowość rocz-

na, jakkolwiek analizowane szeregi

były zbyt krótkie by to wykazać.

Na wykresie 1. widoczna jest

okresowość dobowa. Można zauwa-

żyć określone wartości liczby pa-

kietów w odpowiednich godzinach

w czasie doby. Widoczne jest rów-

nież wzmożenie ruchu w weekend

(24.06.06-25.06.06).

Napisany preprocesor zapisuje

25 parametrów przechwyconego ru-

chu sieciowego:

Co to jest Snort

Snort http://www.snort.org jest dostep-

nym na licencji GNU systemem detek-

cji włamań (IDS). Na stronach Snorta

można znaleźć jego dystrybucje dla

systemów linux i Windows oraz przygo-

towaną specjalnie dla początkujących

wersję w postaci maszyny wirtualnej

VMWare. Snort umożliwia dołączanie

preprocesorów danych implementują-

cych własne mechanizmy detekcji wła-

mań (jednym z nich jest opisany w ar-

tykule preprocesor Anomaly Detection

http://www.anomalydetection.info) , po-

trai również współpracować z progra-

mami zewnętrznymi, dzięki czemu

można rozszerzać jego funkcjonal-

ność na przykład o system aktywnej

odpowiedzi czy o wizualizację staty-

styk włamań za pomocą stron www.

Systemy wykrywania włamań dzieli

się zazwyczaj na systemy detekcji nad-

użyć (oparte o bazę sygnatur, działają-

ce analogicznie do programów antywi-

rusowych czy zwalczajacych malware)

oraz systemy detekcji anomalii – reagu-

jące na nietypowe zachowania sieci lub

komputera. Snort jest systemem wy-

korzystującym sygnaturową detekcję

nadużyć, jakkolwiek można – dzięki je-

go modularnej budowie – próbować za-

implementowac w nim również mecha-

nizmy detekcji anomalii. Jedną z pierw-

szych prób był eksperymentalny pre-

procesor SPADE ( Statistical Packet

Anomaly Detection Engine ) pozwala-

jący zgromadzić charakterystyki, pa-

kietów, w tym statystyki ich występo-

wania. O ile nam jednak wiadomo, pro-

jekt ten po skomercjalizowniu jako SPI-

CE nie jest już rozwijany, natomiast je-

go starą wersję (włącznie z kodem

źródłowym) można znaleźć pod ad-

resem http://www.bleedingsnort.com/

cgi-bin/viewcvs.cgi/?cvsroot=SPADE.

Ciekawym pomysłem jest rów-

nież projekt Snort+AI wykoprzy-

stujący sztuczne sieci neurono-

we do wykrywania skanowania

portów http://afrodita.unicauca.edu.co/

%7Eaarboleda/snort_ai.htm

Trochę statystyki

Aby móc mówić o anomaliach na-

leży przede wszystkim zecydować

się, co uznajemy za normalny ruch

sieciowy. Oczywiście charaktery-

styka każdej sieci będzie wyglą-

dała inaczej, koniecznym jest więc

zaimplementowanie metod pozwa-

lających na nauczenie systemu

charakterystyki sieci, w której bę-

dzie pracował. Na obecnym eta-

pie rozwoju opisywanego progra-

mu zostały do tego wykorzystane

proste mierniki statystyczne (śred-

nie natężenie ruchu określonego

typu oraz odchylenie standardowe,

rzecz jasna liczone osobno dla róż-

nych pór doby).

Pierwszym etapem tworzenia

systemu była implementacja apli-

kacji współpracującej z systemem

Snort, której zadaniem miało być

zapisywanie do pliku określonych

parametrów ruchu przechwycone-

go przez Snorta. Po przejrzeniu

dokumentacji Snorta (bardzo ską-

pej) i przeanalizowaniu jego ko-

• Liczba pakietów TCP,

• Liczba wysłanych pakietów TCP,

• Liczba odebranych pakietów TCP,

Rysunek 1. Wykres 1

www.hakin9.org

hakin9 Nr 3/2007

Obrona

• Liczba pakietów TCP wewnątrz

sieci LAN,

• Liczba datagramów UDP,

• Liczba wysłanych datagramów

UDP,

• Liczba odebranych datagramów

UDP,

• Liczba datagramów UDP we-

wnątrz sieci LAN,

• Liczba pakietów ICMP,

• Liczba wysłanych pakietów

ICMP,

• Liczba odebranych pakietów ICMP,

• Liczba pakietów ICMP wewnątrz

sieci LAN,

• Liczba pakietów z włączonymi

lagami SYN i ACK,

• Liczba wysłanych pakietów port

80 (usługa WWW),

• Liczba odebranych pakietów port

80 (usługa WWW),

• Liczba wysłanych pakietów port

53 (usługa DNS),

• Liczba odebranych pakietów port

53 (usługa DNS),

• Prędkość wysyłania danych w

kB/s (TCP/IP),

• Prędkość ściągania danych w

kB/s (TCP/IP),

• Prędkość wysyłania danych port

80 w kB/s (TCP/IP, WWW),

• Prędkość ściągania danych port

80 w kB/s (TCP/IP, WWW),

• Prędkość wysyłania danych w

kB/s (UDP),

• Prędkość ściągania danych w

kB/s (UDP),

• Prędkość wysyłania danych port

53 w kB/s (UDP, DNS),

• Prędkość ściągania danych port

53 w kB/s (UDP, DNS).

Domyslnie system zapisuje logi co

600sekund (interwał ten może oczy-

wiście być zmieniony przez użytkow-

nika). Po pewnym czasie (im dłuż-

szym tym lepiej) można spróbo-

wać wygenerować proil sieci, czy-

li charakterystykę, która informuje

na przykład o tym, jakie jest śred-

nie natężenie (i odchylenie standar-

dowe) ruchu wychodzącego na port

53 UDP w poniedziałki o godzinie

12:05.

Proil sieci generowany jest za

pomocą osobnej aplikacji o nazwie

ProileGenerator. Program ten wczy-

tuje plik z logami zebranymi przez

preprocesor i na ich podstawie ge-

neruje plik proilu. Zapisywany jest

on w katalogu /etc pod nazwą pro-

ile.txt. W pliku proilu określone są

wartość średnia i odchylenie stan-

dardowe każdego z analizowanych

typów ruchu dla każdego dnia tygo-

dnia i godziny.

W zasadzie powinniśmy poddać

zebrane dane szeregowi testów sta-

tystycznych, żeby sprawdzić jakie-

mu rozkładowi podlegają, jednak na

tym etapie wykorzystaliśmy po pro-

stu średnią i odchylenie standardo-

we. Za anomalię system uzna natę-

żenie ruchu odbiegające od średniej

o więcej niż m odchyleń standardo-

wych:

Gdzie:

- aktualna wartość natężenia

ruchu danego typu,

- wartość średnia ruchu (obli-

czona dla danych historycznych),

m – mnożnik,

- odchylenie standardowe odczy-

tane z proilu (obliczone dla danych

historycznych).

System sprawdza czy aktual-

nie zmierzona wartość ruchu znaj-

Rysunek 2. Wykres 2

Preprocesory

Akwizycja

danych

Dekoder

Pakietów

Preprocesor

AnomalyDetection

Silnik

Detekcji

Pluginy

wyjściowe

Logi

Profil sieci

Generator profilu

sieci

Rysunek 3. Schemat ideowy systemu. Elementy zaznaczone na niebiesko

są częściami systemu AnomalyDetection.

hakin9 Nr 3/2007

www.hakin9.org

Detekcja anomalii ruchu sieciowego w programie Snort

duje się w przedziale ograniczo-

nym przez wartość średnią, do któ-

rej została dodana wartość odchy-

lenia standardowego pomnożona

przez ustaloną przez użytkowni-

ka wartość mnożnika, oraz warto-

ścią średnią, od której została od-

jęta wartość odchylenia standardo-

wego pomnożona przez ustaloną

przez użytkownika wartość mnoż-

nika. Jeśli zmierzona wartość nie

znajduje się w tym przedziale, ge-

nerowany jest alert o odpowied-

niej treści (ruch za duży lub za

mały oraz typ ruchu). Oczywiście

wartość mnożnika m ustala admi-

nistrator programu. Sprawdzaniu

podlegają:

nie przechwyconego ruchu z proi-

lem, drugim programem jest gene-

rator proili.

Przepływ danych w systemie ob-

razuje schemat ideowy systemu (Ry-

sunek 3.).

Listing 1. Struktura pliku nagłówkowego

1 #ifndef __SPP_PREPROCESOR_H__

2 #deine __SPP_PREPROCESOR_H__

3 void SetupPreprocesor ( void );

4 typedef struct _PreprocStruct {

5 int x ;

6 char * string ;

7 } PreprocStruct ;

8 int PreprocCounter = 0 ;

9 void mySecondFunction ( char * str );

10 extern PreprocStruct mySecondStruct ;

11 # endif

Listing 2. Struktura pliku spp_template.c jest następująca:

• Ruch TCP,

• Ruch ICMP,

• Ruch UDP,

• Ruch WWW,

• Ruch DNS,

• Liczba otwartych połączeń,

• Prędkość wysyłania danych,

• Prędkość odbierania danych.

1 #include <sys/types.h>

2 # include "plugbase.h

3 #include " decode . h "

4 #include " spp_preprocesor . h ”

5 void PreprocesorInit ( u_char * args );

6 void PreprocesorFunc ();

7 void PreprocesorCleanExitFunction ();

8 void PreprocesorRestartFunction ();

9 void SetupPreprocesor ( void ) {

10 printf ( "Rejestruje preprocesor...

Na kolejnym wykresie przedsta-

wiono statystykę ruchu TCP wraz

z miejscami, w których wygenero-

wane zostały alerty. Linią przery-

waną zaznaczona jest granica wy-

znaczona przez dodanie i odję-

cie od wartości średniej odchyle-

nia standardowego pomnożone-

go przez 2,5. Na większości wy-

kresów widać ją tylko ponad da-

nymi, które są zaznaczone na żół-

to. Jest to spowodowane tym, że

gdy wartość graniczna schodzi-

ła poniżej zera jej wartość usta-

wiana była na zero (pojęcie ujem-

nego natężenia ruchu sieciowego

nie ma sensu fizycznego). Czer-

wone krzyżyki oznaczają sytu-

acje, w których wygenerowany zo-

stał alert.

\n " );

11 RegisterPreprocessor

( "preprocesor" , PreprocesorInit );

12 }

13 static void PreprocesorInit

( u_char * args ) {

14 ParsePreprocesorArgs (( char *)

args );

15 AddFuncToPreprocList

( PreprocesorFunc );

16 AddFuncToCleanExitList

( PreprocesorCleanExitFunction ,

NULL );

17 AddFuncToRestartList

( PreprocesorRestartFunction ,

NULL );

18 }

19 void PreprocesorFunc

( Packet * p ) {

20 printf ( "Przyszedl pakiet \n " );

21 }

22 void PreprocesorRestart

Function () {

Parę szczegółów

System składa się z dwóch napi-

sanych przez nas programów. Jed-

nym z nich jest preprocesor reali-

zujący zapisywanie parametrów ru-

chu przechwyconego przez Snorta

w określonych odcinkach czasu oraz

porównywanie parametrów aktual-

23 }

24 void PreprocesorCleanExit

Function () {

25 }

www.hakin9.org

hakin9 Nr 3/2007

Obrona

Preprocesory

Preprocesory są to dołączalne mo-

duły programu Snort. W przepływie

danych znajdują się one przed sil-

nikiem detekcji wykorzystującym re-

guły i są wywoływane w momen-

cie nadejścia pakietu. Snort jest

napisany w języku C, zatem pre-

procesory pisane są również za-

zwyczaj w C. Informacje na te-

mat preprocesorów dołączonych

do programu Snort znaleźć można

pod adresem: http://www.snort.org/

docs/snort_htmanuals/htmanual_

2.4/node11.html

Preprocesor powinno się pisać

w momencie, gdy nie jesteśmy w

stanie osiągnąć pewnej funkcjo-

nalności systemu poprzez napisa-

nie reguły. Ważne jest aby prepro-

cessor działał z rozsądną prędko-

ścią. Napisanie zbyt skomplikowa-

nego obliczeniowo preprocesora

(bardzo istotna jest optymalizacja

kodu) lub zbyt dużej ich liczby mo-

że spowodować ogólny spadek wy-

dajności systemu.

Autorzy programu dołączyli do

źródeł Snorta szablony preproce-

sora. Można je znaleźć w katalogu

$SNORT _ DIR/templates . Są to dwa

pliki:

W liniach 9-12 zdeiniowana jest

funkcja rejestrująca preprocesor w

Snorcie (prototyp funkcji Register-

Preprocessor() znajduje się w pliku

plugbase.h, jej argumenty to nazwa

preprocesora z pliku koniguracyjne-

go oraz funkcja inicjalizująca). Kolej-

ne 6 linii to deinicja funkcji inicjalizu-

jącej preprocesor. W ciele tej funkcji

znajdują się kolejno:

-funkcja analizująca argumenty z

pliku koniguracyjnego;

-funkcja dodająca funkcję głów-

ną preprocesora do listy preproce-

sorów Snorta;

-funkcja rejestrująca funkcję wy-

woływaną przy zamykaniu aplikacji

przez ctrl+c;

-funkcja rejestrująca funkcję wy-

woływaną przy restartowaniu apli-

kacji.

Od linii 19 znajdują się deinicje

funkcji głównej preprocesora wy-

woływanej przez Snorta w momen-

cie przechwycenia pakietu oraz de-

inicje funkcji wywoływanych przy

zamykaniu i restartowaniu aplika-

cji. Te trzy funkcje budują (mery-

toryczną) funkcjonalność prepro-

cesora.

Po napisaniu, pliki źródłowe oraz

nagłówkowe preprocesora należy

skopiować do katalogu $SNORT _ DIR/

src/preprocessors . Aby dodać pre-

procesor do systemu Snort nale-

ży przed kompilacją całego syste-

mu kolejno:

1. Wyedytować plik $SNORT _ DIR/

src/plugbase.c:

dodać pliki nagłówkowe naszego

preprocesora :

#include “preprocessors/spp _

nowy.h” //przykladowa nazwa pre-

procesora

dodać do ciała funkcji InitPrepro-

cessors() funkcję rejestrującą pre-

procesor

2. Wyedytować plik $SNORT_

DIR/src/preprocessors/Makefile

(jeśli już został wygenerowany)

lub $SNORT _ DIR/src/preprocessors/

Makeile.in (jeśli jeszcze nie zo-

stał wygenerowany przez polecenie

./conigure) i dodać:

W sekcji l ibspp _ a _ SOURCES =

spp _ arpspoof.c spp _ arpspoof.h (…)

spp _ spp _ nowy.c spp _ spp _ nowy.h

//spp _ nowy.* są to przykładowe na-

zwy preprocesora

W sekcji am _ libspp _ a _ OBJECTS

= (…)str _ search.$(OBJEXT) spp _

spp _ nowy.$(OBJEXT)

Należy skompilować (lub prze-

kompilować) Snorta za pomocą po-

lecenia: make, następnie zainstalo-

wać poleceniem: make install.

Po kompilacji należy dopisać do

pliku koniguracyjnego Snorta, któ-

ry znajduje się domyślnie w etc/

snort.conf , w sekcji preprocesorów

stworzony przez nas preprocesor:

preprocessor nazwa_preprocesora:

argumenty.

Jeśli wszystko poszło zgodnie z

planem pozostaje tylko cieszyć się

nową funkcjonalnością.

Przedstawiony projekt jest

oczywiście jeszcze na bardzo

wczesnym etapie rozwoju. Warto

zastanowić się na przykład nad tym

czy system powinien mieć możli-

wość automatycznego uczenia się,

zmian proilu sieci (można to zreali-

zować choćby przez cykliczne wy-

woływanie generatora proili połą-

czone z usuwaniem informacji o

najstarszych historycznych warto-

ściach ruchu). Takie metody sto-

suje się zazwyczaj w tego typu

rozwiązaniach, żeby uniknąć nad-

miaru fałszywych alertów typu fal-

se positive. W takich przypadkach

atakujący może jednak przyuczyć

system do nierozpoznawania jego

aktywności powoli oswajając go ze

zmianami proilu. Innymi elementa-

mi, które planujemy w ramach roz-

wijania systemu są: tworzenie pro-

ilu dla każdego hosta w sieci, ana-

liza i rozpoznanie rozkładów staty-

stycznych poszczególnych typów

ruchu, implementacja analizy za-

leżności pomiędzy poszczególnymi

parametrami (np. stosunek liczby

wysłanych pakietów TCP do liczby

odebranych pakietów TCP), anali-

za poprawności uzyskanego wyni-

ku przed dodaniem go do logów,

zapis i analiza pakietów przechwy-

conych w momencie wykrycia ano-

malii. Oczywiście wszystkich za-

interesowanych zapraszamy ser-

decznie do współpracy. l

spp_template.h,

spp_template.c.

Instrukcje w liniach 1-3 są wymaga-

ne – pierwsze dwie to instrukcje ste-

rujące dla kompilatora, a trzecia to

prototyp funkcji rejestrującej bieżący

preprocesor przy inicjalizacji prepro-

cesorów przez Snorta. Pozostałe de-

klaracje są opcjonalne i mają sens w

przypadku, gdy zmienne będą uży-

wane przez kilka preprocesorów.

Pierwsze cztery instrukcje dołą-

czają niezbędne pliki nagłówkowe.

Kolejne instrukcje deklarują prototy-

py kolejno:

• Funkcji inicjalizującej preproce-

sor

• Funkcji głównej preprocesora

• Funkcji wywoływanej przy wy-

chodzeniu z programu

• Funkcji wywoływanej przy restar-

cie aplikacji

hakin9 Nr 3/2007

www.hakin9.org

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: