Protokoły sieci teleinformatycznych - Sprawozdanie_lab3_v.1.pdf

Marcin Braniewski Grupa: E7T1S1 Data wykonania: 19.03.2010 r. Data oddania: 17.07.2010 r. Laboratorium Protokoły sieci teleinformatycznych Cwiczenie #3: Analiza dzia ania wybranych protoko ów warstwy aplikacji Prowadzący ćw: mjr dr inż. Jarosław Krygier / kpt. mgr inż Krzysztof Maślanka

Nie ma jeszcze wyników poprzedniego sprawozdania (Laboratorium 2), ale z powodu braku zwrotu sprawozdania nr. 1 wnioskuję, że pomiary wykonane na własną ręke w domowym zaciszu nie są powodem zwrotów. Dlatego też pomiary do poniższego sprawozdania po raz trzeci postanowiłem wykonać na spokojnie w domu. Zdaję sobie sprawę z tego, że ocena poprawności wykonania takiego sprawozdania może być trudniejsza ze względu na różnice w konfiguracji sieci. Aby ułatwić Panu sprawę poniżej wstawię skromny opis urządzeń oraz przydzielone im numery IP. Serwer: 192.168.1.7 Klient: 192.168.1.2 Router: 192.168.1.1 – nie powinien brać większego udziału 2.3.1 Konfiguracja stacji roboczej do pracy w sieci Poniżej, standardowo jak w każdym innym sprawozdaniu screen obrazujący konfigurcję sieci oraz stacji na której przeprowadzone były pomiary. Podobnie jak w poprzednich sprawozdaniach nie będe sie skupial na konfiguracji sieci, instalacji odpowiednich pakietów oraz edycji ich plików konfiguracyjnych tylko przejdę do szczegółowej analizy wyłapanych pakietów. Pomiary będe wykonywał schdkowo, ze względu na to że analiza wszystkich wyłapanych pakietów podczas zestawiania połączenia, logowania, listowania oraz pobierania pliku byłaby bardzo trudna dla laika za jakiego sie uważam. Na początek w terminalu wpisałem instrukcję ftp – żadnych pakietów w wiresharku nie zauważyłem. Na pewno dzieję się tak z powodu braku jakiejkolwiek komunikacji zwnętrznej. Po wpisaniu ftp zwyczajnie wywołałem klienta do wysłuchiwania poszczególnych komend jakie będe wpisywał. Następną komendą było wywołanie serwera I próba nawiązania połączenia:

Do tej operacji niezbędny był już ruch w sieci, co potwierdza przechwycenie przez analizator siedmiu pakietów (6 TCP oraz 1 FTP) Pierwszy pakiet wysyła klient na 21 port serwera, który standardowo odpowiedzialny jest za wymianę poleceń I komend trybie pasywnym FTP. W pakiecie zawarta jest również informacja o porcie z jakiego komunikuje się z serwerm klient. Kolejnym pakietem jest odpowiedz serwera – czyli SYN ACK z portu 21 na port z którego wysłane zostało polecenie zestawienia połączenia. Wysłanie takiego pakietu oznacza, że dany port jest otwarty I za jego pomocą może nastąpić wymiana komunikatów. Następnie klient potwierdza odpowiedz komunikatem ACK, który informuje o tym że za pomocą tych portów następować będzie wymiana polceń (ze strony klienta) oraz odpowiedzi (ze strony serwera) Kolejnym pakietem jest ident z portu 113 – służy do zdalnej identyfikacji właściciela procesu, które nawiązało połączenie TCP. Zapytania na ten port są zazwyczaj wysyłane w odpowiedzi na połączenie z serwisem zewnętrznym. Odpowiedz klienta RST ACK oznacza, że port 113 na komputerze jest zamknięty. Kolejny pakiet w postaci protokołu FTP wysyła informacje o tym, że aplikacja jest gotowa do odczytu danych logowania do serwera FTP oraz odpowiedz w klienta. Ze względu na zbyt długi czas oczekiwania na login I hasło połączenie zostało zerwane, po wznowieniu połączenia komnikacja z klientem odbywać się będzie na innym porcie (52376) – potwierdza to fakt, że port klienta jest przypisywany tymczasowo. Tak wyglądał proces logowania z konsoli:

A tak przesyłane pakiety wyłapane przez analizator: Po analizie wszystkich pakietów TCP wnioskuję, iż są to zwykłe potwierdzenia w które nie warto się wgłębiać. Bardziej skupię się na pakietach protokołu FTP. Po wymianie informacji na temat portów oraz informacji o wymaganym uwierzytelnieniu klient wysyła z wcześniej wymienionego portu pakiet FTP z informacją o nazwie użytkownika: Jak widać po rozszyciu datagramu FTP, znalezc mozemy informację na temat komendy oraz argumentu jaki klient wpisał z klawiatury. (Koleny pakiet to potwierdzenie w postaci pakietu TCP, na których jak pisałem wcześniej nie będe sie skupiał)

Kolejny pakiet to prozba o hasło, oraz informacja o istnieniu danego usera w systemie. Hasło wpisane z klawiatury Oraz potwierdzenie udanego logowania Pytanie o system operacyjny jaki jest zainstalowany po stronie serwera: Oraz odpowiedz:

Pytanie o prawa dostępu oraz dodatkowe informacje: Odpowiedz na pytanie: Pytanie o ścieżkę do katalogu domowego użytkownika Oraz jak zawsze odpowiedz:

Kolejnym etapem było wpisanie w terminalu komendy 'ls': W wiresharku otrzymalem kolejną serię pakietów, których analiza wydaje się być zbędna. Dlatego też postanowiłem opisać tylko dwa najbardziej istotne z punktu widzenia użytkownika. Wybrałem pakiet przesyłający dane oraz pakiet informujący o pomyślnym zakończeniu przesylania danych: Dalej przejdę do analizy pobrania pliku, który jak mogę się domyślać będzie przebiegał w bardzo podobny sposób. Jak można było się domyślać na screenie nie ma nic odkrywczego, pytania o rozmiar pliku, tryb przesyłania danych, potwierdzenie pobrania pliku itp. Moim

zdaniem nie warto się wgłębiać w analize tych danych. Na końcu po wpisaniu polecenia 'by' wysyłany jest komunikat do klienta 'Goodby' oraz zrywanie połączenia. Tak wygląda proces podczas przeglądania serwera za pomocą przeglądarki: Zasadniczą różnicą jaką zauważyłem podczas przechwytywania pakietów było wysyłanie wszystkich danych jednocześnie włącznie z poleceniem list oraz natychmiastowe zakończenie połączenia po wyświetleniu wszystkich danych. Czyli przejście do kolejnych folderów odbywało się po rozpoczęciu kolejnych sesji za pomocą innych portów klienta. Kolejną analizę przeprowadziłem na protokole zdalnego logowania telnet, który zdaje się różnić od ssh tylko I wyłącznie brakiem kodowania przesyłanych informacji. Właśnie z tego powodu nie jest on powszechnie używany przy zdalnym logowaniu do serwera na ktorym mogą znajdować się poufne dane. Mimo wszystko uważam, że jest to naprawdę wspaniały I warty uwagi protokół bez którego życie nie byłoby takie przyjemne!!!

Poniżej, podobnie jak to było w przypadku FTP wstawiam screen z logowania za pomocą konsoli do zdalnej maszyny: No I jak zwykle pełno pakietów do analizy: Pierwsze pakiety TCP – proces odbiega tak samo jak w przypadku FTP – czyli wymiana komunikatów na temat portów za pomocą których będą komunikować sęi obie maszyny. Tym razem telnet pracuje na porcie 23, nie na 21 tak jak to było w przypadku FTP. Też jest to standardowy port dla tego protokołu, z tego też względu właśnie tam poszedł pierwszy pakiet. Kolejne pakiety TELNET to zwykła negocjacja parametrów czyli wymiana informacji na temat rządania echa, konieczności logowania użytkownika, typu terminala itp. Poniżej wstawiam screen z parametrem rządania echa: Następnie zostałem poproszony o login I hasło:

Zauważyłem, że wszystkie wstukane w klawiaturę klawisze były wysyłane za pomocą oddzielnych pakietów a następnie potwierdzane pakietem TCP od strony serwera. Po wpisaniu komendy Ls zauważyłem, że literki wstukiwane w klawiature były wysyłane najpierw jednym pakietem telnet od od klienta do serwera a następnie odwrotnie. Zdaje się, że na tym właśnie polega echo lokalne. No I jak zwykle potwierdzenie serwera pakietem TCP. Dane do wyświetlenia zostały wysłane jednym pakietem tylko do klienta. W przypadku polecenia PWD wszystko odbywało się na tej samej zasadzie. Zakończenie połączenia po wpisaniu komendy exit to podobnie jak w przypadku FTP wysłanie pakietów FIN ACK oraz ACK zarówno z jednej jak I drugiej strony.

Dla porównania wstawiam dane jakie wyłapałem analizując protokół SSH: Jak widać na screenie dane przesyłane przez SSH są kodowane, więc cieżko cokolwiek z nich wyczytać: Poczta przychodząca realizowana za pomocą protokolu SSL, imaps na porcie 993 zgodnie z ustawieniem programu do odbioru poczty. Setki pakietów danych oraz takie same ilości pakietów potwierdzeń: