RPwSK Wykład 4: Problemy Protokołów i Portów

Wstęp do warstwy transportowej

1/30

Warstwa 4 modelu OSI odpowiada za transport danych między końcami sieci (end-to-end).
Główne protokoły: TCP (niezawodny, strumieniowy) i UDP (szybki, datagramowy).
Wprowadza pojęcie portów służących do rozróżniania poszczególnych usług.
Problemy w tej warstwie dotyczą nawiązywania połączeń i wydajności transmisji.
Diagnostyka opiera się na analizie stanów sesji i flag protokołów.
Zapory ogniowe (Firewalle) najczęściej blokują ruch właśnie na poziomie portów.
Zrozumienie fundamentalnych różnic TCP vs UDP jest kluczem do sukcesu.

TCP: Transmission Control Protocol

2/30

Protokół połączeniowy – przed wysłaniem danych musi zestawić sesję.
Mechanizmy: potwierdzenia (ACK), retransmisje, dynamiczna kontrola przepływu.
Gwarantuje dostarczenie danych w dokładnie takiej samej kolejności, jak zostały wysłane.
Standard dla usług: WWW (HTTP/S), Poczta (SMTP/IMAP), Pliki (FTP), Zdalne sterowanie (SSH).
większy narzut protokołu ze względu na złożoność nagłówka i kontrolę.
Wysoka czułość na duże opóźnienia i straty pakietów.
aplikacja jest natychmiast powiadamiana o awarii połączenia.

UDP: User Datagram Protocol

3/30

Protokół bezpołączeniowy – działa w trybie "wyślij i zapomnij".
Brak potwierdzeń odbioru, brak retransmisji, kolejność nie jest gwarantowana.
Zapewnia minimalny narzut i najmniejsze możliwe opóźnienia.
Idealny dla: DNS, DHCP, VoIP, Wideokonferencji, Gier online oraz Streamingu.
Aplikacja musi samodzielnie obsłużyć ewentualne błędy lub zagubienie danych.
Trudniejszy w diagnostyce sieciowej (brak trwałych stanów sesji).
Często wykorzystywany w atakach typu Amplification (np. DNS Amplification).

Proces nawiązywania sesji: TCP 3-way handshake

4/30

Trójetapowe nawiązywanie połączenia (Handshake).
Krok 1: Klient wysyła pakiet SYN (Synchronize).
Krok 2: Serwer odpowiada pakietem SYN+ACK (Synchronize + Acknowledge).
Krok 3: Klient wysyła końcowe potwierdzenie ACK.
Dopiero po pomyślnym zakończeniu tego cyklu rozpoczyna się transfer danych.
Analiza Handshake w Wiresharku pozwala wykryć brak odpowiedzi serwera lub usługi.
Brak SYN+ACK sugeruje, że port jest zamknięty lub zapora blokuje ruch.

Zamykanie sesji TCP: FIN oraz RST

5/30

Standardowe zamknięcie: dwustronna wymiana pakietów FIN i ACK.
Każda strona kończy swój kierunek transmisji w sposób uporządkowany.
Nagłe zerwanie połączenia: pakiet RST (Reset).
Flagę RST wysyła urządzenie, gdy otrzyma pakiet do nieistniejącej sesji.
Firewalle wysyłają RST, gdy chcą aktywnie przerwać połączenie zamiast go "upuszczać" (drop).
Analiza pakietów RST wskazuje, która strona (lub urządzenie pośrednie) zrywa sesję.
Niekontrolowane sesje "wiszące" mogą blokować zasoby serwera.

Porty i gniazda sieciowe (sockets)

6/30

Port: logiczny identyfikator aplikacji/usługi (zakres 0-65535).
Gniazdo (Socket) = Unikalna kombinacja [IP + Port + Protokół].
Porty "Dobrze Znane" (Well-known): 0-1023 (80 HTTP, 443 HTTPS, 22 SSH).
Porty Zarejestrowane: 1024-49151 (np. 3306 MySQL, 1433 MSSQL).
Porty Dynamiczne (Efemeryczne): 49152-65535 (porty źródłowe klientów).
Serwer nasłuchuje na stałym porcie, a klient inicjuje połączenie z losowego portu wysokiego.
Konflikt portów uniemożliwia uruchomienie usługi na zajętym "zasobie".

Kluczowe stany połączeń TCP

7/30

LISTEN: Usługa oczekuje na próby nawiązania połączeń.
SYN_SENT: Klient zainicjował sesję, oczekuje na sygnał od serwera.
ESTABLISHED: Połączenie aktywne, trwa bezpieczna wymiana danych.
TIME_WAIT: Oczekiwanie systemowe po poprawnym zamknięciu (zabezpieczenie sesji).
CLOSE_WAIT: Połączenie jednostronnie zamknięte, czekanie na reakcję aplikacji lokalnej.
Nadmiarowa liczba SYN_SENT świadczy o braku łączności lub ataku odmowy usługi (DoS).
Zbyt wiele stanów TIME_WAIT może doprowadzić do wyczerpania puli portów.

Problem: blokowanie komunikacji na portach

8/30

Główny powód zgłoszeń dotyczących awarii aplikacji sieciowych.
Bariera może znajdować się na firewallu brzegowym lub lokalnym (systemowym).
Typowe objawy: timeout przy próbie logowania (brak reakcji na pakiety).
Szybki błąd "Connection Refused" sugeruje systemową blokadę portu (flagę RST).
Metody testu: `telnet`, `nc`, `Test-NetConnection` (PowerShell).
Niezbędna jest weryfikacja wszystkich reguł bezpieczeństwa po drodze (ścieżka end-to-end).
Częstym winowajcą jest niedopasowana konfiguracja Zapory Windows.

Problem: konflikty o zasób portu

9/30

Próba przywiązania (bind) usługi do portu, który jest już zajęty.
Komunikaty błędów: "Address already in use" lub "Bind failed".
Klasyczny przykład: jednoczesna instalacja XAMPP (Apache) oraz IIS.
Diagnostyka: polecenie `netstat -ano` lub `ss -lntp` ujawnia winny proces.
Rozwiązanie: edycja pliku konfiguracyjnego aplikacji i zmiana numeru portu.
Alternatywnie: wyłączenie zbędnej usługi systemowej blokującej dostęp.
Malware może udawać legalną usługę, zajmując jej port domyślny.

Problem: wyczerpanie portów dynamicznych

10/30

Każda sesja wychodząca wiąże jeden port z puli efemerycznej.
Pula jest skończona (standardowo ok. 16-65 tysięcy, zależnie od systemu).
Problem krytyczny dla Bram (Proxy), Równoważników Obciążenia (LB) i Dużych NATów.
Objaw: brak możliwości nawiązania nowych sesji przy wolnym CPU/RAM.
Przyczyna: lawinowo rosnąca liczba gniazd w stanie TIME_WAIT.
Rozwiązanie: tuning parametrów TCP (np. `tcp_tw_reuse`, skrócenie czasu zwrotu).
Rozwiązanie: wdrożenie wielu adresów IP źródłowych dla trasowania ruchu.

Diagnostyka warstwy nazw: DNS

11/30

Domain Name System – kluczowa usługa tłumacząca nazwy (np. google.pl) na IP.
Zasada: jeśli polecenie ping do adresu IP działa, a do nazwy domeny nie – winny jest DNS.
Struktura hierarchiczna: Root (.) -> TLD (.pl) -> Domena (firma.pl).
Wykorzystuje port 53 (UDP dla zapytań, TCP dla transferów stref).
Agresywne buforowanie (Caching) czasem serwuje nieaktualne (niepoprawne) dane.
Podstawowy zestaw narzędzi: `nslookup`, `dig`, `host`.
Błędy DNS paraliżują niemal każdą nowoczesną usługę sieciową.

Typowe rekordy DNS i ich kody błędów

12/30

Rekord A: IPv4 dla nazwy. Błąd: nieprawidłowy, stary adres.
Rekord AAAA: IPv6 dla nazwy. Błąd: priorytetyzacja IPv6 mimo braku routingu.
Rekord MX: Kierowanie poczty. Błąd: zagubione lub odbite maile.
Rekord CNAME: Alias nazwy. Błąd: zapętlone rekordy (CNAME chase).
NXDOMAIN: Odpowiedź serwera: "Domena o tej nazwie nie istnieje".
SERVFAIL: Problem techniczny serwera (brak autorytatywnej odpowiedzi).
Split-Horizon DNS: serwowanie różnych adresów IP dla sieci LAN oraz WAN.

Problematyka protokołów HTTP / HTTPS

13/30

Protokoły warstwy aplikacji, nierozerwalnie połączone ze stanem TCP.
Kody odpowiedzi serwera to podstawa diagnozy (np. 301 - przekierowanie).
Błędy klienta (4xx): 404 - brak strony, 403 - brak uprawnień dostępu.
Błędy serwera (5xx): 500 - awaria aplikacji, 502/504 - błąd bramy (Gateway).
HTTPS: krytyczne problemy z certyfikatami (brak zaufania, wygaśnięcie).
Kluczowe narzędzia: DevTools w przeglądarce (F12, zakładka Network).
`curl -v` pozwala na pełny podgląd nagłówków i procesu negocjacji TLS.

Analiza problemu z protokołem FTP

14/30

File Transfer Protocol – jeden z najtrudniejszych protokołów dla firewall.
Tryb Aktywny: Serwer próbuje nawiązać połączenie zwrotne do klienta.
Tryb Pasywny (PASV): Klient nawiązuje oba połączenia (zalecane dla NAT).
W trybie aktywnym Zapory Sieciowe po stronie klienta niemal zawsze blokują transfer.
FTP przesyła dane i hasła jawnym tekstem! Wymagana zmiana na SFTP/FTPS.
Kod błędu 530 oznacza najczęściej błędne dane logowania.
Protokół wymaga dwóch gniazd: sterującego (21) i danych (losowe/20).

Diagnostyka bezpiecznego wywołania: SSH

15/30

Secure Shell – domyślnie port 22. Standard administracji systemami.
Błąd `Permission denied publickey`: nieprawidłowy lub niezaładowany klucz.
Ostrzeżenie `REMOTE HOST IDENTIFICATION HAS CHANGED`: zmiana klucza hosta.
Sygnalizuje potencjalny atak podszywania się (MITM) lub reinstalację celu.
Tryb Verbose: `ssh -v` ujawnia dokładny moment przerwania negocjacji.
Opóźnienia przy logowaniu wynikają często z prób zapytania Reverse DNS (`UseDNS no`).
Bezpieczna konfiguracja: blokowanie logowania na konto root oraz zmiana portu.

Narzędzie diagnostyczne: Netstat

16/30

Raportuje aktualny stan wszystkich gniazd sieciowych w systemie.
`netstat -a`: wyświetla wszystkie porty (nawet te tylko słuchające).
`netstat -n`: pomija zamianę adresów IP na nazwy (pracuje znacznie szybciej).
`netstat -ano` (Win) / `-p` (Linux): wiąże połączenie z numerem procesu (PID).
Umożliwia wykrycie podejrzanych sesji zainicjowanych przez wirusy.
Kluczowy etap przy wykrywaniu lokalnych konfliktów portów.
Obecnie w nowszych dystrybucjach Linux zastępowane przez narzędzie `ss`.

Socket statistics: narzędzie SS

17/30

Nowoczesny, szybszy i bardziej szczegółowy zamiennik `netstat`.
Pobiera dane bezpośrednio z jądra systemu, oszczędzając zasoby.
`ss -tulpn`: wyświetla TCP, UDP, status Listening, PID i numery portów.
`ss -s`: generuje błyskawiczne podsumowanie obciążenia stosu sieciowego.
Umożliwia zaawansowane filtrowanie (np. tylko połączenia do portu 80).
Dostarcza informacji o parametrach okna TCP i aktywnych timerach.
Podstawowe narzędzie w warsztacie administratora nowoczesnego Linuxa.

Szybka weryfikacja: Telnet i Netcat (nc)

18/30

Telnet: prosty test "drożności" portu TCP: `telnet [IP] [PORT]`.
Jeśli ekran stanie się pusty (lub kursor mignie) – droga jest wolna i port otwarty.
Netcat (nc): "szwajcarski scyzoryk" sieciowca.
Wspiera testy TCP oraz UDP (opcja `-u`).
Potrafi działać jako tymczasowy serwer nasłuchujący do testów firewalla.
Idealny do skryptowania i przesyłania tekstowych danych testowych.
Obowiązkowe narzędzie przy weryfikacji drożności ACL wewnątrz sieci.

Skanowanie kompleksowe: Nmap

19/30

Network Mapper – zaawansowane skanowanie setek urządzeń jednocześnie.
Inwentaryzacja: otwarte porty, typy usług, szacowany system operacyjny (OS).
Tryb SYN Scan (`-sS`): najszybszy, "półotwarty" (nie kończy procedury handshake).
Skanowanie UDP (`-sU`): niezbędne do audytu DNS/DHCP/VoIP.
Potężny silnik skryptowy NSE do wykrywania luk w zabezpieczeniach.
Uwaga: Skanowanie systemów bez wyraźnej zgody właściciela jest karalne.
Fundament bezpieczeństwa i inwentaryzacji zasobów IT.

Case Study 1: "Serwer Apache nie wstaje"

20/30

Objawy: Aplikacja XAMPP zgłasza błąd startu modułu HTTP.
Dziennik zdarzeń: "Address 0.0.0.0:80 is in use by another process".
Analiza: `netstat -ano | findstr :80` zwraca proces o numerze PID 4.
Identyfikacja: PID 4 to jądro Windows (często usługa IIS lub World Wide Web Publishing).
Rozwiązanie: Zatrzymanie zbędnej usługi Windows lub zmiana portu Apache na 8080.
Wniosek: Konflikt domyślnych usług to najczęstszy problem środowisk deweloperskich.

Case Study 2: "E-mail nie wychodzi ze skrzynki"

21/30

Objawy: Program pocztowy zgłasza błąd łączności z serwerem SMTP.
Diagnostyka: Próba `telnet mail.domena.pl 25` kończy się fiaskiem.
Analiza: Wielu dostawców ISP blokuje port 25 w celu ograniczenia spamu.
Rozwiązanie: Zastosowanie portu dedykowanego 587 (Submission) z TLS.
Wniosek: Standardowe porty usług są często filtrowane przez operatorów zewnętrznych.
Zawsze sprawdź politykę firewalla swojego dostawcy Internetu.

Case Study 3: "Oczekiwanie na załadowanie witryny"

22/30

Objawy: Witryny ładują się z dużym opóźnieniem (nawet kilka sekund).
Diagnostyka: narzędzia `nslookup` wykazują timeout dla pierwszego wpisu DNS.
Analiza: pierwszy serwer na liście w konfiguracji karty sieciowej DHCP jest nieaktywny.
System operacyjny każdorazowo czeka na koniec próby zanim użyje drugiego serwera.
Rozwiązanie: Korekta konfiguracji serwera DHCP i usunięcie martwych adresów DNS.
Wniosek: Błędy DNS są często mylone z ogólnymi problemami z przepustowością.

Precyzyjna analiza ruchu w Wireshark

23/30

`tcp.port == 443`: wyświetla wyłącznie szyfrowany ruch WWW.
`tcp.flags.syn == 1`: izoluje nowo inicjowane próby nawiązania sesji.
`tcp.analysis.retransmission`: klucz do wykrywania problemów fizycznych sieci.
Funkcja "Follow TCP Stream": rekonstrukcja całej konwersacji aplikacyjnej.
Automatyczne kolorowanie pomaga błyskawicznie wychwycić błędy (np. czarne tło - RST).
Analiza odstępów czasowych (Delta Time) pozwala na wykrycie "wąskich gardeł".
Potężne narzędzie wymagające cierpliwości i zrozumienia struktury pakietów.

Strategie bezpieczeństwa portów

24/30

Reguła "Default Deny": blokuj wszystko, co nie jest jawnie dozwolone.
Cykliczne skanowanie infrastruktury (Nmap) w poszukiwaniu "zapomnianych" usług.
Zaciemnianie (ang. Obscurification): zmiana portów standardowych (np. SSH z 22 na 2222) – to tylko utrudnienie.
Port Knocking: ukrywanie portów do czasu podania "hasła" sekwencją pingów.
Mechanizmy Honeypot: pozorowane usługi monitorujące próby nielegalnego dostępu.
Ostrzeżenie przed UPnP: automatyczne otwieranie portów to ogromna dziura w bezpieczeństwie.
Środowiska korporacyjne bezwzględnie powinny posiadać wyłączone wsparcie UPnP.

Problemy wydajnościowe: Load balancing

25/30

Równoważnik obciążenia (Load Balancer) rozdziela żądania na farmę serwerów wykonawczych.
Mechanizm sprawdzania kondycji (Health Check): musi sprawdzać nie tylko dostępność portu, ale i kod (np. HTTP 200).
Błąd: serwer "żyje" (port otwarty), lecz aplikacja zwraca błąd 500 (Internal Error).
Trwałe sesje (Sticky Sessions): zapewnienie, że dany klient zawsze trafi do tego samego serwera sesji.
SNAT na balanserze ukrywa prawdziwy adres IP klienta przed serwerem.
Rozwiązanie: wstrzykiwanie nagłówka X-Forwarded-For dla zachowania logów.

Diagnostyka usług głosowych: VoIP

26/30

Sygnalizacja SIP (port 5060) oraz strumień audio RTP (dynamiczne UDP).
Problem `One-way audio`: słyszysz rozmówcę, ale on ciebie nie.
Przyczyna: Zapora przepuściła tylko sygnalizację SIP, blokując ruch UDP-RTP.
Funkcja SIP ALG na tanich routerach domowych statystycznie częściej psuje komunikację niż pomaga.
Diagnostyka Wireshark: tryb analizy "Telephony" do wykreślenia diagramu sesji.
Nagłe straty pakietów powodują rwanie głosu i całkowity brak zrozumienia.

Problemy ze strumieniowaniem wideo

27/30

Wykorzystuje zarówno TCP (np. YouTube) jak i UDP (IPTV, Multicast).
Pikseloza i zacinanie: najczęściej wynik straty pakietów UDP lub spadku pasma.
Zjawisko Multicast w sieci LAN wymaga włączenia funkcji IGMP Snooping na switchach.
Bez IGMP Snooping ruch wideo zaleje wszystkie porty, paraliżując sieć.
Priorytetyzacja QoS jest niezbędna w sieciach o ograniczonych zasobach.
Pomocne statystyki techniczne (np. "Stats for nerds" na platformach wideo).

Tunele sieciowe i VPN

28/30

Enkapsulacja: zamykanie jednego typu ruchu wewnątrz drugiego bezpiecznego pakietu.
Standardy: IPsec, OpenVPN, nowoczesny WireGuard.
Krytyczne problemy z MTU: nagłówki tunelu zwiększają rozmiar pakietu, wymuszając odrzucanie.
Blokowanie protokołów nieportowych (np. GRE czy ESP) przez prostsze firewalle.
NAT Traversal (NAT-T): metoda pakowania tunelu w UDP 4500 dla przejścia przez NAT.
Podstawą diagnozy są zawsze szczegółowe logi klienta oraz serwera VPN.

Dobre praktyki: ciągły monitoring usług

29/30

Prosty Ping hosta nie jest dowodem na to, że usługa działa poprawnie.
Należy monitorować dostępność konkretnego portu (np. TCP Check na 443).
Zalecane testy scenariuszowe: sprawdzenie, czy serwer zwraca poprawny fragment strony.
Monitoring certyfikatów SSL: zapobieganie nagłemu wygaśnięciu zaufania do witryny.
Popularne rozwiązania: Zabbix, Prometheus, nowoczesna Uptime Kuma.
Systemy te pozwalają na reakcję zanim użytkownik końcowy zgłosi awarię.

Podsumowanie wykładu 4

30/30

Warstwa transportowa jest fundamentem niezawodności każdej aplikacji sieciowej.
TCP i UDP mają skrajnie różne zastosowania oraz specyficzne problemy diagnostyczne.
Porty są "drzwiami" – muszą być właściwie skonfigurowane oraz odpowiednio strzeżone.
DNS to usługa, bez której współczesny stos protokołów przestaje być użyteczny.
Zestaw `netstat`, `nmap`, `wireshark` to alfabet inżyniera systemowego.
Zrozumienie trybu nawiązywania i zamykania sesji pozwala na szybkie usuwanie awarii.
W kolejnym wykładzie omówimy mechanizmy Zapór Sieciowych (Firewall) oraz NAT.