Laboratorium Sieci Komputerowych - 2 Analiza prostych protokołów sieciowych Górniak Jakub Kosiński Maciej 4 maja 2010 1 Wstęp Zadanie polegało na przechwyceniu i analizie komunikacji zachodzącej przy użyciu protokołów ARP, DHCP, TCP i UDP. Wykonywaliśmy je na maszynach M3 i V6. 2 ARP Pierwszym protokołem który badaliśmy był ARP - Address Resolution Protocol, pozwalający na tłumaczenie adresów IP na adresy MAC. Lista najczęściej używanych adresów jest przechowywana w liście podręcznej. W przypadku gdy nie ma na niej poszukiwanego adresu, komputer wysyła zapytanie na broadcast sieci. Zapytanie to zawiera IP i MAC źródła i IP przeznaczenia. Każdy komputer w sieci porównuje IP przeznaczenia z wpisem w swojej pamięci podręcznej, i jeżeli się zgadzają, wysyła odpowiedź bezpośrednio do pierwszej maszyny. Aby uchwycić komunikację za pomocą protokołu ARP, wyczyściliśmy pamięć podręczną: m3:~ Student% sudo arp -da 194.29.146.3 (194.29.146.3) deleted 194.29.146.253 (194.29.146.253) deleted 194.29.146.27 (194.29.146.27) deleted 194.29.146.247 (194.29.146.247) deleted 194.29.146.16 (194.29.146.16) deleted 1
Następnie na dwóch konsolach uruchomiliśmy tcpdump i ping: m3:~ Student% sudo tcpdump -i en0 arp m3:~ Student% ping -c 1 test103 PING test103.iem.pw.edu.pl (194.29.146.242): 56 data bytes 64 bytes from 194.29.146.242: icmp_seq=0 ttl=64 time=7.967 ms Zgodnie z oczekiwaniami, tcpdump zarejestrował pytanie i odpowiedź: 12:56:23.793059 ARP, Request who-has test103 tell m3, length 46 12:56:23.796889 ARP, Reply test103 is-at P103C, length 46 Zgodnie z poleceniem prowadzącego, operaceę powtórzyliśmy dla innego hosta. Usunęliśmy pamięć podręczną, uruchomiliśmy przechwytywanie i spingowaliśmy maszynę EDI: PING edi (194.29.146.16): 56 data bytes 64 bytes from 194.29.146.16: icmp_seq=0 ttl=64 time=0.423 ms 13:23:00.765706 ARP, Request who-has edi tell m3, length 46 13:23:00.765828 ARP, Reply edi is-at EDI, length 46 3 DHCP DHCP to protokół służący do zdalnej konfiguracji komputera. Komunikacja zachodzi w 4 fazach: 1. ujawnienie DHCP - wysyłane przez klienta. Zapytanie jest wysyłane jako rozgłoszenie na FF.FF.FF.FF. 2. oferta DHCP - wysyłana przez serwery. Zawiera identyfikatory IP należące do odpowiedniego zakresu (n.p.: maska sieci lokalnej, bramy, serwery dns, serwery czasu etc.). 3. żądanie DHCP - ponieważ klient może uzyskać oferty od wielu serwerów, precyzuje którą wybrał. Ponieważ wciąż nie ma numeru IP, także ten pakiet wysyłany jest jako rozgłoszenie. 4. potwierdzenie DHCP - wysyłana do klienta informacja o przydzieleniu mu IP. Zawiera też podane w żądaniu parametry opcjonalne, długość całkowitego okresu na jaki przydzielono IP i okresy jego odnawiania. Aby sprawdzić działanie protokołu, usunęliśmy na interfejsie sieciowym warstwę adresową: 2
v6% # ifconfig xl0 delete Następnie uruchomiliśmy program dhclient, który zarejestrował komunikację między maszyną a serwerem: v6% # dhclient xl0 DHCPDISCOVER on xl0 to 255.255.255.255 port 67 interval 6 DHCPOFFER from 194.29.146.27 DHCPREQUEST on xl0 to 255.255.255.255 port 67 DHCPACK from 194.29.146.27 bound to 194.29.146.232 -- renewal in 21600 seconds. 4 UDP UDP to prosty protokół komunikacyjny. Jest bezpołączeniowy, nie gwarantuje kolejności dostarczenia ani dostarczenia pakietów w ogóle. Jego zaletą jest prostota i duża szybkość. Aby zbadać komunikację za jego pomocą, użyliśmy programu nc. Postawiliśmy serwer i uruchomiliśmy tcpdump: v6% nc -u -l 6666 v6% sudo tcpdump -s 1400 -i lo0 -w udp.pcap port 6666 Następnie połączyliśmy się z nim i wysłaliśmy wiadomość v6% nc -u localhost 6666 czesc jestem udp juz nie jestem ^C która pojawiła się także po stronie serwera. Następnie przeanalizowaliśmy w WireSharku logi tcpdumpa: 3
Każdej z trzech wpisanych linii odpowiadał jeden pakiet; Zgodnie z oczekiwaniami, nie przesłano żadnych pakietów kontrolnych. 5 TCP W przeciwieństwie do UDP, TCP posiada szereg mechanizmów, pozwalających na niezawodne przesyłanie informacji między maszynami. Należą do nich m.in.: obsługa sesji, mechanizm składania danych we właściwej kolejności według ich numerów sekwencyjnych, etc. Protokół ten badaliśmy w analogiczny sposób jak poprzedni. Za pomocą tcpdumpa śledziliśmy ruch na wybranym przez nas porcie: v6% nc -l 6666 v6% sudo tcpdump -s 1400 -i lo0 -w tcp.pcap port 6666 v6% nc localhost 6666 czesc bai ^C 4
Mimo że przesłaliśmy tylko dwa komunikaty, doszło do wymiany kilkunastu pakietów. Kolejne fazy komunikacji to: 1. Ustawienie sesji TCP - pakiety 3, 4 i 5, stanowiące tzw. three-way handshake. 2. Wysłanie komunikatów - pakiet 6 z wiadomością czesc, pakiet 7 - potwierdzenie odebrania pakietu. Analogicznie pakiety 8 i 9 dla wiadomości bai 3. Zamknięcie sesji TCP - pakiety 10, 11, 12, 13. Na zrzucie ekranu widzimy też działanie mechanizmu ochrony przed błędami transmisji. Pakiet 1 dotarł z uszkodzonym nagłówkiem, dlatego w pakiecie 2 serwer zresetował połączenie. Pakiet SYN został więc retransmitowany i dalsze ustanawianie sesji przebiegło bez problemów. 6 Wnioski Dzięki ćwiczeniu poznaliśmy szczegóły komunikacji kilku podstawowych protokołów. Nauczyliśmy się wymuszać ruch danego typu na interfejsach i analizować go za pomocą programu WireShark wyposażonego przyjazny interfejs graficzny. 5