Duszenczuk Gr11IiE Sieci Komputerowe Lista WIRESHARK

Danuta Duszeńczuk, gr.
11 IiE, I rok, nr indeksu 130701

Informatyka Ekonomiczna. Sieci komputerowe – lista zadań nr 2. WIRESHARK.
Danuta Duszeńczuk
Sprawozdanie z projektu
„Analizator sieciowy WireShark”
1. Wprowadzenie
1.1 Czym jest WireShark, gdzie można znaleźć o nim dodatkowe informacje
WireShark, znany do czerwca 2006 pod nazwą Ethereal, jest programem służącym do analizy
ruchu sieciowego oraz poznania i analizy wybranych protokołów sieciowych. Należy do grupy tzw.
snifferów, często stosowanych przez hakerów do podsłuchu i przechwytywania danych. Jego
podstawową zaletą jest to, że jest programem wieloplatformowym (obsługuje go kilka systemów
operacyjnych), posiada obok interfejsu tekstowego także graficzny – GUI, a ponadto
rozprowadzany jest na licencji GNU GPL. Jeśli nie posiadamy interfejsu graficznego (lub
jesteśmy przyzwyczajeni do korzystania z narzędzi do analizy sieci udostępnionych przez
Microsoft w wierszu komend), powinniśmy zainteresować się „TShark”, który jest
bezokienkową wersją WireShark. TShark wspiera tą samą funkcjonalność co WireShark i
w pakiecie instalacyjnym dla systemu Windows jest domyślnie również instalowany na
komputerze użytkownika (w dalszej części projektu krótko opiszę, jak umożliwić jego
wywołanie z wiersza poleceń). Niestety, WireShark do dzisiaj nie doczekał się polonizacji.
Brakuje też kompletnego i kompetentnego przewodnika po programie w języku polskim.
Program można pobrać ze strony producenta:
http://www.wireshark.org/download.html
Szczegółowy podręcznik użytkownika w języku angielskim można znaleźć pod adresem:
http://www.wireshark.org/docs/wsug_html_chunked/
Prosty przewodnik w języku polskim dostępny jest pod:
http://openmaniak.com/pl/wireshark.php
WAŻNE. WireShark obecnie nie posiada wsparcia dla sieci bezprzewodowych bluetooth:
http://wiki.wireshark.org/CaptureSetup/Bluetooth
1.2 Cel projektu
Celem projektu jest poznanie możliwości programu WireShark (Ethereal) w pracy administratora
sieci, jak i zwykłego użytkownika – narzędzia oferowane przez program są bardzo przydatne,
pomagają na przykład zwiększyć bezpieczeństwo sieci i świadomość użytkowników, odnośnie jej
działania. Okazują się również niezwykle pomocne w przypadkach włamań do sieci (ułatwiają
namierzenie intruzów) czy też zlokalizowania źródła problemów. Każda analiza poszczególnych
funkcjonalności programu WireShark została zobrazowana przeze mnie stosownym zrzutem
ekranu wraz z komentarzem.
1.3 Kontakt i uwagi
W przypadku jakichkolwiek pytań, uwag i sugestii związanych z niniejszym projektem

zapraszam do kontaktu mailowego: danuta.duszenczuk@gmail.com
Jak również poprzez komunikator tlen: danadusz@tlen.pl i Gadu-Gadu: 4617706.
1
Danuta Duszeńczuk, gr. 11 IiE, I rok, nr indeksu 130701
1.4 Suplement
1.4.a Jak ustawić uruchamianie WireShark z wiersza poleceń?
WireShark, a dokładnie jego tekstowy odpowiednik TShark, domyślnie nie jest dostępny z poziomu wiersza
poleceń. Aby można go było wywołać z menu Start / Uruchom / cmd, wpisując tshark parametr, należy:
1. Na pulpicie znaleźć i kliknąć prawym przyciskiem myszki ikonę Mój komputer.

2. Z rozwiniętego menu wybrać kolejno: Właściwości / Zaawansowane / Zmienne środowiskowe.
3. W sekcji Zmienne systemowe odszukać pozycję Path, zaznaczyć, a następnie wybrać opcję Edytuj.
4. W polu Wartość zmiennej dopisać na samym końcu, po wstawieniu średnika (bez spacji!) ścieżkę
dostępu do folderu z programem WireShark; jeśli przy instalacji nie zmienialiśmy docelowego
folderu, program domyślnie powinien znajdować się w C:\Program Files\Wireshark.
5. Trzykrotnie klikamy na przycisk OK.
2
1.4.b Przykład zastosowania
By móc korzystać z WireShark/TShark i przechwytywać ruch sieciowy, należy zainstalować bibliotekę pcap
(w trakcie instalacji program sam powinien zalecić zainstalowanie WinPcap; bibliotekę można też pobrać
ręcznie ze strony: http://www.winpcap.org/install/default.htm) i pracować w systemie z ustawionymi prawami
administratora.
Bibliotekę pcap i jej sterownik NPF uruchamiamy, wpisując komendę sc config npf start= auto
Powinniśmy otrzymać informację [SC] ChangeServiceConfig SUCCESS
Odtąd Wireshark/TShark może być uruchamiany i wykorzystywany nawet z poziomu użytkownika. Ułatwia to
pracę, jednak niesie ze sobą pewne zagrożenie, gdyż każdy użytkownik może potencjalnie przechwycić ruch
w sieci. Można też uruchamiać i wyłączać działanie bibliotek i sterownika NPF przed uruchomieniem i po
wyłączeniu WireShark/TShark. Jest to bezpieczniejsze rozwiązanie, po zakończeniu pracy inni użytkownicy
nie mają już możliwości przechwycenia ruchu w sieci.
Odpowiednio stosuje się wtedy komendy:

runas /u:administrator "net start npf"
oraz
runas /u:administrator "net stop npf"
Aby uzyskać informacje o dostępnych interfejsach sieciowych, należy wpisać tshark -D

By zacząć śledzić ruch sieciowy, wybieramy aktywny interfejs wpisując tshark -i 1 (1 – numer interfejsu z
wcześniej wyświetlonej listy). Można dodatkowo podać informację, po ilu wyświetlonych pakietach śledzenie
ma zostać przerwane, np. parametr -c 10 wstrzyma śledzenie po uzyskaniu 10 pakietów. Brak tego
parametru implikuje śledzenie w nieskończoność.
Szczegółowy wykaz i opis podstawowych komend wiersza poleceń dla TShark wraz z ich
parametrami można znaleźć pod adresem:
http://www.wireshark.org/docs/wsug_html_chunked/ChCustCommandLine.html
3
2. Zadania do wykonania
1. Uruchomić program ping dla stacji z tej samej podsieci oraz dla stacji z innej
podsieci podając adres domenowy. Przeanalizować w pliku przechwyconych
danych protokoły ARP, ICMP, DNS.
Do testu wybrałam ping na bramę internetową (IP 192.168.0.1)
Zrzut ekranu po wywołaniu ping:
Log z WireShark – Wireshark nie zarejestrował wykorzystania DNS, bo nie był on konieczny:
Opis:
No. Time Source Destination Protocol Info

5 23.145938 DellPcba_e7:43:48 Broadcast ARP Who has 192.168.0.1? Tell
192.168.0.100
Frame 5 (42 bytes on wire, 42 bytes captured)

Ethernet II, Src: DellPcba_e7:43:48 (00:0d:56:e7:43:48), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol (request)

6 23.146628 D-Link_8f:0e:96 DellPcba_e7:43:48 ARP 192.168.0.1 is at 00:1b:11:8f:0e:96

Ethernet II, Src: D-Link_8f:0e:96 (00:1b:11:8f:0e:96), Dst: DellPcba_e7:43:48 (00:0d:56:e7:43:48)
Address Resolution Protocol (reply)
4
ARP to skrót od Adress Resolution Protocol. Jest jednym z protokołów komunikacyjnych TCP/IP,
który na podstawie ruchu w sieci lokalnej rozpoznaje logicznie przypisany 32-bitowy adres IP jako
adres dostępu fizycznego urządzenia lub nośnika (48-bitowe adresy MAC) – jest więc stosowany
do rozpoznawania adresów urządzeń w sieci. Jest również stosowany do rozpoznawania adresów
sieci Ethernet/802.3 lub Token Ring jako adresów urządzeń w sieci.
W powyższym fragmencie raportu widać proces identyfikowania. W wierszu no 5 komputer

DellPcba_e7:43:48 wysyła zapytanie, do jakiego urządzenia należy IP 192.168.0.1. Wysyła w tym
celu ramkę rozgłoszeniową (broadcast) o adresie docelowym MAC w postaci ff:ff:ff:ff:ff:ff do bramy
internetowej. W wierszu no 6 otrzymuje odpowiedź – brama internetowa o IP 192.168.0.1 (router
D-Link), jako że znajduje się w tej samej podsieci, co komputer DellPcba_e7:43:48, wysyła
odpowiedź zawierającą jej adres MAC (00:1b:11:8f:0e:96). W tym momencie stacja o adresie IP
192.168.0.100 zna adres MAC swojej bramy, dlatego może rozpocząć wysyłanie pakietów IP do
stacji znajdujących się w innych podsieciach.

7 23.146643 192.168.0.100 192.168.0.1 ICMP Echo (ping) request

Ethernet II, Src: DellPcba_e7:43:48 (00:0d:56:e7:43:48), Dst: D-Link_8f:0e:96 (00:1b:11:8f:0e:96)
Internet Protocol, Src: 192.168.0.100 (192.168.0.100), Dst: 192.168.0.1 (192.168.0.1)
Internet Control Message Protocol

8 23.147183 192.168.0.1 192.168.0.100 ICMP Echo (ping) reply

ICMP (ang. Internet Control Message Protocol) to internetowy protokół pełniący funkcję kontroli
transmisji w sieci; jest protokołem warstwy sieciowej OSI/TCP/IP wykorzystywanym w diagnostyce
sieci oraz trasowaniu w programach ping oraz traceroute. Zgłasza błędy łączności między hostami.
Lista typów wiadomości dostępna pod:
http://pl.wikipedia.org/wiki/ICMP#Lista_typ.C3.B3w_wiadomo.C5.9Bci
W powyższym przykładzie można zaobserwować pingi pomiędzy komputerem o IP

192.168.0.100 a bramą internetową o IP 192.168.0.1 (router D-Link). W wierszu no 1
komputer wysyła do bramy zapytanie, w wierszu no 2 otrzymuje informację zwrotną.
Komunikacja między interfejsami zachodzi więc bez przeszkód.
5
2. Uruchomić program tracert dla różnych stacji podając adres domenowy.

Przeanalizować w pliku przechwyconych danych protokoły ARP, ICMP, DNS.
Do testu wybrałam tracert na domenę www.ue.wroc.pl
Log z WireSharp:
Zadań nie rozwiązywałam chronologicznie, dlatego czym dokładnie jest protokół DNS i jakie
spełnia funkcje, zostało przeze mnie opisane w przykładzie zadania 6.
6
Opis:



2 0.000540 192.168.0.1 192.168.0.100 ICMP Time-to-live exceeded (Time to live
exceeded in transit)



Wiersze no 1 i 3 należy interpretować analogicznie jak wiersze no 7 i 8 w zadaniu 1; wiersz no 2

wskazuje na ustalenie czasu oczekiwania. Operacje te są powtarzanie przy komunikacji z każdym
kolejnym węzłem trasy.

25 3.033098 192.168.0.100 82.143.159.7 DNS Standard query PTR 14.66.127.212.in-
addr.arpa

User Datagram Protocol, Src Port: 59630 (59630), Dst Port: domain (53)
Domain Name System (query)

26 3.035282 82.143.159.7 192.168.0.100 DNS Standard query response PTR wask-
dialog.wask.wroc.pl

User Datagram Protocol, Src Port: domain (53), Dst Port: 59630 (59630)
Domain Name System (response)
No 25 – stacja o IP 192.168.0.100 wysyła standardowe zapytanie do serwera (IP 82.143.159.7) o

rekord PTR, który jest odpowiedzialny za mapowanie adresu IPv4 na nazwę kanoniczną hosta.
Określenie rekordu PTR dla nazwy hosta w domenie in-addr.arpa (IPv4), który odpowiada
adresowi IP 192.168.0.100 w wierszu no 26, pozwala na implementację odwrotnej translacji
adresów DNS (ang. reverse DNS lookup). Dzięki temu zamieniane są adresy zrozumiałe dla
urządzeń tworzących sieć na adresy znane użytkownikom Internetu (czyli z IP 82.143.159.7 na
nazwę www.ue.wroc.pl). Komunikacja zachodzi na portach 59630 oraz 53.
7
3. Uruchomić przeglądarkę WWW dla wybranych adresów sieciowych

i przeanalizować w pliku przechwyconych danych protokoły HTTP, DNS.
Wybrałam adres www.ue.wroc.pl – analizie poddałam protokół HTTP.
WireShark po zastosowaniu filtra wskazuje dwa zapytania do wybranego hosta:
Dane o przechwyconym połączeniu z Capture file:

6 9.814414 192.168.0.100 156.17.118.245 HTTP GET / HTTP/1.1
...

60 9.917067 156.17.118.245 192.168.0.100 HTTP HTTP/1.1 200 OK (text/html)

62 10.349024 192.168.0.100 156.17.118.245 HTTP GET /css/style.css?1234 HTTP/1.1

Transmission Control Protocol, Src Port: rfio (3147), Dst Port: http (80), Seq: 1, Ack: 1, Len: 606
Hypertext Transfer Protocol

8
Transmission Control Protocol, Src Port: http (80), Dst Port: rfio (3147), Seq: 51101, Ack: 607, Len: 994
[Reassembled TCP Segments (52094 bytes): #8(1460), #9(1460), #10(1460), #12(1460), #13(1460),
#15(1460), #16(1460), #18(1460), #19(1460), #21(1460), #22(1460), #24(1460), #25(1460), #27(1460),
#28(1460), #30(1460), #31(1460), #33(1460), #34]
Line-based text data: text/html

Transmission Control Protocol, Src Port: rfio (3147), Dst Port: http (80), Seq: 607, Ack: 52095, Len: 691
Opis:
Protokół HTTP (ang. Hypertext Transfer Protocol) służy do przesyłania dokumentów

hipertekstowych sieci WWW. Za jego pomocą określana jest forma żądań klienta (np. o
udostępnienie dokumentów WWW, informacje o kliknięciu odnośnika przez klienta, wysłanie
danych z formularzy) , która jest przesyłana do serwera (formę odpowiedzi serwera na te żądania
też jest określana). Jest protokołem bezstanowym, gdyż po zakończeniu transakcji klient-serwer
wszystkie informacje "przepadają". HTTP standardowo korzysta z portu nr 80 (TCP).
No 6 – stacja o adresie IP192.168.0.100 wysyła poprzez bramę komunikat do stacji o IP

156.17.118.245 o żądaniu pobrania zasobu wskazanego przez URI metodą GET. Zasób ten
według żądania ma być zgodny z protokołem HTTP 1.1.
No 60 – stacja o adresie IP 156.17.118.245, która jest serwerem www, udziela odpowiedzi HTTP,
iż żądanie zostało w tym wypadku zaakceptowanie i następuje zwrócenie zawartości do stacji o IP
192.168.0.100.
No 62 – stacja 192.168.0.100 wysyła kolejne żądanie do stacji 156.17.118.245 metodą GET,

tym razem o przesłanie zasobu w postaci kaskadowego arkusza stylów CSS.
Jak widać, kolejne zapytania o przesłanie zasobów pozwolą stacji o IP 192.168.0.100 pobrać
pełne zasoby, które umożliwią przeglądarce wyświetlenie strony, znajdującej się na serwerze o
IP 156.17.118.245 (www.ue.wroc.pl).
9
4. Uruchomić program FTP, zalogować się na dowolny adres, przesłać plik

i przeanalizować w pliku przechwyconych danych protokoły FTP, DNS
Do zadania wybrałam serwer swojej strony internetowej mieszczącej się pod adresem
brulion.yoyo.pl – do serwera mam dostęp poprzez program Total Commander Power Pack 7.5a.
Zrzut logów w WireShark po połączeniu się z serwerem FTP i wgraniu pliku:
Opis:

11 12.557465 88.198.196.10 192.168.0.100 FTP Response: 331 Password required for
brulion.yoyo.pl.

Transmission Control Protocol, Src Port: ftp (21), Dst Port: dpkeyserv (1780), Seq: 37, Ack: 23, Len: 44
File Transfer Protocol (FTP)

12 12.564926 192.168.0.100 88.198.196.10 FTP Request: PASS XXXXXXXX

Transmission Control Protocol, Src Port: dpkeyserv (1780), Dst Port: ftp (21), Seq: 23, Ack: 81, Len: 19
13 12.629391 88.198.196.10 192.168.0.100 FTP Response: 230 User brulion.yoyo.pl
logged in.

FTP (ang. File Transfer Protocol – Protokół Transferu Plików) jest to ośmiobitowy protokół typu
klient-serwer, który umożliwia przesyłanie plików z serwera i na serwer poprzez sieć TCP/IP. Do
komunikacji wykorzystywane są dwa połączenia TCP. Jedno z nich jest połączeniem kontrolnym,
10
za pomocą którego przesyłane są np. polecenia do serwera (przez port 21), drugie natomiast służy
do transmisji danych m.in. plików (port 20). FTP działa w dwóch trybach: aktywnym i pasywnym, w
zależności od tego, w jakim jest trybie, używa innych portów do komunikacji.
Podstawy protokołu FTP, opis i zasada działania znajdują się na stronie:

http://drzewo-wiedzy.pl/?page=artykul&id=79
No 11 – serwer o IP 88.198.196.10 przesyła do komputera o IP 192.168.0.100 informację, że

serwer FTP brulion.yoyo.pl jest gotowy i czeka na podanie hasła przez użytkownika.
No 12 – gdy na komputerze 192.168.0.100 podane zostało hasło, protokół przesyła je do serwera

88.198.196.10. W miejscu XXXXXXXX log normalnie wyświetla hasło – dowodzi to, że za pomocą
WireSharp można przechwytywać tego typu poufne dane.
No 13 – serwer FTP przesyła do stacji 192.168.0.100 potwierdzenie zalogowania się na niego.
W przypadku logu dla wgrywania pliku na serwer fragment raportu wygląda następująco:

34 13.109403 88.198.196.10 192.168.0.100 FTP-DATA FTP Data: 1448 bytes

Transmission Control Protocol, Src Port: ftp-data (20), Dst Port: rfe (5002), Seq: 1022, Ack: 1, Len: 1448
FTP Data

35 13.109450 192.168.0.100 88.198.196.10 TCP rfe > ftp-data [ACK] Seq=1 Ack=2470
Win=65535 Len=0 TSV=124883 TSER=232766791

Transmission Control Protocol, Src Port: rfe (5002), Dst Port: ftp-data (20), Seq: 1, Ack: 2470, Len: 0


FTP Data


FTP Data

38 13.109661 192.168.0.100 88.198.196.10 TCP rfe > ftp-data [ACK] Seq=1 Ack=4503
Win=63503 Len=0 TSV=124883 TSER=232766791

11


39 13.124474 192.168.0.100 88.198.196.10 TCP [TCP Window Update] rfe > ftp-data
[ACK] Seq=1 Ack=4503 Win=65535 Len=0 TSV=124883 TSER=232766791


40 13.124794 192.168.0.100 88.198.196.10 TCP rfe > ftp-data [FIN, ACK] Seq=1
Ack=4503 Win=65535 Len=0 TSV=124883 TSER=232766791


41 13.158248 88.198.196.10 192.168.0.100 TCP ftp-data > rfe [ACK] Seq=4503 Ack=2
Win=6144 Len=0 TSV=232766803 TSER=124883


42 13.158415 88.198.196.10 192.168.0.100 FTP Response: 226 Transfer complete.

Opis flag ACK, SEQ i FIN przy protokole TCP zamieściłam w kolejnym zadaniu, przy
omówieniu zasad jego działania.
12
5. Uruchomić wybrany przez siebie program sieciowy (np. komunikator, poczta)

i przeanalizować w pliku przechwyconych danych odpowiednie protokoły związane
z tym programem.
Wybrałam komunikator Tlen.
Opis:

266 12.681401 87.126.7.33 192.168.0.184 UDP Source port: 27300 Destination port:
56930

Ethernet II, Src: D-Link_8f:0e:96 (00:1b:11:8f:0e:96), Dst: Giga-Byt_d8:f6:d9 (00:16:e6:d8:f6:d9)
User Datagram Protocol, Src Port: 27300 (27300), Dst Port: 56930 (56930)
Data (62 bytes)
0000 64 31 3a 61 64 32 3a 69 64 32 30 3a e3 42 f6 d6 d1:ad2:id20:.B..
0010 f1 5b 1a 53 f9 09 00 15 95 cd 30 54 b0 33 16 99 .[.S......0T.3..
0020 65 31 3a 71 34 3a 70 69 6e 67 31 3a 74 38 3a 85 e1:q4:ping1:t8:.
0030 3e 83 9f b1 9d 38 dc 31 3a 79 31 3a 71 65 >....8.1:y1:qe
UDP (ang. User Datagram Protocol). Datagramowy Protokół Użytkownika jest jednym z
podstawowych protokołów internetowych. Umieszcza się go w tzw. warstwie transportu. Jest to
protokół bezpołączeniowy, który nie ma mechanizmów kontroli przepływu i retransmisji.
Wykorzystywany przy wideokonferencjach, grach sieciowych i komunikatorach.
Na powyższym fragmencie raportu widać, że w operacji no 266 UDP udostępnia mechanizm

identyfikacji różnych punktów końcowych (np. pracujących aplikacji czy innych usług) dzięki portom
o numerach 27300 oraz 56930.

3 0.424025 192.168.0.100 82.143.159.7 DNS Standard query A appmsg.gadu-gadu.pl


4 0.425815 82.143.159.7 192.168.0.100 DNS Standard query response A 91.197.13.212
A 91.197.13.211


5 0.427939 192.168.0.100 82.143.159.7 DNS Standard query A idi.tlen.pl

13

6 0.429724 82.143.159.7 192.168.0.100 DNS Standard query response A 193.17.41.103

DNS (ang. Domain Name System) to system nazw domenowych, protokół komunikacyjny oraz
usługa polegająca na zamianie adresów znanych użytkownikom Internetu (a więc opisowych, w
formie ciągu znaków, np. www.ue.wroc.pl) na adresy IP zrozumiałe dla urządzeń tworzących sieć
komputerową. Możemy wyróżnić dwa rodzaje zapytań DNS: rekurencyjne, które wymusza na
serwerze znalezienie potrzebnej informacji lub zwrócenia wiadomości o błędzie (najczęściej
podania przez serwer adresu IP poszukiwanego hosta) oraz iteracyjne, które wymaga od serwera
jedynie podania najlepszej dostępnej mu w danej chwili odpowiedzi. Każde zapytanie czy też
odpowiedź serwera na nie muszą się zawierać w jednym pakiecie UDP. Struktura zwracanego
komunikatu DNS to kolejno: nagłówek, zapytanie do serwera nazw, odpowiedź na zapytanie,
wskazanie serwerów zwierzchnich dla domeny oraz sekcja informacji dodatkowych.
No 3 – stacja o adresie IP 192.168.0.100 wysyła zapytanie jako pakiet UDP portem 65188 do
serwera o IP 82.143.159.7 (appmsg.gadu-gadu.pl – komunikator Tlen ma wbudowaną obsługę
kont komunikatora Gadu-Gadu) – port docelowy to domena o nr 53.
No 4 – serwer o IP 82.143.159.7 udziela odpowiedzi o dostępności; połączenie z serwerem obsługi

kont GG zostało nawiązane.
W przypadku przesyłu no 5 i 6 sytuacja jest analogiczna, dotyczy jednak obsługi kont tlenowych
(idi.tlen.pl). Po zainicjowaniu tych połączeń użytkownik ma możliwość wysyłania wiadomości do
osób ze swoich list kontaktowych.

22 26.650939 192.168.0.100 192.168.0.1 TCP sdp-id-port > http [SYN] Seq=0
Win=65535 Len=0 MSS=1460

Transmission Control Protocol, Src Port: sdp-id-port (3242), Dst Port: http (80), Seq: 0, Len: 0

23 26.651502 192.168.0.1 192.168.0.100 TCP http > sdp-id-port [SYN, ACK] Seq=0
Ack=1 Win=5840 Len=0 MSS=1460

Transmission Control Protocol, Src Port: http (80), Dst Port: sdp-id-port (3242), Seq: 0, Ack: 1, Len: 0

24 26.651546 192.168.0.100 192.168.0.1 TCP sdp-id-port > http [ACK] Seq=1 Ack=1
Win=65535 Len=0

Transmission Control Protocol, Src Port: sdp-id-port (3242), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0
14
TCP (ang. Transmission Control Protocol – protokół kontroli transmisji) jest to strumieniowy
protokół komunikacji między dwoma komputerami (klient-serwer), odpowiedzialny za warstwę
transportu. W przeciwieństwie do UDP, TCP gwarantuje dostarczenie wszystkich pakietów w
całości, z zachowaniem ich kolejności.
Moment nawiązania połączenia w TCP nazywany jest three-way handshake. Na powyższym

przykładzie: stacja o IP 192.168.0.100 nawiązująca połączenie no 22 używa flagi SYN (od
synchronize) i oczekuje od stacji docelowej (tu: brama internetowa o IP 192.168.0.1.) odpowiedzi
oflagowanej jako ACK (od acknowledge – potwierdzenie). Odpowiedź udzielana jest w wierszu no
23 (Seq=0, Ack=1). Po otrzymaniu odpowiedzi stacja 192.168.0.100 inicjująca połączenie wysyła
do bramy pierwszą porcję danych ustawiając już tylko flagę ACK (i gasząc SYN). Widać to w linii
no 24, gdzie mamy Seq=1, Ack=1.
Inne flagi, jakie mogą wystąpić w przypadku TCP, to FIN (od finished – zakończony), która
informuje o prawidłowym zakończeniu połączenia (najczęściej po otrzymaniu pakietu z flagą FIN,
druga strona również kończy komunikację wysyłając pakiet z flagami FIN i ACK – widać to np. w
przykładzie z wgrywaniem pliku na serwer FTP w zadaniu wcześniejszym, wiersz raportu no 40)
czy też RST (reset), która występuje przy awaryjnym przerwaniu połączenia.
Poniżej – schemat nawiązania połączenia znaleziony na

http://commons.wikimedia.org/wiki/File:Tcp_normal.png :

47 28.285366 192.168.0.100 195.200.214.13 IAX2 IAX, source call# 4241, timestamp 3ms
REGREQ

User Datagram Protocol, Src Port: iax (4569), Dst Port: iax (4569)
Inter-Asterisk eXchange v2

48 28.296875 195.200.214.13 192.168.0.100 IAX2 IAX, source call# 19506, timestamp 3ms
ACK
15


49 28.297005 195.200.214.13 192.168.0.100 IAX2 IAX, source call# 19506, timestamp
12ms REGAUTH

IAX (ang. Inter-Asterisk eXchange) to protokół binarny VoIP stworzony w celu łączenia central
Asterisk (oprogramowanie centrali telefonicznej serwera VoIP na licencji GPL). Na początku
stosowany był głównie przy łączeniu central, jednak stosuje go coraz więcej telefonów
sprzętowych i programowych. Jego unikalną cechą jest możliwość łączenia kilku sesji połączeń
telefonicznych między dwiema centralami w jeden strumień UDP, gdzie w jednym pakiecie
przesyłane są dane dla kilku rozmów. IAX domyślnie korzysta z portu 4569.
No 47 – stacja o IP 192.168.0.100 wysyła zapytanie z prośbą o rejestrację nawiązania połączenia

telefonicznego (call# 19506 oflagowane jako REGREQ) do hosta 195.200.214.13, gdyż
komunikator Tlen ma wbudowany moduł do prowadzenia rozmów głosowych i wideokonferencji,
który przy starcie programu automatycznie jest inicjowany.
W no 48 i 49 stacja inicjująca połączenia 192.168.0.100 otrzymuje odpowiedź z serwera Asterisk o

IP 195.200.214.13 najpierw o otrzymaniu komunikatu (flaga ACK w no 48), a następnie prosi o
autoryzację rejestracji (flaga REGAUTH w no 49).
W rezultacie tych operacji połączenie telefoniczne zostaje zainicjowane i użytkownik komunikatora

tlen może nawiązać rozmowę głosową z innymi użytkownikami sieci.
16
6. Uruchomić wybraną stronę https i przeanalizować przechwycone dane.
HTTPS (ang. HyperText Transfer Protocol Secure) to szyfrowana wersja protokołu HTTP. Zamiast
używać w komunikacji klient-serwer niezaszyfrowanego tekstu, szyfruje go za pomocą protokołu
SSL. Zapobiega to przechwytywaniu i zmienianiu przesyłanych danych. HTTPS działa domyślnie
na porcie nr 443 w protokole TCP.
Analizę protokołu przeprowadziłam na przykładzie https://www.mbank.com.pl
Opis:

13 0.368371 192.168.0.100 199.7.71.72 OCSP Request

Transmission Control Protocol, Src Port: 3404 (3404), Dst Port: http (80), Seq: 1, Ack: 1, Len: 563
POST / HTTP/1.1\r\n
Host: evsecure-ocsp.verisign.com\r\n
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3\r\n
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
Accept-Language: pl,en-us;q=0.7,en;q=0.3\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.7\r\n
Keep-Alive: 115\r\n
Connection: keep-alive\r\n
Content-Length: 115\r\n
Content-Type: application/ocsp-request\r\n
\r\n
Online Certificate Status Protocol
OCSP (ang. Online Certificate Status Protocol) to protokół komunikacyjny pomiędzy systemem
informatycznym odbiorcy usług certyfikacyjnych a serwerem usługowym. Protokół ten określa
format i strukturę zapytania (żądania) o status certyfikatu oraz format i strukturę odpowiedzi
(tokenu), która zawiera wynik weryfikacji w postaci statusu: „poprawny”, „unieważniony”,
„nieznany”. Na powyższym przykładzie no 13 host o IP 192.168.0.100 takie żądanie do stacji o IP
199.7.71.72 (z portu 3404 do 80). Przesyła w tym celu m.in. informacje o przeglądarce (sekcja
user-agent), żądanie zaakceptowania standardów m.in. kodowania znaków (sekcja Accept-
Charset), języka (accept-language), utrzymania i długości sesji (Keep-Alive).
Ostatnim zbadanym przeze mnie protokołem jest TLS (ang. Transport Layer Security) – przyjęte
jako standard w Internecie rozwinięcie protokołu SSL (ang. Secure Socket Layer), które ma na
celu zapewnienie poufności i integralności transmisji danych oraz zapewnienie uwierzytelnienia.
TLS opiera się na szyfrach asymetrycznych, tzn. klucz służący do szyfrowania jest udostępniany
publicznie (klucz publiczny), ale informację nim zakodowaną może odczytać tylko posiadacz
klucza deszyfrującego (klucz prywatny), który nie jest nikomu ujawniany.
Poniżej fragment z pliku przechwyconych danych:

36 1.653700 192.168.0.100 193.41.230.81 TLSv1 Client Key Exchange, Change Cipher
Spec, Encrypted Handshake Message

Transmission Control Protocol, Src Port: 3403 (3403), Dst Port: https (443), Seq: 1, Ack: 1, Len: 318
Secure Socket Layer
17
...

38 1.692166 193.41.230.81 192.168.0.100 TLSv1 Encrypted Handshake Message

Transmission Control Protocol, Src Port: https (443), Dst Port: 3403 (3403), Seq: 7, Ack: 319, Len: 45
Secure Socket Layer
No 36 – stacja o IP 192.168.0.100 inicjuje ze stacją o IP 193.41.230.81 szyfrowaną wymianę

kluczy (z portu 3403 do 443).
No 38 – następuje kodowana wymiana informacji między stacjami 193.17.41.103 oraz

192.168.0.100. Handshake definiuje metody negocjowania parametrów bezpiecznej sesji.
Powoduje to, że tylko adres IP 192.168.0.100 może operować na jednej domenie lub też tylko
subdomenie danej domeny (zależnie od certyfikatu).
3. Wnioski
WireShark to rozbudowany analizator ruchu sieciowego o przyjaznym dla użytkownika interfejsie.
Jego obsługa jest bardzo intuicyjna, a w przypadku sytuacji problemowych użytkownik zawsze
może sięgnąć po wyczerpujący tutorial przygotowany przez producenta. Udostępnia praktyczne
narzędzia do analizy i przechowywania danych odnośnie przechwyconego ruchu sieciowego; jego
raporty możemy dowolnie filtrować (np. gdy chcemy uzyskać wykaz połączeń tylko według
protokołu FTP, albo połączenia z jakimś konkretnym hostem), przeglądać w formie statystyk, a
także eksportować np. do plików txt.
Praca z tym programem uświadomiła mi, jak ważne jest szyfrowanie sieci. Z jednej strony bowiem
WireShark może służyć jako potężne narzędzie administracyjne, z drugiej strony jednak – jako
groźne narzędzie w rękach hakera. Logi w programie bezlitośnie wyświetlają poufne informacje o
problemach z portami czy też hasła i nazwy użytkowników – do serwerów FTP, komunikatorów,
klientów pocztowych. W przypadku komunikatorów można nawet przechwycić całe konwersacje
nieświadomych niczego użytkowników.
W związku z tym na pewno warto bliżej zainteresować się tematyką bezpieczeństwa sieci.
Interesujące artykuły dotyczące tej kwestii:
http://www.pcworld.pl/artykuly/55637/Arsenal.antyhakera.html
http://www.pcworld.pl/artykuly/56525_0_1/Najgorsze.komunikatory.html
http://www.pctips.pl/artykuly/57125/Gadulamacze.i.podsluchiwacze.html
http://www.pzb.net.pl/index.php/Zagrozenia/Sniffing-podstepny-problem-w-zakresie-
bezpieczenstwa.html
http://home.elka.pw.edu.pl/~wmazurcz/moja/art/KSTiT2007.pdf
http://www.hsc.fr/ressources/articles/hakin9_wifi/hakin9_wifi_PL.pdf
http://www.netfocus.pl/raporty/wi-fi/co-widac-w-niezabezpieczonej-sieci-wi-fi
18

Duszenczuk Gr11IiE Sieci Komputerowe Lista WIRESHARK

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Duszenczuk Gr11IiE Sieci Komputerowe Lista WIRESHARK

Uploaded by

Copyright:

Available Formats

Danuta Duszeńczuk, gr.

11 IiE, I rok, nr indeksu 130701

Program można pobrać ze strony producenta:

Szczegółowy podręcznik użytkownika w języku angielskim można znaleźć pod adresem:

Prosty przewodnik w języku polskim dostępny jest pod:

1.2 Cel projektu

1.3 Kontakt i uwagi

W przypadku jakichkolwiek pytań, uwag i sugestii związanych z niniejszym projektem

1.4.a Jak ustawić uruchamianie WireShark z wiersza poleceń?

1. Na pulpicie znaleźć i kliknąć prawym przyciskiem myszki ikonę Mój komputer.

1.4.b Przykład zastosowania

Odpowiednio stosuje się wtedy komendy:

Aby uzyskać informacje o dostępnych interfejsach sieciowych, należy wpisać tshark -D

Do testu wybrałam ping na bramę internetową (IP 192.168.0.1)

Zrzut ekranu po wywołaniu ping:

No. Time Source Destination Protocol Info

Frame 5 (42 bytes on wire, 42 bytes captured)

No. Time Source Destination Protocol Info

Frame 6 (60 bytes on wire, 60 bytes captured)

W powyższym fragmencie raportu widać proces identyfikowania. W wierszu no 5 komputer

No. Time Source Destination Protocol Info

Frame 7 (74 bytes on wire, 74 bytes captured)

No. Time Source Destination Protocol Info

Frame 8 (74 bytes on wire, 74 bytes captured)

W powyższym przykładzie można zaobserwować pingi pomiędzy komputerem o IP

2. Uruchomić program tracert dla różnych stacji podając adres domenowy.

Do testu wybrałam tracert na domenę www.ue.wroc.pl

No. Time Source Destination Protocol Info

Frame 1 (106 bytes on wire, 106 bytes captured)

No. Time Source Destination Protocol Info

Frame 2 (70 bytes on wire, 70 bytes captured)

No. Time Source Destination Protocol Info

Frame 3 (106 bytes on wire, 106 bytes captured)

Wiersze no 1 i 3 należy interpretować analogicznie jak wiersze no 7 i 8 w zadaniu 1; wiersz no 2

No. Time Source Destination Protocol Info

Frame 25 (86 bytes on wire, 86 bytes captured)

No. Time Source Destination Protocol Info

Frame 26 (124 bytes on wire, 124 bytes captured)

No 25 – stacja o IP 192.168.0.100 wysyła standardowe zapytanie do serwera (IP 82.143.159.7) o

3. Uruchomić przeglądarkę WWW dla wybranych adresów sieciowych

Wybrałam adres www.ue.wroc.pl – analizie poddałam protokół HTTP.

WireShark po zastosowaniu filtra wskazuje dwa zapytania do wybranego hosta:

Dane o przechwyconym połączeniu z Capture file:

No. Time Source Destination Protocol Info

No. Time Source Destination Protocol Info

No. Time Source Destination Protocol Info

Frame 6 (660 bytes on wire, 660 bytes captured)

Frame 60 (1048 bytes on wire, 1048 bytes captured)

Frame 62 (745 bytes on wire, 745 bytes captured)

Protokół HTTP (ang. Hypertext Transfer Protocol) służy do przesyłania dokumentów

No 6 – stacja o adresie IP192.168.0.100 wysyła poprzez bramę komunikat do stacji o IP

No 62 – stacja 192.168.0.100 wysyła kolejne żądanie do stacji 156.17.118.245 metodą GET,

4. Uruchomić program FTP, zalogować się na dowolny adres, przesłać plik

No. Time Source Destination Protocol Info

Frame 11 (98 bytes on wire, 98 bytes captured)

No. Time Source Destination Protocol Info

Frame 12 (73 bytes on wire, 73 bytes captured)

Frame 13 (91 bytes on wire, 91 bytes captured)

Podstawy protokołu FTP, opis i zasada działania znajdują się na stronie:

No 11 – serwer o IP 88.198.196.10 przesyła do komputera o IP 192.168.0.100 informację, że

No 12 – gdy na komputerze 192.168.0.100 podane zostało hasło, protokół przesyła je do serwera

No 13 – serwer FTP przesyła do stacji 192.168.0.100 potwierdzenie zalogowania się na niego.

No. Time Source Destination Protocol Info

Frame 34 (1514 bytes on wire, 1514 bytes captured)