Podręcznik

Analiza ruchu sieciowego polega na przechwytywaniu, badaniu i interpretowaniu pakietów przesyłanych przez sieć. Pozwala zrozumieć, co się dzieje „pod maską” komunikacji między urządzeniami, identyfikować aplikacje, protokoły, anomalie, ataki, opóźnienia i wąskie gardła. Niezależnie od tego, czy chodzi o rozwiązania bezpieczeństwa, optymalizację wydajności, debugowanie lub zgodność z normami, analiza ruchu jest fundamentem obsługi sieci. Istnieją dwa główne podejścia: pasywne — gdy ruch jest przechwytywany (np. na mirrorowanym porcie SPAN, w TAP‑ie sieciowym lub na bridge’u), oraz aktywne — gdy wysyła się własny ruch testowy (ping, traceroute, HTTP get) w celu pomiaru zmian, opóźnień, strat czy trasowania. Pasywna analiza to typowo zadanie dla narzędzi takich jak Wireshark, tcpdump, tshark lub algorytmy systemów IDS/IPS (Snort, Suricata), ale też silniki NetFlow/sFlow. Współczesne platformy automatyzują analizę wyników przez uczenie maszynowe – analiza protokołów niedokumentowanych (np. aplikacji IoT), identyfikacja anomalii bez sygnatur, korelacja zdarzeń w czasie. Narzędzia filtrują ruch według IP, portów, kierunku, typu protokołu, a następnie pozwalają rozkładać pakiety na składowe warstwy Ethernet/IP/TCP/HTTP itd., oferując szczegółowy widok na treść pakietów (nagłówki, flagi, payload). Analiza ruchu umożliwia określenie metryk takich jak opóźnienia między hostami (RTT), czas DNS, czas TCP three‑way handshake, czas TLS handshake, przepływność danych oraz proporcje ruchu szyfrowanego i nieszyfrowanego. Pozwala zidentyfikować retransmisje, out‑of‑order, błędy CRC, fragmentacje IP, problemy z MTU, DNS errors, błędy protokołowe (HTTP 4xx/5xx), nietypowe sekwencje SYN/ACK, podejrzane pakiety RST, FIN w złym czasie, skany portów (SYN‑scan, Xmas‑scan, NULL‑scan).

Po stronie narzędzi analiza może być liniowa — najpierw Ethernet, IP, TCP/UDP, aplikacja — lub heurystyczna: np. analiza TLS przy użyciu JA3 fingerprints, identyfikacja klientów (np. przeglądarki, IoT), analiza treści payload w protokołach DNS (zapytania A, MX, TXT), analiza ścieżek HTTP (request‑response), analiza RSS, JSON‑ów, SOAP, REST‑API, WebSocketów. Systemy głębokiej inspekcji pakietów (DPI) rozpoznają i klasyfikują pakiety na podstawie wzorców, czasem ekstraktują nawet dane formularzy, nagłówki, nagłówki HTTP multipart, przy jednoczesnym przestrzeganiu polityk prywatności.

Przykład: diagnoza wolnego ładowania strony. Pasywna analiza wykazuje — opóźnienia na DNS (czas zapytania + odpowiedź), potem wolny TLS handshake (kilka RTT), potem dużą liczbę retransmisji TCP (Time‑Wait lub brak ack), wreszcie pobieranie zasobów z dużymi opóźnieniami — analiza per‑segment i histogramów pokaże obraz problemu.

Aktywna analiza sieciowa to technika, w której użytkownik lub administrator sam generuje ruch w sieci w celu diagnozowania jej właściwości, jakości usług lub topologii. W odróżnieniu od analizy pasywnej, polegającej na nasłuchiwaniu istniejącego ruchu, analiza aktywna wymaga świadomego wygenerowania zapytań diagnostycznych i obserwowania odpowiedzi. Umożliwia to wykrycie ukrytych komponentów infrastruktury takich jak load balancery, translatory adresów (NAT), systemy równoważenia obciążenia oparte na anycaście, tunele VPN, mechanizmy MPLS czy sieci dostarczania treści (CDN). Narzędzia takie jak ping, traceroute, httperf, wrk czy iperf umożliwiają wykonanie takich analiz.

Podstawowym narzędziem aktywnej diagnostyki jest ping, które bazuje na komunikacie ICMP Echo Request i Echo Reply. Mierzy czas potrzebny na przesłanie pakietu do celu i z powrotem, dostarczając informacji o opóźnieniach i utraconych pakietach. Przydatne jest także ustawianie flagi „Don't Fragment” (DF), co pozwala testować maksymalną jednostkę transmisji (MTU). Jeśli pakiet nie zostanie dostarczony, oznacza to zbyt małą wartość MTU na trasie – pozwala to lokalizować błędnie skonfigurowane urządzenia lub tunele VPN.

W tym przykładzie przesyłany jest pakiet 1500 bajtów (dodając 28 bajtów nagłówka IP/ICMP), a flaga „Don't Fragment” nie pozwala na fragmentację. Jeśli taki pakiet nie przejdzie, oznacza to, że na trasie znajduje się urządzenie z niższym MTU (np. 1400 bajtów w przypadku GRE lub IPSec).

Kolejnym narzędziem jest traceroute, które pozwala poznać każdy węzeł (router) na trasie do celu. Działa poprzez wysyłanie pakietów IP o stopniowo zwiększanym polu TTL (Time To Live). Gdy TTL osiąga zero, router zwraca ICMP Time Exceeded – na podstawie tych odpowiedzi można zrekonstruować trasę pakietów przez Internet. To umożliwia wykrycie asymetrycznych tras (gdy pakiet i odpowiedź idą innymi drogami), obecności tunelowania (gdy segmenty trasy są ukryte) czy zmian tras wynikających z dynamicznego routingu lub działania CDN.

Bardziej zaawansowane narzędzia to iperf i iperf3, które służą do pomiaru przepustowości TCP lub UDP między dwoma punktami. Umożliwiają pomiar przepływności w różnych kierunkach, testy w czasie rzeczywistym, badanie jittera (zmienność opóźnienia), strat pakietów, efektywności retransmisji TCP. iperf umożliwia również ustawienie czasu trwania testu, wielkości segmentów, liczby strumieni równoległych.

Wyśle 4 równoległe strumienie TCP przez 10 sekund, pozwalając zmierzyć maksymalną dostępną przepustowość na danym łączu.

Do testowania wydajności HTTP można używać httperf lub wrk. httperf pozwala symulować tysiące żądań HTTP, analizując czasy odpowiedzi, liczbę połączeń na sekundę, zachowanie serwera pod obciążeniem. wrk to nowoczesne narzędzie działające wielowątkowo, potrafiące jednocześnie wysyłać wiele żądań HTTP, rejestrować minimalne, maksymalne i średnie czasy odpowiedzi, rozkład błędów.

Ten test użyje 4 wątków (-t4), 100 równoczesnych połączeń (-c100) i będzie trwać 30 sekund. Rezultatem będzie informacja o liczbie zapytań na sekundę, czasie odpowiedzi i rozkładzie procentowym czasów reakcji.

Za pomocą tych narzędzi można także wykrywać load balancery – np. gdy różne pakiety TCP trafiają do różnych backendów. W przypadku anycastu – wiele serwerów ma ten sam adres IP, ale znajdują się w różnych miejscach świata – narzędzia aktywne pozwalają zidentyfikować do którego fizycznego serwera trafi ruch.

Analizując wartości TTL odpowiedzi, można stwierdzić czy pakiet przebył 2, 5 czy 15 routerów. Jeżeli TTL w odpowiedzi zmienia się przy kolejnym zapytaniu – może to oznaczać dynamiczne równoważenie ruchu, działanie mechanizmów BGP lub obecność sieci typu CDN.

W środowiskach VPN, analiza aktywna wykazuje, że pakiety omijają lokalne trasy, pojawiają się opóźnienia, a trasy traceroute stają się bardziej zwarte (tunelowanie). W MPLS – część tras może być ukryta, bo routery pośrednie nie ujawniają się w odpowiedziach ICMP (tzw. „label switching”).

Dzięki aktywnej analizie możliwe jest również wykrycie NAT-ów – np. w UDP, gdzie port źródłowy jest zmieniany przez NAT. Porównując sekwencje portów lub analizując źródła odpowiedzi można wykryć translację adresów oraz ustalić ich zakres działania.

Analiza ruchu to także podstawa wykrywania anomalii. System obserwuje trendy, alertuje gdy wykracza powyżej odchyleń, generuje SIEM events, pozwala reagować w czasie rzeczywistym (inline IPS). Przykłady: wzrost ruchu UDP do dziwnych portów, powtarzające SYN bez ACK (skanowanie), nietypowe DNS TXT z base64, duże uploady w nocy (wyciek), połączenia do C2 (Command & Control), beaconing. Analiza SSL zamieniaja komunikację w metryki: długość certyfikatu, commonName, issuer, fingerprint, ocsp stapling, pilność cipherSuite itp.

W chmurze natomiast analiza polega na eksportowaniu logów VPC Flow Logs, CloudWatch, Azure Network Watcher, Google VPC logging, zebranych i analizowanych w pipeline: zbieranie do S3/Blob, normalizacja (Glue/Kafka), analiza (Athena/BigQuery, ElasticSearch), dashboardy (Grafana), alerty (pagerduty, slack). Wirtualne TAPy i mirrorowanie w chmurze pozwalają analizować ruch między VM/containers/k8s pods.

Deep Packet Inspection (DPI) uruchamiany inline lub pasywnie może także działać z NAT, IPSec/VPN, TLS termination (w firmach), w chmurze przy load balancerze decryptuje ruch (jeśli ma certyfikat) i inspektuje.

Analiza ruchu sieciowego da się sklasyfikować także wg zastosowań: troubleshooting, bezpieczeństwo, compliance, planowanie pojemności, optymalizacja QoS, billing u ISP. W ISP analiza to billing per-flow, detekcja P2P ruchu, dynamiczny rating, shaping per subscriber. Wztchrone między warstwami, SNMP+NetFlow+pakiety daje pełny obraz: SNMP monitoruje counters (CPU, interfaces), NetFlow – ruch, DPI – treść, pakiety – szczegół pakietowy.

Przykład TCP three‑way handshake: pasywnie widzimy SYN, SYN-ACK, ACK, liczymy opóźnienia między nimi. Gdy SYN-ACK jest retranmitowany – oznacza latencję lub packet loss. Jeśli RST pojawia się bez wcześniejszego SYN, oznacza skan, skrypt lub omyłkowe połączenie. Jeśli FIN pojawia się, ale brak ACK – implicite half‑open, co może sygnalizować błędy w aplikacji.

Analiza ruchu to znak rozpoznawczy pracy sieciowca, DevOps inżyniera, analityka bezpieczeństwa. Wymaga narzędzi, znajomości protokołów, umiejętności odczytu pakietów i kontekstu biznesowego. Dla studentów warto zwrócić uwagę na strukturę pakietów – warstwy OSI – i stosowanie filtrów BPF (np. „tcp port 443 and host 1.2.3.4”) albo predefiniowanych metryk (MRTG, sFlow). Warto wiedzieć, że przy ruchu 10 Gbps analiza pakietów wymaga sprzętowej akceleracji – np. SmartNIC, FPGA, dedykowanych capture cards. Trzeba też pamiętać o prywatności – DPI może przechwytywać dane użytkownika, więc analizę należy stosować z ostrożnością i zgodnie z polityką RODO.

W codziennej pracy analiza może wyglądać następująco: klient narzeka na wolne działanie aplikacji; inżynier włącza tcpdump na mirrorowanym porcie serwera, filtruje komunikację między klientem a serwerem, analizuje licznik序号 pakietów, patrzy czy są retransmisje, out-of-order, diagnostyzuje czy problem jest po stronie sieci, serwera, aplikacji lub po stronie klienta.

Poza obrazem pakietów istotne są także heurystyki np. analiza przepływów do zdalnych krajów, portów 23, 5900, 3389 – podejrzane. W sieciach korporacyjnych lub rządowych stosuje się same aplikacje do analizy: Suricata w ty i Snort generują alarmy na specyficzne sygnatury (np. port knocking, exploit), a Zeek (dawniej Bro) analizuje sesje i protokoły na poziomie aplikacyjnym (HTTP URI, DNS queries).

Badanie ruchu DNS może ujawnić wycieki danych, zapytania do nietypowych subdomen z długimi losowymi nazwami – sygnał beaconingu. Analiza HTTP umożliwia sprawdzenie, które zasoby są pobierane, jakie nagłówki, cookies, cache‑control, CORS są obecne. Pozwala też identyfikować Crawlerów, boty, scrapperów.