1/58
Narzędzia pomocnicze (generatory, skanery)

Prezentacja przedstawia cztery pomocnicze narzędzia sieciowe: Yersinia do ataków warstwy 2 (STP, CDP, DHCP, HSRP), Iptraf do monitorowania ruchu w czasie rzeczywistym, Netcat do transmisji danych przez TCP/UDP oraz Packeth do generowania ramek Ethernet. Każde z narzędzi zostało omówione pod kątem instalacji, składni i praktycznych zastosowań w diagnostyce sieci. Prezentacja zawiera również laboratoria krok po kroku oraz porównanie omawianych narzędzi.

Prezentowane w tej części narzędzia – yersinia, iptraf, netcat i packeth – reprezentują cztery różne podejścia do diagnostyki i testowania sieci na warstwach 2–4 modelu OSI. Yersinia koncentruje się na testach penetracyjnych warstwy łącza danych, iptraf na monitorowaniu ruchu w czasie rzeczywistym, netcat na uniwersalnej komunikacji TCP/UDP, a packeth na generowaniu pojedynczych ramek Ethernet.

Łączne wykorzystanie tych narzędzi pozwala na kompleksową ocenę bezpieczeństwa i wydajności sieci LAN – od sprawdzenia poprawności konfiguracji przełączników (yersinia), przez pomiar obciążenia łączy (iptraf), po testowanie reguł firewall i ACL (packeth) oraz ręczną weryfikację dostępności usług (netcat).

2/58
Plan prezentacji
  • Yersinia (slajdy 3–15) – ataki warstwy 2
  • Iptraf (slajdy 16–28) – monitorowanie ruchu
  • Netcat (slajdy 29–45) – uniwersalne narzędzie TCP/UDP
  • Packeth (slajdy 46–53) – generator pakietów
  • Podsumowanie i pytania (slajdy 54–58)

Materiał został podzielony na cztery główne bloki tematyczne, z których każdy poświęcony jest jednemu narzędziu. Taka struktura ułatwia systematyczne przyswajanie wiedzy – każdy blok zawiera wprowadzenie teoretyczne, instrukcję instalacji, omówienie trybów pracy, przykłady praktyczne oraz porównanie z narzędziami alternatywnymi.

Na końcu prezentacji znajduje się podsumowanie z mapą narzędzi, pytania kontrolne sprawdzające zrozumienie materiału oraz zadanie praktyczne łączące wszystkie cztery narzędzia w jednym scenariuszu laboratoryjnym. Slajdy 54–58 stanowią zamknięcie merytoryczne i zachętę do samodzielnych ćwiczeń.

3/58
Czym jest yersinia?

Yersinia to framework do testów penetracyjnych warstwy 2 (łącza danych) w sieciach LAN. Umożliwia przeprowadzanie ataków na protokoły STP, CDP, DHCP, HSRP, DTP i inne.

Nazwa pochodzi od bakterii Yersinia pestis – nawiązanie do "zarażania" sieci fałszywymi ramkami.

Yersinia działa wyłącznie na systemach Linux. Wymaga uprawnień root.

Yersinia jest rozwijana od początku lat 2000. Jako framework typu open-source, umożliwia nie tylko przeprowadzanie gotowych ataków, ale także tworzenie własnych scenariuszy testowych dzięki architekturze wtyczek (pluginów). Wersja z interfejsem graficznym (GTK+) ułatwia obsługę początkującym, podczas gdy tryb CLI jest preferowany przez zaawansowanych użytkowników pracujących zdalnie przez SSH.

Nazwa narzędzia nawiązuje do bakterii Yersinia pestis, która wywołuje dżumę – analogia do „zarażania” sieci fałszywymi ramkami jest celowa i podkreśla destrukcyjny potencjał narzędzia. Yersinia jest standardowym elementem dystrybucji Kali Linux i jest często wykorzystywana na szkoleniach z bezpieczeństwa sieciowego (CEH, OSCP).

4/58
Instalacja yersinia

Instalacja na Debian/Ubuntu:

sudo apt update
sudo apt install yersinia

Instalacja ze źródeł (najnowsza wersja):

git clone https://github.com/tomac/yersinia.git
cd yersinia
./autogen.sh
./configure --enable-plugins
make
sudo make install

Yersinia nie jest dostępna natywnie na Windows. W środowisku Windows można uruchomić yersinia w maszynie wirtualnej z Linuxem (np. Kali Linux) lub przez WSL2 z dostępem do surowego gniazda.

Instalacja yersinia z repozytoriów dystrybucji (apt, yum) jest najprostszą metodą, ale może nie dawać najnowszej wersji. Instalacja ze źródeł z GitHub pozwala uzyskać aktualne wtyczki i poprawki, ale wymaga zainstalowanych narzędzi developerskich (autoconf, automake, gcc, libgtk-3-dev, libglib2.0-dev).

W systemie Kali Linux yersinia jest preinstalowana, co czyni tę dystrybucję najwygodniejszym środowiskiem do nauki i testów. Dla użytkowników Windows jedyną praktyczną opcją jest uruchomienie Kali w maszynie wirtualnej (VirtualBox, VMware) z mostkowaną kartą sieciową, co zapewnia dostęp do surowych ramek Ethernet niezbędnych do działania yersinia.

5/58
Tryby pracy: CLI i GUI

Yersinia oferuje dwa tryby pracy:

  • CLI (konsola): yersinia -I – interfejs tekstowy z menu kursorowym, lekki, działa w sesji SSH
  • GUI (GTK+): yersinia -G – interfejs graficzny, wygodniejszy, wymaga serwera X
Do zdalnej pracy przez SSH zaleca się tryb CLI ( -I ). Tryb GUI ( -G ) wymaga przekierowania X11 (ssh -X).

Tryb CLI (yersinia -I) uruchamia interfejs tekstowy oparty na bibliotece ncurses, który działa w każdym terminalu, również przez połączenie SSH bez przekierowania X11. Nawigacja odbywa się za pomocą klawiszy strzałek, a wybór ataku potwierdza się klawiszem Enter. Tryb ten jest lżejszy i szybszy, szczególnie na słabszych maszynach.

Tryb GUI (yersinia -G) wykorzystuje bibliotekę GTK+ i oferuje bardziej intuicyjną obsługę – wszystkie opcje ataku są widoczne w formie menu i okien dialogowych. Wymaga jednak działającego serwera X (lub Xming/VcXsrv w przypadku SSH z Windows). Dla zdalnej pracy przez SSH zaleca się użycie opcji -X (przekierowanie X11) lub wybór trybu CLI.

6/58
Uruchomienie yersinia
# Tryb interfejsu tekstowego
sudo yersinia -I

# Tryb graficzny (GTK+)
sudo yersinia -G

# Wyświetlenie dostępnych interfejsów
sudo yersinia -I -i

# Uruchomienie z konkretnym interfejsem
sudo yersinia -I -i eth0

Po uruchomieniu pojawia się lista dostępnych ataków. Wyboru dokonuje się strzałkami i klawiszem Enter.

Przed uruchomieniem yersinia należy upewnić się, że interfejs sieciowy jest w trybie monitorowania (promiscuous mode) – yersinia automatycznie przełącza kartę w ten tryb, ale wymaga do tego uprawnień root. W przypadku wielu interfejsów sieciowych kluczowe jest wskazanie właściwego za pomocą opcji -i.

Po uruchomieniu yersinia w trybie CLI użytkownik widzi główne menu z listą protokołów (STP, CDP, DHCP, HSRP, DTP itp.). Po wybraniu protokołu pojawia się lista dostępnych ataków dla tego protokołu. Każdy atak ma własne opcje konfiguracyjne, takie jak adres MAC źródła, priorytet, liczba ramek czy opóźnienie między ramkami.

7/58
Ataki na STP (Spanning Tree Protocol)

STP zapobiega pętlom w sieci Ethernet. Yersinia może:

  • BPDU flood – zalanie sieci ramkami BPDU, destabilizacja STP
  • Root role attack – wysłanie fałszywych BPDU z niższym priorytetem mostu, przejęcie roli root bridge
  • Topology Change Attack – ciągłe wysyłanie TC BPDU, wymuszenie ponownego przeliczenia STP
# W GUI: wybierz STP -> BPDU flood
# W CLI: strzałkami wybierz STP, potem BPDU

Efekt: przerwy w komunikacji, przekierowanie ruchu, możliwość sniffowania.

Ataki na STP są szczególnie groźne, ponieważ Spanning Tree Protocol działa na warstwie 2 i nie ma wbudowanych mechanizmów uwierzytelniania. Wysyłając fałszywe ramki BPDU (Bridge Protocol Data Units) z niższym priorytetem mostu niż legalny root bridge, atakujący może przejąć rolę korzenia drzewa STP, co pozwala na przekierowanie ruchu przez swoją maszynę.

BPDU flood, czyli wysłanie tysięcy ramek BPDU w krótkim czasie, może doprowadzić do destabilizacji całego drzewa STP, powodując tymczasowe pętle (loop) i przerwy w komunikacji. Atak topology change powoduje ciągłe odświeżanie tabel przekazywania (MAC address table) na przełącznikach, co obniża wydajność przełączania ramek.

8/58
Ataki na CDP (Cisco Discovery Protocol)

CDP to protokół warstwy 2 używany przez urządzenia Cisco do wymiany informacji o sąsiedztwie. Yersinia może:

  • CDP flood – zalewanie sieci ramkami CDP z fałszywymi danymi
  • Device spoofing – podszywanie się pod inne urządzenie Cisco
# W yersinia: CDP -> CDP flood
# Można ustawić własny TLV (Type-Length-Value)

Skutek: dezorientacja administratora, fałszywe wpisy w show cdp neighbors , możliwość socjotechniki.

CDP (Cisco Discovery Protocol) jest domyślnie włączony na wszystkich urządzeniach Cisco i wysyła ramki multicast co 60 sekund. Ramki CDP zawierają informacje takie jak nazwa urządzenia, model, wersja IOS, adres IP interfejsu, typ platformy i możliwości. Yersinia może generować fałszywe ramki CDP z dowolnymi danymi, co wprowadza administratora w błąd podczas diagnostyki.

Atak typu CDP flood polega na wysłaniu dużej liczby ramek CDP z różnymi danymi TLV (Type-Length-Value), co może przeciążyć CPU przełącznika podczas przetwarzania ramek CDP. Device spoofing pozwala podszyć się pod konkretne urządzenie Cisco, co może być wykorzystane w socjotechnice lub do ukrycia obecności atakującego w sieci.

9/58
Ataki na DHCP – przegląd

Yersinia implementuje dwa główne ataki na DHCP:

  1. DHCP Starvation – wyczerpanie puli adresów DHCP
  2. Rogue DHCP Server – fałszywy serwer DHCP

Oba ataki mogą być użyte razem: najpierw starvation, potem rogue server przejmuje ruch.

Ataki DHCP są szczególnie skuteczne w sieciach bez zabezpieczeń (brak DHCP snooping).

Ataki na DHCP są szczególnie skuteczne w sieciach bez włączonego mechanizmu DHCP Snooping, który jest domyślnie wyłączony na większości przełączników. DHCP Snooping polega na klasyfikowaniu portów jako zaufane (trusted – tam gdzie znajduje się legalny serwer DHCP) i niezaufane (untrusted – pozostałe porty), blokując odpowiedzi DHCP z portów niezaufanych.

Yersinia umożliwia sekwencyjne wykonanie obu ataków: najpierw DHCP Starvation wyczerpuje pulę adresów, uniemożliwiając legalnym urządzeniom otrzymanie adresu IP, a następnie Rogue DHCP Server przejmuje kontrolę nad nowymi żądaniami. W środowisku laboratoryjnym warto przećwiczyć oba ataki, aby zrozumieć, jak działają mechanizmy obronne.

10/58
DHCP Starvation

Polega na wysłaniu dużej liczby żądań DHCP Discover z różnymi (fałszywymi) adresami MAC. Serwer DHCP przydziela adresy IP każdemu żądaniu, aż do wyczerpania puli.

# W yersinia: DHCP -> DHCP starvation
# Ustawienia:
# - Source MAC: randomizowany
# - Ilość żądań: 1000+
# - Opóźnienie: 0 ms (maksymalne obciążenie)

Efekt: nowe (legalne) urządzenia nie otrzymują adresu IP (DoS na adresację). Atak nie wymaga odpowiedzi – są to jednokierunkowe transmisje.

DHCP Starvation wykorzystuje fakt, że serwer DHCP przydziela adres IP każdemu żądaniu DHCP Discover, jeśli tylko ma dostępne adresy w puli. Yersinia generuje żądania z losowymi adresami MAC (pole CHADDR w ramce DHCP), co symuluje wiele różnych urządzeń. W ciągu kilku sekund można wyczerpać pulę nawet kilkuset adresów.

Atak nie wymaga odbierania odpowiedzi DHCP Offer/ACK – samo wysłanie Discover z unikalnym MAC wystarczy, aby serwer zarezerwował adres. Dlatego atak jest jednokierunkowy i bardzo trudny do wykrycia bez monitorowania logów serwera DHCP. Po wyczerpaniu puli nowe legalne urządzenia otrzymują komunikat DHCP NAK (Negative Acknowledgment) lub nie otrzymują żadnej odpowiedzi.

11/58
Rogue DHCP Server

Po wyczerpaniu puli (lub równolegle) atakujący uruchamia fałszywy serwer DHCP, który odpowiada na zapytania DHCP Discover z własną konfiguracją.

# W yersinia: DHCP -> Rogue DHCP server
# Konfiguracja fałszywego serwera:
# - IP pool: 192.168.1.100-200
# - Gateway (router): 192.168.1.254 (atakujący)
# - DNS: 8.8.8.8
# - Lease time: 60s

Skutek: ofiary otrzymują adres IP z bramą wskazującą na atakującego (Man-in-the-Middle). Cały ruch ofiar przechodzi przez maszynę atakującego.

Rogue DHCP Server to fałszywy serwer DHCP uruchomiony przez atakującego, który odpowiada na zapytania DHCP Discover szybciej niż legalny serwer (ponieważ znajduje się bliżej ofiary w sieci LAN). W konfiguracji fałszywego serwera atakujący ustawia własny adres IP jako bramę domyślną (default gateway), co powoduje, że cały ruch ofiar jest kierowany przez maszynę atakującego.

Po przejęciu ruchu atakujący może wykonywać ataki typu Man-in-the-Middle: przechwytywać i modyfikować pakiety, wykradać dane uwierzytelniające (np. hasła do stron HTTP), przekierowywać ofiary na fałszywe strony logowania (phishing) lub blokować dostęp do określonych usług. Aby zabezpieczyć się przed tym atakiem, należy włączyć DHCP Snooping na przełącznikach.

12/58
Ataki na HSRP (Hot Standby Router Protocol)

HSRP (Hot Standby Router Protocol) zapewnia redundantną bramę domyślną w urządzeniach Cisco. Yersinia może:

  • HSRP hijack – przejęcie roli active router przez wysłanie fałszywego hello z wyższym priorytetem
# W yersinia: HSRP -> HSRP attack
# Ustawienia:
# - Virtual IP: 192.168.1.1
# - Priority: 255 (maksymalny)
# - Group: 0

Efekt: cały ruch ofiar kierowany na maszynę atakującego zamiast na legalny router.

HSRP używa wirtualnego adresu MAC 00-00-0C-07-AC-XX. VRRP (standard IEEE) używa MAC 00-00-5E-00-01-XX, ale nie jest obsługiwany przez yersinia.

HSRP (Hot Standby Router Protocol) to protokół warstwy 3 firmy Cisco zapewniający redundantną bramę domyślną poprzez utworzenie wirtualnego adresu IP i MAC, który jest współdzielony między dwoma lub więcej routerami. W normalnych warunkach jeden router jest Active (przekazuje ruch), a pozostałe Standby (czekają na awarię). Priorytet decyduje o tym, który router zostanie Active.

Atak HSRP hijack polega na wysłaniu fałszywego komunikatu Hello z priorytetem 255 (maksymalnym), co powoduje natychmiastowe przejęcie roli Active router przez maszynę atakującego. Wirtualny adres IP i MAC są przejmowane, a cały ruch ofiar jest kierowany na maszynę atakującego. Yersinia nie obsługuje ataków na VRRP (Virtual Router Redundancy Protocol) – do testowania VRRP należy użyć Scapy lub innego narzędzia. Zabezpieczeniem jest uwierzytelnianie komunikatów HSRP (MD5) oraz stosowanie mechanizmów IPSG (IP Source Guard).

13/58
Ataki na DTP (Dynamic Trunking Protocol)

DTP to protokół Cisco do negocjacji trunking (tagowanie VLAN 802.1Q). Yersinia umożliwia:

  • DTP enable – wysłanie ramki DTP z żądaniem włączenia trunk
# W yersinia: DTP -> DTP enable
# Ustawienia:
# - Interfejs: eth0
# - MAC źródłowy: własny lub fałszywy

Skutek: port przełącznika zmienia się w trunk, a atakujący widzi ruch ze wszystkich VLAN-ów (VLAN hopping).

Dynamic Trunking Protocol (DTP) to protokół Cisco używany do automatycznej negocjacji trybu trunk między przełącznikami. Domyślnie porty przełączników Cisco są w trybie Dynamic Auto lub Dynamic Desirable, co oznacza, że mogą automatycznie przejść w tryb trunk po otrzymaniu odpowiedniej ramki DTP od sąsiada.

Atak DTP enable polega na wysłaniu ramki DTP z żądaniem włączenia trybu trunk na porcie dostępowym. Jeśli port jest w trybie dynamicznym (domyślnym), przełącznik przełączy go w tryb trunk, a atakujący zyska dostęp do ruchu ze wszystkich VLAN-ów (VLAN hopping). Aby zapobiec temu atakowi, należy ręcznie ustawić wszystkie porty dostępowe jako switchport mode access i wyłączyć DTP (switchport nonegotiate).

14/58
Zapobieganie atakom warstwy 2

Zabezpieczenia przed atakami yersinia:

# Konfiguracja na przełączniku Cisco
# Port Security
switchport port-security
switchport port-security maximum 1
switchport port-security violation shutdown

# BPDU Guard (zapobiega atakom STP)
spanning-tree bpduguard enable

# DHCP Snooping (zapobiega rogue DHCP)
ip dhcp snooping
ip dhcp snooping vlan 1-100

# Dynamic ARP Inspection
ip arp inspection vlan 1-100
Większość ataków warstwy 2 jest skuteczna TYLKO przy domyślnej konfiguracji przełączników. Właściwe zabezpieczenia blokują je całkowicie.

Port Security to mechanizm ograniczający liczbę adresów MAC, które mogą być obsługiwane na danym porcie przełącznika. Po przekroczeniu maksymalnej liczby (domyślnie 1) przełącznik może: zablokować dodatkowe adresy (protect), odrzucić ramki z logowaniem błędu (restrict) lub wyłączyć port (shutdown). Opcja shutdown jest najbezpieczniejsza, ale wymaga ręcznej interwencji administratora do ponownego włączenia portu.

BPDU Guard natychmiast wyłącza port, jeśli na port skonfigurowany jako access zostanie odebrana ramka BPDU. Jest to podstawowe zabezpieczenie przed atakami STP (root role attack). DHCP Snooping w połączeniu z Dynamic ARP Inspection (DAI) i IP Source Guard (IPSG) tworzy kompleksowy system zabezpieczeń warstwy 2, który blokuje rogue DHCP server, ARP spoofing i IP spoofing.

15/58
Yersinia w testach penetracyjnych

Yersinia jest używana w testach penetracyjnych sieci LAN do:

  • Weryfikacji konfiguracji przełączników (czy STP, DHCP snooping działają)
  • Sprawdzania odporności na ataki warstwy 2
  • Testowania procedur incident response
# Typowe scenariusze testowe:
# 1. Czy port security jest włączony?
#    -> DHCP starvation na danym porcie
# 2. Czy DHCP snooping działa?
#    -> Próba rogue DHCP server
# 3. Czy BPDU guard jest aktywny?
#    -> BPDU flood na port
UWAGA: Ataki yersinia powodują realne zakłócenia w sieci. Używaj wyłącznie w kontrolowanym środowisku laboratoryjnym.

W testach penetracyjnych yersinia jest używana do weryfikacji, czy zabezpieczenia warstwy 2 są poprawnie skonfigurowane i aktywne. Standardową procedurą jest próba wykonania każdego ataku i sprawdzenie, czy przełącznik zareagował zgodnie z oczekiwaniami (np. wyłączył port po próbie DHCP Starvation z włączonym Port Security).

Testy należy wykonywać w ściśle kontrolowanym środowisku laboratoryjnym, z dala od sieci produkcyjnej. Nawet pojedyncza ramka BPDU wysłana na sieć produkcyjną może spowodować destabilizację STP i przerwę w komunikacji. Z tego samego powodu yersinia nie powinna być uruchamiana na sieciach, do których nie mamy pisemnej zgody na testy penetracyjne.

16/58
Przykład: DHCP starvation w laboratorium

Scenariusz laboratoryjny:

  1. Uruchom yersinia w trybie CLI: sudo yersinia -I
  2. Wybierz DHCP → DHCP starvation
  3. Ustaw liczbę żądań na 500, opóźnienie 0 ms
  4. Uruchom atak
# Monitorowanie efektu na serwerze DHCP
# Sprawdzenie puli adresów (Linux DHCP server):
cat /var/lib/dhcp/dhcpd.leases | wc -l

Obserwacja: pula adresów zostaje wyczerpana w ciągu kilku sekund. Nowe urządzenia nie otrzymują adresu IP.

Aby odblokować pulę DHCP, należy uruchomić na przełączniku clear ip dhcp binding * lub odczekać czas dzierżawy.

W laboratorium warto przygotować dedykowany serwer DHCP (np. isc-dhcp-server na Linux) z pulą adresów ograniczoną do 50 adresów, aby szybko zaobserwować efekt ataku. Monitorowanie pliku dzierżaw (/var/lib/dhcp/dhcpd.leases) pozwala zobaczyć w czasie rzeczywistym, jak kolejne fałszywe adresy MAC otrzymują adresy IP.

Po zakończeniu ataku i wyczerpaniu puli można sprawdzić, czy nowe legalne urządzenie (np. drugi komputer podłączony do tej samej sieci) otrzymuje adres IP. Jeśli nie, atak zakończył się sukcesem. Aby przywrócić normalne działanie DHCP, należy wyczyścić bazę dzierżaw na serwerze DHCP (komenda clear ip dhcp binding * na Cisco IOS) lub usunąć plik dzierżaw i zrestartować usługę na Linux.

17/58
Czym jest iptraf?

iptraf (IP Traffic Monitor) to narzędzie do monitorowania ruchu sieciowego w czasie rzeczywistym dla Linux. Działa w trybie TUI (Text User Interface). Umożliwia:

  • Podgląd ruchu per host
  • Statystyki interfejsów (pakiety/s, bajty/s)
  • Monitorowanie połączeń TCP
  • Statystyki hostów w sieci LAN
Istnieje nowsza wersja: iptraf-ng (next generation). Większość dystrybucji zawiera iptraf-ng jako domyślną.

iptraf (IP Traffic Monitor) został stworzony przez Gerarda Paula Koka w 1998 roku jako narzędzie do monitorowania ruchu IP w systemie Linux. Wersja iptraf-ng (next generation) jest aktywniej rozwijana i zawiera ulepszenia, takie jak obsługa IPv6, lepsza wydajność przy dużym ruchu oraz wsparcie dla kolorowego wyjścia terminala.

W odróżnieniu od takich narzędzi jak tcpdump czy Wireshark, iptraf nie przechwytuje całych pakietów – zbiera jedynie statystyki i metadane, co czyni go lżejszym i bezpieczniejszym w środowiskach produkcyjnych. Nie wymaga bibliotek do przechwytywania pakietów (libpcap), ponieważ korzysta z /proc/net/dev i mechanizmów jądra Linux.

18/58
Instalacja iptraf
# Instalacja na Debian/Ubuntu
sudo apt update
sudo apt install iptraf iptraf-ng

# Instalacja na CentOS/RHEL
sudo yum install iptraf-ng

# Instalacja na Fedora
sudo dnf install iptraf-ng

# Sprawdzenie wersji
iptraf-ng --version

iptraf nie wymaga dodatkowych bibliotek. Działa w terminalu – nie potrzebuje serwera X.

W nowoczesnych dystrybucjach Linux pakiet iptraf-ng jest preferowaną wersją i często jest jedyną dostępną w repozytoriach. Starszy iptraf (bez -ng) może wymagać ręcznej instalacji ze źródeł, ale nie jest zalecany ze względu na brak aktualizacji i wsparcia dla nowych wersji jądra.

Po instalacji warto sprawdzić dostępne opcje iptraf-ng --help, które wyświetlają listę parametrów wiersza poleceń. Narzędzie nie wymaga konfiguracji wstępnej – działa od razu po uruchomieniu, automatycznie wykrywając dostępne interfejsy sieciowe. Do poprawnego działania wymaga uprawnień root do odczytu statystyk interfejsów.

19/58
Uruchomienie iptraf-ng
# Uruchomienie iptraf-ng
sudo iptraf-ng

# Uruchomienie z konkretnym interfejsem
sudo iptraf-ng -i eth0

# Uruchomienie z zapisem logów
sudo iptraf-ng -B -L /var/log/iptraf.log

# Parametry:
# -B  tryb background (demon)
# -L  plik logu
# -i  monitorowanie interfejsu
# -g  statystyki ogólne interfejsów

Po uruchomieniu bez parametrów pojawia się menu wyboru trybu.

Po uruchomieniu sudo iptraf-ng bez parametrów pojawia się menu główne z następującymi opcjami: IP Traffic Monitor (monitorowanie ruchu IP w czasie rzeczywistym), General Interface Statistics (ogólne statystyki interfejsów), Detailed Interface Statistics (szczegółowe statystyki z błędami), TCP Connection Monitor (monitorowanie połączeń TCP) oraz LAN Station Statistics (statystyki hostów w sieci LAN).

Wybór opcji odbywa się za pomocą klawiszy strzałek i Enter. W każdej chwili można wrócić do menu głównego klawiszem Esc lub Ctrl+Q. iptraf-ng wykorzystuje całą szerokość terminala, dlatego przed uruchomieniem warto zwiększyć rozmiar okna terminala dla lepszej czytelności danych.

20/58
IP Traffic Monitor

IP Traffic Monitor wyświetla pakiety IP w czasie rzeczywistym dla wybranego interfejsu. Pokazuje:

  • Źródłowy i docelowy adres IP
  • Porty TCP/UDP
  • Typ pakietu (TCP, UDP, ICMP)
  • Rozmiar pakietu
# Uruchomienie IP Traffic Monitor (z menu)
# Wybierz: IP Traffic Monitor -> eth0
#
# Widok:
# Src IP:Port      Dst IP:Port       Size  Flags
# 10.0.0.1:443     192.168.1.5:54321  120   ....

Przydatne do szybkiego sprawdzenia, jakie połączenia są aktualnie nawiązywane przez dany interfejs.

IP Traffic Monitor jest najbardziej podstawowym trybem iptraf-ng, pokazującym każdy pakiet IP przechodzący przez wybrany interfejs w czasie rzeczywistym. Dla każdego pakietu wyświetlane są: znacznik czasowy (z dokładnością do sekundy), źródłowy i docelowy adres IP, porty TCP/UDP, typ protokołu (TCP, UDP, ICMP) oraz rozmiar pakietu w bajtach.

Tryb ten jest szczególnie przydatny do szybkiej weryfikacji, czy na interfejsie pojawia się jakikolwiek ruch oraz jakie typy połączeń są nawiązywane. Przy dużej liczbie pakietów widok może być zbyt szybki, aby go śledzić – wtedy zaleca się użycie opcji filtrowania lub przejście do trybu statystyk ogólnych. IP Traffic Monitor nie zapisuje historii, służy wyłącznie do podglądu na żywo.

21/58
General Interface Statistics

General Interface Statistics pokazuje zagregowane statystyki dla wszystkich interfejsów sieciowych:

  • Liczba odebranych/wysłanych pakietów
  • Liczba odebranych/wysłanych bajtów
  • Pakiety/s i bajty/s (średnia)
  • Wykorzystanie pasma (bandwidth utilization)
# Z menu: General Interface Statistics
#
# Przykładowe dane:
# Interface    Pkt In/s  Pkt Out/s  Bytes In/s  Bytes Out/s
# eth0         1250      830        1.2 MB/s     0.8 MB/s
# eth1         0         0          0 B/s        0 B/s

Dane aktualizują się co sekundę. Można wybrać interwał uśredniania (2, 5, 10, 30 s).

General Interface Statistics agreguje dane o ruchu na wszystkich interfejsach sieciowych i prezentuje je w formie tabeli aktualizowanej co sekundę. Każdy wiersz tabeli odpowiada jednemu interfejsowi i zawiera: liczbę pakietów odebranych i wysłanych od początku pomiaru (total), bieżącą szybkość w pakietach na sekundę (Pkt In/s, Pkt Out/s) oraz bieżącą szybkość w bajtach na sekundę (Bytes In/s, Bytes Out/s).

U dołu ekranu wyświetlane są zagregowane wartości sumaryczne dla wszystkich interfejsów. Można zmienić interwał uśredniania (domyślnie 2 sekundy) za pomocą klawisza s (settings) – dostępne wartości to 2, 5, 10 i 30 sekund. Dłuższy interwał daje bardziej stabilne odczyty, krótszy pozwala na obserwację chwilowych skoków ruchu.

22/58
Detailed Interface Statistics

Detailed Interface Statistics zawiera szczegółowe dane o błędach interfejsów:

  • CRC errors
  • Collisions
  • Runts (ramki za krótkie, < 64 B)
  • Giants (ramki za długie, > 1518 B)
  • Frame errors
  • Overruns / underruns
# Z menu: Detailed Interface Statistics -> eth0
#
# CRC errors:         12
# Collisions:          3
# Runts:               0
# Giants:              1
# Frame errors:        5
Wysoka liczba błędów CRC wskazuje na uszkodzony kabel lub zakłócenia elektromagnetyczne. Collisions w sieci przełączanej sugerują problem z duplexem.

Detailed Interface Statistics dostarcza informacji o błędach na poziomie warstwy łącza danych. Błędy CRC (Cyclic Redundancy Check) występują, gdy suma kontrolna ramki Ethernet nie zgadza się z obliczoną wartością – najczęściej przyczyną są uszkodzone kable, zakłócenia elektromagnetyczne lub uszkodzone interfejsy sieciowe. Wartość CRC errors powyżej 0,1% wszystkich ramek jest uważana za nieakceptowalną.

Runts (ramki krótsze niż 64 bajty) i giants (ramki dłuższe niż 1518 bajtów lub 1522 z VLAN) wskazują na problemy z kartą sieciową lub przełącznikiem. Collisions występują tylko w sieciach half-duplex – w nowoczesnych sieciach przełączanych full-duplex kolizje nie powinny występować; jeśli występują, sugerują problem z autonegocjacją duplexu. Overruns i underruns wskazują na problemy z buforowaniem w karcie sieciowej.

23/58
TCP Connection Monitor

TCP Connection Monitor wyświetla wszystkie aktywne połączenia TCP przechodzące przez interfejs:

  • Adres i port źródłowy
  • Adres i port docelowy
  • Stan połączenia (ESTABLISHED, SYN_SENT, TIME_WAIT itp.)
  • Ilość przesłanych danych
# Z menu: TCP Connection Monitor
#
# Source           Destination      State        Bytes
# 192.168.1.5:54321 10.0.0.1:443   ESTABLISHED  1.2K
# 192.168.1.5:54322 10.0.0.1:443   TIME_WAIT    0.4K
# 192.168.1.5:54323 8.8.8.8:53     ESTABLISHED  0.1K

Pomocne przy wykrywaniu nieautoryzowanych połączeń lub podejrzanej aktywności sieciowej.

TCP Connection Monitor wyświetla listę wszystkich aktywnych połączeń TCP przechodzących przez monitorowany interfejs. Dla każdego połączenia pokazywane są: adres źródłowy i docelowy (z portami), stan połączenia w danym momencie (np. ESTABLISHED, SYN_SENT, TIME_WAIT, CLOSE_WAIT) oraz liczba bajtów przesłanych w ramach tego połączenia.

Monitorowanie połączeń TCP jest szczególnie przydatne przy wykrywaniu nieautoryzowanych połączeń, nietypowych ilości połączeń w stanie SYN_SENT (możliwy atak SYN flood) lub połączeń do podejrzanych adresów IP. Tryb ten pozwala na szybką identyfikację procesów generujących ruch sieciowy bez użycia narzędzi takich jak netstat czy ss.

24/58
LAN Station Statistics

LAN Station Statistics zbiera dane o hostach w sieci lokalnej (na podstawie adresów MAC):

  • Adres MAC hosta
  • Adres IP
  • Liczba odebranych/wysłanych pakietów
  • Liczba odebranych/wysłanych bajtów
# Z menu: LAN Station Statistics -> eth0
#
# MAC             IP              Pkt In  Pkt Out
# AA:BB:CC:DD:EE  192.168.1.10   15000   12000
# 11:22:33:44:55  192.168.1.20    8000    5000

Pozwala szybko zidentyfikować hosta generującego najwięcej ruchu w sieci LAN.

LAN Station Statistics zbiera dane o ruchu generowanym przez poszczególne hosty w sieci lokalnej na podstawie ich adresów MAC. Ponieważ iptraf-ng analizuje ruch na poziomie warstwy 2, może identyfikować hosty nawet wtedy, gdy komunikują się one wyłącznie w ramach jednej podsieci (bez routingu).

Statystyki są agregowane per adres MAC i obejmują: adres IP powiązany z danym MAC (jeśli jest widoczny w ruchu), liczbę odebranych i wysłanych pakietów oraz liczbę odebranych i wysłanych bajtów. Tryb ten jest niezastąpiony przy identyfikacji hosta generującego najwięcej ruchu w sieci LAN – wystarczy posortować wyniki według Bytes Out, aby znaleźć „winowajcę”.

25/58
Logowanie iptraf

iptraf może zapisywać statystyki do pliku w trybie background (demon):

# Uruchomienie z logowaniem
sudo iptraf-ng -B -L /var/log/iptraf/iptraf.log \
    -i eth0 -t 300

# Parametry:
# -B         tryb background
# -L plik    zapis logu do pliku
# -i intf    monitorowany interfejs
# -t sek     czas działania (tu: 300s = 5 min)

# Zatrzymanie:
sudo pkill iptraf-ng

Plik logu zawiera wpisy w formacie CSV. Można go analizować w arkuszach kalkulacyjnych lub skryptach.

Tryb background (opcja -B) uruchamia iptraf-ng jako proces demona, który działa w tle i zapisuje wyniki do pliku logu. Jest to szczególnie przydatne w środowiskach produkcyjnych, gdzie nie ma dostępu do terminala lub gdy pomiary mają być wykonywane automatycznie przez dłuższy czas. Plik logu jest otwierany i zamykany dla każdego wpisu, co zapobiega utracie danych w przypadku awarii.

Format CSV pliku logu zawiera znaczniki czasowe, co umożliwia import do arkuszy kalkulacyjnych (Excel, LibreOffice Calc) lub baz danych (InfluxDB, TimescaleDB) w celu dalszej analizy i wizualizacji. Można również użyć narzędzi takich jak awk, sed czy Python do przetwarzania logów i generowania raportów. Dla długotrwałego monitorowania warto skonfigurować rotację logów (logrotate) i ograniczenie rozmiaru pliku (-t czas).

26/58
iptraf w skryptach

iptraf może być używany w skryptach do automatycznego zbierania statystyk:

#!/bin/bash
# Skrypt zbierający statystyki iptraf
LOG_FILE="/tmp/iptraf_report_$(date +%Y%m%d_%H%M).log"

# Uruchom iptraf na 60 sekund
sudo iptraf-ng -B -L $LOG_FILE -i eth0 -t 60

# Odczekaj na zakończenie
sleep 65

# Wygeneruj raport z logu
echo "=== IPTRAF Report ==="
echo "Total bytes in:"
grep "Total" $LOG_FILE | awk '{sum+=$5} END {print sum}'
echo "Total bytes out:"
grep "Total" $LOG_FILE | awk '{sum+=$8} END {print sum}'

Przykładowy skrypt bash pokazuje, jak zautomatyzować pomiar iptraf-ng w celu cyklicznego zbierania statystyk. Zmienna LOG_FILE zawiera znacznik czasu w nazwie pliku (date +%Y%m%d_%H%M), co pozwala na archiwizację wielu pomiarów bez nadpisywania. Opcja -t 60 ogranicza czas działania do 60 sekund, po czym iptraf-ng kończy pracę i zapisuje log.

Po zakończeniu pomiaru skrypt odczekuje 65 sekund (sleep 65) na bezpieczne sfinalizowanie zapisu logu, a następnie przetwarza plik za pomocą grep i awk, aby wyciągnąć zagregowane wartości. Skrypt można uruchomić jako zadanie cron (np. co godzinę) w celu długoterminowego monitorowania ruchu sieciowego.

27/58
Porównanie: iptraf vs nload vs bmon vs iftop
Narzędzie GUI/TUI TCP per connection LAN per host Logowanie
iptraf-ng TUI Tak Tak Tak (CSV)
nload TUI Nie Nie Nie
bmon TUI Nie Nie Nie
iftop TUI Tak (tylko IP:port) Nie Nie
nethogs TUI Nie (per proces) Nie Nie
iptraf-ng jest najbardziej wszechstronnym narzędziem TUI do monitorowania ruchu. Jeśli potrzebujesz widoku per proces, użyj nethogs.

Wybór narzędzia do monitorowania ruchu zależy od konkretnych potrzeb. iptraf-ng jest najbardziej wszechstronny, oferując monitorowanie TCP per connection, statystyki per host w LAN oraz zapis logów. nload jest najprostszy – pokazuje tylko bieżące wykorzystanie pasma w formie dwóch wykresów słupkowych (IN/OUT). bmon oferuje bardziej zaawansowaną wizualizację z histogramami, ale nie śledzi połączeń.

iftop jest podobny do iptraf-ng w monitorowaniu połączeń, ale pokazuje je w formie listy posortowanej według wykorzystania pasma, co ułatwia identyfikację najbardziej aktywnych połączeń. nethogs jest unikalny, ponieważ grupuje ruch według procesów (PID), a nie adresów IP, co ułatwia znalezienie aplikacji generującej ruch. W praktyce często używa się kilku narzędzi równolegle, w zależności od diagnozowanego problemu.

28/58
Przykład: znajdowanie hosta generującego najwięcej ruchu

Scenariusz: Sieć działa wolno. Należy zidentyfikować hosta generującego największy ruch.

# 1. Uruchom iptraf-ng
sudo iptraf-ng

# 2. Wybierz: LAN Station Statistics -> eth0
# 3. Obserwuj kolumnę Pkt Out i Bytes Out
# 4. Host z największymi wartościami to "winowajca"

# Alternatywnie w skrypcie:
sudo iptraf-ng -B -L /tmp/iptraf.log -i eth0 -t 30
grep "LAN" /tmp/iptraf.log | sort -k5 -rn | head -5

Po zidentyfikowaniu hosta można sprawdzić, jakie procesy generują ruch (np. za pomocą nethogs lub netstat).

W opisanym scenariuszu sieć działa wolno, a zadaniem administratora jest znalezienie hosta generującego najwięcej ruchu. iptraf-ng w trybie LAN Station Statistics jest do tego idealnym narzędziem, ponieważ pokazuje ruch per host w sieci lokalnej. Wystarczy uruchomić iptraf-ng, wybrać LAN Station Statistics, wskazać interfejs i obserwować kolumny Pkt Out i Bytes Out.

Alternatywnie, skryptowa wersja (z opcjami -B, -L, -i, -t) pozwala na automatyczne zebranie danych przez określony czas, a następnie przetworzenie logu za pomocą narzędzi uniksowych. Polecenie grep „LAN” /tmp/iptraf.log | sort -k5 -rn | head -5 wyciąga z logu wpisy dotyczące statystyk LAN i sortuje je według piątej kolumny (Bytes Out) malejąco, pokazując 5 najbardziej aktywnych hostów.

29/58
iptraf w diagnostyce – szybkie wykrycie przeciążenia

iptraf jest doskonałym narzędziem do szybkiej diagnostyki:

  • Przeciążenie interfejsu: General Interface Statistics pokaże wykorzystanie pasma bliskie 100%
  • Błędy łącza: Detailed Interface Statistics – wysoka liczba CRC/collision
  • Podejrzane połączenia: TCP Connection Monitor – nietypowe destination IP/port
  • Broadcast storm: IP Traffic Monitor – duża liczba pakietów broadcast
# Szybki test przeciążenia:
# Jeśli General Interface Statistics pokazuje
# Bytes In/s = 0 i wiele błędów ->
# prawdopodobnie uszkodzony kabel lub switch

Szybka diagnostyka z użyciem iptraf-ng powinna przebiegać według schematu: (1) IP Traffic Monitor – sprawdź, czy na interfejsie pojawia się jakikolwiek ruch; (2) General Interface Statistics – sprawdź ogólne wykorzystanie pasma; (3) Detailed Interface Statistics – sprawdź błędy warstwy 2 (CRC, collisions, runts); (4) TCP Connection Monitor – sprawdź aktywne połączenia; (5) LAN Station Statistics – zidentyfikuj najbardziej aktywne hosty.

Jeśli General Interface Statistics pokazuje wykorzystanie pasma bliskie 100% przez dłuższy czas, oznacza to przeciążenie łącza. Wysoka liczba błędów CRC (powyżej 0,01% wszystkich ramek) sugeruje problem fizyczny z okablowaniem lub zakłócenia. Nagły wzrost liczby połączeń TCP z różnych adresów źródłowych na ten sam port docelowy może wskazywać na atak DDoS lub skanowanie portów.

30/58
Czym jest netcat?

Netcat (nc) to uniwersalne narzędzie sieciowe, nazywane "scyzorykiem szwajcarskim" sieci komputerowych. Umożliwia:

  • Tworzenie połączeń TCP i UDP
  • Nasłuch na portach (serwer TCP/UDP)
  • Skanowanie portów
  • Przesyłanie plików
  • Bannergrabbing
  • Tworzenie prostych serwerów usług
# Podstawowa składnia
nc [opcje] [host] [port]
Netcat istnieje w wielu wariantach: tradycyjny nc, OpenBSD nc (domyślny w wielu dystrybucjach), ncat (z pakietu Nmap) – różnią się składnią opcji.

Netcat jest często nazywany „scyzorykiem szwajcarskim” sieci komputerowych ze względu na swoją wszechstronność – jedno narzędzie może zastąpić wiele innych (telnet, ping, port scanner, file transfer). Pierwsza wersja netcat została napisana przez Hobnoba (właśc. Chris Wysopal) w 1995 roku i od tego czasu doczekała się wielu implementacji i rozszerzeń.

Różne warianty netcat mają różną składnię opcji, co może prowadzić do błędów przy przenoszeniu skryptów między systemami. Wariant OpenBSD (nc) jest domyślnym w większości dystrybucji Linux i ma składnię, w której opcja -p musi wystąpić przed -l w trybie nasłuchu. Ncat z pakietu Nmap dodaje obsługę SSL, IPv6, SCTP, proxy SOCKS i skryptowania w Lua, co czyni go najbogatszym wariantem.

31/58
Instalacja netcat
# Linux (Debian/Ubuntu) – tradycyjny netcat
sudo apt update
sudo apt install netcat-traditional
sudo update-alternatives --set nc /usr/bin/nc.traditional

# Linux – wersja OpenBSD
sudo apt install netcat-openbsd

# Linux – ncat z Nmap
sudo apt install ncat

# Windows – z Npcap
# Pobierz i zainstaluj Npcap z https://npcap.com
# ncat.exe jest dołączony do Npcap

W systemach Debian/Ubuntu dostępne są dwa pakiety: netcat-traditional (wersja klasyczna, stabilna, dobrze udokumentowana) i netcat-openbsd (wersja OpenBSD z nieco inną składnią). Polecenie update-alternatives pozwala wybrać, która wersja jest domyślnie uruchamiana jako nc.

Ncat z pakietu Nmap jest instalowany wraz z nmap (w systemach Linux jako pakiet ncat) i oferuje najwięcej funkcji, ale ma też największy narzut pamięciowy. Dla Windows ncat.exe jest dołączany do instalatora Npcap (wcześniej WinPcap) lub dostępny jako samodzielny plik do pobrania z sekcji Nmap na oficjalnej stronie.

32/58
Podstawowa składnia netcat
# Ogólna składnia (OpenBSD netcat):
nc [opcje] [host] [port]

# Główne opcje:
-l     tryb nasłuchu (listen)
-p     numer portu
-v     verbose (szczegółowe informacje)
-u     tryb UDP (domyślnie TCP)
-z     zero I/O (tylko skanowanie)
-w N   timeout po N sekundach
-n     bez rozwiązywania DNS
-4     użyj IPv4
-6     użyj IPv6
Kolejność opcji ma znaczenie! W OpenBSD netcat opcja -p musi wystąpić przed -l . W tradycyjnym nc i ncat kolejność jest bardziej elastyczna.

Opcja -l (listen) przełącza netcat w tryb serwera – nasłuchuje na podanym porcie i czeka na połączenie przychodzące. Bez opcji -l netcat działa jako klient, próbując połączyć się z podanym hostem i portem. Opcja -v (verbose) wyświetla dodatkowe informacje, takie jak adres IP łączącego się klienta (w trybie nasłuchu) lub informację o udanym połączeniu (w trybie klienta).

W wariancie OpenBSD netcat (domyślnym w Ubuntu od wersji 18.04) składnia różni się od tradycyjnego nc: opcja -p określa port lokalny i musi wystąpić przed -l. W tradycyjnym nc można pominąć -p przy użyciu -l (port podaje się jako ostatni argument). Nmap Ncat używa opcji --listen zamiast -l, ale zachowuje zgodność z -l dla wygody.

33/58
Klient TCP

Netcat jako klient TCP łączy się z wybranym hostem i portem:

# Połączenie z serwerem WWW
nc -v 192.168.1.1 80

# Połączenie z serwerem SSH
nc -v 10.0.0.1 22

# Połączenie z serwerem SMTP
nc -v mail.example.com 25

# Z timeoutem 5 sekund
nc -v -w 5 192.168.1.1 80

Po nawiązaniu połączenia można wysyłać dane (np. żądanie HTTP) i odbierać odpowiedzi. Połączenie trwa do zamknięcia przez jedną ze stron.

Netcat jako klient TCP nawiązuje połączenie z wybranym hostem na określonym porcie i połącza standardowe wejście (stdin) z gniazdem sieciowym. Oznacza to, że wszystko, co użytkownik wpisze w konsoli, zostanie wysłane przez gniazdo, a wszystkie dane odebrane z gniazda zostaną wyświetlone na standardowym wyjściu (stdout). Działa to jak dwukierunkowa linia komunikacyjna.

Połączenie z serwerem WWW na porcie 80 pozwala na ręczne wysłanie żądania HTTP (np. GET / HTTP/1.0) i zobaczenie surowej odpowiedzi serwera. Jest to przydatne do debugowania serwerów WWW bez użycia przeglądarki. Po nawiązaniu połączenia netcat utrzymuje je otwarte, dopóki jedna ze stron nie zamknie gniazda lub nie zostanie naciśnięty Ctrl+C.

34/58
Serwer TCP (nasłuch)

Netcat może działać jako serwer TCP – nasłuchiwać na wybranym porcie:

# Nasłuch na porcie 4444
nc -lvp 4444

# Nasłuch na porcie 4444, odpowiedź po połączeniu
echo "Hello, client!" | nc -lvp 4444

# Nasłuch na porcie 80 – prosty serwer WWW
while true; do
  echo -e "HTTP/1.1 200 OK\r\n\r\n

Test

"
| nc -lvp 80 done
Uwaga: na porcie < 1024 potrzebujesz uprawnień root! Pamiętaj o zasadach firewalla.

Netcat w trybie nasłuchu (nc -lvp port) tworzy serwer TCP, który czeka na połączenie przychodzące od klienta. Po nawiązaniu połączenia dane z klienta są wyświetlane na konsoli serwera, a dane wpisane na konsoli serwera są wysyłane do klienta. Jest to prosty, ale w pełni funkcjonalny zdalny czat (chat server), działający bez żadnych dodatkowych usług.

Serwer HTTP z netcat w pętli while pokazuje, jak łatwo stworzyć prosty serwer WWW do testów – każdy klient otrzyma tę samą statyczną odpowiedź HTML. W praktyce taki serwer jest używany do testowania konfiguracji firewalla, sprawdzania, czy port jest dostępny z zewnątrz, lub jako prosty honeypot do wykrywania skanowania portów.

35/58
Przesyłanie plików przez netcat

Netcat umożliwia przesyłanie plików między hostami:

# Strona odbierająca (serwer)
nc -lvp 4444 > odebrany_plik.zip

# Strona wysyłająca (klient)
nc 192.168.1.100 4444 < plik_do_wyslania.zip

# Z paskiem postępu (pv)
# Wysyłający:
pv plik_do_wyslania.zip | nc 192.168.1.100 4444
# Odbierający:
nc -lvp 4444 | pv > odebrany_plik.zip
Przesyłanie przez nc NIE jest szyfrowane. Do bezpiecznego transferu używaj nc z tunelem SSH lub użyj ncat z SSL ( --ssl ).

Przesyłanie plików przez netcat odbywa się przez przekierowanie strumieni: po stronie odbierającej przekierowuje się standardowe wyjście netcat do pliku (> nazwa_pliku), a po stronie wysyłającej przekierowuje się zawartość pliku na standardowe wejście netcat (< nazwa_pliku). Należy pamiętać, aby najpierw uruchomić stronę odbierającą (nasłuch), a dopiero potem wysyłającą (klient).

Transfer jest nieszyfrowany, co oznacza, że każdy w sieci mogący przechwycić pakiety TCP zobaczy całą zawartość przesyłanego pliku. Do bezpiecznego transferu plików przez netcat można użyć tunelu SSH (ssh -L lokalny_port:cel:docelowy_port użytkownik@serwer) lub ncat z opcją --ssl, która szyfruje transmisję za pomocą TLS. Narzędzie pv (Pipe Viewer) dodaje pasek postępu i szacowany czas transferu.

36/58
Skanowanie portów TCP

Netcat może skanować porty TCP na wybranym hoście:

# Skanowanie pojedynczego portu
nc -zv 192.168.1.1 80

# Skanowanie zakresu portów
nc -zv 192.168.1.1 20-100

# Skanowanie wielu portów z verbose
nc -zv 192.168.1.1 22 80 443 8080

# Skanowanie z timeoutem (szybsze odrzucenie)
nc -zv -w 2 192.168.1.1 1-1000
Opcja -z (zero I/O) sprawia, że nc nie wysyła danych po nawiązaniu połączenia – tylko sprawdza, czy port jest otwarty. -v wyświetla wynik.

Skanowanie portów z użyciem netcat (nc -zv) jest prostą, ale skuteczną metodą sprawdzenia, które porty TCP są otwarte na danym hoście. Opcja -z (zero I/O) sprawia, że netcat zrywa połączenie natychmiast po nawiązaniu, bez wysyłania danych – wystarczy mu informacja, czy port zaakceptował połączenie (otwarty) czy odrzucił (zamknięty).

Skanowanie zakresu portów (np. 20-100) jest sekwencyjne – netcat próbuje połączyć się z każdym portem po kolei. Może to być wolne przy skanowaniu dużych zakresów (np. 1-65535). Dodanie opcji -w 2 (timeout 2 sekundy) przyspiesza skanowanie, ponieważ netcat nie czeka dłużej niż 2 sekundy na odpowiedź portu. Do bardziej zaawansowanego skanowania zaleca się Nmap, który oferuje różne typy skanowania (SYN, FIN, NULL, Xmas) i wykrywanie wersji usług.

37/58
Skanowanie portów UDP

Skanowanie UDP jest trudniejsze niż TCP, ponieważ UDP nie ma mechanizmu potwierdzenia połączenia:

# Skanowanie UDP na porcie DNS
nc -zuv 192.168.1.1 53

# Skanowanie zakresu portów UDP
nc -zuv 192.168.1.1 1-1024

# Skanowanie UDP z timeoutem
nc -zuv -w 2 192.168.1.1 53 123 161

# Z verbose
nc -zuv -v 192.168.1.1 53
Skanowanie UDP jest wolniejsze niż TCP, ponieważ nc czeka na ICMP Port Unreachable (który może być blokowany przez firewall). Otwarty port UDP może nie odpowiedzieć, co daje fałszywy wynik.

Skanowanie UDP jest trudniejsze niż TCP, ponieważ UDP jest protokołem bezstanowym – serwer UDP nie wysyła potwierdzenia nawiązania połączenia, więc netcat nie może stwierdzić, czy port jest otwarty przez sam fakt nawiązania połączenia. Zamiast tego netcat wysyła pakiet UDP na dany port i czeka na odpowiedź. Jeśli port jest zamknięty, serwer powinien odpowiedzieć pakietem ICMP Port Unreachable (typ 3, kod 3).

Brak odpowiedzi może oznaczać, że port jest otwarty (usługa po prostu nie odpowiedziała), zamknięty (ICMP Port Unreachable został zablokowany przez firewall) lub że pakiet UDP został utracony w sieci. Z tego powodu skanowanie UDP jest wolniejsze i mniej wiarygodne niż TCP. Do skanowania UDP zaleca się użycie Nmap z opcją -sU, który stosuje zaawansowane techniki detekcji.

38/58
Klient UDP

Netcat jako klient UDP:

# Zapytanie DNS (port 53)
nc -u 192.168.1.1 53

# Wysłanie syslog (port 514)
echo "<14>test message" | nc -u 192.168.1.1 514

# Komunikacja z serwerem NTP
nc -u -w 2 192.168.1.1 123
UDP to protokół bezstanowy – nie ma potwierdzenia dostarczenia pakietu. Używaj opcji -w (timeout) dla uniknięcia zawieszenia.

Netcat jako klient UDP (nc -u) działa podobnie jak w trybie TCP, ale używa protokołu UDP bez nawiązywania połączenia. Dane są wysyłane w datagramach UDP, a odpowiedź (jeśli nadejdzie) jest wyświetlana na konsoli. Przykładem praktycznego zastosowania jest wysłanie syslogu na serwer syslog (port 514) – datagram UDP z komunikatem <14>test message zostanie wysłany i następnie odebrany przez serwer.

W komunikacji z serwerem NTP (Network Time Protocol, port 123) netcat wysyła zapytanie NTP i czeka na odpowiedź z czasem systemowym serwera. Należy pamiętać, że protokół NTP wymaga specyficznego formatu pakietu, więc wysłanie surowego tekstu nie zadziała – do poprawnej komunikacji z NTP używa się dedykowanego klienta ntpdate lub ntpd.

39/58
Bannergrabbing

Bannergrabbing to technika zbierania informacji o usługach sieciowych poprzez odczytanie ich powitalnego komunikatu (banner):

# HTTP
echo -e "GET / HTTP/1.0\r\n" | nc -w 2 192.168.1.1 80

# SSH
nc -w 2 192.168.1.1 22

# SMTP
nc -w 2 mail.example.com 25

# FTP
nc -w 2 192.168.1.1 21

# POP3
nc -w 2 192.168.1.1 110

Wynik: wersja serwera WWW (np. Apache/2.4.41), wersja SSH (OpenSSH_8.9p1) itp. – przydatne w testach penetracyjnych.

Bannergrabbing polega na odczytaniu powitalnego komunikatu (banner) wysyłanego przez usługę sieciową po nawiązaniu połączenia. Banner często zawiera informacje o typie i wersji oprogramowania (np. Apache/2.4.41, OpenSSH_8.9p1), co jest niezwykle przydatne w testach penetracyjnych do identyfikacji podatności (vulnerability assessment).

W przypadku HTTP wysłanie GET / HTTP/1.0 powoduje, że serwer WWW odpowiada nagłówkami HTTP zawierającymi banner (Server: Apache/2.4.41 (Ubuntu)). SSH i SMTP wysyłają banner natychmiast po nawiązaniu połączenia, bez konieczności wysyłania danych. Banner można również przechwycić dla FTP (220 Serwer FTP ready), POP3 (+OK POP3 server ready) i wielu innych protokołów.

40/58
Serwer UDP

Netcat jako serwer UDP:

# Nasłuch UDP na porcie 4444
nc -ulvp 4444

# Nasłuch UDP z zapisem odebranych danych do pliku
nc -ulvp 4444 > odebrane_udp.txt

# Echo server (odbiera i wysyła z powrotem)
while true; do
  nc -ulvp 4444 -c 'read line; echo "$line"'
done

Serwer UDP nasłuchuje na datagramy. Każdy odebrany datagram wywołuje odpowiedź (jeśli skonfigurowana). Możliwe jest również tworzenie własnych protokołów komunikacyjnych.

Serwer UDP z netcat (nc -ulvp port) nasłuchuje na datagramy UDP. W odróżnieniu od TCP, UDP nie nawiązuje połączenia – każdy datagram jest przetwarzany niezależnie. Po odebraniu datagramu netcat wyświetla go na konsoli i czeka na kolejny. Serwer UDP z netcat jest często używany do testowania, czy aplikacje wysyłające dane przez UDP działają poprawnie.

Przykładem zastosowania jest debugowanie aplikacji IoT wysyłających dane pomiarowe przez UDP – serwer netcat odbierze i wyświetli surowe datagramy, co pozwala na weryfikację formatu danych bez pisania dedykowanego odbiornika. Serwer UDP może również zapisywać odebrane dane do pliku (nc -ulvp 4444 > odebrane_udp.txt) w celu późniejszej analizy.

41/58
Opcja -w (timeout)

Opcja -w określa maksymalny czas oczekiwania na połączenie lub dane:

# Timeout 5 sekund na połączenie
nc -w 5 192.168.1.1 22

# Timeout 2 sekundy – skanowanie
nc -zv -w 2 192.168.1.1 20-100

# Timeout dla nasłuchu – zakończ po 10s bez danych
nc -lvp 4444 -w 10

# Timeout w trybie UDP
nc -u -w 3 192.168.1.1 53
Domyślnie nc czeka bez ograniczenia czasowego. Użycie -w zapobiega zawieszaniu się skryptów.

Opcja -w (timeout) w netcat określa maksymalny czas oczekiwania na zdarzenie sieciowe, mierzony w sekundach. W trybie klienta -w określa czas oczekiwania na nawiązanie połączenia TCP. W trybie nasłuchu -w określa czas oczekiwania na dane po nawiązaniu połączenia – jeśli w ciągu N sekund nie nadejdą żadne dane, netcat kończy działanie.

Domyślnie netcat czeka bez ograniczenia czasowego, co może prowadzić do zawieszenia się skryptu, jeśli połączenie nie zostanie nawiązane (host nieosiągalny, firewall blokuje port). Dlatego w skryptach i skanowaniu portów zawsze zaleca się użycie -w z wartością 2-5 sekund. W trybie UDP opcja -w jest szczególnie ważna, ponieważ UDP nie ma mechanizmu timeoutu połączenia.

42/58
Opcja -z (zero I/O)

Opcja -z (zero I/O) powoduje, że netcat nie wysyła żadnych danych po nawiązaniu połączenia – tylko sprawdza, czy port jest otwarty:

# Skanowanie – tylko sprawdzenie otwartych portów
nc -zv 192.168.1.1 22 80 443

# Skanowanie zakresu
nc -zv 192.168.1.1 1-1000

# Skanowanie z verbose
nc -zv -w 2 192.168.1.1 20-100

# Bez -z: nc wysyła dane (np. w konsoli)
# Z -z: nc zamyka połączenie natychmiast po nawiązaniu

Wynik: lista otwartych/zamkniętych portów. Szybsze niż pełne połączenie.

Opcja -z (zero I/O) jest kluczowa dla wydajnego skanowania portów. Bez -z netcat po nawiązaniu połączenia pozostaje w trybie interaktywnym, czekając na dane z klawiatury i wyświetlając dane z gniazda. Z -z netcat zamyka gniazdo natychmiast po nawiązaniu połączenia, co pozwala na szybkie sprawdzenie setek portów w krótkim czasie.

W praktyce nc -zv 192.168.1.1 22 80 443 sprawdzi trzy porty w ciągu kilku sekund. Każdy port jest testowany sekwencyjnie – widać to w outputcie, gdzie pojawia się komunikat succeeded! dla otwartych portów i Connection refused dla zamkniętych. Do szybszego skanowania setek portów równolegle lepiej użyć Nmap (nmap -T4 -F 192.168.1.1).

43/58
Opcja -v (verbose)

Opcja -v (verbose) włącza szczegółowe komunikaty:

# Bez -v (ciche działanie)
nc 192.168.1.1 22

# Z -v (wyświetla informacje o połączeniu)
nc -v 192.168.1.1 22

# Z -vv (jeszcze więcej szczegółów – wersja OpenBSD)
nc -vv 192.168.1.1 22

# Z -v przy skanowaniu
nc -zv 192.168.1.1 22 80 443
W trybie nasłuchu (-l) opcja -v wyświetla adres IP łączącego się klienta. W innych wariantach nc -vv może dodać informacje o MTU, TTL i innych parametrach.

Opcja -v (verbose) zwiększa szczegółowość komunikatów netcat. W trybie klienta -v wyświetla informację o udanym połączeniu (Connection to host port succeeded!) lub błędzie (Connection refused). W trybie nasłuchu -v wyświetla adres IP i port łączącego się klienta, co pozwala na śledzenie, kto i skąd nawiązuje połączenie.

W wariancie OpenBSD netcat podwójna opcja -vv dodaje jeszcze więcej szczegółów, takich jak informacje o MTU, TTL i oknie TCP. W tradycyjnym netcat -vv wyświetla dodatkowe komunikaty diagnostyczne podczas zamykania połączenia. W ncat (Nmap) -v akceptuje wartości od 0 (cichy) do 3 (bardzo szczegółowy) i -v4 wyświetla pakiety w hex.

44/58
Opcja -n (bez DNS)

Opcja -n wyłącza rozwiązywanie nazw DNS. Netcat nie wykonuje zapytań DNS dla adresów IP:

# Z DNS (domyślnie) – może być wolne
nc -v 192.168.1.1 22
# Output: Connection to 192.168.1.1 (hostname.example.com) port 22 [tcp/ssh] succeeded!

# Bez DNS – szybsze
nc -vn 192.168.1.1 22
# Output: Connection to 192.168.1.1 port 22 [tcp/ssh] succeeded!

# Skanowanie bez DNS (znacznie szybsze)
nc -zvn 192.168.1.1 1-1000
Używaj -n zawsze przy skanowaniu portów i gdy nie potrzebujesz nazw hostów – przyspiesza to działanie o 10-50x przy skanowaniu wielu portów.

Opcja -n wyłącza rozwiązywanie nazw DNS przez netcat. Domyślnie netcat wykonuje odwrotne zapytanie DNS (reverse DNS lookup) dla każdego adresu IP, co może znacząco spowolnić działanie, szczególnie przy skanowaniu wielu portów lub hostów. Zapytanie DNS może trwać od kilku milisekund (lokalny DNS cache) do kilku sekund (jeśli serwer DNS jest wolny lub nie odpowiada).

Przy skanowaniu zakresu 1-1000 portów różnica między nc -zv a nc -zvn może wynosić od kilkudziesięciu sekund do kilku minut. Dlatego w skryptach automatycznych i przy skanowaniu zawsze używa się -n. Dodatkowo -n zapobiega wyciekom informacji – serwer DNS nie dowie się, jakie adresy IP są skanowane.

45/58
netcat + skrypty – automatyzacja

Netcat doskonale współpracuje ze skryptami bash:

#!/bin/bash
# Skaner portów z użyciem nc
HOST=$1
PORTS=$2
for PORT in $(seq $PORTS); do
  nc -zv -w 1 $HOST $PORT 2>&1 | grep -q "succeeded" &&
    echo "Port $PORT is OPEN"
done

# Szybki serwer HTTP
while true; do
  { echo -ne "HTTP/1.1 200 OK\r\n"
    echo -ne "Content-Length: 5\r\n\r\n"
    echo "Hello"; } | nc -lvp 8080
done

# Monitorowanie usługi
while true; do
  nc -zw 3 example.com 80 && echo "UP" || echo "DOWN"
  sleep 10
done

Netcat doskonale integruje się ze skryptami bash, co pozwala na automatyzację typowych zadań sieciowych. Przykładowy skaner portów w pętli for iteruje przez zadany zakres portów i dla każdego wykonuje nc -zv z timeoutem 1 sekundy. Jeśli grep znajdzie w outputcie słowo „succeeded”, port jest oznaczony jako otwarty. Jest to prosty, ale w pełni funkcjonalny skaner portów.

Serwer HTTP w pętli while pokazuje, jak utworzyć prosty serwer WWW w jednej linii – po każdym połączeniu klient otrzymuje odpowiedź HTTP z treścią „Hello”. Monitorowanie usługi w pętli while z nc -zw (zero I/O + timeout) pozwala na ciągłe sprawdzanie dostępności usługi i zapisywanie logów z datami i statusami.

46/58
Porównanie: nc vs ncat vs socat
Funkcja nc (tradycyjny) ncat (Nmap) socat
TCP/UDP Tak Tak Tak
SSL/TLS Nie Tak (--ssl) Tak
IPv6 Częściowo Tak Tak
SCTP Nie Tak Nie
Przekierowanie portów Nie Tak Tak
Proxy (SOCKS/HTTP) Nie Tak Tak
Separacja stdin/stdout Nie Nie Tak
Skryptowanie Lua Nie Tak Nie
Do prostych zadań: nc. Do bezpiecznej transmisji: ncat z --ssl. Do zaawansowanych: socat (szczególnie przekierowanie portów i łączenie strumieni).

Wybór między nc, ncat i socat zależy od złożoności zadania. Do prostych czynności, takich jak sprawdzenie dostępności portu, skanowanie portów czy bannergrabbing, w pełni wystarczy tradycyjny netcat (nc). Mały rozmiar pliku (kilkadziesiąt KB) i minimalne zużycie pamięci czynią go idealnym do dołączania do skryptów i obrazów Docker.

Ncat z pakietu Nmap dodaje obsługę SSL/TLS (--ssl), co pozwala na szyfrowanie transmisji bez użycia OpenSSL s_client. Ncat może również działać jako serwer proxy (--proxy, --proxy-type), przekierowywać porty (--sh-exec, --keep-open) i wykonywać skrypty Lua. Socat oferuje największą elastyczność – może łączyć dowolne strumienie danych (gniazda, pliki, potoki, urządzenia) w dowolnej kombinacji.

47/58
Czym jest packeth?

Packeth to graficzny generator pakietów Ethernet dla Linux. Umożliwia:

  • Ręczne budowanie ramek Ethernet
  • Ustawianie pól: MAC src/dst, EtherType, VLAN tag, payload
  • Wysyłanie pojedynczych pakietów lub serii
  • Testowanie firewall, ACL, reguł przełączników
# Packeth działa w trybie GUI (GTK+)
# Wymaga uprawnień root do tworzenia surowych gniazd
Packeth jest prostszy niż Scapy czy hping3 – idealny do szybkich testów ramek Ethernet bez programowania.

Packeth jest narzędziem graficznym (GTK+) do tworzenia i wysyłania pojedynczych ramek Ethernet. W odróżnieniu od narzędzi takich jak hping3 czy Scapy, packeth nie wymaga znajomości składni wiersza poleceń ani programowania – wszystkie parametry ramki są wprowadzane w formularzu graficznym. Jest to szczególnie przydatne dla osób uczących się budowy ramek Ethernet.

Packeth umożliwia modyfikację wszystkich pól ramki Ethernet warstwy 2: adresów MAC (źródłowego i docelowego), pola EtherType (lub długości w standardzie IEEE 802.3), tagu VLAN 802.1Q oraz payloadu w formacie hex lub ASCII. Narzędzie nie modyfikuje pól warstwy 3 (IP) ani warstwy 4 (TCP/UDP) – jeśli potrzebujemy modyfikować te warstwy, należy użyć hping3 lub Scapy.

48/58
Instalacja packeth
# Instalacja na Debian/Ubuntu
sudo apt update
sudo apt install packeth

# Instalacja ze źródeł (GitHub)
git clone https://github.com/jemcek/packeth.git
cd packeth
sudo apt install libgtk-3-dev libglib2.0-dev
make
sudo make install

# Uruchomienie (wymaga root)
sudo packeth

# Wersja z TUI (jeśli dostępna)
sudo packeth -t

Packeth jest dostępny w domyślnych repozytoriach większości dystrybucji Linux. W systemach opartych na Debianie/Ubuntu instalacja przez apt install packeth jest najprostszą metodą. Instalacja ze źródeł z GitHub może być konieczna w przypadku starszych dystrybucji lub gdy potrzebujemy najnowszej wersji z poprawkami błędów.

Packeth wymaga bibliotek GTK+ 3, dlatego nie działa w czystym terminalu bez serwera X. Do uruchomienia przez SSH można użyć przekierowania X11 (ssh -X) lub VNC. Po instalacji packeth jest uruchamiany jako sudo packeth – uprawnienia root są niezbędne do tworzenia surowych gniazd (raw sockets) na interfejsie sieciowym. Istnieje również wersja z interfejsem tekstowym (TUI) uruchamiana opcją -t, ale ma ona ograniczoną funkcjonalność.

49/58
Interfejs GUI packeth

Główne elementy interfejsu packeth:

  • Pole Destination MAC – adres MAC odbiorcy
  • Pole Source MAC – adres MAC nadawcy
  • Pole EtherType – typ protokołu (0x0800 dla IPv4, 0x0806 dla ARP, 0x8100 dla VLAN)
  • Pole VLAN – identyfikator VLAN (0-4095)
  • Payload – dane ramki (hex lub ASCII)
  • Frame Length – długość ramki (automatycznie lub ręcznie)
  • Przycisk Send – wysłanie jednej ramki
  • Przycisk Send Burst – wysłanie serii ramek
# Przykład: ramka ARP request
# Dst MAC: FF:FF:FF:FF:FF:FF
# Src MAC: AA:BB:CC:DD:EE:FF
# EtherType: 0x0806
Wartość EtherType musi być w formacie hex (0x....). Dla VLAN użyj EtherType 0x8100 i uzupełnij pole VLAN ID.

Interfejs graficzny packeth jest podzielony na sekcje odpowiadające polom ramki Ethernet. W górnej części okna znajdują się pola na adresy MAC (Destination MAC, Source MAC), pole EtherType (w formacie hex, np. 0x0800 dla IPv4, 0x0806 dla ARP) oraz pole VLAN ID (0-4095) i priorytet VLAN (0-7).

W dolnej części okna znajduje się pole na Payload (dane ramki) w formacie hex, gdzie każdy bajt można wprowadzić jako dwie cyfry hex oddzielone spacją. Automatycznie wyświetlana jest długość ramki (Frame Length), którą można również ustawić ręcznie. Przyciski Send i Send Burst wysyłają odpowiednio pojedynczą ramkę lub serię ramek z konfigurowalnym interwałem. Wskazane jest zawsze sprawdzenie sumy kontrolnej FCS – packeth generuje ją automatycznie, chyba że opcja Auto FCS jest wyłączona.

50/58
Budowa ramki Ethernet w packeth

Ramka Ethernet w packeth składa się z:

  • Preambuła (7B) + SFD (1B) – generowane automatycznie, nieedytowalne
  • Destination MAC (6B) – np. FF:FF:FF:FF:FF:FF (broadcast)
  • Source MAC (6B) – np. AA:BB:CC:DD:EE:FF
  • EtherType/Length (2B) – typ protokołu lub długość
  • Payload (46-1500B) – dane użytkownika
  • FCS (4B) – suma kontrolna CRC (generowana automatycznie lub ręcznie)
# Minimalna ramka: 64B (wliczając preambułę: 72B)
# Maksymalna standardowa: 1518B (jumbo frame: do 9000B)
# Payload minimalny: 46B (wypełniany zerami jeśli krótszy)

Budowa ramki Ethernet w packeth odzwierciedla standard IEEE 802.3. Preambuła (7 bajtów naprzemiennych 1 i 0 synchronizujących odbiornik) oraz SFD (Start Frame Delimiter, 1 bajt 10101011) są generowane automatycznie przez kartę sieciową i nie są edytowalne w packeth. Adresy MAC (6 bajtów każdy) są wprowadzane w standardowym formacie hex (np. AA:BB:CC:DD:EE:FF).

Pole EtherType/Length (2 bajty) ma podwójne znaczenie: wartości poniżej 0x0600 (1536 dziesiętnie) oznaczają długość ramki w standardzie IEEE 802.3, a wartości powyżej 0x0600 oznaczają typ protokołu w standardzie Ethernet II. Dla IPv4 używa się EtherType 0x0800, dla ARP 0x0806, dla VLAN 0x8100. Payload musi mieć minimum 46 bajtów (jeśli jest krótszy, packeth uzupełnia zerami) i maksymalnie 1500 bajtów (lub więcej dla jumbo frame). Suma kontrolna FCS (4 bajty CRC32) jest obliczana automatycznie.

51/58
Testowanie firewall i ACL

Packeth pozwala testować reguły firewall i ACL na przełącznikach:

# Scenariusz 1: Test reguły MAC
# Wyślij ramkę z określonym Src MAC
# Sprawdź, czy przełącznik/blokuje przepuszcza

# Scenariusz 2: Test EtherType filter
# Wyślij ramkę z niestandardowym EtherType
# (np. 0x88B8 dla Private VLAN)
# Sprawdź, czy firewall blokuje

# Scenariusz 3: Test VLAN filter
# Ustaw VLAN ID 100
# Wyślij ramkę na port w VLAN 200
# Sprawdź, czy ramka jest odrzucana
Packeth wysyła ramki bezpośrednio na interfejs, omijając stos IP systemu – idealne do testowania reguł warstwy 2.

Testowanie firewall i ACL za pomocą packeth jest skuteczne, ponieważ packeth wysyła ramki bezpośrednio przez surowe gniazdo, omijając stos IP systemu operacyjnego. Oznacza to, że reguły firewalla hosta (iptables, nftables) nie wpływają na wysyłane ramki – są one wysyłane na interfejs niezależnie od reguł filtrowania warstwy 3 i 4.

Scenariusz testowania reguł MAC polega na wysłaniu ramki z określonym źródłowym adresem MAC i sprawdzeniu, czy przełącznik ją przepuszcza (jeśli port security blokuje nieznane MAC, ramka zostanie odrzucona). Testowanie filtrów EtherType pozwala sprawdzić, czy przełącznik lub firewall blokuje niestandardowe typy protokołów. Testowanie VLAN polega na wysłaniu ramki z tagiem VLAN na port należący do innego VLAN-u i sprawdzeniu, czy ramka jest odrzucana (powinna być, jeśli konfiguracja jest poprawna).

52/58
Przykład: wysłanie ramki z niestandardowym EtherType

Niestandardowe EtherType są używane w protokołach przemysłowych (EtherCAT, PROFINET) i zastrzeżonych:

# Przykład: EtherType 0x88A4 (EtherCAT)
# Dst MAC: 01:02:03:04:05:06
# Src MAC: AA:BB:CC:DD:EE:FF
# EtherType: 0x88A4
# Payload: (dane EtherCAT)
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
# (wypełnij do minimum 46B payload)

# Wysłanie: kliknij "Send"
# lub "Send Burst" z interwałem 100ms
EtherType poniżej 0x0600 oznacza długość ramki (standard IEEE 802.3). Powyżej 0x0600 oznacza typ protokołu (Ethernet II).

Niestandardowe wartości EtherType są używane w protokołach przemysłowych (EtherCAT 0x88A4, PROFINET 0x8892, Ethernet/IP 0x0800, POWERLINK 0x88AB) oraz protokołach zastrzeżonych przez producentów (Cisco Discovery Protocol 0x2000, Extreme Networks 0x88B8). Wysłanie ramki z niestandardowym EtherType za pomocą packeth pozwala na testowanie, czy urządzenia sieciowe poprawnie przepuszczają lub blokują te ramki.

W praktyce inżynierowie sieci przemysłowych używają packeth do symulacji ruchu EtherCAT, PROFINET i innych protokołów automatyki. Modyfikacja pól VLAN ID i priorytetu (PCP) pozwala na testowanie mechanizmów QoS (Quality of Service) na przełącznikach przemysłowych. Dla ramki z EtherType 0x88A4 (EtherCAT) należy wypełnić payload danymi zgodnymi ze specyfikacją EtherCAT – ramka musi mieć minimum 46 bajtów, więc resztę można wypełnić bajtami zerowymi.

53/58
Packeth + testy zgodności

Packeth może być używany do testów zgodności urządzeń sieciowych:

  • MTU discovery – wysyłanie ramek o różnych rozmiarach
  • Testowanie obsługi VLAN – wysyłanie ramek z tagiem 802.1Q
  • Testowanie obsługi jumbo frame – ramki > 1518B
  • Testowanie MAC flooding – wysyłanie ramek z losowymi adresami MAC
# Test MTU: wyślij ramkę o rozmiarze 9000B
# Jeśli przełącznik obsługuje jumbo frame -> ramka dotrze
# Jeśli nie -> ramka zostanie odrzucona lub fragmentowana

# Test obsługi VLAN: ramka z EtherType 0x8100
# VLAN ID: 10, Priority: 5
# Sprawdź, czy przełącznik poprawnie taguje

Testy MTU (Maximum Transmission Unit) polegają na wysłaniu ramek o różnych rozmiarach, aby sprawdzić, czy urządzenie sieciowe poprawnie obsługuje standardową ramkę 1518 bajtów oraz jumbo frame (do 9000 bajtów). Jeśli przełącznik nie obsługuje jumbo frame, ramka większa niż 1518 bajtów zostanie odrzucona lub podzielona na fragmenty (fragmentation na warstwie IP, jeśli ramka zawiera pakiet IP).

Testowanie obsługi VLAN 802.1Q polega na wysłaniu ramki z tagiem VLAN (EtherType 0x8100 z odpowiednim VLAN ID i priorytetem) i sprawdzeniu, czy przełącznik poprawnie przekazuje ramkę tylko do portów należących do tego samego VLAN-u. Test MAC flooding (wysyłanie ramek z losowymi źródłowymi adresami MAC) służy do sprawdzenia, jak przełącznik radzi sobie z przepełnieniem tablicy adresów MAC (MAC address table) – przy przepełnieniu przełącznik zaczyna zachowywać się jak hub, wysyłając ramki na wszystkie porty.

54/58
Porównanie: packeth vs hping3 vs Scapy
Funkcja packeth hping3 Scapy
GUI Tak (GTK) Nie (CLI) Nie (Python)
Warstwa 2 Tak Ograniczone Tak
Warstwa 3-4 Nie Tak Tak
Szybkość konfiguracji Bardzo szybka Średnia Wolna (programowanie)
Skryptowanie Nie Bash Python
Modyfikacja pól TCP/IP Nie Tak Tak
Obsługa IPv6 Nie Tak Tak
Do szybkich testów Ethernet: packeth. Do zaawansowanych testów TCP/IP: hping3. Do złożonych scenariuszy: Scapy.

Każde z trzech narzędzi do generowania pakietów ma swoje mocne strony. Packeth jest najprostszy – graficzny interfejs umożliwia szybkie tworzenie i wysyłanie ramek Ethernet bez znajomości składni. Jest idealny do nauki budowy ramek Ethernet i testowania warstwy 2. Nie wymaga programowania ani znajomości protokołów warstwy 3 i 4.

hping3 jest narzędziem wiersza poleceń wyspecjalizowanym w generowaniu pakietów TCP/IP z pełną kontrolą nad flagami TCP, numerami sekwencyjnymi, oknami i opcjami IP. Jest często używany w testach odporności firewalli, atakach DoS (SYN flood, ICMP flood) i skomplikowanych testach MTU discovery. Scapy to biblioteka Python oferująca największą elastyczność – pozwala na tworzenie dowolnych pakietów na dowolnej warstwie, automatyzację złożonych scenariuszy testowych i integrację z istniejącymi skryptami Python.

55/58
Podsumowanie – mapa narzędzi
Narzędzie Zastosowanie Warstwa Tryb
Yersinia Ataki warstwy 2, testy penetracyjne L2 CLI/GUI
Iptraf Monitorowanie ruchu, diagnostyka L2-L4 TUI
Netcat Połączenia TCP/UDP, skanowanie, transfer L4 CLI
Packeth Generowanie pakietów Ethernet L2 GUI
Wszystkie cztery narzędzia są darmowe i open-source. Stanowią kompletny zestaw do diagnostyki sieci od warstwy 2 do 4.

Mapa narzędzi przedstawiona w tabeli podsumowującej pokazuje, że cztery omówione narzędzia uzupełniają się wzajemnie, pokrywając warstwy 2-4 modelu OSI. Yersinia i packeth działają na warstwie 2 (łącza danych), iptraf na warstwach 2-4, a netcat na warstwie 4 (transportowej). Łączne wykorzystanie wszystkich czterech narzędzi pozwala na kompleksową diagnostykę sieci LAN od okablowania po aplikacje.

Wszystkie narzędzia są darmowe i open-source, co czyni je dostępnymi dla każdego administratora sieci. Yersinia (GNU GPL), iptraf-ng (GNU GPL), netcat (różne licencje open-source w zależności od wariantu) i packeth (GNU GPL) mogą być swobodnie używane w celach edukacyjnych i testowych. Dla środowisk produkcyjnych warto rozważyć również narzędzia komercyjne, takie jak SolarWinds, PRTG czy Riverbed, które oferują dodatkowe funkcje raportowania i wsparcia technicznego.

56/58
Pytania kontrolne
  1. Jaki atak warstwy 2 powoduje wyczerpanie puli adresów DHCP?
  2. Które narzędzie pozwala monitorować aktywne połączenia TCP w czasie rzeczywistym?
  3. Jak przesłać plik z hosta A do hosta B za pomocą netcat?
  4. Jaka opcja netcat włącza tryb nasłuchu?
  5. Czym się różni packeth od hping3?
  6. Jakie zabezpieczenie blokuje atak rogue DHCP server?
  7. Jaka opcja netcat wyłącza rozwiązywanie DNS?
  8. W jakim trybie uruchamia się yersinia z interfejsem tekstowym?

Pytania kontrolne sprawdzają zrozumienie kluczowych koncepcji omówionych w prezentacji. Odpowiedzi: (1) DHCP Starvation – atak wyczerpujący pulę adresów DHCP; (2) iptraf-ng w trybie TCP Connection Monitor; (3) Po stronie odbierającej: nc -lvp 4444 > plik, po stronie wysyłającej: nc IP 4444 < plik; (4) -l (listen);

(5) packeth działa na warstwie 2 (Ethernet), hping3 na warstwie 3-4 (TCP/IP); (6) DHCP Snooping na przełączniku; (7) -n (no DNS); (8) yersinia -I (tryb CLI). Zachęcam do samodzielnego sprawdzenia odpowiedzi poprzez praktyczne wykonanie każdego z opisanych poleceń w środowisku laboratoryjnym.

57/58
Zadanie praktyczne

Cel: Zidentyfikuj hosta generującego najwięcej ruchu w sieci laboratoryjnej.

Kroki:

  1. Uruchom iptraf-ng: sudo iptraf-ng
  2. Wybierz LAN Station Statistics
  3. Zanotuj 3 hosty z największym ruchem (pakiety/s, bajty/s)
  4. Dla każdego hosta:
    • Użyj nc -zv aby sprawdzić otwarte porty
    • Wykonaj bannergrabbing na otwartych portach
  5. Wyślij pakiet testowy do jednego z hostów przy użyciu packeth (ustaw MAC src/dst, EtherType 0x0800, zapisz payload "TEST")
  6. Sprawdź w iptraf, czy pakiet został odebrany

Wymagane narzędzia: iptraf-ng, netcat, packeth

Zadanie praktyczne łączy w sobie wszystkie cztery narzędzia w jednym scenariuszu laboratoryjnym, co doskonale odzwierciedla rzeczywistą pracę administratora sieci. Rozpoczynając od monitorowania iptraf-ng w celu identyfikacji najbardziej aktywnych hostów, przechodząc do skanowania portów i bannergrabbingu z netcat, a kończąc na wysłaniu testowej ramki Ethernet z packeth i weryfikacji jej odbioru w iptraf.

Aby w pełni wykonać zadanie, należy przygotować środowisko laboratoryjne składające się z co najmniej dwóch maszyn wirtualnych z Linux (np. Kali Linux i Ubuntu) połączonych wirtualnym przełącznikiem. Jedna maszyna pełni rolę atakującego/diagnosty (z zainstalowanymi wszystkimi czterema narzędziami), a druga rolę ofiary (uruchomione usługi SSH, HTTP, FTP). Wykonanie zadania krok po kroku utrwala wiedzę i rozwija praktyczne umiejętności diagnostyczne.

58/58
Dziękuję za uwagę

Koniec części 08

  • Yersinia – ataki warstwy 2
  • Iptraf – monitorowanie ruchu
  • Netcat – uniwersalne narzędzie TCP/UDP
  • Packeth – generator pakietów
# Podsumowanie w jednej linii
echo "Kolejna część: PiDSK_LOGICZNE_09.html"

Pytania? Zapraszam do dyskusji.

Prezentacja PiDSK_LOGICZNE_08 obejmuje cztery kluczowe narzędzia do diagnostyki sieci LAN na warstwach 2-4. Praktyczna znajomość yersinia, iptraf-ng, netcat i packeth jest niezbędna dla każdego administratora sieci i specjalisty ds. bezpieczeństwa. Zachęcam do samodzielnego eksperymentowania z każdym narzędziem w kontrolowanym środowisku laboratoryjnym.

Kolejna część cyklu (PiDSK_LOGICZNE_09) będzie poświęcona kolejnym narzędziom i technikom diagnostyki sieciowej. Wiedza zdobyta w tej części stanowi solidną podstawę do dalszego zgłębiania tematyki pomiarów logicznych w sieciach komputerowych. Wszystkie omówione narzędzia są dostępne w dystrybucji Kali Linux, co ułatwia kontynuację nauki we własnym zakresie.