Wireshark w pracy administratora: analiza DNS, TCP i TLS krok po kroku

Wireshark ma największą wartość wtedy, gdy administrator nie tylko „patrzy na pakiety”, lecz odpowiada na konkretne pytanie diagnostyczne. W tym przewodniku wykonasz kontrolowane przechwycenie i sprawdzisz trzy kolejne warstwy połączenia: odpowiedź DNS, zestawienie TCP oraz początek negocjacji TLS. Celem nie jest zgadywanie przyczyny na podstawie jednego kolorowego wiersza. Celem jest zebranie obserwacji, powiązanie ich z etapem komunikacji i wskazanie następnego bezpiecznego testu.

Bezpieczne przygotowanie przechwytywania

Pracuj wyłącznie w sieci i na urządzeniach, którymi wolno Ci administrować. Przechwycenie może zawierać dane osobowe i tokeny, nazwy hostów, adresy IP, identyfikatory sesji oraz fragmenty nieszyfrowanych protokołów. Ustal krótki przedział testu, zamknij zbędne aplikacje i nie udostępniaj pliku przechwycenia bez sprawdzenia zawartości. Wireshark wymaga uprawnień do odczytu interfejsu, ale codzienna praca całej aplikacji na koncie uprzywilejowanym nie powinna być domyślną praktyką.

Na ekranie startowym wybierz aktywny interfejs sieciowy. Pomaga wykres ruchu obok nazwy interfejsu: wykonaj kontrolowane zapytanie do strony lub serwera DNS i sprawdź, przy którym interfejsie pojawia się aktywność. Następnie rozpocznij przechwytywanie, wykonaj tylko zaplanowane czynności i zatrzymaj przechwytywanie po kilkudziesięciu sekundach. Krótkie przechwycenie jest łatwiejsze do interpretacji i ogranicza zbieranie danych niezwiązanych z incydentem.

Do ćwiczenia użyj hosta testowego oznaczonego adresem dokumentacyjnym 192.0.2.10 albo zastąp go rzeczywistym adresem systemu, który kontrolujesz. Adres 192.0.2.10 jest tu przykładem i nie musi generować odpowiedzi. Po teście zapisz plik pcapng w katalogu roboczym z ograniczonym dostępem. Przed przekazaniem materiału innej osobie usuń lub zanonimizuj dane wrażliwe. Zachowaj oryginał tylko wtedy, gdy wymaga tego obsługa incydentu i obowiązuje właściwa retencja.

Scenariusz diagnostyczny: DNS, TCP i TLS

Realizujemy scenariusz „Diagnoza DNS, retransmisji TCP i początku sesji TLS”. Użytkownik zgłasza, że witryna czasami nie otwiera się, chociaż inne serwisy działają. Najpierw trzeba ustalić, czy nazwa otrzymuje odpowiedź DNS. Następnie sprawdzamy, czy klient zestawia połączenie TCP. Na końcu obserwujemy, czy sesja TLS przechodzi od Client Hello do Server Hello. Każdy etap może zakończyć się inną obserwacją i wymaga innego testu.

1. Wybierz aktywny interfejs sieciowy i upewnij się, że wykres pokazuje ruch generowany przez host testowy.
2. Rozpocznij przechwytywanie, a następnie zanotuj dokładny czas rozpoczęcia próby.
3. Wygeneruj kontrolowane zapytanie DNS dla badanej nazwy i wykonaj jedną próbę połączenia HTTPS.
4. Zatrzymaj przechwytywanie natychmiast po zakończeniu próby, aby nie mieszać jej z ruchem tła.
5. Zapisz plik pcapng pod nazwą zawierającą datę, system testowy i numer próby, bez danych osobowych w nazwie.
6. Usuń lub zanonimizuj dane wrażliwe przed udostępnieniem pliku; jeżeli anonimizacja zniszczyłaby dowód, ogranicz dostęp zamiast modyfikować oryginał.

Ta kolejność ma znaczenie. Jeśli nie ma poprawnej odpowiedzi DNS, nie należy jeszcze obwiniać TLS. Jeśli TCP nie uzyskuje SYN ACK, brak Server Hello jest naturalnym skutkiem, a nie osobnym dowodem awarii certyfikatu. Analiza ma prowadzić od warstwy niższej do wyższej i zatrzymywać się przy pierwszej potwierdzonej granicy błędu.

Filtry krok po kroku

Filtry wyświetlania nie zmieniają zawartości pliku; zawężają jedynie widok. Zacznij szeroko, a potem łącz warunki. Wpisz filtr w pasku Display Filter i zatwierdź klawiszem Enter. Zielone tło paska oznacza poprawną składnię, czerwone — błąd, który trzeba poprawić przed interpretacją wyników.

• dns — pokazuje zapytania i odpowiedzi DNS. Sprawdź, czy identyfikator transakcji łączy zapytanie z odpowiedzią oraz ile czasu upłynęło między nimi.
• dns.flags.rcode != 0 — zawęża widok do odpowiedzi z kodem błędu, na przykład NXDOMAIN lub SERVFAIL. Filtr nie mówi sam, dlaczego serwer zwrócił błąd; wskazuje etap wymagający dalszego sprawdzenia.
• ip.addr == 192.0.2.10 — pokazuje ruch do lub z jednego hosta. Zastąp adres adresem kontrolowanego systemu, aby odseparować badaną próbę od ruchu tła.
• tcp.flags.syn == 1 && tcp.flags.ack == 0 — pokazuje początkowe pakiety SYN wysłane przez klienta. Porównaj je z odpowiedziami SYN ACK w tym samym strumieniu.
• tcp.analysis.retransmission — pokazuje pakiety oznaczone przez analizator jako retransmisje. Pojedyncza retransmisja nie dowodzi przeciążenia; liczy się częstotliwość, kierunek i korelacja z opóźnieniem.
• tls.handshake.type == 1 — pokazuje komunikaty Client Hello. Po wybraniu pakietu sprawdź nazwę serwera SNI, obsługiwane wersje i dalszy przebieg tego samego strumienia.

Dla każdej obserwacji użyj Follow TCP Stream albo pola tcp.stream, aby nie łączyć pakietów z różnych sesji. Następnie wróć do pełnego widoku i sprawdź pakiety bezpośrednio przed oraz po zdarzeniu. Sam filtr jest narzędziem selekcji, nie werdyktem o przyczynie.

Jak interpretować wyniki

Najbezpieczniej zapisywać interpretację jako parę: „co widzę” oraz „co to może znaczyć i jaki test wykonać dalej”. Poniższa tabela nie zastępuje kontekstu topologii, logów serwera ani pomiaru z drugiego punktu sieci.

Aby zweryfikować wniosek, porównaj czas odpowiedzi DNS między próbą udaną i nieudaną. Następnie sprawdź numer strumienia TCP i upewnij się, że wszystkie oceniane pakiety należą do jednej sesji. W warstwie TLS potwierdź, czy po Client Hello pojawia się Server Hello. Jeżeli Server Hello jest obecny, problem leży później niż początek negocjacji; jeżeli go brak, trzeba rozróżnić alert, reset i brak odpowiedzi.

W panelu Packet Details rozwijaj kolejno Ethernet, IP, TCP, DNS lub TLS. Zwracaj uwagę na kierunek komunikacji, czasy względne, numery sekwencyjne i flagi. Kolory ułatwiają nawigację, ale reguła kolorowania nie jest diagnozą. Wniosek powinien wynikać z pól protokołu i sekwencji zdarzeń.

Typowe problemy i ochrona danych

• Brak pakietów po rozpoczęciu przechwytywania: wybierz interfejs, przez który faktycznie biegnie ruch. Sprawdź także uprawnienia przechwytywania i to, czy ruch nie korzysta z tunelu VPN lub interfejsu wirtualnego.
• Zbyt dużo pakietów do analizy: zawęź widok filtrem adresu IP i protokołu. Nie usuwaj oryginału przed zapisaniem kontrolowanej kopii, ponieważ później może być potrzebny szerszy kontekst.
• Nie widać treści szyfrowanej sesji: analizuj metadane i przebieg handshake zamiast zgadywać treść. Deszyfrowanie wymaga legalnego dostępu do sekretów sesji i świadomej procedury ochrony tych danych.

Nie publikuj plików pcapng jako zwykłych załączników do zgłoszenia. Najpierw sprawdź, czy zawierają ciasteczka, tokeny, zapytania DNS, adresy wewnętrzne lub treść nieszyfrowanych protokołów. Jeśli wystarczy opis sekwencji, przekaż tabelę obserwacji zamiast całego przechwycenia. Jeżeli plik jest konieczny, zastosuj ograniczenie dostępu, szyfrowanie transportu i termin usunięcia.

Wnioski i ograniczenia

Wireshark nie wskazuje automatycznie przyczyny każdego problemu. Pokazuje pakiety i wyniki analizatorów, które administrator musi powiązać z topologią, konfiguracją oraz logami systemów końcowych. Szyfrowanie ogranicza widoczność treści aplikacyjnej, lecz nadal można analizować kierunek, czas, zestawienie TCP, wersje protokołu i przebieg handshake. Przechwycenie może zawierać dane osobowe i tokeny, dlatego jego zabezpieczenie jest częścią procedury technicznej, a nie dodatkiem.

Dobra analiza kończy się wskazaniem pierwszej potwierdzonej granicy błędu i następnego testu, nie efektownym zrzutem ekranu. Dla DNS sprawdzasz odpowiedź i czas. Dla TCP sprawdzasz SYN, SYN ACK, retransmisje oraz konkretny strumień. Dla TLS sprawdzasz przejście od Client Hello do Server Hello i ewentualny alert. Dopiero po zestawieniu tych dowodów można odpowiedzialnie skierować dalszą diagnostykę do resolvera, sieci, firewalla, usługi lub konfiguracji TLS.