Protokoły warstwy aplikacji

Transkrypt

1 UNIWERSYTET KAZIMIERZA WIELKIEGO Wydział Matematyki Fizyki i Techniki Zakład Teleinformatyki Laboratorium Sieci Komputerowych 1. Cel ćwiczenia Celem ćwiczenia jest zapoznanie z podstawowymi protokołami warstwy aplikacji: telnet, ssh, DNS, POP3, FTP, http. Analiza wiadomości generowanych podczas konwersacji klient-serwer posłuży do oceny bezpieczeństwa wymienionych protokołów. 2. Podstawy teoretyczne Z punktu widzenia użytkownika, sieć komputerowa umożliwia prawidłowe funkcjonowanie aplikacji sieciowych. Każda z aplikacji korzysta z protokołu wymiany danych z inną aplikacją sieciową, zlokalizowaną po stronie zdalnej. Protokół określa sposób wymiany informacji między procesami w odległych hostach, w szczególności: składnie wiadomości, scenariusze wymiany wiadomości, sposób kodowania, szyfrowania (jeśli wymagane). Jeśli aplikacja nie korzysta z protokołu transportowego TCP, konieczna jest także realizacja sterowania przepływem oraz zapewnienie niezawodności transmisji. Obsługa protokołów warstwy aplikacji zlokalizowana jest w aplikacjach hostów czyli w terminalach dołączonych do sieci. Dane protokołów aplikacji dzielone są na segmenty przez protokoły transportowe, czyli TCP lub UDP. Segmenty kapsułkowane są w pakiety IP, te natomiast kapsułkowane są w ramki Ethernet i przesyłane przez medium w postaci szeregowej do urządzenia sieciowego, np. przełącznika. Protokoły aplikacji można podzielić na dwie grupy: - protokoły standardowe, dobrze znane i zestandaryzowane w RFC, - protokoły autorskie, zwykle implementowane przez jednego producenta, który nie publikuje specyfikacji protokołu. ćwiczenie: 13 Protokoły warstwy aplikacji prowadzący: mgr inż. Piotr Żmudziński zmudzinski@ukw.edu.pl Do pierwszej z wymienionych grup należą: Telnet, FTP, POP3 itp., drugą grupę reprezentują protokoły wykorzystywane przez aplikacje np. Skype, GG itp Protokół FTP (File Transfer Protocol) Protokół FTP przeznaczony jest do transferu plików między hostami. FTP jest dość nietypowym protokołem, ponieważ używa dwóch dwukierunkowych połączeń TCP do poprawnej realizacji zadania. Połączenie sterujące (control) zawiązywane jest z serwerem ftp na porcie 21, natomiast połączenie do transmisji danych użytkownika (data) nawiązywane jest z portem 20. Istnieją dwa tryby pracy FTP: aktywny i pasywny. Tryb aktywny jest pierwotnym trybem pracy, jednak może powodować pewne niedogodności przy stosowaniu zapór sieciowych. Z tego powodu powstał tryb pasywny, obsługiwany najczęściej przez przeglądarki internetowe. Bydgoszcz 2011r Aktywny tryb FTP W trybie aktywnym klient losuje numer lokalnego, wolnego portu N (z puli tzw. portów wysokich, czyli powyżej 1024) i nawiązuję połączenie z portem 21 serwera P.Żmudziński, r., ver 3.0 1

2 (jeśli nie podano inaczej). Następnie klient otwiera lokalny port o numerze N+1 i oczekuje połączenia przychodzącego z portu 20 serwera FTP, Rys.1. Warstwa aplikacji Telnet SMTP POP3 SNMP TFTP FTP DNS Warstwa transportu Nr portu TCP UDP Rys. 1 Połączenie z serwerem FTP w trybie aktywny Warstwa sieci ID protokołu 6 IP 17 1 ICMP W przypadku stosowania firewall a po stronie klienta, należy zezwolić na nawiązywanie połączenia przez zdalny host z portu 20 na host lokalny, dowolny port Pasywny tryb FTP W odróżnieniu od poprzedniego, w trybie pasywnym oba połączenia są otwierane przez klienta. Pierwsze połączenie inicjowanie jest między N portem wysokim (zwanym także nieuprzywilejowanym) a portem 21 serwera. Następnie klient wysyła polecenie PORT do serwera, który otwiera port wysoki i przesyła jego numer X do klienta. W kolejnym kroku, klient nawiązuje połączenie między lokalnym portem N+1 i zdalnym portem Y. Warstwa łącza danych Warstwa dostępu Kod typu Adres fizyczny 0800H Sterownik karty sieciowej Karta Ethernetowa 0800H 0806H ARP Rys. 3 Protokoły w modelu ISO/OSI 2.2. Protokół telnet Protokół telnet przeznaczony jest do inicjowania zdalnej sesji terminalowej na serwerze. Usługa telnet jest jedną z najstarszych usług dostępnych w sieciach komputerowych, protokół telnet został opisany w RFC854 i RFC855. Serwery domyślnie nasłuchują na połączenie telnet na porcie 23 TCP. Ze względu na podatność na przejęcie sesji oraz sniffing, zalecane jest korzystanie z ssh. Rys. 2 Połączenie z serwerem FTP w trybie pasywnym 2.3. Protokół ssh SSH (Secure Shell Login) jest bezpiecznym protokołem terminalu zdalnego udostępniającym usługi szyfrowanego połączenia. Dobrze znanym portem przypisanym do usługi SSH jest 22 protokołu TCP. Dostępne są dwie wersje protokołu P.Żmudziński, r., ver 3.0 2

3 ssh1 i ssh2 oraz dwie rodziny protokołu: komercyjna wersja SSH oraz niekomercyjna OpenSSH. Dostępne są następujące algorytmy szyfrowania: DES, 3DES, BLOWFISH, IDEA, ARCFOUR, TWOFISH. Podstawowym algorytmem generowania asymetrycznych kluczy uwierzytelniających jest DSS lub RSA. OpenSSH korzysta jedynie z otwartych algorytmów, zaznaczonych w tekście kursywą. Popularnym klientem ssh pod Windows jest putty Protokół POP3 POP3 (Post Office Protocol ver.3) jest protokołem pocztowym pozwalającym na pobieranie poczty z serwera. Protokół w wersji 3, która nie jest zgodna wstecz, został zestandaryzowany w dokumentach RFC1939, RFC 1957 i nowszych Protokół DNS Protokół DNS zapewnia komunikację z serwerami DNS, które świadczą usługę zamieniania (rozwiązywania) nazw domenowych hostów na adres IP, niezbędny do rozpoczęcia komunikacji ze zdalnym hostem. Obecnie wykorzystywana wersja protokołu DNS została opublikowana w RFC 1034 i RFC 1035 oraz RFC Zapytania i odpowiedzi DNS są najczęściej kapsułkowane w protokole UDP. Każdy komunikat musi się zawrzeć w jednym pakiecie UDP (standardowo 512 oktetów), format komunikatu DNS został zdefiniowany w RFC Sekcja nagłówka występuje zawsze. W sekcji zapytania zawsze znajduje się jedno zapytanie zawierające nazwę domenową, żądany typ danych i klasę (IN). Sekcja odpowiedzi zawiera rekordy zasobów stanowiące odpowiedź na pytanie. Tab. 1 Format wiadomości protokołu DNS OPCODE [4 bity] określa rodzaj zapytania wysyłanego od klienta, jest przypisywany przez serwer do odpowiedzi. Wartości: 0 QUERY standardowe zapytanie, 1 IQUERY zapytanie zwrotne, 2 STATUS pytanie o stan serwera, 3-15 zarezerwowane do przyszłego użytku AA [1 bit] (Authoritative Answer) oznacza, że odpowiedź jest autorytatywna. TC [1 bit] (TrunCation) oznacza, że odpowiedź nie zmieściła się w jednym pakiecie UDP i została obcięta. RD [1 bit] (Recursion Desired) oznacza, że klient żąda rekurencji pole to jest kopiowane do odpowiedzi RA [1 bit] (Recursion Available) bit oznaczający, że serwer obsługuje zapytania rekurencyjne Z [3 bity] zarezerwowane do przyszłego wykorzystania. Pole powinno być wyzerowane. RCODE (Response CODE) kod odpowiedzi. Przyjmuje wartości: 0 brak błędu 1 błąd formatu serwer nie potrafił zinterpretować zapytania 2 błąd serwera wewnętrzny błąd serwera 3 błąd nazwy nazwa domenowa podana w zapytaniu nie istnieje 4 nie zaimplementowano serwer nie obsługuje typu otrzymanego zapytania 5 odrzucono serwer odmawia wykonania określonej operacji, np. transferu strefy 6-15 zarezerwowane do przyszłego użytku QDCOUNT [16 bitów] określa liczbę wpisów w sekcji zapytania ANCOUNT [16 bitów] określa liczbę rekordów zasobów w sekcji odpowiedzi NSCOUNT [16 bitów] określa liczbę rekordów serwera w sekcji zwierzchności ARCOUNT [16 bitów] określa liczbę rekordów zasobów w sekcji dodatkowej W sekcji zapytanie występuje zapytanie zawierające nazwę domenową, żądany typ danych oraz klasę. Serwer zwraca odpowiedź zawierającą rekord odpowiedzi na zadane pytanie. Rekordów tych może być więcej niż jeden. Jeśli odpowiedź odsyła klienta od innych serwerów DNS, są one wymienione w sekcji zwierzchności. Poniżej wyjaśnione zostaną znaczenia poszczególnych bitów nagłówka. ID [16 bitów] (IDentifier) identyfikator tworzony przez program wysyłający zapytanie; serwer przepisuje ten identyfikator do swojej odpowiedzi, dzięki czemu możliwe jest jednoznaczne powiązanie zapytania i odpowiedzi QR [1 bit] (Query or Response) określa, czy komunikat jest zapytaniem (0) czy odpowiedzią (1) 3. Zagadnienia do przestudiowania 1. Do czego służy i jak działa protokół SMTP? 2. Do czego służy i jak działa protokół IMAP? 3. Jak działa SSL? 4. Bibliografia [1] K. Krysiak, Sieci komputerowe Kompendium, wyd. II, Helion, Gliwice 2006 [2] Vademecum teleinformatyka I / II / III, Warszawa, IDG P.Żmudziński, r., ver 3.0 3

4 5. Przebieg ćwiczenia Ćwiczenie 13 realizowane jest na stanowisku C i D przy wykorzystaniu stacji PC10-13, PC14-17 z zainstalowanym analizatorem sieci WireShark. Aby wykorzystać koncentrator HUB1 lub HUB2, należy przekrosować porty komputerów za pomocą portów I-VIII na prawy stojak. Rys. 4 Sieć laboratoryjna 5.1. Analiza protokołu FTP 1. Połączyć sieć zgodnie ze schematem Rys4 2. Na PC10/11/12 rozpocząć przechwytywanie ramek. 3. Uruchomić TotalCommandera i skonfigurować połączenie do serwera FTP zlokalizowanego na serwer , login/hasło: st01/imsis Wybrać tryb aktywny odznaczony box użyj pasywnego trybu Nawiązać połączenie z serwerem FTP, przesłać niewielki plik, zerwać połączenie. 6. Przeanalizować połączenie między aplikacjami. Zwrócić uwagę na porty połączenia oraz kierunek inicjacji połączenia ( ). 7. Wybrać tryb pasywny zaznaczony box użyj trybu pasywnego Nawiązać połączenie z serwerem FTP, przesłać niewielki plik, zerwać połączenie. 9. Przeanalizować połączenie między aplikacjami. Zwrócić uwagę na porty połączenia oraz kierunek inicjacji połączenia ( ). 10. Przeanalizować procedurę logowania klienta do zdalnego serwera. Czy jest ona bezpieczna ( )? 5.2. Analiza protokołu telnet 1. Uruchomić WireShark na PC10/11/12 2. Zalogować się z linii komend za pomocą telnet z dowolnego hosta na serwer login/pass: st01/imsis Po zarejestrowaniu pakietów, odszukać pierwszy segment TCP połączenia a następnie wybrać Analiyze -> Follow TCP Stream 4. Przeanalizować ruch związany z logowaniem. Czy możliwe jest dzięki analizie ramek podejrzenie loginu i hasła? ( ) 5.3. Analiza protokołu ssh 1. Uruchomić WireShark na PC10/11/12 2. Zalogować się za pomocą aplikacji putty (skrót znajduje się na pulpicie) z dowolnego hosta na serwer Po zarejestrowaniu pakietów, odszukać pierwszy segment TCP połączenia a następnie wybrać z menu Analyze -> Follow TCP Stream 4. Przeanalizować ruch związany z logowaniem. Czy możliwe jest dzięki analizie ramek podejrzenie loginu i hasła? ( ) Analiza protokołu POP3 1. Skonfigurować na PC4 nowe konto w Outlook Express w następujący sposób: - serwer pop3: pop3.wp.pl, serwer poczty wychodzącej SMTP: smtp.wp.pl, numer portu: użytkownik: lab-sieci - hasło: tajne-haslo - serwer poczty wychodzącej wymaga uwierzytelnienia. 2. Uruchomić WireShark na PC10/11/12. Odebrać pocztę z wcześniej skonfigurowanego konta. 4. Przeanalizować format wiadomości protokołu POP3 wykorzystywanego do odbierania poczty. Czy można odszukać ciąg znaków będący loginem oraz hasłem do obserwowanego konta? Jakie dodatkowe informacje można uzyskać analizując zawartości ramek protokołu POP3? 5. Przygotować w OE dowolny list elektroniczny (format tekstowy) i wysłać ją na inne konto pocztowe za pomocą konta wcześniej skonfigurowanego. Czy protokoły pocztowe przesyłają wiadomości w sposób zaszyfrowany? ( ) 5.4. Analiza protokołów DNS 1. Na PC11 i PC12 rozpocząć przechwytywanie ramek. 2. Skasować DNS cache >ipconfig /flushdns 3. Połączyć się ze stroną za pomocą dowolnej przeglądarki 4. Przeanalizować informacje wymieniane między klientem z serwerem DNS zarejestrowane przez WireShark ( ) Analiza protokołu http 1. Uruchomić WireShark na PC10/11/12 2. Na PC5 otworzyć stronę 3. Po zarejestrowaniu pakietów, odszukać pierwszy segment TCP połączenia a następnie wybrać Analyze -> Follow TCP Stream 4. Spostrzeżenia zamieścić w sprawozdaniu ( ). 6. Sprawozdanie P.Żmudziński, r., ver 3.0 4

5 UNIWERSYTET KAZIMIERZA WIELKIEGO, WMFiT, ZT Laboratorium Sieci Komputerowych Sprawozdanie z wykonania ćwiczenia nr ćwiczenia: 13 grupa : zespół: data: ocena : Protokoły warstwy aplikacji Imię i Nazwisko członków zespołu (drukowanymi literami) Protokół FTP Dla połączeń FTP w obu trybach zanotować numery portów połączeń, zaznaczyć liniami symbolizującymi połączenia odpowiednie porty, na liniach zaznaczyć groty symbolizujące kierunek inicjowania połączenia. Przeanalizować ramki przesyłane przez klienta i serwer FTP. Czy login i hasło są szyfrowane? FTP szyfruje / nie szyfruje hasło i login (niepotrzebne skreślić) 6.2 Protokół telnet Czy protokół telnet jest bezpieczny? TAK / NIE Czy telnet wysyła login w jednym pakiecie? TAK / NIE 6.3 Protokół ssh Czy protokół ssh jest bezpieczny? TAK / NIE P.Żmudziński, r., ver 3.0 5

6 warstwa transportowa protokół porta nadawcy port odbiorcy 6.4 Protokół POP3 Czy protokół POP3 przesyła login i hasło do skrzynki pocztowej tekstem jawnym? TAK / NIE 6.5 Protokół DNS ZAPYTANIE warstwa sieci protokół adres nadawcy adres odbiorcy warstwa aplikacji pole wiadomości wartość pole wiadomości wartość ID (numer transakcji) QR RD OPCODE RA TC Z QDCOUNT ANCOUNT warstwa transportowa protokół port nadawcy port odbiorcy answer (domain) answer (type) answer (class) answer (addr.) warstwa aplikacji pole wiadomości wartość pole wiadomości wartość ID (numer transakcji) QR RD OPCODE RA TC Z QDCOUNT ANCOUNT query (domain) query (type) query (class) Czy protokół DNS jest odporny na ataki? TAK / NIE 6.6 Analiza protokołu http Czy protokół http jest protokołem bezpiecznym? TAK / NIE ODPOWIEDŹ warstwa sieci protokół adres nadawcy adres odbiorcy P.Żmudziński, r., ver 3.0 6