Wykonywanie przechwytywania pakietów przy użyciu sniffera może być niezwykle skuteczną metodą diagnozowania złożonych problemów. Kiedy wszystko inne zawiedzie, często pomocne jest przejrzenie nieprzetworzonych danych przesyłanych przez sieć. Pakiety nie kłamią, a analiza ruchu aplikacji na niskim poziomie może ujawnić głębsze symptomy problemu (lub ujawnić problem, o którym nawet nie wiedziałeś).
W tym artykule omówię kilka podstaw korzystania z narzędzia tcpdump opartego na CLI.
Podstawy sniffera
Na początek najpierw rzeczy: co mamy na myśli, mówiąc „sniffer pakietów”? Sniffer pakietów to po prostu oprogramowanie, które umożliwia przechwytywanie pakietów w sieci. Tcpdump i Wireshark to przykłady snifferów pakietów. Tcpdump zapewnia sniffer pakietów CLI, a Wireshark zapewnia bogate w funkcje GUI do wykrywania i analizowania pakietów.
Domyślnie tcpdump działa w trybie rozwiązłym. Oznacza to po prostu, że wszystkie pakiety docierające do hosta będą wysyłane do tcpdump w celu sprawdzenia. To ustawienie obejmuje nawet ruch, który nie był przeznaczony dla określonego hosta, na którym przechwytujesz, taki jak ruch emisji i multiemisji. Oczywiście tcpdump nie jest jakimś magicznym oprogramowaniem: może przechwytywać tylko te pakiety, które w jakiś sposób docierają do jednego z fizycznych interfejsów na twoim komputerze.
Instalowanie tcpdump jest proste. Jest dostępny w standardowych repozytoriach pakietów w systemie Red Hat i możesz go zainstalować według nazwy:
Typowe scenariusze wykrywania pakietów
Przechwytywanie całego ruchu przychodzącego do twojego komputera może wydawać się fajne koncepcyjnie, ale również brzmi dość nisko w przypadku wielu czynności, które wykonujemy w naszej codziennej pracy jako administratorzy systemów. Kiedy więc użyłbyś narzędzia do przechwytywania pakietów? Zazwyczaj korzystam z sniffera pakietów, gdy rozwiązuję problem z aplikacją sieciową i wyczerpałem wszystkie inne opcje. Często wykonywałem już podstawowe rozwiązywanie problemów z siecią i przeglądałem wszelkie pliki dziennika aplikacji, ale nadal nie mogę dojść do sedna problemu. W tym momencie rozerwanie sniffera pakietów w celu zaobserwowania rzeczywistych danych przesyłanych przez kabel może być pouczające.
Kolejny wspaniały przypadek użycia sniffera pakietów jest pedagogiczny. Obserwowanie pakietów biorących udział w wymianie aplikacji może znacznie przyczynić się do lepszego zrozumienia podstawowych protokołów. Na przykład obserwacja pełnego przepływu pakietów rekursywnego zapytania DNS może być nieoceniona, gdy próbujesz zrozumieć, jak działa DNS.
Wykonywanie podstawowego przechwytywania pakietów
Najlepszym sposobem nauki jest po prostu nurkując, więc zacznijmy od przechwytywania podstawowych pakietów. Najpierw wypróbujmy tcpdump bez żadnych specjalnych opcji. Pamiętaj, że musisz być superużytkownikiem, aby przechwytywać pakiety (technicznie rzecz biorąc, możesz uruchomić to ze zwykłego konta ze specjalnymi możliwościami, ale zwykle łatwiej jest uruchomić je jako root). Użyj Ctrl + C lub wyślij SIGTERM do tcpdump identyfikatora procesu (PID), aby zatrzymać przechwytywanie.
Domyślnie tcpdump
Do zobacz domyślne wyjście tcpdump, po prostu wpisz polecenie:
Uwaga: Zamiast mieć dużo danych wyjściowych, przed naciśnięciem Ctrl + C możesz określić ile pakietów chcesz zobaczyć z flagą -c. Powyższe polecenie mogłoby zamiast tego wyglądać na tcpdump -c 6, aby uzyskać te same wyniki (sześć przechwyconych pakietów).
Dane wyjściowe z tcpdump na początku może być trochę onieśmielające, ale po kilkukrotnym użyciu tego narzędzia przyzwyczaisz się do patrzenia na to. Podzielmy pola od lewej do prawej:
Wąchanie określonego interfejsu
Zauważ, że na górze wyników poprzedniego przykładu widać interfejs, który tcpdump rozpoczyna przechwytywanie w (eth0), a na dole przechwytywania znajdują się podsumowania statystyk dotyczących przechwyconych pakietów.
Pierwszą rzeczą, którą prawdopodobnie będziesz chciał zrobić, używając tcpdump służy do określenia konkretnego interfejsu do przechwytywania. Domyślnie tcpdump wybierze interfejs o najniższym numerze, czyli „w górę”. Wiele serwerów ma wiele interfejsów i chcesz wyraźnie określić interfejs, którego używasz do przechwytywania. Ponadto niektóre „specjalne” typy interfejsów, takie jak interfejs netfilter, mogą znajdować się na początku listy. Takie zachowanie może powodować zamieszanie, dlatego najlepiej jest określić interfejs, który Cię interesuje.
Zacznijmy od przejrzenia interfejsów, które są dostępne do przechwytywania:
Z listą interfejsów do naszej dyspozycji, możemy teraz określić interfejs do nasłuchiwania za pomocą flagi -i.Zwróć uwagę, że można użyć nazwy interfejsu lub numeru z polecenia --list-interfaces:
Spojrzenie na powyższe przechwycenia dostarcza podstawowych informacji o pakietach przechodzących przez nasz sieć. Wygląda na to, że te pakiety zawierają dane wyjściowe protokołu Spanning Tree Protocol (STP), być może z przełącznika nadrzędnego. Z technicznego punktu widzenia nie są to pakiety, są to ramki w warstwie drugiej. Jednak podczas omawiania przechwytywania pakietów usłyszysz terminy używane zamiennie.
Uzyskiwanie dodatkowych informacji
Prosty wynik rozwiązywania problemów z poprzedniego przykładu może być świetny do identyfikowania oczywistych problemów, ale czasami potrzebujemy więcej informacji, aby naprawdę zagłębić się w złożony problem. Wiedza o tym, jak dostosować szczegółowość przechwytywania jest ważna, ponieważ pozwala głębiej zagłębić się w rzeczywiste dane zawarte w pakietach.
Poziom szczegółowości tcpdump jest kontrolowane przez dodanie od jednej do trzech flag -v do polecenia:
Zauważ, że określając maksymalny poziom szczegółowości, mogę uzyskać znacznie więcej informacji na temat korpus pakietu. Powyżej możemy zobaczyć dodatkowe informacje o danych w pakiecie STP, takie jak identyfikator mostu głównego i koszt ścieżki głównej. Jeśli nie znasz STP, nie martw się tym. Należy tu zauważyć, że zwiększając szczegółowość, możemy uzyskać dodatkowe informacje o ruchu w sieci.
Sprawdzanie dokładnych bajtów pakietu
Zwiększanie szczegółowości jest przydatne, ale Nadal nie widzę zawartości pakietów. Jeśli naprawdę chcesz zobaczyć dokładne bajty zawarte w pakietach, możesz użyć flag -x i -X. Flaga -x drukuje dane w każdym pakiecie w formacie szesnastkowym, podczas gdy flaga -X również drukuje dane w kodzie ASCII. Oto dane wyjściowe za pomocą -x:
A tutaj dane wyjściowe za pomocą -X:
Zwróć uwagę na dane szesnastkowe i ASCII w powyższych przykładach. W tym przypadku wykonywałem zapytanie o rekord DNS A dla . Zwróć również uwagę, że użyłem flagi -c, aby określić liczbę pakietów do przechwycenia, i podałem filtr przechwytywania port 53. Filtry omówimy w następnym artykule.
Trzymanie się liczb
Podczas pracy z tcpdump możesz zauważyć że jej domyślnym zachowaniem jest automatyczne tłumaczenie adresów IP na w pełni kwalifikowane nazwy domen (FQDN). Tcpdump przetłumaczy również numery portów (na przykład 22) na przyjazne nazwy (takie jak SSH). Chociaż takie zachowanie jest przyjemne, często chcemy zobaczyć dane liczbowe, aby w żaden sposób nie utrudniać rozwiązywania problemów. To domyślne zachowanie można zmienić, przekazując -n, aby wyłączyć wyszukiwanie adresów IP, lub -nn, aby wyłączyć wyszukiwanie adresów IP i portów.
Oto wynik użycia -nn:
Zapisywanie zrzutu
W pewnym momencie możesz chcieć aby zapisać przechwycone pakiety do późniejszej analizy lub do głębszej analizy za pomocą narzędzia graficznego, takiego jak Wireshark. To zadanie można łatwo wykonać za pomocą flagi -w, która umożliwia zapisanie pliku przechwytywania pakietów:
Uwaga: Zapisany plik można odczytać za pomocą tcpdump z flagą -r lub z inną aplikacją obsługującą format pliku pcap.
Jak widać powyżej , flaga -w utworzyła poręczny plik pcap, który możemy zabrać ze sobą.
Podsumowanie
Przechwytywanie pakietów to potężna technika w spisie umiejętności rozwiązywania problemów z siecią, zwłaszcza gdy utkniesz w problemie, a reszta sieci wygląda dobrze. Zrozumienie, jak używać tcpdump w wierszu poleceń, może zaoszczędzić wiele godzin frustracji podczas rozwiązywania problemów z aplikacjami sieciowymi, a składnia jest dość intuicyjna, gdy się do tego przyzwyczaisz.