Wireshark w praktyce – jak analizować ruch sieciowy i wykrywać podejrzane połączenia?

Wprowadzenie: czym jest Wireshark i do czego służy analiza ruchu

Aplikacja nie odpowiada, połączenie z serwerem trwa zbyt długo, a komputer wysyła dane, choć użytkownik nie wykonuje żadnych działań. Każda z tych sytuacji pozostawia ślady w komunikacji sieciowej. Wireshark pozwala zajrzeć do tej komunikacji na poziomie pojedynczych pakietów — sprawdzić, jakie urządzenia wymieniają dane, z użyciem jakich protokołów i w jakiej kolejności. Pomaga w ten sposób zweryfikować przypuszczenia dotyczące awarii lub podejrzanej aktywności.

Wireshark to bezpłatny analizator protokołów sieciowych o otwartym kodzie źródłowym, dostępny m.in. dla systemów Windows, macOS i Linux. Umożliwia przechwytywanie ruchu widocznego na wybranym interfejsie oraz analizę wcześniej zapisanych pakietów. Rozpoznaje strukturę wielu protokołów i przedstawia ich pola w czytelnej postaci. Zamiast oglądać wyłącznie surowe bajty, analityk może odczytać adresy źródłowe i docelowe, porty, informacje sterujące połączeniem czy — jeśli transmisja nie jest zaszyfrowana — treść niektórych komunikatów.

Co daje analiza ruchu sieciowego?

W diagnostyce analiza pakietów pomaga ustalić, na którym etapie komunikacja przestaje działać zgodnie z oczekiwaniami. Pozwala na przykład odróżnić brak odpowiedzi serwera od sytuacji, w której odpowiedź dociera, ale zawiera błąd. Uzupełnia przy tym logi aplikacji i systemów: pokazuje nie tylko to, co dany program zarejestrował, lecz także wymianę danych widoczną w punkcie przechwytywania.

W bezpieczeństwie cel jest nieco inny. Analiza służy ocenie, czy obserwowana komunikacja pasuje do roli urządzenia i sposobu jego użytkowania. Może pomóc potwierdzić nieoczekiwany kontakt z zewnętrznym hostem, określić czas jego wystąpienia oraz oszacować ilość przesłanych danych. Nietypowe połączenie nie jest jednak automatycznie dowodem ataku. Aktualizacje, synchronizacja plików i usługi działające w tle również generują ruch bez bezpośredniego udziału użytkownika. Znaczenie obserwacji trzeba oceniać w kontekście środowiska.

Możliwości i ograniczenia Wiresharka

Wireshark nie jest zaporą sieciową ani systemem, który samodzielnie rozpoznaje i blokuje zagrożenia. Dostarcza szczegółowych danych do analizy, ale ich interpretacja należy do użytkownika. W odróżnieniu od monitoringu pokazującego głównie dostępność usług lub wykorzystanie łącza pozwala przyjrzeć się konkretnym wymianom pakietów i ich przebiegowi.

Nie zapewnia też automatycznie wglądu w całą sieć. Zakres analizy zależy od tego, jaki ruch jest widoczny w miejscu przechwytywania; brak pakietów w zapisie nie musi oznaczać, że komunikacja nie wystąpiła. Dodatkową granicę stanowi szyfrowanie. Przy połączeniach szyfrowanych zwykle nadal można badać adresy, czas transmisji i rozmiary pakietów, lecz odczyt treści wymaga spełnienia dodatkowych warunków.

Przechwycone dane mogą zawierać informacje poufne, dlatego analizę należy prowadzić wyłącznie w zakresie posiadanych uprawnień. Największą wartość przynosi ona wtedy, gdy odpowiada na konkretne pytanie — na przykład czy urządzenie nawiązało określone połączenie — a wnioski są zestawiane z logami i wiedzą o działaniu sieci.

Przygotowanie środowiska i przechwytywanie ruchu: interfejsy, pcap, dobre praktyki

Wiarygodna analiza zaczyna się od wyboru miejsca przechwytywania. Wireshark widzi ruch dostępny na wskazanym interfejsie, a nie automatycznie całą komunikację w sieci. W Cognity często słyszymy pytania, jak praktycznie podejść do przechwytywania ruchu – odpowiadamy na nie także na blogu. Zanim rozpoczniesz zapis, określ, którego urządzenia i jakiego przedziału czasu dotyczy problem. Dzięki temu ograniczysz ilość zbieranych danych i ryzyko, że w pliku zabraknie istotnego fragmentu komunikacji.

Instalacja i uprawnienia

Pobierz Wiresharka z oficjalnej strony projektu lub z zaufanego repozytorium systemowego. W systemie Windows do przechwytywania pakietów zwykle potrzebny jest Npcap, dostępny w instalatorze Wiresharka. W Linuksie możliwość przechwytywania zależy od konfiguracji uprawnień, najczęściej związanych z narzędziem dumpcap i odpowiednią grupą użytkowników.

Stosuj zasadę najmniejszych uprawnień: nie uruchamiaj całego interfejsu Wiresharka jako administrator lub root, jeśli wystarczy poprawnie skonfigurować dostęp do przechwytywania. Na urządzeniu służbowym uzgodnij instalację i zakres zbierania danych z administratorem. Przechwytuj wyłącznie ruch, do którego analizy masz upoważnienie.

Wybór interfejsu i punktu obserwacji

Lista interfejsów może obejmować Ethernet, Wi-Fi, połączenia VPN, interfejsy maszyn wirtualnych oraz loopback. Wybierz ten, przez który rzeczywiście przebiega interesująca Cię komunikacja. Wskaźnik aktywności pomaga znaleźć używane połączenie, ale sam wzrost ruchu nie potwierdza jeszcze, że jest to właściwy punkt obserwacji.

• Ethernet lub Wi-Fi — typowy wybór przy badaniu komunikacji komputera z siecią lokalną i internetem.
• Interfejs VPN — może pokazywać pakiety przesyłane wewnątrz tunelu, podczas gdy interfejs fizyczny pokazuje przede wszystkim zaszyfrowaną komunikację z bramą VPN. Widoczność zależy od konfiguracji klienta i tras.
• Loopback — służy do obserwowania komunikacji między procesami na tym samym urządzeniu, która nie wychodzi na fizyczną kartę sieciową.

W sieci przełączanej komputer zwykle nie otrzymuje pakietów wymienianych między innymi hostami. Sam tryb promiscuous tego nie zmienia. Do obserwacji szerszego fragmentu sieci potrzebny może być port lustrzany SPAN na przełączniku lub TAP sieciowy. Z kolei przechwytywanie ramek Wi-Fi w trybie monitor wymaga zgodnego sprzętu i sterowników; nie jest tym samym co zwykły zapis ruchu własnego połączenia bezprzewodowego.

Przechwytywanie i zapis do pcap lub pcapng

Rozpocznij przechwytywanie przed odtworzeniem problemu, wykonaj badaną czynność i zatrzymaj zapis po jej zakończeniu. Zanotuj czas wystąpienia objawu, adres badanego urządzenia oraz krótki opis wykonanej operacji. Takie informacje ułatwiają później powiązanie pakietów z konkretnym zdarzeniem.

Wireshark zapisuje ruch domyślnie w formacie pcapng, który obsługuje między innymi dane z wielu interfejsów i dodatkowe metadane, takie jak komentarze. Starszy pcap jest przydatny przy wymianie danych z narzędziami wymagającymi tego formatu. Konwersja do pcap może oznaczać utratę części metadanych, dlatego warto zachować oryginalny plik.

Jakość danych i bezpieczeństwo zapisu

Przy dłuższym przechwytywaniu ustaw podział zapisu na pliki oraz limit zajmowanego miejsca. Bufor pierścieniowy pozwala utrzymywać ograniczoną liczbę plików, ale nadpisuje najstarsze — po zauważeniu problemu trzeba więc odpowiednio szybko zabezpieczyć materiał. Sprawdzaj również informacje o pakietach odrzuconych podczas przechwytywania, jeśli są dostępne. Niepełny zapis może prowadzić do błędnych wniosków.

Zadbaj o synchronizację czasu, szczególnie jeśli porównujesz przechwycenia z kilku urządzeń. Ograniczenie zapisywanej długości pakietów zmniejsza rozmiar pliku, lecz może usunąć dane potrzebne do analizy. Pliki z ruchem traktuj jak dane poufne: mogą zawierać adresy, nazwy hostów, tokeny lub niezaszyfrowaną treść komunikacji. Przechowuj je z ograniczonym dostępem, udostępniaj tylko niezbędny zakres i pracuj na kopii, zachowując oryginał bez zmian.

Capture filters vs display filters: różnice, zastosowania i przykłady

W Wiresharku można ograniczyć ruch już podczas przechwytywania albo dopiero podczas przeglądania zebranych pakietów. Służą do tego dwa odrębne mechanizmy: capture filters, czyli filtry przechwytywania, oraz display filters — filtry wyświetlania. Różnią się momentem działania, składnią i wpływem na dostępne dane. Pomylenie ich może oznaczać nie tylko błąd w wyrażeniu, lecz także utratę pakietów potrzebnych do analizy.

Filtry przechwytywania: wybór danych na wejściu

Filtr przechwytywania określa, które pakiety zostaną przyjęte do przechwycenia. Ustawia się go przed rozpoczęciem zbierania ruchu. Wireshark korzysta tutaj ze składni filtrów biblioteki libpcap, powszechnie określanej jako składnia BPF. Można w niej wskazać między innymi adres hosta, podsieć, protokół transportowy lub port.

To dobre rozwiązanie, gdy zakres obserwacji jest znany: interesuje Cię konkretny komputer albo ruch do określonej usługi. Ograniczenie zbieranych pakietów zmniejsza ilość danych do zapisania i późniejszego przeglądania. Ma jednak istotną konsekwencję: pakietów odrzuconych przez filtr nie odzyskasz z tego przechwycenia. Zmiana filtra po zakończeniu zbierania ruchu nie uzupełni brakujących danych.

Filtry wyświetlania: selekcja bez usuwania pakietów

Filtr wyświetlania działa na pakietach już dostępnych w Wiresharku — zarówno podczas trwającego przechwytywania, jak i po otwarciu pliku. Ogranicza widok listy pakietów, ale nie usuwa pozostałych danych. Możesz wielokrotnie zmieniać warunki, a po wyczyszczeniu filtra ponownie zobaczyć pełną zawartość przechwycenia.

Ten mechanizm korzysta z własnej składni Wiresharka i pozwala odwoływać się do pól rozpoznanych przez analizatory protokołów. Jest więc bardziej szczegółowy niż filtr przechwytywania. Sprawdza się, gdy stopniowo zawężasz analizę, porównujesz różne grupy pakietów lub dopiero ustalasz, która komunikacja wymaga uwagi.

Przykłady: ten sam cel, różna składnia

Poniższe pary pokazują odpowiadające sobie warunki. Adres 192.0.2.10 jest przykładowy — należy zastąpić go adresem analizowanego urządzenia.

• Ruch do lub z wybranego hosta: filtr przechwytywania host 192.0.2.10; filtr wyświetlania ip.addr == 192.0.2.10.
• Pakiety wysyłane przez wybrany host: filtr przechwytywania src host 192.0.2.10; filtr wyświetlania ip.src == 192.0.2.10.
• Ruch TCP z portem źródłowym lub docelowym 443: filtr przechwytywania tcp port 443; filtr wyświetlania tcp.port == 443.
• Ruch TCP wybranego hosta na porcie 443: filtr przechwytywania host 192.0.2.10 and tcp port 443; filtr wyświetlania ip.addr == 192.0.2.10 and tcp.port == 443.

Warunek dotyczący portu wskazuje numer portu, a nie potwierdza protokołu aplikacyjnego. Przykładowo tcp.port == 443 nie oznacza automatycznie „cały ruch HTTPS” — obejmuje komunikację TCP na tym porcie, niezależnie od jej rzeczywistej zawartości.

Praktyczna zasada: przechwytuj w zakresie potrzebnym do diagnozy, a szczegółową selekcję wykonuj filtrami wyświetlania. Jeśli przyczyna problemu jest nieznana, zbyt wąski filtr przechwytywania może usunąć istotny kontekst. Gdy natomiast dokładnie wiesz, jakiego ruchu szukasz, oba mechanizmy można stosować razem: pierwszy ogranicza zbieranie, drugi ułatwia analizę.

Najczęstsze protokoły w praktyce: DNS, HTTP/HTTPS, TCP i handshake (SYN/SYN-ACK/ACK)

Otwarcie jednej strony internetowej może wygenerować ruch kilku protokołów: zapytanie DNS o adres serwera, zestawienie połączenia TCP, negocjację TLS i wymianę danych HTTP. Rozpoznanie ich ról pozwala ustalić, na którym etapie pojawia się problem. Brak odpowiedzi DNS, odrzucone połączenie TCP i błąd HTTP to różne sytuacje, choć dla użytkownika każda może oznaczać niedziałającą stronę. W Cognity omawiamy analizę tych etapów zarówno od strony technicznej, jak i praktycznej – zgodnie z realiami pracy uczestników.

DNS — od nazwy domeny do adresu serwera

DNS służy między innymi do ustalania adresów IP przypisanych do nazw domenowych. W Wiresharku warto zacząć od rozwinięcia szczegółów zapytania i odpowiedzi: sprawdzić nazwę, typ rekordu oraz kod odpowiedzi. Rekord A wskazuje adres IPv4, AAAA — IPv6, a CNAME odsyła do innej nazwy domenowej.

Odpowiedź NXDOMAIN oznacza, że pytana nazwa nie istnieje. Nie jest tym samym co brak odpowiedzi ani odpowiedź bez rekordów żądanego typu. To ważne rozróżnienie: pomaga oddzielić błędną nazwę od problemów z dostępnością resolvera, czyli serwera obsługującego zapytania DNS.

Klasyczny DNS korzysta z portu 53, najczęściej przez UDP, ale obsługuje również TCP, wykorzystywany między innymi wtedy, gdy odpowiedź UDP jest zbyt duża i zostaje oznaczona jako skrócona. Brak widocznych pakietów DNS nie dowodzi, że rozwiązywanie nazw nie działa: odpowiedź mogła pochodzić z pamięci podręcznej, a zapytanie mogło zostać przesłane w postaci szyfrowanej, np. przez DNS over HTTPS.

HTTP i HTTPS — żądania aplikacji oraz granice widoczności

HTTP opisuje wymianę żądań i odpowiedzi między klientem a serwerem. Przy nieszyfrowanym ruchu Wireshark może pokazać metodę, np. GET lub POST, ścieżkę zasobu, nagłówki, kod odpowiedzi oraz przesyłaną treść. Kod 404 informuje o nieznalezionym zasobie, natomiast 503 — o niedostępności usługi. Otrzymanie takiej odpowiedzi oznacza, że komunikacja dotarła do serwera HTTP; nie jest to więc ten sam problem co niemożność zestawienia połączenia.

HTTPS to HTTP chroniony przez TLS. Bez odpowiednich kluczy sesji nie zobaczysz treści żądań, pełnych adresów URL ani kodów odpowiedzi HTTP. Nadal dostępne są jednak adresy IP, porty, rozmiary pakietów i czasy ich przesyłania, a także część informacji z negocjacji TLS. Zakres widocznych danych zależy od wersji protokołu i zastosowanych mechanizmów ochrony.

HTTP często używa portu 80, a HTTPS — 443, lecz numer portu jest wskazówką, nie rozstrzygającym dowodem. Warto też pamiętać, że HTTP/3 działa przez QUIC wykorzystujący UDP, więc nie będzie mu towarzyszył klasyczny handshake TCP.

TCP — transport danych i zestawianie połączenia

TCP zapewnia uporządkowane, niezawodne dostarczanie strumienia bajtów między aplikacjami. Wykorzystuje numery sekwencyjne, potwierdzenia odbioru i retransmisje. Nie określa jednak znaczenia przesyłanych danych: poprawne dostarczenie żądania przez TCP nie gwarantuje, że aplikacja je poprawnie obsłuży.

Typowe zestawienie połączenia TCP składa się z trzech kroków, widocznych w Wiresharku jako flagi w szczegółach nagłówka TCP i zwykle także w kolumnie Info:

1. SYN — klient inicjuje połączenie i przekazuje swój początkowy numer sekwencyjny.
2. SYN, ACK — serwer potwierdza żądanie klienta i przekazuje własny początkowy numer sekwencyjny.
3. ACK — klient potwierdza odpowiedź serwera, kończąc trójstronne uzgadnianie.

Pełna sekwencja SYN → SYN/ACK → ACK potwierdza zestawienie połączenia TCP, ale jeszcze nie powodzenie negocjacji TLS czy wymiany HTTP. Powtarzające się pakiety SYN bez widocznej odpowiedzi wskazują, że w przechwyconym ruchu brakuje potwierdzenia rozpoczęcia połączenia. Przyczyną może być niedostępny host, filtrowanie ruchu albo niepełna widoczność komunikacji. Z kolei odpowiedź RST na próbę połączenia zwykle oznacza jego aktywne odrzucenie.

Interpretując te pakiety, uwzględnij moment rozpoczęcia przechwytywania: jeśli zapis obejmuje już trwającą sesję, brak handshake’u jest naturalny i sam w sobie nie świadczy o błędzie.

Śledzenie komunikacji: Follow TCP/UDP Stream, konwersacje, statystyki i rekonstrukcja zdarzeń

Pojedynczy pakiet rzadko wyjaśnia, co wydarzyło się między urządzeniami. Dopiero zestawienie obu kierunków komunikacji, jej czasu trwania i objętości pozwala ocenić przebieg wymiany. W Wiresharku służą do tego trzy uzupełniające się widoki: strumienie pokazują zawartość komunikacji, konwersacje porządkują ją według par punktów końcowych, a statystyki ujawniają jej rozkład w czasie.

Follow TCP/UDP Stream — komunikacja zamiast pojedynczych pakietów

Aby przyjrzeć się konkretnej wymianie, zaznacz należący do niej pakiet i z menu kontekstowego wybierz Follow → TCP Stream lub Follow → UDP Stream. Wireshark otworzy okno z danymi przypisanymi do danego strumienia, rozróżniając kierunki transmisji kolorami. Pozwala to łatwiej zestawić żądanie z odpowiedzią, odczytać komunikat aplikacji albo sprawdzić, jakie dane faktycznie przesłano.

W przypadku TCP narzędzie składa przechwycone dane zgodnie z numerami sekwencyjnymi, dzięki czemu granice segmentów nie przeszkadzają w czytaniu treści. Follow UDP Stream nie oznacza natomiast odtworzenia niezawodnego połączenia: UDP przenosi niezależne datagramy, bez gwarancji dostarczenia i zachowania kolejności. Ten widok ułatwia przegląd wymiany między punktami końcowymi, ale jej interpretacja zależy od protokołu aplikacyjnego.

Format prezentacji warto dopasować do danych: tekst jest wygodny dla czytelnych komunikatów, a zapis szesnastkowy — dla zawartości binarnej. Pamiętaj jednak, że Follow Stream nie odszyfrowuje automatycznie ruchu TLS. Bez odpowiednich sekretów sesji i konfiguracji zobaczysz zaszyfrowane dane, a nie treść aplikacyjną. Narzędzie nie odzyska też bajtów, których nie ma w przechwyceniu.

Conversations i Endpoints — kto z kim rozmawiał?

Widok Statistics → Conversations zestawia komunikację pomiędzy parami punktów końcowych. W zakładkach TCP i UDP uwzględnia adresy IP oraz porty, a w kolumnach pokazuje m.in. liczbę pakietów, liczbę bajtów w obu kierunkach, początek i czas trwania wymiany. Sortowanie według objętości pomaga znaleźć największe transfery, a według czasu rozpoczęcia — uporządkować aktywność chronologicznie.

Dla porównania Statistics → Endpoints grupuje dane według pojedynczych punktów końcowych, nie ich par. To dobry widok do ustalenia, które urządzenie odpowiada za znaczną część zarejestrowanego ruchu. Conversations pozwala następnie sprawdzić, z jakimi partnerami prowadziło wymianę. Przy korzystaniu z opcji ograniczenia wyników do aktywnego filtra wyświetlania zwróć uwagę na zakres analizy: zestawienie może opisywać tylko wycinek przechwycenia.

Statystyki — objętość i rytm transmisji

Statistics → I/O Graphs pokazuje zmiany natężenia ruchu w czasie. Wykres liczby pakietów odpowiada na inne pytanie niż wykres liczby bajtów: wiele krótkich komunikatów może generować dużą liczbę pakietów przy niewielkim transferze. Osobne serie z filtrami dla wybranych strumieni pozwalają porównać ich aktywność i sprawdzić, która konwersacja odpowiada za widoczny wzrost ruchu.

Znaczenie ma także przedział agregacji. Duże przedziały wygładzają krótkie serie transmisji, a mniejsze pomagają dostrzec przerwy i nagłe zmiany. Uzupełnieniem jest Statistics → Protocol Hierarchy, czyli zestawienie udziału rozpoznanych protokołów — przydatne do określenia charakteru analizowanego wycinka.

Rekonstrukcja zdarzeń — od danych do osi czasu

Rekonstrukcja polega na połączeniu informacji z tych widoków: kiedy rozpoczęła się wymiana, który punkt końcowy wysłał pierwsze zarejestrowane dane, kiedy pojawiła się odpowiedź i co nastąpiło później. Pomaga w tym spójny format znaczników czasu oraz wskazywanie numerów pakietów przy zapisywaniu ustaleń. Jeśli potrzebujesz czytelnego obrazu kolejności i kierunków komunikacji, wykorzystaj Statistics → Flow Graph.

Oddzielaj obserwacje od wniosków. Brak odpowiedzi w pliku nie dowodzi, że serwer jej nie wysłał, a pierwszy widoczny pakiet nie musi oznaczać początku połączenia. Przechwycenie mogło rozpocząć się za późno, obejmować tylko jeden kierunek albo zawierać luki. Wiarygodna oś czasu powinna zatem wskazywać zarówno potwierdzone zdarzenia, jak i ograniczenia materiału, na którym oparto analizę.

Wykrywanie anomalii i symptomów incydentów: nietypowe DNS, podejrzane połączenia wychodzące, skany i skokowy ruch

W Wiresharku podejrzany ruch rozpoznaje się przede wszystkim po odstępstwach od normalnego zachowania urządzenia, a nie po pojedynczym pakiecie. Komputer pracownika, serwer kopii zapasowych i kamera IP mają różne wzorce komunikacji. Nowy adres docelowy, seria błędów DNS czy gwałtowny wzrost transferu to powody do sprawdzenia kontekstu — nie samodzielne dowody włamania.

Znaczenie ma również zakres przechwyconego ruchu. Jeśli zapis obejmuje tylko jeden kierunek komunikacji albo fragment zdarzenia, brak odpowiedzi nie musi oznaczać, że połączenie rzeczywiście się nie powiodło.

Nietypowe zapytania DNS

Uwagę powinny zwrócić liczne zapytania o nieistniejące domeny, bardzo długie lub zmieniające się subdomeny oraz nagły wzrost liczby zapytań z jednego hosta. Takie zachowanie może towarzyszyć generowaniu nazw domen przez złośliwe oprogramowanie albo tunelowaniu danych przez DNS. Podobne objawy bywają jednak skutkiem błędnej konfiguracji aplikacji, mechanizmów telemetrycznych lub działania usług ochronnych.

Odpowiedzi informujące o nieistniejącej nazwie domenowej można wyświetlić filtrem dns.flags.rcode == 3. Ważniejsza od pojedynczego wyniku jest seria: ile takich odpowiedzi otrzymuje dany host, jakich nazw dotyczą i czy zjawisko pojawiło się nagle. Z kolei duża liczba zapytań o rekordy TXT nabiera znaczenia dopiero w połączeniu z innymi cechami, np. nietypową długością nazw i regularnością komunikacji.

Brak widocznych zapytań DNS nie oznacza braku rozwiązywania nazw. Przy DNS over HTTPS lub DNS over TLS ich treść jest zaszyfrowana i zwykły podgląd pakietów nie pozwala ocenić odpytywanych domen.

Podejrzane połączenia wychodzące

Sprawdzenia wymagają zwłaszcza połączenia do odbiorców nietypowych dla roli urządzenia, komunikacja poza zwykłymi godzinami jego pracy oraz powtarzające się, krótkie wymiany danych w zbliżonych odstępach. Taka regularność może wskazywać na beaconing, czyli okresowe kontaktowanie się z infrastrukturą sterującą. Nie przesądza jednak o infekcji: podobnie działają agenty monitoringu, komunikatory i usługi synchronizacji.

Oceniaj łącznie adresy docelowe, częstotliwość połączeń, czas ich trwania oraz ilość danych przesyłanych w obu kierunkach. Duży transfer wychodzący z urządzenia, które zwykle głównie pobiera dane, może sugerować eksfiltrację, ale także legalne wysyłanie kopii zapasowej. Numer portu nie potwierdza charakteru ruchu — port 443 nie gwarantuje bezpiecznej komunikacji, a nietypowy port nie dowodzi nadużycia. Przy szyfrowaniu widoczne pozostają przede wszystkim metadane, nie treść transmisji.

Skany portów i rozpoznanie sieci

Typowym sygnałem skanowania jest duża liczba prób połączeń z jednego źródła do wielu portów tego samego hosta albo do tego samego portu na wielu hostach. W ruchu TCP pomocny jest filtr tcp.flags.syn == 1 && tcp.flags.ack == 0, który pokazuje pakiety inicjujące połączenia. Sam wzrost ich liczby nie wystarcza do rozpoznania skanu — trzeba uwzględnić rozrzut celów, tempo prób oraz widoczne odpowiedzi.

Liczne odmowy połączenia lub próby bez dalszej wymiany danych wzmacniają podejrzenie rozpoznania sieci. Taki obraz mogą jednak tworzyć również autoryzowane skanery podatności, systemy inwentaryzacji i błędnie skonfigurowane usługi.

Skokowy ruch i nagłe zmiany obciążenia

Gwałtowny wzrost ruchu warto rozpatrywać osobno jako wzrost liczby pakietów oraz wzrost ilości przesyłanych danych. Wiele małych pakietów może towarzyszyć skanowaniu, zalewaniu usługi lub pętli sieciowej. Duży wolumen danych może wynikać z aktualizacji, backupu, pobierania plików albo nieuprawnionego transferu.

Najbardziej niepokojące są zbieżne symptomy: host zaczyna odpytywać nietypowe domeny, następnie nawiązuje regularne połączenia do nowych adresów, a później wysyła znacznie więcej danych niż zwykle. Wireshark pozwala udokumentować taki wzorzec, lecz przypisanie go do konkretnego procesu i potwierdzenie incydentu zwykle wymaga także logów systemowych, zapory lub narzędzi ochrony stacji końcowych.

Przykładowy workflow analizy incydentu w małej sieci — krok po kroku

Załóżmy, że router zgłasza nietypowo duży ruch wychodzący z jednego komputera, a użytkownik zauważa spowolnienie połączenia. Celem analizy nie jest samo znalezienie podejrzanych pakietów, lecz ustalenie, które urządzenie generuje ruch, co go wywołuje i czy wymaga to reakcji bezpieczeństwa. Poniższy workflow pomaga przejść od zgłoszenia do udokumentowanej decyzji.

1. Zapisz punkt wyjścia i oceń pilność reakcji

Zanotuj czas zgłoszenia wraz ze strefą czasową, adres IP urządzenia, źródło alertu oraz zaobserwowane objawy. Zapytaj użytkownika, co robił w tym czasie: wysyłał duży plik, uruchamiał kopię zapasową czy otworzył nietypowy załącznik. To wskazówki do weryfikacji, nie gotowe wyjaśnienie.

Jeśli są oznaki trwającego wycieku danych, szyfrowania plików lub atakowania innych urządzeń, nie odkładaj izolacji komputera tylko po to, aby zebrać więcej ruchu. Ograniczenie szkód ma pierwszeństwo; analizę można kontynuować na zachowanych zapisach i logach.

2. Potwierdź urządzenie i zakres widoczności

Sprawdź w dzierżawach DHCP, które urządzenie korzystało ze wskazanego adresu IP w chwili zdarzenia. Sam aktualny przydział adresu może być mylący. Ustal też, skąd pochodzi zapis ruchu. Przechwytywanie na przypadkowym komputerze w sieci przełączanej zwykle nie pokaże komunikacji pozostałych stacji, a zapis po zewnętrznej stronie routera z NAT może utrudnić identyfikację konkretnego hosta.

Wybierz źródło danych pozwalające obserwować podejrzane urządzenie, w granicach posiadanych uprawnień. Zapisz miejsce i przedział czasowy przechwytywania — bez tego łatwo uznać brak widocznego ruchu za brak zdarzenia.

3. Zabezpiecz materiał i zawęź analizę

Zachowaj oryginalny plik przechwycenia, a pracuj na jego kopii. Ogranicz dostęp do materiału, ponieważ może zawierać dane użytkowników, treści komunikacji lub informacje uwierzytelniające. Przy formalnym dokumentowaniu incydentu zapisz również sumę kontrolną pliku.

W Wiresharku skup widok na badanym urządzeniu i czasie wokół alertu. Uwzględnij krótki okres przed zdarzeniem i po nim: początek komunikacji może wyjaśnić więcej niż sam moment największego transferu. Na tym etapie chodzi o wyodrębnienie materiału do analizy, nie o odrzucanie wszystkiego, co wygląda zwyczajnie.

4. Wybierz połączenia wymagające wyjaśnienia

Sprawdź, z którymi adresami urządzenie wymieniało najwięcej danych, w jakim kierunku płynął transfer i kiedy rozpoczęły się połączenia. Wybierz kilka rozmów najlepiej odpowiadających czasowi oraz charakterowi alertu. Porównaj je z rolą komputera i używanymi usługami — intensywny transfer może być uzasadniony synchronizacją, ale nie powinien być uznany za bezpieczny wyłącznie na podstawie numeru portu.

Dla każdego istotnego połączenia zapisz adres docelowy, port, czas oraz zaobserwowane zachowanie. Oddzielaj obserwację od hipotezy: „komputer wysłał dużą ilość danych do zewnętrznego adresu” nie oznacza jeszcze „doszło do wycieku”.

5. Powiąż ruch z aktywnością na komputerze

Porównaj ustalenia z logami zapory, systemu, ochrony stacji końcowej i aplikacji. Szukaj procesu odpowiedzialnego za połączenie oraz zdarzeń poprzedzających transfer. Wireshark sam nie przypisze pakietów do procesu, a zaszyfrowana sesja zwykle nie pozwoli ustalić treści przesłanych danych bez dodatkowych materiałów.

Sprawdź, czy czas uruchomienia zadania kopii zapasowej lub synchronizacji odpowiada badanemu transferowi. Jeżeli takiego potwierdzenia brakuje, pozostaw hipotezę otwartą zamiast zastępować brak danych pewnym wnioskiem.

6. Podejmij działanie proporcjonalne do ustaleń

Potwierdzona legalna aktywność może wymagać jedynie korekty harmonogramu albo reguły alertowania. Wiarygodne oznaki naruszenia uzasadniają izolację urządzenia i dalsze działania na stacji końcowej. Ewentualną blokadę adresu docelowego stosuj ostrożnie: jeden adres może obsługiwać wiele legalnych usług, a jego zablokowanie nie usuwa przyczyny infekcji.

7. Zweryfikuj efekt i zamknij dokumentację

Po reakcji sprawdź, czy niepożądana komunikacja ustała i czy nie pojawia się z innych urządzeń. Obserwacja powinna obejmować okres odpowiedni do wcześniejszej częstotliwości połączeń — kilka minut ciszy nie wyklucza aktywności powracającej raz na godzinę.

Zapisz krótką oś czasu, wykorzystane źródła danych, potwierdzone fakty, wykonane działania i nierozstrzygnięte pytania. Zakończenie analizy powinno oznaczać uzasadnioną decyzję, a nie tylko zniknięcie alertu. Jeśli materiał nie pozwala potwierdzić ani wykluczyć incydentu, wskaż konkretnie, jakich danych brakuje i kto powinien je zebrać.

Prywatność i legalność przechwytywania: zakres, minimalizacja danych, zgody i bezpieczne przechowywanie

Plik z przechwyconym ruchem może zawierać znacznie więcej niż informacje potrzebne do rozwiązania problemu sieciowego: adresy IP, identyfikatory urządzeń, nazwy odwiedzanych domen, a przy nieszyfrowanej transmisji także treść wiadomości, hasła czy tokeny sesji. Taki zapis należy traktować jako potencjalnie wrażliwy materiał, a nie zwykły załącznik techniczny. Szyfrowanie połączeń ogranicza widoczność treści, ale nie usuwa ryzyka dla prywatności — metadane również mogą ujawniać aktywność użytkowników.

Uprawnienie techniczne to nie podstawa prawna

Możliwość uruchomienia Wiresharka na danym interfejsie nie oznacza automatycznie prawa do rejestrowania całego dostępnego ruchu. Przed rozpoczęciem analizy trzeba ustalić, kto upoważnia do działania, jakich urządzeń i użytkowników dotyczy przechwytywanie oraz jaki jest jego cel. Samo administrowanie siecią lub posiadanie routera nie daje nieograniczonego prawa do kontrolowania cudzej komunikacji.

Jeśli zapis obejmuje dane osobowe, należy uwzględnić RODO, w tym odpowiednią podstawę przetwarzania, ograniczenie celu i obowiązki informacyjne. Znaczenie mogą mieć również przepisy dotyczące tajemnicy komunikowania się oraz monitoringu pracowników. Zgoda użytkownika nie jest zawsze wymagana ani zawsze właściwa — szczególnie w relacji pracodawca–pracownik jej dobrowolność bywa problematyczna. Z kolei wewnętrzna zgoda przełożonego na diagnostykę nie zastępuje podstawy prawnej przetwarzania danych. Przy monitorowaniu cudzej komunikacji zakres działania warto uzgodnić z osobą odpowiedzialną za ochronę danych lub obsługę prawną.

Rejestruj tylko to, co potrzebne

Zakres przechwytywania powinien wynikać z konkretnego pytania diagnostycznego lub celu dochodzenia. Weryfikacja problemu jednego urządzenia zwykle nie uzasadnia wielogodzinnego zapisywania komunikacji wszystkich użytkowników. Minimalizacja oznacza ograniczenie liczby objętych analizą urządzeń, czasu rejestracji oraz ilości zbieranych informacji. Jeżeli do oceny sytuacji wystarczą metadane, nie należy bez potrzeby utrwalać treści transmisji. W Cognity łączymy teorię z praktyką — dlatego zasady ograniczania zakresu przechwytywania rozwijamy także w formie ćwiczeń na szkoleniach.

Warto odróżnić minimalizację od anonimizacji. Pierwsza ogranicza dane już na etapie ich zbierania, druga ma uniemożliwić identyfikację osób w przygotowanym materiale. Sama zamiana adresów IP nie gwarantuje anonimowości: użytkownika mogą nadal wskazywać nazwy hostów, adresy URL lub zawartość pakietów. Przed przekazaniem zapisu poza uprawniony zespół trzeba sprawdzić cały udostępniany zakres, nie tylko najbardziej oczywiste identyfikatory.

Chroń zapis także po zakończeniu analizy

Pliki z ruchem należy przechowywać w kontrolowanym miejscu, z dostępem ograniczonym do osób, które rzeczywiście ich potrzebują. Podstawą są szyfrowanie podczas przechowywania i przesyłania, rozliczalność dostępu oraz ustalony termin usunięcia. Nie należy umieszczać surowych zapisów w publicznych zgłoszeniach, ogólnodostępnych folderach ani zewnętrznych analizatorach bez sprawdzenia zasad przekazywania danych.

Okres przechowywania powinien odpowiadać celowi analizy i ewentualnym obowiązkom dowodowym, a nie zasadzie „może kiedyś się przyda”. Jeśli zapis dokumentuje incydent, należy zabezpieczyć oryginał przed zmianami i udokumentować jego pochodzenie, natomiast analizę prowadzić na kopii roboczej. Po ustaniu uzasadnionej potrzeby dane trzeba usunąć zgodnie z przyjętymi zasadami, uwzględniając również kopie robocze i cykl retencji kopii zapasowych.

Typografia w Canva – jak dobierać czcionki i tworzyć czytelne materiały? 04 listopada 2026

Jak zwiększyć wydajność produkcji dzięki DOE i metodologii Six Sigma? 02 listopada 2026