Magazyn plików

(7) Sieci komputerowe

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