Możliwych modyfikacji jest co najmniej kilka. Za przykład jednej z nich może posłużyć wpływanie na generowanie ISN w taki sposób, żeby zawierał on znaki ASCII, które chcemy przekazać (np. litera "o" po przetworzeniu dałaby ISN o wartości 1096236). Jest to bodajże najprostsza z wykorzystywanych metod i obecnie nie jest zbyt skuteczna z kilku powodów. Pierwszy - jej ukrycie wymaga wysyłania także "normalnych" pakietów, a to znacznie spowalnia prędkość transmisji. Drugi - działanie to pozostawia wiele na wpół otwartych połączeń, co z kolei musi wzbudzać podejrzenia. Jeżeli zapora, stojąca na naszej drodze do szczęścia, jest prostym filtrem pakietów, to mamy szansę, ale wtedy pojawia się przecież tyle innych możliwości.

Inna z metod tunelowania danych w protokole TCP jest nieco bardziej wyszukana i w skrócie polega na "odbijaniu" pakietów. Pakiety kierowane są na niczego niespodziewającego się hosta w sieci, który przekazuje je do ostatecznego celu. Metoda ta wykorzystuje więc mechanizm podszywania się (spoofingu).

Najbardziej znanym i dość starym narzędziem typu PoC (Proof of Concept), wykorzystującym ukrywanie w protokole TCP, jest Covert_TCP. Chowa on informacje wewnątrz trzech pól w ramach nagłówka TCP: IP number, Sequence number oraz ACK number, przy czym domyślnie wykorzystywane jest jedynie pole IP number, stanowiące czwarty i piąty bajt nagłówka. Mimo swojej niewielkiej objętości narzędzie to daje dość spore możliwości, choć jest potwornie wolne i stanowi bardziej ciekawostkę niż rzecz do zastosowania w rzeczywistości. Co ciekawe, niektóre zapory nawet dziś dają się nabrać na sztuczki Covert_TCP. Wystarczy jednak średnio zaawansowane proxy aplikacyjne lub dobry firewall z antyspoofingiem i... w zasadzie po sprawie. Spadkobiercą Covert_TCP w prostej linii jest inne, bardziej zaawansowane narzędzie - Ncovert (http://ncovert.sourceforge.net).

Są jednak znacznie bardziej przemyślne rozwiązania niż Covert_TCP, których działanie nie jest proste w wykryciu. Wystarczy wspomnieć o LKM (Loadable Kernel Module) o wdzięcznej nazwie Nushu, zaprezentowanym przez Joannę Rutkowską w 2004 r. na konferencji 21th Chaos Communication Congress w Berlinie. Novum tego rozwiązania polega na tym, że aplikacja ta nigdy sama z siebie nie generuje ruchu. Wykorzystuje komunikację generowaną przez inne moduły. Ponadto Nushu funkcjonuje na poziomie jądra systemu operacyjnego (Linuxa z jądrem 2.4.x). Dodatkowo tworzone przez nią zmiany w ISN są szyfrowane. To sprawia, że Initial Sequence Nunmber wygląda wystarczająco losowo, żeby wykrycie anomalii nie było superłatwe. Powyższy opis Nushu jest bardzo skrótowy i nie oddaje jego zaawansowania. Zainteresowani dogłębnym poznaniem koncepcji powinni sięgnąć do godnej polecenia strony WWW pani Joanny (http://invisiblethings.org ).

Jeżeli chodzi o protokół UDP, to nie daje on zbyt dużych możliwości kamuflażu ze względu na bardzo niewielki rozmiar pakietu. Nie będziemy mu więc poświęcać uwagi.

Bardzo ciekawym protokołem funkcjonującym w warstwie transportowej jest wszystkim doskonale znany DNS (Domain Name System). Odpowiada on za przechowywanie w rozproszonej bazie danych informacji o domenach oraz ich wyszukiwanie. Rozwiązuje on adresy IP na nazwy i vice versa, wyszukuje serwery pocztowe wykorzystując rekordy MX. DNS korzysta z komunikacji synchronicznej według schematu zapytanie - odpowiedź.

Tutaj również modyfikacja pól daje możliwości tunelowania danych i sprawiania, że generowany przez nas ruch będzie wyglądał jak niewinne zapytania. Do tego celu najczęściej wykorzystywane są pola QNAME oraz NAME. Pole QNAME zawiera ciąg znaków, które stanowią zapytanie o adres hosta (wg RFC powinien mieć format FQDN - Fully Qualified Domain Name). Ze względu na charakter swojej zawartości długość tego pola określona została na 255 bajtów. Z kolei pole NAME zawiera FQDN, do którego odnosi się rekord danego zasobu i tak jak QNAME ma możliwość pomieszczenia 255 bajtów danych. Do tunelowania może posłużyć wiele innych pól.

Ilość danych, które mogą być ukryte, zależy od rodzajów poszczególnych rekordów w ramach bazy DNS. Do najpopularniejszych z nich należą rekordy TXT, pozwalające na przechowywanie dowolnych treści o wielkości do 220 bajtów. Jeszcze niedawno wydawało się, że ze względu na oczywiste furtki do nadużyć rekordy te przestaną być używane. Nic bardziej mylnego. Za sprawą mnożących się silników antyspamowych korzystających z SPF (Sender Privacy Framework) rekordy TXT wracają do łask.

Innym przykładem rekordu wprost stworzonego do "ciuciubabki" jest niewątpliwie CNAME. Nie daje co prawda takiej dowolności w formie przechowywanych informacji jak TXT (ograniczenie do liter od A do Z, cyfr od 0 do 9 oraz myślnika), ale z długością 110 bajtów na pewno nie jest ułomkiem. Jest jeszcze jeden wart uwagi mechanizm, z którego korzystają niektóre serwery DNS (m.in. serwer DNS w Windows 2003) - EDNS0 (Extended DNS). Pozwala on na wzajemne informowanie się serwera i klienta o tym, czy są w stanie poradzić sobie z datagramami większymi niż 512 bajtów.

Obecnie autorowi znanych jest kilka działających rozwiązań wykorzystujących tunelowanie w protokole DNS. Pierwszym z nich jest NSTX, którego poprawne skonfigurowanie zabiera lata świetlne. Jest też OzyManDNS, skrypt napisany w Perlu przez prawdziwego specjalistę od DNS - Dana Kaminsky'ego. OzyManDNS jest nieco prostszy w uruchomieniu, ale także wymaga gimnastyki. Najprostszy w użyciu jest iodine (http://code.kryo.se/iodine/ ). Wprawnemu użytkownikowi skonfigurowanie tego "wytrycha" nie powinno zająć więcej niż dwadzieścia minut. Jest jeszcze podobnie działająca aplikacja napisana w Javie - DNSCat (http://tadek.pietraszek.org/projects/DNScat ).

Bez względu na narzędzie, które wybierzemy, jest tylko jedno "ale". By móc skorzystać z któregoś z nich, trzeba przede wszystkim mieć dostęp do skonfigurowanego serwera DNS, posiadać na nim uprawnienia administracyjne i dysponować wolną maszyną, która posłuży jako serwer dla "wytrycha". Trochę dużo, ale co to dla nas.

Jeżeli chodzi o drugą stronę medalu, tj. wykrywanie, bardzo dobrze sprawdza się analiza anomalii przy użyciu metod statystycznych. Przykład: podejrzenie na pewno wzbudzi stacja, która wykonuje bardzo częste zapytania do nieznanego, zewnętrznego serwera DNS. Do tego tunelowanie danych w DNS powoduje, że w sposób znaczący rośnie utylizacja łącza dla ruchu na porcie 53, co nie jest normalne. W normalnej sytuacji "waga" ruchu na tym porcie powinna być niewielka. Można zaprzęgać IPS-y zarówno sprzętowe, jak i programowe. Dobrym narzędziem do monitorowania zapytań DNS jest DNStop (http://dns.measurement-factory.com/tools/dnstop/ ). A jak najprościej zablokować możliwość tworzenia tuneli DNS przez użytkowników? Najlepiej uruchomić proxy DNS wewnątrz LAN i zezwolić użytkownikowi na wysyłanie zapytań tylko i wyłącznie do niego.

Siódemka to szczęśliwa liczba

Możemy teraz śmiało przystąpić do najbardziej rozbudowanej pod względem możliwości tunelowania warstwy siódmej. Mnogość protokołów funkcjonujących na tym poziomie oraz bliskość użytkownika sprawia, że wybór jest naprawdę spory i nietrudno znaleźć coś dla siebie. Nie będziemy opisywać wszystkich potencjalnych możliwości. Dla naszkicowania obrazu wystarczy w zupełności kilka przykładów.

Użytkownicy, żeby mogli pracować, muszą mieć dostęp do stron WWW czy poczty. Do tego niezbędne są takie protokoły jak HTTP czy SMTP. O ile z pocztą dosyć łatwo sobie poradzić - wystarczy ograniczyć możliwość komunikacji SMTP wyłącznie do firmowego serwera poczty, o tyle z ruchem webowym nie jest już tak różowo. Często zdarza się, że ze względu na specyfikę niektórych mechanizmów wykorzystywanych przez serwery WWW urządzenia filtrujące zwyczajnie uniemożliwiają przeglądanie stron. To powoduje oburzenie, także prezesa. Trzeba więc bardzo ostrożnie przesiewać ruch, a spora część firm ogranicza się tylko do kontroli pod kątem obecności wirusów. To daje olbrzymie pole do popisu pasjonatom ukrywania i tunelowania.

Jednym z najprostszych i jednocześnie najstarszych rozwiązań jest Reverse WWW Shell. Doskonale nadaje się do kontrolowania z zewnątrz komputera, który znajduje się w sieci firmowej. Niby nic nowego... Cały trik polega tutaj na tym, że wszystko dzieje się pod pozorem zwykłego ruchu HTTP. Wystarczy zainstalować Reverse WWW Shell na komputerze w firmie, a ten w określonych odstępach czasu będzie komunikował się na porcie 80 z określonym komputerem. Jeżeli uda mu się połączyć, będziemy mogli wydawać polecenia. Jeżeli podejrzymy co robi RWWWShell podczas komunikacji, zobaczymy, że pakiety wyglądają jak zwykłe HTTP GET czy HTTP POST. Widać więc jak doskonale RWWWShell maskuje swoje działanie.