KORELACJA W WYKRYWANIU ANOMALII

Tomasz Jordan Kruk

Jarosław Wrzesień

Zakład Jakości Usług Sieci

Instytut Automatyki i Informatyki Stosowanej

Naukowa i Akademicka Sieć Komputerowa

Politechnika Warszawska

Wstęp

Wśród metod wykrywania skanowania portów można wyróżnić dwa główne nurty:

wykrywanie wykorzystujące wyszukiwanie sygnatur możliwych skanowań oraz wykrywanie oparte na analizie anomalii ruchu sieciowego [4]. Tematyka artykułu obejmuje drugi z powyższych nurtów.

W artykule opisano własne zaprojektowane i wstępnie zaimplementowane rozwią-

zanie [10], które umożliwia wykrywanie skanowania w oparciu o badanie wskaźnika anomalii pakietów i ich korelacje z wykorzystaniem algorytmów optymalizacji w przestrzeni dyskretnej oraz własnych funkcji heurystycznych.

1. Snort i Spade

System Snort [7, 2] jest wielozadaniowym narzędziem mającym pomagać w za-bezpieczaniu systemu komputerowego przed intruzami. Snort określany jest mianem lekkiego sieciowego systemu wykrywania intruzów.

Łatwość tworzenia reguł, według których pracuje program oraz fakt, że Snort jest dostępny na wiele platform systemowych czyni system atrakcyjnym dla osób zabezpieczających sieci komputerowe. Bardzo ważną cechą systemu jest darmowość w rezultacie przyjęcia modelu licencjonowania zgodnego z GNU General Public License. System pełni często funkcję uzupełniającą w stosunku do rozwiązań komercyjnych znajdując zastosowanie w sytuacjach, gdy odpowiednie reguły należy przygotować natychmiast, nie czekając na uaktualnienia od producentów systemów komercyjnych.

System Snort w założeniu autorów jako sieciowy lekki system wykrywania włamań (ang. lightweight NIDS) przeznaczony miał być jedynie do sieci o niewielkim natężeniu ruchu. Jednakże obecne wersje doskonale radzą sobie również z połączeniami stumega-bitowymi.

1

Snort może pracować w trzech trybach. Pierwszym z nich jest sniffer, drugim packet logger, zaś trzecim network intrusion detection, NIDS. W trybie sniffer działanie systemu ogranicza się do wyświetlania nagłówków pakietów, natomiast w trybie packet logger do zapisywania w uporządkowanej postaci przefiltrowanych wedle zadanych reguł (adres IP, protokuł, itp.) pakietów.

Wywołanie programu Snort w trybie network intrusion detection spowoduje przykładanie zdefiniowanych reguł do każdego pakietu w celu sprawdzenia, czy nie powinna zostać podjęta któraś z akcji zdefiniowanych w pliku konfiguracyjnym.

Snort w wersji 2.0 posiada bardzo silne narzędzie nazwane analizatorem przepływu protokołu (ang. protocol flow analyser). Analizator ten ma za zadanie rozbicie protokołów warstwy aplikacji na strumienie do serwera i do klienta. Program ma możliwość zdobycia dokładniejszych informacji na temat określonego protokołu. Dzięki tym in-formacjom można decydować, którą, jeśli w ogóle, część protokołu sprawdzać. Jest to metoda optymalizacji czasu analizy pakietów.

Wspominane wcześniej reguły programu Snort służą do zdefiniowania, jakie akcje program ma podjąć w przypadku zaobserwowania określonej aktywności w sieci (znalezienia pakietów o ustalonej zawartości). Reguły tworzone są w prostym ale bogatym języku. Zawierają dwie logiczne części: nagłówek reguły i jej opcje. Nagłówek zawiera typ reguły, protokół, źródłowy oraz docelowy adres IP, maski sieciowe a także informacje o źródłowych i docelowych portach. Część opcji reguły, umieszczana w nawiasie, zawiera informacje alarmowe oraz informacje o tym, który fragment pakietu powinien zostać przeanalizowany. Poniżej zaprezentowano przykładową regułę programu SNORT: alert tcp any any -> 192.168.1.0/24 111

(content:"|00 01 86 a5|"; msg:"mountd access")

Celem powyższej reguły jest zgłoszenie alarmu oraz wypisanie informacji z pola msg, jeżeli do sieci klasy C o adresie 192.168.1.0 na port 111 nadejdzie pakiet TCP z dowolnego portu dowolnego adresu IP zawierający ciąg bajtów określony w polu content.

Reguły programu Snort można tworzyć samemu, można również pobierać gotowe pliki reguł ze strony producenta.

Wykrywanie skanowania portów często nie jest traktowane z należytą powagą. Ad-ministratorzy i specjaliści do spraw bezpieczeństwa wolą koncentrować uwagę na do-konanych włamaniach i zapobiegać ich efektom, niż poświęcić czas na analizowanie i zapobieganie skanowaniu portów, które przeważnie poprzedza przeprowadzenie ataku.

Program Snort standardowo wyposażony jest w dwa moduły umożliwiające proste wykrywanie nieskomplikowanych skanowań portów.

2

Pierwszy z modułów, Portscan Detector, wykrywa skanowania określone jako próby połączeń TCP do więcej niż

portów w ciągu

sekund lub wysłanie pakietów UDP

do więcej niż

portów w ciągu

sekund. Porty mogą być rozłożone na dowolnej

liczbie adresów IP, może też być to jeden konkretny numer portu, jeśli skanowanych jest wiele adresów IP.

Moduł wykorzystywany przez Snort potrafi wykrywać skanowania wysyłane z jednej maszyny na jedną maszynę oraz z jednej maszyny na wiele maszyn. Przyszła wersja ma sobie radzić również ze skanowaniami zapoczątkowanymi na wielu maszynach. Mo-duł ten wykrywa również tak zwane pakiety stealth scan czyli pakiety z ustawionymi niestandardowymi flagami TCP.

Dodatkiem do modułu wykrywającego skanowanie portów jest w programie Snort moduł pozwalający na wykluczenie z zakresu analizy systemu wykrywania określonych maszyn, takich jak serwery czasu, serwery usług DNS i NFS. Moduł nosi nazwę Portscan Ignorehosts.

Drugi moduł służący do wykrywania skanowania portów, Portscan2, jest bardziej zaawansowany. Do funkcjonowania wymaga modułu Conversation, który umożliwia mu wykrycie nowo nawiązywanych połączeń i dostarcza podstawowych informacji na temat komunikujących się protokołów. Moduł ten ma za zadanie umożliwić wykrycie szybkich skanowań, takich jak na przykład rapid scan programu Nmap.

Oba moduły dostarczane standardowo wraz z programem Snort nie potrafią wykrywać skanowań, które atakujący zamaskował w bardziej wyrafinowany sposób. Praktycz-nie rzecz biorąc nie są w stanie wykryć większości skanowań przeprowadzonych przez doświadczonego intruza.

1.1. Spade

Jednym z modułów, jeszcze do niedawna standardowo dostarczanym z pakietem

Snort, a teraz dostępnym jedynie osobno, jest Spade. Spade (ang. Statistical Packet Anomaly Detection Engine) jest częścią pakietu Spice / Spade tworzonego przez firmę Silicon Defense [1], którego celem jest pomoc w wykrywaniu ukrytych i nietypowych skanowań portów. Moduł Spade jest odpowiedzialny za analizowanie przychodzących pakietów sieciowych i nadawanie im wskaźnika anomalii. Wskaźnik ten określa jak bardzo dany pakiet różni się od pakietów standardowo pojawiających się w badanej sieci. W celu nadawania pakietom wskaźników anomalii, Spade przeprowadza prostą analizę statystyczną. Znając standardowy ruch w sieci, Spade może określić jak bardzo nieprawdopodobne jest pojawienie się określonego pakietu w tej sieci. Do tego celu zaimplementowano w programie cztery tryby liczenia prawdopodobieństwa pojawienia się danego pakietu w badanej sieci. Tryby te to:

3

1. wyznaczenie przybliżonej wartości P(sip, sport, dip, dport) z wykorzystaniem sieci Bayes’a

2. wyznaczanie P(sip, sport, dip, dport)

3. wyznaczanie P(sip, dip, dport)

4. wyznaczanie P(dip, dport)

gdzie sip to źródłowy adres IP a sport to port źródłowy, zaś dip to docelowy adres IP, natomiast dport to port docelowy.

Aby praca ze Spade miała sens, program musi mieć możliwość zapamiętywania stanu sieci, w której pracuje. Jeżeli stan taki nie byłby zapamiętywany, po każdym uru-chomieniu Spade musiałby od początku budować tabele prawdopodobieństw dla danej sieci. Bez takich tabel nie jest możliwe wyznaczanie wskaźnika anomalii pakietów.

Właśnie z tego powodu Spade posiada funkcję zapisywania i odtwarzania stanu.

Funkcja ta wykorzystuje plik, do którego co 50000 pakietów zapisywane są dane dotyczące ruchu sieciowego.

Aby możliwe było określenie czy pakiet jest anomalią, konieczne jest ustalenie poziomu prawdopodobieństwa, po przekroczeniu którego pakiet zostanie zarejestrowany.

Aby ułatwić ustawianie poziomu raportowania, programiści zaimplementowali tryby jego ustalania. Jednym z trybów jest tryb szukania progu raportowania. Uruchamia go się na ustalony czas, by nauczyć system aktualnego ruchu sieciowego i na tej bazie wyznaczyć poziom raportowania, który zgłaszać będzie zadaną jako drugi parametr liczbę alarmów.

2. Korelator pakietów

Oprogramowanie Spade miało zgłaszać raporty do narzędzia korelującego informacje o zgłaszanych pakietach nazwanego przez twórców Spice (ang. Stealthy Probing and Intrusion Correlation Engine) [1]. Wstępne wersje rozwiązania dostępne były jako kod otwarty wraz z pakietem Snort i modułem Spade . Potem firma utajniła projekt aktualnie oferując jedynie własny komercyjny produkt zabezpieczający sieci, a podobno wykorzystujący wewnętrznie dopracowany już tandem Spice / Spade wraz z oprogramowaniem Snort .

Dlatego też autorzy niniejszego artykułu postawili sobie za cel próbę zaprojekto-wania i stworzenia oprogramowania korelującego zdarzenia monitorowane przez wciąż jeszcze dostępny za darmo moduł Spade systemu Snort . Dalsza część artykułu omawia własne zaproponowane rozwiązanie wywodzące się z koncepcji zawartych we wczesnych wersjach komercyjnego produktu Spice .

Moduł korelujący przejmuje pakiety z przekroczoną progową wartością wskaźnika 4

1

2

3

4

Rysunek 1. Graf korelacji zdarzeń.

anomalii. Jego celem jest odpowiedź na pytanie, czy dany pakiet został zarejestrowany przypadkowo, czy też może należy do ukrytego skanowania lub ataku.

Korelator musi sprostać dwóm wyzwaniom:

1. Jakimi kryteriami kierować się przy dodawaniu pakietów (zdarzeń) do grafu korelacji. Wiadomo, że należy stworzyć odpowiednie heurystyki pomagające w stwierdze-niu co grupować, nie wiemy jednak jakie heurystyki będą skuteczne w określonym przypadku ataku czy skanowania.

2. W procesie korelacji mała jest szansa skuteczności algorytmów deterministycznych.

Dlatego też używane powinny być algorytmy należące do rodziny algorytmów ewo-lucyjnych, lub jak zaproponowali inżynierowie Silicon Defense, odpowiednio zmo-dyfikowane algorytmy fizyki statystycznej.

2.1. Graf korelacji

Korelator musi przechowywać nadchodzące zdarzenia w strukturze danych, która pozwala mu również zachować informacje o zależnościach występujących pomiędzy nimi. Najlepszy do tego celu jest nieskierowany graf, w którym wierzchołek oznacza zdarzenie a krawędź zależność pomiędzy dwoma zdarzeniami.

Ze względu na dużą liczbę analizowanych zdarzeń oraz możliwość występowania zależności pomiędzy wieloma wierzchołkami, zdecydowano się wykorzystać dynamiczną strukturę danych, która nie ma ograniczeń na liczbę elementów. Struktura ta została zaimplementowana jako graf, lub dokładniej jako dynamiczna lista list.

Załóżmy, że do korelatora nadeszły cztery zdarzenia [Rys. 1]. Zdarzenia te będą reprezentowane przez cztery wierzchołki grafu. Wierzchołki będą stanowić elementy dynamicznej listy utworzonej przez program korelatora. Jeżeli między zdarzeniami wy-stąpią jakieś zależności, będą one reprezentowane przez krawędzie grafu. Aby korelator 5

1

2

3

4

3

3

1

3

4

4

1

2

Rysunek 2. Struktura danych opisująca graf korelacji.

miał łatwy dostęp do informacji o wierzchołkach, pomiędzy którymi występują zależ-

ności, przechowuje informacje na temat krawędzi jako listy dynamiczne wskaźników na wierzchołki zależne.

Na rysunku 2 przedstawiono strukturę danych odpowiadającą grafowi korelacji z rysunku 1. Przykładowo, zależność pomiędzy wierzchołkami 1 i 4 reprezentowana jest przez krawędź pomiędzy tymi wierzchołkami. Na rysunku 2 krawędź ta reprezentowana jest przez dwa elementy dwóch list. Reprezentacja taka jest nadmiarowa, jednak jest to rekompensowane wzrostem szybkości działania algorytmów dodawania zdarzeń do grafu oraz usuwania zdarzeń z grafu.

Kiedy korelator otrzymuje z programu analizującego nowe zdarzenie, musi dodać je do grafu. Ponieważ graf nie przechowuje informacji o powiązaniach między dowolną parą zdarzeń, a tylko między danym zdarzeniem a grupą zaledwie kilku wybranych dla danego innych zdarzeń, od miejsca wstawienia zdarzenia w graf zależeć będzie jakość wyszukiwania grup zdarzeń stanowiących skanowanie.

W grafie może być już wiele wcześniej dodanych zdarzeń, nawet tysiące. Dlatego też moc wiązania nowego zdarzenia nie może być testowana dla wszystkich zdarzeń znajdujących się w grafie. Aby proces dodawania nowego zdarzenia do grafu przyspieszyć, należy wykorzystać odpowiedni algorytm optymalizacji.

W pracy tej wybranym algorytmem jest algorytm symulowanego wyżarzania (ang.

simmulated annealing) [9, 6]. Metoda symulowanego wyżarzania została zaczerpnięta z fizyki statystycznej, gdzie służyła do znajdowania globalnego minimum energetycznego systemów fizycznych. Zastosowania tej metody rozszerzyły się znacznie i dziś jest wykorzystywana do rozwiązywania wielu problemów, w których potrzebne jest znalezienie globalnego ekstremum funkcji przy występowaniu ekstremów lokalnych.

6

2.2. Algorytm wyżarzania

Symulowane wyżarzanie to algorytm z rodziny algorytmów Generuj i Testuj i stanowi modyfikację algorytmu wspinaczki (ang. Simple Hill Climbing), w którym dopuszcza się na początku przejścia ze stanu bieżącego także do stanów gorszych. Dzięki temu można uniezależnić się od punktu startowego i uzyskać możliwość przebadania znacznie większego obszaru przestrzeni rozwiązań.

Symulowane wyżarzanie wzorowane jest na fizycznym procesie nazywanym wyża-

rzaniem, w którym to pewne ciała, np. metal, są rozgrzewane a następnie stopniowo schładzane aż do osiągnięcia krystalizacji. Celem tego procesu jest osiągnięcie jak naj-mniejszego stanu energetycznego obrabianego ciała.

Energia stanu ciała odpowiada funkcji celu, a absolutne minimum tej energii - minimum globalnemu. W procesie powolnego wyżarzania, krystalizacji ciała towarzyszy globalne zmniejszanie energii, ale są również dopuszczalne stany, którym towarzyszy chwilowe jej zwiększenie. Dzięki dopuszczeniu chwilowego wzrostu stanu energetycznego możliwe jest opuszczenie minimum lokalnego, które może pojawić się w trakcie procesu. Dopiero zejście z temperaturą do zera absolutnego uniemożliwia jakiekolwiek podniesienie poziomu energetycznego. Wówczas to zmiany energetyczne mogą zacho-dzić już tylko w kierunku minimum.

Prawdopodobieństwo przejścia do wyższego stanu energetycznego określa wzór:

(1)

gdzie:

wartość o jaką zwiększyła się energia stanu,

temperatura przy jakiej następuje przejście do wyższego stanu energetycznego,

stała Boltzmann’a.

Metoda symulowanego wyżarzania, będąc odpowiednikiem fizycznego procesu wy-

żarzania, uznawana jest za jeden z nielicznych algorytmów umożliwiających praktycz-ne uzyskanie minimum globalnego funkcji wielu zmiennych. Algorytm samej metody przedstawia się następująco:

1. Wybierz stan początkowy

(ang. Current State).

2. Ustal początkową temperaturę

,

, oraz stan

(ang. Best So Far),

"!

.

#$!%

&

3. Dopóki

i pozostają stany nie wykorzystane jako

, wykonaj:

('*)

&

a) Wybierz jeden z niewykorzystanych stanów i nazwij go

(ang. New State).

+,

b) Oblicz różnicę energii w stanach

i

, -

/.

/.

.

+,

&

+02143

&21

7

c) Jeżeli 65

, to

oraz

.

)

&7

+,

"!8

+,

d) Jeżeli -

, wówczas

z prawdopodobieństwem opisanym

'

)

&9

+0

wzorem numer 1.

e) Zmniejsz temperaturę

=?>

, gdzie = jest liczbą z przedziału .

.

;:<(

)@:BAC1

4. Zwróć

jako rozwiązanie i zakończ algorytm.

#$!

Powyższa idea algorymu wyżarzania musiała być dostosowana do zastosowania w realizacji naszego problemu do optymalizacji, czyli znalezienia optymalnego miejsca w grafie korelacji do dołączenia nowego zadanego zdarzenia.

Zmodyfikowano kierunek optymalizacji z minimalizacji do maksymalizacji. Maksy-malizowaną wielkością jest w tym przypadku siła powiązania pomiędzy zdarzeniami.

Zastąpiono pojęcia temperatury i stygnięcia, pojęciem maksymalnej liczby cykli przebiegu algorytmu

. Oznacza to, że nie jest sprawdzana temperatura, a tylko numer cyklu

DEF

przebiegu algorytmu. W związku z tym we wzorze na prawdopodobieństwo przejścia do wyższego stanu energetycznego temperaturę

zastąpiono tak zwanym planem schła-

dzania (ang. cooling schedule), którego wartość odpowiada temperaturze w zadanym jako argument cyklu algorytmu. Usunięto też stałą Boltzmana , która nie gra roli przy numerycznym wykorzystaniu algorytmu.

Po nadejściu do korelatora każde zdarzenie jest losowo łączone z

zdarzeniami

G

już należącymi do grafu. Jednym z tych zdarzeń jest ostatnio dodane zdarzenie. Jest ono wybierane w celu potencjalnej optymalizacji algorytmu. Następnie dla każdej z G

powstałych w ten sposób par zdarzeń przeprowadzany jest algorytm wyżarzania w celu odnalezienia połączenia optymalnego czyli najsilniejszego.

Prawdopodobieństwo wybrania wierzchołka o mniejszej sile powiązania niż wierzchołek bieżący wyraża się wzorem:

J KLKNMPORQSUTWVYXFZ\[]MPZ_^`Jbadc

MP]

ZYi

H

I

(2)

Ce_f

fhg

fhj

gdzie:

k

różnica siły powiązań z wstawianym zdarzeniem zdarzeń: dotąd wybranego i aktualnie rozpatrywanego,

numer cyklu przebiegu algorytmu,

&lnmpoLqrms

maksymalna możliwa do osiągnięcia siła powiązania pomiędzy wierz-

chołkami,

ovu

q}o

.

B|

wskaźnik wpływający na prawdopodobieństwo powiązania z gor-

&tbt

Gwx"y{z

1

szym stanem, zależny od cyklu ,

Zmodyfikowany algorytm wyżarzania wygląda następująco:

8

1. Wybierz stan początkowy

.

~

2. Ustal początkowy cykl przebiegu algorytmu

.

A

3. Dopóki

5

wykonaj:

DF

a) Wybierz losowo jeden z wierzchołków sąsiadujących z

tak, aby nie był już

~

połączony z . Jeżeli wybrany wierzchołek jest już połączony z

wybierz jed-

~

~

nego z jego sąsiadów - i tak dalej, aż wybrany wierzchołek nie będzie połączony z . Wybrany wierzchołek przypisz do

.

~

~+

b) Oblicz różnicę siły powiązania stanu

ze stanem

i ze stanem

, k

~

~?+

~

€lpmpovqrms

.

€lnm@ovqrms

.

.

~+1E3

~-1

c) Jeżeli k

, to

.

'

)

~‚

~?+

d) Jeżeli

5

k

, wówczas

z prawdopodobieństwem wyznaczanym

)

~9

~+

wzorem numer 2.

e) Zwiększ numer cyklu

i przejdź do .

„ƒ…A

†

4. Połącz

z

.

~

~

gdzie:

numer cyklu oraz maksymalna liczba cykli przebiegu algorytmu,

€:‡ˆF

zdarzenie bieżące czyli to, którego połączenie ze zdarzeniem

rozpatrujemy w

~

~

danym cyklu,

zdarzenie następne czyli to, którego połączenie ze zdarzeniem

rozpatrujemy jako

~+

~

ewentualnie bardziej korzystne od połączenia ze zdarzeniem

,

~

&lnmpoLqrms

.

funkcja zawierająca heurystyki określające siłę powiązania wierzchołka do-

1

dawanego z wierzchołkiem, który jest jej argumentem,

k

różnica sił powiązania zdarzenia

ze zdarzeniami

oraz

.

~

~

~+

Dokładniejszego rozwinięcia wymagają dwa określenia: funkcja &lnmpovq}ms . , która 1

ma za zadanie wyznaczyć siłę powiązania zdarzenia (wierzchołka grafu) analizowanego ze zdarzeniem (wierzchołkiem) zadanym jako jej argument, oraz tak zwany plan schładzania reprezentowany w algorytmie przez funkcję

ovu

q}o

.

B|

.

€tCt

G}w‰"yŠz

1

Aby było możliwe dokładne wyznaczenie siły z jaką wierzchołki są powiązane, wykorzystuje się grupy funkcji heurystycznych. Każda grupa może zawierać wiele jed-nostkowych heurystyk, natomiast wszystkie grupy są elementami składowymi jednej funkcji - &lnmpovqrmns . . Funkcje heurystyczne mają za zadanie określić jakość zależności 1

występujących pomiędzy dwoma wierzchołkami. Analizują one informacje na temat te-go, w jaki sposób powiązane są zdarzenia gromadzone w grafie korelacji. Wybór funkcji 9

heurystycznych jest arbitralny i zależy tylko od nas. Istnieje jednak kilka grup funkcji, które wydają się być dobrymi funkcjami startowymi.

Do grup tych należą [8]:

heurystyki równości (ang. equality heuristics), czyli funkcje sprawdzające równoważ-

ność/ identyczność wybranych parametrów, np. identyczność numerów portów, źró-

dłowych adresów IP, protokołów, flag TCP itp.

heurystyki bliskości (ang. proximity heuristics), czyli funkcje sprawdzające bliskość wybranych parametrów, np. portów źródłowych bądź czasu nadejścia pakietów, heurystyki oddalenia (ang. separation heuristics), czyli funkcje sprawdzające oddale-nie wybranych parametrów. Odpowiadają na pytanie, czy różnice wartości określonych parametrów są takie same między wierzchołkiem A i wierzchołkiem B jak między wierzchołkiem B i którymś z sąsiadów wierzchołka B. Mogą dotyczyć np.

czasów nadejścia pakietów oraz docelowych adresów IP,

heurystyki kowariancji (ang. covariance heuristics), czyli funkcje sprawdzające rów-nozmienność wybranych parametrów, tzn, czy tempo zmian wartości kilku parametrów w danych zdarzeniach A i B jest takie samo, oraz czy zmiany te zachodzą z taką samą szybkością pomiędzy zdarzeniem B i sąsiadami zdarzenia B.

Podczas przebiegu algorytmu wyżarzania konieczne jest zastosowanie metody zmniej-szającej prawdopodobieństwo przejścia do stanu o gorszych parametrach. W module korelacji wykorzystywana jest funkcja

ovu

q}o

.

B|

, której wartość może być

€tCt

Gwx"yŠz

1

porównana do temperatury w danym jako argument cyklu algorytmu. W podstawowej wersji algorytmu wyżarzania temperatura obniżana jest proporcjonalnie, w każdym kroku jej wartość jest dzielona przez liczbę z przedziału .

. Możliwe jest jednak

A‹:‡Œ1

obniżanie temperatury w sposób bardziej skomplikowany, co pozwala na regulowanie tempa jej spadku w różnych fazach przebiegu algorytmu. Wartość funkcji CoolingSche-dule() na początku algorytmu równa jest 1 i jest obniżana tak, aby w ostatnim cyklu zejść do 0.

2.3. Właściwe wykrywanie skanowania

Korelator podczas swojej pracy buduje graf przechowujący informacje o zdarzeniach oraz powiązaniach pomiędzy nimi. Sam graf jako struktura nie posiada jednak funkcjo-nalności pozwalającej na zgłoszenie ewentualnie wykrytego skanowania portów. Aby możliwe było znalezienie wśród wszystkich przechowywanych w grafie zdarzeń tych, które są z największym prawdopodobieństwem skanowaniami, konieczne jest zbudowa-nie grupy elementów podejrzanych i sprawdzenie wskaźnika jej anomalii.

10

1,7

4,2

1

2

3

4,1

3,8

4,5

2,0

4,0

3,9

4

5

6

2,7

5,1

4,4

3,2

1,0

7

8

9

Rysunek 3. Rozpoczęcie budowy grupy zdarzeń podejrzanych.

Grupą zdarzeń nazywamy podzbiór grafu korelacji, w którym wszystkie zdarzenia są połączone ze sobą z siłą przekraczającą zadaną wartość progową.

Znalezienie grupy nie oznacza jeszcze tego, że znalezione zostało skanowanie portów. Korelator zgłosi znalezioną grupę tylko wówczas, gdy jej wskaźnik anomalii przekroczy zadaną wartość progową. Wskaźnik anomalii grupy wyznacza się sumując wskaź-

niki anomalii wszystkich należących do niej zdarzeń.

Budowanie grupy przeprowadzane jest przy nadejściu do korelatora nowego zdarzenia. Od nowoprzybyłego zdarzenia graf przeszukiwany jest rekurencyjnie i oznaczane są wszystkie elementy, które w danej chwili połączone są z nim odpowiednio silnymi wiązaniami. Tworzenie grupy kończy się w momencie, gdy nie można znaleźć sąsiadów zdarzeń połączonych siłą większą niż zadana siła progowa.

2.4. Przykład budowy grupy zdarzeń podejrzanych

Zakładamy istnienie grafu jak na rysunku 3 oraz progową wartość siły połączenia równą

. Właśnie dodany do grafu wierzchołek 1 po zastosowaniu algorytmu wyża-

†x:‡

rzania został podłączony do wierzchołków 2 i 4. Zostaje on jako pierwszy dodany do budowanej grupy.

Wartość progowa siły połączenia jest przekroczona tylko dla wiązania z wierzchoł-

kiem 4, więc tylko on zostaje dodany do grupy [Rys. 4].

Wierzchołek 4 jest połączony z trzema wierzchołkami: 1, 2, 7. Ponieważ wierzchołek 1 już należy do grupy, nie jest brany pod uwagę. Wiązania z wierzchołkami 2 i 7 są natomiast silniejsze niż 3,9 i algorytm dodaje oba wierzchołki do grupy [Rys. 5]

11

1,7

4,2

1

2

3

4,1

3,8

4,5

2,0

4,0

3,9

4

5

6

2,7

5,1

4,4

3,2

1,0

7

8

9

Rysunek 4. Budowa grupy zdarzeń podejrzanych - krok 2.

1,7

4,2

1

2

3

4,1

3,8

4,5

2,0

4,0

3,9

4

5

6

2,7

5,1

4,4

3,2

1,0

7

8

9

Rysunek 5. Budowa grupy zdarzeń podejrzanych - krok 3.

12

1,7

4,2

1

2

3

4,1

3,8

4,5

2,0

4,0

3,9

4

5

6

2,7

5,1

4,4

3,2

1,0

7

8

9

Rysunek 6. Budowa grupy zdarzeń podejrzanych - krok 4.

Grupa budowana jest rekurencyjnie, więc w następnym kroku równocześnie rozpatrywane są wierzchołki 7 i 2. Takie zachowanie algorytmu jest tylko teoretyczne. Podczas pracy korelatora wierzchołki 7 i 2 rozpatrywane byłyby kolejno, zgodnie z ich miejscem na liście sąsiadów wierzchołka 4.

Wierzchołek 7 nie posiada sąsiadów powiązanych z nim silniej niż wartość progowa.

Wierzchołek 2 posiada jednego takiego sąsiada - wierzchołek 3 [Rys. 6].

W kolejnych dwóch krokach dodane do grupy zostają jeszcze dwa wierzchołki: 6, 8

[Rys. 7, 8].

Algorytm kontynuuje działanie do momentu, gdy nie ma już sąsiadów powiązanych siłą wyższą niż progowa. Na rysunku 8 przedstawiono ostateczny wygląd grupy zdarzeń podejrzanych.

W momencie zbudowania grupy podejrzanych zdarzeń o odpowiednio wysokim

wskaźniku anomalii, korelator zapisuje do pliku ostrzeżenie oraz dane pakietu, od któ-

rego rozpoczęła się budowa grupy. Przykładowo, dla grupy z rysunku 8 wyświetlone zostałyby dane wierzchołka 1.

Możliwe jest również zapisywanie całej grupy pakietów podejrzanych, jednak może to spowodować obniżenie wydajności programu korelującego. Grupa będzie zgłaszana wielokrotnie jeśli dołączane będą do niej nowe zdarzenia.

Opisane algorytmy i procedury umożliwiają poprawne funkcjonowanie programu korelatora. Poniżej przedstawiono podsumowanie procesu dochodzenia do wykrywania skanowania:

— W momencie nadejścia nowego pakietu sieciowego do komputera jest on przeka-13

1,7

4,2

1

2

3

4,1

3,8

4,5

2,0

4,0

3,9

4

5

6

2,7

5,1

4,4

3,2

1,0

7

8

9

Rysunek 7. Budowa grupy zdarzeń podejrzanych - krok 5.

1,7

4,2

1

2

3

4,1

3,8

4,5

2,0

4,0

3,9

4

5

6

2,7

5,1

4,4

3,2

1,0

7

8

9

Rysunek 8. Ostateczna postać grupy zdarzeń podejrzanych.

14

zywany przez jądro systemu operacyjnego do systemu wykrywania intruzów Snort.

Program ten uruchamia moduł odpowiedzialny za wykrywanie anomalii, Spade, i przekazuje do niego odebrany pakiet.

— Program Spade - wykorzystując zebrane podczas swojej pracy informacje na temat ruchu w chronionej sieci - nadaje pakietowi wskaźnik anomalii zależny od tego, jak bardzo dany pakiet odbiega od standardowego ruchu sieciowego. Pakiet z wartością wskaźnika anomalii przekraczającą poziom niezbędny do jego zgłoszenia zostaje zapisany do pliku rejestru programu Snort oraz wysłany do gniazda, z którego może zostać pobrany przez korelator.

— Po odebraniu nowego zdarzenia z gniazda przez korelator jest ono dodawane do grafu korelacji. Decyzje: w jakim miejscu grafu się znajdzie, do których zdarzeń będzie podłączone oraz jak silne będą to powiązania; zależą od wyniku procesu optymalizacji z wykorzystaniem zadanych funkcji heurystycznych.

— Następnie, po umieszczeniu zdarzenia w grafie, korelator podejmuje próbę zbudowania grupy zdarzeń podejrzanych, opartej na tym zdarzeniu, tak jak w przedstawionym w artykule przykładzie.

— Jeżeli budowa grupy powiedzie się, badany jest jej wskaźnik anomalii. Jeżeli wskaź-

nik ten przekroczy określoną wartość, grupa jest zgłaszana jako grupa podejrzana.

2.5. Dostrajanie parametrów pracy korelatora

O ile cała procedura wykrywania podejrzanych grup zdarzeń w generalnym zarysie została już dobrze zdefionowana, o tyle rzeczywista praktyczna jakość oprogramowania zrealizowanego na bazie powyższych algorytmów zależy od dobrania wartości wielu parametrów. Niestety, w tym przypadku nie zawsze da się znaleźć przekonujące przesłanki do ustalenia takich a nie innych wartości parametrów. W zależności od jakości dostrojenia system wykorzystujący graf zdarzeń może działać bardzo dobrze bądź nie działać w ogóle. Dostrojenie systemu często wymagać będzie dobrania wielu wartości na bazie czysto eksperymentalnej.

Czynnikiem ustalającym ograniczenia górne na wartości pewnych parametrów jest rozmiar i wydajność dostępnych zasobów, w szczególności ilość wolnej pamięci opera-cyjnej (dopuszczalny maksymalny rozmiar grafu) oraz wydajność procesora wymusza-jąca ograniczenie skomplikowania wykorzystywanych algorytmów.

Opisany algorytm może być zatem parametryzowany wartościami następujących elementów:

Liczba cykli przebiegu algorytmu wyżarzania - wartość wpływająca na długość trwa-nia procesu wyżarzania, a więc i jego dokładność i skuteczność. Im dłużej trwa 15

wyżarzanie, tym większe prawdopodobieństwo, że uda się odnaleźć globalne ekstremum – ale również większe obciążenie systemu.

Liczba początkowych połączeń zdarzenia - liczba wiązań ustanawianych dla nowego zdarzenia podczas jego dodawania do grafu korelacji. Utworzenie każdego wiązania jest równoznaczne z koniecznością uruchomienia algorytmu wyżarzania. Im więcej wiązań początkowych zostanie zbudowanych, tym skuteczniej dodaje się kolejne zdarzenia. Tak jak i w poprzednim punkcie, konieczne jest tu wypośrodkowanie skuteczności działania algorytmów i obciążenia systemu.

Plan schładzania - funkcja, która decyduje o sposobie obniżania prawdopodobieństwa przejścia do stanu o gorszych parametrach podczas procesu wyżarzania. Im bardziej skomplikowany jest plan schładzania, tzn. im więcej wykorzystuje funkcji z bibliotek matematycznych, tym bardziej obciąża system.

Wagi funkcji heurystycznych - parametry określające, które z funkcji decydujących o sposobie wyznaczania siły powiązania pomiędzy dwoma zdarzeniami będą miały większe znaczenie.

Progowa siła powiązań zdarzeń - siła z jaką muszą być powiązane zdarzenia, aby mo-gły zostać połączone w grupę. Jeżeli wartość ta będzie zbyt niska, powstawać będą grupy zdarzeń nie mających ze sobą wiele wspólnego. Jeżeli natomiast wartość tego parametru ustawimy na zbyt wysokim poziomie, grupy mogą w ogóle nie powstawać i korelator będzie jedynie gromadził zdarzenia w grafie.

Progowy wskaźnik anomalii grupy - suma wskaźników anomalii wszystkich zdarzeń w grupie, przy której grupa zgłaszana jest jako podejrzana.

Maksymalna liczba zdarzeń w grafie - liczba zdarzeń, po przekroczeniu której zdarzenia zaczynają być usuwane z grafu korelacji. Im większa liczba, tym dłużej korelator przechowuje dane dotyczące zdarzeń i co za tym idzie może korelować zdarzenia bardziej od siebie oddalone. Jeżeli jednak liczba zdarzeń w grafie zostanie ustalona na zbyt wysokim poziomie korelacja zdarzeń dodawanych do mocno rozbudowanego grafu będzie silnie obciążała system.

2.6. Korelator w praktyce

Przed przystąpieniem do dostrajania korelatora konieczne było przygotowanie od-powiedniego środowiska. W tym celu zainstalowano system Snort wraz z detektorem anomalii Spade na komputerze pracującym pod systemem Linux podłączonym do średniej wielkości sieci. Sieć składała się z około 30 komputerów wyposażonych w różne systemy operacyjne i obsługujących różne usługi sieciowe. Sieć miała też wyjście do sieci Internet. Komputery były łączone poprzez przełączniki oraz zwykłe koncentratory.

Konieczne było nauczenie detektora anomalii Spade standardowego ruchu w sieci.

16

W tym celu został on uruchomiony na tydzień przed rozpoczęciem dostrajania. Pozo-stawiono domyślne progowe wartości poziomów raportowania, gdyż okazały się bardzo dobrze dopasowane do sieci testowej - wysoki wskaźnik anomalii uzyskiwały jedynie zdarzenia o bardzo niewielkim prawdopodobieństwie wystąpienia.

Aby zapewnić maksymalną powtarzalność parametrów wejściowych podczas dostrajania, przed każdą serią odtwarzano plik zawierający zapis stanu sieci dla programu Spade , a testy wykonywano wykorzystując tą samą serię pakietów sieciowych. Pakiety wykorzystywane w procesie zostały zapisane przy pomocy programu tcpdump, a następnie były odtwarzane z wykorzystaniem programu tcpreplay, który umożliwiał dokładne odtworzenie kolejności nadchodzenia pakietów.

Dodatkowo, aby zapewnić jak najwierniejsze podobieństwo warunków podczas kolejnych startów korelatora, zlikwidowano na czas dostrajania mechanizmy zmieniają-

ce ziarno generatorów pseudolosowych wykorzystywanych w programie. Dzięki temu zabiegowi zachowano wymaganą przez algorytm wyżarzania losowość, jednocześnie powodując jej powtarzalność w kolejnych uruchomieniach programu korelatora.

Dostrajanie korelatora jest dość złożonym procesem ponieważ wiele z parametrów jest od siebie wzajemnie uzależnionych. Z tego powodu podzielono dostrajane parametry na dwie grupy, z których pierwszą ustalono arbitralnie, a drugą dostrajano w celu uzyskania skutecznej pracy korelatora.

W pracy przyjęto z góry wartości parametrów, które zależały jedynie od mocy ob-liczeniowej komputera, na którym uruchamiano korelator, w celu zmniejszenia liczby koniecznych do przeanalizowania kombinacji.

— Liczba początkowych połączeń zdarzenia została ustalona na 4.

— Liczba cykli przebiegu algorytmu wyżarzania została ustalona na 10.

— Maksymalna liczba zdarzeń w grafie została ustalona na 10000.

Przyjęta liczba początkowych połączeń zdarzenia wynosi 4, co zapewnia dobre po-czątkowe połączenie zdarzenia w grafie. Dzięki temu uzyskano możliwość skutecznego budowania grupy zdarzeń podejrzanych opartej na tym zdarzeniu. Zwiększenie liczby początkowych połączeń nie miało wpływu na działanie korelatora podczas testowych uruchomień, natomiast powodowało większe obciążenie systemu. Zwiększenie obciążenia wynikało z faktu, że każde dodatkowe połączenie początkowe implikuje dodatkowy pełen przebieg wszystkich cykli algorytmu wyżarzania podczas dodawania zdarzenia.

Przyjęta liczba cykli wynosi 10 ponieważ jest ona wypośrodkowaniem pomiędzy dużym obciążeniem systemu a skutecznością algorytmu wyżarzania. Na testowym komputerze wyposażonym z Pentium III 550MHz zajętość procesora dochodziła do 95%, przy zapełnieniu grafu rzędu 10000 zdarzeń i liczby podłączeń początkowych ustawionej 17

na 4. Zwiększenie liczby cykli powodowało przy takim zapełnieniu obciążenie dochodzące do 100% co powodowało gubienie pakietów nadchodzących z analizatora anomalii Spade.

Wartości obydwu powyższych wielkości można zwiększyć w przypadku dysponowania silnym komputerem. Maksymalna liczba zdarzeń w grafie została ustalona na dość wysokim poziomie 10000 elementów. Jak w przypadku dwóch pierwszych parametrów z listy parametrów ustalonych, jej wartość musiała zostać wypośrodkowana. Kierowano się tu zapewnieniem jak najskuteczniejszej pracy korelatora bez wywoływania obciążenia systemu przekraczającego 95%.

W tym miejscu konieczne jest podkreślenie faktu, iż korelator jest programem dzia-

łającym w oparciu o moduł wykrywania anomalii Spade, który jest modułem statystycz-nym oraz, że zastosowany w nim algorytm wyżarzania opiera się w wielu momentach na losowości. Oba te fakty powodują, iż zachowania korelatora nie można przewidzieć w stu procentach oraz to, że nawet najdokładniejsze dobranie parametrów pracy korelatora nie może nam zapewnić jego skuteczności przy wykrywaniu wszystkich skanowań portów.

Pozostałe parametry pracy korelatora dostrajano korzystając ze standardowego na-rzędzia do skanowania portów nmap, które służyło do generowania ukrytych skanowań portów typu SYN. Zastosowano skanowania SYN, gdyż są one najsłabiej wykrywalne ze względu na standardowe ustawienie flag. Skanowania generowano z zewnątrz sieci w różnych odstępach czasu z różnych portów oraz z różnych adresów IP.

Ponieważ najważniejszym zadaniem korelatora jest wykrywanie skanowań niestan-dardowych, do takich właśnie dostrajano parametry. Skanowania niestandardowe to takie, które pochodzą z wielu maszyn i są kierowane do wielu maszyn w różnych odstępach czasu oraz ze zmodyfikowanymi parametrami pakietów.

Jeśli skanowanie jest całkiem chaotyczne nie jest możliwe wykrycie go ze stupro-centową pewnością. Mimo tego, że skanowanie takie dojdzie do korelatora jeśli zostanie zauważone przez Spade, nie ma pewności, że korelator będzie w stanie wykryć je bez jednoczesnego zgłaszania wielu fałszywych alarmów. Możliwe jest bowiem zgłaszanie grup zdarzeń podejrzanych słabiej ze sobą powiązanych poprzez zmniejszenie wartości progowej siły powiązań. Niestety, wiąże się to z łączeniem w grupy również zdarzeń nie związanych ze skanowaniem.

3. Podsumowanie

Przykładowe, rozproszone skanowania, wykryte w trakcie testów za pomocą oprogramowania Snort + Spade + korelator wykazały użyteczność zastosowania korelatora przynajmniej w wybranych przypadkach. Najważniejszym osiągnięciem było stworzenie opogramowania, które umożliwiło choć częściową weryfikację użyteczności omawianych 18

koncepcji. Kierunki dalszych prac skoncentrują się na optymalizacji działania korelatora, na wprowadzaniu ulepszeń do jego działanie.

Ewentualne sposoby udoskonalenia korelatora można podzielić na dwie grupy:

— Udoskonalenia funkcjonalne rozszerzające możliwości korelatora.

— Udoskonalenia wydajnościowe pozwalające na pracę korelatora w silniej obciążonych sieciach jak również na mniej wydajnych maszynach.

Do grupy udoskonaleń funkcjonalnych należy zaliczyć:

— Zautomatyzowanie procesu wyznaczania odpowiednich wartości parametrów raportowania zdarzeń.

— Opracowanie szczegółowych heurystyk porównujących zdarzenia.

— Uzupełnienie korelatora o możliwość graficznej reprezentacji znalezionych grup zdarzeń podejrzanych na bieżąco.

— Dodanie opcji zapisywania stanu pracy do pliku w celu umożliwienia podjęcia pracy w przypadku nagłego zatrzymania, bez utraty danych.

Do grupy udoskonaleń wydajnościowych należy zaliczyć ulepszenie algorytmów dotyczących następujących aspektów:

— częstotliwość uruchamiania procedury znajdowania grup zdarzeń podejrzanych - za-miast przy wstawianiu każdego zdarzenia, np. co ustalony okres,

— ewentualne zrównoleglenie i rozproszenie programu korelatora - umożliwiłoby zwiększenie liczby przechowywanych pakietów. Aktualny maksymalny dopuszczalny rozmiar grafu, 10000, wystarczy zaledwie na zebranie pakietów z okresu około 8.5

godziny pracy w sieci zbliżonej parametrami do sieci testowej, tzn. sieci o średniej przepustowości około 183 pakietów na sekundę, w której na 8800 pakietów występuje około 16 pakietów podejrzanych.

— zmiana sposobu wyboru zdarzeń do usunięcia z przepełniającego się grafu. Aktualnie zależy jedynie od czasu wstawienia zdarzenia do grafu.

Jak widać, zrealizowane oprogramowanie dalekie jest od doskonałości. Nie zmienia to jednak faktu, iż już teraz zachowuje się obiecująco, zaś większość sugerowanych ulepszeń wydaje się być realizowalna. Korelator w obecnej postaci można uznać za fundament, który udoskonalany i rozbudowywany o nowe funkcje, może stać się silnym narzędziem pomocnym w walce z intruzami.

Bibliografia

[1] http://www.silicondefense.com/, Informacje na temat rozwiązań Spade/ Spice.

19

[2] Tomasz J. KRUK. Snort – darmowy system IDS. Konferencja SECURE’ 2001. Bezpieczeństwo - nowe wyzwania, 2001.

[3] Tomasz J. KRUK. Przeciwdziałanie atakom DDoS. Konferencja IT.FORUM SECURE’

2002, 2002.

[4] Tomasz J. KRUK i Andrzej MACHNACZ. Systemy wykrywania anomalii w zabezpiecze-niach technicznych. Studia Informatica, 22(4(46)), 2001. Gliwice.

[5] Tomasz J. KRUK i Jarosław WRZESIEŃ. Wykrywanie nietypowych sposobów skanowania portów. Studia Informatica, 23(2B(49)), 2002. Gliwice.

[6] B. T. LUKE. Simulated Annealing. http://members.aol.com/btluke/simann1.htm.

[7] Martin ROESCH i Chris GREEN.

Snort users manual, Snort release: 2.0.0.

http://www.snort.org/, 2003.

[8] J. A. HOAGLAND S. STANIFORD i J. M. MCALERNEY. Practical automated detection of stealthy portscans. Journal of Computer Security, 10:105–136, 2002.

[9] D. GELATT Jr. Scott KIRKPATRICK i M. P. VECCHI. Optimization by simmulated annealing. Science, 220:671–680, 1983.

[10] Jarosław WRZESIEŃ. Wykrywanie nietypowych sposobów skanowania portów. Praca magisterska, Politechnika Warszawska, 2003.

20