Prezentacja szósta z cyklu Pomiary logiczne stanowi szczegółowe wprowadzenie do narzędzia tcpdump, które jest jednym z najpotężniejszych i najbardziej uniwersalnych narzędzi do przechwytywania i analizy pakietów sieciowych w środowisku wiersza poleceń. Narzędzie to, dostępne domyślnie w praktycznie każdej dystrybucji Linux oraz w systemach BSD i macOS, umożliwia diagnostykę sieci na poziomie poszczególnych pakietów.

Materiał obejmuje zarówno podstawy instalacji i konfiguracji, jak i zaawansowane techniki filtrowania za pomocą wyrażeń BPF, zapis i odczyt plików pcap oraz interpretację szczegółowego wyjścia narzędzia. Wiedza zdobyta w tej części stanowi fundament do dalszej nauki narzędzi takich jak Wireshark, tshark i systemów wykrywania włamań opartych na analizie ruchu sieciowego.

Plan szóstej części prezentacji obejmuje jedenaście głównych obszarów, rozpoczynając od historii i zastosowań tcpdump, poprzez instalację na dwóch najpopularniejszych platformach systemowych, aż po zaawansowane zagadnienia, takie jak filtry BPF, zapis i odczyt plików pcap oraz monitoring na żywo w kontraście z analizą offline.

Szczególny nacisk położono na praktyczne studia przypadków ilustrujące rzeczywiste scenariusze diagnostyczne, w tym analizę wolnego łącza, wykrywanie ataków ping flood oraz diagnostykę protokołu DHCP. Każde z tych zagadnień zostało opracowane w sposób umożliwiający samodzielne odtworzenie opisanych procedur na własnym sprzęcie laboratoryjnym lub w środowisku wirtualnym.

tcpdump zostało stworzone w 1987 roku na Uniwersytecie Kalifornijskim w Berkeley przez trzech wybitnych inżynierów: Vana Jacobsona, Craiga Leresa i Stevena McCanne'a. Jacobson jest znany również z opracowania algorytmów kontroli przeciążeń TCP (slow start, congestion avoidance), które do dziś stanowią fundament działania protokołu TCP/IP.

Biblioteka libpcap, na której opiera się tcpdump, stała się standardem de facto dla przechwytywania pakietów w systemach Unix/Linux. Na jej bazie powstały dziesiątki innych narzędzi, w tym popularny Wireshark. W systemie Windows odpowiednikiem libpcap jest Npcap, który zapewnia kompatybilność z tcpdump i innymi narzędziami z rodziny pcap.

Diagnostyka sieci z użyciem tcpdump pozwala na szybkie sprawdzenie, czy pakiety rzeczywiście opuszczają interfejs sieciowy i docierają do zamierzonego celu. Jest to szczególnie przydatne w sytuacjach, gdy narzędzia wyższego poziomu, takie jak ping czy iperf, nie dają jednoznacznej odpowiedzi na pytanie o lokalizację problemu.

W kontekście bezpieczeństwa tcpdump umożliwia wykrywanie skanowania portów (w tym SYN scan, FIN scan, Xmas scan), ataków typu DoS i DDoS, a także nietypowego ruchu wskazującego na obecność złośliwego oprogramowania. Możliwość automatyzacji przez skrypty powłoki z potokowaniem wyjścia do grep, awk i innych narzędzi tekstowych czyni tcpdump nieocenionym w środowiskach serwerowych bez dostępu do interfejsu graficznego.

Większość dystrybucji Linux zawiera tcpdump w domyślnej instalacji lub w standardowych repozytoriach pakietów. W przypadku Debian i Ubuntu narzędzie dostępne jest w pakiecie o tej samej nazwie, podobnie w Fedorze i RHEL. Alpine Linux, popularny w kontenerach Docker, wymaga jedynie wykonania polecenia apk add tcpdump.

Po instalacji warto sprawdzić dostępną wersję poleceniem tcpdump --version, które pokazuje informacje o wersji libpcap i obsługiwanych formatach plików. Dla poprawnego działania tcpdump wymaga uprawnień root lub odpowiednich capability (CAP_NET_RAW, CAP_NET_ADMIN) do otwarcia gniazda PF_PACKET w trybie promiscuous.

Npcap to następca biblioteki WinPcap, rozwijany przez firmę Nmap, który zapewnia natywne przechwytywanie pakietów w systemach Windows 7/8/10/11. Instalator Npcap zawiera biblioteki niezbędne do przechwytywania pakietów dla innych narzędzi sieciowych, w tym Nmap i Wireshark. Plik tcpdump.exe jest natomiast dystrybuowany wraz z instalatorem Wireshark. Podczas instalacji warto zaznaczyć opcję Install Npcap in WinPcap API-compatible Mode dla zachowania zgodności ze starszym oprogramowaniem.

Windows Subsystem for Linux (WSL2) stanowi wygodną alternatywę - po instalacji wybranej dystrybucji Linux w WSL można korzystać z tcpdump w naturalny sposób, a przechwycone pakiety zapisywać do plików pcap dostępnych z poziomu systemu Windows w katalogu /mnt/c/. Należy jednak pamiętać, że WSL2 używa wirtualnego przełącznika Hyper-V, co może ograniczać dostęp do niektórych trybów przechwytywania.

Składnia tcpdump opiera się na trzech elementach: nazwie programu, opcjach modyfikujących jego zachowanie oraz opcjonalnym filtrze BPF określającym, które pakiety mają być przechwycone. Kolejność opcji i filtra ma znaczenie - filtr musi występować po wszystkich opcjach, ponieważ tcpdump interpretuje pierwszy argument niezaczynający się od myślnika jako wyrażenie filtrujące.

Brak podanego filtra oznacza przechwytywanie wszystkich pakietów docierających do interfejsu sieciowego, co przy dużym obciążeniu sieci może prowadzić do szybkiego przepełnienia bufora jądra i utraty pakietów. Dlatego dobrą praktyką jest zawsze określenie przynajmniej podstawowego filtra (np. ograniczenie do konkretnego protokołu lub portu), nawet podczas wstępnej diagnostyki.

Przełącznik -i jest jednym z najczęściej używanych parametrów tcpdump, ponieważ określenie interfejsu sieciowego jest niezbędne do rozpoczęcia przechwytywania. W systemie Linux nazwy interfejsów mają standardowe nazewnictwo: eth0 dla pierwszej karty przewodowej, wlan0 dla pierwszej karty bezprzewodowej, lo dla interfejsu pętli zwrotnej (loopback).

Specjalna nazwa any dostępna wyłącznie w Linux umożliwia przechwytywanie na wszystkich interfejsach jednocześnie. Jest to przydatne w sytuacjach, gdy nie wiemy, przez który interfejs przechodzi interesujący nas ruch, ale należy pamiętać, że tryb any ma ograniczenia - nie obsługuje wszystkich typów filtrów BPF i nie może pracować w trybie promiscuous na poszczególnych interfejsach.

Opcja -D wyświetla listę wszystkich dostępnych interfejsów sieciowych wraz z ich numerami i krótkim opisem stanu. Numery interfejsów mogą być używane z opcją -i zamiast nazw, co jest szczególnie przydatne w skryptach, gdzie nazwy interfejsów mogą się zmieniać między różnymi systemami.

Lista pokazuje stan każdego interfejsu (Up lub Down), rodzaj (Running, Loopback) oraz dodatkowe informacje, takie jak dostępność przechwytywania. W systemach z wieloma interfejsami wirtualnymi (mostki, VLAN-y, kontenery Docker) lista może być długa, dlatego warto zapoznać się z nią przed rozpoczęciem właściwego przechwytywania.

Przełącznik -c z parametrem liczbowym jest niezbędnym narzędziem w pracy z tcpdump, szczególnie w środowiskach produkcyjnych i w skryptach automatyzujących. Automatyczne zakończenie po przechwyceniu określonej liczby pakietów eliminuje konieczność ręcznego przerywania procesu i ryzyko przypadkowego przechwycenia zbyt dużej ilości danych.

W skryptach powłoki opcja -c pozwala na konstruowanie pętli przetwarzających ruch w partiach, na przykład przechwytywanie 1000 pakietów, zapis do pliku, analiza, a następnie przechwycenie kolejnej partii. W połączeniu z opcją -G (rotacja czasowa) i -C (podział według rozmiaru) umożliwia tworzenie zaawansowanych systemów monitorujących o ograniczonej pojemności dyskowej.

Opcje -n i -nn mają kluczowe znaczenie dla wydajności i czytelności wyjścia tcpdump. Rozwiązywanie nazw DNS dla każdego adresu IP w pakiecie generuje dodatkowy ruch sieciowy i opóźnienia, które w środowisku produkcyjnym mogą zaburzać rzeczywisty obraz ruchu. Ponadto w przypadku braku odpowiedzi DNS wyjście może zawierać nieczytelne nazwy lub być opóźnione przez timeout zapytania.

Drugi aspekt stosowania -nn to bezpieczeństwo - wyświetlanie nazw portów (http, https, ssh) zamiast numerów może maskować niestandardowe użycie portów. Na przykład ruch na porcie 80, który nie jest HTTP, zostanie oznaczony jako http, co może wprowadzić w błąd podczas analizy bezpieczeństwa. Dlatego w środowisku produkcyjnym zawsze zaleca się używanie -nn.

Poziomy szczegółowości tcpdump (-v, -vv, -vvv) dodają kolejne warstwy informacji do standardowego wyjścia. Przełącznik -v dodaje pole TTL (Time To Live), całkowitą długość pakietu (total length) oraz pole ID fragmentacji IP. Te informacje są przydatne przy diagnozowaniu problemów z routowaniem - gwałtowny spadek TTL może wskazywać na pętlę routingu.

Przełącznik -vv dodaje szczegóły TCP, takie jak opcje okna (window scaling), znaczniki czasu TCP (timestamps), selektywne potwierdzenia (SACK) oraz informacje o negocjacji MSS. Maksymalny poziom -vvv jest rzadko używany w praktyce, ponieważ dodaje szczegóły przydatne głównie twórcom stosów TCP/IP i osobom debugującym implementacje protokołów na poziomie kodu źródłowego.

Adresy MAC (Media Access Control) są unikalnymi identyfikatorami przypisanymi do interfejsów sieciowych na poziomie warstwy łącza danych (warstwa 2 modelu OSI). Opcja -e w tcpdump wyświetla nagłówek ramki Ethernet, który zawiera adres MAC źródła (source), adres MAC celu (destination) oraz pole EtherType identyfikujące protokół warstwy sieciowej.

Analiza adresów MAC jest niezbędna w diagnostyce ataków ARP spoofing, gdzie atakujący podszywa się pod adres MAC bramy domyślnej, przechwytując ruch sieciowy. Porównanie adresu MAC bramy w tablicy ARP z faktycznym adresem w przechwyconej ramce pozwala na szybkie wykrycie tego typu ataku. Ponadto opcja -e jest przydatna przy analizie ruchu w sieciach z mostami i przełącznikami warstwy 2.

Tryb cichej pracy -q (quiet) redukuje ilość wyświetlanych informacji do absolutnego minimum, pokazując jedynie znacznik czasu, informację o protokole, adresy źródła i celu oraz typ i długość danych TCP. Jest to przydatne w sytuacjach, gdy interesuje nas jedynie fakt wystąpienia pakietu, a nie jego szczegółowa struktura.

Opcja -q jest często łączona z -c do szybkiego zliczania pakietów spełniających dany filtr. Na przykład polecenie tcpdump -i eth0 -c 100 -q -nn port 80 wyświetli skrócone informacje o stu pakietach HTTP, co pozwala na szybkie sprawdzenie, czy ruch na porcie 80 faktycznie występuje, bez szczegółowej analizy każdego pakietu.

Opcja -x wyświetla zawartość pakietu w formacie szesnastkowym (hexadecymalnym), co pozwala na analizę surowych danych bez interpretacji przez tcpdump. Domyślnie wyświetlane są dane od początku nagłówka IPv4, czyli bez nagłówka Ethernet. Każda linia hex dump składa się z offsetu (0x0000, 0x0010 itd.) oraz 16 bajtów danych w zapisie szesnastkowym.

Hex dump jest niezbędny do analizy protokołów, których tcpdump nie potrafi zinterpretować, oraz do weryfikacji poprawności implementacji protokołów. Na przykład można zweryfikować, czy pole TTL w nagłówku IP ma oczekiwaną wartość, odczytując bajt na pozycji 8 w nagłówku IP (pierwszy bajt hex dumpa po nagłówku IP). W połączeniu ze znajomością struktury nagłówków sieciowych daje to pełną kontrolę nad analizą.

Opcja -XX różni się od -x tym, że wyświetla hex dump łącznie z nagłówkiem Ethernet, czyli pierwszych 14 bajtów ramki zawierających adresy MAC i pole EtherType. Jest to przydatne w sytuacjach, gdy chcemy przeanalizować pełną ramkę od warstwy 2 w górę, na przykład przy diagnostyce protokołu ARP, który działa bezpośrednio na warstwie łącza danych.

Dodatkowe informacje widoczne w -XX pozwalają na identyfikację typu ramki Ethernet (EtherType 0x0800 dla IPv4, 0x86DD dla IPv6, 0x0806 dla ARP, 0x8100 dla VLAN 802.1Q) bez polegania na interpretacji tcpdump. Jest to szczególnie ważne w przypadku ramek z tagami VLAN lub MPLS, gdzie standardowe wyjście tcpdump może nie pokazywać wszystkich informacji.

Opcja -A (ASCII dump) konwertuje binarną zawartość pakietu na drukowalne znaki ASCII, co pozwala na szybki podgląd treści przesyłanych w ramach protokołów tekstowych, takich jak HTTP, SMTP, POP3, FTP czy DNS. Znaki niedrukowalne są zastępowane kropkami, podobnie jak w narzędziu strings, co ułatwia identyfikację fragmentów tekstu w strumieniu binarnym.

W praktyce -A jest często używane do szybkiej weryfikacji treści żądań HTTP bez konieczności otwierania pliku pcap w Wireshark. Na przykład polecenie tcpdump -i eth0 port 80 -A -c 1 pozwala zobaczyć pierwsze żądanie HTTP przechodzące przez interfejs. Należy jednak pamiętać, że w dzisiejszych czasach większość ruchu HTTP jest szyfrowana (HTTPS, port 443), gdzie -A pokaże jedynie nieczytelne, zaszyfrowane dane.

Parametr snaplen (-s) określa maksymalną liczbę bajtów przechwytywanych z każdego pakietu. Domyślna wartość 262144 bajtów (256 KiB) jest w praktyce równoważna przechwytywaniu całego pakietu, ponieważ maksymalny rozmiar pakietu Ethernet (MTU 1500) jest znacznie mniejszy. Jednak w przypadku Jumbo Frames (MTU do 9000 bajtów) warto zachować domyślny snaplen dla przechwytywania pełnych pakietów.

Zmniejszenie snaplen ma bezpośrednie przełożenie na wydajność i rozmiar plików pcap. Dla analizy nagłówków (adresy IP, porty, flagi TCP, TTL) wystarczy przechwycić pierwsze 96 bajtów pakietu, co odpowiada typowemu nagłówkowi Ethernet (14 B) + IPv4 (20 B) + TCP (20-40 B). Plik pcap z snaplen 96 B będzie około 15-20 razy mniejszy niż z pełnym przechwytywaniem, co ma znaczenie przy długotrwałym monitoringu.

Zapis do pliku pcap z użyciem opcji -w jest podstawową metodą przechowywania przechwyconego ruchu do późniejszej analizy. Format pcap (Packet Capture) jest standardem de facto w branży sieciowej i jest obsługiwany przez setki narzędzi, w tym Wireshark, tshark, Snort, Suricata i wiele innych. Pliki pcap przechowują nie tylko pakiety, ale także znaczniki czasu z dokładnością do mikrosekund.

Przy zapisie do pliku warto od razu zastosować odpowiedni filtr przechwytywania, aby nie zapełnić dysku niepotrzebnymi danymi. Na przykład przy monitorowaniu tylko ruchu HTTP użyjemy tcpdump -i eth0 port 80 -w http.pcap. W środowiskach o dużym natężeniu ruchu (powyżej 1 Gb/s) zaleca się zapis na oddzielny dysk SSD lub RAID, aby zapis nie był wąskim gardłem powodującym utratę pakietów.

Analiza offline z użyciem opcji -r jest jedną z najważniejszych funkcji tcpdump, ponieważ umożliwia szczegółowe badanie wcześniej przechwyconego ruchu bez konieczności dostępu do sieci produkcyjnej. Podczas odczytu pliku pcap można stosować te same opcje co przy przechwytywaniu na żywo (-n, -nn, -x, -X, -A, -e, -v), co pozwala na dynamiczne dostosowanie widoku do potrzeb analizy.

Szczególnie przydatna jest możliwość stosowania filtrów BPF podczas odczytu pliku - tcpdump przetwarza tylko te pakiety, które spełniają warunek filtra, co znacznie przyspiesza analizę dużych plików. Na przykład tcpdump -r ogromny.pcap host 10.0.0.1 and port 443 wyodrębni tylko pakiety HTTPS związane z konkretnym hostem, bez konieczności przeglądania całego pliku.

Opcja -C umożliwia dzielenie plików wyjściowych na fragmenty o ograniczonym rozmiarze, co jest niezbędne przy długotrwałym monitorowaniu sieci o dużym natężeniu ruchu. Każdy fragment otrzymuje numer porządkowy (plik.pcap0, plik.pcap1, itd.), a po osiągnięciu maksymalnej liczby plików określonej przez -W najstarszy fragment jest nadpisywany, tworząc bufor cykliczny (ring buffer).

Ring buffer jest szczególnie przydatny w scenariuszach, gdzie interesuje nas tylko najnowszy ruch (np. ostatnia godzina), a starsze dane mogą być bezpiecznie nadpisane. Pozwala to na monitorowanie sieci przez tygodnie lub miesiące bez ryzyka zapełnienia dysku. Dla zwiększenia bezpieczeństwa danych można skopiować każdy zamknięty fragment przed jego nadpisaniem, używając opcji -z z własnym skryptem.

Parametr -W ściśle współpracuje z opcjami -C i -G, określając liczbę plików w buforze cyklicznym. W połączeniu z -C (podział według rozmiaru) pozwala na precyzyjne kontrolowanie maksymalnej ilości danych zajmowanych przez pliki pcap na dysku. Na przykład -C 100 -W 10 tworzy bufor o maksymalnym rozmiarze 1 GB (10 plików po 100 MB).

W połączeniu z -G (rotacja czasowa) opcja -W określa liczbę plików, które zostaną utworzone przed rozpoczęciem nadpisywania. Na przykład -G 3600 -W 24 stworzy 24 pliki godzinowe, po czym najstarszy zostanie nadpisany, co daje bufor 24 godzin ruchu. Należy starannie dobrać parametry bufora do dostępnej przestrzeni dyskowej i spodziewanego natężenia ruchu, aby uniknąć sytuacji, w której pliki są nadpisywane zbyt szybko.

Opcja -G z parametrem czasowym umożliwia tworzenie nowych plików pcap w regularnych odstępach czasu, co jest szczególnie przydatne do długoterminowego monitorowania z podziałem na przedziały czasowe. Znaczniki strftime w nazwie pliku pozwalają na tworzenie czytelnych nazw zawierających datę i godzinę rozpoczęcia przechwytywania, co ułatwia późniejsze wyszukiwanie odpowiedniego fragmentu.

Najczęściej używane znaczniki to %Y (rok czterocyfrowy), %m (miesiąc 01-12), %d (dzień 01-31), %H (godzina 00-23), %M (minuty) i %S (sekundy). Przykładowo wzorzec log_%Y%m%d_%H%M%S.pcap wygeneruje nazwę typu log_20260115_100000.pcap dla pliku rozpoczętego 15 stycznia 2026 o godzinie 10:00:00. W systemie Linux znaczniki są interpretowane przez funkcję strftime, która obsługuje pełen zestaw specyfikatorów zgodnych ze standardem POSIX.

Opcja -z uruchamia zewnętrzny program kompresji po zamknięciu każdego pliku pcap, co pozwala na automatyczne zmniejszenie wykorzystania miejsca na dysku bez ręcznej interwencji. Najczęściej używane kompresory to gzip (szybki, dobra kompresja), bzip2 (wolniejszy, lepsza kompresja) i xz (najwolniejszy, najlepsza kompresja, wymaga pakietu xz-utils).

W praktyce kompresja gzip zmniejsza rozmiar plików pcap o 50-80% w zależności od charakteru ruchu. Ruch zawierający dużo powtarzalnych nagłówków (np. samo przechwytywanie nagłówków TCP) kompresuje się lepiej niż ruch z losowym payloadem. Można również użyć własnego skryptu jako kompresora, na przykład do szyfrowania plików przed zapisem lub do przesyłania ich do zdalnego magazynu danych.

Bufor jądra PF_PACKET to pamięć w przestrzeni jądra systemu operacyjnego, w której przechowywane są pakiety oczekujące na odczyt przez tcpdump. Domyślny rozmiar bufora w Linux wynosi 2048 KiB (2 MiB), co w przypadku ruchu o dużym natężeniu może okazać się niewystarczające. Gdy bufor się przepełni, nowe pakiety są odrzucane (kernel drop), co jest sygnalizowane w statystykach końcowych tcpdump.

Zwiększenie rozmiaru bufora przez -B 4096 (4 MiB) lub -B 8192 (8 MiB) może znacząco zmniejszyć liczbę gubionych pakietów. Należy jednak pamiętać, że maksymalny rozmiar bufora jest ograniczony przez parametr jądra net.core.rmem_max, który można sprawdzić poleceniem sysctl net.core.rmem_max i zwiększyć przez sysctl -w net.core.rmem_max=16777216, jeśli wymagany jest bufor 16 MiB.

Berkeley Packet Filter (BPF) to technologia filtrowania pakietów działająca w przestrzeni jądra systemu operacyjnego, która umożliwia odrzucanie niepotrzebnych pakietów jeszcze przed przekazaniem ich do przestrzeni użytkownika. Dzięki temu tcpdump otrzymuje tylko te pakiety, które spełniają zdefiniowane kryteria, co znacząco zmniejsza obciążenie procesora i zapotrzebowanie na pamięć.

Składnia BPF w tcpdump opiera się na prymitywach, takich jak host, net, port, src, dst, nazwach protokołów (tcp, udp, icmp, arp, ip6) oraz operatorach logicznych (and, or, not). Prymitywy mogą być łączone w złożone wyrażenia z użyciem nawiasów do grupowania warunków. Wyrażenia BPF są kompilowane do kodu maszynowego maszyny wirtualnej BPF, który jest wykonywany bezpośrednio w jądrze systemu dla każdego pakietu.

Port 80 to jeden z najczęściej monitorowanych portów w sieciach TCP/IP - jest to domyślny port protokołu HTTP. Użycie filtra port 80 w tcpdump przechwytuje wszystkie pakiety TCP, których port źródłowy lub docelowy wynosi 80. W nowoczesnych sieciach coraz więcej ruchu HTTP jest przekierowywane na HTTPS (port 443), dlatego często monitoruje się oba porty jednocześnie: port 80 or port 443.

Rozróżnienie kierunku ruchu (src port 80 vs dst port 80) pozwala na selektywne przechwytywanie odpowiedzi serwera (źródłowy port 80) lub żądań klienta (docelowy port 80). Jest to szczególnie przydatne przy analizie wydajności - opóźnienia po stronie serwera są widoczne w pakietach z źródłowym portem 80, podczas gdy opóźnienia sieciowe dotyczą obu kierunków.

Filtr host jest jednym z najczęściej używanych prymitywów BPF, umożliwiającym ograniczenie przechwytywania do ruchu związanego z konkretnym adresem IP. Słowo host jest domyślne w składni BPF, co oznacza, że można je pominąć - tcpdump 192.168.1.1 jest równoważne tcpdump host 192.168.1.1. Filtr dotyczy zarówno pakietów przychodzących, jak i wychodzących względem podanego hosta.

Dodanie kwalifikatorów src i dst pozwala na precyzyjne określenie kierunku ruchu. Na przykład src host 192.168.1.1 przechwytuje tylko pakiety wysłane przez tego hosta, a dst host 192.168.1.1 tylko pakiety do niego adresowane. Jest to przydatne przy diagnozowaniu asymetrycznych problemów sieciowych, na przykład gdy host wysyła pakiety, ale nie otrzymuje odpowiedzi.

Filtr z użyciem dwóch prymitywów host połączonych operatorem and pozwala na ograniczenie przechwytywania do ruchu wymienianego wyłącznie między dwoma konkretnymi hostami. Jest to szczególnie przydatne w diagnostyce problemów komunikacji między dwoma serwerami, na przykład między serwerem aplikacji a serwerem bazy danych.

Należy rozumieć semantykę tego filtra: przechwyci on pakiety, gdzie 10.0.0.1 jest źródłem, a 10.0.0.2 celem LUB 10.0.0.1 jest celem, a 10.0.0.2 źródłem. Innymi słowy, oba adresy muszą wystąpić w pakiecie (jako źródło i cel), ale nie jest ważne, który jest którym. Filtr nie przechwyci jednak pakietów, gdzie któryś z tych adresów w ogóle nie występuje.

Prymityw net z notacją CIDR (Classless Inter-Domain Routing) umożliwia filtrowanie ruchu całych podsieci za pomocą jednego wyrażenia. Notacja 192.168.0.0/24 oznacza adres sieci 192.168.0.0 z maską podsieci 255.255.255.0 (24 bity). Jest to bardziej elastyczne niż tradycyjne klasy adresów IP (A, B, C) i pozwala na precyzyjne definiowanie zakresów adresów.

Filtry sieciowe są szczególnie przydatne w sieciach z wieloma podsieciami VLAN, gdzie chcemy monitorować ruch między wybranymi segmentami. Na przykład filtr net 192.168.0.0/24 and net 10.0.0.0/8 przechwyci pakiety przesyłane między tymi dwiema podsieciami, ignorując ruch wewnątrz każdej z nich oraz ruch do innych sieci. W starszych systemach można użyć składni z maską: net 192.168.0.0 mask 255.255.255.0.

ICMP (Internet Control Message Protocol) to protokół warstwy sieciowej używany do diagnostyki i raportowania błędów. Najbardziej znanym zastosowaniem ICMP jest narzędzie ping (Echo Request/Reply), ale protokół ten obsługuje również komunikaty Destination Unreachable, Time Exceeded (używany przez traceroute), Redirect oraz Parameter Problem.

ARP (Address Resolution Protocol) działa na warstwie łącza danych i służy do mapowania adresów IP na adresy MAC. Do poprawnej analizy ARP w tcpdump wymagana jest opcja -e, ponieważ ARP nie zawiera nagłówka IP i cała informacja o adresach MAC znajduje się w nagłówku Ethernet. Protokół ARP jest szczególnie podatny na ataki ARP spoofing, dlatego jego monitoring jest ważny z punktu widzenia bezpieczeństwa sieci lokalnych.

Filtrowanie flag TCP na poziomie surowych bajtów (tcp[13]) jest przykładem zaawansowanej możliwości BPF, która daje pełną kontrolę nad wyborem pakietów. Bajt 13 w nagłówku TCP zawiera pole Flags (NS, CWR, ECE, URG, ACK, PSH, RST, SYN, FIN), gdzie każda flaga jest reprezentowana przez jeden bit. Wartość 2 odpowiada fladze SYN (bit 1 licząc od 0).

Wyrażenie tcp[13] & 2 != 0 wykonuje bitową operację AND między wartością bajtu 13 a maską 2 (00000010 w binarnym). Jeśli wynik jest różny od zera, oznacza to, że flaga SYN jest ustawiona. Jest to standardowa technika używana w systemach IDS/IPS do wykrywania skanowania portów (SYN scan, half-open scan), gdzie atakujący wysyła pakiety SYN i analizuje odpowiedzi SYN-ACK lub RST.

Operator not (lub !) w składni BPF umożliwia wykluczenie pakietów spełniających określony warunek, co jest często używane do odfiltrowania nieinteresującego ruchu tła. Na przykład podczas monitorowania ruchu HTTP chcemy wykluczyć ruch generowany przez własne skrypty monitorujące, aby nie zafałszowywać wyników.

Wykluczanie własnego ruchu SSH (port 22) jest szczególnie ważne podczas zdalnej diagnostyki przez SSH - bez wykluczenia sesja diagnostyczna będzie generować pakiety, które zostaną przechwycone, tworząc pętlę sprzężenia zwrotnego. Podobnie podczas przechwytywania na serwerze produkcyjnym warto wykluczyć ruch monitoringu (SNMP, NetFlow), aby skoncentrować się na diagnozowanym problemie.

Składnia proto[offset:length] w BPF pozwala na odczytanie dowolnego bajtu lub grupy bajtów w pakiecie, co daje niemal nieograniczone możliwości filtrowania. Na przykład ether[12:2] odczytuje dwa bajty na offsetcie 12 w ramce Ethernet, co odpowiada polu EtherType. Wartość 0x0800 oznacza IPv4, 0x86DD oznacza IPv6, a 0x0806 oznacza ARP.

Filtrowanie według TTL (Time To Live) w nagłówku IP za pomocą wyrażenia ip[8] <= 10 pozwala na wykrywanie pakietów, które przebyły długą trasę (mała wartość TTL) lub prób skanowania sieci z użyciem pakietów o niskim TTL. Podobnie ip[9] = 6 wybiera tylko pakiety z protokołem TCP (wartość 6), co jest równoważne prostszemu filtrowi tcp, ale daje większą kontrolę w przypadku niestandardowych protokołów.

Operatory logiczne w BPF (and, or, not) umożliwiają tworzenie złożonych wyrażeń filtrujących poprzez łączenie prymitywów w hierarchiczne struktury. Nawiasy okrągłe służą do grupowania warunków i określania kolejności ich ewaluacji, co jest niezbędne przy bardziej skomplikowanych filtrach. Na przykład filtr host 10.0.0.1 and (port 80 or port 443) przechwyci ruch HTTP lub HTTPS związany z konkretnym hostem.

Pomimo że BPF obsługuje zarówno składnię słowną (and, or, not), jak i symboliczną (&&, ||, !), zaleca się używanie wersji słownej w tcpdump z kilku powodów: jest czytelniejsza dla osób niezaznajomionych z programowaniem, unika konfliktów z metaznakami powłoki (znaki & i ! są interpretowane przez bash) oraz jest zgodna ze składnią używaną w innych narzędziach (na przykład w Wireshark wyrażenia wyświetlania używają and/or/not).

Tagowanie VLAN zgodne ze standardem IEEE 802.1Q polega na dodaniu do ramki Ethernet czterobajtowego nagłówka zawierającego identyfikator VLAN (12 bitów, wartości 1-4094) oraz pole priorytetu (3 bity zgodne z IEEE 802.1p). Filtr vlan w tcpdump dopasowuje wszystkie ramki zawierające tag 802.1Q (EtherType 0x8100).

Składnia filtrowania VLAN ID w tcpdump jest prosta: vlan 100 oznacza ramki z tagiem 802.1Q o identyfikatorze VLAN 100. Słowo kluczowe vlan zmienia offset w filtrze BPF, aby kolejne wyrażenia odnosiły się do pakietu wewnątrz ramki VLAN. W przypadku podwójnego tagowania QinQ (802.1ad) stosuje się dwukrotne vlan: vlan and vlan.

IPv6 używa odrębnego prymitywu ip6 (nie ip) w składni BPF, ponieważ nagłówek IPv6 ma zupełnie inną strukturę niż IPv4. W IPv6 adresy mają długość 128 bitów (16 bajtów), a routing opiera się na adresacji hierarchicznej z prefiksami sieci. Filtr ip6 przechwytuje wszystkie pakiety IPv6, zarówno z adresami unicast, multicast, jak i anycast.

ICMPv6 (kontrolowany przez icmp6) pełni w IPv6 więcej funkcji niż ICMPv4 - oprócz diagnostyki (ping6) odpowiada za Neighbor Discovery (NDP) - odpowiednik ARP dla IPv6, autokonfigurację adresów (SLAAC) oraz wykrywanie duplikacji adresów (DAD). MPLS (Multiprotocol Label Switching) to technologia przekazywania pakietów oparta na etykietach, która w tcpdump jest filtrowana przez prymityw mpls z opcjonalnym warunkiem na konkretną etykietę.

Każda linia wyjścia tcpdump składa się z kilku obowiązkowych i opcjonalnych pól, których zrozumienie jest kluczowe dla poprawnej interpretacji przechwyconego ruchu. Znacznik czasu ma domyślnie format HH:MM:SS.mikrosekundy, ale może być modyfikowany opcjami -t, -tt, -ttt, -tttt, -ttttt. Protokół warstwy 3 (IP, IP6, ARP) określa typ nagłówka sieciowego.

Flagi TCP są wyświetlane w nawiasach kwadratowych po dwukropku. Najczęściej spotykane kombinacje to [S] (SYN - rozpoczęcie połączenia), [S.] (SYN-ACK - potwierdzenie SYN), [.] (ACK - potwierdzenie danych), [F.] (FIN-ACK - zakończenie połączenia) oraz [R] (RST - reset połączenia). Flagi złożone, takie jak [FP.] (FIN+PSH+ACK), występują w przypadku wysłania danych wraz z żądaniem zamknięcia połączenia. Pole length wskazuje liczbę bajtów danych w pakiecie, nie licząc nagłówków.

Znaczniki czasu w tcpdump są pobierane z zegara systemowego z dokładnością do mikrosekund (domyślnie) lub nanosekund (przy użyciu nowszych wersji libpcap z odpowiednim wsparciem sprzętowym). W systemie Linux dokładność znaczników zależy od użytego źródła czasu - jądro może używać TSC (Time Stamp Counter), HPET (High Precision Event Timer) lub ACPI PM timer.

Opcja -tttt wyświetlająca pełną datę i czas w formacie YYYY-MM-DD HH:MM:SS.mikrosekundy jest szczególnie przydatna podczas analizy plików pcap obejmujących dłuższy okres, ponieważ pozwala na szybką orientację w chronologii zdarzeń. Opcja -ttt (delta od poprzedniego pakietu) jest przydatna do analizy odstępów między pakietami, na przykład w diagnostyce retransmisji TCP, gdzie typowe odstępy czasu są wykładniczo zwiększane zgodnie z algorytmem backoff.

Wybór między monitoringiem na żywo a analizą offline zależy od konkretnego scenariusza diagnostycznego. Przechwytywanie na żywo wymaga uprawnień root i dostępu do interfejsu sieciowego, co na serwerach produkcyjnych może być problematyczne ze względów bezpieczeństwa. Ponadto analiza w czasie rzeczywistym w terminalu jest ograniczona przez szybkość przewijania ekranu i możliwości percepcyjne człowieka.

Analiza offline z pliku pcap nie wymaga uprawnień root (tylko prawa odczytu pliku), pozwala na wielokrotne przeglądanie tych samych danych z różnymi filtrami i poziomami szczegółowości oraz umożliwia zastosowanie zaawansowanych narzędzi, takich jak Wireshark, do analizy graficznej i statystycznej. Dlatego standardowym podejściem jest zapis do pliku na serwerze, przeniesienie pliku na stację roboczą i szczegółowa analiza w Wireshark.

Tryb monitor w sieciach bezprzewodowych (802.11) umożliwia przechwytywanie wszystkich ramek w zasięgu karty, nie tylko tych adresowanych do naszego interfejsu. W trybie managed (domyślnym) karta Wi-Fi odbiera tylko ramki przeznaczone dla siebie, podczas gdy w trybie monitor odbiera wszystkie ramki, w tym ramki zarządzające (Beacon, Probe Request/Response, Association), które są kluczowe dla analizy działania sieci WLAN.

Ramki Beacon są rozgłaszane okresowo przez punkt dostępowy (Access Point) i zawierają informacje o SSID, obsługiwanych szybkościach, możliwościach bezpieczeństwa oraz parametrach warstwy fizycznej. Ramki Probe Request są wysyłane przez klienty w celu wykrycia dostępnych sieci, a Probe Response to odpowiedź AP zawierająca szczegółowe informacje o sieci. Analiza tych ramek pozwala na diagnostykę problemów z zasięgiem, roamingu i kompatybilnością.

Zestaw narzędzi Wireshark (dawniej nazywany Ethereal) zawiera kilkanaście programów pomocniczych do pracy z plikami pcap, które są niezastąpione w codziennej pracy analityka sieciowego. mergecap łączy wiele plików pcap w jeden, co jest przydatne przy składaniu ruchu z różnych źródeł (na przykład z obu stron łącza WAN). editcap pozwala na przycinanie plików, wyodrębnianie zakresów pakietów oraz konwersję między formatami pcap i pcapng.

capinfos wyświetla szczegółowe informacje o pliku pcap: liczbę pakietów, czas trwania przechwycenia, średnią szybkość w pakietach na sekundę, rozmiar pliku i typ enkapsulacji (Ethernet, 802.11, Linux SLL itp.). ngrep (network grep) pozwala na wyszukiwanie wzorców tekstowych w plikach pcap z użyciem wyrażeń regularnych, podobnie jak grep dla plików tekstowych, ale z uwzględnieniem struktury pakietów sieciowych.

Połączenie tcpdump (lekki, zdalny) z Wireshark (bogaty GUI) tworzy optymalny proces diagnostyczny dla administratorów sieci. Na serwerze bez interfejsu graficznego tcpdump zużywa minimalne zasoby i nie wymaga instalacji dużych pakietów. Plik pcap jest następnie transferowany przez SCP, SFTP lub rsync na stację roboczą, gdzie Wireshark zapewnia zaawansowane możliwości analizy.

Możliwe jest również strumieniowanie przechwyconego ruchu bezpośrednio przez SSH do Wireshark, co pozwala na analizę na żywo bez zapisu na dysku serwera. Polecenie ssh user@server "sudo tcpdump -i eth0 -c 1000 -w -" | wireshark -k -i - przesyła pakiety przez strumień wyjścia SSH i wyświetla je w Wireshark na bieżąco. Jest to przydatne przy szybkiej diagnostyce, ale wymaga stabilnego i szybkiego połączenia sieciowego.

Python z biblioteką Scapy oferuje programistyczną analizę plików pcap z pełną kontrolą nad logiką przetwarzania. Scapy pozwala nie tylko na odczyt pakietów, ale także na ich modyfikację, tworzenie nowych pakietów i wysyłanie ich do sieci, co czyni go potężnym narzędziem do testowania i prototypowania rozwiązań sieciowych. Instalacja scapy wymaga jedynie pip install scapy, a biblioteka jest dostępna dla Python 3.

Alternatywą dla Scapy jest biblioteka pyshark, która wykorzystuje tshark (interfejs wiersza poleceń Wireshark) do parsowania pakietów i udostępnia wyniki w formie obiektów Python. Pyshark jest wygodniejszy dla standardowych analiz, ponieważ automatycznie dekoduje protokoły zgodnie z dyssektorami Wireshark, ale jest wolniejszy niż Scapy. Dla analiz wymagających maksymalnej wydajności istnieje biblioteka dpkt, która jest minimalistyczna i nie zawiera żadnych funkcji pomocniczych.

Wybór odpowiedniego narzędzia do przechwytywania zależy od konkretnych wymagań: na zasobooszczędnym serwerze brzegowym czy w kontenerze Docker najlepiej sprawdzi się tcpdump ze względu na minimalny rozmiar (około 500 KB) i niskie zużycie CPU. dumpcap, dostarczany z pakietem Wireshark, oferuje podobną wydajność przy mniejszym rozmiarze niż pełny tshark i obsługuje więcej formatów plików oraz wiele interfejsów jednocześnie.

tshark, będący CLI Wireshark, jest najpotężniejszym z tych trzech narzędzi pod względem możliwości analitycznych, ale jego rozmiar (około 10 MB) i zużycie pamięci są znacznie wyższe. tshark obsługuje display filtry identyczne z Wireshark, co umożliwia płynne przejście z analizy terminalowej do graficznej. W praktyce często stosuje się hybrydowe podejście: dumpcap do przechwytywania na słabszych maszynach, tshark do automatycznej analizy w skryptach, a Wireshark do szczegółowej analizy manualnej.

Statystyki końcowe tcpdump pokazują trzy liczniki: packets captured (pakiety przechwycone i przekazane do tcpdump), packets received by filter (pakiety odebrane przez filtr jądra BPF) oraz packets dropped by kernel (pakiety odrzucone z powodu przepełnienia bufora jądra). Jeśli trzeci licznik jest znacząco różny od zera (powyżej 1%), oznacza to, że system nie nadąża z przetwarzaniem ruchu i wyniki mogą być niekompletne.

Przyczyny dropów mogą być różne: zbyt mały bufor jądra (rozwiązanie: zwiększenie -B), zbyt wolny zapis na dysk (rozwiązanie: użycie szybszego dysku lub zapis do pamięci RAM), zbyt złożony filtr BPF (rozwiązanie: uproszczenie filtra) lub ogólne przeciążenie systemu. W środowiskach o bardzo dużym natężeniu ruchu (powyżej 10 Gb/s) zaleca się stosowanie PF_RING lub AF_PACKET z opcją PACKET_MMAP (memory-mapped packet socket) dla osiągnięcia wyższej wydajności.

Przechwytywanie pakietów w kontenerach Docker wymaga odpowiednich uprawnień, ponieważ domyślnie kontenery działają z ograniczonymi capability. Opcja --privileged daje wszystkie uprawnienia, w tym dostęp do surowych gniazd sieciowych, ale jest najmniej bezpieczna. Bardziej precyzyjnym rozwiązaniem jest dodanie tylko niezbędnych capability: CAP_NET_RAW (dostęp do PF_PACKET) i CAP_NET_ADMIN (zarządzanie interfejsami, tryb promiscuous).

Obraz nicolaka/netshoot jest specjalnie przygotowanym zestawem narzędzi sieciowych dla Kubernetes i Docker, zawierającym tcpdump, tshark, iperf3, nmap, curl, dig i wiele innych. nsenter umożliwia wykonanie polecenia w przestrzeni nazw sieci innego procesu, co pozwala na przechwytywanie ruchu z poziomu hosta dla konkretnego kontenera bez instalowania tcpdump w kontenerze. W Kubernetes można użyć narzędzia kubectl sniff, które automatyzuje ten proces.

Na routerach Cisco diagnostyka ruchu sieciowego odbywa się za pomocą polecenia monitor capture, które jest dostępne w nowszych wersjach IOS (12.2(33) i nowsze) oraz IOS-XE. Stare polecenie debug ip packet (oraz debug ip icmp, debug ip tcp) może generować ogromną ilość danych i obciążać CPU routera, dlatego należy je stosować z dużą ostrożnością i tylko na małym ruchu lub z filtrami ACL.

RouterOS firmy MikroTik oferuje wbudowany sniffer (/tool sniffer) z przyjaznym interfejsem terminalowym i opcjami filtrowania według interfejsu, protokołu, adresów IP i portów. Sniffer MikroTik umożliwia również zapis przechwyconych pakietów do pliku w formacie pcap, który można następnie otworzyć w Wireshark. W systemach Linux pełniących rolę routera tcpdump może być używany bezpośrednio na każdym interfejsie, co daje maksymalną elastyczność.

Analiza retransmisji TCP jest kluczowym elementem diagnostyki wydajności sieci. TCP retransmituje pakiety, gdy nie otrzyma potwierdzenia (ACK) w określonym czasie (RTO - Retransmission Timeout). Wysoki poziom retransmisji (powyżej 2-3%) wskazuje na problem z łączem: utratę pakietów, zbyt małe okno TCP, przeciążenie buforów na trasie lub szumy w medium transmisyjnym.

W praktyce do analizy retransmisji warto użyć Wireshark z filtrem wyświetlania tcp.analysis.retransmission lub tcp.analysis.fast_retransmission, który automatycznie identyfikuje retransmitowane pakiety. Z tcpdump można użyć filtra tcp[13] & 0x10 = 0x10 do wyodrębnienia pakietów z flagą ACK i analizy sekwencji, ale nie jest to tak precyzyjne jak dyssektor Wireshark. Duplikaty ACK (tcp.analysis.duplicate_ack) wskazują na utratę pakietów i wywołanie mechanizmu Fast Retransmit.

Atak ICMP flood (ping flood) polega na wysłaniu bardzo dużej liczby pakietów ICMP Echo Request do ofiary w celu przeciążenia jej łącza lub procesora. Pojedynczy atakujący może wygenerować dziesiątki tysięcy pakietów na sekundę, a w przypadku ataku rozproszonego (DDoS) liczba ta może sięgać milionów. Objawy ataku to gwałtowny wzrost wykorzystania pasma, wysoka utrata pakietów i spadek wydajności usług sieciowych.

Do obrony przed atakami ICMP flood stosuje się ograniczenie szybkości (rate limiting) na firewallu za pomocą iptables z modułem limit, jak pokazano na slajdzie. Można również całkowicie zablokować ICMP Echo Request, ale należy pamiętać, że ICMP pełni ważne funkcje diagnostyczne i jego blokada utrudnia zarządzanie siecią. Nowoczesne systemy IDS/IPS (Snort, Suricata) automatycznie wykrywają i blokują ataki flood na podstawie analizy liczby pakietów na sekundę z jednego źródła.

Protokół DHCP (Dynamic Host Configuration Protocol) automatyzuje przydzielanie adresów IP i innych parametrów konfiguracyjnych (maska podsieci, brama domyślna, serwery DNS) urządzeniom w sieci. Czterofazowa wymiana (DORA: Discover, Offer, Request, Acknowledge) może być w pełni przechwycona przez tcpdump, ponieważ pierwsze trzy fazy są wysyłane jako broadcast przed uzyskaniem adresu IP przez klienta.

W praktyce diagnostycznej brak odpowiedzi DHCP Offer po Discover może wskazywać na: brak serwera DHCP w sieci, wyczerpanie puli adresów, blokadę portów 67/68 na firewallu lub przełączniku (DHCP snooping), błędną konfigurację relay agenta DHCP (IP Helper) w sieciach z VLAN-ami. Opcja -e w tcpdump jest niezbędna przy analizie DHCP, ponieważ klient nie ma jeszcze adresu IP i komunikacja odbywa się wyłącznie na poziomie adresów MAC i broadcastu warstwy 2.

Definiowanie aliasów w plikach konfiguracyjnych powłoki (~/.bashrc, ~/.zshrc, ~/.bash_aliases) znacząco przyspiesza codzienną pracę z tcpdump poprzez redukcję długości wpisywanych poleceń. Aliasy można organizować według funkcji: td dla standardowego przechwytywania z -nn, tdx dla hex dumpa, tdw dla zapisu do pliku, tdr dla odczytu pliku oraz aliasy dla konkretnych protokołów (tdhttp, tddns, tdicmp).

Bardziej zaawansowaną formą aliasów są funkcje powłoki, które mogą przyjmować parametry. Przykładowa funkcja td() { sudo tcpdump -i eth0 -nn "$@"; } pozwala na wywołanie td port 80 lub td host 10.0.0.1, co automatycznie dodaje standardowe opcje. W środowiskach produkcyjnych warto również dodać aliasy uruchamiające tcpdump z wykluczeniem własnego ruchu SSH, aby uniknąć zapętlania podczas sesji zdalnej.

Tabela podsumowująca najważniejsze opcje tcpdump stanowi szybką ściągawkę (cheat sheet) dla administratorów sieci. Opcja -i (interfejs) jest niezbędna do rozpoczęcia pracy, a -n/-nn powinny być domyślnie używane dla zwiększenia wydajności i bezpieczeństwa. Opcje -w i -r odpowiadają za podstawowe operacje wejścia-wyjścia, a -c chroni przed przypadkowym przechwyceniem zbyt dużej ilości danych.

Opcje -C i -W są kluczowe dla długoterminowego monitorowania z ograniczoną przestrzenią dyskową, podczas gdy -s pozwala na kontrolę nad ilością przechwytywanych danych z każdego pakietu. Opcje -e, -X, -XX i -A umożliwiają różne poziomy szczegółowości wyjścia, od podstawowej analizy nagłówków po pełny hex dump. Znajomość tych opcji i umiejętność ich łączenia stanowi podstawę efektywnej pracy z tcpdump.

Dobre praktyki w pracy z tcpdump wynikają z wieloletniego doświadczenia administratorów sieci i inżynierów bezpieczeństwa. Zawsze używaj -nn, aby uniknąć opóźnień DNS i maskowania rzeczywistych adresów oraz portów. Stosuj capture filtry (BPF) do odrzucania niepotrzebnych pakietów jeszcze w jądrze, co zmniejsza obciążenie systemu i ilość danych do analizy.

Zapis do pliku zamiast analizy na żywo w terminalu pozwala na wielokrotne przeglądanie tych samych danych z różnymi filtrami i poziomami szczegółowości. Sprawdzaj statystyki dropów na końcu wyjścia tcpdump i zwiększaj bufor (-B) w razie potrzeby. Testuj filtr na małej próbce (opcja -c) przed uruchomieniem długotrwałego przechwytywania, aby upewnić się, że filtr działa zgodnie z oczekiwaniami. Dokumentuj każde przechwycenie: interfejs, filtr, czas trwania i cel, co ułatwia późniejszą analizę i audyt.

Pytania kontrolne weryfikują zrozumienie praktycznych aspektów pracy z tcpdump. Pytanie o opcję -e sprawdza znajomość warstwy łącza danych - adresy MAC są niezbędne w diagnostyce ARP, wykrywaniu spoofingu i analizie sieci z mostami. Różnica między -x a -XX testuje znajomość budowy ramki Ethernet - pierwsze 14 bajtów nagłówka Ethernet jest pomijanych w -x.

Pytanie o filtr BPF z hostem i portem weryfikuje umiejętność łączenia prymitywów w złożone wyrażenia, co jest codzienną praktyką w pracy z tcpdump. Znaczenie statystyk dropped by kernel i znajomość opcji ring bufora (-C, -W) sprawdzają przygotowanie do pracy w środowiskach produkcyjnych o dużym natężeniu ruchu. Odpowiedzi na te pytania stanowią minimum wymagane od administratora sieci przed przystąpieniem do samodzielnej pracy z tcpdump.

Zakończenie szóstej części cyklu Pomiary logiczne podsumowuje zdobytą wiedzę o tcpdump i przygotowuje grunt pod kolejne zagadnienia. Praca własna zaproponowana na slajdzie obejmuje cztery praktyczne ćwiczenia: instalację tcpdump i przechwycenie 50 pakietów, eksperymenty z opcjami -n, -e, -X, -A na tym samym zestawie danych, porównanie widoku tcpdump i Wireshark na tym samym pliku pcap oraz napisanie samodzielnego filtra BPF dla ruchu DNS.

Wykonanie tych ćwiczeń utrwala wiedzę teoretyczną i rozwija umiejętności praktyczne niezbędne w codziennej pracy administratora sieci. Następna część cyklu poświęcona będzie protokołowi ARP (Address Resolution Protocol) - jego budowie, znaczeniu w sieciach IPv4, podatności na ataki oraz narzędziom do diagnostyki i monitorowania. Zachęcamy do eksperymentowania z tcpdump we własnym środowisku laboratoryjnym przed przystąpieniem do kolejnej części.