Sieci komputerowe — ćwiczenia 7
Temat zajęć: Analiza nagłówków IP, TCP i UDP. Przebieg sesji TCP. Fragmentacja IP.
Strona
domowa Wireshark: www.wireshark.org
Format
nagłówka IP
Struktura nagłówka IP v. 4 (UWAGA: bity numerowane są od 0).
Dodatkowe informacje np. na www.daemon.org/ip.html.
Znaczenie poszczególnych pól:
- Ver — wersja protokołu (4)
- IHL — IP header length —
długość nagłówka IP liczona w 32-bitowych słowach (zwykle 6)
- ToS — type of service —
zwykle 0, jednak może być wykorzystywany przez sieci obsługujące QoS
(qualiy of service)
- Total length — długość całego
datagramu (łącznie z danymi)
- ID — identyfikator,
który wraz z adresem źródłowym jest unikalny;
wykorzystywany przy łączeniu fragmentowanych pakietów
- flg — 3-bitowe pole flag:
pierwszy bit od prawej — flaga More, drugi bit od
prawej — flaga Don't
fragment, trzeci bit nieużywany
- Fragment offset —
przesunięcie w bajtach względem
początku oryginalnego pakietu, używane przy łączeniu
pakietów
fragmentowanych przez routery po drodze
- TTL — time to live —
maksymalna liczba przeskoków (hops), jakie pakiet może
przebyć
- Protocol — oznaczenie
protokołu wewnątrz pakietu IP (np. 1=ICMP, 6=TCP, 17=UDP)
- Header checksum — suma
kontrolna nagłówka — procedurę wyliczania sumy kontrolnej
można znaleźć np. tutaj.
- Source address — adres
nadawcy
- Destination address — adres
odbiorcy
- Options (+padding) — zwykle
nieużywane, może ew. zawierać dodatkowe informacje związane z pakietem
dopełnione zerami (padding) do 32-bitów
- Data — pierwsze słowo danych
(po nim ew. następne)
Format
nagłówka TCP
Struktura nagłówka TCP (UWAGA: bity numerowane są od 0).
Dodatkowe informacje np. na www.daemon.org/tcp.html.
Znaczenie poszczególnych pól:
- Source port — port
źródłowy
- Destination port — port
docelowy
- Sequence number — numer
kolejny (sekwencji) pierwszego
bajtu danych w tym segmencie, za wyjątkiem segmentu SYN — w takim
przypadku jest to początkowy numer sekwencji (ISN — initial sequence
number) i pierwszy bajt danych powinien mieć numer sekwencji ISN+1
- Acknowledgement number —
jeśli w polu Flags ustawiony jest bit ACK
(patrz
niżej), to pole Acknowledgement number zawiera
numer sekwencji, który nadawca tego pakietu spodziewa się
odebrać jako następny
- daof (4 bity) — data offset —
liczba 32-bitowych słów w nagłówku TCP (czyli
offset danych)
- Reserv. — reserved (6 bitów)
— zarezerwowane — musi mieć wartość 0
- Flags (6 bitów) —
pole flag; poszczególne bity (od lewej) oznaczają:
- URG — pole Urgent pointer jest
znaczące
- ACK — pole Acknowledgement
number jest znaczące
- PSH
— funkcja Push (chwilowo nie ma więcej danych u
nadawcy)
- RST — reset
połączenia (wymagane ponowne uzgodnienie sekwencji)
- SYN —
synchronizacja numerów sekwencji
- FIN
— nie ma więcej danych u nadawcy (koniec sesji)
- Window — liczba
bajtów (począwszy od numeru podanego w Acknowledgement
number), które nadawca tego pakietu chce (lub
może) odebrać
- Checksum — suma kontrolna
nagłówka TCP i danych — procedurę wyliczania sumy kontrolnej
można znaleźć np. tutaj.
- Urgent pointer
— wartość tego wskaźnika podawana jest względem numeru
sekwencji bieżącego segmentu; wskazuje on pierwszy bajt po danych typu
urgent (pierwszy bajt "standardowych" danych)
- Options — ew. dodatkowe
parametry (np. maksymalna długość segmentu TCP, która może
być podana w pierwszym pakiecie typu SYN)
- Padding — dopełnienie opcji
zerami do pełnych 32-bitów
- Data — pierwsze słowo danych
Format nagłówka UDP
Struktura nagłówka UDP
(UWAGA: bity numerowane są od 0). Dodatkowe informacje np. na www.networksorcery.com/enp/protocol/udp.htm.
Znaczenie poszczególnych pól:
- Source port — port
źródłowy
- Destination port — port
docelowy
- Length — łączna długość
nagłówka i danych
- Checksum — suma kontrolna —
procedurę wyliczania sumy kontrolnej można znaleźć np. tutaj.
- Data — pierwsze słowo danych
Format nagłówka Ethernet II
Struktura nagłówka warstwy fizycznej typu Ethernet II. Bity numerowane są od 0.
Znaczenie poszczególnych pól:
- Dst — sześciobajtowy adres fyzyczny interfejsu docelowego
- Src — sześciobajtowy adres fizyczny interfejsu źródłowego
- Type — dwubajtowe oznaczenie protokołu wewnętrznego (np. 0x8000 — TCP/IP, 0x8137 — Novell Netware)
- Data — dane (i ew. nagłówki) protokołu wewnętrznego
Analiza protokołów w Wireshark — wstęp
Wireshark
służy do analizy danych wychwyconych z sieci. Jeśli użytkownik posiada
odpowiednie uprawnienia, umożliwia także samo przechwytywanie. W
przeciwnym przypadku możliwa jest analiza off-line, danych
przechwyconych wcześniej i zapisanych w pliku. Na zajęciach będziemy
stosować ten drugi model postępowania.
Okno aplikacji Wireshark (przedstawione poniżej) podzielone jest na kilka sekcji.
Pod
paskiem menu i paskiem narzędzi znajduje się pole filtru. Filtry służą
do odsiewania danych, którymi nie jesteśmy zainteresowani
(składnię filtrów poznamy na kolejnych zajęciach). Dalej mamy
okno danych podzielone na trzy obszary. Pierwszy (od góry)
zawiera listę wszystkich ramek sieciowych, jakie zostały przechwycone
lub znajdują się w załadowanym pliku. Zrzut ekranu u góry
pokazuje ramki generowane przez ping. Kolumny (od lewej) zawierają:
- kolejny numer ramki (No.)
- c
zas względny, liczony od momentu przechwycenia pierwszej ramki (Time)
- źródłowy adres IP
(Source)
- docelowy adres IP (Destination)
- protokół (Protocol)
- dodatkowe informacje, które udało się uzyskać z ramek (Info)
W drugim obszarze znajdują się kolejne warstwy enkapsulacji
protokołów dla wybranej ramki. Na pokazanym wyżej zrzucie mamy
najpierw całą ramkę nr 5. Wewnątrz niej znajduje się ramka Ethernet
typu II, z odpowiednim adresem MAC źródła i odbiorcy. Wewnątrz
ramki Ethernet znajduje się pakiet IP, z odpowiednimi adresami nadawcy
i odbiorcy. Pakiet ten zawiera komunikat ICMP, który (po
rozwinięciu odpowiedniej gałęzi drzewa) okazuje się pakietem typu "Echo
(ping) request".
Trzeci obszar pokazuje surowe dane ramki (bajt po
bajcie i jako kody ASCII). Klikając na danej warstwie w obszarze drugim
automatycznie podświetlany jest odpowiadający jej ciąg bajtów w
obszarze trzecim. Poszczególne warstwy w obszarze drugim można
"rozwijać", oglądając składowe nagłówków
poszczególnych protokołów (odpowiednie dane są zawsze
podświetlane w obszarze trzecim).
W celu analizy
zrzutów z przykładów poniżej należy najpierw zapisać
plik, do którego odnośnik znajduje się w przykładzie, na dysku
lokalnym, a następnie w Wireshark wybrać File|Open i wskazać zapisany plik.
Przykład 1
Zrzut
wykonany na hoście 150.254.76.10, domyślna brama 150.254.76.1, serwer
DNS 150.254.78.2. Plik zawiera wynik działania polecenia
ping -c 1 -s 0 atos.wmid.amu.edu.pl
POBIERZ PLIK
Przykład 2
Zrzut wykonany na hoście 150.254.76.10, domyślna brama 150.254.76.1,
serwer DNS 150.254.78.2. Plik zawiera wynik działania polecenia
traceroute -n ttomek.et.pl
POBIERZ PLIK
Dla porównania rezultat wykonania polecenia, jaki pojawił się na konsoli:
1 150.254.79.193 0.262 ms 0.177 ms 0.174 ms
2 150.254.115.57 1.921 ms 0.675 ms 0.695 ms
3 150.254.71.18 0.517 ms 0.477 ms 0.476 ms
4 150.254.64.5 0.925 ms 1.319 ms 0.878 ms
5 212.191.224.17 16.694 ms 1.423 ms 1.022 ms
6 213.248.77.213 11.896 ms 12.311 ms 11.641 ms
7 213.248.65.177 12.736 ms 11.827 ms 11.527 ms
8 213.248.64.42 26.277 ms 26.257 ms 26.289 ms
9 213.248.64.62 26.855 ms 28.064 ms 28.106 ms
10 80.81.192.16 27.268 ms 26.601 ms 26.750 ms
11 62.242.145.74 27.273 ms 26.992 ms 28.696 ms
12 213.241.1.53 52.759 ms 27.377 ms 27.942 ms
13 81.210.126.114 26.974 ms 28.250 ms 27.841 ms
14 213.241.21.9 28.679 ms 29.154 ms 29.178 ms
15 213.241.121.126 43.928 ms 40.850 ms 38.074 ms
16 62.244.138.65 37.794 ms 37.402 ms 36.915 ms
17 62.244.138.134 36.871 ms 39.542 ms 42.072 ms
Przykład 3
Klient na 192.168.1.6 wysyła do serwera na 192.168.1.200
10000 bajtów protokołem TCP. Następuje fragmentacja (segmentacja) na
poziomie
TCP. Przeanalizować numery sekwencji i potwierdzeń oraz flagi.
POBIERZ PLIK
Przykład 4
Klient na 192.168.1.6 wysyła do serwera na 192.168.1.200
1000 bajtów protokołem TCP. Brak fragmentacji. Przeanalizować numery
sekwencji i potwierdzeń oraz flagi.
POBIERZ PLIK
Przykład 5
Klient na 192.168.1.6 wysyła do serwera na 192.168.1.200 10000 bajtów protokołem UDP. Następuje fragmentacja na poziomie protokołu IP. Przeanalizować offsety fragmentów oraz flagi.
POBIERZ PLIK
Przykład 6
Klient na 192.168.1.6 wysyła do serwera na 192.168.1.200 1000 bajtów protokołem UDP. Brak fragmentacji.
POBIERZ PLIK
Przykład 7
Klient na 150.254.76.10 otwiera połączenie TCP do serwera na 150.254.78.2, po czym zamyka je nie wysyłając żadnych danych. Serwer również zamyka połączenie natychmiast po accept, nie wykonując żadnego recv. Proszę sprawdzić numery potwierdzeń i sekwencji.
POBIERZ PLIK
Przykład 8
Klient na 150.254.76.10 otwiera połączenie TCP do serwera na 150.254.78.2, po czym zamyka je nie wysyłając żadnych danych. Serwer po accept wykonuje jeden raz recv,
który się nie powiedzie (zwraca -1), ponieważ klient zamyka
połączenie nie wysyłając danych. Proszę sprawdzić numery potwierdzeń i
sekwencji.
POBIERZ PLIK
Przykład 7
Klient na 150.254.76.10 otwiera połączenie TCP do serwera na 150.254.78.2 na port 7245, jednak na tym porcie nie nasłuchuje żadna aplikacja.
POBIERZ PLIK
Zadanie 1
Porównując
zrzuty z przykładu 4 i przykładu 6 proszę sprawdzić, ile faktycznie
bajtów (wliczając w to nagłówki i komunikaty kontrolne
wszystkich protokołów) zostaje przesłanych w przypadku
transmisji 1000 bajtów za pomocą TCP i za pomocą UDP.
Zadanie 2
Klient na 150.254.76.10 wysyła do serwera na 150.254.78.2
łącznie 4000 bajtów protokołem TCP. Proszę na podstawie analizy
zrzutu z tej sesji domyślić się ile razy klient wywołał funkcję send.
POBIERZ PLIK
Zadanie 3
W pliku znajduje się wynik działania ping -c 10 -s 20 192.168.1.200, uruchomionego na 192.168.1.6.
Proszę poszukać w zasobach Internetu formatu nagłówka ICMP i
porównać z analizą w Wireshark (wskazówka: wpisać w google
"ICMP header format").
POBIERZ PLIK