Praca Dyplomowa (Inżynierska)

Transkrypt

1 Politechnika Śląska Wydział 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

2 Spis treści Wstęp Zasady działania sieci IP i jej zastosowania Protokół IP Protokół TCP Protokół UDP Protokół ICMP Istniejące rozwiązania monitorowania ruchu i ich porównanie tcpdump iptraf ethereal Założenia dotyczące budowy analizatora Wybór narzędzi i języków programowania sniffer asembler grapher, Perl, PHP Specyfikacja wewnętrzna oraz fragmenty procedur sniffer grapher Specyfikacja zewnętrzna (użytkownika) sniffer grapher Testowanie i przykładowe wyniki działania oprogramowania Ping (icmp) Traceroute (icmp) Nawiązywanie połączenia TCP Transmisja w strumienu TCP Zakończenie połączenia TCP Ataki odmowy usługi i skanowanie Przechwytywanie haseł, protokół FTP Wykresy graphera dla przykładowego ruchu sieciowego Porównanie istniejących rozwiązań z wykonanym analizatorem Podsumowanie Bibliografia

3 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ątych wszedł w etap dynamicznego rozwoju. Sieć zbudowana w oparciu o połączenie wielu sieci z wykorzystaniem rodziny protokołów TCP/IP, nazwana Internetem, połączyła wiele krajów, w tym również Polskę. Początkowo militarne wykorzystanie sieci zostało poszerzone o zastosowania naukowe oraz komercyjne, co spowodowało zwiększenie popularności tej formy komunikacji i jej błyskawiczny rozwój. Wraz z rozszerzaniem zasięgu i przepustowości sieci oraz zwiększaniem ilości podłączonych do niej komuputerów, pojawiły się nieprzewidywane wcześniej anomalia w jej funkcjonowaniu. Zarządzanie Internetem jest rozproszone i odpowiedzialność za poprawną pracę poszczególnych jego części ponoszą różne organizacje i firmy. Osoby zajmujące się utrzymywaniem ruchu w tych organizacjach muszą być wyposażone w odpowiedni zestaw narzędzi umożliwiających monitorowanie ruchu i diagnozowanie przyczyn potencjalnych awarii. Autor pracy zajmuje się zawodowo administracją sieci szkieletowej jednego z lokalnych Dostawców Usług Internetowych (Internet Service Provider). Na codzień rozwiązuje złożone problemy konfiguracji i utrzymania sieci, w czym niezbędną pomocą okazuje się właściwe oprogramowanie. 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 najmniejsze wymagania sprzętowe i prostotę użycia w dowolnych warunkach. Mimo iż tworzone oprogramowanie nie posiada nazbyt rozbudowanych funkcji, może stać się ono bardzo przydatnym i efektywnym narzędziem w codziennej pracy administracyjnej. Pierwszy rozdział pracy stanowi teoretyczny wstęp do zagadnienia transmisji danych miedzy komputerami poprzez sieć IP. Przedstawione są modele budowy sieci oraz różnice pomiędzy nimi wynikające z potrzeby ich praktycznego zastosowania w konkretnej architekturze. Jednym z najistotniejszych elementów architektury sieciowej jest ścisłe określenie sposobu przesyłania danych. W przypadku Internetu sposób ten opisuje rodzina protokołów TCP/IP. Opisane zostały popularne programy sieciowe użytkownika, wykorzystujące poszczególne protokoły do komunikacji z innnymi hostami. Rozdział drugi opisuje trzy najczęściej wykorzystywane w sytemie Linux programy monitorujące ruch 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 analizatora ruchu sieciowego. Koncepcja architektury oprogramowania, dzieląca je na kilka części, ma umożliwić jak najlepszą realizację założeń. Rozdział ten opisuje poszczególne fragmenty analizatora, 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 budowy programu od strony programistycznej. Wyróżnione są funkcje realizujące ważniejsze zadania oraz 3

4 kluczowe struktury danych. Treść tego rozdziału prezentuje tylko poglądowy schemat, gdyż do peł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 potencjalnego użytkownika aplikacji. Przedstawione są w nim sposoby uruchamiania programów, szczegółowy opis dostępnych funkcji, opisy formatów danych wyjściowych. Szczegółowy opis specyfikacji zewnę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ęści teoretycznej. Dzięki zastosowaniu analizatora można przyjrzeć się zasadom ich działania w rzeczywistym ruchu sieciowym. Rozdział zawiera również proste porównanie zbudowanego analizatora z przedstawionymi wcześniej sprawdzonymi rozwiązaniami oraz konfrontację założeń projektu z jego praktyczną realizacją. 4

5 1. Zasady działania sieci IP i jej zastosowania Najczęściej stosowanym sposobem przedstawienia współdziałania poszczególnych części sprzętu i oprogramowania sieciowego jak również samych protokołów transmisji oraz ich wzajemnego powiązania jest model warstwowy ISO/OSI. Przyjęty jako norma przez Międzynarodową Orgranizację Normalizacyjną ISO[1] bardzo szczegółowy model opisuje działanie sieci 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 fizycznym medium. Brak kontroli ciągłości transmisji powoduje, że w przypadku problemów z dostępem do medium 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ów w sieci. Zapewnia przekazywanie pakietów przez rutery tak, aby pakiet dotarł od nadawcy do odbiorcy. warstwa transportowa umożliwia przesyłanie danych kanałem stworzonym przez warstwę sieciową, przy czym zapenia poprawność i pewność transmisji. W warstwie tej prowadzona jest kontrola poprawności otrzymanych segmentów, ich kolejności, a w przypadku błędów retransmisja zagubionych danych. warstwa sesji umożliwia nawiązywanie i zrywanie połączeń przez aplikacje. 5

6 warstwa prezentacji w warstwie tej przepływające dane są poddawane kontroli poprawnoś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 ekranie monitora strony WWW. W większości przypadków powyższy model jest nazbyt szczegółowy wobec czego przez Departament 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 do sieci. Można przyjąć, że sprzęt w postaci karty sieciowej oraz oprogramowanie obsługujące ten sprzęt czyli tak zwany sterownik jest dostarczany przez producenta. W warstwie tej wykonywana jest adresacja (MAC Medium Access Control) umożliwiająca jednoznaczną identyfikację stacji sieciowej w segmencie sieciowym, przy czym adresy są przypisywane urządzeniom w procesie produkcyjnym. Przykładowe protokoły tej warstwy to Ethernet, Decnet, FrameRelay. Warstwa sieciowa w modelu DoD nazwana została warstwą internetową. Zadaniem protokołów tej 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 zawartym w 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

7 do adresata. Najczęściej stosowanym protokołem tej warstwy jest IPv4. Efektem ubocznym bardzo szybkiego 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 warstwie nazywana 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 jest numerowany, a odebranie danych przez warstwę transportową stacji odbierającej jest potwierdzane nadawcy. Następnie odbiorca kompletuje dane według kolejności ich nadawania. Protokoły tej warstwy korzystają z usług protokołu IP, natomiast nagłówek warstwy transportowej zawiera informacje 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ę trzy gó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 oprogramowaniu korzystającym z zasobów. Gdy mamy do czynienia ze stacją sieciową w sieci IP, należy mieć świadomość, że korzystanie z oprogramowania użytkowego (warstwa aplikacji) wiąże się z koniecznością przepływu informacji przez wszystkie warstwy modelu TCP/IP. W ten sposób dane aplikacji klienta np. protokołu SMTP są 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 transmitowane do fizycznego medium. W systemie odbiorcy dane przebywają podobną drogę przez wszystkie warstwy lecz w przeciwnym kierunku. Uniwersalność tego rozwiązania umożliwia jednoczesną komunikację w dwóch kierunkach. Rysunek 1.3 Transmisja danych przez sieć 7

8 1.1. Protokół IP Protokół IP[4] (Internet Protocol) funkcjonuje powyżej warswy kanałowej. Protokół ten niesie informacje niezbędne do zaadresowania pakietów w sieci TCP/IP. Na podstawie informacji zawartych w nagółówku tego protokołu rutery określają, którą drogą wysłać pakiet, aby trafił on do stacji przeznaczenia. Protokół umożliwia też fragmentację pakietów oraz ustawienie dodatkowych opcji. 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 IPv4 wynosi 20 bajtów (pięć 32-bitowych słów), a maksymalną wielkością tego pola jest 15, więc moż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żna okreś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 pola wielkości nagłówka. identification 16 bitowe pole identyfikacji pakietu umożliwia łączenie pofragmentowanych pakietó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

9 fragment offset pole 13 bitowe w połaczeniu z flagami fragmentacji używane do fragmentacji i ponownego łączenia pofragmentowanych pakietów. time to live pole 8 bitowe oznaczające czas życia pakietu. Pakiet IP przenoszony jest w sieci przez rutery. Przy każdym przesłaniu pakietu przez ruter pole to jest zmiejszane o 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 liczbie przeskoków osiągnąć stacji przeznaczenia. protocol pole 8 bitowe określa rodzaj danych w pakiecie, zwykle jest to numer protokołu taki jak: 1 (ICMP), 2 (IGMP), 6 (TCP), 17 (UDP). header checksum 16 bitowe pole sumy kontrolnej, która jest obliczana z całego nagłó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 rutery okreś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żeniu przełączania pakietów. Dane przesyłane są pomiędzy dwoma punktami sieci, od źródła do przeznaczenia, 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 adresu IP przeznaczenia. Trasa przesyłu nie musi być zawsze taka sama i może prowadzić przez wiele sieci tranzytowych. W każdej sieci określona jest maksymalna wielkość jednorazowo przesyłanego pakietu danych (MTU Maximum Transfer Unit), która zależy od rodzaju medium i protokołu warstwy łącza. Naturalnym więc zjawiskiem jest sąsiedztwo sieci o różnych dopuszczalnych wielkościach przesyłanych pakietów. Na styku dwóch takich sieci konieczne jest wykonywanie dodatkowych operacji przez ruter, mających na celu podzielenie większych pakietów jednej sieci na mniejsze, odpowiednie dla drugiej sieci styku. Proces ten nazywa się fragmentowaniem i jest możliwy dzięki umieszczeniu w nagłówku protokołu IP dwóch odpowiednich pół. Jedno z tych pól przechowuje 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óre zachowuje informację o miejscach podziału oryginalnego pakietu, dzięki czemu umożliwia stacji odbierającej poprawną defragmentację, czyli złożenie pofragmentowanych danych w odpowiedniej kolejności w pierwotną całość. Z usług protokołu IP w znacznej większości korzystają protokoły wyższej warstwy - warstwy transportowej - takie jak TCP i UDP. Poza tym również ICMP, definiowany jako protokół warstwy internetowej, 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 stacjach sieciowych zapisuje ich specyficzny numer w nagłówku protokołu IP. Dzięki temu możliwe jest ustalenie rodzaju zawartości pakietu bez konieczności rozpakowywania jego danych, co umożliwia np. szybkie filtrowanie. Datagram IP może zawierać dodatkowe opcje, choć w większości przypadków nie są one wymagane. 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 wymuszenia specyficznego rutingu. 9

10 1.2. Protokół TCP TCP[6] (Transmission Control Protocol) funkcjonuje powyżej warstwy internetowej, co oznacza, że nagłówek jak i pakiet TCP jest enkapsulowany przez niższą warstwę, w tym przypadku IP. Jest to protokół połączeniowy i transmisja danych wymaga ustabilizowania połączenia między hostami nadawcy i odbiorcy. Analogią działania protokołu TCP może być rozmowa telefoniczna. Konieczne jest podniesienie słuchawki przez osobę inicjującą rozmowę, wybranie numeru, podniesienie słuchawki przez odbiorcę połączenienia. Dopiero wtedy można przesyłać dane, a w tym kontekście prowadzić rozmowę. Protokół TCP posiada wszystkie te cechy, a dodatkowo mechanizmy potwierdzeń, sterowania transmisją oraz kontroli szybkości przesyłania danych. W przypadku ustabilizowanego połączenia TCP można mówić o transmisji danych pewnym, w pełni dwukierunkowym 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ż jednoznacznie okreś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 znanych usług, dlatego zwykle aplikacje klienckie wykonujące połączenia inicjują pole port źródłowy wielkością spoza tego zakresu. sequence number 32 bitowe pole numeru sekwencji określa jednoznacznie numer segmentu i jego przynależność do konkretnego połączenia. Jest wykorzystywane przy nawiązywaniu połączenia TCP oraz do określenia kolejności segmentów w strumieniu. acknowledgment number 32 bitowe pole potwierdzeń, wykorzystywane w połączeniu z numerem sekwencji przy kompletowaniu segmentów. offset 4 bitowe pole przesunięcia. reserved 4 bity zarezerwowane. 10

11 flags 8 bitowe pole flag. Ustawienie właściwych flag określa rodzaj i rolę segmentu TCP 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 sterowanie szybkoś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 stacja odbierająca dane wysyła potwierdzenia ustawiając to pole według własnych możliwości odbioru danych (odpowiednio zmniejsza w przypadku niemożności odbierania danych np. przepełnienia buforó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 przerywanie tych połączeń. Implementacje protokołu opierają się o automat stanów skończonych, opisujący wszystkie 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 stacjach sieciowych połączenia, w momencie otrzymywania bądź wysyłania segmentów TCP oznaczonych odpowiednimi 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) lub CLOSED->SYN_SENT (system klienta), wymusza system operacyjny stacji sieciowej. Najczęściej wykorzystywane sekwencje stanów to typowe przejścia CLOSED->ESTABLISHED->CLOSED, czyli nawiązanie połączenia, przesłanie danych i zakończenie połączenia. 11

12 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 stacja sieciowa (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 losowo wybrany numer sekwencyjny (pole sequence number nagłówka TCP), który zwiększony o jeden przez stację akceptującą połączenie stanowi numer potwierdzenia (pole acknowledgment number nagłówka TCP). Tak uzyskany numer potwierdzenia umieszczony w nagłówku wraz z losowo wygrenerowanym przez stację serwera własnym numerem sekwencyjnym, jest przesyłany do stacji inicjują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 wykorzystaniem segmentów PSH, potwierdzanych przez stację odbierającą za pomocą ACK. W trakcie transmisji istnieje konieczność sterowania natężeniem przepływu danych, w przypadku przepełnienia buforów bądź przeciążenia jednej ze stacji połączenia. Sterowanie to jest możliwe dzięki dodatkowemu polu protokoł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 ma miejsce wymiana czterech segmentów: Klient stan ESTABLISHED wysłany segment FIN+ACK pośredni stan FIN_WAIT1 odebrany segment ACK pośredni stan FIN_WAIT2 odebrany segment FIN+ACK pośredni stan TIME_WAIT wysłany segment ACK pośredni stan TIME_WAIT stan CLOSED Serwer stan ESTABLISHED odebrany segment FIN+ACK pośredni stan CLOSE_WAIT wysłany segment ACK wysłany segment FIN+ACK pośredni stan LAST_ACK odebrany segment ACK stan CLOSED 12

13 1.3. Protokół UDP UDP[8] (User Datagram Protocol) również jest protokołem działającym w trzeciej warstwie modelu TCP/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łany pakiet UDP zostanie doręczony, gdyż nie posiada on mechanizmów potwierdzeń odebranych informacji. Analogią dla tego protokołu może być system pocztowy, w którym nadawca wrzuca list do 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 do protokołu TCP numery portów określają, która aplikacja w warstwie zastosowań (aplikacji) jest odpowiedizalna 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 Name System). System ten umożliwia zamianę trudnych do zapamiętania adresów IP na wygodne w użyciu nazwy domenowe, składające się z kilku członów. Baza nazw jest rozproszona i zarządzana przez wiele organizacji, z których każda odpowiedzialna jest za określone poddomeny domen 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 tym najwygodniejsze jest wykorzystanie protokołu bezpołączeniowego jakim jest UDP. Podczas transmisji dźwięku w sieci IP nie mają większego znaczenia pojedyncze straty datagramów, a użycie połączeniowego protokołu TCP, wymagającego potwierdzeń i retransmisji mogł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 straty datagramów nie są czynnikiem krytycznym, wykorzystywany jest protokół UDP. 13

14 1.4. Protokół ICMP Protokół ICMP[10] (Internet Control Message Protocol) spełnia bardzo ważną funkcję nie ze wzgędu na transmisję danych użytkownika, lecz właściwe współdziałanie innych protokołów. Jak nazwa wskazuje, protokół ten umożliwia przesyłanie komunikatów kontrolnych miedzy stacjami sieci 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 echo response, 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 wraz z 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 precyzyjnej informacji 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 hostami w sieci. Sprawdzenie to polega na wysłaniu przez stację źródłową tzw. pakietu żądania echa (echo request), na które to żądanie poprawnie skonfigurowany host w sieci IP jest zobowiązany odpowiedzieć stacji źródłowej pakietem odpowiedzi (echo reply). Przy wykorzystaniu określonego szeregu pakietów echa można ustalić zarówno średni czas transmisji pakietu pomiędzy dwoma stacjami w sieci, jak również jakość połączenia mierzoną w procentowej ilości utraconych pakietów (takich, dla których nie dotarła odpowiedź z hosta docelowego). Kolejny często używany typ komunikatu destination unreachable odpowiedzialny jest za informowanie o niedostępności hosta. Komunikat ten jest wysłany do stacji źródłowej przez ostatni na 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 innymi programów śledzenia trasy pakietu IP w sieci, tak zwanych programów typu traceroute. Cyklicznie wysył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 odebrania komunikatu o niedostepności hosta przeznaczenia ustalenie miejsca przerwania trasy. 14

15 2. Istniejące rozwiązania monitorowania ruchu i ich porównanie System operacyjny Linux został zaprojektowany jako wielodostępny i wielozadaniowy, ale również, co okazało bardzo waże dla jego błyskawicznego rozwoju, jako system sieciowy. Wobec czego zasób oprogramowania sieciowego zarówno w samym jądrze systemu jak i w przestrzeni programów użytkowych jest bardzo duży. W zakresie oprogramowania monitorującego ruch sieciowy można wyróżnić conajmniej kilka aplikacji. 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 zakresie obserwowanego bądź interpretowanego przez te programy ruchu oraz sposobie prezentacji danych tcpdump Najpopularniejszym i najczęściej dołączanym do dystrybucji systemu operacyjnego Linux programem umożliwiającym monitorowanie ruchu sieciowego jest tcpdump[11]. Ze względu na stosunkowo niewielkie wymagania stał się on jednym z podstawowych narzędzi wykorzystywanych przez administratorów serwerów i ruterów sieciowych na platformie Linux. Program rozpoznaje wiele 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 wpisanie w 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 by uzyskać nazwy domenowe dla przechwyconych adresów IP. Poza pewnym ograniczonym zestawem opcji, tcpdump posiada wbudowany interpreter pewnego pseudo 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, że przechwytywanie go w całości byłoby niemożliwe ze względu na ograniczoną moc procesora jak również pojemność dysku: root@ck-gw:~# tcpdump -i eth1 -n -e tcp and host port 135 w ten sposób przechwycony ruch będzie zawierał pakiety należące do protokołu TCP, kierowane do i z adresu , 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ów protokołół warstwy dostępu do sieci, np. ethernet. Twórcy programu tcpdump poszli o krok dalej i umożliwili użytkownikowi porównywanie dowolnego bajtu w zidentyfikowanym nagłówku protokołu. Dzięki tej opcji użytkownik ma niemal nieograniczone możliwości dopasowania właściwego pakietu. root@ck-gw:~# tcpdump -i eth0 -n 'ip[9] == 17' 15

16 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 tym konkretnym przypadku numer protokołu wyższej warstwy. Zostaną więc wyświetlone tylko pakiety protokołu UDP. Tcpdump cechuje sposób wyświetlania przechwyconych i zinterpretowanych danych. Informacje o każdym pakiecie, który przeszedł przez filtry użytkownika są wyświetlane w postacji jednego wiersza. Format tego wiersza jest zależny od rodzaju protokołu. Wspólnym elementem jest zawsze dokł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 jak numery portów, flagi wielkość pakietu i wiele innych. Wyjście programu tcpdump jest dość rozbudowane, czasem do tego stopnia, że posiada część poprawnie zinterpretowanych informacji warstwy aplikacji takich jak np. rodzaj zapytania DNS. Przykładowy output programu tcpdump: 11:28: > : AAAA? ludwik.digi.pl. (32) (DF) 11:28: > : 34271* 0/1/0 (91) (DF) 11:28: > : AAAA? ludwik.gl.digi.pl. (35) (DF) 11:28: > : NXDomain* 0/1/0 (94) (DF) 11:28: > : A? ludwik.digi.pl. (32) (DF) 11:28: > : 43416* 1/3/3 A (171) (DF) prezentuje zapytanie DNS wykonane z hosta do serwera nazw o adresie na 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 (NXDomain Non Existent Domain). Drugie zapytanie kończy się sukcesem i klientowi odesłany zostaje rekord A zawierający adres Na kolejnym fragmencie wyjścia tcpdumpmożna zaobserwować nawiązanie połączenia do usługi zdalnej administracji serwerem na porcie 22/tcp. 11:28: > : S : (0) win 5840 <mss 1460,sackOK,timestamp ,nop,wscale 0> (DF) 11:28: > : S : (0) ack win 5792 <mss 1460,sackOK,timestamp ,nop,wscale 0> (DF) 11:28: > :. ack 1 win 5840 <nop,nop,timestamp > (DF) 11:28: > : P 1:26(25) ack 1 win 5792 <nop,nop,timestamp > (DF) 11:28: > :. ack 26 win 5840 <nop,nop,timestamp > (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ści w interpretacji informacji. Tcpdump do przechwytywania danych z warstwy kanałowej (dostępu do sieci) używa popularnej w systemie Linux biblioteki libpcap[8]. Poza tą biblioteką wymaga wielu funkcji standardowej biblioteki libc, która może zostać wkompilowana statycznie w binaria lub ładowana dynamicznie podczas uruchamiania programu. 16