Piotr Zwierzykowski, mgr inż. Marta Stępniewska PROGRAMOWY ANALIZATOR LOKALNEJ SIECI KOMPUTEROWEJSesja: Kształcenie w dziedzinie elektroniki i telekomunikacji.Politechnika Poznańska

Pełen tekst

(1)www.pwt.et.put.poznan.pl Piotr Zwierzykowski, Marta Stępniewska Politechnika Poznańska Instytut Elektroniki i Telekomunikacji ul. Piotrowo 3A, 60-965 Poznań {pzwierz, mstep}@et.put.poznan.pl. 2005. Poznańskie Warsztaty Telekomunikacyjne Poznań 8 - 9 grudnia 2005. PROGRAMOWY ANALIZATOR LOKALNEJ SIECI KOMPUTEROWEJ Streszczenie: W artykule przedstawiono programowy analizator protokołów stworzony dla potrzeb laboratorium sieci teleinformatycznych Zakładu Sieci Transportu Informacji Instytutu Elektroniki i Telekomunikacji Politechniki Poznańskiej. Prezentowany analizator jest unikalnym połączeniem funkcji niedostępnych w żadnym spośród znanych autorom analizatorów.. 1. WPROWADZENIE Analizatory protokołów sieci pakietowej są bardzo pomocne w zarządzaniu siecią komputerową. W zależności od wielkości sieci oraz jej prędkości stosowane są dwa rodzaje analizatorów: • sprzętowe, • programowe. Analizatory sprzętowe są wyspecjalizowanymi urządzeniami do analizy ruchu w dużych sieciach o wysokich przepływnościach. Tańszym rozwiązaniem jest analizator programowy, zainstalowany na dowolnym komputerze osobistym. Analizator programowy może być wykorzystany do monitorowania i zarządzania siecią komputerową oraz do zapoznania się budową i z zasadami działania protokołów. Analizator pozwala na przechwytywanie ramek i ich analizę, której efektem jest rozpoznawanie nagłówków protokołów wewnątrz pakietu. Z tego względu program taki wydaje się być użytecznym narzędziem, które pozwala w sposób przejrzysty przedstawiać wymianę wiadomości w sieci komputerowej. Niestety nie wszystkie programy tego typu spełniają wymagania określone dla analizatora laboratoryjnego. 2. WYMAGANIA STAWIANE PRZED PROGRAMEM LABORATORYJNYM Najważniejszą cechą programu laboratoryjnego jest dokładna analiza przechwytywanych ramek i poprawne dekodowanie protokołów zawartych w pakiecie. Ponadto program laboratoryjny powinien dekodować protokoły używane na zajęciach laboratoryjnych. Wszystkie analizowane programy, spełniały to kryterium. Program laboratoryjny powinien ponadto umożliwiać obserwację wymiany pakietów w formie graficznej. Niektóre programy (np. Observer1 , Netasyst Ne-. twork Analyzer2 czy OptiView Protocol Expert3 ) wyświetlają wymianę pakietów w formie graficznej. Graficzne przedstawienie wymiany komunikatów ułatwia zaobserwowanie zależności między pakietami. Pomocne w tym może być także zaznaczanie zależności między pakietami na liście za pomocą kolorów. Zwrócono także uwagę na możliwość rozbudowy programu, czyli dodawanie do niego nowych funkcji, a także możliwość rozszerzenia biblioteki dekodowanych protokołów. Programy komercyjne nie udostępniają swoich źródeł, toteż ich funkcjonalność nie może być zmodyfikowana zmieniona przez użytkownika programu. Wśród programów komercyjnych na wyróżnienie zasługuje Anasil4 , który udostępnia interesując funkcję "Programowalnego dekodera ramek". Można zdefiniować postać protokołu w języku PDL i wywołać wewnętrzny kompilator, w celu sprawdzenia poprawności opisu, oraz załadowania nowego protokołu do biblioteki. Dzięki temu można dodawać nowe protokoły w stosunkowo łatwy sposób. Dostępne programy rozwijane na zasadzie OpenSource5 jak Ethereal6 czy Ettercap7 można rozwijać, jednak rozbudowa tak dużych narzędzi jest trudna i dostosowanie funkcjonalności programu do potrzeb laboratorium mogłoby okazać się zbyt pracochłonne. Program używany na zajęciach laboratoryjnych powinien być jednocześnie tak prosty w obsłudze jak to tylko możliwe. Dobrym przykładem funkcjonalnego i przyjaznego użytkownikowi programu jest Anasil oraz Ethereal. Większość funkcji dostępna jest za pomocą jedynie kilku wskazań myszy, natomiast te najczęściej używane, są dostępne bezpośrednio. Niestety żaden spośród programów nie spełnia wszystkich wymagań stawianych przed programem laboratoryjnym. Z tego powodu w Zakładzie Sieci Transportu Informacji Instytutu Elektroniki i Telekomunikacji Politechniki Poznańskiej podjęto pracę nad stworzeniem takiego narzędzia [1].. 2 http://www.mcafee.com/ 3 http://www.flukenetworks.com 4 http://www.anasil.net 5 http://www.opensource.org 6 http://www.ethereal.com. 1 http://www.networkinstruments.com. PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005. 7 http://ettercap.sourceforge.net. 1/5.

(2) www.pwt.et.put.poznan.pl. Rys. 1. Okno programu laboratoryjnego z zakładką powitalną 3. FUNKCJONALNOŚĆ PROGRAMU LABORATORYJNEGO Zrealizowany program laboratoryjny umożliwia przechwytywanie i dekodowanie ramek w sieci Ethernet. Pobrane pakiety są dekodowane. Po odpowiedniej komendzie użytkownika pakiety są analizowane pod kątem adresów lub protokołów i wyświetlane są zależność między nimi w formie graficznej. Ponadto program oferuje możliwość łączenia się z urządzeniami sieciowymi (np. routerami) i ich konfiguracji za pomocą interfejsu RS-232. Po uruchomieniu programu otwierane jest okno z zakładką powitalną, która umożliwia wybór źródła pobierania pakietów - sieć lub plik. W przypadku pobierania pakietów z pliku możliwe jest utworzenie prostego filtru przechwytywanych pakietów. Oferowany filtr jest niezwykle prosty i pozwala na podstawowe ograniczenie rodzaju przechwytywanych pakietów ze względu na protokół, adres oraz port. Wygląd zakładki powitalnej oraz jej podstawowe funkcje przedstawiono na rysunku 1. Po wybraniu źródła pakietów, program otwiera zakładkę na której znajdują się podstawowe informacje dotyczące przechwyconych pakietów. Przykład. Rys. 2. Okno programu laboratoryjnego z listą pakietów. PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005. Rys. 3. Okno programu laboratoryjnego z zakładką prezentującą przykładową wymianę pakietów między hostami okna dekodowania zawartości pakietów wraz ze zdekodowanym pakietem pokazuje rysunek 2. Wszystkie pakiety prezentowane są w liście, podzielonej na pięć kolumn. Pierwsza kolumna zawiera numer porządkowy nadawany w momencie przechwycenia pakietu. Następne kolumny zawierają adres źródłowy i docelowy warstwy drugiej bądź trzeciej (modelu OSI), w zależności od tego czy w ramce znajduje się nagłówek protokołu IP. Poniżej listy pakietów znajdują się dwa pola wypełniane po dwukrotnym wskazaniu myszą na konkretnym pakiecie. Inną przydatną funkcją analizatora jest możliwość obserwacji wymiany pakietów w formie graficznej. Prezentacja ta może odbywać się na dwa sposoby. Pierwszym z nich jest przedstawienie kierunków wymiany pakietów w zależności od hosta. Wybranie drugiej opcji wymaga uściślenia filtrowania pakietów znajdujących się na liście tj. należy wybrać warstwę (2 lub 3 w modelu OSI). Rysunek 3 przedstawia obraz przykładowej wymiany pakietów w warstwie trzeciej. Na wykresie punkt odpowiada określonemu adresowi hosta, natomiast strzałka określa kierunek wymiany pakietów. Często poza globalnym obrazem komunikacji można zaobserwować wymianę pakietów w ramach jednego protokołu pomiędzy dwoma hostami. Program laboratoryjny oferuje możliwość wyświetlenia uproszczonego wykresu MSC8 , na którym oznaczane są dwa hosty wymieniające między sobą komunikaty, zaś same pakiety są oznaczane jako strzałki, nad którymi znajduje się krótka jego charakterystyka. Wykres zawierający przykładową wymianę pakietów zamieszczono na rysunku 4. Program laboratoryjny umożliwia zapisanie przechwyconych pakietów w postaci pliku tekstowego. Pliki zapisane przez analizator mogą być otwierane przez program w momencie wyboru źródła pakietów.. 8 MSC (Message Sequence Chart) - język zarówno graficzny jaki i tekstowy służący do opisu współdziałania elementów systemu (http://www.sdl-forum.org/MSC/index.htm).. 2/5.

(3) www.pwt.et.put.poznan.pl. MAC. IP. TCP. ARP. UDP. Rys. 6. Struktura drzewa protokołów Rys. 4. Okno programu laboratoryjnego z przykładowym wykresem MSC W programie oprócz funkcji analizatora zintegrowano również mechanizm wirtualnego terminala. Wirtualny terminal umożliwia komunikację z urządzeniami sieciowymi takimi jak routery lub przełączniki za pomocą interfejsu szeregowego RS-232. Terminal dostępny jest w programie po wybraniu odpowiedniej zakładki. Dzięki tej zakładce w analizatorze laboratoryjnym można zarówno skonfigurować urządzenie sieciowe, jak i obserwować efekt tych zmian poprzez analizę przechwyconych pakietów. Przykład konfiguracji routera za pomocą wirtualnego terminala zaimplementowanego w programie laboratoryjnym przedstawiono na rysunku 5. 4. IMPLEMENTACJA ANALIZATORA O wyglądzie programu zadecydowało w dużej mierze zastosowanie zakładek oferowanych przez wszystkie biblioteki udostępniające funkcje GUI (Graphical User Interface). Analizator został zrealizowany w środowisku Microsoft Visual Studio .NET. Program zrealizowano przy użyciu bibliotek MFC (Microsoft Foundation Library). Funkcje dekodujące pakiety zawarto w bibliotekach DLL (Dynamic. Link Library) połączonych z programem za pomocą struktury nazwanej drzewem protokołów. Przykładową strukturę drzewa protokołów przedstawiono na rysunku 6. Każdy liść drzewa połączony jest z jedną biblioteką i w programie jest utożsamiany z protokołem dekodowanym przez tą bibliotekę. Struktura drzewa jest budowana przy starcie programu na podstawie informacji zawartych w pliku konfiguracji drzewa. Przedstawiony na rysunku 6 schemat odpowiada następującemu wpisowi do pliku konfiguracji drzewa: proto-mac.dll { proto-arp { } proto-ip.dll { proto-tcp.dll { } proto-udp.dll { } } }. Za pomocą wpisów budowana jest hierarchia dekodowania pakietów oraz określany jest możliwy do wystąpienia porządek nagłówków w pakiecie. Warto podkreślić, że dekodowanie pakietu zgodnie z budową drzewa zmniejsza ilość niezbędnych do wykonania operacji. Przykładowy proces dekodowania pakietu przedstawiono na rysunku 7. Dekodowanie pakietu oznacza sprawdzanie zgodności bitów pakietu z formatem nagłówka danego protokołu, jeśli protokół zostanie rozpoznany i w drzewie za nim nie występuje MAC. MAC. IP. IP. Poziom 1. Poziom 2. TCP. UDP. UDP. Poziom 3 TFTP Poziom 4. HTTP. DHCP. RIP. TFTP. D A N E. Rys. 5. Okno programu laboratoryjnego z zakładką wirtualnego terminala. PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005. Rys. 7. Proces dekodowania protokołu. 3/5.

(4) www.pwt.et.put.poznan.pl już żaden liść lub też żaden z protokołów nie pasuje do analizowanej sekwencji bitów, następuje zakończenie przetwarzania. Ponadto drzewo protokołów pozwala określić, jakie protokoły mogą wystąpić za określonym nagłówkiem, na przykład za nagłówkiem UDP może wystąpić TFTP, a nie HTTP czy FTP. Umieszczenie funkcji dekodujących pakiety w bibliotekach DLL ma dużą zaletę ze względu na znaczną separację kodu dekodującego pakiet od kodu związanego z wyświetlaniem jego zawartości. Dzięki temu biblioteki mogą być dołączane i odłączane od programu za pomocą zmian jedynie w pliku konfiguracji drzewa, bez konieczności kompilacji kodu. Takie rozwiązanie umożliwia również rozwój bibliotek w stosunkowo prosty sposób – nie jest wymagana znajomości budowy programu, a jedynie format dostarczanej przez bibliotekę informacji. Równie proste jest dodawanie bibliotek związanych z tworzonymi przez użytkownika protokołami. Funkcje rysujące wykresy przebiegu komunikacji pomiędzy hostami zrealizowano z pomocą bibliotek OpenGL. Programowanie z użyciem tych bibliotek polega na opisaniu kroków koniecznych do osiągnięcia żądanego wyglądu sceny. Dzięki takiemu sposobowi realizacji OpenGL oferuje znacznie więcej możliwości niż standardowe narzędzia do rysowania dostępne w bibliotekach MFC. OpenGL zapewnia: możliwość rysowania w dwóch lub trzech wymiarach za pomocą jednej biblioteki, łatwość przekształceń takich jak obroty i skalowania, możliwość operowania oświetleniem obiektu oraz niezależność biblioteki od systemu operacyjnego. Dzięki OpenGL można zrealizować powiązanie pomiędzy aplikacją a wyświetlanym rysunkiem – można zareagować na wskazanie myszą konkretnego obiektu. Właśnie ta cecha jest szczególnie użyteczne w programie laboratoryjnym, ponieważ umożliwia łatwe powiązanie logiki protokołu z rodzajami przesyłanych wiadomości. 5. PRZYKŁADOWE ZASTOSOWANIA PROGRAMU Możliwości wykorzystania programu można zaobserwować na przykładzie prostego ćwiczenia laboratoryjnego jakim jest podstawowa konfiguracja routera i zapisanie wyników pracy (pliku konfiguracyjnego) na serwerze TFTP. Zawarte w przykładzie polecenia konfiguracji routera dotyczą urządzeń Cisco opartych na systemie operacyjnym IOS 11.x. Routery Cisco dają możliwość archiwizacji pliku konfiguracyjnego oraz obrazu systemu operacyjnego za pomocą protokołu TFTP. Posługiwanie się tym mechanizmem ma sens jeśli serwer TFTP znajduje się blisko routera i na drodze między nimi nie ma niepożądanych urządzeń mogących podsłuchać transmisję, ponieważ protokół TFTP nie zapewnia kontroli przepływu danych i nie chroni transmisji przed podsłuchem. Zaletą tego protokołu jest prostota i wykorzystanie niewielkiej części pasma do transmisji danych. Przed przystąpieniem do archiwizacji należy przeprowadzić podstawową konfigurację routera.. PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005. Rys. 8. Okno programu laboratoryjnego zawierające przechwycone pakiety TFTP Można to zrobić korzystając z opcji wirtualnego terminala zakładając, że komputer połączony jest z routerem za pomocą interfejsu szeregowego. Jednym z najprostszych poleceń konfiguracji jest nadanie routerowi nazwy. Można tego dokonać przez wydanie polecenia hostname nazwa_routera w trybie uprzywilejowanym. Nazwa routera wyświetlana jest przed znakiem zachęty w trakcie konfiguracji urządzenia. Zmiana ta zostanie odnotowana również w pliku konfiguracyjnym. Zakładając, że rouer jest prawidłowo podłączony do sieci można przystąpić do kopiowania pliku konfiguracyjnego na serwer TFTP. Zaleca się umieszczenie aplikacji serwera TFTP na komputerze lokalnym na którym konfigurowany jest router. Dzięki temu będzie możliwe przechwycenie pakietów TFTP wysyłanych przez router. Po zastosowaniu komendy copy run tftp router rozpocznie procedurę wysyłania pliku konfiguracyjnego od wysłania wiadomości WRITE REQUEST. Jeśli serwer nie odpowie komunikatem błędu, router rozpocznie nadawanie pliku w paczkach, zatwierdzanych każdorazowo wiadomością ACK [2]. Rysunek 8 przedstawia przechwycone pakiety zawierające plik konfiguracyjny routera.. Rys. 9. Okno programu laboratoryjnego zawierające uproszczony wykres MSC. 4/5.

(5) www.pwt.et.put.poznan.pl Rysunek 9 przedstawia uproszczony wykres MSC wygenerowany przez program laboratoryjny na podstawie przechwyconych pakietów. 6. PODSUMOWANIE Zaproponowany analizator spełnia założone wymagania. Program umożliwia przechwytywanie pakietów w czasie rzeczywistym i ich analizę ze względu na protokół oraz kierunek przepływu komunikatu. Rozszerzenie programu o wirtualny terminal czyni z analizatora narzędzie umożliwiające zarówno konfigurację urządzeń sieciowych, jak i obserwowanie konsekwencji tych zmian, za pomocą jednego programu. W przyszłości możliwa jest stosunkowo łatwa rozbudowa programu. Przede wszystkim można będzie rozszerzyć liczbę obsługiwanych protokołów, a także rozwinąć funkcjonalności związane z wyświetlaniem przebiegu komunikacji - np. dodanie interaktywności do prezentowanych wykresów. Intencją autorów jest utworzenie projektu, którego celem byłoby rozwijanie programu na zasadzie OpenSource przez udostępnienie kodów źródłowych oraz do dokumentacji technicznej programu w specjalnie w tym celu stworzonym serwisie www (http://analizator.et.put.poznan.pl). Uczynienie z programu laboratoryjnego projektu OpenSource daje dużą szansę na rozwój programu i uczynienie go szeroko dostępnym programem edukacyjnym SPIS LITERATURY [1]. [2]. M. Stępniewska: Programowy analizator lokalnej sieci komputerowej, praca magisterska, Zakład Sieci Transportu Informacji Instytutu Elektroniki i Telekomunikacji Politechniki Poznańskiej, 23.09.2005. K. Solins: The TFTP Protocol (Revision 2), MIT, July 1992.. PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005. 5/5.

(6)