Analiza ruchu i anomalii w Wiresharku

• Wybierzesz właściwy interfejs i punkt obserwacji.
• Rozróżnisz capture filter od display filter.
• Odczytasz adresy MAC, EtherType i dostępne pola ramki Ethernet II.
• Porównasz broadcast ARP Request z typowym unicast ARP Reply.
• Wyjaśnisz brak FCS bez automatycznego uznawania ramki za błędną.
• Przeanalizujesz sekwencje ICMP, DHCP, DNS, TCP i widoczne metadane TLS.
• Rozpoznasz wzorce wymagające dalszej weryfikacji bez uznawania ich automatycznie za atak.
• Zabezpieczysz plik PCAP jako materiał mogący zawierać dane wrażliwe.

Wymagania wstępne

• Ethernet II i adresacja MAC
• ARP i brama domyślna
• Podstawowa adresacja IPv4

Przechwytuj wyłącznie własny ruch albo ruch objęty jednoznaczną zgodą i zakresem administracyjnym. Plik pcap może zawierać adresy, nazwy, tokeny i inne dane wrażliwe; ogranicz dostęp, czas retencji i zakres przechwytywania.

Wybierz interfejs, którym rzeczywiście płynie badany ruch. Tryb promiscuous nie ujawnia automatycznie ruchu innych portów w sieci przełączanej; do szerszej obserwacji administrator przygotowuje SPAN, port mirroring albo kontrolowany TAP.

• Zanotuj czas, interfejs, cel i zakres przechwycenia.
• Minimalizuj czas oraz ilość zapisywanych danych.
• Nie próbuj pozyskiwać cudzych haseł ani omijać szyfrowania.

Filtra wyświetlania nie można bezpośrednio wkleić jako capture filter. Gdy potrzebujesz kompletnej sekwencji do późniejszej analizy, nie zawężaj przechwycenia bardziej, niż wymaga zakres ćwiczenia.

• Lista pakietów pokazuje pojedyncze ramki i kolumny podsumowania.
• Szczegóły protokołu rozwijają warstwy i pola wybranej ramki.
• Panel bajtów zaznacza surowe dane odpowiadające wybranemu polu.
• Statistics pomaga porównać rozmowy, punkty końcowe i hierarchię protokołów.
• Brak pakietu może oznaczać zły interfejs lub punkt obserwacji, a nie brak ruchu.

To przykłady filtrów przechwytywania. Każdy wiersz jest osobnym filtrem, a adres przykładowy należy zastąpić adresem własnego lub autoryzowanego urządzenia.

Capture filter decyduje, które ramki zostaną zapisane. Nie używa nazw pól takich jak eth.addr ani operatora && znanego z filtrów wyświetlania Wireshark.

arp
ether host aa:bb:cc:dd:ee:ff
broadcast

Zastąp aa:bb:cc:dd:ee:ff rzeczywistym adresem własnego interfejsu lub urządzenia w kontrolowanym laboratorium.

EtherType 0x0800 wskazuje IPv4, a 0x0806 ARP. Opcode 1 oznacza ARP Request, a opcode 2 ARP Reply.

eth
eth.addr == aa:bb:cc:dd:ee:ff
eth.src == aa:bb:cc:dd:ee:ff
eth.dst == aa:bb:cc:dd:ee:ff
eth.type == 0x0800
eth.type == 0x0806
arp
arp.opcode == 1
arp.opcode == 2
arp && eth.dst == ff:ff:ff:ff:ff:ff

Preambuła, SFD i IPG zwykle nie są przekazywane do Wiresharka jako część przechwyconej ramki.

Karta sieciowa lub sterownik może sprawdzić i usunąć FCS przed przekazaniem danych. Brak FCS nie jest automatycznie błędem ramki. Offloading może również wpływać na to, co widzi program.

Dla celu lokalnego Target IP w Request wskazuje host końcowy. Dla celu zdalnego host wykonuje ARP dla adresu bramy, natomiast docelowy IP późniejszego pakietu nadal wskazuje zdalny host.

Brak Request przed ruchem IP może oznaczać, że prawidłowe mapowanie było już w cache. Nie wymuszaj czyszczenia cache w sieci produkcyjnej tylko po to, by uzyskać oczekiwany zrzut.

Odczytuj pola ARP razem z eth.src i eth.dst. Nagłówek Ethernet opisuje dostarczenie bieżącej ramki, a pola Sender i Target opisują treść komunikatu ARP.

Najpierw zanotuj interfejs i konfigurację hosta, potem wygeneruj kontrolowany ruch. Filtruj zapis lub widok dopiero po określeniu, którego etapu komunikacji szukasz.

Analizuj rozmowę, a nie pojedynczy pakiet. Brak wcześniejszego etapu może wynikać z punktu obserwacji, cache, rozpoczęcia przechwycenia w połowie sesji albo zastosowanego filtra.

Każdy wiersz jest osobnym filtrem. tcp.analysis.retransmission jest wynikiem analizy Wiresharka i wskazuje możliwą retransmisję, a nie niepodważalny dowód utraty w sieci.

arp
icmp
dhcp
dns
tcp
tls
tcp.flags.syn == 1 && tcp.flags.ack == 0
tcp.analysis.retransmission
dns.flags.response == 1
ip.addr == 192.0.2.10
ipv6.addr == 2001:db8::10

Anomalia oznacza odchylenie od oczekiwanego zachowania, nie automatycznie incydent. Wniosek wymaga kontekstu: czasu, właściciela, zmian, topologii, baseline, logów urządzeń i działania aplikacji.

Szyfrowanie TLS ogranicza widoczność treści aplikacyjnej. Zależnie od wersji protokołu i konfiguracji mogą pozostać widoczne adresy, porty, rozmiary, czasy, kierunki oraz część handshake. Nie próbuj obchodzić szyfrowania ani pozyskiwać cudzych kluczy.

Brak dostępu do treści nie uniemożliwia diagnostyki: nadal można analizować zestawienie TCP, opóźnienia, retransmisje, zakończenie sesji i relacje między punktami końcowymi. Nie wolno jednak zgadywać zawartości na podstawie samego portu lub rozmiaru pakietu.

• Przechwytuj minimalny zakres adresów, protokołów i czasu potrzebny do celu.
• Nadaj plikowi właściciela, klasyfikację, termin retencji i ograniczone uprawnienia.
• Przechowuj oraz przekazuj PCAP w zatwierdzonym, szyfrowanym miejscu.
• Przed udostępnieniem sprawdź, czy plik nie zawiera tokenów, nazw, danych osobowych lub sekretów.
• Nie używaj publicznych serwisów do analizy pliku bez zgody właściciela danych.
• Po zakończeniu celu usuń kopie zgodnie z procedurą i zachowaj jedynie wymagany raport.

• Zapisz interfejs, punkt obserwacji, strefę czasową, czas rozpoczęcia i zastosowany filtr.
• Najpierw zbuduj oczekiwaną sekwencję, a potem szukaj brakującego lub nietypowego etapu.
• Porównuj liczbę zdarzeń z reprezentatywnym baseline, nie z przypadkowym pojedynczym zrzutem.
• Potwierdzaj hipotezę drugim źródłem: logiem, konfiguracją, licznikiem interfejsu lub testem aplikacji.
• Oddziel obserwację, możliwe wyjaśnienia i potwierdzony wniosek w raporcie.

• Pomylenie capture filter z display filter.
• Wybór nieaktywnego interfejsu lub tunelu zamiast interfejsu używanego przez badany ruch.
• Uznanie braku FCS za dowód uszkodzenia ramki.
• Oczekiwanie ARP Request mimo aktualnego wpisu w cache.
• Mylenie docelowego MAC bramy z docelowym IP zdalnego serwera.
• Uznanie dużej liczby SYN, zapytań DNS lub retransmisji za dowód ataku bez baseline i logów.
• Wnioskowanie o treści zaszyfrowanej sesji wyłącznie z numeru portu lub nazwy protokołu.
• Udostępnienie pliku pcap bez ograniczenia danych i podstawy prawnej.

1. Na własnym interfejsie zastosuj kolejno eth, eth.type == 0x0806 i arp.opcode == 1. Zapisz, jak zmienia się liczba widocznych ramek.
2. Dla pary Request/Reply odczytaj eth.src, eth.dst, arp.opcode, Sender MAC/IP i Target MAC/IP.
3. Porównaj ramkę do hosta lokalnego i pakiet do celu zdalnego. Wyjaśnij, dlaczego Destination IP i Destination MAC mogą wskazywać różne urządzenia.
4. Sprawdź, czy przechwycenie zawiera FCS. Jeżeli nie, opisz ograniczenie punktu obserwacji zamiast zgłaszać automatycznie błąd.
5. W kontrolowanym laboratorium wygeneruj jedno zapytanie DNS, ping i połączenie HTTPS. Ułóż ich pakiety w oczekiwane sekwencje.
6. Porównaj zwykły handshake TCP z trzema próbami połączenia do zamkniętego portu własnej maszyny. Zapisz obserwację i alternatywne wyjaśnienia.
7. Dla wskazanej odpowiedzi ARP sprawdź mapowanie IP–MAC z inwentaryzacją, ale nie uznawaj zmiany automatycznie za spoofing.
8. Przygotuj zasady przechowywania własnego PCAP: właściciel, zakres, dostęp, miejsce, retencja i usunięcie.

• Ethernet i ARP analizuje się jako sekwencję pól i zdarzeń, nie tylko pojedynczy wiersz listy pakietów.
• Request jest broadcastem, a typowy Reply unicatem do pytającego.
• Dla zdalnego celu IP wskazuje serwer, lecz MAC pierwszej ramki wskazuje bramę.
• Sterownik i offloading wpływają na widoczność FCS oraz innych szczegółów przechwycenia.
• DNS, DHCP, ICMP, TCP i TLS analizuje się jako sekwencje zależne od punktu obserwacji.
• Nietypowa liczba zdarzeń jest hipotezą wymagającą baseline, kontekstu i potwierdzenia drugim źródłem.
• Szyfrowanie ogranicza widoczność treści, a PCAP wymaga ochrony jak każdy zbiór danych wrażliwych.

• Ethernet II i adresacja MAC
• ARP i ICMP
• Bezpieczeństwo sieci
• Monitoring bezpieczeństwa, IDS/IPS i SIEM
• Reagowanie na incydenty
• Rozpoznanie sieci za pomocą Nmap
• NET-02 — Ethernet, MAC, ARP i analiza ramek w Wiresharku
• CYB-02 — Analiza anomalii w Wiresharku
• CYB-05 — Korelacja logów i podstawy SIEM
• CYB-06 — Zabezpieczanie materiału: logi i PCAP

• Wireshark User’s Guide
• Wireshark Display Filter Reference — Ethernet
• Wireshark Display Filter Reference — ARP
• Wireshark Display Filter Reference
• Wireshark pcap-filter manual
• RFC 826 — Address Resolution Protocol