Pomiary logiczne koncentrują się na warstwach od 2 do 7 modelu OSI, czyli na tym, co dzieje się z danymi po ich fizycznym przetworzeniu przez medium transmisyjne. Obejmują one analizę protokołów sieciowych, badanie struktury pakietów, pomiar parametrów transmisji oraz wykrywanie anomalii w ruchu sieciowym. W przeciwieństwie do pomiarów fizycznych, które wymagają specjalistycznego sprzętu laboratoryjnego, pomiary logiczne realizuje się za pomocą oprogramowania działającego na standardowych komputerach.

Współczesne sieci komputerowe generują ogromne ilości danych, a umiejętność ich analizy jest kluczowa dla zapewnienia ciągłości działania usług IT. Prezentacja ta stanowi wprowadzenie do zestawu narzędzi i technik, które pozwalają administratorom sieci na diagnozowanie problemów, optymalizację wydajności i zwiększanie bezpieczeństwa infrastruktury sieciowej.

Plan pierwszej części prezentacji obejmuje zarówno zagadnienia teoretyczne, jak i praktyczne przykłady wykorzystania narzędzi pomiarowych. Rozpoczniemy od definicji i klasyfikacji pomiarów logicznych, przez omówienie trybów pracy kart sieciowych, aż po szczegółową analizę składni filtrów BPF. Każde zagadnienie zostało dobrane tak, aby stanowiło fundament wiedzy niezbędnej do samodzielnej pracy z narzędziami typu Wireshark i tcpdump.

Szczególny nacisk położono na praktyczne aspekty filtrowania ruchu sieciowego oraz zrozumienie architektury przechwytywania pakietów. Po przyswojeniu tego materiału student będzie potrafił samodzielnie skonfigurować środowisko pomiarowe, przechwycić ruch sieciowy i zastosować odpowiednie filtry do wyizolowania interesujących go danych.

Pomiary logiczne różnią się od fizycznych przede wszystkim zakresem i narzędziami. Podczas gdy pomiary fizyczne badają parametry elektryczne i optyczne medium (tłumienie, moc sygnału, impedancję), pomiary logiczne analizują zawartość pakietów, zachowanie protokołów i charakterystykę transmisji danych. To właśnie na podstawie pomiarów logicznych administrator może stwierdzić, że protokół TCP wykonuje retransmisje, co jest często pierwszym objawem problemów na niższych warstwach.

Analiza pakietów na poziomie logicznym pozwala na identyfikację nie tylko problemów wydajnościowych, ale także zagrożeń bezpieczeństwa, takich jak skanowanie portów, ataki ARP spoofing czy próby włamań. Wykrywanie anomalii w ruchu sieciowym jest dziś podstawą działania systemów IDS/IPS i nowoczesnych firewalli.

Porównanie pomiarów logicznych i fizycznych pokazuje, że oba podejścia są komplementarne i dopiero ich łączne stosowanie daje pełny obraz stanu sieci. Na przykład wysoki poziom błędów CRC w ramkach Ethernet (logiczny) może wskazywać na uszkodzony kabel lub wadliwą kartę sieciową (fizyczny). Z kolei poprawne parametry fizyczne nie gwarantują jeszcze poprawnej komunikacji, jeśli występują problemy z konfiguracją protokołów.

Tabela na slajdzie zestawia kluczowe różnice w przystępny sposób. W praktyce inżynierskiej najczęściej zaczyna się od pomiarów logicznych (szybki wgląd w problem), a w razie potrzeby pogłębia diagnostykę o pomiary fizyczne. W tym cyklu skupimy się na pomiarach logicznych, które są łatwiej dostępne i wymagają jedynie oprogramowania.

Przechwytywanie ruchu sieciowego wymaga odpowiedniego przygotowania środowiska. Karta sieciowa w trybie normalnym odrzuca ramki, których docelowy adres MAC nie jest zgodny z jej własnym ani nie jest adresem broadcast. Jest to podstawowy mechanizm oszczędzania zasobów systemu, ale uniemożliwia przechwytywanie ruchu innych urządzeń. Włączenie trybu promiscuous zmienia to zachowanie, nakazując karcie przekazywanie wszystkich odebranych ramek do systemu operacyjnego.

Dodatkowo rola biblioteki przechwytującej (libpcap, Npcap) jest kluczowa - to ona udostępnia aplikacjom standaryzowane API do odczytu pakietów z jądra systemu. Bez niej każde narzędzie musiałoby implementować własne mechanizmy dostępu do surowych ramek, co prowadziłoby do fragmentacji i braku zgodności.

Tryb promiscuous jest niezbędny, ale w większości współczesnych sieci przełączanych (switched) nie wystarczy, ponieważ przełącznik przekazuje do portu tylko ramki przeznaczone dla danego urządzenia. Aby przechwycić cały ruch w segmencie, konieczne jest skonfigurowanie zwierciadłowania portów (SPAN) na przełączniku, co kopiuje ruch z wybranych portów na port monitorujący.

W systemie Linux włączenie trybu promiscuous za pomocą polecenia "ip link set eth0 promisc on" można zweryfikować flagą PROMISC w wyjściu "ip link show". Na stałe tryb można ustawić w pliku konfiguracyjnym interfejsu /etc/network/interfaces (w dystrybucjach Debian/Ubuntu) lub w plikach w katalogu /etc/sysconfig/network-scripts/ (w dystrybucjach RHEL/Fedora), albo za pomocą narzędzia NetworkManager. Należy pamiętać, że tryb promiscuous może być wykryty przez skanowanie sieci.

Tryb monitor w sieciach bezprzewodowych WLAN jest odpowiednikiem trybu promiscuous w sieciach Ethernet, ale działa na zupełnie innych zasadach. Karta WLAN w trybie monitor nie wymaga asocjacji z punktem dostępowym (AP) i przechwytuje wszystkie ramki 802.11 w zasięgu, niezależnie od tego, do której sieci należą. Jest to szczególnie przydatne w auditach bezpieczeństwa i analizie pokrycia sygnałem.

Ramki przechwycone w trybie monitor zawierają dodatkowe informacje warstwy fizycznej, takie jak siła sygnału (RSSI), szum (noise), szybkość transmisji (MCS index dla 802.11n/ac/ax) oraz flagi. Wireshark dekoduje te informacje w polu "Radiotap" lub "Prism" na początku ramki, co umożliwia analizę jakości połączenia bezprzewodowego.

Tabela porównawcza trybów promiscuous i monitor uwidacznia fundamentalne różnice wynikające z charakterystyki medium transmisyjnego. W sieci Ethernet (kabel) każdy pakiet jest wysyłany do konkretnego portu, a tylko tryb promiscuous pozwala widzieć ruch innych. W Wi-Fi medium jest współdzielone, a każda karta w zasięgu może odebrać ramkę, jeśli pracuje w trybie monitor.

Wybór odpowiedniego trybu zależy od rodzaju analizowanej sieci. Do diagnostyki sieci przewodowej w firmie stosuje się promiscuous z SPAN, natomiast do analizy bezpieczeństwa WLAN w miejscach publicznych (za zgodą administratora) używa się trybu monitor. Oba tryby wymagają uprawnień administracyjnych (root/admin) do aktywacji.

Architektura przechwytywania pakietów w systemie Linux jest wielowarstwowa i dobrze ilustruje drogę, jaką przebywa pakiet od anteny lub gniazda RJ45 do ekranu administratora. Na poziomie jądra ramka jest odbierana przez sterownik karty sieciowej (np. e1000e, iwlwifi), który umieszcza ją w buforze pierścieniowym (ring buffer). Następnie jądro, w zależności od konfiguracji, może przekazać ramkę do stosu TCP/IP lub do gniazda PF_PACKET.

Biblioteka libpcap (lub Npcap na Windows) korzysta z gniazda PF_PACKET, aby odczytywać surowe ramki z jądra bez ingerowania w stos TCP/IP. Mechanizm ten pozwala na przechwytywanie nawet uszkodzonych ramek (z błędami CRC), które normalnie zostałyby odrzucone przez stos. To dlatego tcpdump i Wireshark mogą pokazywać pakiety, których system operacyjny sam by nie przyjął.

Biblioteka libpcap (Packet Capture library) powstała w 1994 roku w Lawrence Berkeley National Laboratory jako część prac nad narzędziem tcpdump. Od tego czasu stała się standardowym API dla aplikacji przechwytujących pakiety w systemach Unix/Linux. Na platformie Windows funkcję tę pełni Npcap (następca WinPcap), który od wersji 1.0 wspiera również przechwytywanie na interfejsach loopback.

Wybór między WinPcap a Npcap na Windows jest istotny - WinPcap nie jest rozwijany od 2013 roku i nie wspiera nowszych wersji Windows ani architektury 64-bitowej w pełni. Npcap oferuje natomiast zgodność z Windows 10/11, obsługę kart Wi-Fi w trybie monitor oraz lepszą wydajność dzięki nowoczesnym sterownikom NDIS 6. Instalacja Wireshark domyślnie proponuje instalację Npcap.

Gniazda PF_PACKET (wcześniej SOCK_PACKET) są kluczowym mechanizmem umożliwiającym przechwytywanie surowych ramek w systemie Linux. Aplikacja tworzy gniazdo typu SOCK_RAW lub SOCK_DGRAM w rodzinie PF_PACKET, co pozwala na odbiór ramek Ethernet przed ich przetworzeniem przez stos protokołów jądra. Dzięki temu możliwe jest przechwytywanie nawet nietypowych ramek, które nie pasują do żadnego ze standardowych protokołów.

Wymaganie uprawnień root dla gniazd PF_PACKET wynika z kwestii bezpieczeństwa - dostęp do surowych ramek umożliwia nie tylko podsłuchiwanie, ale także wysyłanie sfałszowanych pakietów. W systemach produkcyjnych, aby uniknąć uruchamiania narzędzi z pełnymi uprawnieniami root, stosuje się mechanizmy takie jak capabilities (CAP_NET_RAW, CAP_NET_ADMIN) lub grupy (wireshark group w /etc/group).

Berkeley Packet Filter (BPF) to przełomowa technologia wprowadzona w 1992 roku przez Stevena McCanne'a i Vana Jacobsona z Lawrence Berkeley Laboratory. BPF został zaprojektowany jako wydajna maszyna wirtualna w jądrze systemu, która może wykonywać proste programy filtrujące bez konieczności kopiowania każdego pakietu do przestrzeni użytkownika. To radykalnie zmniejsza obciążenie CPU i umożliwia filtrowanie w sieciach o dużej przepustowości.

Filtr BPF jest kompilowany z języka wysokiego poziomu (składni podobnej do tej z tcpdump) do kodu bajtowego (bytecode), który jest następnie weryfikowany przez jądro przed wykonaniem. Weryfikacja zapewnia, że program BPF nie zawiera pętli nieskończonych i nie odwołuje się do pamięci poza dozwolonym zakresem. To sprawia, że BPF jest bezpieczny dla jądra systemu.

Mechanizm filtrowania w jądrze za pomocą BPF to jedna z głównych zalet narzędzi takich jak tcpdump. Bez BPF każdy pakiet musiałby być kopiowany z jądra do przestrzeni użytkownika, nawet jeśli nie interesuje on aplikacji. W przypadku sieci 10 Gb/s, gdzie w ciągu sekundy może pojawić się kilkanaście milionów pakietów, takie kopiowanie prowadziłoby do natychmiastowego przeciążenia CPU.

Filtr BPF jest stosowany nie tylko przez tcpdump, ale także przez Wireshark (capture filter) i inne narzędzia. Każde gniazdo PF_PACKET może mieć przypisany filtr BPF za pomocą wywołania systemowego setsockopt z opcją SO_ATTACH_FILTER. Po załadowaniu filtra jądro automatycznie stosuje go do każdego przychodzącego pakietu przed przekazaniem do gniazda.

Prymitywy BPF stanowią podstawowe elementy, z których buduje się wyrażenia filtrujące. Każdy prymityw składa się z identyfikatora (np. host, port, net) i opcjonalnego kwalifikatora kierunku (src, dst) lub protokołu (tcp, udp). Łączenie prymitywów za pomocą operatorów logicznych (and, or, not) pozwala na tworzenie filtrów o dowolnej złożoności, ograniczonej jedynie maksymalnym rozmiarem kodu BPF (zwykle 4096 bajtów).

Warto zwrócić uwagę na filtr "ether" - dotyczy on warstwy łącza danych (L2) i operuje na adresach MAC. Filtrowanie po adresie MAC jest przydatne w sieciach, gdzie stosuje się translację adresów (NAT) lub gdy chcemy wyizolować ruch konkretnego urządzenia niezależnie od jego adresu IP (np. w przypadku DHCP, gdzie adres IP jeszcze nie jest przypisany).

Operatory logiczne w BPF działają standardowo: "and" (&&) wymaga spełnienia obu warunków, "or" (||) wymaga spełnienia przynajmniej jednego, a "not" (!) neguje warunek. Kolejność operatorów ma znaczenie - and ma wyższy priorytet niż or, dlatego w bardziej złożonych wyrażeniach zaleca się używanie nawiasów dla jednoznaczności, np. "host 10.0.0.1 and (port 80 or port 443)".

Przykłady na slajdzie ilustrują typowe zastosowania. Filtr "not port 22" jest szczególnie przydatny podczas diagnostyki własnego połączenia SSH - bez niego każde naciśnięcie klawisza w terminalu SSH generowałoby pakiety, które zanieczyszczałyby przechwytywany ruch. W praktyce zaleca się zawsze wykluczać własny port zarządzania z filtra.

Przykłady filtrów BPF na slajdzie pokazują typowe scenariusze analizy ruchu sieciowego. Filtr "tcp port 80" przechwytuje cały ruch HTTP (zarówno żądania GET, jak i odpowiedzi serwera), co jest podstawą diagnostyki działania serwisów WWW. W przypadku ruchu szyfrowanego HTTPS (port 443) zastosowanie tego filtra da tylko pakiety z nagłówkami TLS bez możliwości odczytania treści.

Filtr "icmp" przechwytuje pakiety protokołu ICMP, czyli przede wszystkim pakiety Echo Request i Echo Reply używane przez polecenie ping. Analiza ICMP pozwala na diagnozowanie problemów z łącznością na poziomie sieci (L3), ale należy pamiętać, że wiele firewalli blokuje ICMP, więc brak odpowiedzi ping nie musi oznaczać braku łączności.

Bardziej złożone filtry na tym slajdzie pokazują, jak łączyć warunki dotyczące różnych protokołów i portów. Filtr "port 67 or port 68" przechwytuje ruch DHCP, który jest kluczowy przy diagnozowaniu problemów z przydzielaniem adresów IP. Ponieważ DHCP używa zarówno UDP (porty 67/68), jak i w niektórych przypadkach rozgłoszeń, ten filtr jest dobrym przykładem łączenia warunków.

Filtr "ip6" przechwytuje tylko pakiety IPv6. W sieciach z podwójnym stosem (dual-stack) często występuje ruch zarówno IPv4, jak i IPv6, co może utrudniać analizę. Filtrowanie po wersji protokołu IP pozwala na wyizolowanie interesującej nas wersji, co jest szczególnie przydatne przy migracji z IPv4 na IPv6.

Filtrowanie po adresach MAC jest niezwykle przydatne w sieciach warstwy 2, gdzie komunikacja odbywa się bez użycia adresów IP (np. w sieciach fabrycznych, systemach SCADA). Adres MAC składa się z 6 oktetów (48 bitów) zapisanych w notacji szesnastkowej. Pierwsze 3 oktety (24 bity) to identyfikator producenta (OUI - Organizationally Unique Identifier), który można sprawdzić w bazach danych (np. Wireshark OUI Lookup).

Filtr "ether broadcast" przechwytuje ramki broadcast (adres MAC FF:FF:FF:FF:FF:FF), które są wysyłane do wszystkich urządzeń w segmencie sieci. Z kolei "ether multicast" przechwytuje ramki multicast (adres MAC zaczynający się od 01:00:5E dla IPv4). Nadmierna liczba ramek broadcast może świadczyć o problemach sieciowych, takich jak pętle przełączania lub ataki ARP spoofing.

Filtrowanie po rozmiarze pakietu jest przydatne w wykrywaniu określonych typów ruchu. Na przykład pakiety o rozmiarze 40–60 bajtów to zazwyczaj pakiety sterujące TCP (SYN, ACK, FIN) bez danych. Gwałtowny wzrost liczby takich małych pakietów może wskazywać na atak SYN flood lub skanowanie portów. Z kolei pakiety o rozmiarze bliskim MTU (1500 bajtów dla Ethernet) świadczą o transferach dużych danych.

Filtr "less 100" przechwytuje pakiety krótsze niż 100 bajtów. W sieci Ethernet minimalny rozmiar ramki to 64 bajty (bez preambuły). Pakiety mniejsze niż 64 bajty to tzw. runty i są błędem warstwy łącza danych. Z kolei "greater 1000" przechwytuje pakiety duże, charakterystyczne dla transferów plików, strumieni wideo lub backupów.

Filtrowanie na poziomie bitów (offset) to najbardziej zaawansowana i elastyczna cecha BPF. Pozwala ona na sprawdzenie dowolnego bajtu w ramce Ethernet, niezależnie od protokołu. Składnia "ether[12:2]" oznacza dwa bajty (16 bitów) zaczynając od pozycji 12 w ramce Ethernet. W ramce Ethernet pozycja 12 zawiera pole EtherType (2 bajty), które identyfikuje protokół warstwy sieciowej (np. 0x0800 dla IPv4, 0x86DD dla IPv6, 0x0806 dla ARP).

Filtrowanie flag TCP na podstawie offsetu 13 w nagłówku TCP jest szczególnie użyteczne. Każda flaga TCP jest reprezentowana przez jeden bit w bajcie na pozycji 13 (licząc od początku nagłówka TCP). Flaga SYN to bit 1 (0x02), ACK to bit 4 (0x10), FIN to bit 0 (0x01), RST to bit 2 (0x04). Operator & (AND) pozwala na maskowanie tylko interesujących nas bitów.

Atak SYN flood jest jednym z najstarszych i najbardziej znanych typów ataków DoS (Denial of Service). Polega na wysłaniu dużej liczby pakietów TCP z ustawioną flagą SYN, ale bez finalizowania trójstronnego uzgadniania (three-way handshake). Serwer, odbierając takie pakiety, alokuje zasoby dla każdej półotwartej sesji, co prowadzi do wyczerpania pamięci i odmowy obsługi legalnych połączeń.

Filtr BPF do wykrywania SYN flood wykrywa pakiety, które mają flagę SYN ustawioną na 1, a flagę ACK na 0. W normalnym ruchu takie pakiety pojawiają się tylko przy inicjowaniu nowych połączeń. Jeśli liczba SYN pakietów na sekundę przekracza ustalony próg (np. 1000/s dla typowego serwera WWW), można podejrzewać atak. Narzędzia takie jak tcpdump z filtrem "tcp[13] & 0x02 != 0" umożliwiają zliczanie takich pakietów.

Rozróżnienie między capture filter a display filter w Wireshark jest jednym z najważniejszych pojęć, które należy zrozumieć przy analizie ruchu sieciowego. Capture filter (filtr przechwytywania) używa składni BPF i jest stosowany przed zapisem pakietu do pliku - pakiety odrzucone przez filtr są bezpowrotnie tracone. To oszczędza zasoby (CPU, dysk), ale niesie ryzyko utraty ważnych danych.

Display filter (filtr wyświetlania) ma własną, bogatszą składnię (np. "http.request.method == GET", "tcp.analysis.retransmission") i działa tylko na już przechwyconych danych. Pakiety nie spełniające kryterium są jedynie ukrywane z widoku, ale pozostają w pliku pcap. Zasada ogólna: jeśli nie wiesz dokładnie, czego szukasz, przechwytuj wszystko i używaj display filter.

Przykład konfiguracji przechwytywania na slajdzie ilustruje praktyczny scenariusz, w którym administrator chce monitorować ruch HTTP konkretnej sieci, wykluczając własny komputer. Capture filter "net 192.168.1.0/24 and port 80 and not host 192.168.1.100" jest dobrym przykładem wykorzystania operatorów logicznych w praktyce. Należy pamiętać, że filtr BPF nie rozróżnia ruchu przychodzącego od wychodzącego, chyba że użyje się kwalifikatorów src/dst.

Po przechwyceniu danych display filter "http.request.method == GET" pozwala na wyświetlenie tylko żądań GET, pomijając odpowiedzi serwera i inne metody HTTP (POST, PUT, DELETE). Dla analizy wydajności warto również użyć display filter "tcp.analysis.ack_rtt" do sprawdzenia czasu odpowiedzi serwera lub "http.time" do analizy czasu ładowania stron.

Pułapki capture filtra wynikają z ograniczeń technicznych BPF oraz z faktu, że filtr działa na poziomie jądra, gdzie dostępne są tylko informacje z nagłówków warstwy 2, 3 i 4. Protokoły warstwy aplikacji (HTTP, DNS, DHCP) są dla BPF niewidoczne, ponieważ ich nagłówki znajdują się dopiero w danych pakietu, a BPF nie ma wbudowanej wiedzy o ich strukturze.

Głęboko zagnieżdżone nawiasy mogą przekroczyć limit złożoności kodu BPF, który wynosi zwykle 512 instrukcji dla klasycznego BPF (cBPF). W przypadku bardziej złożonych filtrów warto rozważyć użycie eBPF, które ma wyższe limity (do 4096 instrukcji). Ograniczenia te są jednak rzadko osiągane w praktyce - większość użytecznych filtrów mieści się w kilkunastu instrukcjach.

Port mirroring (SPAN) to podstawowa funkcja przełączników zarządzalnych, która umożliwia monitorowanie ruchu sieciowego bez fizycznej ingerencji w infrastrukturę. Konfiguracja SPAN polega na wskazaniu portów źródłowych (monitorowanego ruchu) i portu docelowego (tam, gdzie podłączony jest analizator). Przełącznik kopiuje każdą ramkę z portów źródłowych na port docelowy.

Rodzaje SPAN różnią się zasięgiem: lokalny SPAN (kopiowanie w obrębie jednego przełącznika) jest najprostszy, RSPAN (kopiowanie przez dedykowaną sieć VLAN) umożliwia monitorowanie na innym przełączniku, a ERSPAN (enkapsulacja w GRE) pozwala na wysłanie ruchu do zdalnego analizatora przez sieć IP. Wszystkie warianty mają jednak ograniczenie - mogą obciążać CPU przełącznika.

TAP (Test Access Point) jest urządzeniem pasywnym, co oznacza, że nie wymaga zasilania do przekazywania ruchu. W przypadku awarii zasilania TAP zachowuje się jak zwykłe złącze - ruch przepływa przez niego bez kopiowania do portów monitorujących. To kluczowa zaleta w porównaniu z SPAN, który wymaga działającego przełącznika. TAP może być optyczny (dla światłowodów) lub miedziany (dla kabli Ethernet).

Nowoczesne TAP-y oferują dodatkowe funkcje: regenerację sygnału (re-timing), agregację ruchu z wielu interfejsów (multi-TAP), filtrowanie sprzętowe oraz obsługę szybkości 40 Gb/s i 100 Gb/s. Regeneracja sygnału pozwala na przechwytywanie bez degradacji jakości łącza, co jest szczególnie ważne w sieciach operatorskich i centrach danych.

Porównanie TAP i SPAN na slajdzie pokazuje, że wybór między nimi zależy od budżetu, wymagań dotyczących niezawodności i charakterystyki sieci. SPAN jest "darmowy" (wbudowany w przełącznik), ale ma ograniczenia - gubi pakiety przy 100% wykorzystania łącza, nie kopiuje błędów ramek i może być wykryty. TAP jest droższy, ale zapewnia pełną widoczność ruchu łącznie z błędami warstwy fizycznej.

W praktyce oba rozwiązania często współistnieją: TAP na kluczowych łączach (między przełącznikiem a firewallem, między centrami danych), a SPAN na mniej krytycznych portach dostępowych. W środowiskach o wysokich wymaganiach (finanse, telekomunikacja) standardem jest stosowanie agregujących przełączników TAP (matrix TAP), które umożliwiają kierowanie ruchu z wielu źródeł do wielu narzędzi analitycznych.

Checklista przygotowania do przechwytywania jest wzorcem postępowania, który powinien stosować każdy administrator sieci przed rozpoczęciem pomiarów. Punkt 1 (definiowanie celu) jest najważniejszy - bez jasno określonego celu łatwo utonąć w ogromie danych. Określenie, czy szukamy problemów z wydajnością, błędów konfiguracji, czy oznak ataku, determinuje wybór punktu przechwycenia i narzędzi.

Punkt 5 (snaplen) i punkt 6 (zapis do pliku) mają bezpośredni wpływ na ilość zbieranych danych. W przypadku długotrwałego monitorowania (24h+) zaleca się stosowanie ring bufora z ograniczeniem rozmiaru pliku. Dokumentacja konfiguracji (punkt 7) jest kluczowa dla powtarzalności pomiarów - opisany scenariusz, użyte filtry i znaczniki czasu powinny być zapisane w notatniku lub pliku konfiguracyjnym.

Snaplen (snapshot length) to parametr często pomijany przez początkujących użytkowników, ale mający istotny wpływ na wydajność przechwytywania i rozmiar plików pcap. Domyślna wartość 262144 bajty (256 KiB) jest odpowiednia do przechwytywania pełnych pakietów, łącznie z danymi warstwy aplikacji. Jednak do analizy nagłówków (adresy, porty, flagi) wystarczy 96–128 bajtów na pakiet.

Zmniejszenie snaplena ma sens w dwóch przypadkach: gdy interesują nas tylko nagłówki (analiza statystyczna, wykrywanie anomalii) oraz gdy przechwytujemy na szybkich łączach (10+ Gb/s), gdzie zapis pełnych pakietów może przeciążyć dysk. W tcpdump opcja -s ustawia snaplen, w Wireshark ustawienie w Capture Options. Należy pamiętać, że po zmniejszeniu snaplena nie zobaczymy payloadu pakietów.

Minimalny snaplen 96 bajtów jest obliczony na podstawie minimalnych rozmiarów nagłówków: Ethernet 14 bajtów (łącznie z 4-bajtowym tagiem VLAN lub bez), nagłówek IP 20 bajtów (bez opcji), nagłówek TCP 20 bajtów (bez opcji). Razem daje to 54 bajty; dodając 42 bajty na ewentualne opcje IP i TCP, otrzymujemy 96 bajtów. Dla UDP nagłówek jest krótszy (8 bajtów), więc 96 bajtów z nadmiarem wystarcza.

Przycięcie pakietów do samego nagłówka (header-only capture) jest często stosowane w systemach monitorowania przepływów (NetFlow, sFlow) oraz w narzędziach bezpieczeństwa, gdzie analizuje się metadane połączeń, a nie treść. W przypadku podejrzenia wycieku danych lub analizy malware niezbędny jest pełny snaplen, aby móc odtworzyć strumień TCP i zobaczyć przesyłane dane.

tcpdump jest najstarszym i najbardziej rozpowszechnionym narzędziem CLI do przechwytywania pakietów. Mimo że jego interfejs jest tekstowy, oferuje pełną funkcjonalność: przechwytywanie z filtrami BPF, zapis do pliku pcap, odczyt z pliku, podstawową analizę protokołów. Opcja -c (count) zatrzymuje przechwytywanie po określonej liczbie pakietów, co jest przydatne przy testach i w skryptach.

Opcja -n (no resolution) wyłącza rozwiązywanie nazw DNS, co znacząco przyspiesza działanie i zwiększa bezpieczeństwo (brak zapytań DNS podczas przechwytywania). W połączeniu z -nn (wyłącza również rozwiązywanie portów serwisowych) daje szybki, czysty output. tcpdump można również używać do odczytu zapisanych plików pcap za pomocą opcji -r.

Wireshark oferuje wygodny interfejs graficzny do przechwytywania i analizy pakietów. Po uruchomieniu (wymagane uprawnienia administratora) wyświetlana jest lista dostępnych interfejsów sieciowych wraz z wykresem aktywności w czasie rzeczywistym. Dwukrotne kliknięcie interfejsu rozpoczyna przechwytywanie z domyślnymi ustawieniami, a kliknięcie ikony płetwy (Start) pozwala na zmianę opcji przed rozpoczęciem.

Główne okno Wireshark dzieli się na trzy panele: listę pakietów (z kolumnami: czas, źródło, cel, protokół, informacje), szczegóły protokołu (drzewiasta struktura nagłówków) oraz hex dump (surowe bajty z zaznaczeniem wybranego pola). Kolory w liście pakietów pomagają w szybkiej identyfikacji typów ruchu: jasnoniebieski dla TCP, zielony dla UDP, żółty dla HTTP.

Ring buffer to technika przechwytywania stosowana przy długotrwałym monitorowaniu sieci. Zamiast jednego, rosnącego bez ograniczeń pliku pcap, tworzonych jest wiele plików o ustalonym maksymalnym rozmiarze. Gdy wszystkie pliki w buforze zostaną zapełnione, najstarszy jest nadpisywany. Dzięki temu nigdy nie zabraknie miejsca na dysku, a jednocześnie zawsze dostępny jest ostatni fragment przechwyconego ruchu.

W tcpdump ring buffer włącza się przez połączenie opcji -C (max rozmiar pliku w MB) i -W (liczba plików w buforze). Na przykład "tcpdump -i eth0 -C 100 -W 10 -w bufor.pcap" tworzy 10 plików po 100 MB każdy, czyli maksymalnie 1 GB danych. Wireshark oferuje ring buffer w ustawieniach Capture Options w zakładce "Output".

Rotacja plików w czasie za pomocą opcji -G w tcpdump jest szczególnie przydatna, gdy chcemy korelować przechwycony ruch z innymi danymi (logi serwera, zdarzenia bezpieczeństwa). Nowy plik jest tworzony co określoną liczbę sekund, a nazwa pliku może zawierać znaczniki czasu formatowane według wzorca strftime (np. %Y = rok, %m = miesiąc, %d = dzień, %H = godzina, %M = minuta, %S = sekunda).

Przykład "tcpdump -i eth0 -G 3600 -w log_%Y-%m-%d_%H.pcap" tworzy pliki cogodzinne o nazwach takich jak log_2026-05-24_10.pcap. Taki podział ułatwia późniejszą analizę i archiwizację - starsze pliki można automatycznie kompresować (gzip) i przenosić do chłodnego przechowywania (cold storage) po upływie okresu retencji.

Wpływ przechwytywania na wydajność systemu analizatora to temat często pomijany, ale krytyczny w środowiskach produkcyjnych. Pasywne przechwytywanie samo w sobie nie spowalnia sieci - pakiety są tylko kopiowane, a nie opóźniane. Jednak proces kopiowania z jądra do przestrzeni użytkownika, filtrowania i zapisu na dysk wymaga zasobów CPU i pamięci systemu, na którym działa narzędzie.

W sieciach 10 Gb/s pełne przechwytywanie może generować strumień danych przekraczający 1 GB/s, co wymaga nie tylko szybkiego procesora, ale przede wszystkim wydajnego systemu dyskowego (NVMe SSD w konfiguracji RAID). W przypadku przekroczenia możliwości sprzętowych narzędzia zgłaszają utratę pakietów (packet loss), co można sprawdzić w statystykach końcowych tcpdump lub w Wireshark (Status bar).

Statystyki przechwytywania podawane przez tcpdump po zakończeniu pracy są kluczowym źródłem informacji o jakości pomiaru. Wartość "packets captured" oznacza liczbę pakietów, które dotarły do aplikacji (tcpdump). "Packets received by filter" to pakiety odebrane przez gniazdo PF_PACKET (czyli wszystkie, które przeszły przez filtr BPF w jądrze). Różnica między tymi wartościami to pakiety, które nie zostały skopiowane do przestrzeni użytkownika.

"Packets dropped by kernel" to pakiety, które jądro odrzuciło z powodu przepełnienia bufora PF_PACKET. Jeśli ten wskaźnik przekracza 1%, oznacza to, że system nie nadąża z przetwarzaniem pakietów. Rozwiązaniem jest zwiększenie bufora jądra (sysctl net.core.rmem_default) lub użycie opcji -B w tcpdump do zwiększenia bufora dla konkretnego przechwytywania.

Bufor jądra dla gniazd PF_PACKET (ring buffer) to kluczowy parametr wpływający na niezawodność przechwytywania. Domyślny rozmiar bufora w Linux to 4096 bajtów na gniazdo, co jest wartością bardzo małą - przy intensywnym ruchu bufor przepełnia się w ułamku sekundy. Dlatego tcpdump i Wireshark automatycznie zwiększają ten bufor podczas uruchamiania, ale wartość domyślna może być niewystarczająca.

Zwiększenie bufora jądra za pomocą sysctl do wartości 16 MB (net.core.rmem_default = 16777216) znacząco zmniejsza ryzyko utraty pakietów, szczególnie przy ruchu z dużą liczbą małych pakietów. W systemach o ograniczonej pamięci należy jednak zachować ostrożność - zbyt duży bufor może prowadzić do wyczerpania pamięci jądra (kernel memory).

Przechwytywanie na wielu interfejsach jednocześnie jest przydatne, gdy analizujemy ruch przechodzący przez router lub firewall i chcemy zobaczyć obie strony połączenia. tcpdump obsługuje tylko jeden interfejs na raz, dlatego do jednoczesnego przechwytywania z wielu interfejsów trzeba uruchomić wiele instancji tcpdump lub użyć tshark z opcją -i dla każdego interfejsu.

Format pcapng (PCAP Next Generation) wspiera wiele interfejsów w jednym pliku, co ułatwia późniejszą analizę. Każdy pakiet w pcapng ma przypisany identyfikator interfejsu (interface ID), dzięki czemu Wireshark może pokazać, na którym interfejsie został przechwycony. Pliki pcapng obsługują także inne rozszerzenia, takie jak komentarze do pakietów i opcjonalne bloki dekodowania.

Mapa narzędzi na slajdzie podsumowuje najpopularniejsze narzędzia używane w pomiarach logicznych. tcpdump to standard CLI do przechwytywania, dostępny na wszystkich systemach Unix/Linux. Jest lekki, szybki i doskonały do skryptów. Wireshark oferuje graficzną analizę z obsługą setek protokołów i zaawansowanych filtrów display. tshark to CLI Wireshark, pozwalający na automatyzację analizy.

dumpcap jest częścią pakietu Wireshark wyspecjalizowaną wyłącznie w przechwytywaniu - nie ma własnych funkcji analizy ani wyświetlania, ale zużywa mniej CPU niż tcpdump. tcpflow rekonstruuje strumienie TCP, co jest przydatne do odtwarzania treści sesji (np. HTTP, SMTP) z plików pcap. ngrep łączy funkcje tcpdump i grep, szukając wzorców w treści pakietów.

dumpcap jest często najlepszym wyborem do przechwytywania w środowiskach produkcyjnych ze względu na minimalne zużycie zasobów. W przeciwieństwie do tcpdump, który parsuje i wyświetla pakiety na bieżąco, dumpcap tylko zapisuje je do pliku, co znacząco redukuje obciążenie CPU. Jest to szczególnie istotne przy przechwytywaniu na serwerach, gdzie każde dodatkowe obciążenie procesora może wpływać na działanie usług.

dumpcap obsługuje zaawansowane opcje rotacji plików: -b filesize:100000 tworzy nowy plik po przekroczeniu 100 MB, -b duration:3600 tworzy nowy plik co godzinę, a -b files:10 ogranicza liczbę plików (ring buffer). Opcje te można łączyć, np. "dumpcap -i eth0 -b filesize:100000 -b files:20 -w wyjscie.pcapng".

ngrep to narzędzie szczególnie przydatne, gdy interesuje nas konkretna treść w pakietach, a nie ich struktura. Na przykład administrator może szybko sprawdzić, czy przez sieć przesyłane są niezaszyfrowane hasła, szukając wzorca "password" w ruchu HTTP. ngrep działa w czasie rzeczywistym, wyświetlając pasujące pakiety na terminalu z podświetleniem dopasowanego fragmentu.

Opcja -d określa interfejs sieciowy, -i ignoruje wielkość liter podczas wyszukiwania, a -x wyświetla pakiety w formacie szesnastkowym. ngrep może również odczytywać pliki pcap (opcja -I) i zapisywać wyniki do pliku (opcja -O). W praktyce ngrep jest używany do szybkiej diagnostyki, a do szczegółowej analizy protokołów lepiej sprawdza się Wireshark.

tcpflow rekonstruuje strumienie TCP, co jest niezwykle przydatne przy analizie protokołów tekstowych (HTTP, SMTP, FTP, POP3). W przeciwieństwie do tcpdump, który pokazuje pakiety, tcpflow składa je w logiczne strumienie i zapisuje do plików. Każdy plik zawiera dane wysłane w jednym kierunku sesji TCP, co umożliwia łatwy odczyt treści komunikacji.

Nazwy plików tworzonych przez tcpflow mają format adres_ŹRÓDŁOWY.port-adres_DOCELOWY.port. Na przykład plik "192.168.1.100.54321-192.168.1.1.00080" zawiera dane wysłane z adresu 192.168.1.100 (port 54321) do 192.168.1.1 (port 80). Dla ruchu szyfrowanego (HTTPS, SSH) tcpflow pokaże tylko zaszyfrowane dane, co uniemożliwia odczytanie treści.

Wykrywanie skanowania portów jest jednym z klasycznych zastosowań analizy ruchu sieciowego. Skaner portów (np. Nmap) wysyła pakiety SYN do wielu portów docelowego hosta w krótkim czasie i analizuje odpowiedzi. Otwarty port odpowiada SYN+ACK (gotowość do nawiązania połączenia), zamknięty RST (odrzucenie połączenia). Wzorzec: wiele SYN do różnych portów z jednego źródła jest charakterystyczny dla skanowania.

Po przechwyceniu podejrzanego ruchu narzędzie Wireshark ułatwia analizę: Statistics -> Endpoints pokazuje wszystkie adresy IP i liczbę pakietów. Sortując po liczbie pakietów, szybko znajdziemy adres IP, który wysyła najwięcej pakietów. Filtr "tcp.flags.syn == 1 and tcp.flags.ack == 0" wyświetla tylko pakiety SYN, co pozwala na zliczenie prób połączeń do poszczególnych portów.

ARP spoofing (ARP poisoning) to technika ataku w sieciach lokalnych, polegająca na wysłaniu sfałszowanych odpowiedzi ARP, w których atakujący podaje swój adres MAC jako adres MAC bramy domyślnej lub innego hosta. W efekcie ruch przeznaczony dla ofiary jest kierowany przez komputer atakującego, który może go podsłuchać, zmodyfikować lub zablokować (man-in-the-middle).

Wireshark oferuje wbudowane narzędzie do wykrywania duplikatów adresów ARP: Analyze -> Expert Info -> Warnings, lub filtr display "arp.duplicate-address-detected". Jeśli dwa różne adresy MAC są przypisane do tego samego IP, mamy do czynienia z ARP spoofingiem. Zabezpieczeniem przed tym atakiem jest stosowanie Dynamic ARP Inspection (DAI) na przełącznikach oraz statycznych wpisów ARP.

Kwestie etyczne i prawne przechwytywania ruchu sieciowego są często bagatelizowane, ale mają poważne konsekwencje. W Polsce przechwytywanie ruchu bez zgody uczestników komunikacji jest czynem zabronionym przez art. 267 Kodeksu Karnego (nieuprawnione uzyskanie informacji). Przepisy RODO dodatkowo chronią dane osobowe, które mogą być zawarte w przechwyconych pakietach (adresy IP, treść komunikacji).

Laboratoryjne środowiska testowe są bezpieczną przestrzenią do nauki przechwytywania. Własna sieć domowa również jest akceptowalna, pod warunkiem że wszystkie podłączone urządzenia należą do nas. Publiczne sieci Wi-Fi (kawiarnie, lotniska) są szczególnie ryzykowne - przechwytywanie w nich ruchu może być uznane za przestępstwo. Zasada: przechwytuj tylko to, do czego masz wyraźną zgodę.

Dobre praktyki w laboratorium mają na celu wyrobienie nawyków, które będą przydatne w pracy zawodowej. Używanie własnych urządzeń i sieci do testów eliminuje ryzyko naruszenia prywatności innych osób. Jeśli laboratorium wymaga przechwytywania ruchu w grupie ćwiczeniowej, należy uzyskać zgodę prowadzącego i wszystkich uczestników, a wyniki analizy nie powinny zawierać danych wrażliwych.

Anonimizacja plików pcap przed udostępnieniem jest ważną umiejętnością. Wireshark oferuje narzędzia do anonimizacji (Statistics -> Anonymize), które zastępują adresy IP i MAC losowymi wartościami, zachowując strukturę ruchu. Można również użyć narzędzia tracewrangler do zaawansowanej anonimizacji. Po zakończeniu analizy należy usunąć pliki pcap, chyba że są potrzebne do dalszej pracy.

Podsumowanie pierwszej części prezentacji pokazuje, jak wiele zagadnień zostało omówionych. Pomiary logiczne różnią się od fizycznych zakresem i narzędziami, ale są z nimi ściśle powiązane - problem fizyczny często objawia się jako logiczny. Zrozumienie trybów pracy kart sieciowych (promiscuous, monitor) jest niezbędne do skutecznego przechwytywania ruchu.

Biblioteka libpcap/Npcap stanowi fundament całego ekosystemu narzędzi pomiarowych, a filtry BPF są uniwersalnym językiem filtrowania pakietów. Umiejętność pisania filtrów BPF odróżnia początkującego użytkownika od zaawansowanego analityka. Filtry mogą wybierać pakiety według adresów, portów, protokołów, flag TCP, a nawet dowolnych bajtów w nagłówkach.

Drugie podsumowanie koncentruje się na praktycznych aspektach korzystania z narzędzi pomiarowych. Zrozumienie różnicy między capture filter (filtr przechwytywania w jądrze) a display filter (filtr wyświetlania w aplikacji) jest kluczowe dla efektywnej pracy. Capture filter oszczędza zasoby, ale bezpowrotnie usuwa pakiety - dlatego gdy nie mamy pewności, lepiej przechwycić wszystko.

SPAN i TAP to dwa uzupełniające się sposoby na dostęp do ruchu w sieciach przełączanych. Wybór między nimi zależy od budżetu, wymagań i topologii sieci. Warto pamiętać, że przechwytywanie może gubić pakiety przy dużym obciążeniu, dlatego należy monitorować statystyki przechwytywania. Etyka i prawo są nieodłączną częścią pracy z narzędziami pomiarowymi.

Pytania kontrolne weryfikują zrozumienie kluczowych pojęć z pierwszej połowy prezentacji. Różnica między trybem promiscuous a monitor ma fundamentalne znaczenie - pierwszy dotyczy sieci przewodowych (Ethernet), drugi bezprzewodowych (Wi-Fi). Tryb promiscuous pozwala na przechwytywanie ramek w sieci z hubem lub SPAN, podczas gdy tryb monitor umożliwia widzenie wszystkich sieci Wi-Fi w zasięgu.

Biblioteka libpcap jest sercem narzędzi pomiarowych w systemach Unix/Linux. Bez niej istnienie Wireshark, tcpdump i innych narzędzi nie byłoby możliwe. libpcap dostarcza standaryzowane API do przechwytywania pakietów, niezależne od konkretnego sprzętu sieciowego czy sterownika. Na platformie Windows funkcje libpcap realizuje biblioteka Npcap.

Kolejne pytania kontrolne sprawdzają znajomość filtrów i narzędzi. Różnica między capture filter a display filter dotyczy momentu zastosowania i zakresu działania. Capture filter (BPF) działa w jądrze i bezpowrotnie odrzuca pakiety, co pozwala oszczędzać zasoby, ale niesie ryzyko utraty danych. Display filter (Wireshark) działa po przechwyceniu i tylko ukrywa pakiety z widoku.

Przykładowy filtr BPF "host 192.168.1.10 and port 80" pokazuje składnię łączenia prymitywów. host określa adres IP, port numer portu, and jest operatorem logicznym koniunkcji. Filtr ten przechwyci cały ruch HTTP (port 80) związany z hostem 192.168.1.10 - zarówno wychodzący, jak i przychodzący, ponieważ nie użyto kwalifikatorów src/dst.

Pytanie o "packets dropped by kernel" dotyczy zjawiska utraty pakietów na poziomie jądra systemu. Gdy bufor gniazda PF_PACKET jest pełny, jądro odrzuca nowe pakiety zamiast blokować proces odczytu. To zjawisko występuje, gdy aplikacja (tcpdump) nie nadąża z odczytywaniem pakietów z bufora, co może być spowodowane zbyt małym buforem lub przeciążeniem CPU.

Różnica między SPAN a TAP jest fundamentalna dla zrozumienia architektury monitorowania sieci. SPAN to funkcja programowa przełącznika, która wymaga zasobów CPU do kopiowania ramek, podczas gdy TAP to urządzenie sprzętowe działające w warstwie fizycznej. TAP jest pasywny i kopiuje błędy ramek (CRC, runt) które SPAN pomija, co czyni go lepszym wyborem do diagnostyki warstwy fizycznej.

Zadanie praktyczne na slajdzie 52 pozwala na samodzielne przećwiczenie omówionych pojęć. Włączenie trybu promiscuous na interfejsie LAN to pierwszy krok do zrozumienia, jak działa przechwytywanie. W systemie Windows ustawienie to znajduje się we właściwościach karty sieciowej (zakładka Zaawansowane), a w Linux za pomocą polecenia ip link.

Kolejne kroki prowadzą przez coraz bardziej zaawansowane filtry: od braku filtra (wszystkie pakiety) przez filtr port 53 (tylko DNS) do filtra icmp (tylko ping). Porównanie liczby przechwyconych pakietów w każdym przypadku ilustruje skuteczność filtrowania BPF. Raport z ćwiczenia powinien zawierać wnioski na temat redukcji liczby pakietów po zastosowaniu filtrów.

eBPF (extended Berkeley Packet Filter) to ewolucja klasycznego BPF, która rozszerza jego możliwości daleko poza filtrowanie pakietów. eBPF umożliwia uruchamianie programów w jądrze systemu w odpowiedzi na różne zdarzenia: przychodzący pakiet, wywołanie systemowe, funkcja jądra, timer. Programy te są pisane w C i kompilowane do bytecodu eBPF, a następnie weryfikowane przez jądro pod kątem bezpieczeństwa.

eBPF znalazł zastosowanie w wielu dziedzinach: obserwowalność (bpftrace, bcc), bezpieczeństwo (Falco, Tracee), sieci (Cilium, XDP) i wydajność. XDP (eXpress Data Path) pozwala na przetwarzanie pakietów już w sterowniku karty sieciowej, przed dotarciem do stosu TCP/IP jądra, co umożliwia osiągnięcie przepustowości rzędu milionów pakietów na sekundę na standardowym sprzęcie.

Przyszłość przechwytywania pakietów zmierza w kierunku odciążania jądra systemu i wykorzystywania specjalizowanego sprzętu. DPDK (Data Plane Development Kit), opracowany przez Intel, umożliwia aplikacjom użytkownika bezpośredni dostęp do kart sieciowych z pominięciem jądra, co eliminuje narzut związany z przełączaniem kontekstu i kopiowaniem danych. DPDK jest szeroko stosowany w rozwiązaniach NFV (Network Functions Virtualization).

PF_RING to technologia opracowana przez ntop, która przyspiesza przechwytywanie pakietów poprzez mmapowanie bufora jądra do przestrzeni użytkownika. W połączeniu z kartami sieciowymi Intel, PF_RING ZC (Zero Copy) umożliwia przechwytywanie i transmisję pakietów z szybkością 10 Gb/s na pojedynczym rdzeniu CPU. Dla 99% zastosowań (sieci do 1 Gb/s) standardowe tcpdump/Wireshark są w pełni wystarczające.

Zakończenie pierwszej części cyklu podsumowuje zdobytą wiedzę i zachęca do samodzielnych ćwiczeń. Praca własna polega na powtórzeniu składni BPF - zaleca się napisanie na kartce kilku przykładowych filtrów, aby utrwalić składnię bez konieczności uruchamiania komputera. Sprawdzenie opcji tcpdump (man tcpdump) pomoże w odkryciu zaawansowanych funkcji, takich jak analiza wyjścia w formacie JSON.

Instalacja Wireshark i Npcap na komputerze to praktyczny krok przygotowujący do następnych części cyklu. Wireshark jest dostępny na stronie wireshark.org, a podczas instalacji należy zaznaczyć opcję instalacji Npcap. Po instalacji warto uruchomić Wireshark i zapoznać się z interfejsem użytkownika - lista pakietów, szczegóły protokołu i hex dump to trzy główne panele, które będą używane w dalszej nauce.