konstruowanie oprogramowania typu

Network Intrusion Detection Systems

Praca magisterska napisana w Instytucie Informatyki

Niniejsza praca jest poświęcona zagadnieniu niezawodnego dostarczania informacji o ruchu w sieci modułom oprogramowania typu NIDS, czyli Network Intrusion Detection Systems. Takie oprogramowanie ma na celu wykrycie prób nieautoryzowanego dostępu lub nadużycia systemów komputerowych.

Oprogramowanie typu NIDS zazwyczaj działa na poziomie sieci lokalnej. Takie programy analizują każdy pakiet, który przepływa przez sieć i starają się symulować jego wpływ na węzeł, który go odbierze. Jeśli obserwowany ruch nosi znamiona wrogiego działania, to NIDS informuje o tym administratora lub samodzielnie podejmuje kroki zaradcze.

W pracy [1] przeanalizowano działanie czterech znanych komercyjnych programów NIDS. Żaden z nich nie umiał przewidzieć, w jaki sposób testowe, nietypowe pakiety TCP zostaną odczytane przez węzły w sieci.

Częścią niniejszej pracy jest projekt i implementacja biblioteki libnids, która ma za zadanie w niezawodny sposób dostarczać dane o ruchu w sieci wyższym warstwom NIDS. Dzięki niej projektant NIDS może skupić się na analizie danych, a nie na ich pozyskiwaniu. Biblioteka została zaimplementowana w języku C. Została przetestowana pod Linuksem, a jej przeniesienie na inny system operacyjny powinno wymagać minimalnych zmian.

Na początku niniejszej pracy w sposób ogólny omówiono zagadnienia związane z bezpieczeństwem w sieci (rozdział 2). W dwóch kolejnych rozdziałach (3 i 4) zamieszczono idee leżące u podstaw NIDS. W rozdziale 5 szerzej opisano problem pozyskiwania danych dla NIDS. Rozdział 6 i 7 to opis libnids. Pracę zamykają rozważania nad nieuchronnymi ograniczeniami NIDS, działających w środowisku systemów Linux (rozdział 8). Szczególną uwagę poświęcono problemowi przewidzenia gospodarki zasobami chronionych węzłów, który do tej pory nie był należycie doceniony.

Po drugie, intruz może sparaliżować pracę systemu, często nie ujawniając swojej obecności. Najprostszym sposobem jest skasowanie wszystkich plików na serwerze. Jeśli intruz nie uzyskał praw nadzorcy, to może on sabotować system przez zużywanie dużej ilości zasobów – pamięci wirtualnej, dysku, czasu procesora.

Dobrze wyszkoleni intruzi nie atakują systemów z komputerów, do których mają legalny dostęp (czyli założone przez administratora konto). W przypadku nieudanego ataku umożliwiałoby to ich łatwą identyfikację i pociągnięcie do odpowiedzialności. Zazwyczaj intruz podporządkowuje sobie pewien słabo zabezpieczony system, zaciera w nim swoje ślady, a następnie może go używać wielokrotnie do atakowania innych celów. Dlatego nawet administrator serwera, który nie zawiera bardzo istotnych danych, również powinien dbać o bezpieczeństwo powierzonego mu systemu, aby utrudnić intruzom poruszanie się w sieci.

Bezpieczeństwo wielu dzisiejszych systemów operacyjnych (w tym Uniksa) oraz protokołów sieciowych (w tym TCP/IP) nie było priorytetem przy ich projektowaniu. Dlatego twórcy ich implementacji mieli duże szanse popełnienia błędów. Niestety są one obecne w wielu miejscach. Ich wykorzystanie daje intruzowi dostęp do systemu lub dodatkowe uprawnienia. Przykładowo, Unix jest napisany w języku C, w którym jest możliwe popełnienie pomyłki programistycznej zwanej przepełnieniem bufora [2] (patrz dodatek C). Wykorzystanie tego błędu jest łatwe i efektywne, stąd jest ulubioną techniką intruzów.

Często bezpieczeństwo jest osłabiane w imię wygody administratora i użytkowników. Przykładowo, nie ma żadnej przyczyny, aby używać nieszyfrowanych protokołów takich jak telnet czy ftp, skoro są dostępne ich bezpieczniejsze odpowiedniki (ssh). Często domyślne konfiguracje systemu operacyjnego mają na celu maksymalną funkcjonalność. Udostępniają wiele usług, które intruz może wykorzystać do swoich celów. Administrator, który nie jest ekspertem, może nie wiedzieć, które usługi może wyłączyć, a które są niezbędne dla działania systemu. Dlatego domyślna konfiguracja często pozostaje niezmieniona przez cały czas istnienia systemu.

Nawet najbezpieczniejszy system jest niewiele wart w rękach niekompetentnego nadzorcy. Wiele systemów zostało spenetrowanych dzięki temu, że domorosły administrator napisał pełen błędów program i nadał mu najwyższe przywileje, co otworzyło furtkę dla intruza. Również wiele komercyjnych aplikacji ma błędy. Czas pracy programisty, który powinien być poświęcony na zabezpieczenie oprogramowania lub systemu przed zakusami intruzów, często jest ograniczany w imię redukcji kosztów.

Praca niniejsza jest poświęcona bezpieczeństwu sieciowemu, stąd pominięto w niej kwestie nie związane bezpośrednio z siecią. Jednakże trzeba pamiętać, że sieć jest tylko jednym ze źródeł zagrożenia. O bezpieczeństwo należy dbać całościowo. Najlepsze zabezpieczenia systemu i aplikacji nic nie dadzą, jeśli nie jest zapewnione fizyczne bezpieczeństwo systemów komputerowych. Jeśli ktoś chce wykraść firmie X jej dane, to jedną z metod jest przecież włamanie do budynku, w którym mieści się serwer i kradzież twardego dysku. Trzeba być przygotowanym również na taką możliwość. Istotne jest sformułowanie i przestrzeganie ogólnej polityki bezpieczeństwa, określonej dla wszystkich członków danej organizacji i jej zasobów komputerowych. Ponadto, według wielu niezależnych źródeł w 80 % przypadków naruszenie bezpieczeństwa systemów należących do organizacji jest dziełem jej pracowników. Fakt, że zazwyczaj mogą być oni łatwo zidentyfikowani, często nie odstrasza wystarczająco. Pamiętając o bezpieczeństwie aplikacji sieciowych, nie wolno zaniedbywać innych systemowych programów, do których mają dostęp użytkownicy lokalni. Jest to tym bardziej istotne, że często intruzi zdobywają najpierw nieuprzywilejowany dostęp do atakowanego systemu.

W pracy [1] Intrusion Detection System, czyli IDS, jest zdefiniowany jako technologia mająca na celu wykrycie i identyfikację działań mających na celu nieautoryzowany dostęp lub nadużycie systemu komputerowego. Według tej definicji, do IDS można zaliczyć zapory przeciwogniowe (ang. firewall) i aplikacje “owijające” (ang. wrappers). Jednakże zazwyczaj mianem IDS określa się systemy bardziej złożone, dysponujące obszerną wiedzą o wzorcach zachowań uznawanych za niebezpieczne.

Im więcej informacji o monitorowanym systemie jest dostępnych dla IDS, tym lepszą ochronę może on zapewnić. Pewne dane, na przykład liczba i rodzaj procesów w systemie czy też identyfikatory zarejestrowanych w nim użytkowników, są najłatwiej osiągalne wtedy, gdy IDS jest uruchomiony na tym samym węźle, który kontroluje. To rozumowanie prowadzi do koncepcji IDS opartego na węźle (ang. host based). Takie systemy często ograniczają się do analizy systemowych dzienników zdarzeń (ang. logs), szczególnie jeśli system operacyjny zapisuje do nich informacje o powstaniu i zakończeniu każdego procesu (ang. accounting).

Warto w tym miejscu wspomnieć o programach zwanych monitorami integralności systemu. Raczej nie można zaliczyć ich do IDS, ale mogą one ściśle z IDS współpracować. Takie programy liczą co pewien czas sumy kontrolne tych plików w systemie, które powinny być niezmienne (w szczególności programów wykonywalnych). Jeśli monitor wykryje zmianę sumy kontrolnej, to oznacza to, że najprawdopodobniej pewien intruz zdołał spenetrować system i zamienić jeden z jego ważnych plików, zwykle w celu późniejszego łatwego uzyskania dostępu. Jest to bezcenne ostrzeżenie dla administratora, który powinien podjąć kroki mające na celu identyfikację i pozbycie się intruza.

Pewne formy ataku nie są wykrywane przez IDS oparte na węźle. Powiedzmy, że atakujący zna lukę w bezpieczeństwie usługi słuchającej na porcie X. Załóżmy, że spróbuje on połączyć się z portem X na każdej z maszyn w naszej sieci. Nawet jeśli na każdym komputerze pracuje jakiś IDS, to żaden z tych systemów nie zauważy nic szczególnego – jednokrotną próbę połączenia się z usługą. Atak jest widoczny w większej skali, na poziomie sieci. Aby go wykryć, IDS musi słuchać całego ruchu w sieci lokalnej. Jest to łatwo osiągalne, jeśli medium sieci jest ethernet. W takim przypadku IDS może być uruchomiony na jednym węźle, którego karta sieciowa jest ustawiona w tryb “rozwiązły” (ang. promiscuous), co powoduje, że odbiera ona wszystkie pakiety przepływające przez sieć. IDS kontrolujący ruch w sieci (zazwyczaj lokalnej) nazywamy NIDS, czyli sieciowy IDS.

Niewątpliwie NIDS otrzymuje dane tylko o ruchu w sieci. Może to być w wielu przypadkach niewystarczające. Jak już wspomniano, do wykrywania ataków lokalnych najlepiej nadają się IDS oparte na węźle. Jednak koncepcja NIDS ma wiele zalet. Po pierwsze, NIDS jest w stanie wykryć atak pochodzący z zewnątrz sieci (na przykład z jednego z milionów węzłów Internetu). Jest to źródło szczególnego zagrożenia. Po drugie, jeden NIDS jest bardziej ekonomiczny i łatwiejszy w zarządzaniu od grupy IDS, rozproszonych po węzłach sieci lokalnej. NIDS analizuje ruch w sieci pasywnie – węzły sieci nie muszą wiedzieć o istnieniu NIDS, co ułatwia jego wdrożenie. Również wydajność sieci ani jej węzłów nie jest obniżona przez działanie NIDS. Te względy powodują, że zainteresowanie NIDS rośnie. Również niniejsza praca jest poświęcona niektórym aspektom funkcjonowania takich systemów.

3.3.1. Ataki typu DOS. Pierwsza z nich to uniemożliwienie dostępu do zasobów (ang. DOS, denial of service). Mają one na celu utrudnienie uprawnionym użytkownikom korzystania z zaatakowanego systemu. Mogą to być ataki wykorzystujące błędy w systemie operacyjnym. Na przykład słynny program “teardrop.c” wysyła serie fragmentowanych pakietów IP (patrz dodatek C), zachodzących na siebie w specyficzny sposób. Wiele systemów nie było przygotowanych na takie nietypowe pakiety – ich nadejście powodowało zawieszenie lub restart systemu operacyjnego.

Najprostszy atak DOS to zatapianie (ang. flood). Polega on na wygenerowaniu dużego ruchu skierowanego do atakowanego systemu. Jeśli jest on podłączony do sieci niezbyt szybkim łączem, to atakujący może całkowicie zająć jego przepustowość, znacząco utrudniając komunikację z zaatakowanym serwerem. Źle skonfigurowane rutery mogą spowodować, że cała sieć zostanie użyta jako “wzmacniacz ICMP” [6]. W takim przypadku atakujący generując przepływ X KB/s może obciążyć atakowany system przepływem nawet 250*X KB/s.

Specyficzną formą powyższego ataku jest zatapianie pakietami TCP z flagą SYN (ang. SYN flood). Takie pakiety inicjują połączenie TCP. Jeśli system otrzyma więcej niż 5 (to standard, ale Linux dopuszcza 128) pakietów SYN skierowanych do jednego portu, to nie jest w stanie zaakceptować nowych połączeń do tego portu do momentu, kiedy jedno z poprzednich żądań połączenia zostanie odrzucone lub zaakceptowane. Atakujący nie dopuszcza do zakończenia zestawienia połączenia TCP. Dopóki pakiety wysłane przez atakującego nie ulegną przedawnieniu (ang. timeout), a jest to czas rzędu minuty, blokują one nowe połączenia.

Niektóre aplikacje sieciowe zużywają dużo zasobów węzła. Otwarcie niezbyt dużej liczby połączeń przez atakującego może zaangażować wszystkie dostępne zasoby, uniemożliwiając pracę innym aplikacjom. Z kolei pewne ważne programy limitują liczbę klientów, którzy mogą się z nimi połączyć w jednostce czasu. Atakujący kosztem otwarcia kilkudziesięciu połączeń może odciąć użytkowników od wielu istotnych usług.

Ataki typu DOS mogą być bardzo uciążliwe. Nie dają one atakującemu kontroli nad serwerem, ale uniemożliwiają korzystanie z niego innym. W wielu przypadkach (na przykład dostawca Internetu, popularny serwer WWW) jest to nie do zaakceptowania. Pewne konstruktywne ataki (na przykład podszywanie się, ang. spoofing, patrz dodatek A) wymagają, aby pewien węzeł sieci był przez krótki czas nieaktywny. Można to osiągnąć właśnie atakiem typu DOS.

3.3.2 Ataki konstruktywne. Tego typu ataki mają na celu uzyskanie dostępu do systemu, często z przywilejami administratora. Wykorzystują one luki w aplikacjach sieciowych lub słabość protokołów. Najczęściej wykorzystywanym błędem jest przepełnienie bufora (patrz dodatek C). Jego pomyślne wykorzystanie daje atakującemu możliwość wykonania dowolnego kodu na serwerze. Można długo wyliczać aplikacje, które były podatne na ten atak. Wystarczy wspomnieć o demonie pocztowym sendmail (praktycznie wszystkie wersje wcześniejsze niż 8.8.0) czy też demonie obsługującym zapytania DNS, named (wersje 4.x). Te programy były używane na wielu odmianach Uniksa. Przepełnienie bufora w aplikacji pracującej pod kontrolą Windows NT jest równie fatalne – opublikowano już niemało konkretnych przykładów wykorzystania tego błędu [7].

Wiele programów (w szczególności często aplikacje CGI) to skrypty interpretatora poleceń (ang. shell), takiego jak bash czy tcsh, oraz skrypty w języku perl. Częstym błędem jest nieuwzględnianie możliwości pojawienia się w danych wejściowych programu znaków specjalnych interpretatora lub perla, takich jak znak “uruchom proces” (czyli ` ) albo znak końca linii (czyli \n). Atakujący może wewnątrz danych posyłanych do serwera zamieścić polecenia interpretatora poleceń lub perla, poprzedzając je jednym ze znaków specjalnych. Niektóre skrypty podczas parsowania danych wywołują interpretator poleceń, podając jako jeden z argumentów dane posłane przez atakującego. Może to doprowadzić do wykonania na serwerze poleceń posłanych przez atakującego.

Niekiedy programy sieciowe próbują ograniczyć zakres usługi, który oferują. Na przykład serwer WWW udostępnia tylko pliki leżące w pewnym wydzielonym podkatalogu. Niestety, pewne serwery nie uwzględniają możliwości pojawienia się w ścieżce żądanego pliku znaku katalogu nadrzędnego (czyli ..). Daje to atakującemu możliwość wyjścia ponad wydzielony katalog, a w konsekwencji dostęp do każdego pliku w systemie, do którego proces serwera WWW ma prawo odczytu.

Ciekawym projektem mającym na celu ustanowienie standardu opisu (i projektowania) IDS jest CIDF, Common Intrusion Detection Framework [5]. Jego autorzy definiują cztery elementy, które można wyodrębnić w każdym IDS. Są to generatory zdarzeń (E-komponenty), moduły analizujące (A-komponenty), moduły magazynujące informacje (D-komponenty) i moduły przeciwdziałające (C-komponenty). Komponent w sensie CIDF może być samodzielną aplikacją lub jej częścią.

Zadaniem E-komponentów jest dostarczanie danych o zdarzeniach w chronionym systemie lub sieci pozostałym komponentom IDS. Interesującymi zdarzeniami mogą być na przykład nadejście pakietu TCP czy też pomyślne zarejestrowanie się użytkownika do systemu. Zdarzenia te same w sobie nie muszą oznaczać próby ataku.

Komponenty A i E produkują bardzo duże ilości danych, które mogą być potrzebne przez dłuższy czas. Zadaniem D-komponentu jest ich magazynowanie i udostępnianie w wygodny sposób administratorowi. W szczególności D-komponenty muszą uwzględniać skończoną pojemność nośników danych.

W przypadku wykrycia ataku IDS zazwyczaj ogranicza się do poinformowania o nim administratora, używając systemowego dziennika zdarzeń czy też pewnych rozproszonych metod, na przykład pułapek SNMP (ang. SNMP traps, patrz dodatek C). W niektórych przypadkach możliwe jest przeciwdziałanie atakowi bez pomocy człowieka. Przykładowo, NIDS może zmodyfikować reguły filtrujące na ruterze tak, aby atakujący nie miał dostępu do chronionej sieci, co może zapobiec dalszym atakom. NIDS może też zerwać podejrzane połączenie TCP. Jeśli IDS jest oparty na węźle, to ma bogatsze możliwości, na przykład wymuszenie zakończenia działania interpretatora poleceń niewłaściwie zachowującego się użytkownika. Wykonaniem takich metod obronnych zajmują się C-komponenty.

4.2.1. Metoda sygnatur. Ta metoda sprawdza się najlepiej przy wykrywaniu znanych ataków. Twórca IDS przypisuje pewnemu atakowi towarzyszący mu ciąg zdarzeń (sygnaturę). Wystąpienie tego ciągu zdarzeń powinno być łatwo wykrywalne. Jeśli IDS odszuka w monitorowanych zdarzeniach sygnaturę, to przyjmuje, że nastąpił atak.

Najczęściej stosowanym typem sygnatur jest wystąpienie pewnego ciągu bajtów w strumieniu TCP. Przykładowo, jeśli atakowana aplikacja jest podatna na przepełnienie bufora (patrz dodatek C), to w 95 procentach przypadków strumień danych skierowany do tej aplikacji przez atakującego będzie zawierał napis (w notacji języka C) ”\xff\xff\xff/bin/sh” . Jest to fragment typowego kodu maszynowego wywołującego interpretator poleceń. Szukanie wystąpienia danego napisu w strumieniu danych jest łatwe – jest to zadanie dopasowywania wzorca (ang. pattern matching). Niestety, sygnatury oparte na wzorcu wykrywają często tylko konkretną implementację ataku. Jest to szczególnie widoczne przy atakach wykorzystujących przepełnienie bufora – atakujący może wykorzystać ten błąd przy użyciu różnych danych.

Pewne sygnatury oparte na wzorcu są wspólne dla wielu ataków. Atakujący zazwyczaj dążą do otrzymania interaktywnej sesji interpretatora poleceń posiadającego uprawnienia nadzorcy. Dlatego za sygnaturę ataku przeciwko systemowi Unix można uznać pojawienie się w strumieniu TCP napisu zachęty (ang. prompt) ”bash#” . Ta sygnatura jest ciekawa, gdyż może wykryć ataki, o których nie wiadomo podczas tworzenia IDS. Ponadto, typowy sieciowy IDS, którego źródłem danych jest ruch w sieci, może wykryć atak typowo lokalny, przeprowadzony przez użytkownika zarejestrowanego w systemie za pomocą sesji programu telnet. Wady tej sygnatury są jednak doskonale widoczne. Atakujący może osiągnąć wszystkie swoje cele bez pomocy interaktywnej sesji interpretatora poleceń. Wzorzec ”bash#” będzie widoczny tylko w niekodowanym strumieniu danych – atakujący, który użyje ssh w celu zarejestrowania się w systemie, uniknie wykrycia. Jest też duża szansa wystąpienia fałszywego alarmu (ang. false positive).

Znacznie mocniejszą sygnaturą jest ogólny opis metody wykorzystania błędu obecnego w aplikacji. W przypadku przepełnienia bufora będzie to “jedna z danych wejściowych aplikacji ma rozmiar większy niż MAX”, gdzie MAX jest rozmiarem bufora alokowanego przez aplikację. Wszystkie ataki wykorzystujące przepełnienie tego bufora mogą być wykryte przy pomocy tej sygnatury. Dlatego nazwijmy ją sygnaturą uniwersalną. Jednakże IDS musi umieć interpretować dane napływające do aplikacji – czyli parsować je według protokołu czy też gramatyki używanej przez aplikację. Czyni to IDS znacznie bardziej złożonym i trudniejszym do rozbudowy – dodanie sygnatury nowego ataku przeciwko pewnej aplikacji wymaga dodania do IDS umiejętności parsowania jej danych.

4.2.2. Wykrywanie anomalii. Jak już wspomniano, metoda sygnatur zazwyczaj nie sprawdza się w przypadku nieznanych ataków, gdyż dla nich nie istnieją sygnatury. Aby się przed nimi bronić, można zbudować pewien profil działalności obserwowanych obiektów (użytkownika, sieci lub jej węzła) a następnie wykrywać odchylenia od tego profilu. Im silniejsze odchylenie, tym większe prawdopodobieństwo, że w obserwowanym systemie dzieje się coś niepokojącego.

Dość łatwo zauważalną anomalią jest skanowanie portów (patrz dodatek C). Duża liczba połączeń inicjowanych przez jeden węzeł sieci wyraźnie odróżnia się od profilu. Zauważmy jednak, że atakujący może wykonać skanowanie powoli, w tempie powiedzmy jednego portu na godzinę. Wtedy odchylenie od profilu może być zbyt małe. Ten przykład ilustruje ogólną słabość metod opartych na statystyce – atakujący może prowadzić nietypowe działania powoli lub w przemieszaniu z niegroźną aktywnością, co ujdzie uwagi IDS.

Wykrywanie anomalii jest trudne do zaimplementowania. Dobór kryteriów używanych przy konstruowaniu profilu, progowe wartości odchyleń powodujących wszczęcie alarmu i inne parametry tej metody nie są oczywiste ani jednoznaczne. Dla potrzeb tej metody używano algorytmów ewolucyjnych i genetycznych oraz pojęć zapożyczonych z badań nad sztuczną inteligencją, jak sieci neuronowe i logika rozmyta. Niestety, rezultaty nie są do tej pory na tyle obiecujące, aby uznać tę metodę za wiodącą przy projektowaniu IDS. Jednakże obecnie badania nad wykrywaniem anomalii są prowadzone intensywnie, są więc szanse na szersze uwzględnienie tej metody przez przyszłych twórców IDS.

Wymienione w tytule podrozdziału systemy to głównie zapory przeciwogniowe i skanery luk (ang. vulnerability scanner). Pierwsze z nich rozdzielają sieci o różnym poziomie bezpieczeństwa. Drugie z nich aktywnie badają węzły sieci, starając się znaleźć w nich luki i poinformować o nich administratora, zanim węzłem zainteresuje się intruz.

NIDS uzupełniają oba wymienione typy systemów. Zapory nie chronią przed atakami, których źródło znajduje się w sieci lokalnej. Poza tym zapory nie zatrzymują pewnych form ataków (na przykład skanowania portów, patrz dodatek C). Ponadto, niekiedy nie można pozwolić sobie na zablokowanie na zaporze pewnych ważnych, lecz potencjalnie niebezpiecznych usług.

Dla typowego NIDS jedynym źródłem danych są przepływające przez sieć pakiety. Aby NIDS był użyteczny, musi on przewidywać reakcję węzła na kierowany do niego ruch. W szczególności, konieczna jest możliwość odtworzenia danych, jakie system operacyjny przekaże aplikacji, kiedy ta wykona operację czytania z gniazda sieciowego. Oznacza to potrzebę emulacji stosu TCP/IP chronionych maszyn.

Po obejrzeniu pakietu NIDS musi najpierw zdecydować, czy pakiet IP zostanie zaakceptowany przez węzeł, do którego jest skierowany. Jak przekonamy się dalej, nie jest to trywialny problem. Powinno być jasne, że jeśli węzeł przyjmie pakiet, a NIDS go odrzuci, to pojawią się problemy. W odrzuconym pakiecie mogły znajdować się dane, które wykorzystywały luki w bezpieczeństwie pewnej aplikacji. Intruz mógł pomyślnie dokonać ataku, a NIDS tego nie zauważył. Taka akcja intruza jest określona w pracy [1] jako atak typu uniknięcie (ang. evasion).

Mniej oczywiste jest to, że równie fatalna jest sytuacja odwrotna, gdy NIDS akceptuje pakiet i analizuje jego zawartość, a węzeł go odrzuca. Konsekwencje są najlepiej widoczne na przykładzie protokołu TCP. Ponieważ pakiety TCP (ogólnie, IP) mogą przybywać do celu w kolejności różnej od tej, w jakiej były wysłane, kolejność danych zawartych w pakietach TCP jest ustalana przez liczby naturalne zwane numerami sekwencji (ang. sequence numbers). Bajtom danych w strumieniu TCP są przypisane kolejne numery sekwencji. W nagłówku każdego pakietu TCP jest zawarta informacja (numer sekwencji pakietu), jaki jest numer sekwencji pierwszego bajtu danych zawartych w tym pakiecie. Zazwyczaj pakiety TCP przybywające do węzła mają rosnące numery sekwencji. Jeśli węzeł otrzyma pakiet TCP o numerze sekwencji X, a następnie otrzyma pakiet TCP o tym samym numerze sekwencji X, to dane z drugiego pakietu nie zostaną przekazane do aplikacji (zostanie on potraktowany jako retransmisja). Intruz może stworzyć następujący scenariusz. Najpierw wysłany jest pakiet TCP o numerze sekwencji X, który nie zostanie przetworzony przez docelowy węzeł (na przykład nie będzie zgadzać się suma kontrolna nagłówka IP), ale NIDS go zaakceptuje. Następnie atakujący wysyła pakiet TCP o numerze sekwencji X, zaakceptowany zarówno przez węzeł, jak i przez NIDS. Jak widać, aplikacja na węźle otrzyma dane z drugiego pakietu (potencjalnie groźne), a NIDS będzie sądzić, że z pierwszego (w którym atakujący zawrze nieszkodliwe dane). Taka akcja intruza jest określona w pracy [1] jako atak typu wstawienie (ang. insertion).

Powyższe twierdzenie wymaga pewnego uzupełnienia. Aby NIDS mógł działać poprawnie, musi on otrzymywać od fizycznego nośnika datagramów sieciowych takie same pakiety co chronione węzły, w tej samej kolejności i względnych odstępach czasowych. Abstrahując od poprawności algorytmów używanych przez NIDS, jeśli dostaje on pakiety w inny sposób niż chronione węzły (w sensie powyższych warunków), to może on działać niepoprawnie. Co więcej, jeśli atakujący może wytworzyć w powtarzalny sposób sytuację, w której jeden warunków wymienionych powyżej nie jest spełniony, to NIDS może być powtarzalnie ominięty. Warunki będą spełnione, jeśli NIDS będzie działać na jednym z węzłów sieci lokalnej, będzie monitorował inne węzły tej sieci, a medium sieci jest ethernet. Dlatego jest to najczęstsza topologia, w jakiej położony jest NIDS.

Z podanego w poprzednim podrozdziale twierdzenia wynika, że budowanie NIDS należy zacząć od skonstruowania niezawodnego stosu TCP/IP. Nie jest to łatwe. W każdym systemie operacyjnym kod realizujący obsługę sieci jest obszerny. W źródłach jądra Linuksa 2.0.36 katalog net/ipv4 zajmuje 789 KB. Jest to efektem złożoności obecnie używanych protokołów sieciowych.

Skupmy się najpierw na poziomie protokołu IP. Inne protokoły sieciowe są oparte na IP, więc błąd popełniony podczas interpretacji pakietu IP może spowodować niewłaściwą interpretację danych przesyłanych w nadrzędnym protokole. W pracy [1] autorzy wyliczają możliwe powody odrzucenia pakietu IP przez węzeł pracujący pod kontrolą systemu operacyjnego FreeBSD 2.2. Są one zamieszczone w poniższej tabeli. W pierwszej kolumnie podano numer linii pliku netinet/ip_input.c, w której funkcja ip_input() wychodzi z błędem.

Ponadto funkcja ip_dooptions() może zwrócić błąd w 12 przypadkach (co spowoduje odrzucenie pakietu). Tak więc widzimy, że problem określenia, czy węzeł zaakceptuje pakiet IP, jest złożony.

Integralną cechą protokołu IP jest fragmentacja (patrz dodatek C). NIDS musi umieć składać fragmentowane pakiety IP. Jeśli nie jest w stanie tego dokonać, atakujący wykona prosty atak typu uniknięcie używając fragmentacji. Warto zauważyć, że realizacja defragmentacji IP była piętą Achillesową wielu systemów operacyjnych. Twórca NIDS powinien starać się uniknąć powtórzenia błędów zawartych w innych implementacjach. Szczególną uwagę należy poświęcić obsłudze nakładających się fragmentów IP.

Rozważmy teraz poziom protokołu TCP, którego używa ogromna większość aplikacji sieciowych. Również dla systemu FreeBSD 2.2 autorzy pracy [1] podają powody, dla których pakiet TCP może nie zostać zaakceptowany. Jest ich 31. Jednakże w większości przypadków generowany jest pakiet RST (co NIDS łatwo zauważy) lub też mogą się one zdarzyć już po zakończeniu przesyłania danych (po wysłaniu pakietu z flagą FIN), co nie daje intruzowi możliwości przeprowadzenia ataku typu wstawienie. Pozostają jednak cztery przypadki związane z niepoprawnymi wartościami pól nagłówka TCP, które NIDS musi koniecznie uwzględniać.

Protokół TCP jest znacznie bogatszy od IP. Definiuje on wiele stanów, w jakich może znaleźć się gniazdo. Interpretacja pakietu może zależeć od stanu gniazda, do którego pakiet skierowano. NIDS musi więc utrzymywać informację o stanie gniazd, tworzących śledzone połączenie. Sterowanie przepływem, stanowiące integralną część protokołu TCP, musi być uwzględnione przy projektowaniu każdego E-komponentu. Niewłaściwe zaimplementowanie dowolnej właściwości protokołu TCP daje intruzowi możliwość ataku. Dlatego podsystem NIDS rozpoznający TCP musi być z konieczności złożony, a przez to podatny na błędy. Stąd jego projekt wymaga szczególnej uwagi.

W poprzednim podrozdziale przedstawiono część zagadnień związanych z emulowaniem stosu TCP/IP przez NIDS. Jest ich pokaźna, ale skończona liczba. Może to wywrzeć wrażenie, że skonstruowanie niezawodnego E-komponentu NIDS to tylko kwestia uważnego przestudiowania odpowiednich dokumentów RFC definiujących protokoły i ich dokładnego zaimplementowania. Niestety, okazuje się, że różne systemy operacyjne w różny sposób implementują protokoły sieciowe, co prowadzi do odmiennej interpretacji takiego samego strumienia TCP przez różne systemy. Można podać przynajmniej dwie przyczyny takiego stanu rzeczy.

Typowym przykładem jest problem związany z danymi pilnymi (ang. urgent data). Protokół TCP daje możliwość posłania w ramach połączenia TCP jednego bajtu, który nie należy do zwykłego strumienia danych. Zazwyczaj jego wystąpienie ma sygnalizować pojawienie się nietypowych warunków, na które należy pilnie zareagować (stąd nazwa). Lokalizację bajtu pilnych danych określa pole w nagłówku pakietu TCP, zwane wskaźnikiem danych pilnych (ang. urgent pointer). Jeśli oznaczymy przez PTR sumę wskaźnika pilnych danych i numeru sekwencji pakietu TCP, to według specyfikacji protokołu TCP numer sekwencji bajtu danych pilnych jest równy PTR. Niestety, większość systemów przyjmuje PTR minus jeden jako położenie danych pilnych. W przypadku, kiedy NIDS bazuje na sygnaturach opartych na wzorcu, niewłaściwa interpretacja nawet jednego bajtu może spowodować, że wzorzec nie zostanie znaleziony w strumieniu TCP.

W dodatku B zamieszczono opis błędu w jądrze Linuksa 2.0.36, związanego z interpretacją pilnych danych. Jak zwykle, może on być wykorzystany przez intruza.

Kolejną kwestią jest obecność w pakiecie TCP flagi ACK. Jeśli jest ona ustawiona, to pole w nagłówku pakietu TCP zwane potwierdzanym numerem sekwencji (ang. acknowledgment number) określa, ile danych w tym połączeniu TCP otrzymał system wysyłający pakiet. Specyfikacja protokołu TCP stwierdza, że w normalnym połączeniu TCP tylko pierwszy pakiet nie ma ustawionej flagi ACK. Jest to naturalne – wszystkie następne pakiety powinny potwierdzać nadejście otrzymanych uprzednio danych. Większość systemów nie przekaże do aplikacji danych otrzymanych w pakiecie TCP bez ustawionej flagi ACK. Jednak niektóre (między innymi Linux) czynią przeciwnie.

Ciekawy przykład świadomego naruszenia protokołu TCP, którego implikacje dla NIDS nie były dotąd zauważone, można znaleźć w kodzie jądra Linuksa. Na wielu systemach pracujących pod tym systemem używana jest wersja instalacyjna jądra. Zawiera ona podsystem filtrowania pakietów, udostępniający funkcjonalność zapory. Domyślnie reguły filtrujące zapory są puste. Należałoby zatem się spodziewać, że obecność podsystemu filtrowania nie wpływa na to, jakie pakiety zostaną zaakceptowane przez jądro. W rzeczywistości jest inaczej. W kodzie zapory znajduje się pewna reguła, która nie jest definiowana przez administratora, ale wpisana na stałe – nie można w żaden sposób jej usunąć. Jej efekt jest taki, że fragmentowany pakiet IP o długości 28, niosący część pakietu TCP, jest zawsze odrzucany. Komentarz w kodzie zapory stwierdza, że jedynym powodem pojawienia się tak krótkiego pakietu jest akcja intruza, tak więc dla poprawy bezpieczeństwa pakiet należy odrzucić. W istocie, taki pakiet zawiera tylko część nagłówka TCP, dlatego zapora może mieć za mało informacji, aby zadecydować o odrzuceniu takiego pakietu. Posyłanie tak krótkich pakietów jest znaną techniką intruzów, stosowaną w nadziei przemycenia pakietów przez niektóre zapory.

Niestety, w celu ominięcia NIDS atakujący może wykorzystać każde odstępstwo implementacji od standardu, nawet jeśli zostało uczynione w intencji poprawienia bezpieczeństwa. Jeśli NIDS nie uwzględnia opisanej wyżej własności jądra Linuksa, to intruz może poprzedzić atak wysłaniem fragmentu pakietu TCP o długości 28. NIDS zaakceptuje taki pakiet, a węzeł go odrzuci. Jest to scenariusz ataku typu wstawienie.

5.3.2. Niezdefiniowanie i opcjonalność niektórych fragmentów protokołów. Pewne istotne parametry protokołów sieciowych nie są podane w ich specyfikacji. Z kolei niektóre cechy protokołów zdefiniowano, ale nie wymaga się ich implementacji.

Największym źródłem rozbieżności między różnymi systemami jest niezdefiniowanie ilości zasobów, które system powinien poświęcić na obsługę sieci. Bliżej temu zagadnieniu przyjrzymy się w rozdziale 8.

Zasoby każdego komputera są ograniczone. Kiedy program nie jest w stanie uzyskać od systemu operacyjnego dostatecznej ilości zasobów, zazwyczaj jest zmuszony awaryjnie zakończyć pracę lub jego poprawne działanie jest niemożliwe.

Zupełnie analogiczny problem jest związany z kolejkowaniem segmentów TCP, które atakujący również może wysyłać w kolejności odwrotnej do tej, w jakiej zostaną złożone. Rozdział 8 przedstawia algorytm, jaki zastosowano w jądrze Linuksa 2.0.36 oraz problemy z nim związane.

Jak już wspomniano, do niezawodnego wykrywania ataków na aplikacje niezbędne jest parsowanie protokołu danej usługi. Wymaga to zazwyczaj pewnej ilości operacji na tekstach, które mogą być kosztowne. Również daje to intruzowi możliwość ataku.

Jeśli węzeł posiada szybki interfejs sieciowy i wolny procesor, to w wyniku dużego ruchu procesor może nie nadążać z kopiowaniem pakietów z karty sieciowej do przestrzeni jądra. Również spowoduje to, że NIDS nie zobaczy istotnych pakietów przepływających przez chronioną sieć.

Konieczność wygenerowania znacznego ruchu oznacza, że intruz może wykonać opisywany atak prawie wyłącznie wtedy, kiedy źródłem ataku jest węzeł w sieci lokalnej.

Zazwyczaj tylko protokół TCP daje wiarygodną informację o adresie nadawcy pakietów. Oznacza to, że atakujący może wygenerować dużą liczbę pakietów IP ze sfałszowanym adresem nadawcy, licząc na to, że komunikaty tworzone przez NIDS nie zdradzą źródła ataku. Mogą one natomiast zużyć całe wolne miejsce na dysku, co efektywnie zablokuje NIDS.

Duża liczba komunikatów tworzonych przez NIDS jest problemem nie tylko w przypadku, gdy przechowuje się je na dysku. Jeśli NIDS wysyła ostrzeżenia dla administratora pocztą elektroniczną albo przy użyciu wiadomości SMS, to konsekwencje mogą być jeszcze gorsze.

while A niepusty do begin

poślij jednobajtowy pakiet o numerze sekwencji send_seq

function ip_evictor

weź z listy ip_queue pierwszą strukturę ipq, usuń ją i jej zawartość

end

Stałą IPFRAG_LOW_THRESH zdefiniowano jako 192 KB.

6.2.2. Śledzenie strumienia TCP. Najważniejszą część E-komponentu stanowi algorytm składania segmentów TCP w strumień danych. Algorytm ten musi uwzględniać kolejkowanie segmentów oraz możliwość wystąpienia duplikowanych lub zachodzących na siebie pakietów TCP. Oczywiście konieczne jest zaimplementowanie całego protokołu TCP, czyli schematu nawiązywania i kończenia połączenia, śledzenia numerów sekwencji, uwzględniania danych pilnych i wielu innych zagadnień.

Aby skorzystać z oferowanej przez libnids możliwości śledzenia każdego strumienia TCP, programista musi przekazać tej bibliotece adres pewnej funkcji F, która będzie w przyszłości wywoływana przez libnids. Deklaracja tej funkcji musi mieć postać

void (struct tcp_stream * ns, void ** param)

Programista może przekazać do libnids adresy dowolnie wielu funkcji o podanym działaniu. Ten sam strumień TCP może być oglądany przez więcej niż jedną funkcję.

6.2.4. Inne własności. Libnids udostępnia wiele innych funkcji. Dokładny opis ich wszystkich znajduje się w plikach nagłówkowych stanowiących część kodu libnids; część z nich opisano w dodatku D. Warto wspomnieć o niektórych z nich.

a) dostęp do każdej warstwy protokołu TCP/IP. Użytkownik może zdefiniować funkcję, która będzie wywoływana po nadejściu pewnego typu pakietu (IP, defragmentowanego IP, TCP, UDP), co ułatwia rozszerzenie funkcjonalności libnids.

Najważniejszą własnością libnids miała być wysoka niezawodność, z jaką ta biblioteka miała rekonstruować ruch kierowany do wybranego systemu – Linuksa 2.0.36. Cel ten miały przybliżyć dwie techniki: użycie części kodu jądra Linuksa do budowy libnids oraz dogłębne testowanie.

Zamierzony cel został prawie osiągnięty. Szczególnie defragmentacja pakietów IP, dzięki zapożyczeniu dużej części kodu ze źródeł Linuksa, powinna działać wysoce niezawodnie. Również emulacja kolejkowania segmentów TCP zachowuje się zgodnie z oczekiwaniami.

Możliwe były dwie metody usunięcia powyższego problemu. Pierwszą z nich było zaimplementowanie w libnids wadliwego sposobu obsługi protokołu TCP przez jądro. Jednakże po usunięciu tych usterek przez programistów rozwijających jądro Linuksa, libnids nie funkcjonowałaby poprawnie.

Wybrano inną drogę. Informacja o zauważonych błędach została przekazana osobie odpowiedzialnej za przygotowanie nowej wersji jądra Linuksa, mianowicie 2.0.37. Ta wersja powinna ukazać się na przełomie czerwca i lipca 1999 roku. Zauważone błędy mają być w niej usunięte. Tak więc libnids będzie najlepiej chronić systemy oparte na tej wersji jądra.

W celu zapewnienia jak największej funkcjonalności, libnids jest w wysokim stopniu konfigurowalna. Szereg istotnych parametrów można zmieniać bez rekompilacji biblioteki. Poza tym, dostępność jej kodu źródłowego pozwala na dokonywanie wszystkich potrzebnych modyfikacji tego kodu przez użytkownika biblioteki.

Rozdział ten zawiera szczegółową analizę algorytmów używanych przez jądro Linuksa 2.0.36 do kontroli zasobów potrzebnych do utrzymywania informacji o stanie gniazd sieciowych.

Najistotniejszym rozszerzeniem libnids byłoby dodanie możliwości niezawodnej rekonstrukcji ruchu w sieci skierowanego do systemów innych niż Linux. Spowodowałoby to konieczność dodatkowej konfiguracji libnids – dla każdego chronionego adresu IP musiałby być znany system operacyjny zainstalowany na węźle o tym IP.

Przy implementacji libnids intensywnie wykorzystano dostępność źródeł systemu, który libnids ma emulować. W szczególności pliki ip_fragment.c i ip_options.c, stanowiące część kodu libnids, są mocno przerobionymi odpowiednimi plikami z kodu jądra Linuksa. Również przy implementacji symulowania protokołu TCP stosowano liczne zapożyczenia z jądra Linuksa.

Aby projekt opisany w powyższym akapicie powiódł się, konieczne będą pewne modyfikacje kodu wyjętego z jądra Linuksa. Przykładowo, po zobaczeniu pakietu TCP z flagą SYN kod ten powinien wytworzyć w swoich strukturach danych realizację gniazda akceptującego połączenia (znajdującego się w stanie LISTEN) i zrealizować połączenie.

Libnids jest E-komponentem. Niektóre fragmenty funkcjonalności innych typów komponentów mogłyby zostać łatwo zaimplementowane. Przykładowo, każdy A-komponent potrzebuje modułu realizującego parsowanie strumienia danych według jednej z zadanych nieskomplikowanych gramatyk. Prosty, wydajny parser warto włączyć do biblioteki, która ma ułatwiać konstruowanie NIDS.

Niestety, wydaje się, że twórcy współczesnych NIDS nie przywiązują należytej wagi do problemów poruszonych w niniejszej pracy. Większość NIDS można ominąć przy pomocy nieskomplikowanych ataków.

Ciekawa byłaby analiza innych systemów operacyjnych pod kątem łatwości symulowania ich działania przez NIDS. Obecnie używane protokoły sieciowe są tak skomplikowane, że nader prawdopodobne jest znalezienie w każdym systemie fragmentów kodu o działaniu trudnym do przewidzenia.

Nawet proste ataki przeciwko NIDS wymagają sporej wiedzy. Wielu administratorów, nawet zaznajomionych z zagadnieniami bezpieczeństwa, skłania się ku lekceważeniu intruzów. Funkcjonuje wizerunek intruza, który jest niedouczonym nastolatkiem, włamującym się do słabo zabezpieczonych serwerów w celu zdobycia poważania w swoim środowisku. Tworzenie oprogramowania z założeniami takimi, jakie przyjęto przy projektowaniu libnids, może wydać się niepotrzebne.

Wreszcie oczywistym być powinno, że o dobrze wyszkolonych intruzach słychać niewiele dlatego, że oni sobie tego nie życzą. Zidentyfikowanie ich podczas próby ataku jest praktycznie niemożliwe – zbyt wiele istnieje sposobów na utrudnienie dotarcia do rzeczywistego źródła agresji. Podsumowując – zagrożenie jest realne. Dlatego każdy projekt, który ma na celu utrudnienie intruzom ataku, zasługuje na uwagę. Czas spędzony na implementacji libnids nie został stracony.

Dodatek ten zawiera opis dwóch błędów w kodzie sieciowym jądra Linuksa, które zostały wykryte dzięki libnids.

Co gorsza, protokół IP zezwala, aby dane z poszczególnych fragmentów zachodziły na siebie (to znaczy przykładowo: pierwszy pakiet przenosi bajty danych o numerach od 0 do 15, a drugi o numerach od 8 do 23). Starsze systemy operacyjne nie przewidywały wszystkich implikacji takiej sytuacji. Odpowiednio spreparowane fragmenty IP mogły spowodować zawieszenie się lub restart systemu operacyjnego.