Wybrane protokoły górnych warstw OSI Marek Kozłowski Wydział Matematyki i Nauk Informacyjnych Politechnika Warszawska Warszawa, 2014/2015
Network Time Protocol (NTP, Mills) NTP wersja 3 definiowany jest w RFC 1305. Powszechnie wykorzystywana wersja 4 protokołu opisana jest na stronach: http://www.eecis.udel.edu/~mills/ntp.html http://www.ntp.org lecz nie jest ujęta w dokumentach IETF. Protokół Simple NTP (SNTP) opisany jest w RFC 4330. Popularną, lekką i przenośną implementacją SNTP jest OpenNTPD (OpenBSD). Implementacja obsługująca pełną wersję protokołu NTP dostępna są na stronach projektu NTP R&D, tj. http://www.ntp.org (otwarty kod w C).
Network Time Protocol (NTP, Mills) cd. Protokół NTP wykorzystuje UDP i domyślnie port 123 (NTP/SSL 563). Klient NTP może być zarazem serwerem NTP dla innych hostów. Wartość stratum określa precyzję hosta, tj. liczbę pośredników do źródła czasu: serwery primary (pobierające czas z zegara atomowego) mają stratum równe 1, serwery pobierające od nich czas 2 itd., aż do 15. Plikiem konfiguracyjnym jest ntp.conf, daemonem ntpd a programem klienckim ntpdate.
Coordinated Universal Time (UTC) Synchronizacja w protokole NTP przebiega wg czasu UTC, ustalanego wg wskazań zegara atomowego. Ze względu na nieregularność ruchu obrotowego Ziemi IERS (International Earth Rotation and Reference Systems Service) periodycznie wprowadza tzw. sekundy przestępne, pozwalające utrzymać niezgodność czasu UTC z czasem astronomicznym na poziomie poniżej 0.9 sekundy. Czasu UTC nie należy utożsamiać z czasem GMT (Greenwich Mean Time), który jest czasem słonecznym.
Telnet Protokół telnet standaryzowany jest przez RFC 854 861 (1983 rok). The purpose of the TELNET Protocol is to provide a fairly general, bi-directional, eight-bit byte oriented communications facility (RFC 854). Połączenie z serwerem telnet (port 23) umożliwia zdalną sesję. Sesja jest przeważnie nieszyfrowana, a jednostronne uwierzytelnienie następuje w oparciu o nazwę użytkownika i hasło. RFC 2941 2953 (2000 rok) rozszerzają protokół telnet o mechanizmy kryptograficzne, jednakże oprogramowanie klienckie często nie wspiera szyfrowania.
Telnet cd. Rozwój protokołu SSH zmarginalizował znaczenie telnetu jako protokołu zdalnej sesji. Oprogramowanie klienckie usługi telnet może być używane do zestawiania surowej sesji TCP z innymi usługami wykorzystującymi nieszyfrowane sesje TCP, jak np. SMTP (telnet smtphost.somedomain 25) np. w celu debuggowania (albo imponowania virginibus facilibus et formosis ;-) ). W systemach Linux kleint i serwer telnet mogą nie być instalowane domyślnie.
File Transfer Protocol (FTP) Protokół FTP standaryzowany jest przez RFC 959 (1985 rok). FTP wykorzystuje zazwyczaj porty TCP: 20 i 21. Sesje FTP nawiązywane są poprzez port 21, natomiast do transferu danych wykorzystywane są osobne połączenia. W trybie active połączenia do transferu danych inicjowane są przez serwer (port 20), zaś w trybie passive przez klienta. Adres TCP do transferu danych przekazywane są w ramach sesji kontrolnej (active: polecenie PORT, passive: odpowiedź na polecenie PASV).
File Transfer Protocol (FTP) cd. Wybrane problemy związane z FTP: W trakcie transferu danych sesja FTP (połączenie z portem 21) jest w stanie idle. W przypadku transferu dużych plików może zostać time-outowana np. na firewallu. Tryb active powoduje problemy na routerach, w szczególności z usługą NAT. Sesje FTP są nieszyfrowane, a uwierzytelnienie jest co najwyżej jednostronne poprzez nazwę użytkownika i hasło. FTP nie umożliwia weryfikowania integralności transferowanych plików (np. poprzez sprawdzenie sumy kontrolnej lub skrótu).
File Transfer Protocol (FTP) bezpieczeństwo Protokół FTP w trybie innym niż anonymous jest wysoce niebezpiecznym (podatnym na niemal wszystkie ataki) protokołem. Dostępne są dwie alternatywne wersje bezpiecznej usługi FTP: SFTP i FTPS. SFTP (secure FTP) to FTP poprzez SSH protokół opracowany przez IETF SECSH Working Group, zazwyczaj implementowany jako podsystem SSH. SFTP obecnie nie jest opisane w formie RFC. FTPS (RFC 4217) to wersja FTP wykorzystująca jako protokół niższej warstwy protokół SSL/TLS (analogicznie jak HTTP/SSL, SMTP/SSL, i in.)
File Transfer Protocol (FTP) wybrane polecenia Polecenia kontroli dostępu, m.in.: USER, PASS, CWD (cd), REIN (reinitialize), QUIT Polecenia kontroli transferu, m.in.: PORT, PASV (passive), PORT, TYPE Polecenia usługi FTP: RETR, STOR, APPE, DELE, MKD (mkdir), RMD, PWD, NLST (ls) Uwaga: Nie należy mylić poleceń protokołu FTP z poleceniami programu klienckiego FTP!
Trivial File Transfer Protocol (TFTP) Protokół TFTP standaryzowany jest przez RFC 1350, korzysta z protokołu transportowego UDP i portu 69. Protokół TFTP: nie wspiera uwierzytelnienia ani szyfrowania, nie pozwala na przeglądanie zawartości katalogów, umożliwia transfer plików nie większych niż 32 MB. TFTP przewiduje tylko pięć typów pakietów: pakiety PRQ (żądanie odczytu) i WRQ (żądanie zapisu) zawierające nazwę pliku i tryb transferu (ASCII, binarnie), pakiety DATA zawierające dwubajtowy numer bloku i 0 511 (ostatni fragment) lub 512 (są następne fragmenty) bajtów danych (tzw. blok), pakiety ACK zawierające numer bloku każdy pakiet DATA (każdy blok) jest indywidualnie potwierdzany, pakiety ERROR zawierające dwubajtowy kod błędu Protokół TFTP wykorzystywany jest np. do pobierania obrazu systemu operacyjnego.
HyperText Transfer Protocol (HTTP) Protokół HTTP rozwijany jest wspólnie przez IEFT i World Wide Web Consortium (http://www.w3.org). Wykorzystuje protokół TCP, domyślnie port 80 (HTTPS, czyli HTTP/SSL 443). HTTP funkcjonuje na zasadzie wymiany żądań (request) i odpowiedzi (response), natomiast jest protokołem stateless nie ma sesji w pełnym znaczeniu tego słowa (pewne zachowania właściwe dla sesji realizowane są poprzez cookies). Najnowsza wersja HTTP/1.1 opisana jest w dokumencie RFC 2616. W wersji tej wprowadzony został mechanizm tzw. persistent connections (kody odpowiedzi 100 i 101, zob. następny slajd) umożliwiający kontynuowanie zapytań.
Persistent Connections
HyperText Transfer Protocol (HTTP) cd. Żądania HTTP, to: GET i HEAD (jedyne wymagane), POST, PUT i DELETE (opcjonalnie) powinny być sygnalizowane użytkownikowi (np. naciśnięcie przycisku), TRACE, OPTIONS (sprawdzanie obsługiwanych żądań) i CONNECT. Odpowiedzi HTTP zawierają standardowo kod i opis np. 404 Not Found (A imię jego czterdzieści i cztery).
Uniform Resource Locator (URL) URL to format stworzony w 1991 roku dla potrzeb łącz (hyperlinks) sieci World Wide Web. W 1994 roku format URL został uogólniony do formatu URI (Uniform Resource Identifier). Najbardziej aktualny dokument IETF opisujący URI to RFC 3986 (2005 rok). URL identyfikuje zasób i jego położenie. Ogólna postać URL jest następująca: scheme://authority/path?query#fragment, gdzie: scheme przeważnie określa protokół dostępu (http, ftp, ldap), authority to nazwa lub adres IP, opcjonalnie także numer portu, nazwa użytkownika i hasło: (user:password@address:port), path to ścieżka dostępu do zasobu, której poszczególne elementy oddzielone są znakiem /, query wyraża dynamiczne parametry programu, zapytania do bazy danych, etc., fragment identyfikuje fragment zasobu.
Uniform Resource Identifier (URI) URL identyfikuje zasób i położenie, natomiast URN (Uniform Resource Name) jednoznacznie wskazuje nazwę zasobu w pewnej przestrzeni nazw niezależną od fizycznej lokalizacji, np. urn:ietf:rfc:3986. URI jest uogólnionym formatem opisującym URL, URN a także tzw. URI References (odwołania względne).
Simple Mail Transfer Protocol (SMTP) SMTP (RFC 2821, który zastąpił pierwotny RFC 821) to prosty, tekstowy protokół przekazywania poczty. SMTP przeważnie wykorzystuje połączenia TCP, lecz zgodnie z RFC 2821 jest niezależny od rozwiązań warstwy transportowej. Dokument RFC 2821 (niektóre źródła wciąż podają odwołanie do pierwotnego dokumentu RFC 1869) opisuje także tzw. ESMTP (Extended SMTP) ogólne ramy dla rozszerzeń protokołu SMTP. Do rozszerzeń takich należą m.in: 8BITMIME (RFC 1652) pozwalające na transfer plików binarnych, SMTP-AUTH (RFC 2554) umożliwiające uwierzytelnienie nadawcy, STARTTLS.
Simple Mail Transfer Protocol (SMTP) porty Porty SMTP: 25 SMTP, 465 SMTP/SSL (w przeciwieństwie do STARTTLS, cała sesja jest tunelowana wewnątrz SSL), 587 submission port, zalecany do wysyłania poczty (odbiór przesyłki dla obcego MTA zazwyczaj wymaga uwierzytelnienia nadawcy, por. relaying). Większość serwerów akceptuje połączenia klienckie na wszystkich trzech portach.
Simple Mail Transfer Protocol (SMTP) polecenia Zgodnie z RFC 821 klient rozpoczynał sesję poleceniem HELO. W protokole rozszerzonym (ESMTP, RFC 2821) polecenie HELO zastąpiono poleceniem EHLO, które wykorzystywane jest do identyfikowania obsługiwanych rozszerzeń (serwer w odpowiedzi podaje listę dostępnych rozszerzeń). Wymaganym argumentem polecenia EHLO jest FQDN klienta. Podstawowe pozostałe polecenia SMTP, to: MAIL FROM: RCPT TO: DATA (kończy się linią zawierającą tylko znak kropki)
Adresy nadawcy i odbiorcy Para adresów: MAIL FROM: i RCPT TO: określana jest mianem koperty. Przesyłka jest dostarczana w oparciu o dane z koperty. Nagłówek maila (będący integralną częścią treści maila (DATA) może zawierać pola from: i to:. Dane adresowe z koperty i z nagłówka mogą być różne (nie jest to błąd ani nieprawidłowość). Większość programów klienckich wyświetla nadawcę i adresata w oparciu o dane z nagłówka.
SMTP relaying Protokół SMTP dopuszcza tzw. relaying, tj. wykorzystywanie pośrednich serwerów SMTP (tj. występujących wobec serwera docelowego w charakterze klientów SMTP). W przypadku, gdy dostarczenie poczty jest niemożliwe, serwer SMTP, który podjął się przekazywania musi przesłać wiadomość zwrotną powiadamiającą o niedoręczeniu (mail undeliverable). Serwer SMTP nie powinien być skonfigurowany jako open relay, tj. powinien dysponować regułami określającymi zasady przyjmowania przesyłek, tak, by nie mógł być wykorzystywany do rozsyłania spamu. W przeciwnym razie serwer może zająć zaszczytne miejsce np. na listach http://www.sorbs.net (dawniej: http://www.ordb.org).
Wybrane metody ochrony przed spamem Listy RBL/DNSBL, np. cbl.abuseat.org, bl.spamcop.net, sbl.spamhaus.org. Kontrola sesji ESMTP, np.: EHLO: brak FQDN, nieistniejący FQDN lub fałszywy FQDN (rzadki przypadek), tzw. unauthorized pipelining, Zasady przekazywania (relaying policies). Sieci wymiany sum kontrolnych, np. dcc lub vipul s razor. Analiza treści.
Post Office Protocol (POP3) POP3 (RFC 1939) jest protokołem pozwalającym na pobieranie poczty ze skrzynki do lokalnego komputera. Wykorzystuje protokół TCP i port 110 (POP3/SSL 995). POP3 jest bardzo prostym protokołem (zob. RFC 1939), bazującym na mechanizmie kolejki i nie umożliwiającym przeglądania poczty do pobrania i transferu wybranych maili lub selekcji załączników. W razie wyboru opcji pozostawiania poczty na serwerze, do identyfikacji nie pobranych przesyłek wykorzystywany jest tzw. numer UIDL (Unique IDentification Listing).
Internet Message (Mail) Access Protocol (IMAP4) Protokół IMAP4 (RFC 3501) jest znacznie bardziej zaawansowanym protokołem niż POP3. Wykorzystuje połączenia TCP i porty 143 i 993 (SSL). Główne zalety: zarządzanie skrzynką po stronie serwera, możliwość zarządzania folderami pocztowymi (w skrzynce), dwustronna synchronizacja wszystkich folderów, selektywne pobieranie, przeszukiwanie poczty (po stronie serwera),... Usługi webmail, np. roundcube, squirrelmail etc. realizowane są w oparciu o IMAP4.