Praca Dyplomowa (Inżynierska) - SourceForgeanalizator.sourceforge.net/ifs-doc.pdf · Praca...

Politechnika ŚląskaWydział Elektroniki, Automatyki i Informtyki

kierunek: Informatyka

Praca Dyplomowa(Inżynierska)

Analizator ruchu TCP/IP w języku symbolicznym procesora ix86 pod system Linux.

Autor: Damian Gołębiowski Prowadzący pracę: dr inż Adam Domański

Gliwice 2005

Spis treściWstęp....................................................................................................................................................31. Zasady działania sieci IP i jej zastosowania.....................................................................................5

1.1. Protokół IP................................................................................................................................81.2. Protokół TCP..........................................................................................................................101.3. Protokół UDP..........................................................................................................................131.4. Protokół ICMP........................................................................................................................14

2. Istniejące rozwiązania monitorowania ruchu i ich porównanie......................................................152.1. tcpdump..................................................................................................................................152.2. iptraf........................................................................................................................................172.3. ethereal....................................................................................................................................19

3. Założenia dotyczące budowy analizatora.......................................................................................234. Wybór narzędzi i języków programowania....................................................................................25

4.1. sniffer – asembler....................................................................................................................254.2. grapher, Perl, PHP...................................................................................................................30

5. Specyfikacja wewnętrzna oraz fragmenty procedur.......................................................................325.1. sniffer......................................................................................................................................325.2. grapher....................................................................................................................................43

6. Specyfikacja zewnętrzna (użytkownika)........................................................................................486.1. sniffer......................................................................................................................................486.2. grapher....................................................................................................................................57

7. Testowanie i przykładowe wyniki działania oprogramowania.......................................................617.1. Ping (icmp).............................................................................................................................617.2. Traceroute (icmp)....................................................................................................................617.3. Nawiązywanie połączenia TCP..............................................................................................627.4. Transmisja w strumienu TCP.................................................................................................637.5. Zakończenie połączenia TCP..................................................................................................637.7. Ataki odmowy usługi i skanowanie........................................................................................647.9. Przechwytywanie haseł, protokół FTP....................................................................................667.10. Wykresy graphera dla przykładowego ruchu sieciowego.....................................................687.11. Porównanie istniejących rozwiązań z wykonanym analizatorem.........................................73

8. Podsumowanie................................................................................................................................749. Bibliografia.....................................................................................................................................75

2

Wstęp

Prowadzony od roku 1957 projekt budowy rozległej sieci łączącej komutery na całymświecie, zapewniającej szybką i niezawodną transmisję danych, na początku lat dziewięćdziesiątychwszedł w etap dynamicznego rozwoju. Sieć zbudowana w oparciu o połączenie wielu sieciz wykorzystaniem rodziny protokołów TCP/IP, nazwana Internetem, połączyła wiele krajów, w tymrównież Polskę. Początkowo militarne wykorzystanie sieci zostało poszerzone o zastosowanianaukowe oraz komercyjne, co spowodowało zwiększenie popularności tej formy komunikacji i jejbłyskawiczny rozwój.

Wraz z rozszerzaniem zasięgu i przepustowości sieci oraz zwiększaniem ilości podłączonych doniej komuputerów, pojawiły się nieprzewidywane wcześniej anomalia w jej funkcjonowaniu.Zarządzanie Internetem jest rozproszone i odpowiedzialność za poprawną pracę poszczególnychjego części ponoszą różne organizacje i firmy. Osoby zajmujące się utrzymywaniem ruchu w tychorganizacjach muszą być wyposażone w odpowiedni zestaw narzędzi umożliwiającychmonitorowanie ruchu i diagnozowanie przyczyn potencjalnych awarii.

Autor pracy zajmuje się zawodowo administracją sieci szkieletowej jednego z lokalnychDostawców Usług Internetowych (Internet Service Provider). Na codzień rozwiązuje złożoneproblemy konfiguracji i utrzymania sieci, w czym niezbędną pomocą okazuje się właściweoprogramowanie.

Poniższa praca jest próbą utworzenia aplikacji, umożliwiającej monitorowanie i podstawowąanalizę ruchu w sieciach IP, przy czym największy nacisk położony został na jak najmniejszewymagania sprzętowe i prostotę użycia w dowolnych warunkach. Mimo iż tworzoneoprogramowanie nie posiada nazbyt rozbudowanych funkcji, może stać się ono bardzo przydatnymi efektywnym narzędziem w codziennej pracy administracyjnej.

Pierwszy rozdział pracy stanowi teoretyczny wstęp do zagadnienia transmisji danych miedzykomputerami poprzez sieć IP. Przedstawione są modele budowy sieci oraz różnice pomiędzy nimiwynikające z potrzeby ich praktycznego zastosowania w konkretnej architekturze. Jednymz najistotniejszych elementów architektury sieciowej jest ścisłe określenie sposobu przesyłaniadanych. W przypadku Internetu sposób ten opisuje rodzina protokołów TCP/IP. Opisane zostałypopularne programy sieciowe użytkownika, wykorzystujące poszczególne protokoły dokomunikacji z innnymi hostami.

Rozdział drugi opisuje trzy najczęściej wykorzystywane w sytemie Linux programy monitorująceruch sieciowy. Porównanie rozwiązań opiera się głównie o takie cechy jak rozmiar programu,wymagania dodatkowych bibliotek w środowisku uruchomieniowym, łatwość w użyciu i czytelnośćdanych wyjściowych.

W trzecim rozdziale pracy stawiane są podstawowe wymagania i założenia projektu analizatoraruchu sieciowego. Koncepcja architektury oprogramowania, dzieląca je na kilka części, maumożliwić jak najlepszą realizację założeń. Rozdział ten opisuje poszczególne fragmentyanalizatora, określa ich rolę oraz wzajemną ich zależność i sposób współdziałania.

Czwarty rozdział w zwięzły sposób przedstawia narzędzia wykorzystane do budowy analizatora.Opis każdego z nich zawiera uzasadnienie wyboru konkretnego rozwiązania pod kątem założeńdotyczących całego projektu jak i poszczególnych jego części.

W rozdziale piątym zawarta jest specyfikacja wewnętrzna oprogramowania, czyli opis budowyprogramu od strony programistycznej. Wyróżnione są funkcje realizujące ważniejsze zadania oraz

3

kluczowe struktury danych. Treść tego rozdziału prezentuje tylko poglądowy schemat, gdyż dopełnego zrozumienia algorytmu działania programu niezbędna jest wnikliwa alanliza całego koduźródłowego.

Rozdział szósty stanowi swego rodzaju instrukcję obsługi przeznaczoną głównie dla potencjalnegoużytkownika aplikacji. Przedstawione są w nim sposoby uruchamiania programów, szczegółowyopis dostępnych funkcji, opisy formatów danych wyjściowych. Szczegółowy opis specyfikacjizewnętrznej wzbogacony jest szeregiem przykładów wywołań programów, które ułatwiajązrozumienie zasady działania oraz uniknięcie potencjalnych problemów.

W siódmym rozdziale znaleźć można wyniki uzyskane podczas testowania oprogramowania.Konkretne przykłady zastosowań wiążą się z aplikacjami i protokołami przedstawionymi w częściteoretycznej. Dzięki zastosowaniu analizatora można przyjrzeć się zasadom ich działaniaw rzeczywistym ruchu sieciowym. Rozdział zawiera również proste porównanie zbudowanegoanalizatora z przedstawionymi wcześniej sprawdzonymi rozwiązaniami oraz konfrontację założeńprojektu z jego praktyczną realizacją.

4

1. Zasady działania sieci IP i jej zastosowania

Najczęściej stosowanym sposobem przedstawienia współdziałania poszczególnych częścisprzętu i oprogramowania sieciowego jak również samych protokołów transmisji oraz ichwzajemnego powiązania jest model warstwowy ISO/OSI. Przyjęty jako norma przezMiędzynarodową Orgranizację Normalizacyjną ISO[1] bardzo szczegółowy model opisuje działaniesieci w postaci siedmiu warstw. Ideą tego modelu jest to, że bezpośrednio komunikują się ze sobątylko sąsiednie warstwy, przy czym warstwy niższe świadczą usługi warstom wyższym.

Rysunek 1.1 Model warstwowy ISO/OSI[2]

Opis poszczególnych warstw modelu:

– warstwa fizyczna najniższa warstwa odpowiedzialna za przesyłanie bitów po fizycznymmedium. Brak kontroli ciągłości transmisji powoduje, że w przypadku problemów z dostępem domedium transmisja zostaje wstrzymana.

– warstwa łącza danych bezpośrednio komunikuje się z warstwą fizyczną pełniąc rolęsterownika transmisji bitów. Zwykle dwie pierwsze warstwy modelu łączy się w jedną całośćw postaci karty sieciowej lub modemu.

– warstwa sieciowa warstwa ta odpowiedzialna jest za sterowanie przepływem pakietóww sieci. Zapewnia przekazywanie pakietów przez rutery tak, aby pakiet dotarł od nadawcy doodbiorcy.

– warstwa transportowa umożliwia przesyłanie danych kanałem stworzonym przez warstwęsieciową, przy czym zapenia poprawność i pewność transmisji. W warstwie tej prowadzona jestkontrola poprawności otrzymanych segmentów, ich kolejności, a w przypadku błędówretransmisja zagubionych danych.

– warstwa sesji umożliwia nawiązywanie i zrywanie połączeń przez aplikacje.

5

– warstwa prezentacji w warstwie tej przepływające dane są poddawane kontrolipoprawności i zgodności z formatami prezentacji danych. Zapewnia ona warstwie aplikacji dane,które mogą być przez nią właściwie zinterpretowane.

– warstwa aplikacji zadaniem tej końcowej od strony użytkownika warstwy jestświadczenie usług takich jak udostępnianie plików, drukarek, zasobów baz danych itp.Przykładem aplikacji może być przeglądarka internetowa umożliwiająca prezentacje na ekraniemonitora strony WWW.

W większości przypadków powyższy model jest nazbyt szczegółowy wobec czego przezDepartament Obrony Stanów Zjednoczonych DoD[3] zbudowany został uproszczony,czterowarstwowy model TCP/IP, który lepiej opisuje specyfikę sieci IP.

Rysunek 1.2 Modele DoD i ISO/OSI[2]

W modelu tym dwie pierwsze warsty ISO/OSI zastały połączone w jedną, warstwę dostępu dosieci. Można przyjąć, że sprzęt w postaci karty sieciowej oraz oprogramowanie obsługujące tensprzęt czyli tak zwany sterownik jest dostarczany przez producenta. W warstwie tej wykonywanajest adresacja (MAC Medium Access Control) umożliwiająca jednoznaczną identyfikację stacjisieciowej w segmencie sieciowym, przy czym adresy są przypisywane urządzeniom w procesieprodukcyjnym. Przykładowe protokoły tej warstwy to Ethernet, Decnet, FrameRelay.

Warstwa sieciowa w modelu DoD nazwana została warstwą internetową. Zadaniem protokołówtej warstwy jest zapewnienie ruchu pakietów w Internecie. Realizowane jest to przez odpowiedniąadresację hostów w sieci i przesyłanie pakietów przez rutery, które dzięki informacjom zawartymw nagłówku protokołu wyznaczają trasę pakietu. Warstwa internetu zapewnia również fragmentacjępakietów jak i mechanizm zapobiegający błądzeniu pakietów, które z jakichś przyczyn nie dotarły

6

do adresata. Najczęściej stosowanym protokołem tej warstwy jest IPv4. Efektem ubocznym bardzoszybkiego rozwoju Internetu stała się groźba niemal całkowitego wyczerpania adresów IP. Dlatego,poza wprowadzeniem reglamentacji adresów i rutingu bezklasowego, opracowano wersję6 protokołu IP.

Protokołami warstwy transportowej są TCP i UDP. Jednostka informacji w tej warstwienazywana jest segmentem. W przypadku TCP pomiędzy hostami przekazującymi dane przez siećustanawiane jest połączenie. W połączeniu takim, przed wysłaniem każdy segment jestnumerowany, a odebranie danych przez warstwę transportową stacji odbierającej jest potwierdzanenadawcy. Następnie odbiorca kompletuje dane według kolejności ich nadawania. Protokoły tejwarstwy korzystają z usług protokołu IP, natomiast nagłówek warstwy transportowej zawierainformacje o tym, do której aplikacji wyższej warstwy ma zostać przekazany pakiet.

W przypadku rodziny protokołów Internetu (TCP/IP) w warstwie aplikacji zawierają się trzygórne warstwy modelu OSI. Do warstwy tej należą takie protokoły jak np. FTP, HTTP, DNS,Telnet, SMTP . Aplikacje tej warstwy mogą pracować w określonej architekturze, np. klient-serwer.Wówczas można mówić o oprogramowaniu udostępniającym zasoby jak i o oprogramowaniukorzystającym z zasobów.

Gdy mamy do czynienia ze stacją sieciową w sieci IP, należy mieć świadomość, że korzystaniez oprogramowania użytkowego (warstwa aplikacji) wiąże się z koniecznością przepływu informacjiprzez wszystkie warstwy modelu TCP/IP. W ten sposób dane aplikacji klienta np. protokołu SMTPsą dzielone przez oprogramowanie systemowe na segmenty TCP i opakowywane jego nagłówkiem,następnie segment jest dzielony na pakiety IP i opatrzony zostaje nagłówkiem tego protokołu,w ostatnim kroku pakiety są dzielone na ramki w warstwie dostępu do sieci i dopiero transmitowanedo fizycznego medium. W systemie odbiorcy dane przebywają podobną drogę przez wszystkiewarstwy lecz w przeciwnym kierunku. Uniwersalność tego rozwiązania umożliwia jednoczesnąkomunikację w dwóch kierunkach.

Rysunek 1.3 Transmisja danych przez sieć

7

1.1. Protokół IP

Protokół IP[4] (Internet Protocol) funkcjonuje powyżej warswy kanałowej. Protokół ten niesieinformacje niezbędne do zaadresowania pakietów w sieci TCP/IP. Na podstawie informacjizawartych w nagółówku tego protokołu rutery określają, którą drogą wysłać pakiet, aby trafił on dostacji przeznaczenia. Protokół umożliwia też fragmentację pakietów oraz ustawienie dodatkowychopcji.

Rysunek 1.4 Format ramki protokołu IP[5]

Opis pól nagłówka IP:

– version pole o długości 4 bitów zawiera wersję protokołu, w przypadku IPv4 jest to 4,dla protokołu Ipv6 odpowiednio jest 6.

– ihl pole o długości 4 bitów zawiera całkowitą długość nagłówka liczonąw długich (32-bitowych) słowach. Ponieważ minimalna długość poprawnego nagłówka IPv4wynosi 20 bajtów (pięć 32-bitowych słów), a maksymalną wielkością tego pola jest 15, więcmożna nadać maksymalnie 40 bajtów opcji.

– type of service pole o długości 8 bitów określa rodzaj usługi. Za pomocą tego pola możnaokreślić rodzaj danych w pakiecie, uzyskując np. minimalne opóżnienia.

– total length 16 bitowe pole określa maksymalną wielkość pakietu IP liczoną w bajtach.Ilość rzeczywistych danych pakietu IP można uzyskać przez odjęcie od wartości tego polawielkości nagłówka.

– identification 16 bitowe pole identyfikacji pakietu umożliwia łączenie pofragmentowanychpakietów.

– flags 3 bity flag używanych przy fragmentacji. Kolejne bity flag oznaczają: DF(don't fragment) zakaz fragmentacji pakietu, MF (more fragments) pakiet pofragmentowany,należy spodziewać się kolejnych fragmentów.

8

– fragment offset pole 13 bitowe w połaczeniu z flagami fragmentacji używane dofragmentacji i ponownego łączenia pofragmentowanych pakietów.

– time to live pole 8 bitowe oznaczające czas życia pakietu. Pakiet IP przenoszonyjest w sieci przez rutery. Przy każdym przesłaniu pakietu przez ruter pole to jest zmiejszaneo jeden. Ruter, który zmniejszając wartość TTL datagramu otrzyma wartość zero odrzuca pakiet.Mechanizm ten zapobiega przenoszeniu pakietów, które nie są w stanie w skończonej liczbieprzeskoków osiągnąć stacji przeznaczenia.

– protocol pole 8 bitowe określa rodzaj danych w pakiecie, zwykle jest to numerprotokołu taki jak: 1 (ICMP), 2 (IGMP), 6 (TCP), 17 (UDP).

– header checksum 16 bitowe pole sumy kontrolnej, która jest obliczana z całegonagłówka, łącznie z opcjami.

– source address 32 bitowy adres nadawcy datagramu, umożliwia pełną komunikacjędwukierunkową oraz odebranie komunikatów kontrolnych protokołu ICMP.

– destination address 32 bitowy adres przeznaczenia datagramu, na podstawie którego ruteryokreślają odpowiednią trasę pakietu w sieci IP.

– options dodatkowe opcje, maksymalnie 40 bajtów.

Protokół IP zaprojektowany został do przesyłania bloków danych w sieciach opartych na założeniuprzełączania pakietów. Dane przesyłane są pomiędzy dwoma punktami sieci, od źródła doprzeznaczenia, przy czym punkty te są w unikalny sposób identyfikowane za pomocą adresów IP.Droga pakietu danych wyznaczana jest przez specjalne urządzenia tzw. rutery, na podstawie adresuIP przeznaczenia. Trasa przesyłu nie musi być zawsze taka sama i może prowadzić przez wiele siecitranzytowych. W każdej sieci określona jest maksymalna wielkość jednorazowo przesyłanegopakietu danych (MTU – Maximum Transfer Unit), która zależy od rodzaju medium i protokołuwarstwy łącza. Naturalnym więc zjawiskiem jest sąsiedztwo sieci o różnych dopuszczalnychwielkościach przesyłanych pakietów. Na styku dwóch takich sieci konieczne jest wykonywaniedodatkowych operacji przez ruter, mających na celu podzielenie większych pakietów jednej sieci namniejsze, odpowiednie dla drugiej sieci styku. Proces ten nazywa się fragmentowaniem i jestmożliwy dzięki umieszczeniu w nagłówku protokołu IP dwóch odpowiednich pół. Jedno z tych pólprzechowuje informację o tym, czy pakiet IP jest integralną całością, czy może należy sięspodziewać dalszych jego części. Drugie pole zawiera tak zwane przesunięcie fragmentacji, którezachowuje informację o miejscach podziału oryginalnego pakietu, dzięki czemu umożliwia stacjiodbierającej poprawną defragmentację, czyli złożenie pofragmentowanych danych w odpowiedniejkolejności w pierwotną całość.

Z usług protokołu IP w znacznej większości korzystają protokoły wyższej warstwy - warstwytransportowej - takie jak TCP i UDP. Poza tym również ICMP, definiowany jako protokół warstwyinternetowej, wykorzystuje pełną adresację i wszystkie właściwości protokołu IP. Aby zapewnićidentyfikację protokołów, które są enkapsulowane w ramkach IP, oprogramowanie w stacjachsieciowych zapisuje ich specyficzny numer w nagłówku protokołu IP. Dzięki temu możliwe jestustalenie rodzaju zawartości pakietu bez konieczności rozpakowywania jego danych, co umożliwianp. szybkie filtrowanie.

Datagram IP może zawierać dodatkowe opcje, choć w większości przypadków nie są onewymagane. O tym, czy w danym pakiecie znajdą się opcje decyduje stacja nadająca dane,a wykorzystywane są one najczęsciej do zapewnienia dodatkowego bezpieczeństwa lub wymuszeniaspecyficznego rutingu.

9

1.2. Protokół TCP

TCP[6] (Transmission Control Protocol) funkcjonuje powyżej warstwy internetowej, co oznacza, żenagłówek jak i pakiet TCP jest enkapsulowany przez niższą warstwę, w tym przypadku IP. Jest toprotokół połączeniowy i transmisja danych wymaga ustabilizowania połączenia między hostaminadawcy i odbiorcy. Analogią działania protokołu TCP może być rozmowa telefoniczna. Koniecznejest podniesienie słuchawki przez osobę inicjującą rozmowę, wybranie numeru, podniesieniesłuchawki przez odbiorcę połączenienia. Dopiero wtedy można przesyłać dane, a w tym kontekścieprowadzić rozmowę. Protokół TCP posiada wszystkie te cechy, a dodatkowo mechanizmypotwierdzeń, sterowania transmisją oraz kontroli szybkości przesyłania danych. W przypadkuustabilizowanego połączenia TCP można mówić o transmisji danych pewnym, w pełnidwukierunkowym strumieniem.

Rysunek 1.5 Format ramki protokołu TCP[7]

Opis pól ramki TCP:

– source port 16 bitowe pole określające port źródłowy.

– destination port 16 bitowe pole określające port przeznaczenia. Para portźródłowy/pory przeznaczenia niesie informacje dla warstwy wyższej jak również jednoznacznieokreśla połączenie TCP. Często wykorzystywane porty to np.: 21 ftp, 22 ssh, 23 telnet, 25 smtp,80 http, 110 pop3, 119 news i inne. Pierwsze 1024 porty są zarezerwowane dla dobrze znanychusług, dlatego zwykle aplikacje klienckie wykonujące połączenia inicjują pole port źródłowywielkością spoza tego zakresu.

– sequence number 32 bitowe pole numeru sekwencji określa jednoznacznie numersegmentu i jego przynależność do konkretnego połączenia. Jest wykorzystywane przynawiązywaniu połączenia TCP oraz do określenia kolejności segmentów w strumieniu.

– acknowledgment number 32 bitowe pole potwierdzeń, wykorzystywane w połączeniuz numerem sekwencji przy kompletowaniu segmentów.

– offset 4 bitowe pole przesunięcia.

– reserved 4 bity zarezerwowane.

10

– flags 8 bitowe pole flag. Ustawienie właściwych flag określa rodzaj i rolę segmentuTCP w transmisji. Możliwe wartości to syn, ack, urg, fin, psh, rst.

– window 16 bitowe pole długości okna. Protokół TCP umożliwia sterowanieszybkością transmisji danych. Za pomocą tego pola stacje stabilizujące połączenie negocjująwielkość okna danych, które może być przesłane w jednym segmencie. Podczas transmisji stacjaodbierająca dane wysyła potwierdzenia ustawiając to pole według własnych możliwości odbiorudanych (odpowiednio zmniejsza w przypadku niemożności odbierania danych np. przepełnieniabuforów, obciążenia).

– checksum 16 bitowa suma kontrolna

– urgent pointer 16 bitowy wskaźnik do danych natychmiastowych.

W związku z tym, że protokół TCP zapewnia transmisję danych z wykorzystaniem połączeńpomiędzy dwoma stacjami sieciowymi, musi on umożliwić nawiązywanie, obsługę i przerywanietych połączeń. Implementacje protokołu opierają się o automat stanów skończonych, opisującywszystkie możliwe scenariusze, które mogą wystąpić w trakcie wykorzystywania funkcji protokołu.

Możliwe stany połączenia tcp to:

• CLOSED brak połączenia, gniazdo sieciowe zamknięte

• LISTEN stacja oczekuje na połącznenia, “nasłuchuje”

• SYN_RCVD zdalna stacja inicjuje połączenie

• SYN_SENT lokalna stacja inicjuje połączenie

• ESTABLISHED połączenie nawiązane, ustabilizowano kanał przesyłu danych

• FIN_WAIT1, FIN_WAIT2 oczekiwanie na potwierdzenie zakończenia połączenia

• CLOSE_WAIT, LAST_ACK zakończenie połączenia i potwierdzenia

• CLOSING, TIME_WAIT zamykanie aktywnych gniazd w stacjach sieciowych

Odpowiednie przejścia pomiędzy wyżej wymienionymi stanami następują w obu stacjachsieciowych połączenia, w momencie otrzymywania bądź wysyłania segmentów TCP oznaczonychodpowiednimi flagami:

– SYN synchronizacja numerów sekwencyjnych

– ACK flaga oznaczająca potwierdzenie

– URG wystąpienie wskaźnika danych natychmiastowych

– FIN nie ma więcej danych od nadawcy, koniec połączenia

– PSH funkcja push, segment zawiera dane użytkownika

– RST reset połączenia

Niektóre zmiany stanów, jak na przykład CLOSED->LISTEN (system serwera) lubCLOSED->SYN_SENT (system klienta), wymusza system operacyjny stacji sieciowej. Najczęściejwykorzystywane sekwencje stanów to typowe przejścia CLOSED->ESTABLISHED->CLOSED,czyli nawiązanie połączenia, przesłanie danych i zakończenie połączenia.

11

Nawiązywanie połączenia TCP ze względu na konieczność wymiany conajmniej trzech segmentów,nazywane jest 3-way handshake, a typ flag w tych segmentach zależny jest od roli jaką pełni stacjasieciowa (klient/serwer):

Klient

stan CLOSED

wysłany segment SYN

pośredni stan SYN_SENT

odebrany segment SYN+ACK

wysłany segment ACK

stan ESTABLISHED

Serwer

stan LISTEN

odebrany segment SYN

wysłany segment SYN+ACK

pośredni stan SYN_RCVD

odebrany segment ACK

stan ESTABLISHED

W celu jednoznacznej identyfikacji połączenia, segment SYN stacji inicjującej zawiera losowowybrany numer sekwencyjny (pole sequence number nagłówka TCP), który zwiększony o jedenprzez stację akceptującą połączenie stanowi numer potwierdzenia (pole acknowledgment numbernagłówka TCP). Tak uzyskany numer potwierdzenia umieszczony w nagłówku wraz z losowowygrenerowanym przez stację serwera własnym numerem sekwencyjnym, jest przesyłany do stacjiinicjującej w segmencie SYN+ACK. Ostatnim krokiem jest odesłanie przez stację inicjującązwiększonego o jeden numeru sekwencyjnego serwera w segmencie ACK.

Poprzez tak uzyskany dwukierunkowy kanał, przesyłane są dane użytkownika z wykorzystaniemsegmentów PSH, potwierdzanych przez stację odbierającą za pomocą ACK. W trakcie transmisjiistnieje konieczność sterowania natężeniem przepływu danych, w przypadku przepełnienia buforówbądź przeciążenia jednej ze stacji połączenia. Sterowanie to jest możliwe dzięki dodatkowemu poluprotokołu, które określa maksymalną wielkość okna danych (pole window nagłówka TCP). Wartośćtego pola jest negocjowana przy nawiązywaniu połączenia i zwykle zmienia się w czasie transmisji.

Zakończenie połączenia może przebiegać według kilku scenariuszy, w najprostszym przypadku mamiejsce wymiana czterech segmentów:

Klient

stan ESTABLISHED

wysłany segment FIN+ACK

pośredni stan FIN_WAIT1


pośredni stan FIN_WAIT2

odebrany segment FIN+ACK

pośredni stan TIME_WAIT


pośredni stan TIME_WAIT

stan CLOSED

Serwer

stan ESTABLISHED

odebrany segment FIN+ACK

pośredni stan CLOSE_WAIT


wysłany segment FIN+ACK

pośredni stan LAST_ACK


stan CLOSED

12

1.3. Protokół UDP

UDP[8] (User Datagram Protocol) również jest protokołem działającym w trzeciej warstwie modeluTCP/IP. W odróżnieniu jednak od TCP do transmisji danych między stacjami nie wymaga połączeń,jest również opisywany jako protokół bezpołączeniowy. Nie ma jednak gwarancji, że wysłanypakiet UDP zostanie doręczony, gdyż nie posiada on mechanizmów potwierdzeń odebranychinformacji. Analogią dla tego protokołu może być system pocztowy, w którym nadawca wrzuca listdo skrzynki, lecz nie ma pewności czy nie zostanie on zagubiony.

Rysunek 1.6 Format ramki protokołu UDP[8]

Opis pól nagłówka UDP:

– source port 16 bitowe pole zawierające numer portu źródłowego.

– destination port 16 bitowe pole zawierające numer portu docelowego, analogicznie doprotokołu TCP numery portów określają, która aplikacja w warstwie zastosowań (aplikacji) jestodpowiedizalna za przetwarzanie danych datagramu.

– length 16 bitowe pole przechowujące długość nagłówka i danych datagramu UDP.

– checksum 16 bitowe pole sumy kontrolnej nagłówka i danych datagramu UDP

Najbardziej popularną usługą Internetu, korzystającą z protokołu UDP jest DNS[9] (Domain NameSystem). System ten umożliwia zamianę trudnych do zapamiętania adresów IP na wygodnew użyciu nazwy domenowe, składające się z kilku członów. Baza nazw jest rozproszonai zarządzana przez wiele organizacji, z których każda odpowiedzialna jest za określone poddomenydomen wyższego poziomu. Zapytania o nazwy, kierowane do tak zwanych serwerów nazw, sąniewielkie, dość częste i wystepują w różnych odstępach czasowych. W związku z tymnajwygodniejsze jest wykorzystanie protokołu bezpołączeniowego jakim jest UDP.

Podczas transmisji dźwięku w sieci IP nie mają większego znaczenia pojedyncze stratydatagramów, a użycie połączeniowego protokołu TCP, wymagającego potwierdzeń i retransmisjimogło by powodować przestoje i przerwy. Dlatego UDP jest doskonały do tego typu zastosowań.

Wszędzie tam, gdzie pakiety są stosunkowo małe, mogą pojawiać się asynchronicznie, a stratydatagramów nie są czynnikiem krytycznym, wykorzystywany jest protokół UDP.

13

1.4. Protokół ICMP

Protokół ICMP[10] (Internet Control Message Protocol) spełnia bardzo ważną funkcję nie zewzgędu na transmisję danych użytkownika, lecz właściwe współdziałanie innych protokołów. Jaknazwa wskazuje, protokół ten umożliwia przesyłanie komunikatów kontrolnych miedzy stacjamisieci IP.

Rysunek 1.7 Format ramki protokołu ICMP[10]

Opis pól ramki ICMP:

– type 8 bitowe pole określające typ komunikatu ICMP, przykładowe typy to: 0 echoresponse, 3 destination unreachable, 5 echo request.

– code 8 bitowe pole określające podgrupę typu komunikatu.

– checksum 16 bitowe pole sumy kontrolnej całego komunikatu ICMP wrazz nagłówkiem.

– unused 32 bitowe nieużywane pole, zwykle równe 0.

Istnieje bardzo wiele typów komunikatów ICMP, które umożliwiają przesłanie bardzo precyzyjnejinformacji o zaistniałej sytuacji w sieci IP.

Jednym z najczęściej wykorzystywanych typów pakietów ICMP jest para echo_request/echo_reply.Dzięki tym komunikatom istnieje możliwość sprawdzenia podstawowej łączności między hostamiw sieci. Sprawdzenie to polega na wysłaniu przez stację źródłową tzw. pakietu żądania echa (echorequest), na które to żądanie poprawnie skonfigurowany host w sieci IP jest zobowiązanyodpowiedzieć stacji źródłowej pakietem odpowiedzi (echo reply). Przy wykorzystaniu określonegoszeregu pakietów echa można ustalić zarówno średni czas transmisji pakietu pomiędzy dwomastacjami w sieci, jak również jakość połączenia mierzoną w procentowej ilości utraconychpakietów (takich, dla których nie dotarła odpowiedź z hosta docelowego).

Kolejny często używany typ komunikatu destination unreachable odpowiedzialny jest zainformowanie o niedostępności hosta. Komunikat ten jest wysłany do stacji źródłowej przez ostatnina drodze pakietu ruter, który nie może skomunikować się z hostem docelowym.

Dzięki połączeniu wyżej wymienionych typów komunikatów jest możliwe działanie między innymiprogramów śledzenia trasy pakietu IP w sieci, tak zwanych programów typu traceroute. Cykliczniewysyłane pakiety żądania echa z odpowiednio zwiększaną wartością pola TTL umożliwiająuzyskanie odpowiedzi z kolejnych ruterów na trasie pakietu IP, a w przypadku odebraniakomunikatu o niedostepności hosta przeznaczenia ustalenie miejsca przerwania trasy.

14

2. Istniejące rozwiązania monitorowania ruchu i ich porównanie

System operacyjny Linux został zaprojektowany jako wielodostępny i wielozadaniowy, alerównież, co okazało bardzo waże dla jego błyskawicznego rozwoju, jako system sieciowy. Wobecczego zasób oprogramowania sieciowego zarówno w samym jądrze systemu jak i w przestrzeniprogramów użytkowych jest bardzo duży.

W zakresie oprogramowania monitorującego ruch sieciowy można wyróżnić conajmniej kilkaaplikacji. Wspólną cechą tych programów jest sposób przechwytywania pakietów z sieci,udostępnionych przez jądro systemu. Różnice natomiast polegają głównie na zakresieobserwowanego bądź interpretowanego przez te programy ruchu oraz sposobie prezentacji danych.

2.1. tcpdump

Najpopularniejszym i najczęściej dołączanym do dystrybucji systemu operacyjnego Linuxprogramem umożliwiającym monitorowanie ruchu sieciowego jest tcpdump[11]. Ze względu nastosunkowo niewielkie wymagania stał się on jednym z podstawowych narzędzi wykorzystywanychprzez administratorów serwerów i ruterów sieciowych na platformie Linux. Program rozpoznajewiele protokołów sieciowych trzech pierwszych warstw modelu DoD takich jaki: decnet, ethernet,ip, lat, tcp, udp icmp i inne. Jest on programem przeznaczonym dla trybu tekstowego, pod tzw.konsolę. Uruchomienie programu i zadanie mu opcji wywołania następuje poprzez wpisaniew wierszu poleceń komendy uruchamiającej program z odpowiednimi przełącznikami:

root@r2:~# tcpdump -i eth0 -n -c 10

powyższa komenda spowoduje uruchomienie programu nasłuchującego na interfejsie sieciowym'eth0', przechwycenie dziesięciu pakietów i wyłączenie zapytań revDNS wykonywanych po to byuzyskać nazwy domenowe dla przechwyconych adresów IP.

Poza pewnym ograniczonym zestawem opcji, tcpdump posiada wbudowany interpreter pewnegopseudo języka umożliwiającego specyfikowanie dość rozbudowanych filtrów ruchu sieciowego.Filtrowanie ma duże znaczenie w przypadku szybkich sieci, w których ruch jest tak duży, żeprzechwytywanie go w całości byłoby niemożliwe ze względu na ograniczoną moc procesora jakrównież pojemność dysku:

root@ck-gw:~# tcpdump -i eth1 -n -e tcp and host 10.0.0.2 port 135

w ten sposób przechwycony ruch będzie zawierał pakiety należące do protokołu TCP, kierowane doi z adresu 10.0.0.2, wysłane z portu zródłowego lub do portu przeznaczenia o numerze 135. Dośćistotnym w tym przypadku jest przełącznik nakazujący tcpdump wyświetlanie również adresówprotokołół warstwy dostępu do sieci, np. ethernet.

Twórcy programu tcpdump poszli o krok dalej i umożliwili użytkownikowi porównywaniedowolnego bajtu w zidentyfikowanym nagłówku protokołu. Dzięki tej opcji użytkownik ma niemalnieograniczone możliwości dopasowania właściwego pakietu.

root@ck-gw:~# tcpdump -i eth0 -n 'ip[9] == 17'

15

powyższe polecenie wyświetki każdy pakiet IP, w którego dziewiątym bajcie nagłówka znajdzie sięwartość 17. W rzeczywistości dziewiąty bajt nagłówka IP określa rodzaj danych pakietu, w tymkonkretnym przypadku numer protokołu wyższej warstwy. Zostaną więc wyświetlone tylko pakietyprotokołu UDP.

Tcpdump cechuje sposób wyświetlania przechwyconych i zinterpretowanych danych. Informacjeo każdym pakiecie, który przeszedł przez filtry użytkownika są wyświetlane w postacji jednegowiersza. Format tego wiersza jest zależny od rodzaju protokołu. Wspólnym elementem jest zawszedokładny czas przechwycenia pakietu, następnie wyświetlane są adresy warstwy internetu,względnie warstwy dostępu do sieci, dane specyficzne dla konkretnego rodzaju protokołu takie jaknumery portów, flagi wielkość pakietu i wiele innych. Wyjście programu tcpdump jest dośćrozbudowane, czasem do tego stopnia, że posiada część poprawnie zinterpretowanych informacjiwarstwy aplikacji takich jak np. rodzaj zapytania DNS.

Przykładowy output programu tcpdump:

11:28:51.868719 213.227.72.4.40500 > 213.227.72.1.53: 34271+ AAAA? ludwik.digi.pl. (32) (DF)

11:28:51.912055 213.227.72.1.53 > 213.227.72.4.40500: 34271* 0/1/0 (91) (DF)

11:28:51.912790 213.227.72.4.40500 > 213.227.72.1.53: 34272+ AAAA? ludwik.gl.digi.pl. (35) (DF)

11:28:51.913231 213.227.72.1.53 > 213.227.72.4.40500: 34272 NXDomain* 0/1/0 (94) (DF)

11:28:51.922271 213.227.72.4.40500 > 213.227.72.1.53: 43416+ A? ludwik.digi.pl. (32) (DF)

11:28:51.923261 213.227.72.1.53 > 213.227.72.4.40500: 43416* 1/3/3 A 80.48.8.1 (171) (DF)

prezentuje zapytanie DNS wykonane z hosta 213.227.72.4 do serwera nazw o adresie 213.227.72.1na standardowym, 53 porcie serwerów nazw. Zapytanie onazwę domenową 'ludwik.gl.digi.pl'kończy się odpowiedzią serwera informującą klienta o braku nazwy w podanej strefie (NXDomainNon Existent Domain). Drugie zapytanie kończy się sukcesem i klientowi odesłany zostaje rekordA zawierający adres 80.48.8.1. Na kolejnym fragmencie wyjścia tcpdumpmożna zaobserwowaćnawiązanie połączenia do usługi zdalnej administracji serwerem na porcie 22/tcp.

11:28:51.924061 213.227.72.4.47598 > 80.48.8.1.22: S 360246405:360246405(0) win 5840 <mss1460,sackOK,timestamp 881652088 0,nop,wscale 0> (DF)

11:28:51.928924 80.48.8.1.22 > 213.227.72.4.47598: S 2974500731:2974500731(0) ack 360246406 win 5792<mss 1460,sackOK,timestamp 26439682 881652088,nop,wscale 0> (DF)

11:28:51.928985 213.227.72.4.47598 > 80.48.8.1.22: . ack 1 win 5840 <nop,nop,timestamp 88165208926439682> (DF)

11:28:51.935363 80.48.8.1.22 > 213.227.72.4.47598: P 1:26(25) ack 1 win 5792 <nop,nop,timestamp26439683 881652089> (DF)

11:28:51.935933 213.227.72.4.47598 > 80.48.8.1.22: . ack 26 win 5840 <nop,nop,timestamp 88165208926439683> (DF)

Można wyróżnić adresy IP zródła i przeznaczenia pakietu, porty zródłowe i przeznaczenia,kierunek przesyłu pakietu, flagi TCP (S syn, P psh, ack), wielkość okna danych, fragmentację.Czasem jednak tak rozbudowany sposób prezentacji danych może prowadzić do trudnościw interpretacji informacji.

Tcpdump do przechwytywania danych z warstwy kanałowej (dostępu do sieci) używa popularnejw systemie Linux biblioteki libpcap[8]. Poza tą biblioteką wymaga wielu funkcji standardowejbiblioteki libc, która może zostać wkompilowana statycznie w binaria lub ładowana dynamiczniepodczas uruchamiania programu.

16

2.2. iptraf

Bardzo wygodnym w użyciu w środowisku tekstowym (konsoli) jest program iptraf[12]. Programten bazuje na okienkowym interfejsie użytkownika, dzięki czemu zapewnia przejrzystośćprezentacji danych oraz łatwą interakcję użytkownika. Podobnie jak w tcpdump,zaimplementowanych zostało wiele protokołów poszczególnych warstw modelu TCP/IP orazobsługa filtrów ruchu. Iptraf ma jednak przewagę nad tcpdump chociażby dlatego, że potrafianalizować ruch na kilku interfejsach sieciowych jednocześnie, mierzyć prędkość transmisji, śledzićpołączenia TCP na podstawie numerów sekwencyjnych.

Rysunek 2.1 iptraf, prędkość transmisji na interfejsach

W czasie przechwytywania ruchu prowadzone jest zliczanie pakietów zaszeregowanych doposzczególnych grup (IP, NonIP, BadIP), dzięki czemu można określić z pewnym przybliżeniemprędkość transmisji na danym interfejsie.

Poza zestawieniem wszystkich interfejsów stacji sieciowej, iptraf udostępnia też szczegółowestatystyki poszczególnych interfejsów:

Rysunek 2.2 iptraf, szczegółowe statystyki interfejsu

Bardzo istoną cechą iptrafa jest umiejętność śledzenia połączeń TCP wykorzystująca numerysekwencyjne i potwierdzeń tego protokołu. Daje to możliwość prezentacji danych dotyczącychposzczególnych połączeń zmieniających się w czasie rzeczywistym, takich jak: flagi TCP (fazy

17

nawiązania połączeń, transmisji danych z potwierdzeniem, zakończenia połączeń), ilości danychtransmitowanych w danym połączeniu w obu kierunkach, nazwy interfejsu sieciowego stacji przezktóry odbywa się transmisja. W ten sposób poszczególne pakiety są grupowane, co czyni wyjścieprogramu wygodnym w odczycie i zrozumieniu.

W oddzielnym oknie natomist są wyświetlane w tradycyjny sposób pakiety protokołówbezpołączeniowych takich jak np.: UDP, ICMP, ARP.

Rysunek 2.3 iptraf, śledzenie połączeń TCP

Na rysunku zaobserwować można siedem aktywnych sesji TCP: połączenie protokołu GG (portprzeznaczenia 8074), dwie sesje szyfrowanego zdalnego dostępu do powłoki (SSH, port 22) i trzysesje szyfrowanego protokołu HTTP (port 443).

Iptraf daje możliwość definicji rozbudowanych filtrów pakietów różnych warstw, a także dość dużąilość opcji konfiguracji zarówno funkcji sieciowych jak i samego interfejsu użytkownika.

W odróżnieniu od tcpdump, do kompilacji nie jest wymagana biblioteka przechwytywania pakietów(libpcap), ponieważ iptraf implementuje własne funkcje w tym zakresie. Tym niemniej do realizacjiinterfejsu użytkownika niezbędna jest biblioteka ncurses i oczywiście funkcje bibliotekistandardowej libc.

18

2.3. ethereal

Najbardziej rozbudowanym z trzech porównywanych programów jest ethereal[13]. Program tenpodobnie jak tcpdump korzysta z biblioteki libpcap do przechwytywania pakietów oraz umożliwiadefiniowanie zaawansowanych filtrów ruchu. Ethereal potrafi zidentyfikować bardzo wieleprotokołów poszczególnych warstw, a dodatkowo interpretuje dane przeznaczone dlaoprogramowania warstwy zastosowań, dzięki czemu można śledzić np. sesje SMTP, HTTP i wieleinnych.

Jedna z różnic w działaniu Ethereal polega na tym, że funkcje przechwytywania oraz interpretacji sąrozdzielone. Użytkownik określa kryteria przechwytywania i filtrowania pakietów, następnieprowadzony jest nasłuch na wybranym interfejsie aż do momentu przerwania przez użytkownika,ostatnim krokiem jest interpretacja i identyfikacja poszczególnych protokołów. Tak przygotowanedane są nastepnie prezentowane w bardzo wygodny dla użytkownika sposób, umożliwiającyinteraktywne przeglądanie niemal każdej części przechwyconych danych.

Poza najbardziej rozbudowanymi funkcjami interpretacji przechwyconego ruchu Ethereal posiadakluczową przewagę nad pozostałymi programami tego typu, jest nią graficzny interfejsużytkownika.

Rysunek 2.4 Ethereal, kryteria przechwytywania

Istnieje możliwość określenia interfejsu sieciowego, ilości bajtów kopiowanych z sieci, czasuprzechwytywania, ilości pakietów, definicji filtrów.

19

Rysunek 2.5 Ethereal, przechwytywanie

W czasie przechwytywania prowadzone jest zliczanie pakietów poszczególnych protokołów. Jakwidać na powyższym rysunku, Ethereal rozróżnia wiele protokołów różnych warstw już w fazieprzechwytywania. Można zaobserwować protokoły warstwy transportowej takie jak TCP oraz UDPi ich procentowy udział w całości ruchu sieciowego, protokół rozwiązywania adresów sieciowychARP, protokół dynamicznego rutingu OSPF oraz wiele innych. Już z tej prostej statystykiuaktualnianej na bieżąco w trakcie przechwytywania, można określić, że sniffer działa w sieciopartej głównie na protokole IP, w której dominującą rolę pełni protokół transportowy TCP.

Prezentacja danych w kilku oknach jednocześnie (Rysunek 2.6), z możliwością interaktywnegoprzeglądania poszczególnych pakietów zapewnia szybki i wygodny dostęp do wybranychinformacji. Pierwsze okno zawiera listę wszystkich przechwyconych pakietów z podstawowymiinformacjami dotyczącymi każdego z nich, takimi jak: czas przechwycenia, adres źródłowy, adresprzeznaczenia, rodzaj protokołu, istotne informacje nagłówka, rozpoznany typ transmisji lubkonkretne zapytanie. Drugie okno zawiera wartości wszystkich pól nagłówków poszczególnychwarstw przedstawione w postaci rozwijanego drzewa. W trzecim oknie cały pakiet łącznie z danymiużytkownika zapisany jest w postaci szeregu liczb szesnastkowych. Właściwość ta może być bardzoprzydatna w diagnozowaniu błędów lub nieprawidłowości protokołów wartwy aplikacji, zwłaszczatych, które przesyłają dane w postaci nieszyfrowanego tekstu ASCII, takich jak POP3, SMTP, FTPi wielu innych.

20

Rysunek 2.6 Ethereal, prezentacja danych

Zwykle wielkość danych użytkownika jest tak duża, że oprogramowanie sieciowe nie jest w staniezmieścić ich w jednym segmencie i jest zmuszone podzielić ja na części, które transmitowane sąniezależnie. Wówczas prezentacja danych pakietu, jak w przypadku powyżej, nie jest w pełnikomfortowa dla śledzącego je użytkownika. Jedna z wielu przydatnych funkcji Ethereal dajemożliwość rekonstrukcji strumienia danych z przechwyconych segmentów uszeregowanych wewłaściwej kolejności. Aby tego dokonać wykorzystywane są pola nagłówka protokołu TCP: SEQ(numer sekwencyjny) oraz ACK (numer potwierdzenia), które określają kolejność w ciągusegmentów. W ten sposób można łatwo i zupełnie niezależnie śledzić dane sesji protokołówwyższych warstw przesyłane w dwukierunkowym strumieniu TCP. Istnieje możliwość prezentacjiw kilku różnych postaciach i notacjach (ASCII, Hex dump i inne) oraz zapisania sesji do pliku orazpóźniejszego wykorzytania danych.

Rysunek 2.7 przedstawia przechwyconą sesję protokołu HTTP (popularne połączenie WWW),a dokładnie żądanie przesłane do serwera www.yahoo.com oraz jego odpowiedź. W danychużytkownika można wyróżnić pełny nagłówek zapytania (spyfikacja wirtualnego hosta WWW,identyfikacja przeglądarki WWW, określenie akceptowanych typów rozszerzeń, akceptowanejęzyki, kodowanie, zestaw znaków i inne) oraz odpowiedź serwera, która zawiera nagłówekodpowiedzi (kod odpowiedzi, czas lokalny serwera, typ dukumentu, rodzaj kodowania i inne) i daneaplikacji, w tym przypadku dokument html poddany kompresji gzip.

21

Rysunek 2.7 Ethereal, prezentacja danych warstwy zastosowań

Ethereal niewątpliwie posiada ogromne możliwości, pociąga to jednak za sobą dość dużewymagania. Poza biblioteką przechwytywania pakietów wymagane jest środowisko GTK+[14] orazX serwer[15] umożliwiający pracę w trybie graficznym. Wymagania te wykluczają użycie tegooprogramowania na ruterach ze względu na ograniczoną ilość bibliotek użytkowych. Uruchamianieśrodowisk graficznych wiąże się również z koniecznością rezerwacji dużych zasobów pamięcioperacyjnej i mocy procesora, które w przypadku ruterów winny być przeznaczone na zupełnie innezadania wynikające z celu zastosowania.

Wszystkie trzy porównywane programy (tcpdump, iptraf i ethereal) poza wymienionymi wcześniejpodobieństwami i różnicami, mają dadatkową istotną cechę wspólną, a mianowicie przenośność.Zastosowane w nich języki programowania oraz biblioteki użytkowe mają swoje odpowiedniki lubzamienniki w innych niż Linuks systemach operacyjnych oraz platformach sprzętowych. Ponadto,sam kod źródłowy programów jest skonstruowany w taki sposób, aby można było poprawnieskompilować i zbudować je w różnych systemach operayjnych.

Ta szczególna cecha różni zasadniczo omawiane programy od zaprojektowanego przez autora pracyanalizatora, gdyż on w założeniu wymaga platformy sprzętowej Intel x86 oraz powszechniestosowanego jądra systemu operacyjnego Linuks w wersji 2.

22

3. Założenia dotyczące budowy analizatora.

Istniejące oprogramowanie umożliwiające przechwytywanie i analizę ruchu cechuje się dużąilością opcji, rozbudowanymi funkcjami jak również zaawansowanym interfejsem użytkownika.Wszystkie te cechy powodują zwiększenie wymagań sprzętowych systemów, w których sąuruchamiane. Efektem może być niemożność zastosowania oprogramowania na stacjach, które niespełniają tych wymagań.

Jednym z podstawowych założeń przy projektowaniu analizatora, poza prostotą i łatwością użycia,było zminimalizowanie wymagań dotyczących zarówno sprzętu jak i dodatkowegooprogramowania. W celu realizacji tego założenia analizator podzielony został na dwie części.Pierwszą z nich jest program przechwytujący (tzw. Sniffer) i analizujący zaobserwowany ruchsieciowy pod kątem protokołów rodziny TCP/IP. Jest on kluczowym elementem oprogramowaniai może również działać zupełnie niezależnie, jako odrębne narzędzie. Drugą częścią analizatora(Grapher) są skrypty umożliwiające tworzenie wykresów i statystyk z danych częściowozinterpretowanych, udostępnionych w pliku wyjściowym sniffera. Grapher, mimo że wymagadanych od sniffera, nie musi działać na tej samej stacji. Takie rozwiązanie pozwala na rozłożeniezadań pomiędzy dwa hosty: ruter, na którym prowadzone jest przechwytywanie oraz serwer, któryumożliwia wizualizację zaobserwowanego ruchu.

Rysunek 3.1 Przechwytywanie i prezentacja w stacji rutera

Sniffer działa na stacji sieciowej, której głównym zadaniem jest przekazywanie lub obsługa ruchusieciowego, wobec czego powinien w jak najmiejszym stopniu absorbować jej zasoby. Ma toszczególne znaczenie w przypadku narzuconych ograniczeń sprzętowych lub programowych.W ruterach opartych o jednodyskietkowe dystrybucje systemu operacyjnego oraz stacjebezdyskowe, kluczowym elementem jest ilość miejsca wymaganego na nośniku danych. Często

23

niemożliwe okazuje się umieszczenie na jednej dyskietce zarówno systemu i bibliotek jaki dodatkowych narzędzi administracyjnych. Sniffer poza tym, że nie wymaga żadnych dodatkowychbibliotek, jest programem niemal mikroskopijnych rozmiarów, dzięki czemu można łatwozainstalować i użyć go w nawet najbardziej ubogich konfiguracjach sprzętowych.

Z założenia sniffer powinien wymagać jak najmniej pamięci operacyjnej i zajmować stosunkowoniewiele czasu procesora. Jest to zadanie dość trudne, zwłaszcza, że sniffer może zostać użyty nastacji, która przesyła dane w szybkich sieciach. Wówczas ilość pakietów jakie w czasierzeczywistym musi przetworzyć taki analizator jest bardzo duża. Do budowy sniffera wykorzystanojęzyk symboliczny procesora, który zapewnia dużą szybkość działania. Implementacja własnych,uproszczonych procedur obsługi poszczególnych zdarzeń eliminuje konieczność czasochłonnychodwołań do funkcji bibliotecznych systemu.

Problem przechowywania danych przechwyconych przez sniffer został rozwiązany za pomocąmechanizmu zdalnego logowania. Zwykle wielkość wyjściowego pliku danych jest dość znaczna,zwłaszcza gdy monitorowane są szybkie sieci lub czas przechwytywania jest długi. Dziękizaimplementownej w programie sniffera funkcjonalności dane te nie muszą być składowanew stacji prowadzącej monitorowanie, lecz na zdalnym serwerze syslog. Na serwerze tym możerównież działać grapher, który na bieżąco analizuje plik logów i konstruuje aktualne statystyki.

Miejscem uruchamiania programu graphera jest w założeniu stacja serwera. Serwer w związkuz rolą jaką pełni, jest wyposażony w odpowiednie zasoby sprzętowe, takie jak duża ilość pamięcioperacyjnej, wielka moc obliczeniowa jednego lub wielu procesorów, bardzo duża przestrzeńdyskowa. Poza odpowiednim sprzętem, w systemie serwera zainstalowane jest specjalistyczne,rozbudowane oprogramowanie umożliwiające udostępnianie zasobów.

Rysunek 3.2 Przechwytywanie w stacji rutera, prezentacja w zdalnej stacji serwera

24

4. Wybór narzędzi i języków programowania.

Zadania przechwytywania i analizy ruchu sieciowego są rozdzielone i mogą być prowadzonew dwóch odrębnych środowiskach. Dlatego też, ze względu na specyficzne wymagania każdegoz nich, do zbudowania poszczególnych częsci oprogramowania wykorzystane zostały różnenarzędzia i języki programowania.

4.1. sniffer – asembler

Dobrym sposobem realizacji wymagań stawianych oprogramowaniu sniffera jest wykorzystaniejęzyka, który zapewnia dużą szybkość działania aplikacji, nie wymaga dodatkowych bibliotek,a uzyskany kod wynikowy programu jest jak najmniejszy. Narzędziem takim może być języksymboliczny procesora czyli tak zwany asembler.

W systemie Linux istnieje możliwość używania kilku różnych narzędzi tego typu. Jednaknajpopularniejszym z nich, dostępnym niemal w każdej dystrybucji oraz używanym w kodzieźródłowym samego jądra systemu jest gasm, który jest jedną z głównych części pakietu GNUBinutils[16].

Charakterystyka gasm :

Za pomocą poleceń języka symbolicznego można wykonywać szybkie operacje na danychzawartych w rejestrach procesora. W przypadku gasm nazwa argumentu oznaczająca konkretnyrejestr musi być zawsze poprzedzona znakiem procenta '%'. Na platformie sprzętowej Intel 80386dostępne dla programisty są nastepujące rejestry:

• osiem 32 bitowych rejestrów:

%eax (akumulator), %ebx, %ecx, %edx, %edi, %esi, %ebp, %esp (wskaźnik stosu).

• osiem 16 bitowych części rejestrów 32-bitowych nazwanych odpowiednio:

%ax, %bx, %cx, %dx, %di, %si, %bp, %sp.

• osiem 8 bitowych rejestrów odpowiadających odpowiednio starszym i młodszym ośmiu bitomrejestrów 16 bitowych (%ax, %bx, %cx, %dx):

%ah, %al, %bh, %bl, %ch, %cl, %dh, %dl.

Poza rejestrami, argumentami rozkazów mogą być dane znajdujące się w pamięci. System Linuxdziała w trybie chronionym procesorów Intel i zapewnia własne mechanizmy dostępu i zarządzaniazarówno pamięcią operacyjną jak i wirtualną. Dzięki temu, stosując język asemblera można uzyskaćłatwy dostęp do dużych bloków pamięci za pomocą prostej, liniowej adresacji. Jest to znaczneułatwienie, gdyż nie istnieje konieczność specyfikowania segmentów i skomplikowanych obliczeńadresu efektywnego, która miała miejsce w przypadku systemów DOS pracujących w trybierzeczywistym.

25

Domyślnie używaną przez kompilator gasm składnią jest składnia AT&T. Niesie to za sobą pewneróżnice w porównaniu ze składnią Intela:

• zmienna natychmiastowa musi być poprzedzona znakiem dolara '$'.

• w przypadku instrukcji dwuargumentowych odwrotna jest kolejność źródło/przeznaczene,np. polecenie movl $15, %ecx załaduje wartość 15 do 32 bitowego rejestru %ecx.

• gdy wykonywane są odwołania do pamięci, rozmiar danej jest specyfikowany za pomocą sufiksurozkazu. Sufiksy 'b', 'w' i 'l' oznaczają odpowiednio: bajt (8 bitów), word (słowo 16 bitowe)i long (32 bity). Przykładowe polecenie powoduje załadowanie szesnastobitowego słowaz pamięci, wskazywanego przez adres etykiety adr do rejestru %ax : movw adr, %ax.

Odwołanie do adresu w pamięci można wykonać przez użycie etykiety bądź podanie adresuw rejestrze. W tym drugim przypadku niezbędne jest ujęcie nazwy rejestru w nawias, np.:

addb (%ecx), %eax, dodanie do rejestru %eax wartości bajtu komórki pamięci, której adresjest w rejestrze %ecx.

Przykładowe tryby adresowania używane również przy budowie sniffera:

domyślny argument rozkazu jest niejawny, zwykle rozkaz operuje na konkretnychrejestrach, najczęściej jest to akumulator:

cwde konwersja słowa w rejestrze %ax dopodwójnego słowa w %eax

natychmiastowy dana jest zawarta bezpośrednio w rozkazie procesora:

movb $130, %bl załadowanie stałej 130 do rejestru %bl

bezpośredni adres danej jest zawarty bezpośrednio w rozkazie:

movl %eax, rules_file załadowanie 32 bitowej danej z rejestru%eax do pamięci pod adres rules_file

bazowy adres znajduje się w rejestrze:

movb (%ebx), %al załadowanie do rejestru %al danej (bajtu)spod adresu wskazywanego przez rejestr%ebx

bazowyindeksowany

adres i przemieszczenie znajdują się w rejestrach:

movb %ah, (%ebx, %ecx) załadowanie bajtu z rejestru %ah do komórkipamięci o adresie w rejestrze %ebxi przemieszczeniu w %ecx

26

Bardzo często wykorzystywanym elementem przy konstrukcji programu są instrukcje lub grupyinstrukcji umożliwiających iteracyjne powtarzanie wybranej części kodu. W języku asmeblerafunkcję tę pełnią w połączeniu z etykietami, instrukcje przekazujące sterowanie do innej częscikodu, czyli tak zwane skoki. Rozróżnić można dwa podstawowe rodzaje skoków: warunkowei bezwarunkowe. W przypadku tych pierwszych sytuacja jest prosta i całe zadanie instrukcjisprowadza się do przekazania sterowania. Natomiast przy skokach warunkowych wcześniej, przedwykonaniem skoku, sprawdzany jest wynik ostatniego porównania.

cmpl $0, %ecx

jg etykieta

W powyższym przykładzie skok do etykiety etykieta wykonany zostanie jeśli wartość w 32 bitowymrejestrze %ecx będzie większa od zera. W przeciwnym przypadku wykonana zostanie instrukcjanastępująca po rozkazie skoku.

Przykłady użycia skoków i etykiet do budowy instrukcji iteracyjnych:

petla1:

...

incl %eax

cmpl $100, %eax

jl petla1

Pętla do { } while() języka C.

start_petla2:

cmpl $80, %eax

jge koniec_petla2

...

jmp start_petla2

koniec_petla2:

Pętla while() {} lub for (;;) {} języka C.

Mechanizmy skoków w powiązaniu z etykietami pozwalają na konstrukcję dowolnej, nawet bardzozłożonej iteracji. Często takie rozwiązanie ma przewagę nad instrukcjami iteracyjnymi językówwyższego poziomu, ze względu na możliwość szybkiego przekazania sterowania w dowolnemiejsce pętli. Głównym jednak mankamentem zbyt częstego stosowania instrukcji skoku jestskomplikowanie kodu programu, a w konsekwencji trudność w późniejszym jego zrozumieniui poprawieniu, bądź rozszerzeniu o dodatkowe funkcjonalności.

Jednym z podstawowych elementów składni języka, umożliwiającym pogrupowanie fragmentówkodu pod kątem wykonywanych zadań i późniejsze wywoływanie tych sekwencji instrukcji, sąprocedury. Spełniają one oczywiście analogiczną rolę jak w innych symbolicznych językachprogramowania, lecz w przypadku asemblera gasm dużą zaletą jest bardzo prosta składniadefinicji procedur.

27

Wystarczy posłużyć się zwykłą etykietą, oznaczającą początek procedury oraz instrukcją ret, którazwraca sterowanie do miejsca, z którego zastała wywołana procedura. Dodatkowo warto przedrozpoczęciem właściwego kodu procedury umieścić instrukcję zapisującą bieżącą zawartośćrejestrów na stosie, by później na końcu procedury móc je odtworzyć:

procedura1:

pushal

...

...

popal

ret

Wywołanie tak zdefiniowanej procedury wykonuje się za pomocą polecenia call:

incl %eax

call procedura1

movl %eax, %ecx

...

Po zakończeniu wykonywania kodu procedury sterowanie zostanie przekazane do kolejnejinstrukcji, przy czym rejestr %eax nie został naruszony i może być wykorzystywany w dalszejczęści programu.

Przekazywanie parametrów i odbieranie zwracanych przez procedury wartości można zrealizowaćwykorzystując wybrane rejestry lub stosując zmienne w pamięci.

Poza dużym zasobem instrukcji operujących na rejestrach i pamięci, gasm daje programiściemożliwość skorzystania z zasobów i funkcji jądra systemu operacyjnego. Poszczególne zadaniasystemowe, takie jak: opercje na plikach, zarządzanie procesami, dostęp do zegara systemowego,funkcje realizujące elementarne operacje sieciowe oraz wiele innych, są wykonywane przez takzwane wywołania systemowe. Analogiczne zadania w oprogramowaniu DOS pełnią przerwaniai procedury obsługi przerwań.

W asmeblerze gasm dostęp do wywołań systemowych zapewnia instrukcja int $0x80. Numerwywołania systemowego ustala się za pomocą rejestru %eax, a argumenty przekazywane są zwykleprzez pozostałe rejestry. W przypadku większej ilości argumentów w określonym rejestrzeumieszcza się adres tablicy z opcjami.

movl $6, %eax

movl $2, %ebx

int $0x80

28

Wywołanie systemowe zamykające plik standardowego wyjścia błędów, w rejestrze %eax numerwywołania (6 sys_close), w %ebx numer deskryptora pliku.

Przykładowe numery wywołań systemowych:

– sys_exit (1) zakończenie procesu,

– sys_fork (2) funkcja powołująca kopię działającego procesu,

– sys_read (3) czytanie z deskryptora pliku

– sys_write (4) zapis do deskryptora pliku

– sys_open (5) otwarcie pliku

– sys_close (6) zamknięcie pliku

– sys_chdir (12) zmiana katalogu

– sys_getpid (20) pobranie numeru procesu (Process ID)

– sys_getuid (24) pobranie numeru użytkownika (User ID)

– sys_signal ( 48) obsługa sygnałów

– sys_ioctl (54) operacje na deskryptorach

– sys_socketcall (102) wywołanie funkcji sieciowych

Typowy program w asemblerze powinien zawierać dwie sekcje: danych i kodu programu.Niezbędne jest określenie na początku kodu programu globalnej etykiety _start, która przekazujeprogramowi linkującemu (tak zwanemu linkerowi) informację o tym, w którym miejscu rozpoczynasię właściwy kod. Poza tym należy poprawnie zakończyć proces za pomocą odpowiedniegowywołania systemowego.

.data

# sekcja danych: tablice, struktury, sta e...ł

.text

# sekcja kodu programu

.global _start

_start:

# wlasciwy program

...

...

# zakonczenie procesu

movl $1, %eax

int $0x80

29

4.2. grapher, Perl, PHP

Zadaniem graphera jest zbudowanie strony WWW prezentującej zaobserwowany ruch w postaciwykresów. W tym celu należy najpierw przeanalizować plik wyjściowy sniffera pod kątemwystępujących protokołów, wielkości pakietów, wartości pól TTL, numerów portów i innychdanych. Następnie posortowane i przetworzone dane posłużą do utworzenia szablonu html[17]z obrazkami png[18].

Pierwsza część zadania oparta jest głównie na sekwencyjnym odczycie pliku oraz poszukiwaniuwzorców danych i ich sortowaniu lub szeregowaniu. Doskonałym narzędziem do tego typu operacjijest Perl[19] (Practical Extraction and Reporting Language). Jedną z głównych zalet tegoelastycznego języka wyższego poziomu jest szybkość programowania. Można pominąć długii pracochłonny proces tworzenia skomplikowanych struktur danych i określania ich typów,a posłużyć się specyficznymi mechanizmami dostarczanymi przez Perl.

Bardzo ciekawą, a jednocześnie wygodną w użyciu i bardzo przydatną właściwością Perla są takzwane tablice asocjacyjne. Te struktury danych różnią się od tablic tradycyjnych tym, że indeksynie są kolejno numerowane, a do czynienia mamy niejako z nieuporządkowanym zbioremskojarzonych par danych w postaci klucz-wartość.

%protocols = ( 'ICMP' => 1390,

'TCP' => 5720,

'UDP' => 582,

'Non IP' => 5 );

Przykładowa tablica asocjacyjna przyporządkowuje ilość wystąpień pakietów danego protokołu dojego nazwy.

Dostępne są też specjalne funkcje i polecenia iteracyjne ułatwiające szybki i wygodny dostęp dotakich tablic, m.in. sort, keys, foreach.

foreach $proto_name (sort { $a <=> $b } keys %protocols) {

print $proto_name, " = ", $protocols{$proto_name}, "\n";

}

Przykładowa instrukcja iteracyjna wyświetli klucze i przyporządkowane im wartości liczbowe,posortowane według kluczy w porządku malejącym. W miejsce nawiasów klamrowychw wywołaniu funkcji sort można wstawić dowolną procedurę sortującą.

Po analizie pliku wyjściowego sniffera i utworzeniu odpowiednio poszeregowanych tablicposzczególnych pól nagłówków, grapher buduje strukturę stron WWW. Jednym z najprostszychsposobów dynamicznej konstrukcji stron i obrazów jest użycie języka PHP[20]. Jest to popularnyjęzyk skryptowy umożliwiający wykonywanie kodu po stronie serwera WWW (np. Apache),wyposażony w bardzo bogatą kolekcję bibliotek.

30

Poza standardowymi funkcjami, skrypty PHP utworzone przez graphera do szybkiej budowyobrazów PNG (Portable Network Graphics) wykorzystują funkcje biblioteki GD[21], takie jak np.:

$image = ImageCreate($x, $y)

utworzenie obrazu o określonym rozmiarze, zwraca referencję do obrazu używaną późniejw pozostałych funkcjach operujących na tym obrazie.

$color = ImageColorAllocate($image, $R, $G, $B)

ustalenie rodzaju koloru za pomocą złożenia składowych RGB (Red, Green, Blue), zwracareferencję do ustalonego koloru.

ImageColorTransparent($image, $color)

przełączenie indeksu koloru w tryb przeźroczystości

ImageLine($image, $x, $y, $x1, $y1, $color)

narysowanie linii koloru $color pomiędzy punktami, które okreslają współrzędne. Funkcjawykorzystywana np. do wykreślenia osi układu współrzędnych.

ImageFilledRectangle($image, $x, $y, $x1, $y1, $color)

narysowanie prostokąta o podanych współrzednych wypełnionego kolorem $color. Np. budowawykresów słupkowych.

ImageString($image, $font, $x, $y, $text, $color)

wyświetlenie wiersza tekstu $text czcionką o numerze $font i kolorze $color

ImageStringUp($image, $font, $x, $y, $text, $color)

wyświetlenie teksu analogicznie do wcześniejszej funkcji, z tą różnicą, że tekst jest obrócony o 900

ImagePNG($image)

wygenerowanie z obszaru roboczego obrazka $image pliku graficznego w formacie PNG

ImageDestroy($image)

zwolnienie pamięci zajmowanej przez struktury danych obrazu $image, zakończenie pracy

Tak utworzony dynamicznie obraz można wyświetlić z wykorzystaniem standardowej przeglądarkiWWW, jak również zapisać w postaci właściwego formatu pliku graficznego. W przypadkugraphera jest to format PNG.

31

5. Specyfikacja wewnętrzna oraz fragmenty procedur

5.1. sniffer

Program sniffera, ze względu na wybór jęzka w jakim został napisany, posiada bardzoskomplikowany kod źródłowy. Język asemblera cechuje się małą przejrzystością, dlatego podczasprojektowania i programowania należy szczególną uwagę zwrócić na odpowiednią konstrukcjękodu źródłowego oraz konkretne schematy tworzenia poszczególnych jego części. Bardzo ważnajest dyscyplina programowania i bieżące komentowanie kodu programu.

Podział na pliki i procedury

Aby uczynić kod programu bardziej czytelnym i łatwiejszym w użyciu przy późniejszympoprawianiu błędów lub dodawaniu nowych funkcjonalności, został on podzielony na kilka plików.W zamierzeniu, podział ten miał grupować fragmenty kodu pod kątem ich zastosowania.W poszczególnych plikach zawarte są procedury i definicje struktur danych wykorzystywanychw tych procedurach.

args.s plik zawiera procedury operujące na argumentach wiersza poleceń.

• print_args procedura wyświetla wszystkie argumenty wiersza poleceń, używana główniedo celów diagnostycznych.

• parse_args parsuje argumenty wiersza poleceń i poszukuje w nich poprawnychprzełączników programu, w przypadku gdy któryś z przełączników jest błędny lub posiadaniewłaściwy argument procedura kończy działanie i zwraca błąd (w rejestrze %eax ustawianajest wartość -1). Podobnie jak w wszystkich procedurach tego pliku, parametry to zmienne argvi argc, z których pierwsza określa adres tablicy argumentów, a druga ilość elementów tej tablicy.

• print_opt to kolejna procedura diagnostyczna. Wyświetla ona opcje, które zostałyustawnione przez procedurę parsującą argumenty.

data.s plik, który zawiera tylko sekcję danych. W pliku tym zawarte są struktury danych(zmienne, stałe), które używane są w większości pozostałych plików programu, takie jaknp.: numery wywołań systemowych, typy gniazd sieciowych, podstawowe numery deskryptorówplików programu, struktura do przechowywania przechwyconego datagramu, zmienneprzechowyjące argumenty i opcje zadane przez użytkownika podczas uruchamiania programu.Umożliwia to uporządkowanie kodu oraz łatwą komunikację pomiędzy fragmentami koduz wykorzystaniem zmiennych globalnych.

packet.s definiuje typy danych i procedury wykonujące operacje na danych przechwyconychz sieci, takie jak: określenie typu pakietu i zebranie danych z nagłówków, przygotowanie nagłówkai danych pakietu do prezentacji.

32

• packet_encapsulate argumentem niejawnym jest zmienna ip_ihl, wskazująca naadres początka nagłówka warstwy internetowej. Procedura ta wykonuje obliczenie wielkościnagłówka IP i danych zawartych w pakiecie, określa rodzaj danych w pakiecie IP (numerprotokołu wyższej warstwy).

• prepare_data procedura przygotowuje dane pakietu do wyświetlenia, sprawdzana jestdługość danych, wykonywane są konwersje do formatu ciągu znaków ASCII. Argumentem tejprocedury jest adres na dane przekazywany w rejestrze %eax. Również w tym rejestrzeprocedura zwraca ilość bajtów danych, które umieściła we wskazanym miejscu pamięci.

• prepare_line procedura przygotowuje wiersz znaków ASCII opisujący pola nagłówkówzinterpretowanych przez program. Podobnie jak w przypadku procedury przygotowującej dane,adres bufora jest przekazywany w rejestrze %eax. Procedura zwraca ilość skopiowanych bajtów.

promisc.s plik te zawiera dwie procedury umożliwiające przełączanie interfejsu w trybbezładny (promiscuous). Domyślna konfiguracja urządzenia warstwy dostępu do sieci (np. kartasieciowa ethernet) w stacji sieciowej nakazuje przekazywanie danych do wyższych wartw jedyniewówczas, gdy ramka przeznaczona jest do niej. Pozostałe pakiety są natychmiast odrzucane. Trybbezładny umożliwia zmianę tego zachowania i przechwytywanie wszystkich ramekzaobserwowanych na sieci.

• promisc_on procedura włącza tryb promiscuous, wykonywane jest to przez ustawienieodpowiednich flag interfejsu sieciowego za pomocą wywołania systemowego sys_ioctl(SIOCGIFFLAGS i SIOCSIFFLAGS, pobranie i ustawienie flag).

• promisc_off wyłączenie trybu bezładnego, procedura zwykle wywoływana przedzakończeniem działania sniffera.

rules.s zbiór procedur odpowiedzialnych za parsowanie reguł wczytywanych z pliku filtrów.

• set_up_rule procedura parsuje poszczególne części regułki. Parametry przekazywane zapomocą rejestrów to: %eax adres łańcucha znaków regułki, %ebx ilość znaków regułki, %ecxokreśla aktualie parsowaną część regułu (część zródłowa lub przeznaczenia). Proceduraw przypadku błędu zwraca w rejestrze %eax wartość -1.

• setup_bytes procedura wykorzystywana przez set_up_rule do ustawieniaposzczególnych bajtów reguły w pamięci przeznaczonej na filtry.

• match_rule procedura próbuje dopasować regułę filtra. Kod tej procedury wykonujeiteracyjne próby dopasowania danych uzyskanych z nagłówków przechwycnego pakietu, doktóregoś z zaaplikowanych przez użytkownika filtrów. W przypadku gdy dopasowanie powiodłosię w rejestrze %eax procedura zwraca wartość 0, w przeciwnym przypadku wartość -1.

33

• slog_match_rule w przypadku gdy użytkownik użyje opcji logowania pakietów przezsieć z wykorzystaniem protokołu syslog, sniffer musi odfiltrować ruch, który on sam w tensposób generuje. Jeśli zaobserwowany pakiet nie należy do transmisji syslog procedura zwraca wrejestrze %eax wartość -1, w przeciwnym przypadku 0.

signals.s plik zawiera procedury odpowiedzialne za przechwytywanie określonych sygnałówi ich właściwą obsługę z punktu widzenia sniffera.

• catch_signals procedura przejmuje sygnały SIGHUP, SIGINT i instaluje proceduręich obsługi (signal_action). Wykonywane jest to za pomocą wywołania systemowegosys_signal.

• signal_action procedura obsługi sygnałów. Gdy użytkownik nie określi ilościpakietów, które sniffer ma przechwycić i zinterpretować, powstaje tak zwana pętla definitywna.Wówczas, aby umożliwić poprawne zakończenie procesu należy wysłać do programu jedenz sygnałów, który spowoduje zatrzymanie dotychczasowych działań sniffera i wykona proceduręobsługi sygnału. Zadania jakie realizuje ta procedura to: zamknięcie deskryptorów plików,wyłączenie trybu bezładnego interfejsu, względnie wyświetlenie komunikatu o zakończeniuprocesu.

basicproc.s plik podstawowych procedur, dla łatwiejszej komunikacji procedury zawarte w tympliku korzystają ze wspólnych strktur zdefiniowanych również w tym pliku. Ilość procedur jest dośćduża, a zadania przez nie spełniane to np. konwersja typów danych, funkcje sieciowe, elementarneoperacje na plikach i inne. Część z nich i ich opis jest przedtawiony poniżej:

• int_to_ascii konwersja dwóch bajtów zawartych w rejestrze %eax do łańcucha znakóww pamięci pod adresem %ebx. Procedura zwraca w rejestrze %eax ilość znaków napisu.

• byte_to_hex alanoligcznie jak w poprzedniej procedurze wykonywana jest konwersja, alenapis prezentuje liczbę w zapisie szesnastkowym (np. 0F, C5)

• interfejs, set_interface_name i compare_if to procedury operujące na nazwieinterfejsu, pozwalają na ustalenie nazwy interfejsu, a następnie porównywanie jej z tą, którąuzyskuje się w danych przechwyconych z warstwy kanałowej.

• socket_inet pierwsza z procedur sieciowych, wykonuje elementarne wywołanie sieciowebudujące tzw. gniazdo sieciowe (strukturę i deskryptor umożliwiającu dostęp do funkcjisieciowych).

• bind procedura sieciowa, która związuje numer gniazda z konkretną strukturąadresową.

• recvfrom umożliwia po zainicjowaniu gniazda na odbiór datagramów z sieci.

34

• sendto procedura umożliwia wysyłanie datagramów do sieci. Wszystkie procedury sieciowewymagają określenia kilku parametrów. Jest to wykonywane za pomocą struktur zmiennych,specyficznych dla konkretnej procedury.

• openr, openw procedury wykonujące elementarne operacje na plikach, takie jak otwarciepliku dyskowego do odczytu lub zapisu. Obie te procedury wymagają określenia w rejestrze%ebx adresu łańcucha znaków opiującego poprawną nazwę plik. W rejestrze %eax zwracany jestdeskryptor pliku lub numer błędu w przypadku jego wystapienia.

• read odczyt bajtu z deskryptora pliku. W rejestrze %eax należy określić numerdeskryptora, pocedura zwraca odczytany bajt w ośmiobitowym rejestrze %al.

• close zamknięcie pliku lub gniazda o deskryptorze określonym w rejestrze %eax.

• check_uid w związku z tym, że program sniffera wykonuje w systemie operacjesieciowe, do których niezbędne są prawa administratora systemu (root, UID równy 0), istniejekonieczność określenia, jaki użytkownik uruchamia program. Procedura ta ustala identyfikatorużytkownika za pomocą wywołania systemowego sys_getuid i w przypadku gdy jest on różnyod zera zwraca wartość -1.

• daemon_init procedura umożliwia przełączenie procesu w tryb demona, to znaczyodłączenie go od terminala sterującego. Wykonywane jest to za pomocą odpowiedniej sekwencjiwywołania systemowego sys_fork.

• time, get_time procedury umożliwiają odczytanie i interpretację czasu systemowego.Są one wykorzystywane do określenia czasu przechwycenia datagramu.

• syslog wykonuje logowanie danych do zdalnej stacji za pmocą protokołu UDP/syslog.

• strtoip konwersja adresy IP przedstawionego w notacji kropkowo dziesiętnej(np. 195.82.190.1) do liczby long (32 bity) w sieciowej kolejności bajtów. Procedurawykorzystywana do zbudowania struktury adresowej dla procedury syslog.

ifs.s plik zawiera główną część programu, w nim dołączone są poszczególne moduły opisywanewcześniej. Głównymi zadaniami wykonywanymi w tej części kodu są: ustawienie zmiennych argci argv określających argumenty wiersza poleceń, odczytanie argumentów i określenie opcjiprogramu, kontrola użytkownika uruchamiającego program, względnie odczyt reguł i definicja filtrapakietów, w przypadku zdalnego logowania aplikacja dodatkowych reguł sysloga, ustalenie plikówwyjściowych logowania pakietów, włączenie trybu bezładnego, względnie włącznie trybu demona,instalacja procedur obsługi sygnałów, inicjacja dostępu do sieci i określenie kryteriówprzechwytywania, iteracyjne przechwytywanie kolejnych pakietów, ich interpretacja i logowanie.

35

Uproszczony algorytm działania

36

N są reguły T

odczyt argumentów

inicjacja

start

odczyt i ustawienie reguł

N logowanie zdalne T

ustawienie reguły syslog

demonizowanie procesu

przełączenie interfejsu w tryb bezładny

N tryb demona T

przygotowanie do sniffowania

*

37

przechwyć dane z sieci

*

N logowanie zdalne T

N pasuje reguła syslog T

N są reguły T

dopasowanie pakietu do reguł

T reguła pasuje N

N wyśw. dane pakietu T

przygotowania bufora wyświetlania

dołączenie daty

wyświetlenie wiersza nagłówka

T logowanie zdalne N

wyświetl zawartość pakietu

T sniffować dalej N

wyślij wiersz przez sieć

koniec

Kody źródłowe wybranych procedur

bind:

pushal

movl $sys_socketcall, %eax # rodzaj syscalla

movl $sys_bind, %ebx # bind

movl $bind_args, %ecx # argumenty

int $0x80

movl %eax, err

popal

ret

Prosta procedura korzystająca z wywołania systemowego związuje gniazdo z odpowiednią strukturąadresową.

get_time:

pushl %ebx

pushl %ecx

pushl %edx

pushl %esi

pushl %edi

pushl %esp

pushl %ebp

call time

movl year, %eax # w EAX liczba lat

movl $s_data, %ebx # w EBX adres stringa

call int_to_ascii # konwersja na stringa

addl %eax, %ebx # przesuniecie adresu

movb $47, (%ebx) # wklejenie znaku '/'

incl %ebx # przesuniecie adresu

38

movl month, %eax # w EAX liczba miesiecy

call int_to_ascii # konwersja

addl %eax, %ebx

movb $47, (%ebx) # wklejenie znaku '/'


movl day, %eax # w EAX liczba dni


addl %eax, %ebx

movb $32, (%ebx) # wklejenie odstepu

incl %ebx

cmpl $10, hour

jnl p15_cont

movb $48, (%ebx) # wklejenie znaku '0'


p15_cont:

movl hour, %eax # w EAX liczba godzin


addl %eax, %ebx

movb $58, (%ebx) # wklejenie znaku ':'


cmpl $10, minute # jesli liczba mniejsza od

jnl p15_cont1 # 10 to wklej zero



p15_cont1:

movl minute, %eax # w EAX liczba minut

39


addl %eax, %ebx

movb $46, (%ebx) # wklejenie znaku '.'


cmpl $10, second # jesli liczba mniejsza od

jnl p15_cont2 # 10 to wklej zero



p15_cont2:

movl second, %eax # w EAX liczba sekund


addl %eax, %ebx

movb $32, (%ebx) # wklejenie znaku LF

incl %ebx

movl %ebx, %eax # znakow stringa

subl $s_data, %eax

popl %ebp

popl %esp

popl %edi

popl %esi

popl %edx

popl %ecx

popl %ebx

ret

Prcedura z wykorzystaniem podprocedur time i int_to_ascii buduje łańcuch znakówoznaczający aktualną datę i czas systemowy. W związku z tym, że w systemie Linux wywołaniesystemowe sys_time zwraca ilość sekund od dnia 1 stycznia 1970, istnieje konieczność obliczeniadaty przez cykliczne dzielenie tej liczby na poszczególne lata, miesiące, dni, godziny i minuty.

40

daemon_init:

pushal

movl $sys_fork, %eax # wywolanie

int $0x80 # fork

cmpl $0, %eax # rodzic konczy

jne exit # dzialanie

## tutaj dziala pierwszy potomek

movl $sys_setsid, %eax # potomek zostaje

int $0x80 # przywodca sesji

# ignorowanie sygnalu SIGHUP

movl $sys_signal, %eax # wywolanie signal

movl $1, %ebx # SIGHUP

movl $1, %ecx # SIG_IGN

int $0x80

# powolanie drugiego potomka

movl $sys_fork, %eax # wywolanie

int $0x80 # fork

cmpl $0, %eax # pierwszy potomek

jne exit # konczy dzialanie

# zamkniecie plikow... stdin, stdout, stderr

movl $stdin, %eax

call close

movl $stdout, %eax

call close

movl $stderr, %eax

call close

# teraz proces jest demonem bez terminala sterujacego

popal

ret

41

Procedura daemon_init wykorzystująca wywołanie systemowe sys_fork do dwukrotnegopowołania potomka, w celu odłączenia procesu od terminala sterującego. Jedynym procesemprzodkiem jest wówczas pierwszy proces systemu operacyjnego init. Ostatnim działaniemprocedury jest zamknięcie trzech domyślnych plików procesu: stdin, stdout, stderr.

signal_action:

# zamyka socketa

movl sfd, %eax

call close

# wylacza tryb promisc

call promisc_off

# wyswietla komunikat

movl $graceful_shutdown, %eax

call printn

# zamyka plik wyjsciowy

movl out_file, %eax

call close

jmp exit

ret

W przypadku kiedy użytkownik nie określi ilości przechwytywanych pakietów podczas wywołania,program może działać w pętli nieskończonej. W celu umożliwienia jego poprawnego zakończeniaw takiej sytuacji, wykorzystano procedurę obsługi sygnałów INT i HUP, która po nadejściu sygnałudo procesu zamyka używane pliki, wyłącza tryb bezładny interfejsu sieciowego, wyswietlakomunikat i poprawnie kończy proces w systemie operacyjnym.

42

5.2. grapher

Podstawowymi zadaniami oprogramowania umożliwiającego wizualizację zaobserwowanegoruchu są: analiza pliku wyjściowego sniffera oraz konstrukcja dynamicznej strony WWW.

Grapher to jeden plik stanowiący skrypt języka Perl. Główna pętla programu cyklicznie pobierawiersze z pliku wejściowego i szereguje zaobserwowane dane w tak zwanych tablicachasocjacyjnych:

• %ip_proto zaobserwowane protokoły TCP/IP.

• %tcp_flags pakiety z konkretnymi flagami TCP.

• %icmp_type typy komunikatów ICMP.

• %ttl_count, %tcp_ttl, %udp_ttl, %icmp_ttl tablice zawierające ilościwystąpień pakietów z konkretnymi wartościami pola TTL.

• %len_count, %tcp_len, %udp_len, %icmp_len tablice zawierające ilościwystąpień pakietów o konkretnej długości danych.

• %sip, %tcp_sip, %udp_sip, %icmp_sip zliczanie wystąpień konkretnychźródłowych adresów IP.

• %dip, %tcp_dip, %udp_dip, %icmp_dip zliczanie wystąpień konkretnychadresów IP przeznaczenia.

• %sport, %tcp_sport, %udp_sport ziczanie portów źródłowych.

• %dport, %tcp_dport, %udp_dport zliczanie portów przeznaczenia.

Dzięki procedurom wykorzystywanym przy zlicznaniu poza ogólnymi statystykami uzyskuje sięrównież statystyki dla poszczególnych protokołów:

– tcp_count zlicza ruch TCP

– udp_count zlicza ruch UDP

– icmp_count zlicza ruch ICMP

Kolejnymi krokami po procesie zliczania są sortowanie poszczególnych tablic oraz konstrukcja

43

plików skryptowych PHP i HTML.

Najważniejszym plikiem PHP jest skrypt zawierający dane, czyli posortowane i okrojone tablice.Jego konstrukcja polega na szeregu wywołań (dla poszczególnych tablic) dwóch procedur:

• make_vsorted_table tworzy dwie posortowane w kolejności malejącej tablice PHPz tablic asocjacyjnych Perla. Pierwsza z nich zawiera uporządkowane klucze, a druga wartościodpowiadające tym kluczom. Parametrami procedury są: nazwa tablicy wejściowej, prefiks nazwtablic oraz maksymalna długość tablic wynikowych. Wykorzystywana dla numerów portów,numerów IP, wartości TTL i długości danych pakietu.

• make_percentage_table tworzy trzy posortowane w kolejności malejącej tablice PHP,z których pierwsza jest tablicą kluczy, druga wartości, a trzecia wartości wyrażonychprocentowo. Wykorzystywana dla zaobserwowanych protokołów, flag TCP oraz komunikatówICMP.

Do budowy plików skryptowych PHP generujących dynamicznie obrazy PNG wykorzystywane sącztery nastepujące procedury:

• make_phppng_port konstrukcja skryptu wyświetlającego statystyki najczęsciejwystępujących portów źródłowych oraz przeznaczenia, statystyki ogólne jak również oddzielnedla protokołów TCP i UDP.

• make_phppng_ip konstrukcja skryptu wyświetlającego statystyki najczęsciejwystepujących adresów IP (źródłowych i przeznaczenia), ogólne oraz oddzielne dla protokołówTCP, UDP i ICMP.

• make_phppng_lt konstruuje skrypty wyświetlające statystyki pól nagłówka IP: TTLi długość danych pakietu.

• make_phppng_iit konstruuje skrypty wizualizujące ilość wystąpień konkretnychprotokołów, zestawów flag TCP oraz komunikatów ICMP.

Parametry przekazywane do powyższych procedur to: pełna nazwa pliku wynikowego, prefiksnazwy tablicy zapisane w pliku z danymi, opis osi X, opis statystyki.

Ostatnim zadaniem jakie wykonuje skrypt Perla jest utworzenie plików zawierających stronyHTML, które łączą dynamicznie zbudowane obrazki PNG w jeden, łatwy do przeglądaniadokument. Poszczególne procedury odpowiedzialne są za konkretne pliki HTML: make_sip,make_dport, make_length, make_ttl, make_index.

Pliki skryptów PHP mają bardzo podobną strukturę i wykonują w większości funkcje bibliotekigraficznej GD. Różnice polegają na wykorzystaniu specyficznych tablic danych wejściowych i nasposobie prezentacji wykresów.

44

Przykładowy skrypt PHP uruchamiany po stronie serwera WWW tworzy dynamicznie obraz PNGze statystykami najczęściej wystepujących adresów IP:

<?php

include 'tab.php';

/* inicjacja rozmiaru obrazka */

$x_max = 820;

$y_max = 430;

/* rozmiary slupkow */

$odstep = 6;

$szer = 10;

/* skala */

$skala = 1;

/* przypisanie nazwy tablicy */

$tb = $sip;

$tb_idx = $sip_idx;

$x_name = "IP adr";

$head = "Frequently seen SOURCE IP addresses";

/* korekta rozmiaru obrazka wzgledem rozmiaru tablicy */

$maxs = 43;

$mins = 30;

if (($tb_size = count($tb)) >= $maxs) {

$tb_size = $maxs;

$x_max = 820;

}

else {

$x_max = ($tb_size + 2) * $odstep + (($tb_size + 1) * $szer);

}

if ($tb_size < $mins) {

$x_max = ($mins + 2) * $odstep + (($mins + 1) * $szer);

}

/* ustalenie granic wyswietlania */

$xo = 50;

$yo = $y_max-80;

$ys = $yo - $odstep -$xo;

$x_len = $x_max-10;

45

/* przesuniecie fontow */

$yf = 2;

$xf = 20;

/* korekta skali */

$skala = $ys / $tb[0];

/* naglowek */

header("Content-type: image/png");

/* konstrukcja obrazka */

$im = ImageCreate($x_max, $y_max);

ImageInterlace($im, 1);

/* przezroczystosc obrazka */

$white = ImageColorAllocate($im, 255, 255, 255);

ImageColorTransparent($im, $white);

/* definicja pozostalych kolorow */

$black = ImageColorAllocate($im, 0, 0, 0);

$kol = ImageColorAllocate($im, 0x15, 0x3e, 0xd3);

/* petla wyswietlania statystyk */

for ($i=0; $i < $tb_size; $i++) {

$x1 = ($i + 1) * $odstep + ($i * $szer);

$x2 = $x1 + $szer;

ImageFilledRectangle($im, $xo+$x1, $yo-$tb[$i]*$skala, $xo+$x2, $yo, $kol);

ImageStringUp($im, 1, $xo+$x1, $y_max -5, $tb_idx[$i], $black);

}

/* osie */

/* skrzyzowanie osi */

$oo = 10;

/* ilosc dzialek */

if ($tb_size < 10) {

$il_dz = $tb_size;

}

else {

$il_dz = 10;

}

$sz_dz = 2;

46

/* os pionowa z podzialka */

ImageLine($im, $xo, $yo-$ys -10, $xo, $yo+$oo, $black);

$dz = $tb[0] / $il_dz;

$il_m = $tmp = 1;

for ($i=0; $i < 8; $i++) {

$tmp *= 10;

if ( $tb[0] >= $tmp) $il_m++;

}

for ($i=0; $i < $il_dz+1; $i++) {

ImageLine($im, $xo-$sz_dz, $yo-($dz*$i*$skala), $xo+$sz_dz, $yo-($dz*$i*$skala), $black);

ImageString($im, 1, $xo-2*$sz_dz-$il_m*5, $yo-($dz*$i*$skala) -3 , round($dz*$i), $black);

}

ImageString($im, 3, 1, 30, "packets", $black);

/* os pozioma */

ImageLine($im, $xo-$oo, $yo, $x_len, $yo, $black);

ImageString($im, 3, $x_len-60, $yo+10, $x_name, $black);

ImageString($im, 6, ($x_max/2)- (strlen($head)/2)*6, 20, $head, $black);

ImagePng($im);

ImageDestroy($im);

?>

47

6. Specyfikacja zewnętrzna (użytkownika)

Duży nacisk nałożony został na to, by oprogramowanie analizatora było jak najprostszew użyciu. Chodzi zarówno o wymagania środowiska uruchomieniowego jak i o łatwość użyciakonkretnych funkcji oprogramowania.

6.1. sniffer

Wymagania sprzętowe i programowe

Sniffer w porównaniu z innymi programami dla środowiska Linux jest niemal miniaturowąaplikacją. Plik binarny programu to zaledwie 10kB kodu, który stanowi statyczny programuruchomieniowy, co znaczy, że nie wymaga on tak często stosowanych dzielonych bibliotekdynamicznych. Dzięki temu sniffer zajmuje niewielką ilość pamięci. Do uruchomienia niezbędnejest tylko działające na platformie Intel 80386 jądro systemu operacyjnego Linux z wbudowanąobsługą sieci, co w przypadku ruterów sieciowych jest oczywiste.

Kompilacja i instalacja w systemie

W przypadku gdy brak pliku binarnego programu należy skompilować, zbudować i zainstalować gow systemie. Aby to zrobić trzeba ściągnąć z Internetu spakowany plik z kodem źródłowym snifferai wykonać następujące polecenia w wierszu poleceń powłoki:

[droper@pxgw droper]$ tar zxvf ifsnew.tgz

ifsnew/

ifsnew/Makefile

ifsnew/ifs.s

ifsnew/README

ifsnew/rules.s

ifsnew/basicproc.s

ifsnew/args.s

ifsnew/data.s

ifsnew/rules.conf

ifsnew/promisc.s

ifsnew/signals.s

ifsnew/packet.s

Rozpakowanie pliku z katalogiem źródeł programu.

[droper@pxgw droper]$ cd ifsnew

[droper@pxgw ifsnew]$

48

Przejście do katalogu zródeł.

[droper@pxgw ifsnew]$ make

as W o ifs.o ifs.s

ld s o ifs ifs.o

rm rf ifs.o

wykonanie makropolecenia spowoduje kompilację kodu w języku symbolicznym, zlinkowanieprogramu i zbudowanie uruchomieniowego pliku binarnego, usunięcie pliku obiektowego.

[droper@pxgw ifsnew]$ su

Password:

root@pxgw:/home/droper/ifsnew#

Przełączenie na użytkownika root (konto administracyjne) w celu dokonania wpisu do systemowychkatalogów binariów (/usr/sbin).

root@pxgw:/home/droper/ifsnew# make install

cp ifs /usr/sbin

Skopiowanie pliku binarnego do katalogu systemowego.

Uruchamianie

Podobnie jak wiele innych programów dla konsoli, sniffer uruchamiany jest przez wpisanie nazwypliku binarnego (ifs) w wierszu poleceń konsoli i potwierdzenie klawiszem <enter>. W celuuproszczenia obsługi programu, został on wyposażony w zestaw domyślnych opcji uruchomienia.W przypadku uruchomienia programu bez żadnych przełączników następuje próba dostępu dopierwszego interfejsu Ethernet (eth0), przechwytywane są wszystkie pakiety z tego interfejsu i niejest wykonywane żadne filtrowanie ruchu. Zinterpretowane pakiety są wyświetlane bezpośrednio nastandardowe wyjście programu. Zakończenie następuje po naciśnieciu kombinacji <ctrl+c> lubprzez wysłanie do programu jednego z sygnałów: INT, HUP, w ostateczności KILL.

Opcje programu

Składnia uruchomienia sniffera z dodatkowymi opcjami wygląda nastepująco:

ifs [d] [i <interfejs>] [b <ilosc>] [o <nazwa pliku wyjsciowego>] [s <adres IP>]

[r <nazwa pliku regulek filtra>] [c <ilosc>] [l <rozmiar>] [g <rozmiar>]

49

Opis poszczególnych opcji:

-d program działa w trybie demona. Demon w systemie Linux to proces, który działaodłączony od terminala sterującego. Znaczy to, że komunikacja z procesem może odbywać się zapomocą sygnałów, brak tu bezpośredniej interakcji z użytkownikiem. W tym trybie sniffer zamykapliki standardowego wejścia, standardowego wyjścia i standardowego wyjścia błędów (deskryptory0, 1 i 2), nie wyświetla wyników działania i nie ma możliwości przerwania za pomocą kombinacjiklawiszy. Od tego momentu program działa niezależnie, a dane wyjściowe zapisywane są do plikudyskowego lub wysyłane przez sieć.

-i nazwa określenie nazwy interfejsu sieciowego, na którym program ma nasłuchiwać. To teninterfejs zostanie przełączony w tak zwany tryb bezładny (promiscuous) i interpretowany będzieruch z sieci do której jest on bezpośrednio podłączony.

-b ilość ustalenie ilości bajtów danych pakietu, które mają być wyświetlane. Domyślniesniffer wyświetla tylko zinterpretowane pola nagłówków protokołów, dzięki czemu działa szybko,gdyż z pakietów przechwytywana i kopiowana do programu jest tylko ta część bufora, która zawieranagłówki, zwykle około 120 bajtów). Maksymalna ilość danych pakietu to 1500 bajtów, ze względuna ograniczenie MTU (Maximum Trasmission Unit). Przy specyfikowaniu tej opcji należy zwrócićuwagę na fakt, że kopiowanie znacznych ilości danych sieciowych może w znacznym stopniuobciążyć system, a nawet w przypadku szybkich sieci spowodować przeciążenie stacji. Gdy celemjest stworzenie pliku wyjściowego do późniejszego wykorzystania go przez graphera, nie zalecanejest używanie tej opcji.

-o nazwa określenie nazwy pliku wyjściowego. Opcja ta ma zastosowanie tylko w przypadkutrybu demona. Domyślnie jest to plik o nazwie logfile w bieżącej lokalizacji. W przypadku gdy pliko podanej nazwie istnieje w systemie plików, sniffer kończy działanie, a plik nie jestmodyfikowany. Należy zwrócić uwagę na to zachowanie programu zwłaszcza w momencie, gdyprogram nie wykona oczekiwanych działań. W trybie trminala plikiem wyjściowym jeststandardowe wyjście zwykle kierowane na ekran monitora.

-r nazwa określa nazwę pliku, w którym zawarte są reguły filtra pakietów. Format tego plikujest opisany w dalszej częsci specyfikacji. Domyślnie pakiety nie podlegają żadnemu filtrowaniu.

-c ilość ustalenie ilości pakietów, po przechwyceniu której program zakończy działanie.Domyślnie nie ma ograniczenia tej ilości i sniffer działa dopóki użytkownik świadomie go niezakończy. Zliczne są tylko te pakiety, które wyspecyfikował użytkownik, czyli pasujące dowybranych opcji i spełniające kryteria wyznaczone przez filtry.

-l rozmiar określenie maksymalnej wielkości pakietu. Wyświetlone zostaną tylko te wpisy,w których wielkość pakietu jest mniejsza od tego rozmiaru. W przypadku wartości 0 dla tej opcjipakiety nie są filtrowane.

-g rozmiar określenie minimalnej wielkości pakietu. Podobnie jak we wcześniejszej opcji,filtrowanie nie jest wykonywane gdy rozmiar jest ustawiony na 0.

50

-s IP ustalenie adresu IP serwera syslog. Dane wyjściowe sniffera są wysyłane przez siećza pomocą protokołu UDP do zdalnej maszyny, na której musi być uruchomiona usługa logowania.W przypadku użycia tej opcji na ruch sieciowy jest automatrycznie zakładany filtr pakietówkierowanych do tej konkretnej maszyny. Wówczas sniffer przechwytuje cały ruch sieciowyz wyjątkiem tego, który sam generuje. W przypadku szybkich interfejsów i dużego ruchu zdalnelogowanie może być niemożliwe, ze względu na straty pakietów UDP z dużą częstotliowściątransmitowanych do sieci. Poziom logowania ustawiany jest na LOCAL4.

-t wyświetla tylko segmenty protokołu TCP, przełącznik ten można łączyć z dwomakolejnymi w celu wyświetlenia nagłówków wybranych protokołów.

-u wyświetla tylko datagramy UDP

-m wyświetla tylko komunikaty ICMP

Plik reguł filtra pakietów

Plik ten powinien składać się z wierszy o określonym formacie, z których każdy specyfikuje jednąregułę filtra.

Format pojedynczej reguły:

s1.s2.s3.s4:sport>d1.d2.d3.d4:dport

Pola s1, s2, s3 i s4 oddzielone kropką '.' oznaczają kolejne bajty źródłowego adresu IP, odnajstarszego do najmłodszego. Każde z tych pól może być liczbą z zakresu od 0 do 255(maksymalnie 3 znaki).

Znakiem dwukropka ':' od źródłowego adresu IP jest oddzielone pole sport, oznaczające 16 bitowynumer portu źródłowego. Pole to może być liczbą z zakresu od 0 do 65535 (maksymalnie5 znaków).

Kolejnym (stałym) elementem reguły są znaki rozdzielające część źródłową reguły od częsciprzeznaczenia: '->'.

Adres przeznaczenia analogicznie do adresu źródłowego składa się z pól opisujących poszczególnebajty (d1, d2, d3, d4).

Ostatnim elementem reguły jest pole dport oznaczające port przeznaczenia.

Każda reguła, aby została właściwie zinterpretowana musi zawierać się w oddzielnym wierszu.Liczba 0 na dowolnym polu oznacza dopasowanie dowolnej wartości. W przypadku błędóww regułach, sniffer wyświetli, która z nich zawiera błąd.

51

Przykładowa zawartość pliku reguł:

0.0.0.0:0>0.0.0.0:22

0.0.0.0:22>0.0.0.0:0

213.227.72.4:0>0.0.0.0:80

0.0.0.0:80>213.227.72.4:0

Tak utworzone reguły spowodują wyświetlanie pakietów należących do wszystkich sesji protokołuSSH oraz połączeń z serwerami WWW hosta 213.227.72.4.

Format danych wyjściowych

W związku z tym, że sniffer może działać jako niezależne narzędzie administracyjne, danewyjściowe są prezentowane w taki sposób by nie tylko udostępniać kompleksowe informacjegrapherowi, ale przede wszystkim by były przejrzyste i czytelne dla użytkownika.

Pierwszym polem wiersza wyjściowego jest data i godzina przechwycenia pakietu. Pole to maodmienny format w przypadku logowania na lokalnej lub na zdalnej stacji. Wynika to z faktu, żew pierwszym przypadku sniffer sam określa dokładny czas i dołącza go do wyjścia programu.Natomiast syslog (zdalne logowanie) zapewnia własne mechanizmy umożliwiające właściwewypełnienie tego pola.

Drugie pole stanowi ciąg znaków określający rodzaj danych pakietu IP, zwykle jest to nazwaprotokołu wyższej warstwy.

Kolejne pola formatu wyjściowego zależne są od tego, jaki protokół został rozpoznany.W przypadku TCP następne pole to flagi protokołu oddzielone przecinkami (np. psh,ack), ICMP torodzaj komunikatu kontrolnego.

Wpólne dla wszystkich pakietów IP są pozostałe poza, z tym tylko wyjątkiem, że w przypadkuICMP brak numerów portów.

Źródłowy adres IP jest przedstawiony w notacji kropkowo dziesiętnej, za nim po znaku dwukropka':' następuje numer portu źródłowego. Znaki określające kierunek przesyłu danych IP to '->'.Analogicznie do źdródłowego sformatowany jest adres przeznaczenia.

Trzy ostatnie pola to wartość TTL (Time To Live), długość danych pakietu oraz bity fragmentacji(możliwe wartości to: DF, MF i 0).

2004/5/31 09:08.00 TCP psh,ack 217.11.251.145:1755 -> 213.227.72.61:1089 ttl=111 len=1460 DF

2004/5/31 09:08.00 TCP ack 80.213.67.1:24462 -> 195.82.189.250:2049 ttl=113 len=1448 DF

2004/5/31 09:08.00 UDP 62.21.6.63:12912 -> 195.82.188.115:3696 ttl=121 len=25 0

2004/5/31 09:08.00 TCP ack 216.74.27.29:80 -> 213.227.72.74:3659 ttl=107 len=1448 DF

2004/5/31 09:08.00 UDP 213.23.198.130:4679 -> 195.82.189.119:5662 ttl=118 len=20 0

2004/5/31 09:08.00 UDP 193.12.224.218:11015 -> 213.227.72.52:10609 ttl=114 len=111 0


52

2004/5/31 09:08.00 TCP fin,ack 212.144.70.45:4662 -> 213.227.72.66:4426 ttl=118 len=0 DF

2004/5/31 09:08.00 ICMP echo_request 213.227.72.91 -> 68.145.109.222 ttl=4 len=4 0

2004/5/31 09:08.00 UDP 213.227.73.18:1043 -> 140.112.3.52:4665 ttl=125 len=18 0

2004/5/31 09:08.00 UDP 213.227.74.140:6257 -> 4.5.128.38:6257 ttl=125 len=217 0

Przykładowe wyjście sniffera prezentuje opisane wcześniej pola sformatowanego wiersza. Ilośćdanych i przejrzystość ich prezentacji zapewnia łatwą interpretację i efektywność działania.

W domyślnej konfiguracji sniffer przechwytuje i interpretuje tylko nagłówki protokołówposzczególnych warstw. Jednak często istnieje potrzeba obserwacji danych pakietu w celuzdiagnozowania przyczyn niewłaściwego działania sieci. Wówczas sniffer poza sformatowanymwierszem nagłówka wyświetla określoną przez użytkownika ilość bajtów danych pakietu:

2004/5/31 11:47.07 TCP syn 213.227.72.4:51014 -> 195.187.7.66:80 ttl=63 len=0 DF

No data. Only header.

2004/5/31 11:47.07 TCP syn,ack 195.187.7.66:80 -> 213.227.72.4:51014 ttl=56 len=0 DF


2004/5/31 11:47.07 TCP ack 213.227.72.4:51014 -> 195.187.7.66:80 ttl=63 len=0 DF



GET / HTTP/1.1

Host: www.cert.pl

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

Accept:text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1

Accept-Language: pl,en;q=0.8,be;q=0.5,ru;q=0.3

Accep

2004/5/31 11:47.07 TCP ack 195.187.7.66:80 -> 213.227.72.4:51014 ttl=56 len=0 DF


2004/5/31 11:47.07 TCP ack 195.187.7.66:80 -> 213.227.72.4:51014 ttl=56 len=1448 DF

HTTP/1.1 200 OK

Date: Mon, 31 May 2004 09:47:07 GMT

Server: Apache

Keep-Alive: timeout=15, max=100

Connection: Keep-Alive

Transfer-Encoding: chunked

Content-Type: text/html

Przykładowe wyjście prezentuje nawiązanie połączenia TCP do serwera www.cert.pl (trzy pierwszepakiety zawierają tylko nagłówki). Zaobserwować można zapytanie HTTP oraz odpowiedź serwera.

53

Należy zwrócić uwagę, że w przypadku ruterów podłączonych do sieci o dużej przepustowości,przechwytywanie nawet tylko nagłówków może spowodować, że rozmiar pliku wyjściowego będziebardzo duży. Gdy prowadzone jest zdalne logowanie syslog, dodatkowo istnieje problemutraconych podczas szybkiej transmisji pakietów. Dlatego zalecane jest filtrowanie ruchu zapomocą reguł oraz przełączników programu.

Przykłady uruchamiania

Do programu sniffera można przekazać parametry za pomocą odpowiednich przełączników wierszapoleceń, co pociąga za sobą konieczność sprawdzenia poprawności ich argumentów. Zachowanieprogramu i jego interakcja z użytkownikiem jest zależna od rodzaju potencjalnego błędu wywołaniabądź niewłaściwego formatu danych wejściowych.

W przypadku większości błędów składni uruchamiania sniffera, na standardowe wyjście drukowanajest informacja o formacie wywołania oraz zwięzły opis opcji programu.

Przykład 1

root@r1:~# ifs i eth0 c 1000 b R

IFS Internet Protocol Sniffer

Usage: ifs [OPTION]...

d daemon mode

i IfName sniffing interface

b Bytes number of bytes sniffed from each packet

c Count numer of packets sniffed

l LessSize sniff packets less than LessSize

g GreSize sniff packets greater than GreSize

o LogFile file for logging packets

r RulesFile file with sniffing rules

s IP IP address of syslogd machine

W powyższym przykładzie trzy pierwsze przełączniki i ich argumenty są podane właściwie, leczostatni (-R) jest błędny. Sniffer wyświetla informacje o zestwie dostępnych przełączników, dziękiktórym użytkownik jest w stanie szybko zlokalizować swój błąd.

Analogiczne zachowanie sniffera ma miejsce również wówczas, gdy choć do jednego z podanychpoprawnie przełączników, użytkownik nie określi wymaganego argumentu lub argument maniewłaściwy format.

54

Przykład 2

root@r1:~# ifs g 0x15f

Błędny format argumentu. Paprawne akceptowalne wartości mogą być przekazane jedynie w zapisiedziesiętnym.

Przykład 3

root@r1:~# ifs r c 400 s

Brak nazwy pliku reguł za przełącznikiem -r, brak numeru IP za przełącznikiem -s.

Część błędów wywołania jest możliwa do wykrycia w etapie sprawdzania poprawnościargumentów. Jednak mogą zdarzyć się sytuacje, w których pozornie poprawny argument nieodpowiada wymaganiom sniffera. Tego rodzaju błędy to np. nieistaniejący interfejs sieciowy, brakpodanego pliku reguł lub błędny format pliku. W takim przypadku program sygnalizuje wystąpieniebłędu odpowiednim komunikatem i albo przerywa działanie gdy błąd jest krytyczny, albokontynuuje działanie jeśli błąd nie ma wpływu na kluczowe funkcje sniffera.

Przykład 4

root@r1:~# ifs i eth4 b 150 r reguly.txt

Error opening file reguly.txt.

Plik o podnej nazwie nie istnieje lub nie można go otworzyć, program kończy działanie.

Przykład 5

root@r1:~# ifs i ppp8 l 20

ppp8 entering promiscuous mode...

No such device.

W systemie brak interfejsu sieciowego o podanej nazwie, program kończy działanie. Sniffer wykryłpowyższy błąd w momencie próby przełączenia interfejsu w tryb bezładny.

55

Przykład 6

root@r1:~# ifs c 3 r rules.conf

Bad rule: 0.0.0.0:0>195.82.190.25a:80

eth0 entering promiscuous mode...

2004/6/11 19:41.31 TCP ack 69.93.182.178:80 > 213.227.72.34:2621 ttl=42 len=1460 DF

2004/6/11 19:41.31 TCP fin,psh,ack 69.93.182.178:80 > 213.227.72.34:2621 ttl=42 len=1052 DF

2004/6/11 19:41.31 TCP ack 195.137.208.67:80 > 213.227.72.54:4252 ttl=118 len=1448 DF

W pliku reguł (rules.conf) jedna z reguł ma niewłaściwy format (w adresie IP znajduje się litera 'a').Program informuje o tym fakcie w momencie parsowania reguł, następnie działa dalej, pomijającbłędną regułę.

Przykład 7

[droper@r1 droper]$ ifs i eth0 c 200

Only root can run this program.

W przykładzie użytkownik systemu zamierzał prowadzić monitorowanie ruchu 200 pakietów nainterfejsie eth0. Dostęp do warstwy kanałowej, w której prowadzone jest przechwytywanie jestściśle ograniczony i jedynym użytkownikiem, który ma prawo wykonywać tego typu operacje jestadministrator systemu. Jedną z pierwszych czynności, które przeprowadza sniffer jest weryfikacjanumeru identyfikacyjnego użytkownika (UID) uruchamiającego program. W przypadku gdy numerten jest inny niż określony numer administratora systemu (UID 0) sniffer kończy działanieinformując użytkownika, że nie ma on odpowiednich uprawnień do wykonywania programu.

Poza opisanymi w przykładach, najczęściej występującymi błędami uruchomienia sniffera, mogąwystąpić inne anomalia w działaniu, które jednak autor pracy w procesie testowania i poprawianiabłędów starał się wyeliminować.

Zestaw przełączników i opcji w połączeniu z wykorzystaniem pliku reguł przechwytywania, dajedość dużą ilość możliwości użycia programu.

56

6.2. grapher

Wymagania

W założeniu grapher powinien działać w środowisku serwera, co zapewnia mu niezbędneoprogramowanie.

Podstawowym wymaganiem do samego uruchomienia graphera i jego poprawnej pracy jest pakietPerl wraz ze standardowymi bibliotekami. Zwykle jest on instalowany domyślnie w każdejserwerowej dystrybucji systemu Linux, także ze względu na fakt, że wiele aplikacji systemowychz niego korzysta.

W celu udostępnienia wygenerowanych przez graphera stron html i obrazków niezbędne jesturuchomienie serwera WWW (np. Apache) z obsługą skryptów PHP i biblioteką GD.

Instalacja

Grapher zawiera się w jednym pliku tekstowym o bardzo małym rozmiarze i jest dołączony doźródeł programu sniffera. Podczas instalacji sniffera, w systemie zainstalowany zostanie równieżgrapher. Nie jest wymagana żadna dodatkowa konfiguracja.

Uruchamianie

Najprostszym sposobem uruchomienia graphera jest wpisanie jego nazwy wraz z wymaganymiprzełącznikami w wierszu poleceń powłoki i potwierdzenie klawiszem <enter>. Po analizie plikuwejściowego skrypt utworzy wszystkie niezbędne pliki i zakończy działanie.

Dzięki prostocie wywołania programu może on być z łatwością użyty w różnego rodzaju skryptachautomatyzujących zadania.

Opcje programu

Grapher posiada ograniczoną do niezbędnego minimum ilość opcji, z których dwie są konieczne douruchomienia skryptu: lokalizacja pliku wejściowego i katalog przeznaczenia.

Składnia uruchamiania:

grapher.pl [s] f <plik> d <katalog>

Opis poszczególnych opcji:

-f plik określenie nazwy pliku wejściowego wraz z pełną ścieżką dostępu.

-d katalog ustalenie katalogu, w którym zapisywane będą pliki wynikowe. Skrypt powinienmieć prawo zapisu w tym katalogu, w przeciwnym przypadku jego działanie zakończy się

57

komunikatem o błędzie. Jeśli w katalogu tym znajdują się pliki o takich samych nazwach jakgenerowane przez skrypt, to zostaną one nadpisane.

-s określa rodzaj pliku wejściowego. Plik wyjściowy posiada niewielkie różnice zależneod sposobu uruchomienia sniffera. Opcję tę należy włączyć w przypadku przetwarzania plikuutworzonego zdalnie przez usługę syslog.

Pliki wyjściowe

Drzewo plików wyjściowych stanowi kompletną witrynę, którą można przeglądać zdalniez dowolnego hosta wyposażonego w przeglądarkę WWW (np. Mozilla).

Pliki z rozszerzeniem .php generują dynamicznie obraz PNG, który można zapisać w tymformacie na komputerze klienta:

• obrazy statystyk ogólnych i szczegółowych adresów IP:

dip.php, sip.php, icmp_dip.php, icmp_sip.php, tcp_dip.php,

tcp_sip.php, udp_dip.php, udp_sip.php

• obrazy statystyk ogólnych i szczegółowych numerów portów:

dport.php, sport.php, tcp_dport.php, tcp_sport,

phpudp_dport.php, udp_sport.php

• obrazy statystyk ogólnych i szczegółowych długości danych pakietu:

length.php, icmp_length.php, tcp_length.php, udp_length.php

• obrazy statystyk ogólnych i szczegółowych wartości pola Time To Live:

ttl.php, icmp_ttl.php, tcp_ttl.php, udp_ttl.php

• obrazy statystyk zaobserwowanych protokołów, typów komunikatów ICMP oraz zestawów flagTCP:

ip_proto.php, tcp_flags.php, icmp_type.php

Dostęp do tych obrazów można uzyskać odwołując się bezpośrednio do danego pliku lubwykorzystać szablon HTML, który stanowią następujące pliki:

dip.html, dport.html, index.html, length.html,

sip.html, sport.html, ttl.html

58

Ostatnim i najważniejszym plikiem jest tab.php, w którym mieszczą się tablice zawierająceposzeregowane przez graphera wartości dla poszczególnych kluczy. Jesli zabraknie tego pliku lubzostanie on skasowany, pozostałe skrypty nie będą w stanie zbudować wykresów.

Przykłady uruchamiania

W odróżnieniu od sniffera, skrypt graphera posiada ograniczony do niezbędnego minium zestawprzełączników. Poza tym jego uruchomienie nie wymaga posiadania praw administratora systemu,a jedynie możliwości odczytu pliku wejściowego oraz dostępu do zapisu w katalogu docelowym.

Przykład 1

[droper@max droper]$ grapher.pl

Grapher IFS statistics maker

Usage: grapher.pl [OPTION] f logfile d output_dir

s syslog type Logfile

W przypadku, kiedy użytkownik nie poda wymaganych przełączników wraz z odpowiednimiaregumentami, program wyświetli poprawną składnię wywołania oraz uproszczony opis opcji.

Przykład 2

[droper@max droper]$ grapher.pl f r3.log d /home/droper/public_html/r3/

Can't open log file: r3.log

Użytkownik określił plik wejściowy za pomocą przełącznika -f, jednak plik ten nie istniejew określonej lokalizacji, wobec czego program wyświetla komunikat i kończy działanie.

Przykład 3

[droper@max grapher]$ grapher.pl f kawa.log d /var/www/html/

Can't open output file /var/www/html/tab.php for writing.

59

W związku z tym, że grapher tworzy drzewo plików wyjściowych, wymaga on praw zapisuw katalogu wyjściowym. Podczas otwierania do zapisu każdego pliku wyjściowego są sprawdzanewarunki poprawności. W przypadku gdy otwarcie choć jednego z plików nie powiedzie się, skryptkończy działanie informując użytkownika o błędzie zapisu. W powyższym przykładzie użytkownikoreślił katalog wyjściowy na katalog główny, w którym serwer WWW przechowuje dokumenty(/var/www/html). Z tego powodu, że zwykły użytkownik systemu nie ma praw zapisu w tymkatalogu, grapher wyświetlił komunikat o błędzie tworzenia pierwszego pliku wyjściowego(tab.php), który zawiera tablice dla pozostałych skryptów i zakończył działanie.

Przykład 4

[droper@max grapher]$ grapher.pl f wnet.log d /home/droper/public_html/wnet/

Powyższe poprawne wywołanie programu spowoduje zbudowanie z pliku wejściowego wnet.logstruktury plików w katalogu /home/droper/public_html/wnet/. Szybkość działania grapherazależy głównie od czasu przetwarzania pliku wejściowego, który może być znaczny w przypadkudużych plików. Ułatwieniem dla użytkownika jest nadpisywanie przez program starych plikówo tych samych nazwach w katalogu wyjściowym. Umożliwia to cykliczne uruchamianie grapheraw celu aktualizacji wykresów przy zmianach w pliku wejściowym (np. plik generowany przezsyslog).

Przykład 5

root@pirx:/var/www/html# ifs s f /var/log/sniffer.log d .

W przykładzie tym przetwarzany jest plik sniffer.log. Który utworzony został w systemie hostapirx z wykorzystanie zdalnego logowania syslog. Możliwe jest by tak utworzony plik zawierał danez kilku snifferów uruchomionych na różnych stacjach, dzięki czemu administrator ma sposobnośćobserwowania specyficznego ruchu w różnych miejscach sieci jednocześnie oraz łatwe zbudowaniejego statystyk na jednym hoście-serwerze. Dostęp do plików w katalogu logów systemowych orazprawa zapisu w głównym katalogu dokumentów serwera WWW, ma użytkownik root, dlategopolecenie w przykładzie jest wywołane z jego konta. Przełącznik -s sygnalizuje grapherowi, że plikwejściowy jest w formacie syslog i że należy go interpretować w nieco inny sposób. Drzewo plikówwyjściowych utworzone zostanie w katalogu bieżącym (argumentem przełącznika -d jest kropka '.')czyli w katalogu /var/www/html.

60

7. Testowanie i przykładowe wyniki działania oprogramowania

W sieciach TCP/IP, ze względu na zastosowanie szerokiej rodziny protokołów różnychwarstw modelu DoD, mają miejsce określone zjawiska przewidziane i zaplanowane przez twórcówprotokołów. Często jednak zdarza się, że projektowane w czasach gdy Internet nie był takpowszechny jak obecnie protokoły stają się podatne na różnego rodzaju ataki, począwszy odprostych (syn flood) a kończąc na bardzo wyrafinowanych (tcp spoofing). Do sprawdzeniapoprawności działania sieci i wykrycia błędów lub ataków można wykorzystać sniffera.Oto przykładowe zastosowania:

7.1. Ping (icmp)

Najprostszym programem diagnostycznym wykorzystywanym do sprawdzenia łączności międzydwoma stacjami w sieci TCP/IP jest program ping.

root@bzz:~# ifs


2004/6/1 20:03.10 ICMP echo_request 213.227.72.4 -> 66.218.71.114 ttl=64 len=60 DF

2004/6/1 20:03.10 ICMP echo_response 66.218.71.114 -> 213.227.72.4 ttl=41 len=60 DF





Działanie programu ping oparte na wymianie komunikatów kontrolnych protokołu ICMP. Stacjasieciowa wysyła do zdalnego hosta komunikat echo request (żądanie odpowiedzi z echem). Jeślizdalny komupter jest poprawnie skonfigurowany w środowisku sieci IP i ma włączoną obsługęICMP powinien odpowiedzieć komunikatem echo response. W powyższym przykładzie na stacjisieciowej o adresie 213.227.72.4 badana jest dostępność serwera yahoo.com (66.218.71.114).

7.2. Traceroute (icmp)

Programy typu traceroute z wykorzystaniem cyklicznego przesyłania komunikatów ICMPumożliwiają wyznaczenie trasy pakietu IP od hosta źródłowego do przeznaczenia, przy czymdokładnie określone są rutery przez które przesyłany jest pakiet.

Przykładowe wywołanie programu mtr (Matts Traceroute):

droper@bzz:~$ mtr -c 1 ftp.task.gda.pl -r

HOST LOSS RCVD SENT BEST AVG WORST

px-gw.gl.digi.pl 0% 1 1 1.39 1.39 1.39

ck-gw--z-JP-ATM.gl.digi.pl 0% 1 1 16.23 16.23 16.23

z-pirxnet.SILWEB.PL 0% 1 1 12.57 12.57 12.57

61

K-PSE-r1-rc.SILWEB.PL 0% 1 1 9.42 9.42 9.42

K-PSE-r2-rc.SILWEB.PL 0% 1 1 17.06 17.06 17.06

z-gliwic-oc3.gdansk.pol34.pl 0% 1 1 26.32 26.32 26.32

rge-ci-swr.task.gda.pl 0% 1 1 31.10 31.10 31.10

korweta.task.gda.pl 0% 1 1 30.22 30.22 30.22

Trasa do tego hosta prowadzi przez siedem ruterów. Poniżej przechwycona przez sniffera wymianakomunikatów ICMP:

root@bzz:~# ifs



2004/6/1 20:29.03 ICMP echo_response 213.227.72.12 -> 213.227.72.4 ttl=64 len=68 0

















Badanie trasy wykonywane jest za pomocą wysyłanych kolejno komunikatów echo requestz cyklicznie inkrementowanym polem TTL, zaczynając od wartości 1. W ten sposób żądania echadocierają do kolejnych ruterów i są odsyłane nadawcy. Czynność ta jest powtarzana aż doosiądnięcia celu lub przekroczenia dopuszczalnej liczby hopów (domyślnie 30).

7.3. Nawiązywanie połączenia TCP

Protokół TCP jest protokołem połączeniowym wartwy transportowej. Połączenie jest wykonywanew trzech krokach: stacja inicjująca połączenie wysyła do serwera pakiet TCP z ustawioną flagąSYN i pewnym generowanym losowo numerem sekwencyjnym, następnie serwer odpowiadapakietem z zapalonymi flagami SYN i ACK oraz zwiększonym o jeden numerem sekwencyjnymstacji klienta (ack) oraz własnym numerem sekwencyjnym, klient po odebraniu pakietu odsyłasegment ACK ze zwiększonym o jeden numerem sekwencyjnym serwera.

62

root@bam:~/ifs-new# ./ifs


2004/6/2 20:46.23 TCP syn 10.0.0.2:1030 -> 195.82.191.3:25 ttl=64 len=0 DF


2004/6/2 20:46.23 TCP ack 10.0.0.2:1030 -> 195.82.191.3:25 ttl=64 len=0 DF

Przykładowe połączenie TCP do serwera pocztowego na port 25, przechwycone z wykorzystaniemsniffera.

7.4. Transmisja w strumienu TCP

Protokół transportowy TCP gwarantuje poprawność przesyłanych w strumieniu połącznia danych.Jednym z mechanizmów kontroli transmisji są potwierdzenia odebrania każdego segmentu.

root@bam:~/ifs-new# ./ifs



2004/6/2 20:56.16 TCP ack 10.0.0.2:1036 -> 213.227.72.4:22 ttl=64 len=0 DF


2004/6/2 20:56.16 TCP ack 213.227.72.4:22 -> 10.0.0.2:1036 ttl=56 len=0 DF


2004/6/2 20:56.16 TCP ack 10.0.0.2:1036 -> 213.227.72.4:22 ttl=64 len=0 DF


2004/6/2 20:56.17 TCP ack 213.227.72.4:22 -> 10.0.0.2:1036 ttl=56 len=0 DF


2004/6/2 20:56.17 TCP ack 10.0.0.2:1036 -> 213.227.72.4:22 ttl=64 len=0 DF


2004/6/2 20:56.17 TCP ack 213.227.72.4:22 -> 10.0.0.2:1036 ttl=56 len=0 DF


2004/6/2 20:56.17 TCP ack 10.0.0.2:1036 -> 213.227.72.4:22 ttl=64 len=0 DF

Przedstawiona powyżej dwukierunkowa transmisja zdalnego dostępu do powłoki systemu (SSH,port 22) obrazuje działanie potwierdzeń (ack). Segmenty danych (pole length oreśla ilość bajtów)przesyłane przez serwer lub klienta opatrzone są flagami PSH i ACK, potwierdzenia natomiastto puste segmenty ACK (długość danych równa 0).

7.5. Zakończenie połączenia TCP

W celu zakończenia połączenia jedna ze stacji wysyła segment FIN (może być również zapalonaflaga ACK jako potwierdzenie odbioru wcześniejszych danych), odpowiedzią zdalnego hosta jestrównież pakiet FIN,ACK potwierdzający zerwanie połączenia, ostatnim krokiem jest potwierdzenie

63

wysyłane przez pierwszą stację.root@bam:~/ifs-new# ./ifs




2004/6/2 21:11.17 TCP ack 213.77.21.150:110 -> 10.0.0.2:1037 ttl=60 len=0 DF

7.7. Ataki odmowy usługi i skanowanie.

Często wykorzystywanym atakiem DoS (Denial of Service, atak odmowy usługi) jest tak zwanySYN flood. Jest to prosty, siłowy atak polegający na szybkim zalewaniu konkretnych hostów lubsieci pakietami inicjującymi połączenie (zapalona flaga TCP SYN). W ten sposób oprogramowanieTCP/IP atakowanego hosta stara się odpowiedzieć segmentem syn/ack, co przy odpowiednio dużymnatężeniu strumienia SYN może spowodować, że host nie będzie w stanie świadczyć usługsieciowch, a nawet system operacyjny zawiesi się w wyniku przeciążenia.

Rozszerzeniam pojedynczego ataku odmowy usługi jest DDoS (Distributed Denial of Service),w którym atak przeprowadzany jest z wielu hostów w sieci na jeden serwer usług. Atak taki jestzwykle skuteczny, gdyż trudno się przed nim uchronić za pomocą właściwego filtrowania ruchu.

Poniższy fragment wyjścia sniffera prezentuje skanowanie sieci za pomocą pakietów SYN przezzarażone (robak Blaster) hosty 192.168.11.58 i 192.168.11.53, w celu zainfekowania kolejnychhostów potrzebnych następnie do wykonania rozproszonego ataku odmowy usługi:

[root@kawa ifs-new]# ./ifs -i eth0 -c 1000 -r rules.conf


2004/6/6 17:54.39 TCP syn 192.168.11.58:1459 -> 209.175.16.253:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.58:1460 -> 209.175.16.254:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.58:1462 -> 209.175.17.0:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.58:1463 -> 209.175.17.1:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.58:1464 -> 209.175.17.2:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.58:1465 -> 209.175.17.3:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.58:1466 -> 209.175.17.4:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.58:1467 -> 209.175.17.5:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.58:1468 -> 209.175.17.6:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.58:1469 -> 209.175.17.7:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.58:1470 -> 209.175.17.8:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.58:1471 -> 209.175.17.9:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.58:1472 -> 209.175.17.10:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.58:1473 -> 209.175.17.11:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.58:1474 -> 209.175.17.12:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.58:1475 -> 209.175.17.13:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.58:1476 -> 209.175.17.14:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.58:1477 -> 209.175.17.15:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.58:1478 -> 209.175.17.16:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.53:1940 -> 193.211.222.249:135 ttl=128 len=0 DF

64

2004/6/6 17:54.39 TCP syn 192.168.11.53:1941 -> 193.211.222.250:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.53:1942 -> 193.211.222.251:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.53:1943 -> 193.211.222.252:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.53:1944 -> 193.211.222.253:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.53:1945 -> 193.211.222.254:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.53:1947 -> 193.211.223.0:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.53:1948 -> 193.211.223.1:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.53:1949 -> 193.211.223.2:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.53:1950 -> 193.211.223.3:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.53:1951 -> 193.211.223.4:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.53:1952 -> 193.211.223.5:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.53:1953 -> 193.211.223.6:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.53:1954 -> 193.211.223.7:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.53:1955 -> 193.211.223.8:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.53:1956 -> 193.211.223.9:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.53:1957 -> 193.211.223.10:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.53:1958 -> 193.211.223.11:135 ttl=128 len=0 DF

2004/6/6 17:54.39 TCP syn 192.168.11.53:1959 -> 193.211.223.12:135 ttl=128 len=0 DF

2004/6/6 17:54.40 TCP syn 192.168.11.58:1479 -> 209.175.17.17:135 ttl=128 len=0 DF

2004/6/6 17:54.40 TCP syn 192.168.11.58:1480 -> 209.175.17.18:135 ttl=128 len=0 DF

2004/6/6 17:54.40 TCP syn 192.168.11.58:1481 -> 209.175.17.19:135 ttl=128 len=0 DF

2004/6/6 17:54.40 TCP syn 192.168.11.58:1482 -> 209.175.17.20:135 ttl=128 len=0 DF

2004/6/6 17:54.40 TCP syn 192.168.11.58:1483 -> 209.175.17.21:135 ttl=128 len=0 DF

2004/6/6 17:54.40 TCP syn 192.168.11.58:1484 -> 209.175.17.22:135 ttl=128 len=0 DF

2004/6/6 17:54.40 TCP syn 192.168.11.58:1485 -> 209.175.17.23:135 ttl=128 len=0 DF

2004/6/6 17:54.40 TCP syn 192.168.11.58:1486 -> 209.175.17.24:135 ttl=128 len=0 DF

2004/6/6 17:54.40 TCP syn 192.168.11.58:1487 -> 209.175.17.25:135 ttl=128 len=0 DF

2004/6/6 17:54.40 TCP syn 192.168.11.58:1488 -> 209.175.17.26:135 ttl=128 len=0 DF

2004/6/6 17:54.40 TCP syn 192.168.11.58:1489 -> 209.175.17.27:135 ttl=128 len=0 DF

2004/6/6 17:54.40 TCP syn 192.168.11.58:1490 -> 209.175.17.28:135 ttl=128 len=0 DF

2004/6/6 17:54.40 TCP syn 192.168.11.58:1491 -> 209.175.17.29:135 ttl=128 len=0 DF

2004/6/6 17:54.40 TCP syn 192.168.11.58:1492 -> 209.175.17.30:135 ttl=128 len=0 DF

2004/6/6 17:54.40 TCP syn 192.168.11.58:1493 -> 209.175.17.31:135 ttl=128 len=0 DF

2004/6/6 17:54.40 TCP syn 192.168.11.58:1494 -> 209.175.17.32:135 ttl=128 len=0 DF

2004/6/6 17:54.40 TCP syn 192.168.11.58:1495 -> 209.175.17.33:135 ttl=128 len=0 DF

2004/6/6 17:54.40 TCP syn 192.168.11.58:1496 -> 209.175.17.34:135 ttl=128 len=0 DF

2004/6/6 17:54.40 TCP syn 192.168.11.58:1497 -> 209.175.17.35:135 ttl=128 len=0 DF

2004/6/6 17:54.40 TCP syn 192.168.11.58:1498 -> 209.175.17.36:135 ttl=128 len=0 DF

Skanowane podsieci to: 219.175.16/24, 219.175.17/24, 193.211.222/24 i 193.211.222/24.

Port skanowania 135/tcp, port źródłowy jest cyklicznie inkrementowany przez oprogramowanieTCP/IP skanującego hosta.

65

Rysunek 7.1 skanowanie, statystyki portów przeznaczenia

Na wykresie wygenerowanym przez graphera port przeznaczenia 135 zajmuje czwartą pozycję naliście njaczęsciej występujących portów.

Nie znając konktretnego ataku bądź numeru portu wykorzystywanego przez atakujących, można zapomocą przechwytywania pakietów i ich analizy wyznaczyć konkretne źródło i sposób ataku.

7.9. Przechwytywanie haseł, protokół FTP

Monitorowanie i analiza ruchu ujawnia słabość wielu protokołów warstwy zastosowań. Ochronazasobów systemowych z wykorzystaniem autoryzacji w protokołach bez silnego wsparciakryptograficznego jest niemal iluzoryczna.

Fragment pliku wyjściowego sniffera obrazuje sesję FTP (File Transfer Protocol), w którejużytkownik podlega autoryzacji nazwą użytkownika i hasłem. Protokół jednak nie zapewniażadnego szyfrowania i całość danych jest przesyłana przez sieć w postaci tekstu ASCII.W przypadku przechwycenia hasła przez intruza narażony jest zarówno użytkownik jak i samserwer.

root@bzz:~/ifs-new# ./ifs -b 100 -r rules.conf


2004/6/9 07:50.01 TCP syn 213.227.72.4:46895 -> 213.77.21.150:21 ttl=64 len=0 DF




2004/6/9 07:50.01 TCP ack 213.227.72.4:46895 -> 213.77.21.150:21 ttl=64 len=0 DF

66



220 ProFTPD 1.2.9 Server (PirxNet FTP Server) [max]

2004/6/9 07:50.01 TCP ack 213.227.72.4:46895 -> 213.77.21.150:21 ttl=64 len=0 DF



USER jan

2004/6/9 07:50.08 TCP ack 213.77.21.150:21 -> 213.227.72.4:46895 ttl=64 len=0 DF



331 Password required for jan.

2004/6/9 07:50.08 TCP ack 213.227.72.4:46895 -> 213.77.21.150:21 ttl=64 len=0 DF



PASS cn7dl12

2004/6/9 07:50.19 TCP ack 213.77.21.150:21 -> 213.227.72.4:46895 ttl=64 len=0 DF



230 User jan logged in.

2004/6/9 07:50.19 TCP ack 213.227.72.4:46895 -> 213.77.21.150:21 ttl=64 len=0 DF


67

7.10. Wykresy graphera dla przykładowego ruchu sieciowego

Rysunek 7.2 grapher, zaobserwowane protokoły

Rysunek 7.3 grapher, statystyka pakietów TCP

68

Dominującą rolę pełnią dwa rodzaje pakietów. Wynika to z natury ruchu TCP, w którym przyjęciekażdego segmentu danych (PSH,ACK) jest potwierdzane przez stację odbierającą pustymsegmentem ACK. W związku z tym, że TCP jest protokołem połączeniowym, zaobserwowanychzostało dość dużo pakietów SYN, które inicjują połączenia. Zauważalny jest również udziałpakietów kończących (FIN,ACK) i resetujących połączenia (RST,ACK).

Rysunek 7.4 grapher, rodzaje komunikatów ICMP

Typowym zastosowaniem protokołu ICMP jest badanie dostepności hostów w sieci, w związkuz czym najczęściej wystepującymi typami komunikatów są żądania i odpowiedzi echa (programping).

Komunikaty ICMP pochodzące od ruterów, informujące o nieosiągalności hosta (destinationunreachable) zajmują trzecie miejsce na prezentowanym wykresie.

69

Rysunek 7.5 grapher, wielkości pakietów

W ruchu sieciowym, który obrazuje powyższy wykres, dominują puste pakiety. Wynika to z faktu,że najczęsciej występującym protokołem w tym ruchu jest TCP, w którym pakiety inicjujące,kończące połaczenia i potwierdzające przyjęcie każdego segmentu danych mają długość danychrówną 0. Poniższy rysunek wyszczególnia tylko pakiety TCP:

Rysunek 7.6 grapher, statystyka wielkości segmentów TCP

70

Rysunek 7.7 grapher, statystyka wielkości pakietów UDP

W przypadku protokołu UDP, w grupie najczęściej pojawiających się długości datagramów nie madługości zerowych. Najczęstszym zastosowaniem tego protokołu są zapytania DNS (Domain NameSystem), dzięki którym możliwa jest translacja trudnych w użyciu adresów IP na przyjazneużytkownikowi nazwy domenowe. Zapytania takie są niewielkie, na wykresie dominują datagramyo długości 18 bajtów.

Rysunek 7.8 grapher, najczęściej występujące adresy IP (przeznaczenia)

Bardzo przydatna statystyka, umożliwiająca ustalenie najbardziej aktywnych użytkowników (adresyIP) w sieci.

71

Rysunek 7.9 grapher, najczęściej występujące porty przeznaczenia (TCP)

Numery portów identyfikują aplikację w warstwie zastosowań, która obsługuje daną transmisję.Najczęściej używanym portem jest port 80, na którym odbywa się komunikacja z serweramiWWW. Znaczny udział ma również protokół transmisji plików FTP (porty: 21 i 20). Na porcie8080 zwykle uruchamiana jest usługa Proxy przyspieszająca działanie serwisów WWW. W związkuz szybkim rozwojem sieci P2P (peer to peer) można zaobserwowac zwiększony ruch na portachtych usług (np. 4662).

Statystyki najczęsciejwy korzystywanych portów są przydatne zwłaszcza w przypadku anomalióww działaniu sieci, takich jak ataki DoS. Dzięki takiemu zobrazowaniu ruchu sieciowego o wielełatwiej wykryć przyczynę i zablokować sprawcę przeciążenia.

72

7.11. Porównanie istniejących rozwiązań z wykonanym analizatorem

Sniffer/Grapher Tcpdump A Iptraf B Ethereal C

Rozmiar binariów 8,3 kB / 25 kB 407 kB 155 kB 4,9 MB

Wymaganabibliotekastandardowa libc

NIE/TAK TAK TAK TAK

Dodatkowebiblioteki NIE/TAK TAK TAK TAK

DodatkowebibliotekiokienkoweD

NIE NIE TAK NIE

DodatkowebibliotekigraficzneE

NIE NIE NIE TAK

Interfejs graficzny NIE NIE NIE TAK

Interfejsokienkowy NIE NIE TAK TAK

Zdalne logowanie TAK NIE NIE NIE

Filtry ruchu Podstawowe Rozbudowane Rozbudowane Rozbudowane

Językprogramowania

Asembler/Perl,PHP C C C, C++

Przenośność F NIE/TAK TAK TAK TAK

Rozdzieleniezadań pomiędzyruter i serwer

TAK NIE NIE NIE

Statystyki,wykresy

TAK NIE TAK TAK

A – tcpdump version 3.7.2, libpcap version 0.7.2

B – IPTraf Version 2.7.0

C – ethereal 0.9.11, with GTK+ 2.2.1, with GLib 2.2.1, with libpcap 0.7.2, with libz 1.1.4

D – biblioteki do tworzenia interfejsów okienkowych Ncurses

E – biblioteki interfejsu graficznego stacji roboczej X serwera

F – możliwość zastosowania na różnych platformach sprzętowych i programowych

Wszytkie powyższe wersje programów pochodzą z dystrybucji Slackaware Linux 9.0.

Szybkość działania aplikacji nie została formalnie sklasyfikowana w tabeli ze względu natrudności w określeniu zakresu badanych czynności, jednak samo przechwytywanie pakietów z sieciprzez porównywane aplikacje odbywa się ze zbliżoną prędkością, tak jak pozwala na to jądrosystemu operacyjnego.

73

8. Podsumowanie

Powstanie projektu analizatora sieciowego było spowodowane koniecznością realizacjizadań monitorowania i diagnozowania ruchu w sieciach IP w określonym środowisku sprzętowymi programowym. Istnieją kompleksowe aplikacje tego typu, posiadające bardzo rozbudowanefunkcje, jednak wymagają one także bogatych konfiguracji sprzętowych.

W związku ze specyficznymi wymaganiami sprzętowymi oraz dążeniem Autora pracy do głębszegopoznania mechanizmów sieciowych jądra systemu operacyjnego, do jego budowy użyty został dośćrzadko ostatnio wykorzystywany język asemblera. Wynikiem tego był dość wolny postępw pracach, gdyż implementacja algorytmów w tym języku wymaga dużego zaangażowania zestrony programisty i jest bardzo pracochłonna. Funkcje analizy i prezentacji wyników napisanezostały w uniwersalnych i ogólnodostępnych językach skryptowych. Analizator jako całość jestdzięki temu bardzo małą aplikacją, gotową do użycia na niemal każdej stacji sieciowejobsługiwanej przez system Linux. W prostym porównaniu do istniejących programów możnapowiedzieć, że jest on aplikacją mikroskopijną. Jest to jednak okupione znacznie uboższymzestawem funkcji, zwłaszcza filtrowania ruchu, identyfikacji protokołów sieciowych wyższychwarstw i innych rodzin, szczegółowej prezentacji wszystkich najdrobniejszych informacji zawartychw nagłówkach oraz danych. Zaletami mogą być prostota w użyciu, szybkość i łatwość instalacjii użycia w niemal dowolnych warunkach, możliwość zdalnego logowania, a także niezależnejzdalnej prezentacji zaobserwowanego ruchu.

Mimo wielu niedoskonałości i ograniczeń wykonanego analizatora, może on być i jestwykorzystywany przez Autora pracy do zadań związanych z bieżącą administracją sieci. Realizacjaprojektu, poza umożliwieniem i ułatwieniem monitorowania sieci w jej najodleglejszych miejscach,również przyczyniła się znacznie do poszerzenia wiedzy Autora w omawianej w pracy dziedzinieteleinformatyki.

Projekt analizatora w celu łatwego pobrania źródeł oraz dodatkowych informacji zostałumieszczony w serwisie SourceForge pod adresem: http://analizator.sourceforge.net oraz nastronie: http://analizator.digi.pl

74

9. Bibliografia

[1] http://www.iso.org/iso/en/aboutiso/introduction/index.html#two

[2] http://www.ussg.iu.edu/usail/network/nfs/network_layers.html

[3] http://www.defenselink.mil

[4] http://www.rfc.net/rfc791.html

[5] http://www.rfc.net/rfc791.html#p11


[7] http://www.rfc.net/rfc793.html#p15




[11] http://www.tcpdump.org

[12] http://cebu.mozcom.com/riker/iptraf/

[13] http://www.ethereal.com

[14] http://www.gtk.org

[15] http://www.x.org/X11.html

[16] http://www.gnu.org/software/binutils/


[18] http://www.libpng.org/pub/png/pngintro.html

[19] http://www.perl.org/about.html

[20] http://pl.php.net/manual/pl/faq.general.php

[21] http://www.boutell.com/gd/manual2.0.26.html#whatis

[22] "UNIX programowanie usług sieciowych" Richard Stevens, WNT Warszawa 2000

[23] "Linux kernel, jądro systemu" M.Beck, H.Böhme, M.Dziadzka, U. Kunitz,R.Magnus, D.Verworner, Mikom

[24] "Turbo Assembler biblia użytkownika" Gary Syck, Oficyna Wydawnicza LT&P

75

[25] "Using 'as', The GNU Assembler, January 1994, Dean Elsner, Jay Fenlason& friends

[26] "PHP4 Podręcznik programisty" Sterling Huges, Helion 2002

[27] "Perl dla każdego" Laura Lemay, Helion 2000

[28] http://www.rfc.net

76

Praca Dyplomowa (Inżynierska) - SourceForgeanalizator.sourceforge.net/ifs-doc.pdf · Praca...

Documents

Transcript of Praca Dyplomowa (Inżynierska) - SourceForgeanalizator.sourceforge.net/ifs-doc.pdf · Praca...