Zastosowanie sieci Bayesa w wykrywaniu ataków DoS

Zastosowanie sieci Bayesa w wykrywaniu ataków DoS Marcin urakowski, Przemysław Kazienko Zakład Systemów Informacyjnych, Wydział Informatyki i Zarzdzania, Politechnika Wrocławska mzurakowski@esolution.pl, kazienko@pwr.wroc.pl Wstp Powstajce w latach 70 tych sieci ARPANET, NFSNET dały pocztek Internetowi, czyli powszechnie znanej i wykorzystywanej globalnej pajczynie. W zamysłach projektantów sie miała słuy przede wszystkim celom wojskowym lub naukowym: zapewnia łczno, wspomaga przeprowadzanie bada i wymiany informacji pomidzy orodkami. Zapewne aden z jej twórców nie spodziewał si, e kiedy Internet bdzie sieci oplatajc cały wiat i jednym z waniejszych filarów wiatowej gospodarki. Dzi Internet łczy miliony ludzi a w jego wirtualnej rzeczywistoci moemy znale coraz to wicej usług pochodzcych ze wiata rzeczywistego (e-handel, e-gospodarka, e-wybory, e- rozrywka). Internet ma te swoj ciemn stron: włamania do systemów, blokowanie usług, wirusy, spam to tylko kilka zagroe czyhajcych na ludzi uywajcych Internetu. Błdy popełnione we wstpnych latach podczas projektowania protokołów i usług wraz z niedoskonałym i dziurawym oprogramowaniem, spowodowały, e te niedoskonałoci zamieniły si w prawdziwe plagi. Jednym z takich zagroe s ataki typu DoS/DDoS (Denial of Sernice / Distributed Denial of Service), czyli działania majce na celu zablokowanie wybranej usługi i uniemoliwienie korzystania z niej uprawnionym uytkownikom. Niniejszy referat koncentruje si na podgrupie tych ataków wystpujcych w warstwie sieciowej i transportowej modelu OSI [12]. Zaproponowany system BIDS (Bayesian Intrusion Detection System) został stworzony, jako praktyczna cz pracy [17]. Jego wersja prototypowa została zaimplementowana, wdroona i przetestowana w warunkach zblionych do rzeczywistych. 1. Ataki typu DoS/DDoS Ataki typu DoS (Denial of Service) czyli odmowy usługi [9] maj na celu uniemoliwienie uprawnionym uytkownikom skorzystania z zasobów lub usług systemu komputerowego. Istnieje bardzo wiele odmian tego ataku - od przecicia kabla zasilajcego po skoordynowane uderzenie pakietami sieciowymi z tysicy komputerów jednoczenie [5]. Urzdzenia komputerowe do sprawnego działania potrzebuj kilku podstawowych zasobów, takich jak czas procesora, powierzchnia dyskowa, pami RAM, przepustowo łcza. Ataki DoS staraj si doprowadzi do zuycia bd zablokowania tych zasobów, wykorzystujc przy tym wiele z codziennie wykonywanych przez uytkowników czynnoci. Przepełnione konto pocztowe i zgubione listy do prosty przykład ataku DoS o nazwie Mail Bombing [8]. Mona równie utworzy bardzo wiele małych plików, co np. w systemie Linux moe doprowadzi do wyczerpania maksymalnej liczby wzłów (INODE)

przechowujcych informacje o plikach i w konsekwencji do niemonoci stworzenia jakiegokolwiek nastpnego pliku. Kolejn form ataku DoS jest zajcie całego czasu procesora przez procesy jednego uytkownika (fork bomb), co uniemoliwia korzystanie z zasobów przez inne osoby. Osobna grupa ataków DoS polega na zniszczeniu lub modyfikacji danych o konfiguracji programów i urzdze. Intruz moe zdalnie lub lokalnie zniszczy pliki konfiguracyjne, blokujc dostp uprawnionym uytkownikom do danego programu (usługi) lub uniemoliwiajc jego prawidłowe działanie. Na przykład modyfikujc tablic routingu moe on zablokowa cał sie, a zmieniajc warto rejestru systemowego Windows - doprowadzi do wyłczenia niektórych usług lub do bardzo dziwnego, uniemoliwiajcego prac, zachowania si systemu. Istotnym rodkiem obrony przed atakami DoS jest fizyczne zabezpieczenie sprztu gdy unieruchomienie kluczowego routera moe skutecznie zablokowa cał sie na długi czas [2]. Ataki sieciowe DoS nie wymagaj lokalnego bezporedniego dostpu do atakowanej maszyny, wykorzystuj one luki w oprogramowaniu sieciowym oraz niedoskonałoci w protokołach komunikacyjnych. Aplikacje sieciowe po otrzymaniu niepoprawnych, czsto specjalnie spreparowanych danych, przerywaj działanie lub zajmuj cały czas procesora, a nawet restartuj maszyn. Bardzo czsto ataki DoS wykorzystuj błdy w implementacji protokołów w systemach operacyjnych, np. tworzenie niewłaciwej tablicy ARP, nie sprawdzanie długoci pakietów przed ich przetworzeniem (ataki Land, Teardrop, Ping of Death) czy nieprawidłowa obsługa składania pofragmentowanych pakietów IP. DDoS (Distributed Denial of Service) jest udoskonalon a przede wszystkim rozproszon wersja ataku DoS. Znacznemu zmodyfikowaniu uległy głównie skuteczno oraz "bezpieczestwo" agresora. O ile w metodzie DoS atak odbywa si z komputera agresora, o tyle atak DDoS przeprowadzany jest w sposób rozproszony, tzn. z wielu przejtych wczeniej komputerów jednoczenie. Komputery te znajduj si w rónych lokalizacjach, a ich uytkownicy nie s wiadomi tego, i włanie bior udział w ataku na serwer internetowy. Aby komputer taki mógł wzi udział w ataku musi by wczeniej zaraony odpowiednim programem złoliwym. Słu do tego rónego rodzaje konie trojaskie, które dopiero na wyrany sygnał od agresora uaktywniaj si i rozpoczynaj proces destrukcji. Wykrycie takiego programu złoliwego jest stosunkowo trudne ze wzgldu na to, i aktywuje si on tylko i wyłcznie w momencie ataku, po czym znów przechodzi w stan upienia. Takie niepodane programy mog by bardzo inteligentne - po przeprowadzonym ataku starannie zacieraj lady swojej obecnoci w systemie niewiadomego uytkownika samoczynnie si deinstalujc i kasujc. Dokładne omówienie kilkunastu rodzajów ataków, ich anatomii oraz proponowanych metod obrony przed nimi zostało zawarte w pracy [17]. 1.1. Fazy ataku W zalenoci od rodzaju ataku, jego przebieg moe by za kadym razem inny. Wyrónijmy jednak kilka faz ataku, które s wspólne dla wikszoci z nich [5]. Faza I Poszukiwanie błdów Do przeprowadzenia skomasowanego i skutecznego ataku typu DDoS agresor potrzebuje armii maszyn i systemów operacyjnych, nad którymi bdzie mógł

przej kontrol i wykorzysta do własnych celów. Dla duych firm, portali i innych popularnych systemów internetowych nieprzerwana widoczno w sieci to ich by albo nie by. Ataki DoS/DDoS s dla nich duym zagroeniem, dlatego inwestuj rodki w dobr infrastruktur sieciow: o Równoległe łcza do wielu dostawców czsto o przepustowociach setek Mbit/s. o Wydajne routery, które s zaprojektowane do obsługi o wiele wikszego ruchu ni aktualnie wystpujcy. Routery te czsto odpowiadaj za balansowanie ruchu na wszystkich dostpnych łczach. Zaatakowanie jego z nich powoduje przeniesienie uytkowników na inne. o Wydajne zapory ogniowe renomowanych firm. o Systemy IDS (Intrusion Detection Systems), czyli systemami wykrywania włama [4] [6] [7]. o Właciwa konfiguracja wszystkich elementów sieci oraz zaktualizowane oprogramowanie. o Całodobowy monitoring, ze strony własnego personelu technicznego, jak równie ze strony administratorów dostawców internetowych ISP. Atak na takie instytucje wymaga sieci DDoS o liczbie setek tysicy maszyn. Podczas pierwszych ataków typu DDoS, sie agresora była budowana z maszyn pracujcych pod kontrol systemów klasy Unix. Jednak ich stosunkowo mała liczba oraz dbało administratorów (w wikszoci przypadków) o ich bezpieczestwo powodowało, e zbudowanie wystarczajco duej sieci nie było zadaniem prostym. Wtedy agresorzy zwrócili si w kierunku systemów biurkowych firmy Microsoft (Windows 95, Windows 98, Windows Me, Windows 2000, Windows XP, Windows 2003). W stosunku do maszyn pracujcych pod systemem Unix, maj one wicej zalet w punktu widzenia agresora: o Popularno. Sytemu klasy Windows s zainstalowane na ponad 95% [16] komputerów PC, za liczba maszyn działajcych pod tym systemem i podłczonych do sieci Internet jest ogromna. o Niewiedza uytkowników. Przecitny uytkownik tego systemu posiada nikł wiedze na temat bezpieczestwa sieciowego. Dodatkowo, uytkownicy, czsto z lenistwa, nie aktualizuj swoich systemów, nie instaluj prywatnych zapór ogniowych ani innych elementów zwikszajcych bezpieczestwo. o Dua liczba krytycznych błdów. Statystyki błdów pokazuj, e w kadym kwartale jest wykrywanych rednio po kilka błdów, które maj status krytyczny i umoliwiaj przejcie zdalnej kontroli. o Słabe bezpieczestwo. Domylnie w tej klasie systemów zwykły uytkownik ma prawa administratora i moe zrobi wszystko ze swoim komputerem. Uruchamiane przez niego programy równie nie podlegaj ograniczeniom. Takie rodowisko jest wprost wymarzone dla wirusów i robaków. W tej pierwszej fazie, agresor albo intensywnie poszukuje błdów w systemach operacyjnych, albo czeka spokojnie, a inni je znajd. Faza II Kodowanie

Gdy odpowiedni błd zostanie znaleziony, agresor musi stworzy właciwy program (tzw. exploit), umoliwiajcy jego wykorzystanie. Do jego kodu, nastpnie dodawanie s kolejne moduły, z których najczciej moemy spotka: o Moduł do skanowania sieci w poszukiwaniu nastpnych ofiar o Moduł ukrywajcy narzdzie w systemie o Moduły do infekcji innymi drogami (poczta elektroniczna, dyskietki, itp.) o Moduł atakujcy DDoS o Moduł autodestrukcji o Moduł komunikacji z innymi agentami i agresorem Mniej pracowici wandale, zwykle składaj robaka z gotowych klocków napisanych przez innych. Faza III Budowanie sieci Gdy narzdzie jest gotowe, wystarczy e agresor zarazi kilka komputerów na pocztek, a te z kolei zainfekuj nastpne. W zalenoci od sposobu infekowania, poszukiwania innych maszyn oraz oczywicie popularnoci błdu, liczba maszyn w sieci DDoS moe w cigu kilku godzin osign nawet kilka milionów. Faza IV Atak Atak na wybrany cel odbywa si albo o cile okrelonym czasie, ju wybranym podczas kodowania, albo agenci komunikuj si midzy sob i bezporednio, lub porednio otrzymuj komend od agresora. 2. System wykrywania ataków DOS/DDOS BIDS BIDS (Bayesian Intrusion Detection System), jest aplikacj, której celem jest wykrywanie ataków typu DoS/Dos [17]. Aplikacja ta koncentruje si na wykrywaniu anomalii w nateniu ruchu. Szczególnie czuła jest na zwikszony ruch w wybranych protokołach. Takie załoenie projektowe spowodowało, e system BIDS nie wykryje ataku DoS/DDoS, który polega na wysłaniu pojedynczego, specjalnie przygotowanego pakietu. W takich przypadkach bardzo dobrze sprawuj si tradycyjne systemy IDS [6] [7], np. Snort [3], które posiadaj swoj baz sygnatur ataków. BIDS nie jest konkurencj dla nich, a jedynie uzupełnieniem ich funkcjonalnoci. Jest to wic system wykrywajcy anomalie (anomalny detection), a nie wzorce ataków (signature detection). Załoeniem projektowym było nie tylko wykrywanie kilku popularnych ataków DoS/DDoS, ale take ostrzeganie o wzrocie podejrzanego ruchu, który nie został zidentyfikowany. Wybrane charakterystyczne wykrywane ataki to: powód ICMP Redirect, ICMP Smurf, powód ICMP Unreach, powód UDP Chargen, atak na serwer DNS, SYN Flood, atak na serwer SMTP, atak na serwer WWW. Inne ataki, które nie pojawiły si na powyszej licie, zostan zakwalifikowane jako: powód pakietów ICMP, powód pakietów UDP, powód pakietów TCP. System BIDS nie tylko wykrywa ataki, które s dokonywane na sie chronion, ale równie ostrzega on o anomaliach ruchu wychodzcego z tej sieci. Przez to moemy zosta poinformowani, e poredniczymy, na przykład, w ataku typu SMURF.

2.1. Koncepcja działania systemu Aplikacja BIDS przełcza interfejs sieciowy w tryb nasłuchiwania pełnego (promiscuous). W tym trybie karta sieciowa potrafi odbiera wszystkie pakiety, które fizycznie do niej docieraj, mimo, e nie s przeznaczone dla niej (take te, z innym adresem docelowym MAC). System BIDS umoliwia zdefiniowanie przez uytkownika dodatkowych filtrów, które ogranicz ruch brany pod uwag przez sam aplikacj. Przechwytywanie pakietów przez BIDS Agregacja pakietów Przekazanie zagregowanych danych do sieci Bayesa Analiza danych przez sie Bayesa stosuj specjalne funkcje dyskretyzujce. Przechwycone pakiety s klasyfikowane na dwie kategorie: ruch do chronionej sieci i ruch od chronionej sieci. Pozostałe pakiety s odrzucane. W nastpnych kroku dane z docierajcych pakietów (np. rozmiar, ilo) s sumowane z innymi. W ten sposób nastpuje agregacja danych. Zagregowane dane s nastpnie zapisywane do pamici operacyjnej i czekaj na zanalizowanie. Dane te tworz rekordy. Rekord moe odpowiada pojedynczemu połczeniu (adres ródłowy IP, port ródłowy, adres docelowy IP, port docelowy), jak i moe przedstawia ruch na dan usług w sieci chronionej (wszystkie połczenia do serwera WWW). Kady rekord jest analizowany cyklicznie, co jaki czas. Długo tego okresu jest zaleny od aktualnego obcienia sytemu, jednak nie jest mniejszy od 4 s (domylnie). Nastpnie system wyszukuje w pamici te rekordy, które zostały zmodyfikowane od ostatniej analizy. Jeli jaki rekord spełnia te warunki, to dane z niego s przepisywane do wzłów sieci Bayesa wartoci oznaczaj stan wzła. Stany wszystkich wzłów maj charakter dyskretny. Dla niektórych wartoci, jak ilo pakietów na sekund system W dalszej kolejnoci sie Bayesa oblicza prawdopodobiestwa nieustalonych wzłów. Jednym z nich (centralnym) jest wzeł oznaczajcy typ ataku. W ten sposób zostaje obliczone prawdopodobiestwo ataku P. W przypadku, gdy jest wiksze od zdefiniowanego progu (0.75 - domylnie), na ekran jest wypisywane ostrzeenie. Przykładowy alert ma posta:

CISCOSYSTEMS Atak 'tcp_syn_flood' z prawdopodobienstwem 0.987 z 192.168.10.10:0 -> 192.168.0.1:70 Kady alert zawiera nazw rozpoznanego ataku, jego prawdopodobiestwo, ródłowy adres IP, port ródłowy, docelowy adres IP, port docelowy. Kiedy dany rekord został ju zanalizowany, jego wartoci s zerowane (ilo pakietów, sumaryczny rozmiar itp). Jeeli przyjd kolejne pakiety, które bd pasowa do danego rekordu, to dane o nich zostan do niego dodane. System BIDS dba o optymalne wykorzystanie pamici, dlatego rekordy, które nie były przez dłuszy czas uywane (domylnie 60 s), s usuwane z pamici. 2.2. Miejsce instalacji systemu System BIDS ma charakter pasywny. Obserwuje on tylko ruch przechodzcy przez sieci, ale nie wpływa na niego. Aplikacj mona zainstalowa w kilku miejscach: Umiejscowienie systemu BIDS 2.3. Obserwacja parametrów sieci Brama sieciowa jest to moliwe, o ile funkcj t pełni komputer klasy PC z zainstalowanym systemem Linux. Wewntrz chronionej sieci zalecana konfiguracja, jeli nasz przełcznik w sieci lokalnej posiada port monitorujcy, na który bdzie kierowany cały ruch wejciowy i wyjciowy. Instalacja na jednym z serwerów system w takiej konfiguracji bdzie chronił tylko ten jeden komputer pod warunkiem, e bdzie on pracował pod system Linux. W kadej rzeczywistej sieci ilo, wielko oraz natenie przesyłanych danych jest inne. Dodatkowo wartoci te zmieniaj si w czasie na przestrzeni doby (duy ruch w dzie, mały w nocy), oraz w dłuszym okresie (zwikszanie iloci klientów powolny wzrost ruchu). Parametry te zale od bardzo wielu czynników, z których główne to: Liczba serwerów w chronionej sieci Konfiguracja sieci (zapory ogniowe, filtry i ograniczniki ruchu) Rodzaj udostpnianych usług (protokoły, wielkoci przesyłanych danych) Przepustowo łcz danych do dostawców ISP Liczba klientów i ich zachowania Kultura pracy w firmie (godziny pracy) Przykładowe wykresy obcienia łcz zostały pobrane od jednego z dostawców dostpu do sieci Internet (ISP).

Przykładowy wykres iloci odebranych i wysłanych danych (okres doby) Przykładowy wykres iloci odebranych i wysłanych danych (okres tygodnia) System BIDS potrzebuje do pracy rednich wartoci przesyłanych danych. Wyznaczenie tego w sposób automatyczny jest zadaniem trudnym i moe okaza si, e otrzymane wyniki bd błdne. Dodatkowo podczas automatycznej obserwacji sieci moe zdarzy si wiele zaburze, które zniekształc wyliczone dane: Atak typu DoS/DDoS (nagły wzrost ruchu) Awaria łcza (prawie całkowity zanik ruchu) Prace administracyjne (wykonywana kopia zapasowa na inny serwer, rekonfiguracja sieci itp) Z tego wzgldu system BIDS wymaga od administratora rcznego uruchomienia w specjalnym trybie, jak i równie rcznego zatrzymania. Podczas tego okresu bd mierzone rednie parametry przesyłanych danych. Takie działanie ma kilka zalet. Po pierwsze administrator moe wybra okres mierzenia parametrów (kilka godzin, doba, tydzie). Zmierzenie redniego ruchu w dzie, spowoduje, e system bdzie prawdopodobnie za mało czuły w nocy (mniejszy ruch), natomiast uruchomienie tego trybu w nocy moe spowodowa, e w dzie jego czuło bdzie za dua. To pozwoli administratorowi dobra optymalny okres (np. doby). Drugim wanym plusem jest to, e w przypadku niespodziewanego zdarzenia, które spowoduje zmniejszenie, lub zwikszenie ruchu pomiar moe by przerwany i powtórzony jeszcze raz. Dlatego podczas tego trybu pracy zaleca si dodatkowo obserwacj obcienia sieci, na przykład przy pomocy takich narzdzi jak MRTG. 2.4. Moduły wewntrzne W celu funkcjonalnego podziału i lepszego zarzdzania kodem, system BIDS składa si z kilkunastu modułów. Główne moduły wraz z kierunkiem przepływu danych zostały przedstawione na poniszym rysunku.

Moduły systemu BIDS i kierunki przepływu danych Moduł Catcher odpowiedzialny za przechwytywanie pakietów z interfejsu sieciowego, klasyfikowaniu ich ze wzgldu na protokoły oraz przekazywanie danych do dalszych modułów. Moduł Storman - odpowiedzialny za przechowywanie i zarzdzanie informacjami o połczeniach (zarzdzenie pamici) Moduł Analyser odpowiedzialny za analiz zgromadzonych danych przechowywanych w pamici operacyjnej. Moduł działa w postaci wtku, osobno od reszty modułów. Celem takiej implementacji było uniezalenienie go od reszty programu i dowolne dostosowanie tempa i czasu przetwarzania. Moduł Analyser Bayes - mózgiem całego systemu. Odpowiada on za załadowanie zgromadzonych danych do sieci Bayesa i odczytanie prawdopodobiestwa. 2.5. Zastosowanie sieci Bayesa U podstaw koncepcja sieci Bayesa ley twierdzenie podane przez angielskiego matematyka Thomas Bayes (1702 61). W rzeczywistym wiecie jest wiele sytuacji, w których wystpienie jakiego zdarzenia cile zaley od innego zdarzania. Zastosowanie sieci Bayesa pozwala na uniknicie oblicze o duej złoonoci obliczenie jednego prawdopodobiestwa a posteriori łczy si z uprzednim obliczeniem wykorzystywanych prawdopodobiestw. Ogromn zalet sieci Bayesa jest przedstawianie wiedzy niepewnej, zdarze, co, do których nie ma pewnoci, e zaszły. Klasyczna sie Bayesa składa si z wzłów, które reprezentuj zmienne oraz łuków definiujcych powizania pomidzy wzłami. Graficznie przedstawienie sieci przybiera posta acyklicznego grafu. W dziedzinie wykrywania ataków sie Bayesa posiada kilka wanych zalet: Bardzo dua szybko oblicze w przypadku pracy sytemu BIDS na bardzo obcionej sieci, moe by potrzeba setek analiz na sekund. Obliczanie prawdopodobiestw wewntrz sieci Bayesa jest proste i szybkie. System nie moe pozwoli sobie na zajcie czasu procesora na poziomie 100%, gdy sam stałby si narzdziem DoS. Moliwo uczenia si sieci Bayesa pozwalaj na szybkie uczenie si. Jedynie, co trzeba im dostarczy to stany zmiennych z rzeczywistych zdarze.

Przetwarzanie wiedzy niepewnej fakt zaistnienia ataku jest okrelany z pewnym prawdopodobiestwem o wartociach cigłych. Jako silnik implementujcy sie Bayesa została wybrany pakiet Netica firmy Norsys [13]. Przyczynami takiego wyboru były: Wersja graficzna pakietu pod system Windows Biblioteki C oraz Java zarówno na platform Linux jak i Windows Dobrze zaprojektowane API Stabilno pakietu Darmowa wersja limitowana (limitowanie dotyczy iloci wzłów) Graficzny moduł pakietu Netica (Windows) Projekt sieci Bayesa został wykonany po przeanalizowaniu kilkunastu innych sieci z uwzgldnieniem zalenoci pomidzy gromadzonymi wartociami. Stany wszystkich wzłów maj charakter dyskretny. Ze wzgldu na gromadzone dane, zostały zdefiniowane nastpujce wzły w sieci Bayesa: apsps (Avg packet size per second) - rednia ilo przesłanych danych w skali od L0...L5 (na sekund). apcps (Avg packet count per second) rednia ilo przesłanych pakietów w skali od L0...L5 (na sekund). fcf (From Client Flood) wzeł wskazujcy, czy nastpuje powód pakietów. srv (Service) rodzaj usługi w sieci chronionej do jakiej kierowane s pakiety. Wybrano popularne usługi, które działaj na protokołach: ICMP, UDP, TCP. Reszta usług bdzie pokrywana przez stany wzła: icmp_other, udp_other i tcp_other. atsps (Avg TCP SYN) rednia ilo pakietów protokołu TCP majcych zapalon flag SYN w stali L0...L5 (dla ICMP i UDP zawsze L0). atrps (Avg TCP RST) rednia ilo pakietów protokołu TCP majcych zapalon flag RST w stali L0...L5 (dla ICMP i UDP zawsze L0). atfps (Avg TCP FIN) rednia ilo pakietów protokołu TCP majcych zapalon flag FIN w stali L0...L5 (dla ICMP i UDP zawsze L0).

ataps (Avg TCP ACK) rednia ilo pakietów protokołu TCP majcych zapalon flag ACK w stali L0...L5 (dla ICMP i UDP zawsze L0). atpps (Avg TCP PUSH) rednia ilo pakietów protokołu TCP majcych zapalon flag PUSH w stali L0...L5 (dla ICMP i UDP zawsze L0). atups (Avg TCP URG per second) rednia ilo pakietów protokołu TCP majcych zapalon flag URG w stali L0...L5 (dla ICMP i UDP zawsze L0). attack_type wzeł, który jako swoje stany posiada nazwy ataków. Ostatni stan o nazwie normal, oznacza brak ataku. Schemat sieci Bayesa 2.6. Waniejsze algorytmy - funkcje dyskretyzacji Dane o iloci pakietów oraz ich rozmiarze, które s przechowywane w pamici maj charakter cigły s to liczby rzeczywiste. Kluczowym fragmentem analizy jest ich zamiana na specjaln skal 6-stopniow L0...L5, która jest wymagana przez sie Bayesa. Do tego celu s wykorzystywane 3 funkcje dyskretyzujce, kada w innej sytuacji. Pierwsza z nich stosowana jest do zamiany iloci pakietów. Jest stosowana do wszystkich protokołów. Funkcja ma charakter logarytmiczny, ronie szybko na pocztku, łagodniej dla wikszych argumentów i dlatego została wybrana do przeliczania liczby pakietów. L = round(log ( nc + 1) 1 MID_LEVEL ( count + 1)), if L > MAX _ LEVEL then L = MAX _ LEVEL gdzie: L obliczony poziom MIN_LEVEL...MAX_LEVEL nc współczynnik odczytany z pliku net_stat.conf MID_LEVEL redni poziom zdefiniowany w pliku konfiguracyjnym config.h count ilo pakietów w tym rekordzie danych (przechwyconych) MAX_LEVEL maksymalny poziom zdefiniowany w pliku config.h.

Dla: nc=20, MID_LEVEL=2.5, MAX_LEVEL=5 wykres funkcji L(count) jest nastpujcy: Druga z nich, równie jest stosowana do wszystkich protokołów i przelicza rozmiar zgromadzonych danych na poziom L0...L5. Ma charakter liniowy. size * MID _ LEVEL L = round( ), ps if L > MAX _ LEVEL then L = MAX _ LEVEL gdzie: size rozmiar przechwyconych pakietów, ps współczynnik odczytany z pliku net_stat.conf Dla ps=100, MID_LEVEL=2.5, MAX_LEVEL=5 wykres funkcji L(size) jest nastpujcy: Ostatni funkcja ma za zadanie przeliczy wystpowanie flag w pakietach TCP (SYN, ACK itp), na odpowiednie poziomy. flag * MAX _ LEVEL L = round( ) count gdzie: flag ilo pakietów z zapalon dan flag (przechwyconych)

2.7. Waniejsze algorytmy uogólnianie danych Nie mona poddawa analizie tylko rekordy zawierajce dane o połczeniach komputer-komputer, gdy w ten sposób atak na cała sie został by przeoczony. Do dalszej analizy dane musz by uogólniane. Postpowanie polega na odrzucaniu po kolei portu oraz adres nadawcy (z poza sieci chronionej) i nastpnie zsumowaniu danych z innymi połczeniami. Pozwoli to na wykrywanie ataków rozproszonych DDoS, oraz ataków na usług w sieci chronionej, gdzie czsto adres i port ródłowy s losowane. Pełne dane o połczeniu IP: 192.168.10.10 Port: 3456 -> IP: 192.168.0.1 Port: 80 Sie zewntrzna Sie chroniona Pami Uogólniane - Krok 1 - Port ródlowy IP: 192.168.10.10 Port: 0 -> IP: 192.168.0.1 Port: 80 Sie zewntrzna Sie chroniona Pami Uogólniane - Krok 2 - Adres ródlowy IP: 0.0.0.0 Port: 0 -> IP: 192.168.0.1 Port: 80 Sie zewntrzna Sie chroniona Pami Schemat postpowania przy uogólnianiu danych Powyszy przykład dotyczy protokołu UDP i TCP. Dla protokołu ICMP schemat postpowania jest podobny. 2.8. Waniejsze algorytmy uczenie sieci Bayesa Sie Bayesa składa si z wzłów, które reprezentuj zmienne oraz łuków prawdopodobnych zalenoci pomidzy wzłami. Sie charakteryzuje si tym, e poprzednik wzła bezporednio powoduje stan zmiennej skojarzonej z tym wzłem. Dla kadego wzła okrela si rozkład prawdopodobiestwa warunkowego albo podajc je wprost albo uczc sie na przykładach. Dla wartoci dyskretnych funkcj prawdopodobiestwa warunkowego mona zapisa w tabeli przedstawiajcej prawdopodobiestwa przyjcia poszczególnych wartoci Przykładowy rozkład prawdopodobiestw w wle (własnych) przez wzeł dziecko, sieci Bayesa w zalenoci od kolejnych z moliwych wartoci rodzica.

CISCOSYSTEMS Podczas tworzenia systemu BIDS przyjto, e sie zostanie nauczona rozpoznawa ataki typu DoS/DDoS i prawdopodobiestwa nie bd rcznie poprawiane. Przygotowanie odpowiednich pików uczcych pozwoliło zrealizowa to załoenie. System został zainstalowany na głównym serwerze jednego z dostawców usług internetowych. Serwer ten ma wiele funkcji, z których główne to: Serwer WWW Serwer poczty (SMTP, POP3, IMAP) Serwer DNS System ten jest rednio obciony podczas dnia roboczego na poziomie: 200 kbit/s ruchu wchodzcego do serwera i 1.5 Mbit/.s ruchu wychodzcego z serwera. Przed nauk system BIDS został uruchomiony w trybie obserwacji sieci, aby zebra dane dotyczce redniego ruchu. Sam proces uczenia nastpował w dwóch fazach: W pierwszej fazie system BIDS został uruchomiony z opcj generowania pliku CASE. System w tym trybie obserwuje cały wychodzcy i wchodzcy ruch, agreguje dane i wypisuje wyniki na ekran. Wypisywanie wiersze maj tzw. stan normalny, co oznacza, e zostały na sztywno zakwalifikowane jako ruch prawidłowy (nie atak). Jednoczenie cały czas ruch wychodzcy i wchodzcy do serwera był obserwowany innym narzdziem (iptraf, MRTG), aby sprawdzi czy nie nastpuje próba ataku. Jeli nastpiłby prawdziwy atak, został by on przez system BIDS w tym trybie zakwalifikowany jako prawidłowy ruch. W rezultacie sie dostała by błdne dane. Rezultatem tej fazy był plik CASE o rozmiarze 47MB i zawierajcy 319,748 rekordów. Schemat sieci podczas pierwszej fazy uczenia Druga faza miała na celu nauczenie sieci Bayesa wykrywania ataków DoS/DDoS. Do nauki został uyty drugi serwer znajdujcy si w sieci lokalnej. Z niego, przy wykorzystywaniu specjalnych narzdzi były symulowane ataki DoS oraz DDoS. Do czci ataków stosowany był program hping2 [10], do innych zostały napisane specjalne skrypty w jzyku PERL i biblioteki Net::RawIP. Symulowane były kolejne ataki z rón sił tj. zmianie ulegało natenie pakietów oraz ich rozmiar. Najlepiej, aby nauka

CISCOSYSTEMS nie odbywała si w sieci lokalnej, jednak nie było moliwoci jej przeprowadzenia z komputera zdalnego, gdy zostaliby odcici klienci obu sieci. Rezultatem tej fazy były 4 pliki CASE: dla protokołu ICMP, UDP, TCP oraz osobny plik z wykrytymi atakami typu SYN Flood. Schemat sieci podczas drugiej fazy uczenia Wszystkie pliki z obu faz zostały nastpnie wczytane do pakietu NETICA, który dokonał ich przetworzenia. Podczas importu pakiet umoliwia wybranie tzw. stopnia importu. Jest to liczba całkowita, wiksza od 0. Warto ta determinuje, ale razy kady wiersz ma by przetwarzany. Jeli plik CASE ma 10 przypadków, a podany współczynnik jest równy 5, wtedy kada linia 5 razy wpływa na zmian prawdopodobiestw. Pliki CASE z atakami zawierały o wiele mniej danych ni plik CASE z prawidłowym ruchem, dlatego kady z nich został zaimportowany z współczynnikiem 5. Wicej informacje o algorytmach uczenia sieci Bayesa mona znale w pomocy pakietu Netica [13] oraz w publikacjach [1] [14] [15]. 3. Analiza działania systemu BIDS rodowiskiem testowym stała si sie lokalna jednej z firm działajcych w brany IT. Sie ta była odseparowana przy pomocy bramy (gateway) od produkcyjnych systemów tej firmy. Brak zakłóce w funkcjonowaniu Router Serwer Główny Połczenie do sieci firmowej BIDS BIDS Switch DoS Serwer pomocniczy Schemat rodowiska testowego tyche systemów był głównym warunkiem udostpnienia infrastruktury. rodowisko testowe składało si z nastpujcych elementów: Główny serwer testowy, na którym została zainstalowana aplikacja BIDS. Parametry komputera: Pentium II 400 MHz, 128 MB RAM, Dysk IDE 10 GB. Pomocniczy serwer testowy, który bdzie symulował ataki DoS/DDoS na serwer główny. Parametry

Prawdopodobiestwo komputera: AMD XP 1400, 256 MB RAM, Dysk 40 GB. Przełcznik sieciowy 10/100 MBit 3COM Router Cisco, jego zadaniem było uniemoliwienie przedostania si generowanego ruchu do głównej sieci firmowej. System BIDS uruchomiony z logowaniem na poziomie 1 i 2 do pliku Do generowania ruchu o podanym nateniu i wielkoci pakietów zostało wykorzystane narzdzie hping2 [10] oraz własne skrypty napisane w jzyku PERL i biblioteki Net::RawIP. 3.1. Testy skutecznoci Celem tych testów było zmierzenie skutecznoci systemu, czyli jego zdolnoci do wykrywania ataków typu DoS/DDoS. W tym celu zasymulowano 3 rodzaje Prawdopodobiestwo 1.1 1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 0 0 10 20 30 40 50 60 70 80 90 100 110 120 Pakiety [p/s] 0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 Pakiety [p/s] ICMP Redirect UDP Domain ataków, po jednym z kadego protokołu (ICMP, UDP, TCP). Siła ataku bdzie regulowana przez zwikszanie dwóch parametrów: Natenia iloci pakietów [ilo/s] Natenia iloci danych [KB/s] Testy miały da odpowied, jak system BIDS ocenia i klasyfikuje zwikszony ruch. Pierwsze trzy wykresy (dwa rysunki) przedstawiaj zmian prawdopodobiestwa w zalenoci od liczby pakietów. Na wszystkich z nich mona zauway, e przy małych wartociach liczby pakietów (ok. 10-12) gwałtownie ronie 1.1 1 prawdopodobiest 0.9 wo, osigajc 0.8 szybko poziom 0,8-0.7 0.6 0,9. Wpływ na takie 0.5 zachowanie 0.4 systemu maj dwa 0.3 czynniki. Po 0.2 TCP SYN FLood 0.1 pierwsze rednia ilo pakietów zawarta w pliku konfiguracyjnym dla protokołów ICMP i UDP wynosi około 10-13. W tym włanie przedziale zmienna przekazywana do sieci Bayesa (ilo pakietów/s) zmienia si z L2 na L3. Drugim czynnikiem, jest natomiast zawarto danych uczcych. Dane oznaczone jako normalne miały wspomniany czynnik w wikszoci ustawiony na wartoci L0..L2, natomiast dane uczce ataków L3...L5. Ten gwałtowny wzrost nie obnia skutecznoci systemu, o ile bdzie on wystpował przy odpowiednich przedziałach. Administrator ma moliwo zmiany tych wartoci.

W drugiej fazie tych testów, liczba pakietów była ustalana na warto redni dla danego protokołu, a zmianie ulegała ich wielko, czyli wzrastała ilo danych 1 docierajcych do 0.9 serwera testowego. 0.8 W przypadku 0.7 pierwszych dwóch 0.6 ataków (ICMP Redirect i UDP 0.5 Domain Flood) 0.4 wzrost natenia 0.3 danych pocigał za Prawdopodobiestwo 0.2 0.1 0 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 5.5 6 Dane[ KB/s] ICMP Redirect UDP Domain sob wzrost prawdopodobiest wa. Mona było zaobserwowa, e wzrost ten nie jest jednostajny, s wartoci, dla których prawdopodobiestwo powinno rosn, a mimo to maleje. Przyczyn tego zachowania jest nie do koca dobre ustalenie tablic prawdopodobiestw w sieci Bayesa, które nastpiło w wyniku samodzielnego uczenia si. Trzeci z wykresów, dotyczcy ataku TCP SYN Flood, znaczco róni si od Prawdopodobiestwo 0.1 0.09 0.08 0.07 0.06 0.05 0.04 0.03 0.02 0.01 0 0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 Dane[ KB/s] pozostałych dwóch. Wida na nim, e wzrost natenia danych prawie w ogóle nie wpływa na wzrost prawdopodobiest wa. Przy maksymalnej wartoci, prawdopodobiest wo wynosi zaledwie 8%. Jest to jak najbardziej prawidłowa warto, gdy przy tego rodzaju ataku, agresorowi zaley na przesłaniu jak najwikszej iloci pakietów i ich rozmiar powinien by jak najmniejszy. Testy wykazały, e pomimo pewnych drobnych niedocigni system BIDS dobrze rozpoznaje ataki i moe by skutecznych i przydatnych narzdziem do walki z agresorami. Uzyskanie lepszych wyników wizałoby si prawdopodobnie z udoskonaleniem procesu uczenia (bardziej reprezentatywne próbki) oraz zmodyfikowaniem sieci Bayesa. 3.2. Testy wydajnociowe Celem tych testów było zmierzenie obcienia systemu, jakie powoduje system BIDS podczas najwikszej powodzi, jak uda si zasymulowa. W tym tecie bd badane dwa kluczowe parametry: Ilo zuytej pamici [w kb] - CPU. Zajto czasu procesora [%] - MEM. TCP SYN Flood

Działanie innych usług na testowanym serwerze została ograniczona do minimum, aby nie mogły one wpłyn na wyniki. W tym tecie serwer bdzie zalewany pakietami TCP na przypadkowe usługi z przypadkowym adresem ródłowym oraz portem ródłowym. Czas pomiaru dla kadego z protokołów do 10 minut kady. Wykresy obcienia procesora i zuycia pamici dotycz typu procesu systemowego BIDS. ICMP UDP TCP Czas pomiaru 576 s 546 s 711 s rednia ilo pakietów 571,77 p/s 420,23 p/s 370,72 p/s Warto rednia CPU 56,78 % 57,01 % 54,99 % Warto minimalna CPU 0 % 0 % 0 % Warto maksymalna CPU 77,88 % 74,86 % 75,96 % Warto rednia MEM 4603,05 KB 4561,89 KB 4899,42 KB Warto minimalna MEM 3072 KB 3084 KB 3088 KB Warto maksymalna MEM 4700 KB 4628 KB 5028 KB Wykorzystanie zasobów komputera podczas testów wydajnociowych Warunki przeprowadzonego testu miały na celu wywołanie maksymalnego obcienia sytemu. W sytuacji, kiedy kady z pakietu wysłanego do serwera miał losowy numer IP i port (ródłowy), BIDS był zmuszony do przydzielenia kademu z nich 6000 5500 5000 4500 4000 3500 3000 pojedynczego rekordu w pamici. Dlatego we wszystkich przypadkach w cigu pierwszych 60 s nastpuj gwałtowny wzrost wykorzystanej pamici. Po 60 s 0 50 100 150 200 250 300 350 400 450 500 550 600 (czas ycia t [s] rekordu), pierwsze alokowane rekordy straciły swoj wano i zostały nadpisane przez nowe dane. Dynamika przydziału nowych bloków spadła praktycznie do zera i utrzymała si do koca MEM [KB] cpu [%] 100 90 80 70 60 50 40 30 20 10 0 0 50 100 150 200 250 300 350 400 450 500 550 600 t [s] testu. Ilo zaalokowanej pamici wynosiła maksymalnie ok 2MB (5028 KB - 3088 KB = 1940 KB) w przypadku protokołu TCP i nieznacznie mniej w przypadku pozostałych (UDP, ICMP). Wynika to z prostej przyczyny, e pojedynczy rekord dla protokołu TCP zajmuje o kilkadziesit bajtów wicej ni rekordy dla ICMP i UDP.

Inaczej przedstawiało si wykorzystanie procesora. We wszystkich przypadkach, z pocztkowego zera (brak ataku), nastpił gwałtowny wzrost i osignicie maksymalnej wartoci w cigu pierwszych 10 s ICMP 77,88%. Nastpnie wykorzystanie CPU spadło nieznaczne o około 15-20%. W dalszych fazach testu w przypadku wszystkich protokołów wykorzystanie procesora zmieniało si cyklicznie w czasie (raz malało, raz wzrastało), nie wychodzc jednak z widełek 50%-60%. Mona przypuszcza, e przyczynami takiego zachowania mogło by zmiana strategii przydzielania czasu procesora przez system albo konieczno synchronizowania jednej z funkcji wewntrz wtku. Ustalenie dokładnej przyczyny wymaga zastosowania profilera i jest do trudne do przeprowadzenia przy takim obcieniu. Generalnie system przeszedł pozytywnie testy wydajnociowe. Pozytywnie naley oceni bardzo niewielkie wykorzystanie pamici (do 5 MB), co w przypadku dzisiejszych programów jest dobr wielkoci. Nieco gorzej aplikacja radzi sobie z obcianiem procesora jest ono troch za wysokie, ale mieszczce si w granicach rozsdku. Z pewnoci pomogłoby dokładne przeanalizowanie całego kodu aplikacji i jego optymalizacja. Równie zastpienie sekwencyjnego przeszukiwania tablicy rekordów poprzez przeszukiwanie uporzdkowanego drzewa znaczco poprawiłoby wyniki. W dalszej kolejnoci mona by rozway własn, wysoce zoptymalizowan implementacje sieci Bayesa. 4. Podsumowanie W ostatnich latach ataki typu odmowa usługi (DoS, DDoS) stały si prawdziw plag. Ofiarami ich staj si najwiksze firmy z brany nowych technologii: Yahoo, ebay, Amazon (2000), Microsoft (2003 i 2004), SCO (2004). Pomimo, e firmy te dysponuj ogromnymi rodkami, nie powstrzymały zmasowanych ataków na ich serwery. Problem z atakami typu DDoS polega na tym, e nie ma złotego rodka zaradczego. System wykrywania ataków DoS/DDoS - BIDS (Bayesian Intrusion Detection System) jest krokiem na przód w tej walce. Aplikacja ta koncentruje si na wykrywaniu anomalii w nateniu ruchu i jest szczególnie czuła na zwikszony ruch w wybranych protokołach. Załoeniem projektowym było, aby system wykrywał nie tylko kilka okrelonych ataków, ale równie potrafił wykry te nieznane. Poprzez odpowiednio dobrany proces uczenia sieci Bayesa cel został osignity. Pewn obaw było, czy system BIDS bdzie w stanie zanalizowa w czasie rzeczywistym wszystkie dane docierajce do niego podczas ataku. Testy wykazały jednak, e obcienie procesora i wykorzystanie pamici mieci si w bezpiecznych granicach. Zasadnicze testy dotyczce skutecznoci wykrywania ataków, równie wypadły dobrze system poprawnie wykrywa zwikszone natenie przesyłanych pakietów i odpowiednio klasyfikuje rodzaj ataku. Wykorzystanie sieci Bayesa, jako silnika do analizy przechwyconych okazało si bardzo dobrym pomysłem. Ogromn jej zalet jest szybko (kluczowy parametr) oraz moliwo uczenia si poprzez zadanie odpowiednich przykładów zachowania sieci. 5. LITERATURA [1] Bayesian Learning, http://www.andrew.cmu.edu/user/dgovinda/pdf/bayes.pdf. [2] BODZIANOWSKI Łukasz: Bezpieczestwo systemów komputerowych, http://www.bsk.konin.lm.pl/wstep.html.

[3] CASWELL Brian, ROESCH Marty: Snort. The Open Source Network Intrusion Detection System, Sourcefire, INC. 2004, http://www.snort.org/. [4] Cisco - Cisco Intrusion Detection, Cisco Systems, Inc, 2004 http://www.cisco.com/warp/public/cc/pd/sqsw/sqidsz/. [5] CZARNOWSKI Aleksander: DDoS - nowa posta starego ataku, PC Kurier 5/2000, http://www.pckurier.pl/archiwum/art0.asp?id=3873. [6] DOROSZ Piotr., KAZIENKO Przemysław.: Systemy wykrywania intruzów. VI Krajowa Konferencja Zastosowa Kryptografii ENIGMA 2002, Warszawa 14-17 maja 2002 r., s. TIV 47-78. [7]!!"#$"!" #!!%"$#"$ %!!%"%!#%&" [8] Email Bombing and Spamming, CERT Coordination Center, 1999-2002 http://www.cert.org/tech_tips/email_bombing_spamming.html. [9] FERGUSON Paul: Denial of Service (DoS) Attack Resource Page, DTS, 2000, http://www.denialinfo.com/. [10] HPING, Salvatore Sanfilippo, 2004, http://www.hping.org/. [11] Internet Protocol, University of Southern California, 1981, http://www.ietf.org/rfc/rfc0791.txt. [12] Open Systems Interconnection (OSI) Protocols, Cisco Systems, Inc, 2003, http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/osi_prot.htm. [13] Norsys Software Corp., 2004, http://www.norsys.com/. [14] Radford Neal: What is Bayesian Learning, 2004, http://www.faqs.org/faqs/ai-faq/neural-nets/part3/section-7.html. [15] ROTH Dan: Bayesian Learning, http://l2r.cs.uiuc.edu/~danr/teaching/cs346-04/lectures/10-lecbayes- NB4.pdf. [16] Systemy operacyjne, Ranking.PL, Gemius SA, http://www.ranking.pl/rank.php?stat=sysoperal. [17] URAKOWSKI Marcin: Obrona przed Atakami typu odmowa usługi (DoS). Praca magisterska, Wydział Informatyki i Zarzdzania, Politechnika Wrocławska, 2004, http://inet4u.esol.pl/opatou-dos.pdf.