Laboratoria 1-3

Gniazda TCP i UDP Gniazda – uniwersalny sposób komunikacji między procesami. Parę gniazd, tworzących kanał komunikacyjny, nazywamy asocjacją. Gniazda posiadają: - domenę komunikacyjną, w obrębie której odbywa się komunikacja - typ gniazda, określający sposób transmisji danych - protokół właściwy dla danej domeny komunikacyjnej i typu - informacje adresowe (adres, numer portu) służące do komunikacji GNIAZDO = ADRES IP + NUMER PORTU Funkcje gniazd: (nazwy argumentów nie są takie jak w dokumentacji, ale opisują do czego są argumenty) - socket (domain, type, protocol) – tworzy gniazdo - connect (descript, *sock_struct_adress, sock_struct_len) – połączenie klienta z serwerem - bind (descript, *sock_struct_adress, sock_struct_len) – przypisuje nazwę gniazdu - listen (descript, queue_len) – wywołanie serwerowe, przekształaca gniazdo w nasłuchujące - accept (descript, *sock_struct_addres, sock_struct_len) – akceptacja połączenia i utworzenie asocjacji - close (descript) – zamyka gniazdo poprzez zmniejszenie liczby deskryptorów o 1 - sendto(descript, *data, data_len, flags, *to_struct_addres, to_struct_len) – wysyłanie danych - send(descript, *data, data_len, flags) – wysyłanie danych dla ustalonego połączenia - recvfrom(descript, *data, data_len, flags, *from_struct_address, from_struct_len) – odbiór danych - recv(descript, *data, data_len, flags) – odbiór danych dla ustalonego połączenia Przeprowadzanie komunikacji klient-serwer TCP: klient server socket, bind, listen, accept socket BLOKADA DO USTALENIA POŁĄCZENIA connect <3-way> POŁĄCZENIE send -> recv PRZETWORZENIE ŻĄDANIA recv recv close

UDP: klient

sendto -> recvfrom
server socket, bind, recvfrom BLOKADA DO DATAGRAMU PRZETWARZANIE ŻĄDANIA sendto close

HTTP - Protokół bezstanowy pozwalający na komunikowanie się komputerów między sobą. Metody http: - GET – pobranie zasobu wskazanego przez URI (możliwa postać warunkowa jeżeli header z If-Modified-Since) - HEAD – pobieranie informacji o zasobie (sprawdzanie dostępności zasobu) - PUT – przyjęcie danych od klienta (aktualizacja encji) - POST – przyjęcie danych od klienta (np. zawartości formularza) - DELETE – żądanie usunięcia zasobu - OPTIONS – informacje o opcjach - TRACE – diagnostyka, analiza kanału - CONNECT – żądanie dla serwerów pośredniczących przy tunelowaniu (poza standardem 1.1, ale implementowane) - PATCH – aktualizacja części danych

Protokoły IPv4 i IPv6 IP – protokół służący do identyfikacji hostów lokalnych i zdalnych. Pozwala dzielić pakiety na mniejsze fragmenty i transmitować je, a następnie defragmentować po dotarciu do celu. Odrzuca pakiety przeterminowane. Protokół nie realizuje żadnych dodatkowych funkcji zabezpieczających transmisje (np. retransmisja). Bezpołączeniowy. IPv4 Wersja (4)

Długość nagłówka (4) Typ usługi (8) Całkowita długość (16) Numer identyfikujący (16) Flagi (3) Przesunięcie (13) Czas życia (8) Protokół warstwy wyższej (8) Suma kontrolna nagłówka (16) Adres źródłowy IP (32) Adres docelowy IP (32) Opcje (32 – wypełnienie) Wypełnienie (32 - opcje) Wersja – wersja protokołu Długość nagłówka – długość nagłówka wyrażona w 32bit słowach Typ – typ QoS, na podstawie tego router ustawia wartości transmisji Całkowita długość – długość datagramu IP (maks = 65535, min = 576 bajtów) Numer identyfikacyjny – identyfikuje pakiet po fragmentacji Flagi – do fragmentacji, pola: DF (możliwość fragmentacji), MG (czy jest ostatnim fragmentem) Przesunięcie –określa miejsce fragmentu w większym datagramie (jednostki ośmiooktetowe) Czas życia – liczba przeskoków jakie może przebyć datagram i nie zostać odrzuconym IPv6 Wersja (4)

Klasa ruchu (8) Długość danych (16)

Etykieta przepływu (20) Następny nagłówek (8) Limit przeskoków (8) Adres źródła (128) Adres docelowy (128) Wersja – wersja protokołu Klasa ruchu – sposób traktowania pakietu (poprzedni Typ) Etykieta przepływu – odróżnianie pakietów tego samego typu Długość danych – wielkość pakietu bez nagłówka (ale z nagłówkami rozszerzeń) Następny nagłówek – typ następnego nagłówka (rozszerzenia czy warstwy wyższej) Limit przeskoków – ilość węzłów po których przeskoczeniu pakiet zostaje odrzucony Nagłówki rozszerzające – zwiększają możliwości protokołu IPv6. Zdefiniowane nagłówki: - Hop-by-Hop Option – protokół 0. Sprawdzane przez router i stosowane dla router alerts i Jumbofram. - Opcje miejsca docelowego – protokół 60. Opcjonalne informacje dotyczące adresu docelowego. - Routingu – protokół 43. Pozwala wysłać pakiet przez konkretny router do węzła docelowego. - Fragmentacji – protokół 44. Opis reguł fragmentacji gdy węzeł nie ma PMTUD (coś jak defaultowe reguły) - Uwierzytelniania – protokół 51. IPsec (pole AH) by zapewnić uwierzytelnianie, integralność i bezpieczeństwo - ESP – protokół 50. IPsec (pole ESP) by zapewnić uwierzytelnianie, integralność i bezpieczeństwo Różnice między IPv6, a IPv4 - Rozszerzone adresy – adresy 128bit zamiast 32. Zakres adresu dla multicast i dodanie anycast (wysłanie pakietu do najbliżeszego węzła z grupy). - Uproszczenie formatu nagłówka – usunięcie lub zastąpienie opcjami niektórych pól z nagłówka. - Ulepszenie obsługi rozszerzeń nagłówków i opcji – opcje IP6 umieszczono w oddzielnych nagłówkach - Zdolność etykietowania przepływu – oznaczanie ruchu sieciowego z zapewnieniem danej jakości usługi (QoS) - Uwierzytelnianie i zdolność zapewnienia poufności – rozszerzenia pozwalają na uwierzytelnianie nadawcy, zapewnienie integralności oraz poufności danych Współdziałanie protokołów IPv4 i IPv6 - dual stack – implementacja obu wersji w stosach TCP/IP - dual layer (tunelowanie) – komunikowanie się hostów IP6 przez IP4 dzięki enkapsulacji pakietów IP6 w datagramach IP4 (LINUX – nie można utworzyć gniazda IP6 i IP4 na jednym porcie).

Stacje dwuprotokołowe - gniazda nasłuchujące IPv4 – połączenie tylko z klientem IPv4 - gniazda nasłuchujące IPv6 dowiązane do adresu uogólnionego – połączenie ze wszystkim - gniazdo nasłuchujące IPv6 dowiązane do adresu IPv6 nieutworzonego z IPv4 – połączenie z klient IPv4 Serwer dwuprotokołowy - datagram IP4 odebrany przez gniazdo IP4 – wymiana datagramów IP4 - datagram IP6 odebrany przez gniazdo IP6 – wymiana datagramów IP6 - datagram IP4 odebrany przez gniazdo IP6 – adres IP4 zostaje przetworzony do postaci IP6 (IPv4mapped IPv6). Wymiana datagramów IP4 Klient dwuprotokołowy - klient IP4 łączy się z serwerem IP4 – wymiana datagramów IP4 - klient IP6 łączy się z serwerem IP6 – wymiana datagramów IP6 - klient IP6 łączy się z serwerem IP4 poprzez adres przekształcony – wymiana datagramów IPv4 Klient IP4 <-> Serwer IP6 Serwer tworzy gniazdo IP6 z adresem uogólnionym -> klient wywołuje gethostbyname (otrzymuje rekord A) -> klient wywołuje funkcję connect (wysyła SYN) -> serwer odbiera SYN i ustawia flagę mówiącą, że w tym połączeniu stosowane są adresy przekształcone (IPv4-mapped IPv6) -> użycie datagramów IPv4 Klient IP6 <-> Serwer IP4 Serwer tworzy gniazdo nasłuchujące IP4 -> klient wywołuje gethostbyname (żadanie adresów IP6) -> klient wywołuje connect z adresem IP6 utworzonym z IP4 -> stacja serwera wysyła SYN/ACK (protokół IP4) Struktury adresowe w komunikacji IPv4 i IPv6 Sockaddr – ogólna struktura gniazdowa, do której rzutują wskaźniki struktur adresowych IP4 i IP6 sockaddr_in – informacje adresowe IP4. Zawiera sin_family (domena adresowa), sin_port (numer portu), sin_addr (adres IP w big endian). sockaddr_in6 – informacje adresowe IP6. Dodatkowo zawiera sin6_flowinfo (brak zastosowania), sin6_scope_id (indeks interfejsu dla adresów link-local) sockaddr_storace – struktura adresowa niezależna od rodziny protokołów. Pole ss_family określa rodzinę protokołów.

Opcje IP i gniazda surowe Gniazda surowe – idea programowania gniazd surowych opiera się na ręcznym modyfikowaniu nagłówków poszczególnych protokołów. Pozwala to na stosowanie protokołów, dla których w danym języku nie utworzono wyspecjalizowanych gniazd (lub tych nieprzetwarzanych w jądrze [wszystkie poza ICMP, IGMP, UDP, TCP]) czy ręczną zmianę pól normalnie uzupełnianych przez system operacyjny. Aby program mógł utworzyć gniazdo surowe musi posiadać zdolność CAP_NET_RAW (root gwarantuje). socket(comm_domain, sock_type, protocol) – tworzy gniazdo. Jeżeli chcemy surowe type = SOCK_RAW. Zwraca deskryptor gniazda lub -1 (niepowodzenie). bind() – dla gniazd surowych kojarzy adres z lokalnym gniazdem (numer portu nie ma znaczenia) connect() – kojarzy gniazdo z adresem zdalnym (nr portu nie ma znaczenia, pozwala użyć write, send, sendto) Funkcje sendto/recvfrom działają tak samo jak dla gniazd zwykłych, z tym że istnieje możliwość odczytania nagłówków przy ich pomocy. Reguły dotyczące datagramów: - UDP i TCP – nie są przesyłane do gniazd surowych, możliwe do przeczytania na poziomie datalink - ICMP – prócz komunikatów echo request, timestamp request, address mask request dochodzą do gniazd po przetworzeniu prze jądro - IGMP – dochodzą do gniazd po przetworzeniu przez jądro - IP z nieznanym polem protokołu – dochodzą do gniazda z pominięciem jądra Dla datagramów jądro zawsze sprawdza adres docelowy, sumę kontrolną, wersję protokołu i długość nagłówka. Jeżeli datagram jest pofragmentowany to najpierw jest składany, a potem przekazywany do gniazda. Aby datagram dotarł do danego gniazda muszą być spełnione następujące reguły: - trzeci argument socket() musi się zgadzać z polem protokół datagramu - adres lokalny gniazda powiązany funkcją bind() musi być taki sam jak adres docelowy datagramu - adres zdalny gniazda powiązany funckją connect() musi być taki sam jak adres źródłowy datagramu - gniazdo surowe zostało utworzone z protocol = 0 – wszystkie datagramy są kierowane do niego Funkcje opcji gniazd: setsockopt(s_desc, opt_lvl, optname, *optval, optlen) – ustawienie konkretnej opcji lub całego pole opcji (opt_lvl = IPPROTO_IP, optname = IP_OPTIONS) getsockopt(s_desc, opt_lvl, optname, *optval, optlen) – pobranie wartości opcji (dodatkowo wywołane z optname = IP_OPTIONS pozwala pobrać odwrotność trasy routingu) Jeżeli chcemy sami zbudować nagłówek należy ustawić opcję IP_HDRINCL (w Linux nie można dla IPv6). W takim wypadku musimy podać pola idntyfikatora, pola sumy kontrolnej oraz pola opcji IP. Inaczej początkiem danych do wysłania będzie pierwszy bajt po nagłówku automatycznie utworzonym przez system. Opcje IP – dodatkowe pole nagłówka IP. Definiowane przez jeden podzielony na trzy części bajt: zachowanie w przypadku fragmentacji (1 bit – wartość 1 sprawia, że opcja jest kopiowana do wszystkich fragmentów), klasa opcji (2 b – 0 to opcja kontrolna, 2 to debug), numer opcji(5 b). Do jednego bajta mogą zostać dodane kolejne dwa – z długością opcji i danymi opcji (czyli opcje mogą być jednym lub trzema oktetami). Wyróżnia się około 30 opcji IP. Najważniejsze to: - 0 – wyznacza koniec listy opcji - 1 – No Operation – pusta opcja - 2 – Security – kod zabezpieczający możliwy do odszukania w RFC 791 - 3 – Loose Source Routing – pozwala wyznaczyć routery przez które musi przejść pakiet - 4 – Internet Timestamp – przechowuje czas (ale nie wiem czego) - 7 – Record Route – zapisuje drogę przebytą przez datagram - 8 – Stream ID – id strumienia - 9 – Strict Source Routing – pozwala wyznaczyć kolejność w której pakiet będzie przesyłany do routerów Długość pola opcji nie może przekroczyć 40 bajtów ponieważ znajdujące się w nagłówku 4bitowe pole długości HL ogranicza długość nagłówka do 60bajtów.

PODSUMOWANIE PYTAŃ Z KOLOKWIUM 1:

Stany gniazd TCP/IP - SYN_RECVD, TIME_WAIT, CLOSE_WAIT lub SYN_SENT, LISTEN, ESTABILISHED Wireshark - sniffer, netstat - monitor Nawiązywanie połączenia TCP: SYN i S1, SYN i S2, ACK i S1, ACK i S2 W IPv6: dodano anycast, integralność i uwierzytelnienie danych, rozszerzenie adresu do 128bitów, możliwość szyfrowania, etykietowanie dual-stack (XP): dwie niezależne; dual-layer (Server, Vista): jedna współna warstwa transportowa pozwala stworzyć gniazdo dwuprotokołowe (JEDNO) na jednym porcie, nie pozwala dwóch IPC - Inter Process Communication, OSI - Open System Interconnection, IGMP - Internet Group Management Protocol HL w IPv4 ma 4 bity - ogranicza długość nagłówka TCP: socket->bind->listen->accept; UDP: socket->sendto->recvfrom->close write->sendto, read->recvfrom Pole opcji: pojedynczy oktet lub 3 oktety, Opcje w IP: jeden bajt podzielony na 3 Protokół IP - bezpołączeniowy, nie gwarantuje poprawności transmisji SUPERDEMON: fork robi proces, exec podmienia Sterownik NAT, TCP/IP: jądra, Win Sockets, netssh: user Oprogramowanie iteracyjnie klient-serwer: UPD + port efemeryczny Protokoły bezpieczeństwa nad warstwą transportową crypt(11)=32, crypt(12)=48, crypt(9)=35, crypt(19)=57 Interfejs = warstwa 3, adapter = warstwa 2 SPI dla warstwy transportowej NetBIOS: TCP do sesji, UDP do nazw i datagramów TCP 12345, UDP 12345 oraz 12346: będą działać w trybie serwera na jednej marzynie UDP zostaje zakończona po odebraniu zapytania od klienta: można ją włączyć ponownie od razu TCP - trzeba liczyć sumę kontrolną, UDP - nie trzeba : warstwa transportowa UDP - voip, TCP - ssh getsockopt - pobiera opcje gniazd; setsockopt - nadaje opcje Opcje w IPv6 - pozalają wytropić adres źródłowy bind - przypisuje nazwę gniazdu, accept - stan czynny, listen - stan bierny Enkapsulacja - przejście z IPv6 do IPv4 Nagłówek IPv6 - 40 bajtów, IPv4 - 20 do 40 bajtów Inspekcja w warstwie aplikacji - ftp ICMP - ping i traceroute Połączeni TCP i UDP wynosi 16 bitów (wtf?!) Firewall zablokuje wszystko wychodzące poza kilkoma wyjątkami