Laboratorium Sieci Komputerowych

Temat: ETHEREAL

Cel ćwiczenia: Poznanie właściwości protokołów TCP/IP i sposobu zastosowania analizatora sieci.

1. Analizowanie sesji telnet

Posługując się programem Ethereal analizowaliśmy pakiety przesyłane w sesji telnet. Telnet korzysta z protokołu transportowego połączeniowego TCP. Aby odfiltrować segmenty inicjujące i kończące transmisję TCP sesji telnet posłużyłem się wyrażeniem:

tcp.port == 23 and (tcp.flags.syn == 1 or tcp.flags.fin == 1 or tcp.flags.ack ==1)

i przedstawiłem je w poniższej tabeli:

No.	Time	Source	Destination	Protocol	Info
Pakiety TCP inicjujące sesję telnet
344	200.366090	156.17.31.45	156.17.31.51	TCP	1070 > telnet [SYN] Seq=3239073255 Ack=0 Win=5840 Len=0
345	200.366401	156.17.31.51	156.17.31.45	TCP	telnet > 1070 [SYN, ACK] Seq=436926727 Ack=3239073256 Win=5792 Len=0
346	200.366521	156.17.31.45	156.17.31.51	TCP	1070 > telnet [ACK] Seq=3239073256 Ack=436926728 Win=5840 Len=0
Pakiety TCP kończące sesję telnet
944	406.512312	156.17.31.51	156.17.31.45	TCP	telnet > 1070 [FIN, ACK] Seq=436927438 Ack=3239073454 Win=5792 Len=0
945	406.512662	156.17.31.45	156.17.31.51	TCP	1070 > telnet [FIN, ACK] Seq=3239073454 Ack=436927439 Win=6432 Len=0
946	406.512967	156.17.31.51	156.17.31.45	TCP	telnet > 1070 [ACK] Seq=436927439 Ack=3239073455 Win=5792 Len=0

Pierwszy zostaje wysłany segment z ustawionym bitem SYN=1 o numerze 344, po czasie 200.366090 sekund od momentu uruchomienia aplikacji Ethereal, z mojej stacji roboczej o adresie 156.17.31.45 będącej klientem na adres serwera zrlab18: 156.17.31.51 . Zawiera on żądanie nawiązania połączenia TCP sesji telnet. Klient nadaje na porcie 1070 a serwer odbiera pakiet na port 23 telnetu. "Seq=3239073255" jest proponowanym numerem sekwencyjnym pakietu wysłanego od klienta, a "Ack=0" numerem sekwencyjnym segmentu otrzymanego w odpowiedzi od serwera. Występuje to w celu zachowania kolejności pakietów, w przypadku zagubienia się niektórych z nich. Dodatkowo przesyłane są takie parametry jak długość nagłówka w słowach (Len=0) oraz rozmiar okna (Win=5840).

Serwer odpowiada ze swojego portu 23 na port 1070 klienta segmentem z bitami SYN=1, ACK=1 mówiącym o tym, że serwer odebrał żądanie i zgadza się na nawiązanie transmisji TCP. Numer sekwencyjny "Ack=3239073256" jest to kolejny numer po Seq wysłanego wcześniej segmentu klienta, od którego rozpocznie się liczenie kolejnych segmentów. Analizator obliczył, że odpowiedź została wysłana po czasie 311us od czasu otrzymania segmentu SYN.

Następnie klient wysyła segment z bitem ACK=1 wraz z pierwszymi danymi i od tej pory zostanie nawiązane połączenie telnetu. Widać zgodność numerów sekwencyjnych Seq i Ack.

Po tych trzech pakietach zostają przesyłane dane, takie jak powitanie, login użytkownika, jego hasło i inne zależne od usługi i użytkownika polecenia. Analizując strumień danych transmisji TCP widać, że wszelkie dane są w sesji telnet przesyłane otwartym tekstem, bez żadnego szyfrowania:

____ ______________________ ______

| ( ( Laboratorium ( ( 7|

| ) ) Systemow ) ) |

| ( ( Telekomunikacyjnych ( ( |

~~~~ ~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~

login: mmaaccsszzuuppii

Password: ktetczr9

Last login: Wed Apr 2 13:38:29 from lst13

[macszupi@zrlab3 macszupi]$ ppwwdd

/opt/home/student/macszupi

[macszupi@zrlab3 macszupi]$ oott  ttoouucchh tteesstt    ppkkiill   lliikk__tteellnneett

[macszupi@zrlab3 macszupi]$ 1 (arg: 1)  [macszupi@zrlab3 macszupi]$ eexxiitt logout

W transmisji telnet każdy znak jest przesyłany niezależnie i po każdym odsyłana jest odpowiedź. Dlatego widoczne są podwojone litery. Login, hasło i wszelkie polecenia nie są szyfrowane.

Kończąc połączenie TCP wysyłany jest segment FIN (tutaj FIN,ACK) zależnie, kto pierwszy kończy klient czy serwer. Jedna strona wysyła ten pakiet z odpowiednimi numerami sekwencyjnymi Seq i Ack. Druga strona odpowiada segmentem FIN,ACK i w tej chwili kończy transmisję. Dla formalności zostaje wysłany jeszcze segment ACK, w potwierdzeniu na pakiet FIN,ACK.

2. Analizowanie sesji ssh

Aby odfiltrować pakiety inicjujące i kończące transmisję TCP sesji ssh posłużyłem się wyrażeniem:

tcp.port == 22 and (tcp.flags.syn == 1 or tcp.flags.fin == 1 or tcp.flags.ack ==1)

No.	Time	Source	Destination	Protocol	Info
Pakiety TCP inicjujące sesję ssh
1845	848.964708	156.17.31.45	156.17.31.52	TCP	1074 > 22 [SYN] Seq=3946505557 Ack=0 Win=5840 Len=0
1846	848.965051	156.17.31.52	156.17.31.45	TCP	22 > 1074 [SYN, ACK] Seq=1125752690 Ack=3946505558 Win=5792 Len=0
1847	848.965161	156.17.31.45	156.17.31.52	TCP	1074 > 22 [ACK] Seq=3946505558 Ack=1125752691 Win=5840 Len=0
Pakiety TCP kończące sesję ssh
1895	854.928448	156.17.31.52	156.17.31.45	TCP	1074 > 22 [FIN, ACK] Seq=3946507244 Ack=1125754914 Win=8832 Len=0
1896	854.932890	156.17.31.45	156.17.31.52	TCP	22 > 1074 [FIN, ACK] Seq=1125754914 Ack=3946507245 Win=9480 Len=0
1897	854.932990	156.17.31.52	156.17.31.45	TCP	1074 > 22 [ACK] Seq=3946507245 Ack=1125754915 Win=8832 Len=0

Pakiety tutaj są analogiczne jak w przypadku sesji telnet. Jedyna różnica to numer portu 22 na serwerze, na który się łączymy oraz adres serwera. W tym przypadku łączymy się z serwerem zrlab20 o adresie 156.17.31.51 . Podobnie jak w przypadku telnetu zachowane są numery sekwencyjne Seq i Ack.

Analizując strumień TCP sesji ssh widzimy, że dane są szyfrowane zgodnie z założeniem tego protokołu (Secure Shell).

3. Analizowanie sesji ftp

Aby odfiltrować pakiety inicjujące i kończące transmisję TCP sesji ssh posłużyłem się wyrażeniem:

tcp.port == 21 and (tcp.flags.syn == 1 or tcp.flags.fin == 1 or tcp.flags.ack ==1)

No.	Time	Source	Destination	Protocol	Info
Pakiety TCP inicjujące sesję ftp
1107	484.063401	156.17.31.45	156.17.31.51	TCP	1071 > ftp [SYN] Seq=3538875479 Ack=0 Win=5840 Len=0
1108	484.063745	156.17.31.51	156.17.31.45	TCP	ftp > 1071 [SYN, ACK] Seq=739977120 Ack=3538875480 Win=5792 Len=0
1109	484.063862	156.17.31.45	156.17.31.51	TCP	1071 > ftp [ACK] Seq=3538875480 Ack=739977121 Win=5840 Len=0
Pakiety TCP kończące sesję ftp
1391	659.945048	156.17.31.45	156.17.31.51	TCP	1071 > ftp [FIN, ACK] Seq=3538875604 Ack=739977510 Win=5840 Len=0
1392	659.945448	156.17.31.51	156.17.31.45	TCP	ftp > 1071 [FIN, ACK] Seq=739977510 Ack=3538875605 Win=5792 Len=0
1393	659.945540	156.17.31.45	156.17.31.51	TCP	1071 > ftp [ACK] Seq=3538875605 Ack=739977511 Win=5840 Len=0

Numer portu przydzielonego dla ftp na serwerze to 21. Adres serwera ftp to 156.17.31.51

Analizując strumień TCP dla sesji ftp widzimy, że dane przesyłane są w postaci tekstu niezaszyfrowanego:

220 *Witamy w Laboratorium Sieci Komputerowych na serwerze ftp*

USER macszupi

331 Please specify the password.

PASS ktetczr9

230 Login successful. Have fun.

SYST

215 UNIX Type: L8

PWD

257 "/opt/home/student/macszupi"

TYPE I

200 Binary it is, then.

PORT 156,17,31,45,4,48

200 PORT command successful. Consider using PASV.

RETR /opt/home/student/macszupi/plik_telnet

150 Opening BINARY mode data connection for /opt/home/student/macszupi/plik_telnet (0 bytes).

226 File send OK.

QUIT

221 Goodbye.

W sesji ftp login i hasło przesyła się w jednym pakiecie, a nie znak po znaku z potwierdzeniem, tak jak to było w przypadku sesji telnet. Tutaj jeszcze łatwiej jest przechwycić i wyodrębnić hasło niż w telnecie.

4. Analizowanie sesji http

Aby odfiltrować pakiety inicjujące i kończące transmisję TCP sesji ssh posłużyłem się wyrażeniem:

tcp.port == 80 and (tcp.flags.syn == 1 or tcp.flags.fin == 1 or tcp.flags.ack ==1)

No.	Time	Source	Destination	Protocol	Info
Pakiety TCP inicjujące sesję http
2343	1135.681213	156.17.31.45	156.17.31.55	TCP	1078 > http [SYN] Seq=4236209906 Ack=0 Win=5840 Len=0
2344	1135.682710	156.17.31.55	156.17.31.45	TCP	http > 1078 [SYN, ACK] Seq=877985717 Ack=4236209907 Win=5792 Len=0
2345	1135.682824	156.17.31.45	156.17.31.55	TCP	1078 > http [ACK] Seq=4236209907 Ack=877985718 Win=5840 Len=0
Pakiety TCP kończące sesję http
2697	1136.522322	156.17.31.55	156.17.31.45	TCP	http > 1078 [FIN, ACK] Seq=878301620 Ack=4236210280 Win=6432 Len=0
2698	1136.522981	156.17.31.45	156.17.31.55	TCP	1078 > http [FIN, ACK] Seq=4236210280 Ack=878301621 Win=63712 Len=0
2699	1136.524277	156.17.31.55	156.17.31.45	TCP	http > 1078 [ACK] Seq=878301621 Ack=4236210281 Win=6432 Len=0

Numer portu przydzielonego dla http na serwerze to 80. Adres serwera www to 156.17.31.55

Analizując strumień TCP dla sesji http widzimy, że stosując polecenie:

GET <adres_url> HTTP/1.1

dostajemy wiele informacji, m.in. o typu połączenia (Connection: Keep-Alive), systemie operacyjnym i rodzaju serwera (Red-Hat, Apache) oraz o aplikacji z jakiej korzystamy podczas połączenia (User-Agent: Links) itp.

GET /~sieci HTTP/1.1

Host: lstwww

User-Agent: Links (0.93pre4; Linux 2.4.5 i586)

Accept: */*

Accept-Charset: us-ascii, ISO-8859-1, ISO-8859-2, ISO-8859-4, ISO-8895-5, ISO-8859-13, windows-1250, windows-1251, windows-1257, cp437, cp850, cp852, cp866, x-cp866-u, x-mac-ce, x-kam-cs, x-koi8-r, x-koi8-u, utf-8

Connection: Keep-Alive

HTTP/1.1 301 Moved Permanently

Date: Wed, 02 Apr 2003 11:58:34 GMT

Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)

Location: http://lstwww/~sieci/

Connection: close

Transfer-Encoding: chunked

Content-Type: text/html; charset=iso-8859-1120

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<HTML><HEAD>

<TITLE>301 Moved Permanently</TITLE>

</HEAD><BODY>

<H1>Moved Permanently</H1>

The document has moved <A HREF="http://lstwww/~sieci/">here</A>.<P>

<HR>

<ADDRESS>Apache/1.3.27 Server at lstwww Port 80</ADDRESS>

</BODY></HTML>

Wnioski

Aby nawiązać połączenie TCP miedzy dwoma komputerami, należy wymienić ze sobą conajmniej 3 segmenty z ustawionymi bitami: SYN; SYN,ACK; oraz ACK. Dopiero po tym ostatnim pakiecie zostają otwarte porty przeznaczone do danej usługi: telnet, ssh, http itp. i następuje wymiana danych. Żeby natomiast zakończyć połączenie TCP należy przesłać conajmniej dwa segmenty z ustawionymi bitami: FIN oraz FIN,ACK. Często po tym zostaje także wysłany segment ACK, ale jest to tylko formalnością, bo połączenie TCP zostało już i tak zerwane. Wszystkie połączenia TCP są wirtualne, rozpoznawane po adresach i portach komputerach docelowych i źródłowych. Pakiety TCP są buforowane dodatkowo w celu zapewnienia poprawności przesyłanych danych.

Inaczej jest w przypadku protokołu UDP, który nie wymaga pakietów inicjujących oraz kończących połączenie. Wymiana danych rozpoczyna się szybciej, czyli istotna jest tu przepustowość, zato mały nacisk kładzie się na kontrolę przepływu informacji. Jeśli pakiet nie dotrze do odbiorcy, albo kiedy wyliczona suma kontrolna nie będzie zgodna z sumą zawartą w nagłówku, to UDP nie podejmie żadnych działań zmierzających do korekty lub retransmisji pakietów. Jest stosowany do takich protokołów jak SNMP, BOOTP itp., gdzie głównie przesyła się komunikaty.

---