Co to jest Wireshark i do czego służy ten analizator protokołów sieciowych?

Wireshark to darmowy analizator protokołów sieciowych, który przechwytuje ruch danych w czasie rzeczywistym i tłumaczy go na format czytelny dla człowieka. Ten program służy administratorom i inżynierom bezpieczeństwa do diagnozowania awarii, namierzania wycieków z infrastruktury oraz badania podejrzanych pakietów przesyłanych przez karty sieciowe. Aplikacja działa na poziomie warstwy łącza danych w modelu OSI. Widzi absolutnie wszystko, co wchodzi i wychodzi z danego interfejsu. To potężne narzędzie diagnostyczne. Skraca czas szukania problemu z kilku dni do kilkunastu minut.

Rozumiemy ten mechanizm na prostej zasadzie podsłuchu. Karta sieciowa w twoim komputerze zazwyczaj ignoruje pakiety, które nie są adresowane bezpośrednio do niej. Wireshark wymusza na karcie przejście w tryb nasłuchu (promiscuous mode). Interfejs zaczyna chłonąć każdą ramkę Ethernet przelatującą przez kabel lub sieć Wi-Fi. Oprogramowanie zapisuje te dane w formacie pcapng. Następnie rozbija surowe zera i jedynki na konkretne nagłówki protokołów takich jak TCP, UDP, DNS czy HTTP. Ty widzisz to na ekranie w formie uporządkowanej tabeli z adresami źródłowymi i docelowymi.

Jak dokładnie działa Wireshark od strony technicznej?

Silnik programu opiera się na bibliotece libpcap w systemach Linux oraz Npcap w środowisku Windows. Te biblioteki komunikują się bezpośrednio ze sterownikami sprzętowymi. Omijają standardowy stos sieciowy systemu operacyjnego. Zbierają dane zanim zapora sieciowa zdąży je przetworzyć lub odrzucić. To daje ci surowy i niezakłamany obraz sytuacji na kablu.

Pamiętam wtorek rano na wdrożeniu centrali pod Poznaniem. Zrobiliśmy konfigurację SIP, potem padł routing na firewallu, więc wprowadzono poprawkę ACL przed poniedziałkiem. Wireshark wypluł nam setki retransmisji protokołu RTP. Szlag człowieka trafia przy takim debugowaniu w ciemno bez zrzutu ruchu. Podpięliśmy laptopa do portu span na switchu i od razu wyszło, że pakiety głosowe odbijają się od błędnie skonfigurowanej bramy domyślnej. Błąd naprawiliśmy w trzy minuty. Bez analizatora szukalibyśmy przyczyny w oprogramowaniu telefonów.

Interfejs graficzny dzieli się na trzy główne okna. Górne pokazuje listę przechwyconych pakietów. Środkowe pozwala rozwijać szczegóły konkretnej ramki warstwa po warstwie. Dolne wyświetla surowy zrzut szesnastkowy i kody ASCII. Taki układ pozwala na szybką korelację tego, co widzisz w nagłówku, z tym, co fizycznie poszło w sieć.

Zrzuty pamięci z dużych sieci potrafią zająć gigabajty miejsca na dysku. Dlatego programiści zaimplementowali mechanizm tshark. To wersja Wiresharka działająca w linii komend. Służy do automatycznego logowania ruchu na serwerach bez środowiska graficznego. Wrzucasz skrypt na maszynę linuksową, zostawiasz na noc i rano analizujesz gotowy plik pcap na własnym komputerze.

Kto najczęściej używa snifferów i po co to robi na produkcji?

Zastosowania tego oprogramowania wykraczają daleko poza akademickie laboratoria. Prawda jest zresztą absolutnie taka, że nikt nie instaluje Wiresharka dla zabawy. Odpala się go, gdy standardowe metody zawodzą. Wymienię cztery grupy specjalistów, dla których praca ze snifferem to chleb powszedni:

• Administratorzy sieciowi diagnozujący pętle routingu i problemy z protokołami dynamicznymi takimi jak OSPF czy BGP.
• Inżynierowie cyberbezpieczeństwa łapiący złośliwy ruch z zainfekowanych stacji roboczych komunikujących się z serwerami Command and Control.
• Deweloperzy aplikacji sprawdzający, dlaczego ich kod wysyła zniekształcone żądania API do bazy danych.
• Audytorzy weryfikujący, czy wrażliwe dane logowania nie latają po sieci w postaci czystego tekstu bez szyfrowania.

Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze? Sam się nad tym borykałem dzisiaj u siebie w biurze. Deweloper twierdził, że aplikacja wysyła poprawne zapytanie GET. Serwer odpowiadał błędem 400 Bad Request. Odpaliliśmy sniffer i od razu wyszło, że aplikacja doklejała niewidoczny znak nowej linii do nagłówka autoryzacyjnego. Oprogramowanie po prostu NIE WIE co to za wartość i zrywa sesję. Logi serwera milczały. Sniffer pokazał nagą prawdę na poziomie pojedynczych bajtów.

Czy Wireshark jest legalny w firmie i w domu?

Samo posiadanie i używanie analizatora protokołów jest całkowicie zgodne z prawem. Problem leży w tym, do kogo należy sieć i jakie dane przechwytujesz. Własna sieć domowa to twój prywatny poligon. Możesz tam podsłuchiwać ruch z telewizora, lodówki czy telefonu. W środowisku korporacyjnym potrzebujesz wyraźnej zgody na piśmie od zarządu lub działu prawnego.

Skanowanie ruchu obcych użytkowników bez ich wiedzy w publicznej kawiarni podpada pod paragrafy o naruszeniu tajemnicy korespondencji i nielegalnym dostępie do informacji. To narzędzie działa jak nóż. Możesz nim pokroić chleb albo zrobić komuś krzywdę. W środowiskach B2B wpisujemy użycie snifferów w procedury reagowania na incydenty. Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj z logów firmowych, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał przed zmianą polityki prywatności w firmach z branży finansowej.

Jakie są główne funkcje filtrowania ruchu sieciowego?

Filtrowanie to absolutna podstawa. Bez tego utoniesz w setkach tysięcy pakietów ARP i rozgłoszeniowych wiadomości z drukarek. Wireshark wykorzystuje dwa odrębne mechanizmy odcedzania danych. Musisz zrozumieć różnicę między nimi, by nie obciążyć procesora i nie zapchać dysku twardego w kilka minut.

Pierwszy mechanizm działa na poziomie karty sieciowej i sterownika. Drugi działa już po zapisaniu danych do pamięci RAM. Pomyłka w zastosowaniu składni powoduje odrzucenie komendy. Użytkownicy często wpisują polecenia z jednego języka do drugiego i dziwią się, że interfejs świeci na czerwono sygnalizując błąd składniowy.

Czym różnią się filtry przechwytywania od filtrów wyświetlania?

Filtry przechwytywania (Capture Filters) odcinają niechciany ruch zanim ten w ogóle trafi na dysk. Używają składni Berkeley Packet Filter (BPF). Są proste i brutalne w swoim działaniu. Z kolei filtry wyświetlania (Display Filters) ukrywają pakiety w oknie programu, ale nie usuwają ich z zapisanego pliku pcap. Korzystają z własnego, bardzo rozbudowanego języka zapytań.

Dobrym pomysłem jest stosowanie filtrów przechwytywania na produkcji. Wpisujesz proste port 443 i program zrzuca tylko ruch szyfrowany webowy. Oszczędzasz gigabajty przestrzeni. Gdy masz już plik na dysku, używasz filtrów wyświetlania. Wpisujesz tcp.analysis.flags i na ekranie zostają tylko pakiety z błędami retransmisji czy duplikatami potwierdzeń. To natychmiast zawęża pole poszukiwań.

Jak diagnozować awarie i gubienie pakietów TCP?

Awarie transmisji TCP to codzienność w dużych infrastrukturach. Protokół TCP został zaprojektowany z myślą o niezawodności. Jeśli zgubi pakiet po drodze, wyśle go ponownie. Problem pojawia się, gdy tych zgubionych pakietów jest za dużo. Aplikacja zwalnia do zera, a użytkownicy zgłaszają lagi.

Otwierasz zrzut ruchu z maszyny klienckiej. Zwracasz uwagę na czarne paski w interfejsie. Program automatycznie koloruje pakiety z problemami. Widzisz komunikaty TCP Retransmission. Oznaczają one, że nadawca nie dostał potwierdzenia ACK od odbiorcy i musiał wysłać dane jeszcze raz. Często obok pojawiają się komunikaty TCP Dup ACK. To sygnał od odbiorcy mówiący „dostałem pakiet numer 5 i pakiet numer 7, brakuje mi szóstki, wyślij ją natychmiast”.

Wysoka latencja to kolejny morderca wydajności. W modelu klient-serwer badamy czas trwania trójetapowego nawiązania połączenia (TCP Three-way Handshake). Klient wysyła pakiet SYN. Serwer odpowiada SYN-ACK. Klient potwierdza ACK. Jeśli czas między SYN a SYN-ACK przekracza trzysta milisekund w sieci lokalnej, masz poważny problem z przeciążonym sprzętem węzłowym. Sniffer pozwala zmierzyć ten czas z dokładnością do mikrosekund.

Zmieniliśmy te zasady na robocie w zeszłym miesiącu. Zamiast pingować maszyny, od razu rzucamy zrzut ruchu z serwera bazy danych. Wyszło nam, że zapytania SQL wykonują się szybko, ale sterownik sieciowy na wirtualnej maszynie fragmentował pakiety do rozmiaru 500 bajtów. Zamiast wysłać jedną dużą ramkę, wysyłał trzy małe. Narzut nagłówków zabijał przepustowość. Zwiększyliśmy MTU na interfejsie i problem zniknął.

Gdzie kończą się możliwości darmowych analizatorów ruchu?

Większość ruchu w internecie jest dzisiaj zaszyfrowana. Protokół TLS 1.3 stał się standardem. Oznacza to poważny problem dla inżynierów sieciowych. Wireshark potrafi przechwycić taki ruch, ale pokaże ci tylko niezrozumiały ciąg losowych znaków w sekcji danych warstwy aplikacji. Widzisz, że dwa hosty rozmawiają, ale nie masz pojęcia o czym.

Istnieją metody na obejście tego ograniczenia w kontrolowanym środowisku. Możesz wyeksportować klucze sesyjne przeglądarki do pliku ustawiając zmienną środowiskową SSLKEYLOGFILE. Podpinasz ten plik w ustawieniach programu i nagle zaszyfrowany ruch HTTPS staje się w pełni czytelnym protokołem HTTP/2. Widzisz nagłówki, ciasteczka i zawartość pobieranych obrazków. To działa tylko na twoim własnym komputerze z twoją własną przeglądarką.

W sieciach korporacyjnych rozszyfrowywanie ruchu na żywo wymaga wdrożenia mechanizmów SSL Inspection na urządzeniach brzegowych. Firewall przejmuje rolę serwera dla klienta i klienta dla serwera (atak Man-in-the-Middle za zgodą administratora). Rozszyfrowuje pakiet, skanuje go pod kątem wirusów, szyfruje ponownie i wysyła dalej. Wireshark sam w sobie nie złamie współczesnej kryptografii. Odczyta tylko to, do czego dostarczysz mu odpowiedni klucz prywatny lub plik z logami sesji.

Kolejnym ograniczeniem jest wydajność. Przechwytywanie ruchu na łączu o przepustowości dziesięciu gigabitów na sekundę zabije standardowy procesor. Baza danych wpadnie w zadyszkę. Pakiety zaczną być gubione przez sam sterownik sniffera. W takich scenariuszach sprzętowe analizatory sieci za setki tysięcy złotych wygrywają z darmowym oprogramowaniem. Mają dedykowane układy FPGA do chwytania ramek z kabla światłowodowego bez obciążania systemu operacyjnego.

Często zapominamy o odpowiednim pozycjonowaniu sondy w sieci. Podpięcie laptopa do zwykłego portu w switchu pokaże ci tylko ruch adresowany do tego konkretnego portu. Switch to nie hub. Filtruje ruch na podstawie adresów MAC. Aby zobaczyć komunikację między dwoma innymi serwerami, musisz skonfigurować port mirroring (SPAN). Kopiujesz ruch z portów serwerowych na port diagnostyczny, do którego podpięty jest twój komputer z uruchomionym analizatorem.

Program posiada wbudowane narzędzia statystyczne. Menu „Statistics” to kopalnia wiedzy o stanie infrastruktury. Generuje wykresy przepustowości w czasie, listy najaktywniejszych adresów IP oraz drzewa hierarchii protokołów. Wykrywanie ataków DDoS typu SYN Flood staje się banalne. Klikasz w wykres konwersacji i natychmiast widzisz jeden zewnętrzny adres IP, który inicjuje tysiące połączeń do twojego serwera bez wysyłania pakietów z danymi.

FAQ – Najczęściej zadawane pytania o analizatory sieci

Poniżej znajdziesz zestawienie konkretnych problemów zgłaszanych przez użytkowników na forach technicznych i podczas szkoleń z administracji systemami Linux oraz Windows.

• Czy Wireshark może zainfekować komputer wirusem z sieci?
  Sam program nie wykonuje złośliwego kodu zawartego w przechwyconych pakietach. Służy wyłącznie do ich odczytu. Jeśli jednak w oprogramowaniu znajduje się niezałatana luka (tzw. podatność w parserze protokołu), spreparowany pakiet może zdestabilizować aplikację. Warto regularnie aktualizować narzędzie.
• Dlaczego widzę tylko własny ruch sieciowy?
  Zależy to od konfiguracji infrastruktury. Przełączniki sieciowe (switche) izolują ruch między portami. Twój interfejs otrzymuje tylko pakiety rozgłoszeniowe (broadcast) i te adresowane bezpośrednio do ciebie. Wymagana jest konfiguracja Port Mirroringu na switchu lub użycie fizycznego urządzenia typu Network Tap.
• Jak zapisać zrzut ruchu, żeby plik nie zajmował kilku gigabajtów?
  Użyj Ring Buffer w ustawieniach przechwytywania. Program podzieli nagranie na mniejsze pliki, np. po 100 megabajtów każdy. Możesz ustawić nadpisywanie najstarszych plików, gdy brakuje miejsca na dysku. To ratuje sytuację przy debugowaniu problemów występujących losowo raz na kilka dni.
• Czy sniffer widzi hasła wpisywane na stronach internetowych?
  Jeśli strona używa szyfrowania HTTPS (a robią to obecnie prawie wszystkie serwisy), hasło jest niewidoczne. Zobaczysz tylko wymianę zaszyfrowanego ładunku TLS. Hasła przesłane czystym tekstem przez stare protokoły takie jak Telnet, FTP czy HTTP są widoczne natychmiast w oknie podglądu strumienia TCP.
• Czym różni się tryb promiscuous od trybu monitora w Wi-Fi?
  Tryb promiscuous w sieci Wi-Fi łapie pakiety tylko z sieci, do której jesteś aktualnie podłączony i z którą masz zestawioną sesję. Tryb monitora pozwala karcie bezprzewodowej chwytać absolutnie wszystkie ramki radiowe w eterze, włączając w to ruch z obcych routerów i pakiety zarządzające (Beacon frames), nawet bez znajomości hasła do sieci.
• Jak wyciągnąć plik graficzny lub dokument z przechwyconego ruchu sieciowego?
  Wykorzystaj opcję Export Objects. Jeśli przechwyciłeś nieszyfrowany ruch HTTP lub SMB, program pozwala wyodrębnić przesyłane pliki binarne bezpośrednio z ramek sieciowych i zapisać je na dysku twardym w ich oryginalnej formie.

Zainstaluj oprogramowanie na swoim komputerze, odpal interfejs sieciowy, włącz nasłuch na portach i znajdź pierwszy błąd retransmisji we własnej sieci domowej. Zobaczysz na własne oczy, ile śmieci przelatuje przez twój router w ciągu kilkunastu sekund. Czekam na informacje, co udało wam się wyciągnąć z czystego pliku pcap po pierwszej godzinie filtrowania.

Bibliografia:

1. Wireshark Foundation – https://www.wireshark.org
2. Nmap Project – https://nmap.org
3. Internet Engineering Task Force – https://www.ietf.org
4. SANS Institute – https://www.sans.org
5. Cisco Systems – https://www.cisco.com