Wykorzystanie mechanizmu okna odbiorczego protokołu TCP w

Wykorzystanie mechanizmu okna odbiorczego protokołu TCP w

Wykorzystanie mechanizmu okna odbiorczego protokołu TCP
w steganografii sieciowej
Paweł Radziszewski
[email protected]
Instytut Informatyki Politechniki Warszawskiej
Streszczenie: Artykuł przedstawia metodę steganografii sieciowej, polegającą na możliwości
wykorzystania mechanizmu okna odbiorczego protokołu TCP do utworzenia kanału
steganograficznego.
Słowa kluczowe: ukrywanie informacji, steganografia sieciowa, TCP, okno odbiorcze
Wstęp
Zdecydowana większość (ok. 80%) ruchu w sieci Internet jako protokół transportowy wykorzystuje
Transmission Control Protocol (TCP). Dzieje się tak m.in. ze względu na jego cechy, przydatne dla
projektantów i programistów aplikacyjnych:
−
gwarancję dostarczenia danych, niwelującą problemy wynikające z możliwych strat pakietów,
ich uszkodzeń oraz dotarcia do odbiorcy w nieodopowiedniej kolejności,
−
elastyczność, skutkującą automatycznym dopasowywaniem się szybkości transmisji do
dostępnej przepływności sieci.
Steganografia sieciowa jest odmianą steganografii, ukrywającą informację nie w przesyłanych
danych czy obiektach, jak ma to miejsce w klasycznej steganografii, ale w mechanizmach
służących do ich przesyłania.
Niniejszy artykuł przedstawia możliwość wykorzystania mechanizmu okna odbiorczego protokołu
TCP do utworzenia kanału steganograficznego.
Okna odbiorcze i nadawcze w protokole TCP
Protokół TCP w swej pierwotnej formie [CERF74][RFC675][RFC793] (tzw. baseline TCP) jako
jedyne dwa mechanizmy sterujące transmisją wykorzystywał okno odbiorcze i zegar retransmisji.
Za pomocą okna odbiorczego odbiorca informuje nadawcę, jaka ilość informacji może zostać do
niego wysłana przez nadawcę bez konieczności odebrania potwierdzenia. Rozmiar okna
odbiorczego może być traktowany jako estymacja miejsca dostępnego w buforze odbiorcy. Nie
może być traktowany z nim tożsamo, ze względu na spowodowane przez dwukrotny proces
transmisyjny opóźnienie pomiędzy sygnalizacją przez odbiorcę nadawcy zmiany w rozmiarze okna
a tego skutkiem - obserwowaną zmianą intensywności napływu pakietów i tym samym danych.
W pierwotnej formie protokołu nie występowały mechanizmy sterowania przeciążeniem.
Wykorzystanie jedynie okna odbiorczego nie powodowało występowania dużej intensywności strat
pakietów, gdyż łącza miały zbliżone przepływności.
Z kolei jednak zastosowanie zegara retransmisji jako jedynego mechanizmu wykrywania strat
pakietów, ze względu na konserwatywność takiego podejścia, prowadziło do spowolnienia
transmisji: nadawca dokonywał retransmisji dopiero po upłynięciu czasu RTO (retransmission
timeout), który był stosunkowo długi, aby nie prowokować wystąpienia niepotrzebnych retransmisji
wskutek zmienności czasów transmisji poszczególnych pakietów lub nawet zaburzenia kolejności
ich odbierania.
Mechanizm sterowania przepływem, w postaci okna nadawczego [RFC1323], stał się w protokole
TCP potrzebny, gdy w sieci Internet zaczęto masowo wykorzystywać węzły koncentrujące większą
liczbę łączy, a same łącza zaczęły mieć bardzo różne przepływności, co mogło bardzo łatwo
prowadzić do niedopasowania szybkości transmisji do aktualnej pojemności sieci i skutkować
odrzuceniami, a następnie - niepotrzebnymi retransmisjami pakietów. Okno nadawcze steruje
szybkością transmisji poprzez wysyłanie bez potwierdzenia ilości danych wprawdzie nadal
limitowanej przez okno odbiorcze, ale w wielu przypadkach zdecydowanie od niej mniejszej. Tym
samym nadawca stara się elastycznie dopasowywać do dostępnej przepływności sieci, unikając jej
przeciążenia, prowadzącego do niepotrzebnych retransmisji.
Do ulepszonego w opisany powyżej sposób protokołu TCP z upływem czasu zostały wprowadzone
rozliczne modyfikacje. Wiele z nich dotyczy mechanizmów okien. Modyfikacje były wprowadzane,
aby dostosować się do zmieniających się technologii, albo aby zwiększyć szybkości transmisji, w
przypadkach ogólnych lub specjalizowanych (różne metody sterowania oknem nadawczym).
Rozmiar okna odbiorczego jest polem o długości 16 bitów, a więc umożliwiającym odbiorcy
wysłanie informacji o rozmiarze okna do 64 kB. Ta wartość, w miarę rozpowszechniania się łączy
szybkich, o dużym iloczynie przepływność * opóźnienie, okazała się niewystarczająca i stała się
powodem dodania do TCP możliwości tzw. skalowania okna. Skalowanie rozmiaru okna
odbiorczego [RFC1323] polega na uzgodnieniu podczas nawiązywania połączenia, za pomocą
mechanizmu opcji, mnożnika, przez który nadawca powinien przemnożyć anonsowany przez
odbiorcę rozmiar okna. Mnożnik jest liczbą będącą potęgą dwójki, z zakresu 20 - 214. Zatem rozmiar
okna z uwzględnieniem skalowania okna, może mieć wartość do 230 bajtów. Powoduje to
możliwość wykorzystania zwiększonej pojemności łącza. Zauważyć należy, że:
−
skalowanie okna jest ustalane na etapie nawiązywania połączenia i potem jest już, dla danego
połączenia, niezmienne,
−
skalowanie okna jest niezależne dla obu kierunków transmisji.
Istotnym ulepszeniem protokołu TCP było wprowadzenie do niego mechanizmu sterowania
przeciążeniem, realizowanego za pomocą różnych algorytmów [RFC1122][RFC2581] (m. in. Reno,
NewReno[RFC2582][RFC3782], Cubic, High-Speet, Hybla, Westwood). Ideą sterowania
przeciążeniem w protokole TCP jest dodanie do istniejącej w pierwotnej wersji protokołu
możliwości ostrzegania o przeciążeniu odbiorcy (realizowanego poprzez zmniejszenie okna
odbiorczego), możliwości oddzielnego ostrzegania o przeciążeniu sieci. Podstawową oznaką
przeciążenia jest strata pakietu, o której nadawca może się dowiedzieć na skutek upłynięcia czasu
RTO lub otrzymania powielonych potwierdzeń. Wykorzystywane mogą być cztery fazy pracy
algorytmów - slow start, congestion avoidance, fast retransmit i fast recovery, w różnych
modyfikacjach. Skutkiem zastosowania mechanizmów sterowania przepływem jest elastyczne
dostosowywanie się szybkości przepływu TCP do dostępnej szybkości łącza, bez niepotrzebnych
retransmisji. Fakt, że zmiany konieczne są tylko po stronie nadawczej zapewnia kompatybilność z
wcześniejszymi implementacjami.
Kanał steganograficzny w oknie odbiorczym protokołu TCP
Steganografia sieciowa jest dziedziną stosunkowo nową. Metody steganografii sieciowej
wykorzystują modyfikacje pól nagłówków protokołów (np. dla IP - pola ToS, Fragment ID, Flags,
pole opcji; dla TCP - Initial Sequence Number, pole zarezerwowane, wskaźnik ważności, pole
opcji), zależności czasowych lub strat pakietów, niekiedy łącznie. Proponowana metoda tworzy
kanał steganograficzny za pomocą mechanizmu okna odbiorczego protokołu TCP.
Z uwagi na fakt, że, niezależnie od tego, czy i jak zostało uzgodnione skalowanie okna, odbiorca
ma do dyspozycji 16-bitową rozdzielczość anonsowanego nadawcy rozmiaru okna, może on, w
uzgodnieniu z nadawcą, ustalić alfabet, mówiący o tym, jak poszczególne wartości przesyłane w
polu rozmiaru okna, będą kodować symbole przesyłane w sposób ukryty. Najprostsze, naiwne
kodowanie, może np. przyporządkowywać „0” symbolom parzystym i „1” symbolom
nieparzystym. Tym samym stworzony zostanie kanał steganograficzny o przepływności 1 bitu na
pakiet.
Informacja ukryta jest w tym kanale przesyłana w kierunku odwrotnym do informacji użytecznej symbole ukryte są przesyłane w pakietach potwierdzających otrzymane przez odbiorcę dane.
Połączenie TCP jest jednak dwukierunkowe, a więc proponowana metoda pozwala na zestawienie
w ramach jednego połączenia dwóch niezależnych kanałów steganograficznych.
Utworzony w ten sposób kanał nie gwarantuje dostarczenia informacji ukrytej: pakiety, niosące
ukryte symbole, podlegają normalnym regułom transmisji i, podobnie do zwykłych pakietów, mogą
zostać odrzucone lub utracone. Zatem:
−
kanał powinien być używany do przesyłania informacji mało wrażliwej na częściową utratę,
albo
−
należy zapewnić mechanizm potwierdzeń i retransmisji, np. z wykorzystaniem przeciwnie
skierowanego kanału steganograficznego w ramach tego samego połączenia TCP; taki
mechanizm może być zbliżony do mechanizmów stosowanych przez protokoły warstwy
aplikacyjnej, wykorzystujące protokół UDP, np. TFTP czy DNS.
Przepływność uzyskanego kanału zależy od zastosowanego kodowania, które z kolei nie może być
dowolne, żeby wykrycie transmisji nie było trywialne. Górnym (teoretycznym) ograniczeniem jest
przypadek, kiedy wszystkie bity pola wielkości okna są użyte do kodowania symbolu ukrytego.
Odpowiada to przepływności 16 bitów (2 bajtów) na pakiet. W zależności od rozmiaru pakietu
odpowiada to różnej części przepływności kanału-nośnika. Dla pakietów krótkich, nie niosących
danych wyższych warstw, a jedynie nagłówki warstwy sieciowej (IP) i transportowej (TCP), jak ma
to miejsce w pakietach potwierdzeń, jest to typowo 2/(20+20)=5% przepływności. Dla pakietów
długich, niosących dane użyteczne, jest to typowo 2/(20+20+1460)=0,133% przepływności.
Rozmiar okna odbiorczego, wyznaczany i przeznaczony do wysłania przez oryginalną warstwę
TCP stosu protokołowego, jest skorelowany z ilością miejsca w buforze odbiorczym. Nie może być
z nią identyczny, z uwagi na opóźnienie występujące w swoistej pętli sterowania, pomiędzy
momentem wysłania przez odbiorcę informacji o braku miejsca a momentem, w którym, po
spowolnieniu transmisji przez nadawcę, wysłane wcześniej pakiety przestaną docierać do odbiorcy.
Implementacja systemu steganograficznego, wykorzystującego proponowaną metodę, może
polegać na zmodyfikowaniu oryginalnej warstwy TCP stosu protokołowego i modyfikowaniu
rozmiaru okna wyznaczanego przez oryginalną implementację. Przykładowo w systemie Linux taka
modyfikacja powinna wpływać na rezultaty kodu, znajdującego się w pliku
/usr/src/linux/net/ipv4/tcp_output.c.
Wysyłany przez odbiorcę rozmiar okna można traktować jako sumę rozmiaru wyznaczanego przez
oryginalną implementację oraz dodawanego przez podsystem steganograficzny przyrostu. Ze
względu na możliwość przeciążenia odbiorcy, rozważać należy przede wszystkim przyrosty ujemne
- a więc zmniejszanie oryginalnego rozmiaru okna. Może to oznaczać negatywny wpływ na
szybkość transmisji. Jednak bardzo często to nie rozmiar okna odbiorczego, wysyłany przez
odbiorcę, a rozmiar okna przeciążenia, ustalany przez nadawcę za pomocą jednego z algorytmów
unikania przeciążeń, jest czynnikiem wstrzymującym wysyłanie danych przez nadawcę. Dlatego też
spowolnienie transmisji niekoniecznie musi wystąpić, a nawet jeśli wystąpi - niekoniecznie musi
być znaczące. I znowu mocno zależy to od przyjętego sposobu kodowania symboli
steganograficznych: modyfikacja wszystkich bitów może w istocie spowodować spowolnienie
transmisji, ale modyfikacja tylko bitów najmniej znaczących nie powinna wpływać istotnie na
szybkość transmisji.
Odporność na wykrycie (steganalizę) zależy przede wszystkim od wyboru sposobu kodowania
symboli steganograficznych - poczynając od najprostszych, np. wspomnianego powyżej,
kodującego symbole za pomocą najmłodszego bitu rozmiaru okna, a kończąc na bardziej
zaawansowanych. Zauważyć należy, że sposób kodowania może zostać zapożyczony z innych
odmian steganografii, np. ukrywających informację w obrazach. Można traktować wartość
rozmiaru okna w pakiecie jako analog wartości składowych pojedynczego piksela.
Przeprowadzona przez autora analiza ruchu pokazała, że podczas typowej dłuższej transmisji
niezmodyfikowana warstwa TCP wysyła do nadawcy wiele (ok. 100) różnych wartości rozmiaru
okna. Zatem możliwe jest stosunkowo łatwe ukrywanie symboli pośród wartości rozmiaru okna.
Dodatkowo - możliwe jest takie zmodyfikowanie warstwy TCP, aby celowo zwiększała liczbę
możliwych wartości rozmiaru okna, wprowadzając tym samym szum, w którym ukrycie symboli
będzie jeszcze łatwiejsze. Oczywiście wybór sposobu kodowania powinien być odporny na metody
steganalizy, np. takie jak badanie częstości wystąpień symboli.
Podsumowanie
Proponowana metoda pozwala na utworzenie wewnątrz połączenia TCP dwóch jednokierunkowych
kanałów steganograficznych. W każdym z kanałów informacja jest przesyłana w kierunku
przeciwnym do strumienia informacji użytecznej. Metoda jest elastyczna - pozwala na płynne
sterowanie, za pomocą wyboru schematu kodowania, liczbą bitów ukrytej informacji,
umieszczanych w pakiecie, co ma wpływ na przepływność kanału, ale też i na oczekiwane
spowolnienie transmisji oraz odporność na steganalizę. Metoda znajduje się w fazie koncepcji;
trwają prace, zmierzające do opracowania modyfikacji stosu TCP/IP w systemie Linux,
pozwalającej na przeprowadzenie studium wykonalności, a następnie - badań różnych metod
kodowania symboli steganograficznych i ich odporności na steganalizę oraz wpływu na szybkość
transmisji.
Bibliografia
[CERF74]
V. Cerf, R. Kahn, A Protocol for Packet Network Intercommunication, IEEE
Transactions on Communications, Vol. 22, No. 5, May 1974 pp. 637-648
[RFC675]
Specification of Internet Transmission Control Program. W. Cerf, Y. Dalal, C.
Sunshine. December 1974.
[RFC793]
Transmission Control Protocol. J. Postel. September 1981.
[RFC1122]
Requirements for Internet Hosts - Communication Layers. R. Braden, Ed..
October 1989.
[RFC1323]
TCP Extensions for High Performance. V. Jacobson, R. Braden, D. Borman. May
1992.
[RFC2581]
TCP Congestion Control. M. Allman, V. Paxson, W. Stevens. April 1999.
[RFC2582]
The NewReno Modification to TCP's Fast Recovery Algorithm. S. Floyd, T.
Henderson. April 1999.
[RFC3782]
The NewReno Modification to TCP's Fast Recovery Algorithm. S. Floyd, T.
Henderson, A. Gurtov. April 2004.