Protokoly warstwy aplikacji i transportowej stanowia najwazniejsza czesc stosu TCP/IP z punktu widzenia uzytkownika i administratora sieci. Podczas gdy warstwy nizsze (dostepu do sieci i internetowa) zajmuja sie adresacja i dostarczaniem pakietow, warstwy transportowa i aplikacji umozliwiaja aplikacjom komunikacje przez siec.

Szosta czesc wykladu poswiecona jest szczegolowej analizie protokolow TCP i UDP w warstwie transportowej oraz protokolom HTTP/HTTPS, DNS, DHCP, FTP, SMTP i SSH w warstwie aplikacji. Omowione zostana budowa naglowkow, mechanizmy dzialania oraz narzedzia do diagnostyki kazdego z protokolow.

Zrozumienie protokolow warstwy transportowej jest kluczowe dla kazdego administratora sieci, poniewaz to wlasnie na tym poziomie podejmowane sa decyzje o niezawodnosci, kontroli przeplywu i zarzadzaniu polaczeniami. Bez tej wiedzy trudno diagnozowac problemy sieciowe na poziomie aplikacji.

W czesci praktycznej studenci poznaja narzedzie Wireshark do analizy ruchu sieciowego oraz polecenia systemowe (netstat, nslookup, telnet) sluzace do testowania dzialania protokolow. Cwiczenia laboratoryjne obejmuja przechwytywanie i analize sesji TCP, zapytan DNS i procesu DORA.

Plan szostej czesci wykladu obejmuje wszystkie kluczowe protokoly warstwy transportowej i aplikacji stosu TCP/IP. Rozpoczniemy od szczegolowego omowienia protokolu TCP - segmentacji danych, mechanizmu potwierdzen, kontroli przeplywu i trójfazowego uzgadniania polaczenia.

Nastepnie przeanalizujemy protokol UDP - jego budowe, cechy charakterystyczne i zastosowania. Porownamy TCP i UDP pod katem wydajnosci, niezawodnosci i narzutu protokolarnego, co pozwoli zrozumiec, kiedy stosowac ktory protokol.

W warstwie aplikacji omowimy najwazniejsze protokoly: HTTP i HTTPS (komunikacja WWW), DNS (system nazw domenowych), DHCP (automatyczna konfiguracja sieci), FTP i SFTP (transfer plikow), SMTP i POP3/IMAP (poczta elektroniczna) oraz SSH i Telnet (zdalny dostep).

Kazdy protokol zostanie przeanalizowany pod katem budowy naglowka, mechanizmu dzialania, domyslnych portow oraz typowych problemow diagnostycznych. Czesc wykladu zawiera rowniez 20 pytan kontrolnych i cwiczenia laboratoryjne z wykorzystaniem Wireshark.

Segmentacja danych w TCP jest procesem dzielenia strumienia danych z warstwy aplikacji na mniejsze jednostki zwane segmentami. Kazdy segment otrzymuje numer sekwencyjny (Sequence Number), ktory pozwala odbiorcy na zlozenie danych w oryginalnej kolejnosc, nawet jesli segmenty dotra w innej kolejnosci.

Maksymalny rozmiar segmentu (MSS - Maximum Segment Size) jest negocjowany podczas Three-Way Handshake i jest to najwiekszy rozmiar danych uzytkownika, jaki moze byc przeslany w pojedynczym segmencie TCP. Dla standardowego Ethernetu z MTU 1500 bajtow, MSS wynosi 1460 bajtow (1500 - 20 bajtow IP - 20 bajtow TCP).

Jesli dane z warstwy aplikacji sa wieksze niz MSS, TCP dzieli je na wiele segmentow, kazdy z wlasnym numerem sekwencyjnym. Odbiorca uzywa numerow sekwencyjnych do poprawnego zlozenia danych i wykrycia brakujacych segmentow.

Rozmiar MSS ma istotny wplyw na wydajnosc transmisji. Zbyt male MSS zwieksza narzut protokolarny (wiecej naglowkow na te sama ilosc danych), zas zbyt duze MSS moze prowadzic do fragmentacji na poziomie IP, jesli pakiet przekroczy MTU ktoregos z laczy na trasie.

Mechanizm potwierdzen w TCP (ACK - Acknowledgment) jest podstawa niezawodnosci tego protokolu. Po otrzymaniu segmentu danych, odbiorca wysyla pakiet z flaga ACK i numerem potwierdzenia (Acknowledgment Number), ktory okresla nastepny oczekiwany bajt danych.

Jesli nadawca nie otrzyma ACK w ciagu RTO (Retransmission Timeout), zaklada ze segment zostal utracony i retransmituje go. Dlugosc RTO jest dynamicznie wyliczana na podstawie pomiarow RTT (Round-Trip Time) i moze byc zaokraglana w gore z powodu opoznien w sieci.

Selektywne potwierdzenia (SACK - Selective Acknowledgment) to opcjonalny mechanizm TCP (RFC 2018), ktory pozwala odbiorcy potwierdzic wiele odebranych segmentow naraz, nawet jesly wystepuja luki. Dzieki SACK nadawca retransmituje tylko faktycznie utracone segmenty, a nie caly blok danych.

Wireshark oznacz pakiety retransmitowane etykieta [TCP Retransmission] i [TCP Fast Retransmission]. Roznica polega na tym, ze Fast Retransmission jest wyzwalana przez trzy duplikaty ACK (bez czekania na timeout), podczas gdy zwykla Retransmission nastepuje po uplywie RTO.

Kontrola przeplywu w TCP zapobiega przeciazeniu odbiorcy przez nadawce. Mechanizm okna odbiorcy (rwnd - receiver window) jest oglaszany przez odbiorce w kazdym segmencie i okresla maksymalna liczbe bajtow, jaka odbiorca moze przyjac bez potwierdzenia. Nadawca nie moze wyslac wiecej niz rwnd bajtow bez otrzymania ACK.

Kontrola przeciazenia (congestion control) zapobiega przeciazeniu sieci. Mechanizm okna przeciazenia (cwnd - congestion window) jest zarzadzany przez nadawce i dynamicznie dostosowuje sie do warunkow sieciowych. Rzeczywiste okno wysylania (swnd) jest mniejsza z dwoch wartosci: min(rwnd, cwnd).

Algorytm kontroli przeciazenia dziala w trzech fazach: Slow Start (cwnd podwaja sie co RTT az do progu ssthresh), Congestion Avoidance (cwnd rosnie liniowo o 1 MSS na RTT) i Fast Recovery (po wykryciu utraty pakietu przez potrojny Dup ACK).

Nowoczesne algorytmy kontroli przeciazenia, takie jak TCP Cubic (domyslny w Linux) i TCP BBR (opracowany przez Google), znacznie poprawiaja wykorzystanie przepustowosci w sieciach o duzym opoznieniu (np. lacza satelitarne) i w sieciach z zmienna przepustowoscia (sieci bezprzewodowe).

Trójfazowe uzgadnianie TCP (Three-Way Handshake) jest standardowa procedura nawiazywania polaczenia TCP. Proces ten zapewnia, ze obie strony sa gotowe do komunikacji i ze numery sekwencyjne sa zsynchronizowane. Bez tego mechanizmu protokol TCP nie moglby gwarantowac niezawodnego dostarczania danych.

W pierwszym kroku klient wysyla pakiet SYN (Synchronize) z losowym numerem sekwencyjnym (SEQ=x). W drugim kroku serwer odpowiada pakietem SYN-ACK z wlasnym losowym numerem sekwencyjnym (SEQ=y) i numerem potwierdzenia ustawionym na x+1.

W trzecim kroku klient wysyla pakiet ACK z numerem sekwencyjnym x+1 i numerem potwierdzenia y+1. Po otrzymaniu tego pakietu polaczenie przechodzi w stan ESTABLISHED i moze rozpoczac sie wlasciwa transmisja danych.

Wireshark pozwala na latwa identyfikacje Three-Way Handshake poprzez filtr tcp.flags.syn==1. Pierwsze trzy pakiety sesji TCP (SYN, SYN-ACK, ACK) sa widoczne jako osobne wpisy, a w kolumnie Info widnieje opis SYN, SYN-ACK lub ACK.

Protokol UDP (User Datagram Protocol) jest protokolem warstwy transportowej bez polaczenia, co oznacza, ze przed wyslaniem danych nie jest wymagane nawiazywanie polaczenia miedzy nadawca a odbiorca. Datagramy UDP sa po prostu wysylane do adresata bez zadnych gwarancji dostarczenia.

Naglowek UDP ma stale 8 bajtow i zawiera tylko cztery pola: Source Port (2B), Destination Port (2B), Length (2B) i Checksum (2B). W porownaniu z minimalnym naglowkiem TCP (20B), UDP ma znacznie mniejszy narzut protokolarny, co jest kluczowe dla aplikacji czasu rzeczywistego.

UDP nie zapewnia potwierdzen, retransmisji, kontroli przeplywu ani zachowania kolejnosci datagramow. Datagramy moga zostac utracone, zduplikowane lub dostarczone w innej kolejnosci bez powiadomienia aplikacji. To sprawia, ze UDP jest odpowiedzialny tylko za dostarczenie datagramu do okreslonego portu.

Mimo braku gwarancji, UDP jest szeroko stosowany w protokolach takich jak DNS (zapytania), DHCP (konfiguracja sieci), VOIP (transmisja glosu), streaming video, gry online i NTP (synchronizacja czasu). W tych zastosowaniach niskie opoznienie jest wazniejsze niz niezawodnosc.

Porownanie TCP i UDP pokazuje fundamentalne roznice w podejsciu do komunikacji sieciowej. TCP jest protokolem zorientowanym na polaczenie, oferujacym niezawodne dostarczanie danych z potwierdzeniami, retransmisja i kontrola przeplywu. UDP jest prosty, szybki, ale zawodny.

Naglowek TCP ma minimum 20 bajtow (z opcjami do 60 bajtow), podczas gdy UDP ma stale 8 bajtow. Ta roznica wynika z dodatkowych pol TCP potrzebnych do numerow sekwencyjnych, potwierdzen, okna, flag i opcji. W rezultacie TCP ma wiekszy narzut protokolarny.

TCP gwarantuje dostarczenie danych w odpowiedniej kolejnosci dzieki numerom sekwencyjnym i potwierdzeniom. UDP nie gwarantuje ani dostarczenia, ani kolejnosci. Aplikacje uzywajace UDP musza same implementowac mechanizmy niezawodnosci, jesli sa one wymagane.

Wybór miedzy TCP a UDP zalezy od wymagan aplikacji. TCP jest niezbedny tam, gdzie kazdy bajt danych musi zostac dostarczony poprawnie (strony WWW, poczta, transfer plikow). UDP jest preferowany tam, gdzie niskie opoznienie i mala przepustowosc sa kluczowe (VoIP, gry, streaming).

Socket (gniazdo) jest abstrakcyjnym mechanizmem programistycznym, ktory łączy adres IP, numer portu i protokol transportowy w jedna jednostke identyfikujaca punkt koncowy komunikacji sieciowej. W systemach Unix/Linux gniazda sa reprezentowane jako deskryptory plikow i obslugiwane przez standardowe funkcje wejscia-wyjscia.

Kazde polaczenie TCP lub UDP jest jednoznacznie identyfikowane przez piec parametrow: protokol (TCP/UDP), adres IP zrodla, port zrodla, adres IP celu i port celu. Dzieki temu jeden serwer WWW na porcie 80 moze ob slugiwac tysiace jednoczesnych polaczen - kazde ma unikalna kombinacje IP i portu zrodlowego klienta.

Porty sa 16-bitowymi numerami (0-65535) i dziela sie na trzy kategorie: Well-Known Ports (0-1023) zarezerwowane dla znanych uslug (HTTP 80, HTTPS 443, DNS 53), Registered Ports (1024-49151) dla aplikacji zarejestrowanych w IANA, oraz Dynamic/Private Ports (49152-65535).

Polecenie netstat -an (Windows/Linux) wyswietla wszystkie aktywne gniazda na systemie wraz z ich stanem. W systemie Linux polecenie ss -tulpn jest szybsza alternatywa, pokazujaca gniazda TCP (-t) i UDP (-u) nasluchujace (-l) i polaczone, z informacja o procesie (-p).

HTTP (Hypertext Transfer Protocol) jest podstawowym protokolem warstwy aplikacji dla World Wide Web. Dziala w modelu zadanie-odpowiedz (request-response), gdzie klient (przegladarka) wysyla zadanie do serwera, a serwer odpowiada z zasobem (strona HTML, obraz, plik CSS).

HTTP jest protokolem bezstanowym (stateless) - serwer nie przechowuje informacji o poprzednich zadaniach tego samego klienta. Mechanizmy takie jak cookies i sesje po stronie serwera (PHP sessions, JWT) dodaja stan na poziomie aplikacji.

Metody HTTP: GET (pobranie zasobu), POST (wyslanie danych do przetworzenia), PUT (zastapienie zasobu), DELETE (usuniecie zasobu), HEAD (pobranie samych naglowkow), OPTIONS (pytanie o dozwolone metody), PATCH (czesciowa modyfikacja).

HTTP/1.1 (RFC 7231) wprowadzil Keep-Alive, pozwalajacy na wielokrotne zadania w ramach jednego polaczenia TCP. HTTP/2 dodal multipleksowanie (wiele strumieni w jednym polaczeniu) i kompresje naglowkow. HTTP/3 uzywa QUIC (oparty na UDP) zamiast TCP dla mniejszego opoznienia.

Zadanie HTTP sklada sie z trzech czesci: linii zadania (request line), naglowkow (headers) i opcjonalnego ciala (body). Linia zadania zawiera metode HTTP, sciezke zasobu i wersje protokolu. Przyklad: GET /index.html HTTP/1.1.

Naglowki HTTP zadania dostarczaja dodatkowych informacji: Host (nazwa serwera - wymagany w HTTP/1.1), User-Agent (klient), Accept (akceptowane typy MIME), Cookie (ciasteczka), Authorization (uwierzytelnienie), Referer (zrodlo), Content-Type i Content-Length (dla POST/PUT).

Wireshark pozwala na przechwycenie i analize zadania HTTP. Filtr http wyswietla tylko pakiety HTTP, a rozwinięcie sekcji Hypertext Transfer Protocol w szczegolach pakietu pokazuje wszystkie pola zadania: metode, URI, wersje, naglowki i ewentualne cialo.

W fazie cwiczen studenci przechwyca zadanie HTTP w Wireshark i identyfikuja metode HTTP (np. GET), naglowek Host (np. www.example.com), User-Agent (np. Mozilla/5.0) oraz kod odpowiedzi (np. 200 OK). Jest to podstawowe cwiczenie z analizy protokolow.

Odpowiedz HTTP sklada sie z linii statusu (status line), naglowkow (headers) i opcjonalnego ciala (body). Linia statusu zawiera wersje HTTP, kod statusu (3 cyfry) i opis tekstowy. Przyklad: HTTP/1.1 200 OK.

Kody statusu HTTP dziela sie na piec klas: 1xx (informacyjne - 100 Continue), 2xx (sukces - 200 OK, 201 Created), 3xx (przekierowanie - 301 Moved Permanently, 302 Found, 304 Not Modified), 4xx (bledy klienta - 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found) i 5xx (bledy serwera - 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable).

Naglowki odpowiedzi HTTP zawieraja: Content-Type (typ MIME zasobu), Content-Length (dlugosc ciala), Cache-Control (polityka buforowania), Set-Cookie (ustawienie ciasteczka), Server (oprogramowanie serwera) i Date (data odpowiedzi).

Wireshark pokazuje odpowiedz HTTP w sekcji Hypertext Transfer Protocol. Po rozwinięciu widac kod statusu, wszystkie naglowki odpowiedzi i cialo odpowiedzi (np. kod HTML strony). Filtr http.response umozliwia wyswietlenie tylko odpowiedzi HTTP.

HTTPS (HTTP Secure) to polaczenie protokolu HTTP z warstwa szyfrowania TLS (Transport Layer Security). Dane przesylane miedzy klientem a serwerem sa szyfrowane, co zapewnia poufnosc, integralnosc i autentycznosc komunikacji.

TLS dziala pomiedzy warstwa transportowa (TCP) a warstwa aplikacji (HTTP). Przed rozpoczeciem szyfrowanej komunikacji TLS wykonuje handshake, podczas ktorego klient i serwer uzgadniaja wersje TLS, algorytmy szyfrowania, wymieniaja certyfikaty i ustalaja klucz sesji.

Certyfikat X.509 jest cyfrowym dokumentem potwierdzajacym tozsamosc serwera. Zawiera nazwe domeny, dane organizacji, klucz publiczny, date waznosci i podpis cyfrowy wystawcy (Certificate Authority). Przegladarki ostrzegaja, jesli certyfikat jest niewazny lub niepasuje do domeny.

W Wireshark ruch HTTPS jest widoczny jako Client Hello, Server Hello, Certificate Exchange, Server Key Exchange i nastepnie Application Data (zaszyfrowane). Przechwycenie ruchu HTTPS nie pozwala na odczytanie tresci bez klucza prywatnego serwera lub klucza sesji.

DNS (Domain Name System) przechowuje rozne typy rekordow, z ktorych kazdy sluzy do innego celu. Rekord A (Address) mapuje nazwe domeny na adres IPv4. Rekord AAAA mapuje nazwe domeny na adres IPv6. Bez tych rekordow przegladarka nie wiedzialaby, pod jaki adres IP wyslac zadanie HTTP.

Rekord CNAME (Canonical Name) tworzy alias domeny. Na przyklad www.example.com moze byc aliasem dla example.com. Dzieki CNAME zmiana adresu IP example.com automatycznie dotyczy rowniez www.example.com. Rekord MX (Mail Exchange) wskazuje serwer poczty odpowiedzialny za odbiór e-maili dla domeny.

Rekord NS (Name Server) wskazuje autorytatywny serwer DNS dla domeny. Rekord TXT (Text) przechowuje dowolny tekst, uzywany m.in. do weryfikacji wlasnosci domeny (Google Search Console), SPF (Sender Policy Framework) i DKIM (DomainKeys Identified Mail) dla poczty.

Narzedzie dig (Linux) pozwala na szczegolowe zapytania DNS: dig google.pl A wyswietla rekord A, dig google.pl MX wyswietla rekord MX, dig google.pl ANY wyswietla wszystkie typy rekordow. Wynik pokazuje rowniez sekcje AUTHORITY (autorytatywny serwer) i ADDITIONAL (dodatkowe informacje).

Diagnostyka DNS jest niezbedna w codziennej pracy administratora sieci. Narzedzie nslookup (Windows/Linux) umozliwia wykonywanie zapytan DNS z linii polecen. nslookup google.pl wyswietla adres IP domeny, a nslookup -type=MX google.pl wyswietla serwer poczty.

Narzedzie dig (Linux) oferuje bardziej szczegolowe wyniki niz nslookup. dig google.pl A +short wyswietla tylko adres IP bez dodatkowych informacji. dig google.pl ANY wyswietla wszystkie typy rekordow. dig -x 8.8.8.8 wykonuje odwrotne zapytanie DNS (adres IP na nazwe).

Wireshark z filtrem dns pozwala na przechwycenie i analize zapytan DNS. Po rozwinięciu pakietu DNS widac: Transaction ID (identyfikator zapytania), Flags (QR - zapytanie/odpowiedz, Opcode - standardowe/zapytanie odwrotne), Questions (sekcja pytan) i Answers (sekcja odpowiedzi).

Typowe problemy z DNS: brak odpowiedzi od serwera DNS (sprawdz konfiguracje sieci), bledny wpis w pliku hosts, buforowanie nieaktualnych wpisow (ipconfig /flushdns w Windows), atak DNS spoofing (falszywe odpowiedzi DNS). Narzedzia diagnostyczne pomagaja zidentyfikowac zrodlo problemu.

Proces DORA w DHCP (Discover, Offer, Request, ACK) jest standardowa procedura uzyskiwania adresu IP przez klienta. W pierwszym kroku klient wysyla broadcastowy pakiet DHCPDISCOVER z adresem zrodlowym 0.0.0.0 i docelowym 255.255.255.255, pytajac o dostepne serwery DHCP.

Serwer DHCP odpowiada pakietem DHCPOFFER, proponujac adres IP, maske podsieci, brame domyslna i adresy serwerow DNS. Klient moze otrzymac wiele ofert, jesli w sieci dziala kilka serwerow DHCP. W drugim kroku klient wybiera jedna oferte i wysyla DHCPREQUEST.

Serwer potwierdza przydzial adresu pakietem DHCPACK. Od tego momentu klient moze uzywac przydzielonego adresu IP przez okres dzierzawy (lease time). Jesli serwer nie moze przydzielic adresu (np. pula wyczerpana), wysyla DHCPNAK.

Wireshark z filtrem dhcp lub bootp pokazuje cztery pakiety DORA. Po rozwinięciu pakietu DHCP widac: Message Type (Discover/Offer/Request/ACK), Transaction ID, Client MAC Address, Your IP Address (w Offer i ACK), Server Identifier i opcje DHCP (Subnet Mask, Router, DNS).

Protokoly transferu plikow dziela sie na szyfrowane i nieszyfrowane. FTP (File Transfer Protocol) korzysta z dwoch kanalow: kanalu kontrolnego na porcie 21 (komendy) i kanalu danych na porcie 20 (dane). FTP przesyla dane w czystym tekscie, l acznie z haslami, co stanowi powazne zagrozenienie bezpieczenstwa.

FTPS (FTP Secure) dodaje warstwe szyfrowania TLS do protokolu FTP, chroniac zarowno kanal kontrolny, jak i kanal danych. FTPS moze dzialac w dwoch trybach: implicit (wymuszone TLS na porcie 990) i explicit (STARTTLS na porcie 21).

SFTP (SSH File Transfer Protocol) nie jest rozszerzeniem FTP, lecz odrebnych protokolem dzialajacym przez SSH na porcie 22. SFTP zapewnia szyfrowanie, uwierzytelnianie i integralnosc danych. W odroznieniu od FTP, SFTP uzywa tylko jednego polaczenia do przekazywania komend i danych.

FTP dziala w dwoch trybach: aktywnym (Active) i pasywnym (Passive). W trybie aktywnym serwer łączy sie z klientem na porcie danych, co jest blokowane przez firewalle. W trybie pasywnym klient łączy sie z serwerem na porcie danych, co rozwiazuje problem firewalli.

Protokoly poczty elektronicznej dziela sie na protokoly wysylania (SMTP) i odbierania (POP3, IMAP). SMTP (Simple Mail Transfer Protocol) na porcie 25 sluzy do przesylania wiadomosci miedzy serwerami poczty. Klienci uzywaja SMTP na porcie 587 (lub 465 dla SMTPS) do wysylania wiadomosci.

POP3 (Post Office Protocol version 3) na porcie 110 sluzy do odbierania poczty z serwera. Klient POP3 łączy sie, pobiera wszystkie wiadomosci i domyslnie usuwa je z serwera. To rozwiazanie jest odpowiednie dla uzytkownikow korzystajacych z jednego urzadzenia.

IMAP (Internet Message Access Protocol) na porcie 143 sluzy do odbierania poczty z serwera, ale wiadomosci pozostaja na serwerze. IMAP synchronizuje stan wiadomosci (przeczytane, usuniete) miedzy wieloma urzadzeniami, co jest idealne dla uzytkowników korzystajacych z telefonu i komputera.

Opcje szyfrowane: SMTPS (SMTP przez TLS na porcie 465), POP3S (POP3 przez TLS na porcie 995) i IMAPS (IMAP przez TLS na porcie 993). Szyfrowanie TLS chroni hasla i tresc wiadomosci przed przechwyceniem w sieci lokalnej.

Protokoly zdalnego dostepu umozliwiaja zarzadzanie serwerami i urzadzeniami sieciowymi z odleglosci. Telnet (Telecommunication Network) na porcie 23 jest historycznym protokolem zdalnego terminala, ktory przesyla wszystkie dane (l acznie z haslami) w czystym tekscie.

Ze wzgledu na brak szyfrowania, Telnet jest uznawany za niebezpieczny i nie powinien byc uzywany w sieciach produkcyjnych. Haker moze latwo przechwycic haslo podczas logowania przez Telnet, uzywajac narzedzia typu Wireshark.

SSH (Secure Shell) na porcie 22 jest bezpieczna alternatywa dla Telnetu. SSH szyfruje cala komunikacje, l acznie z uwierzytelnianiem. Obsluguje rozne metody uwierzytelniania: haslo, klucz publiczny (RSA, ECDSA), Kerberos i uwierzytelnianie dwuskładnikowe.

SSH oferuje rowniez dodatkowe funkcje: tunelowanie (port forwarding) do bezpiecznego przekazywania ruchu TCP, przesyłanie plikow (SFTP, SCP), X11 forwarding do zdalnego uruchamiania aplikacji graficznych oraz wykonywanie polecen na zdalnym serwerze bez logowania (ssh user@host command).

Tabela najwazniejszych portow jest niezbedna sciagawka dla kazdego administratora sieci. Port 20/21 (FTP - Transfer plikow), port 22 (SSH - Zdalny dostep), port 23 (Telnet - Zdalny terminal), port 25 (SMTP - Wysylanie poczty), port 53 (DNS - Tlumaczenie nazw).

Port 67/68 (DHCP - Autokonfiguracja sieci), port 80 (HTTP - Strony WWW), port 110 (POP3 - Odbieranie poczty), port 143 (IMAP - Synchronizacja poczty), port 389 (LDAP - Katalog), port 443 (HTTPS - Szyfrowane WWW), port 993 (IMAPS), port 995 (POP3S).

Wazne jest zrozumienie, ze protokoly moga uzywac zarowno TCP, jak i UDP. DNS uzywa UDP dla standardowych zapytan (szybkosc) i TCP dla transferow stref (niezawodnosc). DHCP uzywa UDP, poniewaz klient nie ma jeszcze adresu IP i nie moze nawiazac polaczenia TCP.

Polecenie netstat -an | findstr :80 (Windows) lub ss -tlnp sport = :80 (Linux) pozwala na szybkie sprawdzenie, czy jakas aplikacja nasluchuje na danym porcie. Jest to pierwszy krok w diagnostyce problemow z dostepnoscia uslug.

Flagi TCP to 6 bitow w naglowku TCP, z ktorych kazdy steruje innym aspektem polaczenia. SYN (Synchronize) - inicjuje polaczenie, uzywany w pierwszym kroku Three-Way Handshake. ACK (Acknowledgment) - potwierdza odbior danych, ustawiony we wszystkich pakietach poza pierwszym SYN.

FIN (Finish) - konczy polaczenie, wysylany gdy host nie ma juz danych do wyslania. RST (Reset) - natychmiast przerywa polaczenie w przypadku bledu lub gdy port jest zamkniety. PSH (Push) - wymusza natychmiastowe przekazanie danych do aplikacji bez buforowania.

URG (Urgent) - oznacza pilne dane, ktore maja byc przetworzone przed normalnym strumieniem danych (rzadko uzywany). Wspolczesne implementacje TCP moga ignorowac flage URG ze wzgledow bezpieczenstwa (ataki typu Urgent pointer).

Wireshark pozwala na filtrowanie wedlug flag TCP: tcp.flags.syn==1 (tylko SYN), tcp.flags.reset==1 (tylko RST), tcp.flags.fin==1 (tylko FIN). W kolumnie Info widoczne jest podsumowanie flag dla kazdego pakietu, np. SYN, SYN-ACK, ACK, PSH-ACK, FIN-ACK.

Naglowek UDP ma stala dlugosc 8 bajtow, co czyni go jednym z najprostszych naglowkow w protokolach internetowych. Source Port (16 bitow) i Destination Port (16 bitow) identyfikuja aplikacje zrodlowa i docelowa. Wartosc 0 w Source Port oznacza, ze port nie jest uzywany (zapytania DNS).

Length (16 bitow) okresla calkowita dlugosc datagramu UDP l acznie z 8-bajtowym naglowkiem. Minimalna wartosc to 8 (sam naglowek), maksymalna teoretycznie 65535, ale w praktyce ograniczona przez MTU. Checksum (16 bitow) jest opcjonalny w IPv4, ale wymagany w IPv6.

Pole Checksum w UDP jest wyliczane dla pseudonaglowka (IP zrodla, IP celu, Protocol, Length UDP) i danych UDP. W IPv4 pole Checksum moze byc ustawione na 0 (wylaczone), ale w IPv6 musi byc obliczone. Blad w Checksum powoduje odrzucenie datagramu bez powiadomienia.

Wireshark pokazuje datagram UDP w sekcji User Datagram Protocol. Po rozwinięciu widoczne sa wszystkie cztery pola naglowka. W kolumnie Info wyswietlane jest podsumowanie: port zrodlowy -> port docelowy, dlugosc datagramu (np. 1234 -> 53 Len=40).

MSS (Maximum Segment Size) jest parametrem TCP negocjowanym podczas Three-Way Handshake. Oznacza maksymalny rozmiar danych uzytkownika (payload) w jednym segmencie TCP, bez naglowkow TCP i IP. MSS jest ustawiany na podstawie MTU interfejsu sieciowego.

Dla standardowego Ethernetu z MTU 1500 bajtow, domyslne MSS wynosi 1460 bajtow (1500 - 20 bajtow IP - 20 bajtow TCP). Dla laczy z mniejszym MTU (np. PPPoE 1492, tunel GRE 1476) MSS musi byc odpowiednio mniejsze, aby uniknac fragmentacji IP.

Jesli nadawca wysyla segment wiekszy niz MSS odbiorcy, router musi fragmentowac pakiet na poziomie IP. Fragmentacja zwieksza narzut i ryzyko utraty danych - jesli jeden fragment zginie, caly segment musi byc retransmitowany.

Path MTU Discovery (PMTUD) to mechanizm TCP, ktory wykrywa minimalne MTU na calej trasie od zrodla do celu. TCP wysyla segmenty z flaga DF (Don't Fragment) i w przypadku otrzymania ICMP Fragmentation Needed, zmniejsza MSS do wartosci zgodnej z MTU.

Port 80 jest domyslnym portem dla protokolu HTTP (Hypertext Transfer Protocol). Jest to jeden z najbardziej rozpoznawalnych portow w internecie, uzywany przez serwery WWW do obslugi nieszyfrowanego ruchu HTTP. Poniewaz HTTP przesyla dane w czystym tekscie, port 80 jest podatny na ataki z rodzaju man-in-the-middle.

Nowoczesne serwery WWW często przekierowuja ruch z portu 80 na port 443 (HTTPS) za pomoca kodu statusu HTTP 301 (Moved Permanently) lub 302 (Found). Dzieki temu uzytkownicy, ktorzy wpisza http://example.com, sa automatycznie przekierowani do https://example.com.

W niektorych sieciach (szkoly, firmy, hotspoty) port 80 jest uzywany do przekierowania na strone logowania (captive portal). Po uwierzytelnieniu uzytkownik ma dostep do internetu. Jest to realizowane przez mechanizm transparentnego proxy.

Z punktu widzenia diagnostyki, telnet example.com 80 pozwala na reczne wyslanie zadania HTTP do serwera i zobaczenie odpowiedzi. Jest to przydatne do testowania, czy serwer WWW odpowiada i jakie naglowki zwraca.

Rekord MX (Mail Exchange) w DNS okresla, jaki serwer poczty jest odpowiedzialny za odbior wiadomosci e-mail dla domeny. Rekord MX zawiera priorytet (liczba od 0 do 65535) i nazwe serwera poczty. Nizszy priorytet oznacza wyzszy priorytet - serwer z priorytetem 10 jest preferowany nad serwerem z priorytetem 20.

Wiele domen ma kilka rekordow MX z roznymi priorytetami dla zapewnienia niezawodnosci. Jesli glowny serwer poczty (niski priorytet) jest niedostepny, serwer nadawcy probuje dostarczyc poczte do serwera zapasowego (wyzszy priorytet). Miedzy serwerami o tym samym priorytecie ruch jest rownowazony.

Narzedzie dig domena MX (np. dig google.pl MX) wyswietla wszystkie rekordy MX dla domeny. Wynik zawiera priorytet i nazwe serwera poczty. nslookup -type=MX domena dziala podobnie w systemie Windows.

Konfiguracja rekordow MX jest krytyczna dla dzialania poczty w domenie. Bledny rekord MX (nieistniejacy serwer, zly priorytet) powoduje, ze poczta nie bedzie dostarczana. Dodatkowo rekordy SPF (TXT) i DKIM (TXT) sluza do uwierzytelniania nadawcy i zapobiegania spamowi.

POP3 (Post Office Protocol version 3) i IMAP (Internet Message Access Protocol) roznia sie fundamentalnie w podejsciu do zarzadzania poczta. POP3 pobiera wiadomosci z serwera na klienta i domyslnie usuwa je z serwera, co oznacza, ze wiadomosci sa dostepne tylko na urzadzeniu, z ktorego zostaly pobrane.

IMAP przechowuje wiadomosci na serwerze i synchronizuje ich stan miedzy urzadzeniami. Oznacza to, ze wiadomosc przeczytana na telefonie jest oznaczona jako przeczytana rowniez na komputerze. IMAP lepiej nadaje sie dla uzytkownikow korzystajacych z wielu urzadzen (telefon, laptop, tablet).

POP3 uzywa portu 110 (lub 995 dla POP3S), IMAP uzywa portu 143 (lub 993 dla IMAPS). POP3 jest prostszy i zuzywa mniej pamieci na serwerze, ale IMAP oferuje bogatsze funkcje, takie jak foldery, przeszukiwanie na serwerze i czesciowe pobieranie wiadomosci.

Wybór miedzy POP3 a IMAP zalezy od potrzeb uzytkownika. Dla pojedynczego urzadzenia i oszczedzania miejsca na serwerze - POP3 jest odpowiedni. Dla dostepu z wielu urzadzen i synchronizacji - IMAP jest lepszym wyborem.

HTTP 404 (Not Found) jest jednym z najbardziej rozpoznawalnych kodow bledu w internecie. Nalezy do kategorii 4xx (bledy klienta), co oznacza, ze problem lezy po stronie klienta - zazwyczaj bledny URL, usuniety zasob lub niedzialajacy link.

Inne czeste kody 4xx: 400 Bad Request (bledne zadanie, np. bledna skladnia), 401 Unauthorized (wymagane uwierzytelnienie), 403 Forbidden (brak uprawnien), 405 Method Not Allowed (metoda HTTP niedozwolona dla zasobu), 408 Request Timeout (przekroczenie czasu oczekiwania).

Kody 5xx (bledy serwera): 500 Internal Server Error (ogolny blad serwera), 502 Bad Gateway (bledna odpowiedz z serwera posredniego), 503 Service Unavailable (serwer przeladowany lub w konserwacji), 504 Gateway Timeout (przekroczenie czasu odpowiedzi serwera posredniego).

Z punktu widzenia diagnostyki, kody HTTP mozna sprawdzic za pomoca narzedzi takich jak curl (Linux) lub w przegladarce w zakladce Network (F12). curl -I https://example.com wyswietla tylko naglowki odpowiedzi, w tym kod statusu HTTP.

Proces DORA (Discover, Offer, Request, ACK) jest sercem protokolu DHCP. Discover: klient wysyla broadcast na 255.255.255.255 z adresem zrodlowym 0.0.0.0, pytajac o dostepne serwery DHCP. Offer: serwer odpowiada, proponujac adres IP i konfiguracje sieciowa.

Request: klient wybiera jedna oferte (jesli jest wiele serwerow) i wysyla zadanie o przydzial adresu. ACK: serwer potwierdza przydzial, a klient konfiguruje interfejs sieciowy z otrzymanymi parametrami (adres IP, maska, brama, DNS).

W przypadku bledu, serwer wysyla DHCPNAK (Negative Acknowledgment), co wymusza na kliencie rozpoczęcie procesu od nowa. Typowe przyczyny DHCPNAK: adres IP juz uzywany przez inne urzadzenie, wyczerpana pula adresow, nieautoryzowany klient.

Wireshark z filtrem dhcp lub bootp umozliwia przechwycenie wszystkich czterech pakietow DORA. Analiza pakietow pozwala na identyfikacje czasu odpowiedzi serwera DHCP, proponowanego adresu IP i wszystkich negocjowanych opcji.

FTP (File Transfer Protocol) i SFTP (SSH File Transfer Protocol) to dwa rozne protokoly do transferu plikow. FTP jest starszym protokolem (RFC 959 z 1985 roku), ktory przesyla dane w czystym tekscie, l acznie z haslami. SFTP jest nowszym protokolem dzialajacym przez SSH (port 22).

FTP uzywa dwoch oddzielnych polaczen TCP: kanal kontrolny (port 21) do komend i kanal danych (port 20) do danych. SFTP uzywa jednego polaczenia SSH do wszystkich operacji, co jest bezpieczniejsze i latwiejsze w konfiguracji przez firewalle.

Tryby FTP: Active (serwer łączy sie z klientem na porcie danych - blokowane przez firewalle) i Passive (klient łączy sie z serwerem na porcie danych - dziala przez firewalle). Passive FTP wymaga okreslenia zakresu portow pasywnych na serwerze.

Ze wzgledow bezpieczenstwa, zaleca sie uzywanie SFTP lub FTPS zamiast FTP. Wiele nowoczesnych IDE i klientow FTP (FileZilla, WinSCP) obsluguje wszystkie trzy protokoly i automatycznie wybiera szyfrowane polaczenie, jesli jest dostepne.

Keep-Alive w HTTP/1.1 to mechanizm, ktory pozwala na wyslanie wielu zadan HTTP w ramach jednego polaczenia TCP, bez koniecznosci powtarzania Three-Way Handshake dla kazdego zadania. Przed HTTP/1.1 (HTTP/1.0) kazde zadanie wymagalo nowego polaczenia TCP.

Keep-Alive znacznie poprawia wydajnosc stron WWW, poniewaz nowoczesna strona moze wymagac pobrania kilkudziesieciu zasobow (HTML, CSS, JS, obrazy). Bez Keep-Alive kazdy zasob wymagalby osobnego Three-Way Handshake, co zwiekszyloby opoznienie.

Naglowek Connection: keep-alive jest domyslnie uzywany w HTTP/1.1. Serwer i klient moga okreslic maksymalna liczbe zadan w ramach jednego polaczenia (Keep-Alive: max=100) i maksymalny czas bezczynnosci przed zamknieciem polaczenia (Keep-Alive: timeout=5).

Wireshark pozwala na zobaczenie efektu Keep-Alive w sesji HTTP: wiele zadan GET wysylanych w ramach jednego polaczenia TCP bez SYN miedzy nimi. Bez Keep-Alive kazde zadanie rozpoczynaloby sie od nowego pakietu SYN.

TLS Handshake (RFC 8446 dla TLS 1.3) jest procesem, w ktorym klient i serwer uzgadniaja parametry szyfrowanej komunikacji. W TLS 1.2 handshake wymagal dwoch rund (2 RTT), podczas gdy TLS 1.3 skrocil go do jednej rundy (1 RTT), co znacznie przyspiesza nawiazywanie polaczenia.

W pierwszym kroku klient wysyla ClientHello z lista obslugiwanych algorytmow szyfrowania (cipher suites), losowa liczba (client random) i opcjonalnie lista rozszerzen TLS (SNI, ALPN). Serwer odpowiada ServerHello z wybranym algorytmem i wlasna losowa liczba.

Nastepnie serwer wysyla swoj certyfikat X.509 (Certificate), opcjonalnie zada certyfikatu klienta (CertificateRequest) i wysyla ServerHelloDone. Klient weryfikuje certyfikat serwera z lista zaufanych urzedow certyfikacji (CA) i sprawdza, czy nazwa domeny sie zgadza.

Po wymianie kluczy za pomoca Diffie-Hellman (lub RSA), obie strony generuja klucz sesji uzywany do szyfrowania symetrycznego (AES, ChaCha20). Wireshark z TLS pokazuje ClientHello, ServerHello, Certificate i nastepnie Encrypted Handshake Message.

Narzedzie dig (Domain Information Groper) jest zaawansowanym narzedziem do zapytan DNS, dostepnym w systemach Unix/Linux. W porownaniu z nslookup, dig oferuje bardziej szczegolowe wyniki i wiecej opcji. dig google.pl A wyswietla szczegoly zapytania o rekord A.

Wynik dig zawiera sekcje: HEADER (status, flaga AA - autorytatywna odpowiedz), QUESTION (zapytanie), ANSWER (odpowiedz z TTL i adresem IP), AUTHORITY (autorytatywny serwer DNS) i ADDITIONAL (dodatkowe informacje, np. adres IP serwera DNS).

Przydatne opcje dig: +short (tylko adres IP), +trace (sledzenie calej sciezki DNS od root do autorytatywnego serwera), -x adres_IP (odwrotne zapytanie), @serwer_DNS (zapytanie do konkretnego serwera), MX (tylko rekord MX), ANY (wszystkie typy).

dig +trace google.pl pokazuje, jak zapytanie DNS przechodzi przez serwery root, serwery TLD (.pl) i autorytatywny serwer google.pl. Jest to doskonaly przyklad działania hierarchicznej struktury DNS i niezbedne narzedzie diagnostyczne.

Metody HTTP GET i POST roznia sie przede wszystkim przeznaczeniem i sposobem przekazywania danych. GET sluzy do pobierania zasobow - parametry sa przekazywane w URL (np. /search?q=test), co czyni je widocznymi w historii przegladarki i logach serwera.

POST sluzy do wysylania danych do przetworzenia - parametry sa przekazywane w ciele zadania (body), a nie w URL. POST jest uzywany do formularzy logowania, przesyłania plikow i tworzenia zasobow. Dane w POST nie sa widoczne w URL ani w historii przegladarki.

Inne wazne metody: PUT (zastapienie calej zasobu), PATCH (czesciowa modyfikacja), DELETE (usuniecie), HEAD (pobranie tylko naglowkow - szybkie sprawdzenie istnienia zasobu), OPTIONS (pytanie o dozwolone metody OPTIONS).

Z punktu widzenia bezpieczenstwa, GET nie powinien byc uzywany do operacji zmieniajacych stan (np. usuwanie uzytkownika przez GET /users/delete?id=5). POST, PUT i DELETE sa bezpieczniejsze, poniewaz nie moga byc wywolane przez klikniecie w link ani przez przegladarke.

Gniazdo sieciowe (socket) jest abstrakcyjnym punktem koncowym komunikacji sieciowej. W systemie operacyjnym gniazdo jest reprezentowane przez deskryptor pliku, co oznacza, ze do komunikacji sieciowej moga byc uzywane standardowe funkcje odczytu i zapisu plikow.

Gniazdo jest jednoznacznie identyfikowane przez piec atrybutow: protokol (TCP/UDP), adres IP zrodla, port zrodla, adres IP celu i port celu. Dzieki temu serwer na pojedynczym adresie IP moze ob slugiwac tysiace polaczen - kazde ma unikalna kombinacje.

API Berkeley Sockets definiuje funkcje: socket() - tworzy gniazdo, bind() - przypisuje adres IP i port, connect() - łączy sie z serwerem, listen() - przechodzi w tryb nasluchiwania, accept() - przyjmuje polaczenie, send()/recv() - wysyla/odbiera dane, close() - zamyka gniazdo.

Polecenie netstat -an (Windows/Linux) lub ss -tlnp (Linux) wyswietla wszystkie aktywne gniazda. Dla kazdego gniazda widac: protokol (TCP/UDP), adres lokalny (IP:port), adres zdalny (IP:port) i stan (LISTEN, ESTABLISHED, TIME-WAIT). W systemie Linux -p pokazuje PID i nazwe procesu.

Flaga RST (Reset) w TCP sluzy do natychmiastowego przerwania polaczenia, bez koniecznosci przechodzenia przez procedure FIN. RST jest wysylany w kilku sytuacjach: gdy host otrzymuje pakiet dla nieistniejacego polaczenia, gdy port docelowy jest zamkniety, lub w przypadku bledu protokolu.

Najczestsza przyczyna RST: proba polaczenia z zamknietym portem. Gdy serwer nie ma aplikacji nasluchujacej na danym porcie TCP, odpowiada pakietem RST zamiast SYN-ACK. Wireshark pokazuje to jako SYN-RST lub port unreachable.

RST moze byc rowniez wygenerowany przez firewall, ktory blokuje polaczenie. W takim przypadku firewall wysyla RST do klienta (lub po prostu odrzuca pakiet, symulujac brak odpowiedzi). Wireshark pokazuje RST z adresem IP firewalla.

Diagnostyka RST: jesli widzisz wiele pakietow RST w przechwyconym ruchu, sprawdz, czy aplikacja na docelowym porcie jest uruchomiona (netstat -an). Jesli port jest otwarty, RST moze wskazywac na firewall blokujacy polaczenie lub blad w aplikacji.

Kody statusu HTTP dziela sie na piec klas, co ulatwia identyfikacje rodzaju problemu. 1xx (100-199) - informacyjne, 2xx (200-299) - sukces, 3xx (300-399) - przekierowanie, 4xx (400-499) - blad klienta, 5xx (500-599) - blad serwera.

Najwazniejsze kody: 200 OK (sukces), 201 Created (utworzono nowy zasob), 204 No Content (sukces, brak tresci), 301 Moved Permanently (staly przekierowanie), 302 Found (tymczasowe przekierowanie), 304 Not Modified (zasob niezmieniony - uzywanie cache).

Kody 4xx: 400 Bad Request (bledne zadanie), 401 Unauthorized (brak uwierzytelnienia), 403 Forbidden (brak uprawnien), 404 Not Found (zasob nie istnieje), 405 Method Not Allowed, 408 Request Timeout, 429 Too Many Requests (przekroczenie limitu zapytan).

Kody 5xx: 500 Internal Server Error (ogolny blad serwera), 502 Bad Gateway (bledna odpowiedz z upstream), 503 Service Unavailable (serwer przeladowany), 504 Gateway Timeout (przekroczenie czasu oczekiwania na upstream), 505 HTTP Version Not Supported.

Rekord CNAME (Canonical Name) w DNS tworzy alias domeny. Na przyklad, jesli www.example.com jest aliasem CNAME dla example.com, to zapytanie DNS o www.example.com zwróci adres IP taki sam jak example.com. CNAME ulatwia zarzadzanie domena - zmiana adresu IP w rekordzie A automatycznie dotyczy wszystkich aliasow.

Wazne: rekord CNAME nie moze wspolistniec z innymi typami rekordow dla tej samej nazwy. Nie mozna miec rekordow A i CNAME dla www.example.com jednoczesnie. Ponadto, rekord CNAME moze wskazywac tylko na inna nazwe domeny, a nie bezposrednio na adres IP.

CNAME jest czesto uzywany w uslugach CDN (Content Delivery Network) i cloud hosting. Na przyklad cdn.example.com moze byc aliasem dla domena.cloudfront.net (Amazon CloudFront). Dzieki temu zmiana dostawcy CDN wymaga tylko zmiany rekordu CNAME, bez zmiany konfiguracji strony.

W praktyce administratorow sieci, dig www.example.com CNAME pokazuje alias, a dig example.com A pokazuje rzeczywisty adres IP. Przykladowo: dig www.google.com CNAME zwraca odpowiedz (www.google.com jest aliasem), co pozwala zrozumiec strukture DNS duzych serwisow.

Buforowanie DNS (DNS caching) jest kluczowym mechanizmem poprawiajacym wydajnosc i zmniejszajacym obciazenie serwerow DNS. Kiedy resolver DNS otrzyma odpowiedz na zapytanie, przechowuje ja w lokalnej pamieci podrecznej na czas okreslony przez TTL (Time To Live) w odpowiedzi.

TTL jest podawany w sekundach i moze byc rozny dla roznych typow rekordow. Typowe wartosci TTL: 300 (5 minut) dla serwerow o czesto zmieniajacym sie adresie IP, 86400 (24 godziny) dla stabilnych domen. Krotki TTL umozliwia szybka zmiane adresu IP, ale zwieksza obciazenie serwerow DNS.

W systemie Windows pamiec podreczna DNS mozna wyswietlic poleceniem ipconfig /displaydns i wyczyscic ipconfig /flushdns. W Linux cache DNS jest zarzadzany przez systemd-resolved lub dnsmasq i mozna go wyczyscic przez systemctl restart systemd-resolved.

Atak DNS cache poisoning (trucie pamieci podrecznej DNS) polega na wstrzyknieciu falszywej odpowiedzi DNS do cache resolwera. Ofiara jest przekierowywana na falszywa strone bez swojej wiedzy. Zabezpieczeniem jest DNSSEC (DNS Security Extensions), ktory podpisuje cyfrowo odpowiedzi DNS.

Sprawdzanie otwartych portow jest podstawowa czynnoscia diagnostyczna w administracji sieci. Najprostszym narzedziem jest netstat -an (Windows/Linux), ktory wyswietla wszystkie aktywne polaczenia i nasluchujace porty. W systemie Linux ss -tlnp jest szybsza alternatywa.

Narzedzie nmap (Network Mapper) sluzy do zdalnego skanowania portow. nmap -p 80,443 example.com skanuje porty 80 i 443 na zdalnym serwerze. nmap -sT example.com wykonuje skanowanie TCP Connect (pelne polaczenie TCP), a nmap -sS example.com wykonuje skanowanie SYN (half-open).

Ręczne testowanie portu: telnet adres_IP port (np. telnet smtp.gmail.com 25). Jesli port jest otwarty, telnet wyswietli komunikat polaczenia. Jesli port jest zamkniety, telnet zakonczy sie bledem polaczenia (lub RST). UWAGA: Skanowanie portow bez zgody moze byc nielegalne!

W kontekscie bezpieczenstwa, zamkniete porty (brak nasluchujacej aplikacji) sa pierwsza linia obrony przed atakami. Nalezy regularnie audytowac otwarte porty na serwerach za pomoca nmap i zamykac niepotrzebne uslugi, aby zminimalizowac powierzchnie ataku.

Telnet jest uzywany w diagnostyce sieci do testowania, czy port jest otwarty i czy serwer odpowiada. Polecenie telnet adres_IP port (np. telnet smtp.gmail.com 25) probuje nawiazac polaczenie TCP z okreslonym portem. Jesli polaczenie sie powiedzie, mozna recznie wyslac komendy protokolu.

Przyklad diagnostyki SMTP: telnet smtp.gmail.com 25 nawiazuje polaczenie z serwerem SMTP. Nastepnie mozna recznie wyslac komendy EHLO, MAIL FROM, RCPT TO i DATA, aby przetestowac dzialanie serwera poczty. Jest to przydatne przy diagnozowaniu problemow z wysylaniem poczty.

Przyklad diagnostyki HTTP: telnet example.com 80, a nastepnie GET / HTTP/1.1 i Host: example.com. Serwer odpowie naglowkami HTTP i trescia strony. Jesli polaczenie jest niemozliwe, prawdopodobnie firewall blokuje port lub serwer nie odpowiada.

Telnet jest czesto blokowany przez firewalle i nie jest domyslnie zainstalowany w nowszych wersjach Windows. W systemie Linux telnet mozna zainstalowac przez menedzer pakietow. Alternatywa jest nc (netcat), ktory oferuje wiecej funkcji niz telnet.

Analiza HTTP w Wireshark to podstawowe cwiczenie z diagnostyki protokolow sieciowych. Aby przechwycic ruch HTTP, uruchom Wireshark, wybierz interfejs sieciowy i ustaw filtr http. Nastepnie otworz przegladarke i wejdz na strone http:// (nie https:// - ruch HTTPS jest szyfrowany).

Po przechwyceniu zadania HTTP zidentyfikuj metode HTTP (GET/POST), naglowek Host (nazwa serwera), User-Agent (przegladarka), Accept (akceptowane typy MIME) i kod odpowiedzi (200 OK, 404 Not Found). Rozwin sekcje Hypertext Transfer Protocol, aby zobaczyc wszystkie pola.

W odpowiedzi HTTP sprawdz: kod statusu, Content-Type (typ MIME zasobu), Content-Length (dlugosc w bajtach), Server (oprogramowanie serwera), Date (data odpowiedzi) i Set-Cookie (ustawienie ciasteczka, jesli wystepuje).

Zapisz zrzut ekranu z rozwinietym naglowkiem HTTP w Wireshark. W raporcie z cwiczenia opisz kazde pole naglowka, jego znaczenie i wartosc dla przechwyconego ruchu. To cwiczenie rozwija umiejetnosc analizy protokolow na poziomie bitowym.

Badanie DNS i netstat to praktyczne cwiczenie z diagnostyki sieci. Rozpocznij od nslookup google.pl - sprawdz adres IP domeny. Nastepnie nslookup -type=MX google.pl - znajdz serwer poczty. Wykonaj nslookup -type=NS google.pl - sprawdz serwery nazw.

Polecenie netstat -an wyswietla wszystkie aktywne polaczenia sieciowe i nasluchujace porty. Zwroc uwage na rozne stany polaczen: LISTEN (nasluchiwanie), ESTABLISHED (aktywne polaczenie), TIME-WAIT (oczekiwanie po zamknieciu), CLOSE-WAIT (oczekiwanie na zamkniecie przez aplikacje).

W systemie Windows netstat -anb pokazuje PID i nazwe procesu dla kazdego polaczenia. W systemie Linux ss -tlnp sport = :80 pokazuje tylko gniazda TCP nasluchujace na porcie 80 wraz z informacja o procesie.

Porownaj wyniki przed i po otwarciu strony WWW. Zauwaz, jak zmienia sie liczba polaczen ESTABLISHED po zaladowaniu strony. Nowoczesna strona WWW moze wymagac kilkudziesieciu polaczen do roznych serwerow (domena glowna, CDN, reklamy, social media).

Cwiczenie dopasowywania portow do protokolow sprawdza znajomosc standardowych portow. Port 22 - SSH, port 80 - HTTP, port 443 - HTTPS, port 53 - DNS, port 25 - SMTP. Znajomosc tych portow jest niezbedna przy konfiguracji firewalli i diagnostyce problemow sieciowych.

Dodatkowe porty: port 20/21 - FTP, port 23 - Telnet, port 67/68 - DHCP, port 110 - POP3, port 143 - IMAP, port 389 - LDAP, port 3306 - MySQL, port 3389 - RDP (Remote Desktop Protocol), port 5432 - PostgreSQL.

Dla kazdego portu wazne jest zrozumienie, czy uzywa TCP, UDP, czy obu protokolow. DNS uzywa UDP dla standardowych zapytan i TCP dla transferow stref. DHCP uzywa UDP, poniewaz klient nie ma jeszcze adresu IP.

W praktyce administracyjnej plik /etc/services (Linux) lub C:\Windows\System32\drivers\etc\services (Windows) zawiera pelna liste zarejestrowanych portow i protokolow. netstat -an w polaczeniu z tym plikiem pozwala na szybka identyfikacje nasluchujacych uslug.

Przechwytywanie DNS w Wireshark to cwiczenie pokazujace, jak dziala system nazw domenowych w praktyce. Ustaw filtr dns w Wireshark, nastepnie wykonaj nslookup google.pl w konsoli. Wireshark przechwyci dwa pakiety: zapytanie DNS i odpowiedz DNS.

Rozwin pakiet zapytania DNS: Transaction ID (unikalny identyfikator zapytania), Flags (QR=0 - zapytanie, Opcode=0 - standardowe), Questions (sekcja pytan z nazwa domeny i typem A). Rozwin pakiet odpowiedzi DNS: Transaction ID (taki sam), QR=1 (odpowiedz), Answers (sekcja odpowiedzi z adresem IP i TTL).

W sekcji Answers odpowiedzi DNS widac: Name (zapytana domena), Type (A - adres IPv4), Class (IN - Internet), Time to Live (TTL w sekundach), Data Length (4 bajty dla IPv4) i Address (adres IP, np. 142.250.184.78 dla google.pl).

To cwiczenie pokazuje, jak Wireshark umozliwia analize kazdego aspektu komunikacji DNS, od identyfikatora transakcji po szczegoly odpowiedzi. Jest to niezbedna umiejetnosc dla administratorow sieci diagnozujacych problemy z rozwi azywaniem nazw.

Obserwacja procesu DORA w Wireshark to praktyczne cwiczenie pokazujace, jak DHCP przydziela adresy IP. Ustaw filtr dhcp lub bootp w Wireshark, nastepnie w konsoli Windows wykonaj ipconfig /release i ipconfig /renew. W Linux uzyj dhclient.

Wireshark pokaze cztery pakiety: DHCP Discover (broadcast z adresem zrodlowym 0.0.0.0 i docelowym 255.255.255.255), DHCP Offer (serwer proponuje adres IP), DHCP Request (klient potwierdza wybor) i DHCP ACK (serwer potwierdza przydzial).

Rozwin pakiet DHCP Offer, aby zobaczyc: Your (Client) IP Address (proponowany adres IP), Subnet Mask (maske podsieci), Router (brama domyslna), Domain Name Server (serwery DNS), IP Address Lease Time (czas dzierzawy), DHCP Server Identifier (adres serwera DHCP).

To cwiczenie pokazuje, jak DHCP automatyzuje konfiguracje sieciowa. Bez DHCP kazde urzadzenie musialoby byc recznie konfigurowane, co w sieciach z setkami urzadzen byloby niemozliwe. DHCP to jeden z najwazniejszych protokolow w administracji sieci.

Analiza sesji TCP w Wireshark to zaawansowane cwiczenie, ktore pozwala na zrozumienie pelnego cyklu zycia polaczenia TCP. Przechwyc ruch do dowolnej strony HTTP (nie HTTPS). Zastosuj filtr tcp.port==80 i kliknij prawym przyciskiem na dowolnym pakiecie -> Follow -> TCP Stream.

W oknie Follow TCP Stream widac cala wymiane danych miedzy klientem a serwerem: zadanie HTTP (GET / HTTP/1.1, Host, User-Agent, Accept) i odpowiedz serwera (HTTP/1.1 200 OK, naglowki, tresc HTML). Dane sa wyswietlane w kolejnosci transmisji.

Zidentyfikuj trzy pakiety Three-Way Handshake (SYN, SYN-ACK, ACK) na poczatku sesji. Sprawdz numery sekwencyjne i potwierdzenia. Na koncu sesji zidentyfikuj pakiety FIN lub RST konczace polaczenie.

To cwiczenie pokazuje, jak TCP zapewnia niezawodna komunikacje: segmentacja, sekwencjonowanie, potwierdzenia i zamykanie polaczenia. Zrozumienie tych mechanizmow jest niezbedne dla kazdego specjalisty IT.

Podsumowanie zdobytej wiedzy z zakresu protokolow warstwy transportowej i aplikacji obejmuje kluczowe koncepcje. TCP dzieli dane na segmenty i gwarantuje dostarczenie dzieki mechanizmowi potwierdzen (ACK), retransmisji i kontroli przeplywu przez okno (rwnd, cwnd).

UDP jest protokolem bezpolaczeniowym, ktory oferuje szybka transmisje bez gwarancji dostarczenia. Naglowek UDP ma stale 8 bajtow, co czyni go znacznie bardziej oszczednym niz TCP (minimum 20 bajtow). UDP jest idealny dla aplikacji czasu rzeczywistego.

HTTP/HTTPS to podstawa komunikacji WWW. HTTP dziala na porcie 80, HTTPS na porcie 443 z szyfrowaniem TLS. DNS tlumaczy nazwy domen na adresy IP, a DHCP automatyzuje konfiguracje sieciowa urzadzen poprzez proces DORA.

Znajomosc standardowych portow (20/21 FTP, 22 SSH, 25 SMTP, 53 DNS, 80 HTTP, 110 POP3, 143 IMAP, 443 HTTPS) jest niezbedna dla kazdego administratora sieci. Wireshark pozwala na analize kazdego aspektu komunikacji sieciowej.

Sciagawka protokolow sieciowych przedstawia najwazniejsze protokoly warstwy aplikacji i transportowej. HTTP (port 80 TCP) - strony WWW, HTTPS (port 443 TCP) - szyfrowane WWW, DNS (port 53 TCP/UDP) - tlumaczenie nazw, DHCP (port 67/68 UDP) - konfiguracja IP.

FTP (port 20/21 TCP) - transfer plikow, SSH (port 22 TCP) - zdalny dostep, SMTP (port 25 TCP) - wysylanie poczty, POP3 (port 110 TCP) - odbieranie poczty offline, IMAP (port 143 TCP) - synchronizacja poczty miedzy urzadzeniami.

Dodatkowe protokoly: Telnet (port 23 TCP) - zdalny terminal (niebezpieczny), SMTPS (port 465 TCP) - szyfrowane wysylanie poczty, POP3S (port 995 TCP) - szyfrowane odbieranie poczty, IMAPS (port 993 TCP) - szyfrowana synchronizacja poczty.

Znajomosc tych protokolow i ich portow jest kluczowa przy konfiguracji firewalli, diagnostyce problemow sieciowych i audytach bezpieczenstwa. Wiele atakow polega na wykorzystaniu niepotrzebnie otwartych portow.

Pytania do samodzielnej powtorki sprawdzaja zrozumienie kluczowych koncepcji. Flagi TCP: SYN (synchronizacja), ACK (potwierdzenie), FIN (konczenie), RST (reset), PSH (push), URG (pilne). Kazda flaga ma okreslone znaczenie w sterowaniu polaczeniem TCP.

Naglowek TCP ma minimalnie 20 bajtow (z opcjami do 60), naglowek UDP ma stale 8 bajtow. Roznica wynika z pol TCP potrzebnych do numerow sekwencyjnych, potwierdzen, okna i flag. UDP ma tylko porty, dlugosc i sume kontrolna.

Three-Way Handshake: SYN (klient -> serwer), SYN-ACK (serwer -> klient), ACK (klient -> serwer). Po tym polaczenie przechodzi w stan ESTABLISHED. DORA w DHCP: Discover, Offer, Request, ACK. Kody HTTP: 1xx (info), 2xx (sukces), 3xx (przekierowanie), 4xx (blad klienta), 5xx (blad serwera).

Zaleca sie przeanalizowanie kazdego z tych pytan i sprawdzenie odpowiedzi w materialach wykladu. Zrozumienie tych koncepcji jest niezbedne do dalszej nauki diagnostyki sieciowej i protokolow wyzszych warstw.

Odpowiedzi do pytan powtorkowych: Flagi TCP to SYN, ACK, FIN, RST, PSH, URG. SYN inicjuje polaczenie, ACK potwierdza odbior, FIN konczy polaczenie, RST natychmiast przerywa, PSH wymusza przekazanie do aplikacji, URG oznacza pilne dane.

Naglowek TCP ma minimalnie 20 bajtow (5 slow 32-bitowych). Naglowek UDP ma stale 8 bajtow (2 slowa 32-bitowe). Rózica 12 bajtow wynika z dodatkowych pol TCP (Sequence Number, ACK Number, Window, Flags, Options).

Three-Way Handshake: SYN -> SYN-ACK -> ACK. Po trzecim pakiecie polaczenie ESTABLISHED. DORA: Discover (szukanie serwera), Offer (propozycja adresu), Request (zadanie o adres), ACK (potwierdzenie przydzialu).

Kody HTTP: 1xx informacyjne (100 Continue), 2xx sukces (200 OK), 3xx przekierowanie (301, 302), 4xx blad klienta (400, 401, 403, 404), 5xx blad serwera (500, 502, 503). Znajomosc tych kodow ulatwia szybka diagnostyke problemow WWW.

Narzedzia do analizy protokolow sa niezbedne w codziennej pracy administratora sieci. Wireshark jest graficznym analizatorem pakietow oferujacym szeroki zakres filtrow (http, dns, tcp.port==443), statystyki (Protocol Hierarchy, IO Graph) i funkcje (Follow TCP Stream).

tcpdump jest konsolowym analizatorem pakietow dla systemow Unix/Linux. tshark jest konsolowa wersja Wireshark. Oba sa przydatne na serwerach bez interfejsu graficznego. Przyklad tcpdump: tcpdump -i eth0 port 80 -w http.pcap przechwytuje ruch HTTP do pliku.

netstat (Windows/Linux) i ss (Linux) wyswietlaja aktywne polaczenia i nasluchujace porty. nslookup i dig sluza do zapytan DNS. telnet testuje polaczenia TCP. nmap skanuje porty na zdalnych hostach.

Zaleca sie systematyczne uczenie kazdego z tych narzedzi. W praktyce administracyjnej czesto konieczne jest uzycie kilku narzedzi jednoczesnie do zdiagnozowania problemu - na przyklad Wireshark do przechwycenia ruchu i netstat do sprawdzenia lokalnych polaczen.

Testowanie portów za pomoca telnet to praktyczne cwiczenie diagnostyczne. telnet google.pl 80 probuje nawiazac polaczenie TCP z serwerem Google na porcie 80. Jesli polaczenie sie powiedzie, widoczne jest puste okno lub komunikat polaczenia.

Po udanym polaczeniu mozna recznie wyslac zadanie HTTP: GET / HTTP/1.1 (Enter), Host: google.pl (Enter), (Enter). Serwer odpowie naglowkami HTTP i trescia strony. To samo cwiczenie mozna wykonac dla innych portow, np. telnet smtp.gmail.com 25 (SMTP).

Jesli telnet nie jest dostepny (nowsze wersje Windows), mozna uzyc Putty (tryb Raw) lub PowerShell: Test-NetConnection google.pl -Port 80. W Linux mozna uzyc nc (netcat): nc -v google.pl 80, ktory oferuje wiecej opcji niz telnet.

To cwiczenie pokazuje, jak protokoly warstwy aplikacji dzialaja na poziomie tekstowym. Wiele protokolow (HTTP, SMTP, POP3) uzywa komend tekstowych, ktore mozna recznie wyslac przez telnet, co jest przydatne w diagnostyce.

Porownanie HTTP i HTTPS w Wireshark pokazuje fundamentalna roznice miedzy szyfrowana a nieszyfrowana komunikacja. Przechwyc ruch do http://example.com (port 80) - wszystkie naglowki i tresc sa widoczne w czystym tekscie, l acznie z danymi formularzy.

Nastepnie przechwyc ruch do https://example.com (port 443) - widac tylko ClientHello, ServerHello, Certificate Exchange i nastepnie zaszyfrowane Application Data. Tresc zadania i odpowiedzi jest nieczytelna bez klucza prywatnego serwera.

W HTTP widac pelna tresc: metode GET/POST, naglowki, ciasteczka, parametry URL i tresc strony. W HTTPS widac tylko: adres IP serwera, port, SNI (Server Name Indication) w ClientHello - czyli nazwe domeny, oraz rozmiar zaszyfrowanych pakietow.

To cwiczenie uzasadnia koniecznosc stosowania HTTPS na stronach WWW. HTTPS chroni nie tylko hasla i dane logowania, ale rowniez prywatnosc uzytkownikow - atakujacy nie moze zobaczyc, jakie strony odwiedza ofiara (poza domena glowna dzieki SNI).

Dobre praktyki analizy sieci sa kluczowe dla efektywnej diagnostyki. We Wireshark uzywaj display filtrow do precyzyjnego wyswietlania ruchu: http, dns, tcp.port==443, ip.addr==192.168.1.1. Filtry znacznie upraszczaja analize w ruchu o duzym wolumenie.

Uzywaj Follow TCP Stream (kliknij prawym na pakiecie TCP -> Follow -> TCP Stream) do zobaczenia calej sesji komunikacji miedzy klientem a serwerem. To pokazuje pelna wymiane danych w kolejnosci chronologicznej.

Statystyki Wireshark: Protocol Hierarchy pokazuje, jakie protokoly sa uzywane i jaki udzial w ruchu ma kazdy z nich. IO Graph pokazuje przepustowosc w czasie, co pomaga w identyfikacji skokow ruchu. Statistics -> Endpoints pokazuje liste wszystkich hostow w sieci.

Zapisuj przechwycony ruch do pliku pcap (File -> Save As) do pozniejszej analizy. Pliki pcap moga byc otwierane w kazdym analizatorze zgodnym z formatem (Wireshark, tcpdump, NetworkMiner). To standardowy format wymiany przechwyconego ruchu sieciowego.

Szosta czesc wykladu dotyczaca protokolow warstwy transportowej i aplikacji stanowi fundament wiedzy o komunikacji sieciowej. TCP i UDP to dwa podstawowe protokoly transportowe, kazdy z wlasnymi zaletami i wadami. Wybor miedzy nimi zalezy od wymagan aplikacji.

Protokoly warstwy aplikacji (HTTP, DNS, DHCP, FTP, SMTP, SSH) okreslaja, jak programy komunikuja sie przez siec. Kazdy z nich ma okreslony port, format wiadomosci i mechanizm dzialania. Znajomosc tych protokolow jest niezbedna w administracji sieci.

Wireshark jest niezastapionym narzedziem do analizy protokolow. Umożliwia przechwycenie, filtrowanie i szczegolowa analize kazdego pakietu. Narzedzia systemowe (netstat, nslookup, telnet) sa przydatne w szybkiej diagnostyce bez koniecznosci instalacji dodatkowego oprogramowania.

Nastepna czesc: Protokoly warstwy sieciowej i l acza - IP, ICMP, ARP, Ethernet, CSMA/CD, CSMA/CA, STP/RSTP. Praca wlasna: przechwyc w Wireshark ruch HTTP i HTTPS, porownaj widoczne informacje. Wykonaj nslookup dla 5 domen, sprawdz rozne typy rekordow.