Dokument ten powstał na potrzeby wykładu prowadzonego przeze mnie dla PLUG Poznań.

[web]:: http://plug.poznan.mtl.pl/ [email]:: plug@poznan.mtl.pl

User Datagram Protocol (UDP)

UDP jest protokołem zapewniającym procedury, które umożliwiają wysyłanie wiadomości z minimalnym nakładem mechanizmów do tego potrzebnych.UDP daje aplikacją bezpośredni dostęp do usług rozsyłania datagramów, podobnych do usług oferowanych przez IP. UDP nie posiada żadnych mechanizmów umożliwiających kontrole czy wysyłane dane dotarły poprawnie do miejsca przeznaczenia czy też nie zostały powtórnie wysłane.UDP do określenia aplikacji nadającej i odbierającej dane wykorzystuje pierwsze słowo nagłówka wiadomości, zawierające numery portu źródłowego i portu przeznaczenia transmisji.

 bity  ----->    0        8       16       24       32
                 +--------+--------+--------+--------+
                 |       Port      |       Port      |
                 |     źródłowy    |  przeznaczenia  |
                 +--------+--------+--------+--------+
                 |                 |                 |
                 |     Długość     |  Suma kontrolna |
                 +--------+--------+--------+--------+
                 |                                   |
                 |          początek danych          |
                 +-----------------------------------+

                 format nagłówka UDP

• Port źródłowy: numer portu źródłowego transmisji, pole opcjonalne jeżeli nie jest używane wstawia się wartość 0, ten port może służyć do wysyłania odpowiedzi w przypadku innych informacji
• Port przeznaczenia: numer portu przeznaczenia transmisji
• Długość: całkowita długość datagramu (nagłówek + dane) wyrażona w bajtach
• Suma kontrolna: suma kontrolna dla nagłówka i danych

Transmission Control Protocol (TCP)

TCP jest protokołem połączeniowym, działającym na strumieniach bajtów. Posiada on mechanizm PAR (Positive Acknowledgment with Retransmission), czyli mechanizm potwierdzenia z retransmisją.PAR polega na wysyłaniu danych dopóki nie otrzyma wiadomości, że wysłane dane przeszły bezbłędnie.Blok danych, który wymieniają między sobą współpracujące moduły TCP nazywa się segmentem.

bity -->  0                   1                   2                   3
     -->  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |        Port źródłowy          |          Port docelowy        |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                        Numer sekwencji                        |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                      Numer potwierdzenia                      |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          | Offset|           |U|A|P|R|S|F|                               |
          | danych|Zarezerwo- |R|C|S|S|Y|I|             Okno              |
          |       |   wane    |G|K|H|T|N|N|                               |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |         Suma kontrolna        |         Pilny wskaźnik        |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                    Opcje                      |     Puste     |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                             dane                              |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 formatu nagłówka segmentu TCP

• Port źródłowy: numer portu źródłowego, wielkość 16 bitów
• Port docelowy: numer portu docelowego, wielkość 16 bitów
• Numer sekwencji: kolejny numer pierwszego oktetu (bajtu) w tym segmencie (tylko gdy nie jest obecny SYN), jeśli obecny jest SYN to numerem sekwencji jest ISN, a pierwszy oktet danych to ISN +1, wielkość 32 bity
• Numer potwierdzenia: jeśli ustawiony jest bit ACK, to pole zawiera wartość następnego numeru sekwencji, który nadawca segmentu spodziewa się otrzymać, gdy połączenie zostanie już ustalone wartość ta jest zawsze wysyłana, wielkość 32 bity
• Offset danych: liczba 32 bitowych słów w nagłówku TCP, wskazuje początek danych, nagłówek TCP (nawet zawierający opcje) jest integralną 32 bitową liczbą, wielkość 4 bity
• Zarezerwowane: pole musi mieć wartość 0, zarezerwowane na przyszłość, wielkość 6 bitów
• Bity kontrolne:
  URG: oznaczenie pola pilnego wskaźnika
  ACK: oznaczenie pola potwierdzenia
  PSH: funkcja przepychania
  RST: zresetuj połączenie
  SYN: zsynchronizuj numer sekwencji
  FIN: nie pobieraj więcej danych od nadawcy jest to 6 pojedynczych wartości bitowych
• Okno: liczba oktetów danych (bajtów), które nadawca zgodzi się przyjąć, wielkość 16 bitów
• Suma kontrolna: Każdy segment zawiera sumę kontrolną, która jest wykorzystywana przez odbiorcę do kontroli poprawności danych.Jeżeli segment danych został odebrany bez błędów, odbiorca wysyła potwierdzenie otrzymania danych do nadawcy.Jeżeli odebrany segment jest uszkodzony odbiorca odrzuca go.Po odpowiednim czasie moduł TCP wysyłający dane ponawia transmisję segmentu, dla którego nie otrzymał potwierdzenia.
• Pilny wskaźnik: pole zawiera bieżącą wartość wskaźnika o tej samej nazwie (pilny wskaźnik) jako dodatni offset kolejnego numeru tego segmentu, pliny wskaźnik wskazuje numer sekwencji oktetu znajdującego się za pilnymi danymi, pole jest interpretowane tylko w segmentach z ustawionym bitem URG, wielkość 16 bitów
• Opcje: opcje zajmują przestrzeń na końcu nagłówka TCP, a ich długość jest wielokrotnością 8 bitów, wielkość zmienna

handshake

TCP jest protokołem połączeniowym.Ustanawia logiczne połaczenie pomiędzy komunikującymi się hostami.Przed właściwą transmisją hosty wymieniają komunikaty kontrolne - handshake.TCP stosuje potwierdzenie trójpoziomowe (three-way handshake), ponieważ podczas ustalania połączenia wymieniane są trzy segmenty kontrolne.

      host A                    host B
  +------------+            +------------+
  |    SYN ----|------------|----->      |
  |            |            |     |      |
  |            |            |  SYN,ACK   | 
  |            |            |     |      |
  |     <------|------------|------      |
  |     |      |            |            |
  |  ACK,dane  |            |            |
  |     |------|------------|----->      |
  |            |            | początek   |
  |            |            | transmisji |
  +------------+            +------------+

     tree-way handshake

Podsumowanie

TCP interpretuje wysłane dane jako ciągły strumień bajtów, a nie jako niezależne pakiety.Z tego powodu ważne jest zachowanie kolejności w jakiej bajty zostaną wysłane i odebrane.Do tego celu służą umieszczone w nagłówku pola numer sekwencyjny i numer potwierdzenia.Dla standardu TCP nie jest istotne, od jakiej liczby system rozpocznie numerację bajtów, ponieważ każdy system wybiera sobie sam liczbę początkową.Żeby kolejność bajtów u nadawcy i odbiorcy była identyczna, muszą znać wybrane przez siebie numery początkowe.Numery te wymieniane są w segmentach potwierdzenia z ustawionym bitem SYN.Pole numer sekwencji w segmencie SYN zawiera ISN (Initial Sequence Number), czyli początkowy numer sekwencji, od którego numerowane są przychodzące bajty danych.Ze względów bezpieczeństwa ISN powinien być wybrany losowo, często jednak nadaje mu się wartość 0.

Bajtom danych nadane są numery kolejne począwszy od ISN, a pierwszy bajt danych ma numer ISN + 1.Numer sekwencji w nagłówku segmentu danych określa pozycję w strumieniu danych pierwszego bajtu w przesyłanym segmencie.Jeżeli na przykład pierwszy bajt w strumieniu danych miał numer 1 (ISN = 0) i przeszło już 4000 bajtów danych to pierwszy bajt w kolejnym segmencie będzie bajtem 4001, a numer sekwencji wyniesie 4001.

Segment z ustawionym bitem potwierdzenia (ACK) pełni dwie funkcje. Potwierdza otrzymanie danych i steruje ich przepływem.Informuje on nadawcę w jakim stanie doszły dane oraz ile odbiorca może ich jeszcze przyjąć.Liczba w polu numer potwierdzenia zawiadamia nadawcę jaki numer sekwencyjny odbiorcy spodziewa się znaleźć w kolejnym segmencie danych. Standard nie wymaga potwierdzenia każdego segmentu danych.Segment potwierdzający poświadcza odbiór wszystkich danych od początku transmisji. Jeżeli na przykład pierwszy wysłany bajt danych miał numer 1 a do tej pory prawidłowo odebrano 2000 bajtów to liczba w polu numer potwierdzenia będzie wynosiła 2001.

Pole okno zawiera liczbę bajtów, które może przyjąć odbiorca (wielkość ta nazywa się również oknem).Jeżeli odbiorca jest w stanie przyjąć jeszcze 6000 bajtów, okno będzie miało wartość 6000.Nadawca może wysyłać segment tak długo, dopóki sumaryczna liczba wysyłanych bajtów nie przekroczy wartości okna.Za pomocą okna odbiorca steruje przepływem danych pomiędzy nim i nadawcą.Okno o wartości 0 nakazuje nadawcy wstrzymanie transmisji do momentu, dopóki odbiorca nie prześle segmentu z oknem o niezerowej wartości.

                 |-------------okno długości 6000 bajtów--------------------|
                 |                                                          |
|                |                                                          |
|-dane odebrane--|                   |sb |                                  |
|                |                   |   |                                  |
|1_____|1001_____|2001_____|3001_____|4001_____|5001_____|6001_____|7001____|
|                |                   |
|                |                   |
|                |                   |
poczatkowy numer numer potwierdzenia numer sekwencyjny
sekwencyjny 0    2001                4001
                 

strumień danych TCP

sb - segment bieżący

Techniki skanowania

- Ping scanning

ping za pomocą protokołu ICMP wysyła pakiet z zapytaniem o echo.Host, który jest odpytywany nie musi mieć otwartych portów, ponieważ stos TCP/IP wymaga aby odpowiedział na takie zapytanie nawet, gdy nie dostarcza żadnych usług.Wydawać się może, że wszystkie hosty, które mają poprawnie skonfigurowany routing odpowiedzą na ping i w ten sposób dowiemy się czy w ogóle istnieją.Jednak tak nie jest można ukryć się przed pingiem, a jak to zrobić pokarzę później.

- TCP connect() scan

Jest to podstawowa i najprostsza metoda skaningu.Używa ona funkcji systemowej connect() do nawiazania pełnego połączenia z interesującymi nas portami. Jeżeli skanowany port jest otwary, wówczas dochodzi do połączenia.W przeciwnym razie oznacza to, że dany port nie jest osiągalny czyli żadna usługa nie pracuje na nim.Zaletą TCP connect() jest to, iż nie potrzebujesz uprawnień administratora, aby z niej korzystać oraz jest to w miarę szybkie rozwiązanie Natomiast wadą jest łatwe wykrycie takiego skanu.W logach pozostaje wyraźny ślad.

- TCP SYN scan

Często nazywa się również tą technikę half-open, ponieważ korzystając z niej nie dochodzi do pełnego połączenia TCP.Osoba wykonująca skaning wysyła segment z ustawionym bitem SYN do skanowanej maszyny, tak jak ma to miejsce podczas próby nawiązania normalnego połączenia.Jeżeli skanowany host odpowie segmentem z ustawionym bitem SYN/ACK oznacza to, że dany port na tej maszynie jest otwarty.Jeżeli otrzymamy segment z ustawionym bitem RST oznacza to, że port jest niedostępny.Nie chcąc nawiązać połączenia tak jak ma to miejsce w TCP connect(), do skanowanej maszyny wysyłany jest segment z ustawionym bitem RST, który nakazuje kernelowi zerwać połączenie.Ta technika jest lepsza od TCP connect(), ale również małym nakładem pracy możemy ją wykryć, poza tym chcąc z niej korzystać potrzebne są uprawnienia roota.

- TCP FIN scan

Inaczej stealth scanning, polegający na wysyłaniu segmentów z ustawionym bitem FIN.Zgodnie z RFC 793 otwarte porty nie odpowiedzą na FIN, natomiast te porty które są zamknięte muszą odpowiedzieć bitem RST.Technika ta jednak nie sprawdzi się w przypadku Windows 95/NT jak i Cisco, BSDI, HP/UX, MVS oraz IRIX.Dlaczego tak jest ? Zapewne ktoś postanowił nie brać pod uwagę RFC i samemu "lepiej" to zrobić.Plusem w takiej sytuacji jest sposób odróżnienia Windows od innego OSa.Na przykład FIN scanning maszyny pokazuje, że wszystkie porty na niej są zamknięte, a SYN scanning pokazał, iż pewne porty są otwarte. Jest to wówczas prawdopodobnie Windows.W innym przypadku, gdy skanujemy maszynę techniką FIN i pewne porty są otware mamy pewność, iż nie jest to Windows.Tak jak w poprzednim przypadku musimy mieć uprawnienia administratora, by korzytać z FIN scanningu.

- FTP bounce attack

Podczas skanowania tą techniką skaner sprawdza czy serwer jest podatny na atak typu FTP bounce.Atak ten polega na wykorzystaniu pewnej ciekawej cechy protokołu FTP.Otóż podczas przesyłania danych FTP wykorzystuje dwa porty do różnych zadań.Port 21 jest wykorzystywany do przesyłania informacji między naszym hostem, a hostem odległym, czyli na tym porcie jest połączenie kontrolne.Natomiast port 20 jest wykorzystywany do przesyłania danych.Protokół FTP wykorzystuje polecenie PORT do kontrolowania połączenia, które informuje o porcie oraz IP klienta łączącego się z serwerem.Jeżeli za pomocą PORT wyślemy informację do serwera, że numerem portu oraz IP klienta to nasz obiekt skanu wówczas serwer, z którym się połączyliśmy wyśle dane na wskazany przez nas port ofiary.Następnie jeśli serwer, z którym się łączymy otrzyma odpowiedź informującą o błędzie od skanowanego hosta wiemy, iż ten port jest zamknięty.W przeciwnym razie przypuszczamy, że port jest otwarty.Ta technika sprawdza się tylko, gdy serwer FTP nie porównuje adresu IP przesłanego przez polecenie PORT z adresem IP połączenia kontrolnego.

- UDP scan

Ta technika skanowania polega na sprawdzeniu, które porty UDP są dostępne. Ponieważ w UDP nie ma handshake, tak jak to ma miejsce w TCP, trudniej określić, które porty są otwarte.W tej metodzie posyła się pakiet UDP do każdego portu badanej maszyny i czeka na odpowiedź.Jeżeli otrzymamy komunikat ICMP_PORT_UNREACH, wówczas wiemy, że sprawdzany port jest zamknięty.W przeciwym razie, gdy nie otrzymamy takiej wiadomości port jest otwarty lub jest to port za firewallem, ponieważ w takim przypadku również nie otrzymamy odpowiedzi.Ta technika może być wyjątkowo wolna jeżeli nasz obiekt starań posłuchał rady z RFC 1812 (sekcja 4.3.2.8) i ograniczył tempo wysyłania wiadomości ICMP oznajmujących bład.W kernelu 2.2.x jest to zdefiniowane w net/ipv4/icmp.c.Oczywiście Microsoft i jego asy nie wiedzą co to RFC i ich to ograniczenie nie dotyczy, dlatego Windowsa skanuje się znacznie szybciej. Uprawnienia roota są niezbędne do korzystania z UDP scanningu.

- ACK scan

Skanowanie tą metodą służy głównie do sprawdzania firewalli.Dzięki tej technice możemy określić czy firewall jest typu stateful, czy też zwykłym filtrem pakietów blokującym pakiety z ustwawionym bitem SYN.Pomysł polega na tym, iż wysyłane są pakiety z ustawionym bitem ACK wraz z losowo wyglądającym numerem potwierdzenia.Jeżeli wróci do nas pakiet z RST wówczas taki port uważa się za niefiltrowany, a jeżeli otrzymujemy ICMP unreachable, lub też żaden komunikat, port uznaje się za filtrowany.Zwykły użytkownik nie może korzystać z tej metody, potrzebne są uprawnienia admina.

- Window scan

Jest to technika bardzo podobna do ACK scanningu.Różnica polega na tym, iż czasami dzięki wielkości okna (w protokole TCP), a właściwie różnym ich wielkością można określić czy port jest otwarty.Oczywiście poza tym czy port jest filtrowany czy też nie.Jak podaje Fyodor w dokumentacji do nmap głównie systemy, które są na to podatne to: Amiga, BeOS, BSDI, Cray, Tru64 UNIX, DG/UX, OpenVMS, Digital UNIX, FreeBSD, HP-UX, OS/2, IRIX, MacOS, NetBSD, OpenBSD, OpenStep, QNX, Rhapsody, SunOS 4.X, Ultrix, VAX, VxWorks oraz pewne AIXy.Linux 2.2.x nie jest podatny, nie wiem jak z innymi wersjami kernela. Oczywiście uprawnienia roota wymagane.

- Reverse ident

Ta technika działa podobnie jak TCP connect().Również nawiązuje pełne połączenie z hostem, a gdy już to zrobi stara się za pomocą protokołu ident sprawdzić kto jest właścicielem procesu słuchającego na danym porcie. Ta technika nie będzie działać jeżeli skanowany host nie ma uruchomionego demona ident.

- Fragmentacja

Istnieje też technika polegająca na fragmentacji pakietów i jest wykorzystywana w SYN i FIN scanningu.Polega ona na fragmentacji nagłówka TCP na kilka mniejszych pakietów, zmniejszając tym szanse na odrzucenie go przez firewall.Tak jak poprzednio nie można skanować tą metodą będąc userem.

- ip.id

Autorem tej techniki jest antirezer.Największą zaletą ip.id dla skanującego jest możliwość sfałszowania pola source address, dzięki czemu w logach skanowanego hosta nie pojawi się nasz adres.Niestety, aby móc z tej techniki korzystać potrzebny nam będzie jeszcze jedne host nie wysyłający pakietów, czyli poprosu maszyna stojąca sobie cicho w Sieci :-).Jak sprawdzić czy host nie wysyła w danej chwili pakietów ? Można to zrobić za pomocą programu hping2 [1], również autorstwa antirezera.W dokumentacji tego programu jest dokładnie opisane jak to zrobić, a najważniejszą rzeczą jest pole id, które zwiększając swoją wartość o +1 (id=+1) inforuje, że dana maszyna pomiędzy zapytaniami od naszego hosta nie wysłała żadnych innych pakietów.

# hping B -r
HPING B (eth0 xxx.yyy.zzz.jjj): no flags are set, 40 data bytes
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=0 ttl=64 id=41660 win=0 time=1.2
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=1 ttl=64 id=+1 win=0 time=75 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=2 ttl=64 id=+1 win=0 time=91 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=3 ttl=64 id=+1 win=0 time=90 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=4 ttl=64 id=+1 win=0 time=91 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=5 ttl=64 id=+1 win=0 time=87 ms

Próby zabezpieczenia się przed skanowaniem

Wszystkie techniki opisane wyżej, poza ip.id, są zaimplementowane w skanerze nmap [2].Skanerem, który wykorzystuje technikę ip.id jest na przykład idlescan [3].Dobra teraz trochę o tym jak możemy się zabezpieczyć przed skanowaniem.Jeżeli chodzi o program ping, możemy uciszyć naszą maszynę tak, aby nie odpowiadała na ICMP echo request na przykład za pomocą filtra pakietów.

Linux 2.0:  # ipfwadm -I -a deny -P icmp -S 0.0.0.0/0 8
Linux 2.2:  # ipchains -I input -p ICMP --icmp-type echo-request -j DENY
Linux 2.4:  # iptables -I INPUT -p ICMP --icmp-type echo-request -j DROP

127.0.0.1    * FreeBSD, NetBSD, OpenBSD

# nmap -O -vv www.openbsd.org

Remote operating system guess: Solaris 2.6 - 2.7
OS Fingerprint:
TSeq(Class=RI%gcd=1%SI=7CFBF)
T1(Resp=Y%DF=Y%W=2297%ACK=S++%Flags=AS%Ops=NNTNWME)
T2(Resp=N)
T3(Resp=N)
T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=Y%W=0%ACK=S%Flags=AR%Ops=)
PU(Resp=N)

# nmap -O -vv www.freebsd.org

Remote operating system guess: FreeBSD 2.2.1 - 4.0
OS Fingerprint:
TSeq(Class=RI%gcd=1%SI=42A2E)
T1(Resp=Y%DF=Y%W=402E%ACK=S++%Flags=AS%Ops=M)
T2(Resp=N)
T3(Resp=Y%DF=Y%W=402E%ACK=S++%Flags=AS%Ops=M)
T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=F%RIPCK=F%UCK=0%ULEN=134%DAT=E)

T3(Resp=Y%DF=Y%W=402E%ACK=S++%Flags=AS%Ops=M)

/proc/sys/net/ipv4/ip_default_ttl