Tcpdump jest narzędziem pozwalającym przyjrzeć się szczegółowo ruchowi, z jakim ma do czynienia maszyna, na której pracujemy, a w sprzyjających warunkach nawet cała sieć, w której pracujemy. Dzięki temu możemy się zorientować, czy część ruchu nie jest przypadkiem ruchem nieprawidłowym, wskazującym na problemy z konfiguracją, albo na problemy związane z atakiem intruzów.
Na dobry początek warto zorientować się, na jakich interfejsach komunikacyjnych możemy wykonywać nasłuchiwanie:
# sudo tcpdump -D
W wyniku otrzymamy odpowiedź w stylu
1.enp0s25 [Up, Running, Connected] 2.wlp3s0 [Up, Running, Wireless, Associated] 3.any (Pseudo-device that captures on all interfaces) [Up, Running] 4.lo [Up, Running, Loopback] 5.docker0 [Up, Disconnected] 6.bluetooth0 (Bluetooth adapter number 0) [Wireless, Association status unknown] 7.bluetooth-monitor (Bluetooth Linux Monitor) [Wireless] 8.usbmon3 (Raw USB traffic, bus number 3) 9.usbmon2 (Raw USB traffic, bus number 2) 10.usbmon1 (Raw USB traffic, bus number 1) 11.usbmon0 (Raw USB traffic, all USB buses) [none] 12.nflog (Linux netfilter log (NFLOG) interface) [none] 13.nfqueue (Linux netfilter queue (NFQUEUE) interface) [none]
która nam wskaże, że nie tylko mamy interfejs sieciowy bezprzewodowy
(wlp3s0) oraz bezprzewodowy (enp0s25), ale
także że możemy przysłuchiwać się komunikacji Bluetooth czy przez
porty szeregowe USB albo też dowiadywać się, co się dzieje na naszej
ścianie ogniowej zaimplementowanej za pomocą netfilter.
W związku z tym, że program tcpdump może pokazywać
informacje niekoniecznie publiczne, dostęp do jego wykonywania jest
zwykle możliwy tylko, jeśli mamy prawa administratora. Stąd
wszystkie wywołania tego polecenia w tej czytance są poprzedzone
wywołaniem programu sudo. Wywołanie to można opuścić,
jeśli wykonujemy polecenia jako root.
Spróbujmy pozyskać jakieś informacje z urządzeń sieciowych, do których jesteśmy podłączeni. Najprościej można zrobić to tak:
# tcpdump -i any
Polecenie to sprawi, że zaczniemy uzyskiwać informacje o wszystkich
pakietach trafiających do dowolnego z interfejsów komunikacyjnych,
które są przeglądane przez tcpdump. Przykładowy wynik,
jaki możemy tu uzyskać to:
tcpdump: data link type LINUX_SLL2 dropped privs to tcpdump tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes 15:55:23.012033 enp0s25 In IP6 waw02s13-in-x0a.1e100.net.https > aronia.mimuw.edu.pl.52458: UDP, length 85 15:55:23.012712 enp0s25 In IP6 waw02s13-in-x0a.1e100.net.https > aronia.mimuw.edu.pl.52458: UDP, length 29 15:55:23.012913 enp0s25 Out IP6 aronia.mimuw.edu.pl.52458 > waw02s13-in-x0a.1e100.net.https: UDP, length 42 15:55:23.156775 wlp3s0 In IP intra-ns2.mimuw.edu.pl.domain > aronia.mimuw.edu.pl.52006: 1466 1/0/1 PTR waw02s13-in-x0a.1e100.net. (140) 15:55:23.157374 enp0s25 In IP6 waw02s13-in-x0a.1e100.net.https > aronia.mimuw.edu.pl.52458: UDP, length 1332
Powyższy wynik to fragment szybko przesuwającej się ściany tekstu,
jaką zwykle w takiej sytuacji możemy zobaczyć. Każdy wiersz tutaj
zawiera opis konkretnego pakietu, który trafił do nas
(adnotacja In w trzeciej kolumnie) lub został z naszej
maszyny wysłany (adnotacja Out w trzeciej kolumnie), a
odbyło się to w konkretnym punkcie czasu (zawartość pierwszej
kolumny) na wskazanym interfejsie (zawartość drugiej kolumny).
Jak łatwo się domyślić, widzimy tutaj trochę ruchu po IPv6 i trochę
po IPv4. Widać też tutaj trochę ruchu po protokole transportowym UDP
oraz jedną odpowiedź z systemu DNS (w punkcie czasowym
15:55:23.156775).
Warto też rozumieć, że w powyższych napisach wskazane jest też, kto jest nadawcą i odbiorcą pakietu. Na przykład fragment jednego z zapisów:
aronia.mimuw.edu.pl.52458 > waw02s13-in-x0a.1e100.net.https
wskazuje, że nadawcą pakietu jest komputer o adresie DNS
aronia.mimuw.edu.pl (na lewo od znaku >), zaś
odbiorcą komputer o adresie
DNS waw02s13-in-x0a.1e100.net (na prawo od znaku
>). Pozostaje wyjaśnić, czym są pozostałe fragmenty napisów,
tzn. 52458 oraz https. Otóż są to numery
portów, między którymi następuje komunikacja. W tym przypadku
komunikacja zachodzi między portem 52458 o nieustalonej
funkcjonalności na maszynie aronia.mimuw.edu.pl a
portem 443 na
maszynie waw02s13-in-x0a.1e100.net, który ma ustaloną
domyślną funkcjonalność – jest to port protokołu HTTP działającego w
tunelu SSL. Powiązanie numeru portu (443) z usługą (https) wraz z wieloma innymi tego typu powiązaniami możemy
znaleźć w pliku /etc/services.
Przy diagnozowaniu stanu sieci często się zdarza, że adresy DNS nie
są dostępne (bo nie możemy się skomunikować z serwerem DNS). Wtedy
wygodnym sposobem na uzyskanie wyników z
programu tcpdump jest:
# sudo tcpdump -n -i any
Po takim wywołaniu wszystkie adresy będą wyświetlane w postaci adresów IP (zarówno IPv4, jak i IPv6).
Jeśli dodatkowo chcemy widzieć raczej numery portów niż nazwy usług
im odpowiadającym, to możemy wywołać tcpdump tak:
# sudo tcpdump -nn -i any
Często się zdarza, że nie chcemy oglądać ciągnącej się ściany napisów, a jedynie rzucić okiem na kilka pakietów. Zwykle już to pozwala zorientować się, z jakim rodzajem awarii sieciowej mamy do czynienia (np. dużo pakietów DHCP wychodzących, ale za to żadnego przychodzącego, może świadczyć o tym, że nie mamy połączenia z lokalnym serwerem DHCP). W takiej sytuacji pomoże nam polecenie
# sudo tcpdump -i any -c3
które wyświetli nam tylko 3 pakiety (nazwa opcji -c pochodzi od angielskiego count).
Zwykle jednak oglądanie całego ruchu sieciowego jest zbyt trudne i chcemy się skupić na konkretnym jego wycinku. Do tego przydają się filtry. Najprostszy rodzaj filtru polega na podaniu rodzaju protokołu, jaki nas interesuje. Na przykład polecenie
# sudo tcpdump -i any -c3 udp
da nam wynik:
tcpdump: data link type LINUX_SLL2 dropped privs to tcpdump tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes 12:46:14.158336 wlp3s0 Out IP aronia.mimuw.edu.pl.45130 > _gateway.domain: 29009+ AAAA? ade.googlesyndication.com. (43) 12:46:14.158435 wlp3s0 Out IP aronia.mimuw.edu.pl.42889 > _gateway.domain: 5748+ A? ade.googlesyndication.com. (43) 12:46:14.169924 wlp3s0 Out IP aronia.mimuw.edu.pl.44201 > waw02s07-in-f161.1e100.net.https: UDP, length 401 3 packets captured 11 packets received by filter 0 packets dropped by kernel
za pomocą którego dowiemy się, że ruch DNS na lokalnej maszynie odbywa się za pomocą właśnie protokołu UDP (mogłoby też odbywać się za pomocą TCP). Warto jednak pamiętać, że takie określenie protokołu jest możliwe dla protokołów, które znajdują się co najwyżej na poziomie warstwy transportowej i sieci (tcp, udp, ip6, arp itp.).
Jeśli chcielibyśmy obejrzeć protokoły warstwy łącza, to musimy dodać jeszcze jedną opcję do wywołania. Wykonanie polecenia
# sudo tcpdump -i any -e -c3
da nam taki wynik:
# sudo tcpdump -i any -e -c3 tcpdump: data link type LINUX_SLL2 dropped privs to tcpdump tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes 13:01:29.120674 wlp3s0 In ifindex 3 76:c3:78:19:ee:44 (oui Unknown) ethertype IPv4 (0x0800), length 123: ed-in-f189.1e100.net.https > aronia.mimuw.edu.pl.60538: Flags [P.], seq 2827910991:2827911042, ack 1309638939, win 395, options [nop,nop,TS val 2425401776 ecr 996398348], length 51 13:01:29.120714 wlp3s0 Out ifindex 3 7c:7a:91:04:ba:ff (oui Unknown) ethertype IPv4 (0x0800), length 72: aronia.mimuw.edu.pl.60538 > ed-in-f189.1e100.net.https: Flags [.], ack 51, win 501, options [nop,nop,TS val 996427838 ecr 2425401776], length 0 13:01:29.223349 wlp3s0 Out ifindex 3 7c:7a:91:04:ba:ff (oui Unknown) ethertype IPv4 (0x0800), length 93: aronia.mimuw.edu.pl.34372 > _gateway.domain: 59285+ PTR? 189.143.125.74.in-addr.arpa. (45) 3 packets captured 4 packets received by filter 0 packets dropped by kernel
gdzie możemy zauważyć adresy, w tym przypadku ethernetowe (6 kolumna), informacje o numerze interfejsu (po słówku ifindex), informacje o rodzaju zawartości pakietu (po słówku ethertype) itp.
Często chcemy dowiedzieć się, jak wygląda ruch między komputerem a zewnętrznym światem, często z określonym komputerem:
# sudo tcpdump -i any -c3 host usosweb.mimuw.edu.pl
lub pod określonym portem
# sudo tcpdump -i any -c3 port https
(tutaj https można zastąpić oczywiście też przez 443).
Oczywiście nieco bardziej przydatna jest możliwość określenia, że interesuje nas ruch do konkretnego komputera pod konkretny port. Takie coś możemy uzyskać za pomocą łączenia reguł za pomocą wyrażeń logicznych:
# sudo tcpdump -i any -c3 host students.mimuw.edu.pl and port https
Gdyby nas natomiast interesował ruch do naszego lokalnego serwera, SSH, to można go uzyskać za pomocą polecenia:
# sudo tcpdump -i any -c3 \(src host aronia.mimuw.edu.pl or src host localhost\) and src port 22
Warto zwrócić uwagę na to, że bardziej skomplikowane wyrażenia wymagają użycia nawiasów, ale ponieważ nawiasy są znakami znaczącymi powłoki poleceń, to trzeba je ozdobić odpowiednim znakiem ochronnym.
Czasami nasza analiza ruchu może być czasochłonna. Wtedy zwykle lepiej jest nagrać sobie interesujący fragment ruchu na dysku i potem stosować filtry już na nim. Do nagrywania służy polecenie:
# sudo tcpdump -i any -e -w nazwapliku
które zapisze dane ściągnięte z sieci do pliku o nazwie nazwapliku. Odczytać dane można za pomocą polecenia
# sudo tcpdump -i any -e -r nazwapliku
które oczywiście można do woli ozdabiać potrzebnymi filtrami. Warto
sobie zakonotować, że do pliku nie trafiają całe pakiety, ale ich
początkowe fragmenty. Długość tych fragmentów można konfigurować za
pomocą odpowiedniej opcji tcpdump. Zapraszamy do jej
wyszukania na stronie man.
Więcej na temat różnych możliwości filtrowania można przeczytać na
stronie man pcap-filter (nota bene pcap to
nazwa biblioteki, która pozwala na śledzenie pakietów, jakie
trafiają na urządzenia sieciowe do komputera.
Program wireshark to w zasadzie graficzna nakładka na
program tcpdump. Nakładka ta ma jednak pewne cechy,
które są bardzo użyteczne, a nie tak łatwe do uzyskania za pomocą
tego ostatniego. Najważniejsza z nich to możliwość uzyskania
ciągłego obrazu sesji TCP. W tym celu należy (po określeniu, z
jakiego źródła będziemy analizować dane) wybrać z menu opcję
Analizuj/Podążaj/Strumień TCP (lub Analyze/Follow/TCP Stream).
Warto przećwiczyć użycie filtrów wspomnianych przy okazji oglądania
programu tcpdump. Z maszyną wirtualną można się
połączyć za pomocą polecenia.
# ssh -Y adres_maszyny
takie wywołanie pomoże wyświetlać graficzną aplikację, jaką
jest wireshark.
Spróbujcie za pomocą programu wireshark znaleźć hasło
do jednego konta, które zostało utrwalone w załączonym
pliku dump. Hasło w pliku tekstowym należy przesłać
do Moodle.
| Załącznik | Wielkość |
|---|---|
| dump.tgz | 11.08 KB |