Steganografia w sieciach IP

SAMODZIELNY ZAKŁAD SIECI KOMPUTEROWYCH POLITECHNIKA ŁÓDZKA 90-924 Łódź ul. Stefanowskiego 18/22 tel./fax. (42) 636 03 00 e-mail: szsk@zsk.p.lodz.pl Filip Pacholczyk Steganografia w sieciach IP praca magisterska Promotor: dr inż. Michał Morawski Dyplomant: Filip Pacholczyk nr albumu 93642 Łódź, czerwiec 2003

Spis treści Wstęp Cel i zakres pracy Używane skróty Konwencje typograficzne i oznaczenia iii iv vi vii 1 Podstawowe wiadomości 1 1.1 Steganografia................................. 1 1.1.1 Rys historyczny............................ 1 1.1.2 Definicje................................ 2 1.2 Steganografia w sieciach komputerowych.................. 3 1.3 Modele ISO/OSI i czterowarstwowy model TCP/IP............ 3 1.4 Zestaw protokołów TCP/IP......................... 6 1.4.1 Protokół IPv4............................. 6 1.4.2 Protokół TCP............................. 13 1.5 Automorfizm toroidalny........................... 18 2 Opis bibliotek i narzędzi 21 2.1 Linux 2.4 i netfilter.............................. 22 2.1.1 Ogólna charakterystyka netfilter................... 22 2.1.2 Architektura netfilter......................... 23 2.1.3 iptables................................ 25 2.1.4 Wnioski................................ 26 2.2 Biblioteka libipq i mechanizm kolejkowania................. 27 2.2.1 Kolejkowanie pakietów........................ 28 2.2.2 Biblioteka libipq........................... 29 3 Wykorzystanie sieci TCP/IP dla steganografii 30 3.1 Identyfikacja ukrytych kanałów....................... 31 i

3.1.1 Protokół IP.............................. 31 3.1.2 Protokół TCP............................. 35 3.2 Ukryte kanały wykorzystane w implementacji............... 37 3.2.1 Kodowanie danych.......................... 38 3.2.2 Pole identyfikacji w nagłówku IP.................. 39 3.2.3 Wskaźnik ważności w nagłówku TCP................ 39 4 Implementacja programowa 41 4.1 Informacje ogólne i budowa programu.................... 41 4.1.1 Zasada działania i składowe..................... 41 4.1.2 Nadajnik................................ 48 4.1.3 Odbiornik............................... 55 4.2 Instalacja programu.............................. 60 4.2.1 Wymagania sprzętowe i programowe................ 60 4.2.2 Kompilowanie programu....................... 61 4.2.3 Konfiguracja.............................. 62 4.3 Użytkowanie programu i przykłady działania................ 63 4.3.1 Nadajnik................................ 63 4.3.2 Odbiornik............................... 63 4.3.3 Ukrywanie danych w nagłówku datagramu IP........... 63 4.3.4 Ukrywanie danych w nagłówku segmentu TCP........... 70 Zakończenie 74 Literatura 76 A Opis funkcji bibliotecznych biblioteki libipq 79 B Opis zawartości płyty CD 82 Spis rysunków 83 ii

Wstęp Współczesny świat daleki jest od doskonałości. Często zdarza się, że posiadamy jakieś istotne dane, które mogą wzbudzać zainteresowanie ze strony osób, firm, instytucji, które nie są upoważnione do dostępu do tych informacji. Dane przechowywane i przesyłane są narażone na przechwycenie i odczytanie, co jest niepożądane, a może być wręcz groźne (ze względów bezpieczeństwa, finansowych itp.). Aby uchronić swoje dane i uniemożliwić ich odczyt przez niepowołane osoby, stosuje się techniki kryptograficzne. Odpowiednio silne algorytmy szyfrowania dają gwarancję praktycznej niemożności złamania i odczytania chronionych danych bez znajomości klucza, a zatem zapewniają bezpieczeństwo. Z wymienionych wyżej powodów przydatna byłaby technika umożliwiająca, oprócz zaszyfrowania danych, ukrycie tego faktu przed osobami postronnymi. Jeśli nie da się ukryć tego, że przesyła się jakieś dane, to może chociaż zrobić coś, by wyglądały niewinnie? Taka technika istnieje i nosi nazwę steganografii. Dynamiczny rozwój sieci komputerowych, i jednoczesne z nim mnożenie się liczby nadużyć i przestępstw, wymusza tworzenie coraz lepszych i bardziej wyrafinowanych zabezpieczeń sieciowych. Wszelkie podmioty, dla których dostęp do sieci globalnej jest niezbędny, muszą dla chronienia swoich systemów i danych odgradzać się od Internetu instalacjami firewall, proxy itp. Chcą w ten sposób mieć pewność, że żaden niepożądany ruch nie wyjdzie ani nie wejdzie do sieci wewnętrznej. Tutaj tworzy się wyzwanie dla steganografii: jak w dozwolonym, niewinnym ruchu sieciowym (takim jak transmisja HTTP z ogólnodostępnych serwerów WWW, na przykład popularnych portali) zaszyć dane, które nie powinny się dostać do wnętrza sieci? Jak z wnętrza takiej chronionej sieci wysłać w świat dane, jeśli wszelkie możliwości wysyłania danych zostały przez administratorów zablokowane? Niniejsza praca stanowi próbę udzielenia odpowiedzi na powyższe pytania. Przedstawiono w niej analizę zagadnienia steganografii w powiązaniu z sieciami komputerowymi, w szczególności sieciami TCP/IP, jako najpopularniejszymi obecnie. Przemyślenia i wnioski przedstawione w pracy mają zastosowanie zarówno w odniesieniu do lokalnych sieci TCP/IP, jak i sieci globalnej Internetu. iii

Cel i zakres pracy Głównym celem niniejszej pracy jest przedstawienie pojęcia steganografii i zapoznanie ze steganografią jako dziedziną wiedzy oraz analiza możliwości wykorzystania komputerowych sieci opartych o protokoły TCP/IP do przeprowadzania transmisji steganograficznych. Przedmiotem pracy jest zidentyfikowanie ukrytych kanałów komunikacyjnych, potencjalnie obecnych w nagłówkach pakietów tworzonych przez protokoły IP i TCP, oraz określenie stopnia ich przydatności do transmisji. Dodatkowo przeprowadzona zostanie analiza odporności takich transmisji na wykrycie i przerwanie. Praca składa się z dwóch części: teoretycznej i praktycznej. Część teoretyczna, obejmuje pierwsze trzy rozdziały i stanowi wprowadzenie do części praktycznej, której przedmiotem jest implementacja programowa wybranych metod ukrywania danych w transmisji sieciowej. Przedstawiony program StegoIP wykorzystuje dwa ukryte kanały, spośród opisanych w części teoretycznej. Jego głównym i najistotniejszym założeniem jest brak generowania własnego ruchu sieciowego w celu przesłania komunikatu polega on całkowicie na użytkowniku, mającym zapewnić istnienie wystarczającej ilości ruchu TCP/IP w sieci. Rozdział pierwszy omawia podstawowe pojęcia związane ze steganografią i przedstawia krótką historię tej dziedziny nauki. W jego dalszej części znajduje się wprowadzenie do zagadnień związanych z sieciami komputerowymi opartymi o zestaw protokołów TCP/IP omówienie najważniejszych cech tych dwóch protokołów oraz przedstawienie budowy definiowanych przez nie jednostek transportowych. Rozdział drugi opisuje narzędzia wykorzystane podczas tworzenia programu, stanowiącego część praktyczną. Znajduje się w nim omówienie głównych i najważniejszych dla implementacji cech systemu Linux i obecnego w jego nim podsystemu wyboru i filtrowania pakietów o nazwie netfilter. Rozdział trzeci stanowi dyskusję na temat możliwości wykorzystania nagłówków datagramów IP oraz segmentów TCP do trasmisji danych steganograficznych. Została w nim zawarta szczegółowa analiza budowy i właściwości tych pól nagłówków, które pozwalają utworzyć ukryte kanały. Rozdział czwarty jest prezentacją budowy i działania programu StegoIP. Zamieszczono w nim opis założeń wedle których pracuje program i głównych koncepcji projektoiv

wych. Przedstawiono schematy blokowe najważniejszych funkcji wraz z omówieniem ich działania. Rozdział ten omawia ponadto sposób przygotowania systemu operacyjnego, w którym pracować ma program StegoIP, a także kroki niezbędne do skompilowania i skonfigurowania programu. Na końcu rozdziału czwartego zamieszczono dwa przykłady działania programu StegoIP wraz z omówieniem wyników. W zakończeniu podano najważniejsze wnioski, płynące z analizy protokołów TCP/IP pod kątem wykorzystana ich w steganografii oraz z implementacji programowej przedstawionej w pracy. Wskazano na trudności, której pojawiły się w trakcie tworzenia programu StegoIP, a także dalsze możliwości rozwoju technik steganograficznych związanych z sieciami komputerowymi. Treść pracy w postaci dokumentu PDF oraz wszelkie materiały elektroniczne w niej cytowane zamieszczone zostały na dołączonej płycie CD. Szczegółowe omówienie zawartości płyty zawiera dodatek B. v

Używane skróty API DARPA DNAT ICMP IP ISO MTU NAT OSI PDF RFC SNAT TCP UDP Application Program Interface Defence Advanced Research Projects Agency Destination Address Network Address Translation Internet Control Message Protocol Internet Protocol International Standards Organization Maximum Transmission Unit Network Address Translation Open Systems Interconnect Portable Document Format Request for Comments (nieoficjalne źródła standardów sieciowych) Source Address Network Address Translation Transmission Control Protocol User Datagram Protocol vi

Konwencje typograficzne i oznaczenia W pracy przyjęto następujące konwencje typograficzne: iptables queueing odbiorca nadajnik słowa kluczowe, skróty i nazwy mechanizmów programowych występujące po raz pierwszy; słowa obcojęzyczne; zmienne, stałe, nazwy plików, wpisywane polecenia i wyświetlane komunikaty, fragmenty kodu źródłowego i plików; elementy programu StegoIP W przedstawionych schematach blokowych funkcji przyjęto następujące oznaczenia elementów algorytmu: START KONIEC Początek i koniec algorytmu (programu lub funkcji) utworzenie uchwytu ipq Proces wykonanie jednej lub kilku instrukcji. odczyt parametrów wywołania Odczyt lub zapis danych, operacje wejścia/wyjścia. vii

czy to pakiet IP? NIE TAK Instrukcja warunkowa (sprawdzanie warunku). oczekiwanie na połączenie Proces zewnętrzny funkcja (definiowana w oddzielnym schemacie blokowym). viii

Rozdział 1 Podstawowe wiadomości 1.1 Steganografia 1.1.1 Rys historyczny Sztuka ukrywania informacji jest bardzo stara. Pierwszy udokumentowany przykład zastosowania steganografii podają Dzieje greckiego historyka Herodota, żyjącego w latach 485-425 p.n.e. Opisuje od fortel, jakiego użył tyran Histiajos, przetrzymywany w areszcie domowym przez króla perskiego Dariusza. Tajną wiadomość do swoich bliskich w Milecie wytatuował na głowie niewolnika i poczekał, aż temu odrosną włosy, a następnie posłał go do Miletu. Tam odbiorcy wiadomości, poinformowani przez niewolnika o sposobie ukrycia informacji, bez przeszkód ją odczytali. Inne historyczne metody steganograficzne obejmowały ukrywanie wiadomości w określonych literach niewinnie wyglądających tekstów (np. w drugiej literze każdego wyrazu), za pomocą odpowiedniego ułożenia tekstu na stronie, czy też zapisując przekaz przy pomocy sympatycznego atramentu, wśród informacji widocznych i nie wzbudzających podejrzeń. Rozwój optyki, a później fotografii, pozwolił na rozwinięcie dużo bardziej wyrafinowanych metod. W czasie II wojny światowej służby wywiadowcze III Rzeszy stosowały tzw. technikę mikrokropek. Polegało to na sfotografowaniu poufnych informacji (tekstu drukowanego, map, rysunków technicznych itp.) i ukryciu ich na mikroskopijnych, doskonałej jakości kliszach fotograficznych. Tak otrzymane mikrozdjęcia umieszczano w tekście w postaci kropek nad literami i, j oraz na końcu zdań [12, 16]. Obecnie, dzięki rozwojowi technik informatycznych i łatwości obróbki danych cyfrowych wszelkiej postaci obrazu, dźwięku, tekstu steganografia ma idealne możliwości rozwoju. Wszelkie dane zapisane cyfrowo nadają się też dobrze do tego, by je ukryto zapis zerojedynkowy rozumiany jako obecność pewnego ustalonego elementu lub jego brak, można w prosty sposób kodować na bardzo wiele sposobów w innych danych. Do niedawna steganografia nie wzbudzała większego zainteresowania, w przeciwieństwie 1

do kryptografii, przeżywającej burzliwy i gwałtowny rozwój w XX wieku. Dopiero od około 10 lat obserwuje się lawinowy wzrost badań nad zastosowaniem steganografii w informatyce. Jednym z zastosowań steganografii jest ochrona praw autorskich do dzieł (filmów, utworów muzycznych, oprogramowania) rozpowszechnianych drogą elektroniczną, poprzez stosowanie cyfrowych znaków wodnych. Pozwala to na ukrycie informacji o prawach autorskich, numerów seryjnych czy innych charakterystycznych cech identyfikujących dany egzemplarz w pliku z dziełem i późniejsze odróżnienie oryginału od kopii [12]. Teoretycznie, gdyż w praktyce z niewykrywalnością tego typu ingerencji bywa różnie, często okazują się one mimo wszystko łatwe do wykrycia [13]. Łatwość ukrywania informacji przed okiem ludzkim przy pomocy technik komputerowych idzie w parze z dużo większą łatwością wykrycia tego faktu przez maszyny. Najbardziej popularną i najpowszechniej opisywaną gałęzią steganografii w informatyce jest chyba ukrywanie informacji w plikach graficznych. Wykorzystywany jest fakt, że przy kodowaniu w systemie RGB kolor każdego piksela składa się z trzech składowych (czerwonej, zielonej i niebieskiej), każdej zapisanej w ośmiu bitach. Okazuje się, że bez widocznej straty jakości obrazu można wykorzystać najmłodsze (najmniej znaczące) bity kodujące składowe do zapisu ukrytych informacji, uzyskując w ten sposób ukryty kanał o pojemności trzech bitów na każdy piksel a więc już całkiem niebagatelnej. Zaawansowane programy steganograficzne dbają o to, by statystyczny rozkład kolorów w tak przetworzonym obrazie nie różnił się w sposób znaczący od rozkładu w obrazie oryginalnym a więc by analiza obrazu z tajnym przekazem nie dawała podstaw do podejrzeń, iż obraz zawiera ukryte treści [4]. 1.1.2 Definicje Kryptografia (krypto- + gr. gráphein pisać ) dziedzina zajmująca się utajnianiem informacji przez jej szyfrowanie; także ogół technik szyfrowania informacji. Steganografia dział wiedzy zajmujący się utajnianiem informacji poprzez ich ukrycie w innych informacjach. Blisko związane ze steganografią jest pojęcie ukrytego kanału, które zdefiniuję tutaj, by móc używać go w przyszłości: Ukryty kanał (ang. covert channel) logiczny kanał komunikacyjny umożliwiający przesyłanie wiadomości w sposób nie przewidziany w założeniach technicznych środka komunikacji. 2

1.2 Steganografia w sieciach komputerowych Ze względu na wielką ilość danych przesyłanych obecnie przez sieci komputerowe ruch sieciowy stanowi atrakcyjne medium dla technik steganograficznych. Zachodzi pytanie, czy dane przesyłane w Internecie mogą zostać wykorzystane jako nośnik, być może nawet bez wiedzy ich nadawcy i adresata? Sieci oparte o protokoły TCP/IP są rozwijane od ponad dwudziestu lat. Zestaw protokołów sieciowych, tworzonych na podstawie tych dwóch najważniejszych, był i nadal jest stale rozbudowywany i wzbogacany o nowe techniki. W każdej z warstw teoretycznego modelu OSI istnieje wiele rozmaitych protokołów, w różny sposób realizujących cele właściwe dla danej warstwy. Każdy z nowopowstających protokołów sieciowych jest projektowany z myślą o konkretnych zastosowaniach, warunkach działania i przy uwzględnieniu doświadczeń płynących z całej historii rozwoju sieci komputerowych, a sieci TCP/IP w szczególności. Pierwsze protokoły tworzone były niemal wyłącznie z myślą o sprawnym działaniu, obecnie zaś duży nacisk kładziony jest na bezpieczeństwo, zarówno na etapie samego projektu, jak i późniejszej jego implementacji. Niemniej jednak, praktycznie rzecz biorąc, w niemal każdym miejscu modelu OSI, a więc w obrębie protokołów realizujących usługi każdej z warstw, można znaleźć elementy, które przy mniejszym lub większym nakładzie pracy można wykorzystać do celów, które nie były przewidziane przez projektantów. Powodem mogą być takie cechy protokołów sieciowych, jak redundancja przesyłanych danych czy też brak jednoznaczności w definiowaniu poszczególnych składowych czy mechanizmów. Wiele technik jest tworzonych z myślą o jak największej ich uniwersalności lub zgodności z jeszcze nieistniejącymi mechanizmami przekłada się to na często niejasne lub wadliwe działanie obsługującego dane protokoły sprzętu i oprogramowania, co z kolei prowadzić może do rozmaitych nadużyć. Z punktu widzenia administratorów sieci i systemów istotne jest uświadomienie sobie tego faktu. Istotne jest, by zdawać sobie sprawę z potencjalnych słabości używanych technik, co pozwoli także na szukanie sposobów aktywnego przeciwdziałania zagrożeniom i minimalizowania ich. 1.3 Modele ISO/OSI i czterowarstwowy model TCP/IP Sposób przepływu informacji pomiędzy aplikacjami działającymi na dwóch stacjach sieciowych, połączonych siecią i za jej pośrednictwem komunikujących się, wygodnie jest opisywać przy pomocy ogólnego modelu. Powszechnie stosuje się wielowarstwowy model koncepcyjny stworzony w 1984 roku przez Międzynarodową Organizację Normatywną International Standards Organization, ISO i nazywany jest wzorcowym modelem łączenia systemów otwartych (ang. Open Systems Interconnect Reference Model, OSI ). 3

Praktycznie zawsze, gdy opisywana jest struktura i funkcje dowolnego protokołu wymiany danych w sieciach komputerowych, czynione jest to w odniesieniu do tego modelu, stąd jego znajomość jest niezbędna dla zrozumienia zagadnień dotyczących sieci komputerowych. Model OSI składa się z siedmiu niezależnych warstw, służących do opisu poszczególnych działań, składających się na przesyłanie informacji poprzez sieć. Działania te są autonomiczne i mogą być implementowane niezależnie od siebie. Jednym z podstawowych założeń modelu jest to, że warstwy niższe (położone niżej w modelu) dostarczają usług warstwom wyższym, przy czym dana warstwa wyższa korzysta z usług jedynie położonej bezpośrednio pod nią warstwy niższej. Ponieważ model przedstawia jedynie ogólną koncepcję komunikacji, nie określa szczegółowych metod komunikacji tym zajmują się konkretne protokoły komunikacyjne, definowane oddzielnie, choć często w odniesieniu do modelu OSI. Protokół komunikacyjny zbiór formalnych reguł i konwencji szczegółowo określających mechanizmy wymiany informacji między stacjami połączonymi medium transmisyjnym (kablem sieciowym) [26]. Ze względu na warstwową budowę, strukturę modelu OSI określa się często stosem protokołów, jednak warto podkreślić, że pojęcie warstwy nie jest tożsame z pojęciem protokołu definiuje ona funkcje, które mogą być realizowane przez więcej, niż jeden protokół, może więc obejmować wiele protokołów, z których każdy realizuje funkcje tej warstwy. W praktycznych implementacjach często bywa także, że popularne protokoły (z TCP i IP na czele) nie są od siebie niezależne, wbrew założeniom modelu OSI (TCP nie może istnieć bez IP, bo korzysta z części jego nagłówka [19]). Poniższa tabela przedstawia nazwy i najważniejsze funkcje poszczególnych warstw modelu OSI [11]: warstwa aplikacji warstwa prezentacji warstwa sesji warstwa transportowa warstwa sieciowa warstwa łącza danych warstwa fizyczna zawiera programy aplikacyjne wykorzystujące sieć określa strukturę danych przekazywanych między aplikacjami, zajmuje się konwersją pomiędzy różnymi formatami danych, systemami kodowania znaków itp. zarządza sesjami łączącymi aplikacje określa mechanizmu detekcji i korekcji błędów po obu stronach połączenia zarządza połączeniami sieciowymi wykorzystywanymi przez wyższe warstwy zapewnia niezawodne dostarczanie danych poprzez łącza fizyczne określa fizyczne składniki nośników danych wykorzystywanych przez sieć 4

Dokładne omawianie modelu OSI nie jest przedmiotem niniejszej pracy, a z punktu widzenia przedstawionej w niej problematyki funkcje wszystkich warstw modelu nie są istotne, dlatego nie będą one szerzej opisywane. Przyjmuje się, że architektura TCP/IP składa się z mniejszej liczby warstw, niż model OSI. Jego właściwości i funkcje lepiej oddaje uproszczony model czterowarstwowy, zwany także modelem DARPA lub po prostu modelem TCP/IP. Poszczególne warstwy tego modelu to [11]: warstwa aplikacji warstwa transportowa warstwa Internetu dostępu do sieci składa się z aplikacji i procesów korzystających z sieci udostępnia mechanizmy dostarczania danych od nadawcy do odbiorcy definiuje datagram i obsługuje mechanizmy rutujące udostępnia funkcje dostępu do fizycznej warstwy sieci Poszczególne warstwy obu modeli wzajemnie sobie odpowiadają, przy czym dwie spośród warstw modelu TCP/IP łączą w sobie funkcje kilku warstw modelu OSI: model ISO/OSI model TCP/IP (DARPA) 7 warstwa aplikacji 6 warstwa prezentacji warstwa aplikacji 4 5 warstwa sesji 4 warstwa transportowa 3 warstwa sieciowa 2 warstwa łącza danych 1 warstwa fizyczna warstwa transportowa 3 warstwa Internetu 2 warstwa dostępu do sieci 1 Rysunek 1.1. Porównanie modeli warstwowych OSI i DARPA W obu modelach warstwowych dane wysyłane przez aplikację do sieci zaczynają wędrować w dół stosu protokołów. Po odebraniu przez stację docelową, odbywają drogę w górę stosu. Każdy z protokołów działających w obrębie danej warstwy, dołącza do wysłanych przez aplikację danych swoje własne informacje, zwane nagłówkiem. Wraz z wędrówką danych w dół stosu protokołów, są one wzbogacane o dalsze nagłówki. Każda warstwa traktuje wszystkie informacje otrzymane z warstwy wyższej jako dane i zaopatruje je we własny nagłówek. Proces dodawania kolejnych nagłówków przez kolejne warstwy nosi nazwę enkapsulacji, czyli opakowywania. Po odebraniu danych przez 5

stację docelową, w trakcie wędrówki danych w górę stosu protokołów, następuje proces odwrotny odpowiednie warstwy odcinają swój nagłówek przed przekazaniem informacji do warstwy wyższej. Warstwowa budowa modelu OSI pozwala na łatwiejsze poszukiwanie i wykorzystanie ukrytych kanałów komunikacyjnych, niż działoby się to w przypadku konieczności jednorazowej analizy sieci jako całości, bez szczegółowego podziału funkcjonalnego. Na przykład, prościej jest rozpatrywać i badać przekazywanie ukrytych danych z jednej warstwy do drugiej, bezpośrednio do niej przylegającej niż zajmować się przekazywaniem tych danych od razu w obrębie kilku warstw lub warstw nie stykających się bezpośrednio [7]. Niniejsza praca koncentruje się na protokołach IP i TCP, a więc na warstwach Internetu i transportowej modelu czterowarstwowego 1. Ponieważ w przypadku tego modelu i zestawu protokołów TCP/IP nie można opisywać warstw w oderwaniu od charakterystyki protokołów IP i TCP, cechy tych warstw zostaną bliżej omówione poniżej, wraz z opisem najważniejszych własności tych dwóch protokołów. 1.4 Zestaw protokołów TCP/IP Poniżej zostaną omówione dwa podstawowe protokoły sieci IP: protokół warstwy Internetu IP (wersja 4), i protokół warstwy transportowej TCP. Omówienie to ma na celu ułatwienie późniejszego zrozumienia przedstawionych w dalszej części pracy rozważań na temat tworzenia ukrytych kanałów przy pomocy nagłówków tychże protokołów. Z tego też względu pominięto opis kluczowego dla działania sieci TCP/IP protokołu ICMP, a także protokołu UDP uznano bowiem, że protokoły te nie oferują atrakcyjnych możliwości przesyłania ukrytych danych, a co za tym idzie, ich dokładne poznanie nie jest konieczne do zapoznania się z tematyką niniejszej pracy. 1.4.1 Protokół IPv4 Protokół IP Internet Protocol, czyli protokół międzysieciowy opisany i zdefiniowany w dokumencie RFC 791 ([18]), jest najważniejszą częścią warstwy Internetu 2. Dostarcza on podstawowych usług wysyłania i odbierania pakietów danych, na bazie których budowane są usługi sieci TCP/IP. Wszystkie protokoły warstw wyższych wykorzystują IP do przesyłania danych, a wszelkie dane przesyłane w sieciach TCP/IP przechodzą przez warstwę IP. W niniejszej pracy omówiono budowę protokołu IP w wersji czwartej (IPv4), znajdującej się obecnie w użyciu. 1 ze względu na koncentrowanie się na sieciach TCP/IP, w dalszej części pracy obecne są odniesienia do modelu czterowarstwowego, nie zaś modelu ISO/OSI. 2 warstwy sieciowej w modelu OSI 6

Najważniejsze zadania tego podstawowego protokołu internetowego, to ([11]): definiowania podstawowej jednostki danych przesyłanej w Internecie datagramu; definiowanie schematu adresowania obowiązującego w sieci Internet (i wszystkich sieciach TCP/IP); przesyłanie danych między warstwą dostępu do sieci i warstwą transportową; trasowanie (rutowanie) datagramów skierowanych do odległych stacji sieciowych; dokonywanie fragmentacji i ponownej defragmentacji datagramów na ich drodze przez sieć. Protokół IP jest protokołem bezpołączeniowym, to znaczy nie ustanawia w żaden sposób połączenia i nie sprawdza gotowości odległego komputera do odebrania przesyłanych danych. Nie buduje jednej ścieżki między stacją nadawczą i odbiorczą, pakiety do stacji odbiorczej mogą być przesyłane różnymi trasami i docierać do niej w innej kolejności niż są wysyłane przez stację nadawczą. Dane przepływają przez trwałe połączenia między węzłami sieci, a każdy pakiet jest obsługiwany indywidualnie i niezależnie od innych pakietów danego komunikatu (transmisji). Jest to możliwe dzięki temu, że każdy pakiet jest kompletnie zaadresowany, to znaczy, że każdy z nich ma swój adres stacji nadawczej i stacji odbiorczej (zawiera je nagłówek datagramu IP). Protokół IP odpowiedzialność za wykrywanie i korekcję błędów transmisji przekazuje na inne protokoły sam nie przewiduje takich usług. Jeżeli kontrola poprawności dostarczenia i odebrania danych jest niezbędna, zapewniają ją protokoły innych (wyższych) warstw [11]. Fragmentacja IP Podczas przesyłania datagramu poprzez różne sieci może zajść potrzeba podzielenia go na mniejsze części. Teoretycznie, maksymalny rozmiar datagramu to 65535 bajtów wraz z nagłówkiem (ponieważ pole nagłówka IP określające długość datagramu ma rozmiar 16 bitów). W praktyce, wielkość ta zależy od stosowanego protokołu warstwy dostępu do sieci i przyjętego w nim maksymalnego rozmiaru pakietu (ang. Maximum Transmission Unit, MTU ). Jeżeli wysyłany datagram IP jest większy, niż MTU, to musi on zostać podzielony, by możliwe było jego przesłanie w sieci. Proces ten nosi nazwę fragmentacji, a części datagramu powstałe w jego wyniku fragmentów. Fragmentacja zachodzić może podczas wysyłania datagramu ze stacji sieciowej, a także na ruterach, w przypadku, gdy docelowy port, na który przekazują datagram należy do sieci innego rodzaju, mającej mniejsze MTU. Fragmenty tego samego datagramu mają taką samą wartość pola identyfikacji w nagłówku IP, co pozwala na odtworzenie całego datagramu z fragmentów na stacji docelowej. 7

Budowa datagramu IP Budowę jednostki transportowej protokołu IP datagramu, przedstawia rysunek 1.2. 32 bity 4 8 12 16 20 24 28 31 wersja długość nagłówka TOS/DSCP długość identyfikacja flagi przesunięcie fragmentacji czas życia (TTL) protokół suma kontrolna nagłówka 5 słów źródłowy adres IP docelowy adres IP opcje (zmienna długość) dopełnienie dane (zmienna długość) Rysunek 1.2. Datagram IPv4 Omówione zostaną teraz funkcje i znaczenie poszczególnych pól nagłówka datagramu [8, 18]. wersja To czterobitowe pole określa wersję protokołu IP, do której należy datagram. Niniejsza praca poświęcona jest protokołowi IP w wersji czwartej (IPv4), zatem każdy badany datagram ma wpisaną do tego pola wartość 4. długość nagłówka (ang. Internet Header Lenght, IHL) Kolejne pole określa długość nagłówka datagramu, mierząną w 32-bitowych słowach (w wielokrotności 4 oktetów). Minimalna długość prawidłowego nagłówka IP wynosi 5 słów (20 bajtów 3 ), zaś maksymalna 15 słów (60 bajtów). Pole to można odczytywać także jako przesunięcie (ang. offset) pierwszego słowa danych przenoszonych przez datagram. 3 nie zawsze jeden bajt to 8 bitów, czyli oktet (uzależnione jest to od platformy sprzętowej) jednak w dalszej części pracy przyjęto, że tak jest. 8

typ usługi Type of Service / Differentiated Services Codepoint Jednobajtowe pole ToS służy do określania typu usługi przenoszonej przez dany pakiet oraz pożądanych parametrów jakości usług. Znaczenie tego pola jest abstrakcyjne i mimo określonej budowy, jego interpretacja i wybór metod stosowanych do zapewnienia tych parametrów zależy od producentów ruterów i administratorów sieci je wykorzystujących. Pole to może być brane pod uwagę przez rutery podczas podejmowania decyzji rutowania i w algorytmach kolejkowania, ale nie musi (może być zignorowane i często jest). Dokładną budowę pola TOS przedstawia rysunek 1.3: pierwszeństwo D T R C 0 Rysunek 1.3. Pole Type of Service Pierwsze trzy bity określają pierwszeństwo (ang. precedence) i są ignorowane w większości współczesnych sieci IP. Kolejne cztery określają rodzaj usługi, jaka oczekiwana jest od rutera i w danym momencie może być ustawiony tylko jeden z nich. Oznaczają kolejno: małe opóźnienie; dużą przepustowość; dużą niezawodność; niski koszt. Wraz z upływem czasu i rozwojem sieci IP pole ToS w takiej formie okazało się nieprzydatne, a po wprowadzeniu technik Differentiated Services zostało przedefiniowane [15] do postaci przedstawionej na rysunku 1.4 i otrzymało nazwę Differentiated Services CodePoint, DSCP. DSCP CU Rysunek 1.4. Pole Differentiated Services CodePoint W polu DSCP wykorzystywanych jest sześć pierwszych (najstarszych) bitów, oznaczających kategorię usługi, do jakiej należy kierować dany datagram IP. Ostatnie dwa bity nie są wykorzystywane. 9

Dokładne omawianie mechanizmów jakości usług i znaczenia oraz interpretacji pola ToS/DSCP wykracza poza ramy tej pracy. Zagadnienia te są szczegółowo omawiane w powstającej równolegle pracy dyplomowej Jakuba Turskiego [24], i tam też należy szukać dalszych informacji. długość Kolejne pole określa całkowitą długość datagramu nagłówka oraz danych (łącznie). identyfikacja 16-bitowe pole identyfikacji służy do niepowtarzalnego identyfikowania datagramu w obrębie jednej transmisji. Jest ono ustawiane przez stację wysyłającą datagram. W obrębie jednej transmisji, rozumianej jako para nadawca-odbiorca, musi być unikalne dla każdego datagramu, z wyjątkiem stanu, gdy datagram został poddany fragmentacji w takim przypadku każdy z fragmentów ma taką samą wartość pola identyfikacji. Dzięki temu możliwe jest złożenie datagramu z poszczególnych fragmentów po jego dotarciu do celu rolą pola identyfikacji jest umożliwienie tego. Na ogół po wysłaniu każdego datagramu pole to jest inkrementowane, co jednak zależy od konkretnej implementacji stosu TCP/IP w systemie operacyjnym. Wartość pola identyfikacji na początku transmisji nie jest określona, RFC 791 nie narzuca także żadnej metody zmieniania wartości doń wpisywanej w kolejnych wysyłanych datagramach, prócz bezwzględnej konieczności zapewnienia unikalnych wartości. flagi fragmentacji Trzy bity flag fragmentacji określają pożądane traktowanie datagramu w przypadku wystąpienia konieczności przeprowadzenia jego fragmentacji. Kolejno od lewej (od najstarszego bitu) są to: flaga zarezerowowana (ang. Reserved Flag, RF ) obecnie niewykorzystywana; flaga Don t Fragment, której ustawienie oznacza brak zgody na przeprowadzanie fragmentacji tego datagramu (jeśli datagram musi być poddany fragmentacji, a flaga DF jest ustawiona, to datagram zostanie odrzucony); flaga More Fragments, ustawiona oznacza, że datagram jest częścią sfragmentowanego pakietu, a po nim następują dalsze fragmenty. Ostatni fragment datagramu ma tą flagę wyzerowaną. przesunięcie fragmentacji 13-bitowe pole przesunięcia fragmentacji występuje w częściach datagramu poddanego fragmentacji i określa offset poczatku fragmentu w oryginalnym datagramie. Przesunięcie wyrażane jest jako wielokrotność ośmiu oktetów (64 bitów). W przypadku datagramów niesfragmentowanych ma wartość zero. 10

czas życia (ang. Time To Live, TTL) Pole TTL określa maksymalny czas (mierzony ilością przeskoków pomiędzy kolejnymi ruterami), przez jaki pakiet może pozostać w sieci IP. Jest ono dekrementowane w każdym ruterze, przez który przechodzi dany datagram, a gdy osiągnie wartość 0, jest on odrzucany. protokół To 8-bitowe pole określa protokół warstwy transportowej, którego dane przenosi datagram. Na przykład, dla protokołu TCP wpisywana jest do tego pola wartość 6. Pełną listę numerów przypisanym poszczególnym protokołom znaleźć można w RFC [22], który jednak jest ostatnim wydaniem tego spisu w takiej formie. Aktualniejszą listę numerów protokołów znaleźć można w sieci Internet na stronach organizacji Internet Assigned Numbers Authority, pod adresem http://www.iana.org/assignments/protocol-numbers. suma kontrolna nagłówka 16-bitowa suma kontrolna zabezpiecza jedynie dane zawarte w nagłóku datagramu IP, nie chroni danych. Dane przenoszone przez protokoły warstwy wyższej są chronione osobną sumą kontrolną implementowaną w tych protokołach. źródłowy adres IP Jest to 32-bitowy adres IP stacji będącej nadawcą datagramu. docelowy adres IP Jest to 32-bitowy adres IP stacji, do której datagram jest wysyłany. pole opcji Pole to jest nieobowiązkowe i może mieć zmienną wielkość, zależną od ilości i rodzaju wpisanych do niego opcji w obrębie pola opcji (jeśli takie w ogóle występuje) może być umieszczona jedna, kilka lub wiele opcji, każda innej długości. Jedynym ograniczeniem jest maksymalna długość nagłówka IP, która wynosi, jak napisano powyżej, 60 oktetów (a więc na pole opcji przeznaczone może być do 40 bajtów). Pomimo, iż opcje IP są rzadko spotykanym elementem datagramów, to muszą (tego wymaga RFC 791) być obsługiwane przez wszystkie urządzenia sieciowe komunikujące się za pośrednictwem sieci IP. Pojedyncza opcja może jeden z dwóch formatów: pojedynczy oktet (bajt) oznaczający typ opcji; bajt oznaczający typ opcji, bajt określający jej długość i kilka bajtów z danymi opcji. Budowę pierwszego oktetu opcji, opisującego jej typ i identycznego w obu powyższych przypadkach, przedstawia rysunek 1.5. 11

7 6 5 4 0 F C Number Rysunek 1.5. Pole typu opcji IP Najstarszy, siódmy bit, o nazwie Copy to Fragments Bit bądź Copied Flag, określa czy opcja ma być skopiowana do każdego fragmentu datagramu w przypadku, gdy nastąpi jego fragmentacja (flaga ustawiona), czy też ma występować jedynie w pierwszym fragmencie (flaga wyzerowana). Do bitów szóstego i piątego, nazywanych razem klasą opcji (ang. Option Class) wpisywana jest liczba z zakresu od 0 do 3, przy czym: wartość 0 oznacza opcję klasy Control; wartość 2 oznacza opcję klasy Debugging and Measurement; wartości 1 i 3 są zarezerwowane (i nigdy nie występują). Trzecia część typu opcji określa jej numer w obrębie danej klasy. W przypadku opcji jednobajtowych występuje tylko opisany powyżej bajt typu opcji. Dla opcji, które posiadają również (różnego rodzaju) dane, dodawany jest drugi bajt, określający długość całej opcji wliczając w to bajt typu i bajt długości oraz pewna ilość bajtów z danymi opcji. I tak, przykładowo, dla opcji Stream Identifier 4, zdefiniowanej w RFC 791 [18], która posiada dwa bajty danych, do pola długości wpisywana jest wartość 4. Dokument RFC 791, opisujący protokół IP, definiuje tylko kilka opcji IP. Obecnie wykorzystywana jest jedynie ich część, a reszta zastąpiona została mechanizmami oferowanymi przez inne protokoły sieciowe (warstw wyższych) i uznana jest za przestarzałą. Przyjęty sposób oznaczania i numeracji opcji IP pozwala na zdefiniowanie własnych opcji, o ile nie będą kolidować ze zdefiniowanymi wcześniej. Poza RFC 791, różnego rodzaju dodatkowe opcje IP wprowadzane były w późniejszych dokumentach RFC, prawdopodobnie najpełniejszą ich listę wraz z odnośnikami do definiujących je źródeł można znaleźć na stronie wspomnianej już organizacji Internet Assigned Numbers Authority, pod adresem http://www.iana.org/assignments/ip-parameters. W praktyce opcje w datagramach IP spotkać jest bardzo trudno i chyba można wysunąć tezę, iż poza szczególnymi zastosowaniami diagnostycznymi opcje IP nie występują. 4 w rzeczywistych sieciach opcja ta nie powinna występować, ponieważ jak wiele innych opcji IP jest określana jako przestarzała (ang. obsolete) i nie powinna pojawiać się w żadnym prawidłowym datagramie IP. 12

Pole opcji musi być albo zakończone opcją End of Option List, EOOL (jest wtedy w razie konieczności uzupełniane pole dopełnienia), bądź mieć długość będącą wielokrotnością 32 bitów w tym drugim przypadku koniec pola opcji rozpoznawany jest na podstawie pola długości nagłówka (IHL). dopełnienie Jeżeli pole opcji nie ma wielkości będącej wielokrotnością 32 bitów (4 oktetów), to po ostatniej opcji EOOL występuje dopełnienie do 32 bitów. Pole dopełnienia ma zmienną wielkość, zależną od liczby bitów brakujących do 32. Zgodnie z RFC pole to powinno być wypełnione zerami [18]. 1.4.2 Protokół TCP Do niezawodnego przesyłania danych poprzez sieci IP wykorzystywany jest, zdefiniowany w dokumencie RFC 793 [19], protokół kontroli transmisji Transmission Control Protocol, TCP. Jest to protokół warstwy transportowej 5, udostępniający usługi niezawodnego przesyłania danych wraz z kontrolą i korekcją błędów. Protokół TCP jest protokołem niezawodnym i połączeniowym. Oprócz protokołu TCP, warstwa transportowa w sieciach IP obejmuje także drugi protokół transportowy, UDP (ang. User Datagram Protocol) [17], służący do bezpołączeniowego dostarczana datagramów. Jednak nieskomplikowana budowy nagłówka datagramów UDP i praktyczny brak w nim pól niewykorzystanych bądź nie mających ściśle określonego znaczenia, nie predystynują go do wykorzystania w ukrytej transmisji danych i nie będzie omawiany w tej pracy. Niezawodność przesyłu danych w protokole TCP zapewniana jest przez mechanizm potwierdzania z retransmisją (ang. Positive Acknoledgement with Retransmission, PAR). Polega on na wysyłaniu danych tak długo, aż nie nadejdzie potwierdzenie ich poprawnego odbioru. Do weryfikacji poprawności przesłanych danych służy suma kontrolna, znajdująca się w nagłówku podstawowej jednostki transportowej protokołu TCP segmentu. Potwierdzenie jest wysyłane przez odbiorcę danych jedynie, gdy odebrał on dane i stwierdził ich bezbłędność. W przeciwnym wypadku, segment jest odrzucany, a po pewnym czasie nadawca ponawia jego wysyłkę [11]. Protokół TCP określany jest często protokołem działającym na strumieniach bajtów, gdyż zawarte w nagłówku segmentu TCP numery sekwencyjne (porządkujące bajty w transmisji i pozwalające odtworzyć ich właściwą kolejność u celu) nie odnoszą się do poszczególnych segmentów, lecz mają znaczenie w obrębie całej transmisji strumienia danych [8]. Połączeniowość protokołu TCP ma źródło w tworzeniu przez ten protokół logicznego 5 warstwy o tej samej nazwie (warstwy transportowej) w modelu OSI 13

połączenia między stacjami przesyłającymi między sobą dane. Na początku transmisji, przed rozpoczęciem właściwej komunikacji, wymieniane są między stacjami komunikaty kontrolne, noszące nazwę handshake, których rolą jest ustanowienie połączenia do transmisji. W TCP stosowane jest tzw. potwierdzenie trójpoziomowe (ang. three-way handshake) [19] (rysunek 1.6). Podczas procedury nawiązywania połączenia wysyłane są trzy segmenty. Pierwszy wysyłany segment jest segmentem synchronizującym (ma ustawioną flagę synchronizacji SYN w nagłówku) 6. Stacja docelowa (serwer) jest informowana o żądaniu nawiązania połączenia, a także otrzymuje początkowy numer sekwencji (Initial Sequence Number, ISN ) przesyłanych danych. Następnie, stacja ta przesyła stacji klienta segmentem z ustawionymi bitami synchronizacji (SYN) i potwierdzenia (ACK), potwierdzającym numerem sekwencyjnym o wartości otrzymanej od klienta + 1, oraz własnym początkowym numerem sekwencyjnym. Klient po otrzymaniu tego segmentu odpowiada segmentem z ustawioną flagą potwierdzenia (ACK) i potwierdzającym numerem sekwencyjnym o wartości ISN serwera + 1. Po odebraniu tego segmentu przez serwer połączenia jest nawiązane [11]. SYN ISN klienta SYN+ACK ISN serwera ISN+1 klienta ACK ISN serwera + 1 klient serwer Rysunek 1.6. Three-way handshake 6 opis flag TCP znajduje się w dalszej części rozdziału, na stronie 16 14

Budowa segmentu TCP Budowę jednostki transportowej protokołu TCP segmentu, przedstawia rysunek 1.7. 32 bity 4 8 12 16 20 24 28 31 port źródłowy port docelowy numer sekwencyjny potwierdzający numer sekwencyjny 5 słów długość nagłówka pole zarezerwowane flagi rozmiar okna suma kontrolna TCP wskaźnik ważności opcje (zmienna długość) dopełnienie dane (zmienna długość) Rysunek 1.7. Segment TCP [8, 19]. Omówione zostaną teraz funkcje i znaczenie poszczególnych pól nagłówka segmentu port źródłowy Pierwsze 16-bitowe pole określa numer portu, identyfikujący proces nadający na stacji określonej przez adres IP z nagłówka datagramu IP. port docelowy Kolejne pole podaje numer portu związanego z procesem odbierającym dane. numer sekwencyjny 32-bitowy numer sekwencyjny pozwala zachować kolejność bajtów w obrębie stumienia danych TCP. Jak powiedziano wcześniej, podczas nawiązywania połączenia zarówno stacja nadawcza, jak odbiorcza, ustalają swoje początkowe numery sekwencyjne (ang. Initial Sequence Number, ISN ). Istotną własnością protokołu TCP jest numerowanie bajtów nie od zera, lecz począwszy od ISN, który ma, a nawet powinien, mieć wartość różną od zera i praktycznie losową. Dla prawidłowej pracy mechanizmów potwierdzania i retransmisji 15

(PAR) protokołu TCP początkowa wartość numeru sekwencyjnego nie ma znaczenia. Definiujący protokół dokument RFC 793 stwierdza, że numer ISN jest generowany osobno dla każdego połączenia, na podstawie 32-bitowego zegara, którego najmłodszy bit inkrementowany jest co cztery mikrosekundy. W praktyce zdarza się, że implementacje stosów TCP/IP upraszczają metodę generowania numeru ISN [9]. potwierdzający numer sekwencyjny Pole to służy do potwierdzenia otrzymania wskazywanej przez nie liczby bajtów strumienia TCP. Ma ono znaczenie w segmentach z ustawioną flagą ACK. długość nagłówka przesunięcie danych (ang. data offset)) Kolejne pole określa długość nagłówka i tym samym miejsce, gdzie rozpoczynają się właściwe dane przenoszone przez segment TCP. Długość nagłówka jest mierzona w 32- bitowych słowach, zatem maksymalna wartość wpisywana do tego pola to 15 (dla nagłówka długości 60 bajtów). Zwykle nagłówek segmentu TCP ma długość 20 bajtów (5 słów). pole zarezerwowane Jest to 6-bitowe pole zarezerwowane do przyszłego wykorzystania i według RFC 793 powinno być zawsze puste (zawierać wartość 0). flagi Kolejne sześć bitów nagłówka segmentu TCP tworzy pole flag. Poczynając od najstarszego bitu tego pola (od lewej), są to [19]: URG flaga ważności, oznaczająca, że pole ważności ma zastosowanie dla tego segmentu, a segment zawiera ważne dane; ACK flaga potwierdzenia (określa, że potwierdzający numer sekwencyjny ma zastosowanie w tym segmencie); PSH flaga oznaczająca konieczność niezwłocznego wysłania przez stos TCP/IP powiadomienia do aplikacji o danych, które nadeszły i mają nadejść. RST flaga resetowania połączenia, zwykle ustawiana w odpowiedzi do klienta próbującego połączyć się (przez wysłanie segmentu z ustawioną flagą SYN) z serwerem, w którym żaden proces nie nasłuchuje na żądanym porcie. Czasem flaga RST jest ustawiana w odpowiedzi na nadejście nieprawidłowego segmentu TCP [5]. SYN flaga synchronizacji, inicjalizująca połączenie i synchronizująca numery sekwencyjne. FIN flaga oznaczająca koniec wysyłania danych, używana do kończenia połączeń TCP. 16

rozmiar okna 16-bitowe pole z rozmiarem okna określa wielkość dostępnego bufora dla odbieranych danych jest to ilość danych, które może jeszcze przyjąć odbiorca. Stosowanie zmiennej wielkości okna pozwala na sterowanie przepływem danych; przykładowo gdy jedna z komunikujących się stron chce wymusić na drugiej chwilową przerwę w nadawaniu, wysyła pakiet z ustawionym rozmiarem okna zero, co będzie informacją o konieczności zaprzestania wysyłania danych. suma kontrolna 16-bitowa suma kontrolna TCP służy ochronie całego nagłówka segmentu TCP oraz przenoszonych przezeń danych. Ochrania ona także 12-bajtowy pseudonagłówek (rysunek 1.8), zawierający dodatkowo: źródłowy i docelowy adres IP, numer protokołu (dla TCP 6) oraz długość segmentu TCP (nagłówek plus dane) w oktetach. 32 bity 4 8 12 16 20 24 28 31 źródłowy adres IP docelowy adres IP zera protokół długość segmentu TCP 3 słowa Rysunek 1.8. Pseudonagłówek TCP wskaźnik ważności Ostatnie obowiązkowe pole nagłówka segmentu TCP to 16-bitowe pole wskaźnika ważności. Interpretowane jest ono jako przesunięcie (offset) ostatniego ważnego (ang. urgent) bajtu w strumieniu i jest dodawane do numeru sekwencyjnego. Pole to ma znaczenie jedynie w segmentach z ustawioną flagą URG, w przypadku gdy jest ona wyzerowana, pole ważności musi mieć wartość zero. Pole ważności jest stosowane w przypadku wysyłania przez aplikację danych, które po odebraniu muszą zostać niezwłocznie przekazane aplikacji odbierającej dane z pominięciem buforowania i kolejek. Nawet w przypadku, gdy użyta zostanie flaga PSH, sygnalizująca konieczność natychmiastowego dostarczenia danych, to będą one nadal częścią strumienia i zostaną przesłane do aplikacji dopiero po zwykłych danych występujących wcześniej w strumieniu. Zastosowanie wskaźnika ważności pozwala na dostarczenie ważnych danych do aplikacji z całkowitym pominięciem oczekiwania na przyjęcie dotychczas nieprzetworzonych danych. Takie ważne dane określane są terminem out-of-band data [10]. Wskaźnik ważności, wskazując na numer ostatniego bajtu takich danych, informuje 17

stos TCP, w którym momencie należy wrócić do normalnego przetwarzania informacji ze strumienia. Stacja musi udostępniać możliwość przetwarzania ważnych danych i akceptować je, nawet jeżeli wcześniej sygnalizowała niemożność otrzymywania danych i wysyłała pakiet z wielkością okna ustawioną na zero. pole opcji Zawarte w nagłówku segmentu TCP pole opcji może mieć, podobnie jak pole opcji IP, zmienną długość. Występować w nim mogą opcje o dwojakiej budowie: pojedynczy oktet rodzaju opcji (ang. option kind); oktet rodzaju opcji, oktet określający długość oraz pewną ilość oktetów z danymi opcji. Do długości wskazywanej drugim oktetem (jeśli jest) wliczane są wszystkie bajty składające się na opcję rodzaj, długość i dodatkowe dane. Dokument RFC 793 definiuje jedynie trzy opcje jednobajtowe End of Option List (służącą do oznaczania końca pola opcji) i No Operation (ignorowaną) oraz czterobajtową Maximum Segment Size opcję określającą maksymalny rozmiar segmentu akceptowany przez stację sieciową. W późniejszym okresie wprowadzane były kolejne opcje TCP, ich najpełniejsza dostępna lista dostępna jest pod adresem http://www.iana. org/assignments/tcp-parameters na stronach organizacji IANA. dopełnienie Dopełnienie ma takie samo znaczenie, jak w przypadku analogicznego pola w nagłówku datagramu IP służy ono do uzupełnienia pola opcji (jeśli takowe występuje w nagłówku segmentu) do długości będącej wielokrotnością 32 bitów. Pole to musi być wypełnione zerami. 1.5 Automorfizm toroidalny W implementacji programowej, do kodowania wysyłanych danych użyto transformaty noszącej w angielskojęzycznej literaturze nazwę toral automorphism. Ze względu na trudności w znalezieniu polskich materiałów źródłowych, w dalszej części pracy przyjęto tłumaczenie tego pojęcia jako automorfizm toroidalny. Automorfizm toroidalny jest silnie chaotycznym (mieszającym) systemem [2], który znalazł zastosowanie w tworzeniu cyfrowych znaków wodnych. Jest to dwuwymiarowa transformata działająca na płaszczyznach kwadratowych. Reprezentowana jest macierzą A o wymiarach 2x2: 18

A = 1 1 k k + 1 której wyznacznik jest równy 1: det(a) = 1, własność ta daje pewność istnienia przekształcenia odwrotnego, reprezentowanego macierzą A 1. Automorfizm toroidalny to iteracyjne przekształcenie macierzy kwadratowej 7 o wymiarach NxN, które jest iloczynem macierzy automorfizmu A przez wektor x (x, y {0, 1,..., N 1}) modulo N: y x n+1 y n+1 = 1 1 k k + 1 x n y n mod N gdzie n N jest liczbą iteracji. Operacja modulo nie pozwala punktom uciec poza przekształcaną macierz kwadratową. Przekształcenie całej macierzy kwadratowej powyższym automorfizmem polega na wykonaniu n iteracji dla każdego punktu. Transformata ta jest przekształceniem wzajemnie jednoznacznym. Można wykazać [25], że współrzędne punktów otrzymywane podczas każdej iteracji są ze sobą nieskorelowane statystycznie i zależą od wybranych parametrów k i N (gdzie N jest wymiarem przekształcanej macierzy kwadratowej). Ponadto, pomimo chaotyczności przekształcenia, jest ono okresowe po określonej liczbie iteracji wraca do stanu początkowego. Ze względu na cechy automorfizmu toroidalnego, otrzymywane wartości są losowe, jeśli nieznane są parametry przekształcenia [1, 25]. Z tego powodu nadaje się ono dobrze do zastosowania podczas kodowania znaków przy przesyłaniu ich ukrytym kanałem. Rysunek 1.9 (na następnej stronie) [6] przedstawia graficzną reprezentację automorfizmu toroidalnego. Obrazuje on kolejne iteracje przekształcenia, danego macierzą: A = 1 1 1 2 (parametr k wynosi 1), i działającego na torusie, który początkowo pokolorowany jest jedynie w połowie (na ilustracji znajduje się na samej górze). W miarę wykonywania kolejnych iteracji, pokolorowana połowa jest rozciągana na cały torus. Po pewnej ilości iteracji część pokolorowana i część pozbawiona koloru mieszają się i równomiernie pokrywają całą powierzchnię torusa. 7 w literaturze przekształcana macierz określana jest jako lattice (krata), czyli kwadratowa macierz złożona z punktów rozmieszczonych regularnie (w równych odległościach) na przykład, macierz zawierająca obraz cyfrowy złożony z pikseli 19

Rysunek 1.9. Graficzna reprezentacja automorfizmu toroidalnego 20

Rozdział 2 Opis bibliotek i narzędzi Implementacja protokołów TCP/IP dołączana jest obecnie do każdego systemu operacyjnego. O ile jeszcze kilka, kilkanaście lat temu, wymagane były specjalne zabiegi, by móc korzystać z sieci TCP/IP w systemie operacyjnym nie przeznaczonym specjalnie do pracy w sieci, o tyle obecnie trudno wyobrazić sobie funkcjonalny i pełnowartościowy system operacyjny pozbawiony obsługi protokołów TCP/IP i to niezależnie od tego, czy jest on przeznaczony do zastosowań serwerowych, czy dla stacji roboczych. W chwili obecnej w implementacje stosu protokołów wyposażane są nawet systemy operacyjne takich urządzeń, jak palmtopy (ang. Personal Digital Assistant, PDA) czy telefony komórkowe. Pomimo precyzyjnego sformułowania standardu, implementacje stosu protokołów TCP/IP w poszczególnych systemach operacyjnych różnią się. Programiści systemowi, aby uprościć kod tworzonego oprogramowania lub poprawić jego wydajność, pozwalają sobie na drobne odstępstwa od specyfikacji protokołu. Prowadzi to do zjawisk takich, jak możliwość rozpoznania systemu operacyjnego na podstawie jego reakcji na specyficznie zbudowane pakiety i późniejsze wykorzystanie luk w konkretnej implementacji. Szczególny nacisk na bezpieczeństwo tworzenia stosów TCP/IP w systemach operacyjnych jest kładziony dopiero od niedawna, zwłaszcza w przypadku systemów operacyjnych przeznaczonych na komputery desktop (stacje robocze). Przedstawiony w niniejszej pracy program StegoIP działa w systemie operacyjnym Linux 2.4. System ten wybrany został z kilku powodów. Pierwszym z nich jest stosunkowo dobrej jakości implementacja stosu TCP/IP w tym systemie. Analiza firmy Reasoning Inc. (www.reasoning.com), zajmującej się automatycznym badaniem kodów źródłowych oprogramowania w celu wyszukania błędów w implementacji, wykazała wysoką jakość kodu odpowiedzialnego w Linuksie za obsługę sieci TCP/IP [21]. Porównanie obejmuje analizę kodu jądra Linuksa 2.4.19 z pięcioma innymi implementacjami komercyjnymi. Jej wynikiem jest konluzja, iż błędy w kodzie stosu TCP/IP systemu Linux pojawiają się ze średnią częstością 0.1 na 1000 linii kodu, przy wskaźniku 0.55 na 1000 linii dla oprogramowania komercyjnego. 21