Przejdź do głównej zawartości

Przypadek użycia: śledztwo po alercie WAF/IDS

Filtry z poprzedniego modułu (http.request.uri contains "SELECT", contains "<script>") są dobrym punktem wejścia, ale w praktyce zwykle nie zaczynasz od nich — zaczynasz od gotowego alertu z WAF-a lub IDS-a i musisz potwierdzić, co faktycznie wydarzyło się w ruchu.

Typowy workflow śledczy​

  1. Zawęź czas i hosta na podstawie znacznika czasu i adresu IP z alertu:
    ip.addr == 10.0.0.50 and frame.time >= "2026-08-11 09:00:00"
  2. Znajdź konkretne żądanie HTTP wskazane przez alert po URI lub metodzie:
    http.request.method == "POST" and http.request.uri contains "/login"
  3. Prześledź całą wymianę klienta z serwerem: kliknij pakiet prawym przyciskiem → Follow → HTTP Stream (dla starszego HTTP/1.1) lub Follow → HTTP/2 Stream — zobaczysz pełne żądanie i odpowiedź, nie tylko fragment URI.
  4. Sprawdź, czy payload jest zakodowany — ataki rzadko trafiają w URI jako czysty tekst; typowe jest URL-encoding, Base64 czy podwójne kodowanie, które omijają proste filtry contains. Warto sprawdzić też treść żądania (body), nie tylko URI.

Ograniczenie: ruch szyfrowany​

Jeśli aplikacja działa po HTTPS, a nie masz logu sekretów sesji (SSLKEYLOGFILE) ani klucza serwera, Wireshark widzi tylko zaszyfrowane bajty TLS — treść żądania jest niedostępna. W takiej sytuacji Wireshark potwierdza fakt komunikacji (adresy, porty, wolumen, czas), a szczegóły payloadu trzeba brać z logów aplikacji/WAF-a. To dobry przykład na to, że Wireshark uzupełnia WAF/IDS, a nie go zastępuje — patrz też moduł o korelacji z SIEM.

Podsumowanie​

Wireshark jest wszechstronnym narzędziem wykorzystywanym w analizie sieci zarówno pod kątem wydajności, jak i bezpieczeństwa. W kolejnym rozdziale omówimy najlepsze praktyki w zakresie konfiguracji i optymalizacji Wiresharka dla różnych scenariuszy użycia.