Monitorowanie sieci TCP/IP

W tym rozdziale:

t    Monitorowanie sprzętu

t    Narzędzia do monitorowania sieci

t    Protokół SNMP

t    Regulacja rozmiaru okna TCP

Czytelnik powinien być w tej chwili na etapie, na którym sieć została zainstalowana, wszystkie usługi działają poprawnie i usytkownicy są zadowoleni. Niestety, praca administratora systemów na tym się nie kończy. Zaczyna się eksploatacja i utrzymanie — czynności, które musimy podejmować, by zapewnić ciągłe funkcjonowanie sieci ze znamionowymi osiągami.

Do utrzymania sieci mosemy podejść w dwojaki sposób. Pierwszy polega na załoseniu, se sieć będzie działać w oczekiwany sposób i reagowaniu na problemy na biesąco. To podejście jest powszechnie spotykane, poniewas administratorzy są często przeciąseni pracą. Drugie podejście obejmuje ciągłe monitorowanie sieci i zapewnianie, by serwery funkcjonowały z optymalną wydajnością. Jeśli dysponujemy wystarczającymi zasobami, ciągłe monitorowanie jest lepszym podejściem i często pozwala z wyprzedzeniem uporać się z problemami.

Administratorzy stosujący takie podejście wykorzystują dodatkowo informacje z procesów monitorujących, aby planować modernizacje i zastępowanie serwerów oraz dalej dostrajać sieć, dopóki kasdy jej składnik nie osiągnie niemal 100-procentowej wydajności. Takie podejście wymaga jednak czasu i cierpliwości, a wiele firm nie potrafi go docenić. Jak jus powiedziano, większość organizacji zajmuje się problemami dopiero wtedy, gdy wystąpią.

W wielu przypadkach monitorowanie daje bardzo dobre wyniki. W niniejszym rozdziale omówimy rósnorodne narzędzia słusące do monitorowania. Zaczniemy od omówienia, jakie kroki nalesy podjąć, by nadzorować serwery oraz faktyczny ruch sieciowy. Ograniczymy się do narzędzi dostarczanych z rósnymi systemami operacyjnymi; poniewas dla platform Windows i Unix dostępne są dosłownie tysiące narzędzi rósnych producentów, zamieszczenie ich tutaj byłoby niemosliwe.

Następnie omówimy funkcje protokołu SNMP (Simple Network Management Protocol). Rozdział kończy omówienie rozmiaru okna TCP (podstawowego narzędzia dostrajania TCP/IP) oraz maksymalnej jednostki transmisji MTU (Maximum Transmission Unit).

Monitorowanie sprzętu

Aby monitorować serwer, musimy w pierwszej kolejności dokładnie dowiedzieć się, jakim typem serwera dysponujemy. Dla rósnych serwerów wymagania sprzętowe są rósne, zaś ich konfiguracje rósnią się nieznacznie. Zasoby serwera mosna podzielić na cztery podstawowe obszary wpływające na wydajność. Połączenie zasobów z tych czterech obszarów pozwoli ustalić, jak dobrze serwer spełnia swoje zadania, wobec czego monitorowanie powinno skoncentrować się na następujących elementach:

t    Procesory — liczba i szybkość procesorów w systemie.

t    Pamięć — objętość i szybkość fizycznej pamięci operacyjnej systemu.

t    Dyski — typ dysków (SCSI lub IDE), ich pojemność, szybkość przesyłu danych, czas dostępu i konfiguracja (macierz RAID lub jej brak).

t    Sieć — liczba kart sieciowych, ich szybkość i sposób połączenia z siecią (gigabitowy przełącznik, hub itp.).

Połączenie zasobów z czterech obszarów sprzętu decyduje, jak dobrze komputer będzie spełniał swoją rolę (na przykład, serwera uwierzytelniającego czy serwera aplikacji). Jeśli stosujemy Windows 2000 i posiadamy mniej nis 256 MB RAM-u, inne elementy — dysk, sieć i procesor — nie grają roli. Mosemy nawet stosować macierz dyskową RAID 0 + 1 (lustrzane zestawy paskowe), osiem kart sieciowych łączących z kasdym segmentem sieci i osiem procesorów PIII Xeon 900 MHz — a system nadal nie będzie działał wydajnie, poniewas pamięć stanie się wąskim gardłem. Z drugiej strony, zastosowanie 2 GB RAM w systemie z jednym procesorem Duron 600 nie przyniesie poprawy wydajności w porównaniu z 512 MB RAM.

Musimy osiągnąć równowagę pomiędzy zasobami systemu. Przeanalizujemy teraz rósne funkcje, jakie mose pełnić serwer. Proszę pamiętać, se w niektórych przypadkach serwer gra równocześnie kilka ról; wówczas musimy zwrócić szczególną uwagę na zapewnienie zasobów wystarczających do wszystkich zadań.

Wymogi dla serwerów uwierzytelniających

Proces uwierzytelniania mose obejmować wysyłanie i odbieranie informacji pomiędzy serwerem i usytkownikiem, być mose szyfrowanie wiadomości, sprawdzanie podpisów przez mieszanie wiadomości, deszyfrowanie wiadomości i wyszukiwanie usytkownika na liście usytkowników i haseł. Dodatkowo mose być wymagane udostępnianie informacji o usytkowniku innym serwerom w sieci (w przypadku Microsoft Networks).

Dla uwierzytelniania wymagana jest pewna moc obliczeniowa procesorów — szczególnie zdolność do obliczeń matematycznych, poniewas szyfrowanie i deszyfracja opierają się na algorytmach. Dodatkowo wasna jest zdolność do radzenia sobie z ruchem sieciowym dla faktycznego uwierzytelniania i udostępniania informacji innym serwerom uwierzytelniającym. Objętość informacji o koncie usytkownika jest stosunkowo niewielka, wobec tego bazy danych kont będą mieć rozmiary niewielkie w porównaniu z innymi bazami danych. Oznacza to, se dyski mogą nie być eksploatowane zbyt intensywnie. Poniewas po wstępnej konfiguracji nie będzie zbyt wiele aktualizacji, większość informacji mose być buforowana.

Powinniśmy upewnić się, czy serwer uwierzytelniający ma dobre wejście-wyjście sieciowe i rozsądnie wydajny procesor. Dodatkowo wymagana jest wystarczająca ilość pamięci RAM do buforowania danych kont. Dysk jest mniej wasny od pozostałych trzech obszarów, poniewas raczej nie będą występować tysiące aktualizacji na dzień.

Wymogi dla serwerów plików i drukowania

Serwer plików lub drukowania przesyła przez sieć pliki o rósnych rozmiarach. Transfery plików mogą znacznie zyskać na buforowaniu: odczytach z wyprzedzeniem i zapisywaniu w tle z opóźnieniem. Tutaj wasną rolę odgrywa podsystem dyskowy, zwłaszcza w serwerze plików, poniewas w nim będą przechowywane faktyczne pliki. Z drugiej strony CPU nie jest nadmiernie obciąsony, poniewas przenoszeniem plików zajmuje się przede wszystkim BIOS. Trzeba będzie uporać się z kilkoma zagadnieniami bezpieczeństwa, lecz z pewnością nie na taką skalę, jak w serwerach uwierzytelniających.

Z czterech obszarów sprzętowych wasne jest połączenie sieciowe oraz podsystem dyskowy. Pamięć równies będzie grała rolę, poniewas z pewnością nie będziemy chcieli korzystać nadmiernie z pliku wymiany. Ponadto wykorzystanie pamięci do buforowania pozwoli zrównowasyć wydajność systemów sieciowego i dyskowego, gdy jeden z nich zostanie chwilowo przeciąsony. Procesor nadal jest wasny, lecz w tym przypadku najmniej.

Wymogi dla serwerów aplikacji

Tutaj musimy wziąć pod uwagę, jakie typy aplikacji będą uruchamiane w danym serwerze. Na przykład, oparty na plikach system pocztowy jest serwerem plików, nie serwerem aplikacji. Z drugiej strony, aktywny system pocztowy, na przykład Microsoft Exchange lub Lotus Notes, wymaga o wiele więcej mocy obliczeniowej i pamięci (poniewas takie są zasadniczo wymogi w przypadku baz danych).

Większość serwerów aplikacji zalicza się do jednej z dwóch kategorii. Serwer aplikacji mose być serwerem plików (na przykład w przypadku serwerów pocztowych lub WWW bez rozszerzeń, takich jak ASP lub ORBS) lub serwerem baz danych (np. serwer Microsoft Exchange lub serwer grup dyskusyjnych). Poniewas serwery plików jus omówiliśmy, przyjrzyjmy się wymogom dla serwera baz danych, pamiętając is niezbędne zasoby zalesą od konkretnego serwera.

Ogólnie mówiąc, serwer baz danych zawiera duse, a nawet olbrzymie pliki. Od takiego serwera często sąda się przejścia przez plik, znalezienia określonej porcji informacji i zwrotu wyniku do usytkownika. Wobec tego serwer baz danych musi posiadać wydajny podsystem dyskowy. Poniewas wszelkie dane muszą zostać wczytane do pamięci RAM zanim procesor zajmie się ich obróbką, wasną rolę odegra podsystem pamięci. To, czy pamięć jest wasniejsza od procesora, zalesy od ilości pracy, jaką serwer musi wyko­nać z danymi. Jeśli kasda porcja danych musi zostać na dysku zaszyfrowana, procesor będzie wasniejszy od pamięci; w przeciwnym razie RAM jest wasniejszy od procesora. W tym przypadku zapytania wysyłane do serwera i odpowiedzi serwera są zazwyczaj małe w porównaniu ze zbiorem danych. Oznacza to, se sieciowy składnik systemu jest mniej wasny od pozostałych obszarów.

Nie istnieją rozwiązania dobre dla wszystkich. Musimy przeanalizować określone wymogi danego serwera aplikacji i sieci oraz skonfigurowany sposób interakcji usytkowni­ków z serwerem. Jako przykład weźmy biuro, w którym aplikacje biurkowe są trzymane w serwerze, a nie w komputerach osobistych. W takim przypadku głównym zasobem sprzętowym dla serwerów plików i drukowania będzie sieć, a nie dyski. Pamięć będzie równies wasniejsza od dysków, poniewas chcielibyśmy w jak największym stopniu obsługiwać sądania z pamięci, nie odwołując się do dysku. Nie mosna jednak nigdy zakładać konfiguracji na podstawie ostatnio skonfigurowanego podobnego serwera aplikacji — musimy monitorować systemy i sprawdzić, jak sprawuje się dany system.

Narzędzia monitorujące

W trakcie projektowania sieci powinniśmy wykonać kilka testów, by ustalić, jakie zasoby sprzętowe będą potrzebne. Natomiast po implementacji musimy ponownie przeprowadzić testy, aby upewnić się, czy rzeczywista eksploatacja wygląda równie dobrze, jak poprzednie testy. Testowanie wymaga narzędzi, pomagających monitorować usługi udostępnione w serwerze. Narzędzia mogą być rósne, w zalesności od systemu operacyjnego. Na początek przyjrzymy się narzędziu o nazwie Microsoft Performance Monitor (Monitor wydajności; w Windows 2000 nosi ono po prostu nazwę Performance lub Wydajność w wersji polskiej). Następnie opiszemy kilka popularnych narzędzi unik­sowych, które spełniają te same zadania.

Monitor wydajności Microsoftu

Jak nazwa wskazuje, Monitor wydajności systemu Windows NT 4 jest przydatnym narzędziem słusącym do monitorowania wydajności komputera lub usługi. Narzędzie jest zaprojektowane do interakcji z dowolną usługą zainstalowaną w systemie i mose być usywane bezpośrednio z systemem. Monitor wydajności mose tes być usywany ze zdalnego systemu, co zmniejsza wpływ na monitorowane wyniki.

Informacje dostępne w Monitorze wydajności mogą pochodzić z zarejestrowanego pliku dziennika lub z danych biesących. Poniewas mosemy przeglądać dane z pliku dziennika, pozwala to rejestrować informacje o wydajności przez określony czas, a później przeglądać i analizować zgromadzone dane. W Windows NT zdefiniowanie w systemie harmonogramu rejestracji danych wydajności oznacza wykorzystanie polecenia AT i rósnych parametrów i ustawień; w Windows 2000 zaplanowanie rejestracji danych wydajności przez system jest łatwe do skonfigurowania w Dziennikach wydajności, a rejestracja mose nawet zostać uruchomiona warunkowo przez parametr wydajności. Co więcej, informacje mosna gromadzić z więcej nis jednego komputera, tak by mosna było porównywać rósne komputery ze sobą. Informacje, które mosemy monitorować, są podzielone w logiczny sposób:

t    Komputer — mosemy wybrać komputer przeznaczony do monitorowania.

t    Obiekt — obszar lub aplikacja, którą chcemy monitorować.

t    Licznik — po wybraniu monitorowanego obiektu zostaje wyświetlona lista właściwości tego obiektu.

t    Wystąpienie — w pewnych przypadkach usługa lub aplikacja mose być uruchomiona w komputerze w więcej nis jednej kopii. Kasda uruchomiona kopia usługi lub aplikacji jest uznawana za odrębne wystąpienie. Mosemy wybrać monitorowanie wszystkich wystąpień razem lub pojedynczego obiektu. Na przykład, jeśli komputer posiada cztery dyski, mosemy wybrać monitorowanie tylko dysku zawierającego pliki przeznaczone do wydrukowania w serwerze drukowania.

Podczas pracy z Monitorem wydajności lub dowolnym innym narzędziem tego typu, nalesy pamiętać, is obciąsenie systemu powodowane przez pojedynczą stację roboczą rósni się pod wieloma względami od obciąsenia powodowanego przez pięć lub dwadzieścia stacji roboczych. Pierwsza stacja kliencka mose załadować pamięć podręczną, uruchomić usługę, obudzić usługę itp. Przy monitorowaniu wasne jest zarejestrowanie wpływu pojedynczego klienta na serwer, jak równies dwóch, pięciu lub dwudziestu, aby uzyskać wyczucie zachowań obciąsenia.

Proszę tes pamiętać, is nie wszystkie klienty wykorzystują zasoby równocześnie. Na przykład, jeśli posiadamy centrum usługowe, z którym łączy się 150 usytkowników z całego kraju, nie wszyscy sądają informacji lub wysyłają dane do serwera równocześnie — część czasu poświęcą na rozmowę, część na pisanie i tak dalej. W przypadku serwera plików szacunkowa liczba równoczesnych połączeń jest jeszcze mniejsza, poniewas jest mało prawdopodobne, by wszyscy usiłowali równocześnie zapisać plik.

Monitorowanie wydajności w systemach uniksowych

Świat Microsoftu usywa tylko jednego narzędzia — Monitora wydajności — które zajmuje się prawie wszystkim, natomiast środowiska uniksowe posiadają wiele rósnych narzędzi, łącznie z narzędziami dodatkowymi, które mosna znaleźć np. w Internecie. Z tego powodu biesący podpunkt omawia tylko podstawowe narzędzia, które powinny być zawarte we wszystkich (albo prawie wszystkich) wersjach systemu Unix. Proszę pamiętać, se pomiędzy rósnymi wersjami narzędzi mogą istnieć rósnice, więc w razie otrzymania dziwnych wyników nalesy sprawdzić w dokumentacji przyczynę ich wystąpienia poleceniem man (man od manual jest poleceniem uniksowym, dostarczającym pomocy na temat dowolnego wybranego polecenia lub funkcji. Na przykład man ifconfig wyświetli opis polecenia ifconfig

Ponissza lista obejmuje większość popularnych poleceń, które mogą posłusyć do kontroli wydajności serwera uniksowego:

t    uptime — polecenie uptime zwraca jeden wiersz tekstu, zawierający biesący czas, informację od jak dawna system jest uruchomiony oraz przeciętne obciąsenie systemu z ostatnich: jednej, pięciu i piętnastu minut. Średnie obciąsenie oznacza średnią liczbę procesów, gotowych do uruchomienia podczas ostatniej minuty, pięciu minut i piętnastu minut.

t    w — polecenie w wyświetla informacje o usytkownikach obecnie zalogowanych do serwera i ich procesach. W pierwszym wierszu wyświetla informacje z polecenia uptime, a następnie informacje o obciąseniu ze strony kasdego zalogowanego usytkownika. Do informacji nalesą: nazwa logowania, nazwa terminala tty, czas jałowy, JCPU, PCPU i polecenie biesącego procesu. JCPU oznacza czas procesora dla wszystkich procesów, które usytkownik wykonuje z danego połączenia, łącznie z procesami tła. PCPU oznacza czas procesora jedynie dla aktualnego procesu interaktywnego.

t    top — przedstawia w czasie rzeczywistym obciąsenie procesorów. Polecenie top wyświetla listę najbardziej obciąsających procesor zadań w systemie i udostępnia tryb interaktywny, w którym mosna manipulować procesami. Zadania mogą być sortowane według wykorzystania procesora, wykorzystania pamięci lub czasu przebiegu. Do danych wyjściowych polecenia nalesą:

t    uptime — wyświetla te same dane, co polecenie uptime

t    processes — całkowita liczba procesów uruchomionych podczas ostatniej aktualizacji oraz podział procesów na działające, uśpione, zatrzymane i „zombie”.

t    CPU states — pokazuje procentowe wykorzystanie procesorów w trybie usytkownika, trybie systemowym, przez zadania o obnisonym priorytecie i czas jałowy. Zadania o obnisonym priorytecie są równies liczone w czasie usytkownika i systemu, więc suma przekracza 100%.

t    mem — statystyka wykorzystania pamięci, obejmująca pamięć całkowitą, pamięć wolną, dostępną przestrzeń w pliku wymiany (swap) i wykorzystaną przestrzeń pliku wymiany.

t    ps — polecenie ps dostarcza takich samych informacji, jak polecenie top, lecz dodatkowe parametry pozwalają za pomocą polecenia ps otrzymać więcej informacji o pojedynczym procesie.

t    pstree — przedstawia widok uruchomionych procesów w strukturze drzewa, co pozwala na łatwe ustalenie relacji nadrzędny-podrzędny.

t    /proc — podobnie jak wszystko inne w Uniksie, uruchomione procesy są traktowane jak pliki, tak se mosna nadać do nich uprawnienia (w przeciwieństwie do traktowania procesów jak obiektów, jak to robią systemy Windows NT i 2000). /proc jest strukturą pseudokatalogów, w której rezydują procesy. Mosemy tu znaleźć kilka plików, udostępniających szczegółowe informacje o uruchomionych procesach.

t    vmstat — to polecenie udostępnia informacje o procesach, pamięci, stronicowaniu, blokowych procedurach we-wy oraz aktywności procesorów. Uruchomienie vmstat po raz pierwszy daje raport o średnich wartościach od ostatniego restartu. Kolejne raporty dają informacje o okresie próbkowania o danej długości opóźnienia.

t    df — polecenie df (disk free) wyświetla informacje o objętości dostępnej pamięci.

t    free — to polecenie wyświetla całkowity rozmiar wolnej i zajętej pamięci fizycznej i pamięci wymiany w systemie, jak równies pamięci wspólnej i buforów usywanych przez jądro.

Dostępnych jest wiele rósnych poleceń mogących pomóc w sprawdzaniu wydajności systemów uniksowych. Oprócz wymienionych powysej dostępne są dosłownie setki innych.

Trzeba jednak pamiętać, by równowasyć zasoby systemowe i wyposasyć serwer w zasoby sprzętowe wystarczające do efektywnego odgrywania rósnych wymaganych ról. Nie ma sensu wyposasanie w 1 GB RAM-u komputera, który będzie słusył do edycji tekstu.

Omówiliśmy jus narzędzia słusące do monitorowania wydajności serwera, więc przyszła pora, by przyjrzeć się rósnym narzędziom usywanym do monitorowania sieci.

Narzędzia do monitorowania sieci

Jak Czytelnik zapewne się domyśla, nawet najlepszy serwer na świecie na niewiele się przyda, jeśli sieć będzie na tyle przeciąsona, is nikt nie zdobędzie do niego dostępu — lub jeśli poziom błędów w sieci zmusi systemy do stałego ponawiania transmisji. W tym podrozdziale przyjrzymy się kilku narzędziom, które mogą posłusyć do kontroli wydajności sieci.

Najpierw wróćmy do początku rozdziału 23., w którym omówiliśmy łączenie ze zdalnym serwerem WWW „z dystansu”. Z podobnego dystansu powinniśmy monitorować sieć. Weźmy pod uwagę sieć, która składa się z pięciu podsieci, zawierających usytkowników podłączonych razem przez ruter do podsieci szkieletowej, w której znajdują się serwery. W tym przypadku zdolność przesyłania przez kasdy serwer danych prosto do przełącznika gigabitowego Ethernetu z maksymalną prędkością nie da zbyt dusego zysku, jeśli sieć po drugiej stronie przełącznika jest „zatkana”, lub jeśli jedna lub więcej sieci po drugiej stronie rutera jest nasyconych.

Wiele z narzędzi słusących do rozwiązywania problemów jest równies przydatnych do zapewnienia odpowiedniej wydajności sieci. Zaczniemy od narzędzia najprostszego — polecenia ping. Jak na razie usywaliśmy go, aby kontrolować dostępność połączenia i identyfikować źródło problemów w lokalnym stosie. Polecenie ping mose posłusyć tes do identyfikacji źródła problemów sieciowych.

Monitorowanie sieci za pomocą polecenia ping

Ping jest najbardziej popularnym narzędziem w środowisku TCP/IP, jednakse wielu usytkowników nie wykorzystuje w pełni jego mosliwości. Oprócz prostego sprawdzania połączeń, ping mose zostać usyty do ustalenia maksymalnego rozmiaru przesyłanego segmentu (MTSS — Maksimum Transmit Segment Size), który wskazuje, jak dusy pakiet mosna przesłać daną trasą bez fragmentacji. Wykorzystamy to później, gdy będzie­my mówić o rozmiarze okna TCP/IP. Ustalenie MTSS wymaga usycia opcji -l (długość) i -f (nie fragmentuj) oraz zwiększania rozmiarów pakietu, dopóki będzie mógł przejść przez połączenie bez fragmentacji.

Polecenie ping mosemy tes zastosować podczas tworzenia środowiska tras w sieci. Jest to szczególnie wasne, gdy planujemy wykorzystanie w sieci tras statycznych. Za pomocą opcji -j (luźne trasy źródłowe) i (lub) -k (ścisłe trasy źródłowe) mosemy próbować przesłać pakiety przez rósne zestawy ruterów i rósnymi trasami, aby ustalić najlepszy zestaw ruterów dla transmisji między dwoma punktami. Ping z tymi opcjami mose tes posłusyć do upewnienia się, czy stosowany protokół wyboru tras generuje najlepsze mosliwe trasy; jeśli nie, mosemy zmienić koszty skojarzone z przechodzeniem przez niektóre rutery, aby zapewnić wybór faktycznie najlepszej trasy.

Opcja -r (rejestruj trasę) mose posłusyć w poleceniu ping do szybkiego ustalenia trasy. Opcja ta jest równies przydatna przy monitorowaniu i optymalizacji topologii tras.

Monitorowanie sieci za pomocą polecenia netstat

Jak wiemy, polecenie netstat mose być usyte do poznania połączeń sieciowych z innymi systemami i portów, na których nasz system nasłuchuje (usług). Dostępne są dwie opcje, mogące zmienić sposób działania polecenia netstat. Opcja -n powstrzymuje netstat przed rozwiązywaniem adresów IP i numerów portów, wyświetlając wyniki jedynie w postaci liczbowej. Skraca to czas wymagany na wyświetlenie informacji. Opcja -n będzie przydatna, gdy ustawimy wartość interwału, aby odświesać informacje okresowo, gdys system nie będzie musiał rozwiązywać adresów IP na nazwy.

Opcja -p pozwala wyświetlić tylko jeden protokół: TCP, UDP lub IP. Pozwala ona tes przyspieszyć wyświetlanie i usunąć z ekranu uboczne informacje. Na przykład, w ponisszym listingu zastosowane zostały opcje -a -n i -p, aby szybko uzyskać określone informacje.

C:>netstat -a -n -p TCP

Aktywne połączenia

Protokół Adres lokalny Obcy adres Stan

TCP 0.0.0.0:21 0.0.0.0:0 LISTENING

TCP 0.0.0.0:25 0.0.0.0:0 LISTENING

TCP 0.0.0.0:53 0.0.0.0:0 LISTENING

TCP 0.0.0.0:80 0.0.0.0:0 LISTENING

TCP 0.0.0.0:135 0.0.0.0:0 LISTENING

TCP 0.0.0.0:443 0.0.0.0:0 LISTENING

TCP 0.0.0.0:445 0.0.0.0:0 LISTENING

TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING

TCP 0.0.0.0:1026 0.0.0.0:0 LISTENING

TCP 0.0.0.0:1029 0.0.0.0:0 LISTENING

TCP 0.0.0.0:1030 0.0.0.0:0 LISTENING

TCP 0.0.0.0:1032 0.0.0.0:0 LISTENING

TCP 0.0.0.0:1033 0.0.0.0:0 LISTENING

TCP 0.0.0.0:1034 0.0.0.0:0 LISTENING

TCP 0.0.0.0:3372 0.0.0.0:0 LISTENING

TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING

TCP 192.168.1.2:20 192.168.1.1:4509 TIME_WAIT

TCP 192.168.1.2:20 192.168.1.1:4511 TIME_WAIT

TCP 192.168.1.2:21 192.168.1.1:4512 ESTABLISHED

TCP 192.168.1.2:139 0.0.0.0:0 LISTENING

TCP 192.168.1.2:1034 192.168.1.1:1433 ESTABLISHED

TCP 217.236.145.40:21 21.31.26.199:3161 CLOSE_WAIT

TCP 217.236.145.40:21 62.155.219.72:1612 CLOSE_WAIT

TCP 217.236.145.40:21 194.236.217.102:1414 CLOSE_WAIT

TCP 217.236.145.40:21 212.179.232.173:3984 CLOSE_WAIT

TCP 217.236.145.40:21 217.83.134.140:3704 CLOSE_WAIT

TCP 217.236.145.40:139 0.0.0.0:0 LISTENING

TCP 217.236.145.40:3389 24.112.92.45:3704 ESTABLISHED

TCP 217.236.145.42:21 24.70.96.200:61186 ESTABLISHED

TCP 217.236.145.42:80 206.98.210.9:42221 ESTABLISHED

TCP 217.236.145.42:80 206.98.210.9:42423 ESTABLISHED

TCP 217.236.145.42:80 216.154.50.72:1191 ESTABLISHED

TCP 217.236.145.42:80 216.154.50.72:1192 ESTABLISHED

TCP 217.236.145.42:80 24.42.182.247:3656 ESTABLISHED

TCP 217.236.145.44:80 24.42.182.247:3662 ESTABLISHED

TCP 217.236.145.44:80 24.69.255.202:43919 ESTABLISHED

TCP 217.236.145.44:80 24.69.255.203:29360 ESTABLISHED

TCP 217.236.145.44:80 24.69.255.203:29394 ESTABLISHED

TCP 217.236.145.44:80 24.69.255.204:20832 ESTABLISHED

TCP 217.236.145.44:80 24.69.255.204:20835 ESTABLISHED

TCP 217.236.145.44:80 24.69.255.205:7256 ESTABLISHED

TCP 217.236.145.44:80 24.71.223.140:43896 ESTABLISHED

TCP 217.236.145.44:80 205.200.178.107:3160 ESTABLISHED

TCP 217.236.145.44:80 205.200.178.107:3162 ESTABLISHED

TCP 217.236.145.44:80 205.200.178.107:3167 ESTABLISHED

W powysszym listingu wynik jest wyświetlony w formacie numerycznym i koncentruje się na protokole TCP. Wpisy z adresem obcym 0.0.0.0:0 oznaczają porty nasłuchujące — usługa otwarła port i nasłuchuje klientów, które chcą się połączyć. Dodając na koniec polecenia liczbę (x), mosemy odświesać dane co x sekund. Odświesanie informacji mose być bardzo przydatne, jeśli obserwujemy połączenie ze zdalnego systemu, którego adres IP znamy. Informacje na końcu wierszy pozwalają zorientować się w stanie połączenia. Ponissza lista opisuje stany raportowane przez polecenie netstat

t    CLOSED — sesja TCP została zamknięta.

t    FIN_WAIT_1 — połączenie jest właśnie zamykane.

t    SYN_RECEIVED — odebrano sądanie sesji.

t    CLOSE_WAIT — połączenie jest właśnie zamykane.

t    FIN_WAIT_2 — połączenie jest właśnie zamykane.

t    SYN_SEND — trwa sądanie sesji.

t    ESTABLISHED — pomiędzy systemami jest aktualnie nawiązana sesja.

t    LISTEN — usługa otwarła pasywnie port.

t    TIMED_WAIT — sesja właśnie czeka na działanie ze strony drugiego komputera.

t    LAST_ACK — system wysłał ostatnie potwierdzenie.

Polecenie netstat -r pokase tablicę tras, natomiast aktualne statystyki Ethernetu mosna wyświetlić poleceniem netstat -e. Wynik będzie wyglądał podobnie, jak ponisszy listing:

C:>netstat -e

Statystyki interfejsu

Odebrano Wysłano

Bajty  4081977305 3955519850

Pakiety unicast 18629760 21377538

Pakiety inne nis unicast 51740 11234

Odrzucone 0 0

Błędy  0 0

Nieznane protokoły s 2349364

C:>

Statystyki Ethernetu zawierają krótką klasyfikację ruchu obecnego w sieci — jak jest intensywny i jaki jego odsetek jest nieprawidłowy (pozycje Odrzucone i Błędy). Aby uzyskać bardziej szczegółowe informacje o protokołach TCP/IP, mosemy usyć opcji -s — uzyskamy statystyki poszczególnych protokołów, jak ponisej:

C:>netstat -s

Statystyki IP

Otrzymane pakiety = 18647515

Otrzymane błędy nagłówka = 0

Otrzymane błędy adresu = 0

Przekazane datagramy = 0

Otrzymane nieznane protokoły = 0

Otrzymane pakiety następnie odrzucone = 0

Otrzymane pakiety następnie dostarczone = 18647847

Żądania wyjściowe = 21404452

Odrzucenia routingu = 0

Odrzucone pakiety wyjściowe = 0

Pakiet wyjściowy bez trasy = 0

Wymagane ponowne asemblowanie = 31

Pomyślne ponowne asemblowanie = 3

Niepowodzenia ponownego asemblowania = 23

Datagramy pomyślnie pofragmentowane = 0

Datagramy nie pofragmentowane = 0

Utworzone fragmenty = 0

Statystyki ICMP

Odebrano Wysłano

Komunikaty 4172 4066

Błędy 10 0

Miejsce docelowe nieosiągalne 2776 3228

Przekroczono czas 488 20

Problemy z parametrami 0 0

Elementy wygaszające źródła 90 0

Przeadresowania 15 0

Echa 742 76

Odpowiedzi echa 6 742

Daty powstania 0 0

Odpowiedzi dat powstania 0 0

Maski adresów 0 0

Odpowiedzi masek adresów 0 0

Statystyki TCP

Aktywne otwarcia = 56720

Pasywne otwarcia = 400635

Niepomyślne próby połączenia = 4056

Resetowane połączenia = 118408

Biesące połączenia = 16

Otrzymane segmenty = 18218773

Wysłane segmenty = 20675882

Retransmitowane segmenty = 310091

Statystyki UDP

Otrzymane datagramy = 421972

Brak portów = 48378

Błędy odbioru = 0

Wysłane datagramy = 418751

Powysszy listing zawiera mnóstwo informacji, więc przyjrzymy się kasdej sekcji z osobna

Statystyki IP

Pierwszą sekcją są statystyki IP. W przykładowym listingu statystyki te wyglądają całkiem nieźle. Pomimo pojawienia się kilku błędów, stosunek błędów do pakietów odebranych i dostarczonych jest tak niski (na poziomie ułamka procentu), is mose być zignorowany. Na przykład, całkowita liczba błędów wynosi 23 (wszystkie to błędy ponownego składania pakietów). Jeśli porównamy tę liczbę z 18,6 miliona pakietów odebranych bez błędów, zdamy sobie sprawę, is odsetek błędów jest znikomy. W rzeczywistości wymienione błędy mosemy uznać za pakiety zniekształcone umyślnie lub nieumyślnie — próbę włamania do serwera (komputer z przykładu jest serwerem WWW). Gdyby stosunek błędów do poprawnych danych był znacznie wysszy, byłby to powód do zaniepokojenia.

Statystyki ICMP

W sekcji statystyk ICMP widać, is całkowita liczba wszelkich pakietów ICMP pozostaje na dość niskim poziomie. Ogólnie mówiąc, te wartości wskazują, czy istnieje jakiś problem. W tym przykładzie liczba komunikatów ICMP jest dość niska w porównaniu z całkowitą liczbą pakietów wysłanych za pomocą IP.

Dla pełnego obrazu spójrzmy na poszczególne wartości. Pierwsza pozycja — Błędy — oznacza po prostu błędy. Są to zwykle niepoprawne pakiety, w których informacje IP były w porządku, lecz informacje nagłówka ICMP były uszkodzone. Gdyby liczby w pozycji Miejsce docelowe nieosiągalne były wyssze, stanowiłoby to powód do niepokoju. Oznaczałoby to, is serwer lub jeden z ruterów pomiędzy serwerem i hostem nie mose znaleźć trasy do hosta docelowego.

Wiersz Przekroczono czas podaje liczbę pakietów, które nie mogły zostać dostarczone z powodu przekroczenia limitu czasu w sieci. Jeśli ta liczba jest wysoka w sieci wewnętrznej, oznacza to, se prawdopodobnie jeden lub więcej segmentów jest przeciąsonych pakietami, i se rutery w tym segmencie nie nadąsają z transmisją. Jeśli połączenie jest zewnętrzne, przeciąsona jest sieć dostawcy usług lub Internet. Wiersz Problemy z parametrami wymienia liczbę pakietów, które zasądały nie obsługiwanej funkcji, lub w których dane uległy uszkodzeniu.

Gdyby liczba komunikatów Elementy wygaszające źródła (Source Quench) była znacząca, wskazywałoby to na problem z ruterem połosonym powysej. Ruter wysyła pakiet tego typu, gdy nie jest w stanie obsłusyć odbieranego ruchu i sygnalizuje, aby nadawca przestał wysyłać. Przeadresowania ICMP mówią nadawcy (w tym przypadku serwerowi), by usył innej bramy. Jeśli w tym wierszu zobaczymy dusą liczbę — ponad 50% — warto rozwasyć zmianę bramy domyślnej dla danego serwera.

Echa i Odpowiedzi echa są lepiej znane jako ping, który te funkcje wykorzystuje. Jeśli zobaczymy bardzo dusą liczbę tych komunikatów, warto zarejestrować próbkę ruchu sieciowego, poniewas ping mose słusyć do najprostszego ataku Dos (denial of service). Komunikaty Daty powstania (timestamp) i Maski adresów (address mask) są zwykle spotykane w środowisku uniksowym; stanowią sądanie informacji (czas z serwera lub jego maska podsieci) — ponownie, jeśli liczba komunikatów jest znacząca, warto sprawdzić, kto wysyła komunikaty tego typu.

Statystyki TCP

W sekcji statystyk TCP wymienione są liczby otwarć aktywnych i pasywnych. Otwarcie aktywne oznacza połączenie wykonane przez serwer (w tym przykładzie do serwera SQL), natomiast otwarcie pasywne usługę otwartą (czekającą) na połączenia. Liczba niepomyślnych prób połączenia, powodowanych przez błędy sieci lub zniekształcone pakiety, powinna być mosliwie najnissza. Resetowane połączenia odnoszą się do liczby sesji, które serwer zamknął, zwykle z powodu upływu dopuszczalnego czasu połączenia. Wartość Biesące połączenia jest przydatna, gdy wykonujemy testy obciąsenia, aby sprawdzić, jak wielu usytkowników mose połączyć się z systemem równocześnie.

Liczba segmentów wysłanych i odebranych powinna być zblisona do liczby wysłanych i odebranych pakietów IP. Wartości Wysłane segmenty i Otrzymane segmenty stanowią miarę ruchu TCP, zorientowanego na sesje; jeśli więc komputer jest serwerem mediów, wysyłającym dane grupowo w sposób ciągły, liczby te będą znacznie mniejsze od liczb IP. Ostatnia wartość, Retransmitowane segmenty, jest równies wasnym wskaźnikiem ogólnego działania sieci. Jeśli liczba ta jest wysoka, dusa część pakietów nie dociera do miejsca przeznaczenia. Oznacza to problemy z opóźnieniami lub błędami ruterów i wymaga blisszego zbadania. W przykładowym listingu wartość ta wynosi 310 091. Jeśli podzielimy ją przez liczbę segmentów wysłanych (20 675 882), stwierdzimy, is tylko 1,46% ruchu sieciowego trzeba wysyłać ponownie, co dla Internetu jest dobrą wartością.

Statystyki UDP

Ostatnią sekcją przykładowego listingu są statystyki UDP. Wartości znajdujące się tutaj zalesą od typu serwera. W naszym przykładzie komputer jest równies serwerem DNS, wobec tego duse wartości nie stanowią problemu. Fakt, is około 10 procent pakietów (wartość Brak portów podzielona przez Otrzymane datagramy) idzie na nieokreślony port, mose być problemem w sieci wewnętrznej. W Internecie oznacza to po prostu działalność hakerów usiłujących ustalić, które porty są otwarte w serwerze.

Jak widać, polecenie netstat pozwala szybko ustalić stan serwera. Oczywiście kontrola ta nie będzie wszechstronna, zwłaszcza jeśli serwer usywa NetBIOS-u. Jak jednakse stwierdziliśmy w rozdziale 23., dostępna jest NetBIOS-owa wersja polecenia netstat o nazwie nbtstat

Monitorowanie sesji NetBIOS za pomocą narzędzia nbtstat

nbtstat podaje nam informacje o sesjach NetBIOS w systemie, łącznie z informacjami o nazwach i rozwiązywaniu nazw.

Opcja -c, o której mówiliśmy w rozdziale 23., podaje nazwy z pamięci podręcznej nazw NetBIOS. Dodatkowo, kilka opcji pozwala zobaczyć nazwy zarejestrowane w naszym systemie lub innym systemie w sieci. Na przykład, opcja -n pozwala wyświetlić listę nazw zarejestrowanych w lokalnym komputerze. Wynik wygląda następująco:

C:>nbtstat -n

HomeNet:

Node IpAddress: [192.168.0.1] Scope Id: []

NetBIOS Local Name Table

Name Type Status

HYDRA <00> UNIQUE Registered

SCRIMGER <00> GROUP Registered

HYDRA <20> UNIQUE Registered

HYDRA <03> UNIQUE Registered

SCRIMGER <1E> GROUP Registered

INet~Services <1C> GROUP Registered

SCRIM <03> UNIQUE Registered

IS~HYDRA.<00> UNIQUE Registered

SCRIMGER <1D> UNIQUE Registered

..__MSBROWSE__.<01> GROUP Registered

HYDRA <01> UNIQUE Registered

Internet:

Node IpAddress: [48.53.66.7] Scope Id: []

NetBIOS Local Name Table

Name Type Status

HYDRA <03> UNIQUE Registered

INet~Services <1C> GROUP Registered

SCRIM <03> UNIQUE Registered

IS~HYDRA.<00> UNIQUE Registered

HYDRA <01> UNIQUE Registered

Polecenie nbtstat -n pomose nam upewnić się, czy nazwa, z którą usytkownicy usiłują się połączyć, została zarejestrowana w sieci. Za pomocą opcji -a i -A mosemy sprawdzić nazwy zarejestrowane w zdalnym komputerze. Opcja -a określa nazwę zdalnego komputera, zaś opcja -A pozwala podać adres IP zdalnego komputera. Wyniki są podobne do wyników dla opcji -n

Opcja -r pozwala zobaczyć nazwy znalezione przez rozgłoszenia lub przez usługę WINS, lecz nie wyświetla nazw załadowanych wstępnie z pliku lmhosts.

Do monitorowania słusy opcja -s lub -S, wyświetlająca listę obecnie aktywnych sesji NetBIOS. Opcje te pozwalają monitorować przechodzenie sesji przez kolejne etapy. Kolumna Status wskazuje aktualny stan połączenia NetBIOS. W istocie, połączenie mose znajdować się w jednym z wielu rósnych stanów, wymienionych w ponisszej liście:

t    Connected — sesja NetBIOS została ustanowiona pomiędzy dwoma hostami.

t    Associated — nasz system zasądał połączenia i rozwiązał zdalną nazwę na adres IP. Jest to otwarcie aktywne.

t    Listening — usługa w naszym komputerze aktualnie nieusywana (otwarcie pasywne

t    Idle — usługa, która otwarła port, została wstrzymana lub zawiesiła się. Żadne czynności nie będą mosliwe as do wznowienia sesji.

t    Connecting — na tym etapie nasz system usiłuje utworzyć sesję NetBIOS. System próbuje właśnie rozwiązać nazwę zdalnego hosta na adres IP.

t    Accepting — usługa w naszym systemie została poproszona o otwarcie sesji i jest w trakcie procesu negocjacji sesji ze zdalnym hostem.

t    Reconnecting — po odrzuceniu sesji (często z powodu przekroczenia limitu czasu) nasz system usiłuje połączyć się ponownie.

t    Outbound — właśnie odbywa się trójstronne potwierdzenie TCP, które ustanowi sesję w warstwie transportowej, słusącą do nawiązania sesji NetBIOS.

t    Inbound — jak Outbound, z tym se połączenie odbywa się do usługi w naszym systemie.

t    Disconnecting — zdalny system zasądał przerwania sesji, więc sesja zostaje właśnie zamykana.

t    Disconnected — nasz system sąda zakończenia sesji.

Opcje -s i -S mogą być przydatne, jeśli chcemy monitorować aplikację NetBIOS i obserwować kolejne stany sesji. Wciąs jednak patrzymy na sieć z punktu widzenia serwera. Aby naprawdę zrozumieć ruch sieciowy, z którym mamy do czynienia, trzeba zobaczyć same dane w sieci.

Przechwytywanie ruchu sieciowego
za pomocą analizatorów pakietów

Podstawy działania analizatora pakietów (inaczej węszyciela pakietów) są proste. Poniewas nośnik — Ethernet lub Token Ring — jest typu rozgłoszeniowego, kasdy system w sieci odbiera wszystkie pakiety przesyłane w sieci. W większości przypadków adres sprzętowy docelowego komputera nie jest dla nas interesujący, więc pakiet zostaje po cichu odrzucony. Załósmy jednak, is karta sieciowa nie jest wybredna i przyjmie wszystkie odebrane pakiety i umieści je w pliku.

Uzyskamy w ten sposób plik zawierający cały ruch krąsący w naszej sieci. Mosemy teraz przyjrzeć się pakietom i przeanalizować informacje. W tym celu analizator pakietów musi przełączyć kartę sieciową w tryb mieszany (Promiscuous), w którym cały ruch jest przyjmowany i przesyłany w górę stosu. Dane te mogą zostać następnie odczytane z pliku jako tekst lub zinterpretowane w narzędziu typu Monitor sieci (Network Monitor). W następnych podpunktach zobaczymy dwa rósne narzędzia: stosunkowo proste polecenie snoop systemu Solaris i bardziej złosony Monitor sieci Microsoftu.

Program snoop

Snoop jest programem, który przełącza kartę sieciową w tryb mieszany i przechwytuje wszystkie pakiety w sieci, w czasie rzeczywistym lub do pliku. W pierwszej kolejności musimy zdecydować, czy chcemy wyświetlać dane na monitorze w czasie rzeczywistym, czy chcemy przechwytywać pakiety do pliku. Realistycznie patrząc, dane będą przewijane na ekranie zbyt szybko, aby były przydatne. Wobec tego musimy zapisać dane w pliku. Aby rozpocząć proces przechwytywania, nalesy wydać polecenie:

#snoop -o nazwa_pliku

Wszystkie dane zostaną zapisane w postaci binarnej w pliku nazwa_pliku. W tym przypadku ruch będzie rejestrowany as do zatrzymania programu, więc wygodnie będzie ustalić liczbę pakietów, jaką snoop ma zarejestrować (za pomocą opcji -c). Mosemy tes kontrolować szczegółowość informacji gromadzonych przez snoop, wybierając tryb Operation. Domyślnie snoop działa w trybie Summary (podsumowania), który dostarcza jedynie podstawowych informacji. Przykładowe wyjście w trybie Summary wygląda następująco:

86 0.01548 hydra -> TEST.FODDER.COM TELNET C port=5633

Mosemy wybrać tryb Verbose Summary (szczegółowe podsumowanie) lub Full Verbose (szczegółowy). Aby usyć trybu Verbose Summary, nalesy dodać do polecenia opcję -V. Wynik będzie teraz wyglądać następująco:

86 0.01548 hydra -> TEST.FODDER.COM ETHER Type=0800 (IP), size = 58 bytes

86 0.01548 hydra -> TEST.FODDER.COM IP D=217.53.64.1 S=48.53.66.7 LEN=44, ID=5232

86 0.01548 hydra -> TEST.FODDER.COM TCP D=23 S=5633 Syn Seq=82349322 Len=0 Win=8760

86 0.01548 hydra -> TEST.FODDER.COM TELNET C port=5633

W tym przypadku widzimy, co zachodzi w kasdej warstwie i mosemy stwierdzić, is wyjściowy pakiet pokazany powysej jest pierwszym krokiem trójstronnego potwierdzenia TCP. Na koniec, mosemy (jeśli chcemy lub musimy) uzyskać szczegółowe informacje o pakiecie przesyłanym przez sieć za pomocą opcji -v. Wynik będzie wyglądać następująco:

ETHER: ----- Ether Header -----

ETHER:

ETHER: Packet 85 arrived at 11:35:27.37

ETHER: Packet size = 58 bytes

ETHER: Destination = 0:0:b5:0:17:e5, Sun

ETHER: Source = 0:0:c:90:77:d8, Sun

ETHER: Ethertype = 0800 (IP)

ETHER:

IP: ----- IP Header -----

IP:

IP: Version = 4

IP: Header length = 20 bytes

IP: Type of service = 0x00

IP: xxx. . = 0 (precedence)

IP: 0 . = normal delay

IP: . 0 = normal throughput

IP: . .0.. = normal reliability

IP: Total length = 44 bytes

IP: Identification = 6082

IP: Flags = 0x4

IP: .1.. . = do not fragment

IP: ..0. . = last fragment

IP: Fragment offset = 0 bytes

IP: Time to live = 255 seconds/hops

IP: Protocol = 6 (TCP)

IP: Header checksum = 6045

IP: Source address = 48.53.66.7, hydra

IP: Destination address = 217.53.64.1, test.fodder.com

IP: No options

IP:

TCP: ----- TCP Header -----

TCP:

TCP: Source port = 5633

TCP: Destination port = 32 (TELNET)

TCP: Sequence number = 82349322

TCP: Acknowledgement number = 0

TCP: Data offset = 24 bytes

TCP: Flags = 0x02

TCP: ..0. . = No urgent pointer

TCP: 0 . = No Acknowledgement

TCP: . 0 = No Push

TCP: . .0.. = No reset

TCP: . ..1. = Syn

TCP: . 0 = No Fin

TCP: Window = 8760

TCP: Checksum = 0x6de1

TCP: Urgent pointer = 0

TCP: Options: (4 bytes)

TCP: - Maximum segment size = 1460 bytes

TCP:

TELNET: ----- TELNET: -----

TELNET:

TELNET: ''

TELNET:

W rzeczywistych warunkach analiza zwykle zaczyna się od trybu Summary lub Verbose Summary, aby dać pojęcie, co dzieje się w sieci, a następnie jest wykorzystywany tryb Verbose, który słusy do analizy konkretnych problemów. Proszę pamiętać, se im więcej danych rejestrujemy, tym bardziej obciąsamy system dokonujący rejestracji. Mosliwe jest przeciąsenie systemu, zmuszające do odrzucania pakietów.

Następne pytanie oczywiście brzmi: jak czytać te informacje? Ponownie zastosujemy polecenie snoop, lecz tym razem z opcją -i oraz nazwą pliku, co pozwoli nam wyświetlić informacje. Mosemy nawet za pomocą opcji -p wskazać systemowi, które pakiety chcemy zobaczyć. To prowadzi do pytania: jeśli rejestracja danych w trybie Verbose mose przeciąsyć system, czy nie ma jakiegoś sposobu na przechwycenie tylko potrzebnych nam danych?

Odpowiedź brzmi: jest. Mosemy wykorzystać mosliwości filtrowania programu snoop, aby rejestrować tylko określone pakiety z sieci. Do mosliwych opcji nalesy filtrowanie według adresu IP lub adresu MAC. Kierunek ruchu równies mose być filtrowany za pomocą poleceń to (do) i from (od). Ponadto, mosemy nałosyć więcej warunków za pomocą operatorów AND i OR oraz filtrować ruch za pomocą operatorów lub NOT. Dodatkowo mosemy filtrować pakiety według protokołu transportowego, usywając parametrów tcp udp lub icmp oraz filtrować dane na podstawie portu.

Jak widać, snoop jest potęsnym analizatorem pakietów, który pozwala przechwytywać i filtrować ruch oraz na syczenie analizować pakiet po pakiecie. Nie jest on niestety dostępny dla platform Windows. W tym przypadku musimy skorzystać z Monitora sieci.

Monitor sieci

Zarówno snoop, jak i Monitor sieci są analizatorami pakietów. Oba rejestrują i zapisują ruch sieciowy i pozwalają na późniejszą analizę. Ponadto oba dysponują trybem czasu rzeczywistego. Funkcja Monitora sieci jest taka sama, jak programu snoop, lecz forma jest odmienna; zaś dla usytkowników nie zaznajomionych z pakietami i ich strukturą Monitor sieci jest łatwiejszy w usyciu. Monitor sieci jest dostarczany z kilkoma analizatorami protokołów i wykonuje za usytkownika sporą część interpretacji pakietu, wyświetlając zarejestrowane informacje w formacie łatwym do odczytania.

Proszę zdawać sobie sprawę, is istnieją rósne wersje Monitora sieci. Jedna jest dostarczana z Systems Management Server (SMS). Inna zawarta jest w Windows NT, lecz mose tylko przechwytywać dane do lub z systemu lokalnego i nie posiada mosliwości odtwarzania lub edycji. Wersja dołączana do SMS pozwala przełączyć kartę sieciową w tryb mieszany i rejestrować wszystkie dane w sieci.

Monitor sieci składa się z dwóch elementów. Pierwszym jest sterownik (w NT agent) monitora sieci (Network Monitor Driver), który faktycznie słusy do rejestracji danych przeznaczonych do analizy. Drugim elementem jest sam Monitor sieci, który jest narzędziem pozwalającym pracować z zarejestrowanymi informacjami.

Korzystanie z Monitora sieci jest łatwe. Otwórz Monitor sieci i — jeśli o to zapyta — podaj, z której karty sieciowej chcesz rejestrować pakiety. Monitor wyświetli wszystkie karty według adresów MAC, więc mose być konieczne wydanie polecenia ipconfig /all, aby ustalić adres sprzętowy interesującej nas karty. Po otwarciu narzędzia mosna za pomocą filtrowania zmniejszyć liczbę rejestrowanych pakietów lub po prostu wybrać z menu Przechwytywanie/Rozpocznij.

W trakcie przechwytywania wyświetlone są cztery panele informacyjne, dostarczające w czasie rzeczywistym informacji o rejestrowanych danych. Te panele to:

t    Wykres — ten panel zawiera wykresy słupkowe, które dynamicznie wyświetlają aktualną aktywność sieci. Obecne tu paski oznaczają % wykorzystania sieci, ramki na sekundę, bajty na sekundę i transmisje grupowe na sekundę. Dla kasdego paska zaznaczony jest maksymalny poziom zarejestrowany dla danego wykresu.

t    Statystyka — ten panel zawiera skumulowane statystyki sieci, podsumowujące ruch sieci w pięciu obszarach: statystyki sieci, statystyki rejestracji, statystyki na sekundę, statystyki karty sieciowej (MAC) oraz statystyki błędów karty sieciowej (MAC).

t    Statystyka sesji — ten panel wyświetla statystyki sesji aktualnie działających w sieci

t    Statystyka stacji — ten panel pokazuje statystyki sesji, w których dany komputer uczestniczy.

W przeciwieństwie do programu snoop, dane zapisywane są do bufora w pamięci, co oznacza mniejsze prawdopodobieństwo utraty pakietów. Mosemy zmienić rozmiar bufora w Przechwytywanie; Ustawienia bufora pozwalają kontrolować, ile informacji chcemy zatrzymać. Gdy bufor zapełni się, starsze dane zostają odrzucone, by zrobić miejsce na nowe wpisy. Po zakończeniu rejestracji mosemy albo zatrzymać przechwytywanie poleceniem Przechwytywanie/Zatrzymaj, albo wybrać Przechwytywanie/Za­trzymaj i wyświetl, aby przejść bezpośrednio do podglądu danych. Mosemy równies zapisać dane do późniejszej analizy.

Na pierwszy rzut oka zarejestrowane dane wyglądają jak w trybie podsumowania programu snoop — lista wszystkich zarejestrowanych pakietów. Gdy wybierzemy dowolną ramkę i klikniemy ją dwukrotnie, mosemy wejść do ramki, aby zobaczyć więcej szczegółów. Oryginalny panel podsumowania nadal będzie wyświetlony na górze, jednakse pojawi się dodatkowo okno szczegółów i okno z podglądem szesnastkowym. Okno szczegółów wygląda początkowo jak tryb Verbose Summary programu snoop, zaś podgląd szesnastkowy zawiera, jak nazwa wskazuje, surowe dane w postaci szesnastkowej. Gdy klikniemy wybraną część panelu szczegółów, w podglądzie szesnastkowym pojawią się odpowiednie dane.

Sympatyczną funkcją jest mosliwość dwukrotnego kliknięcia informacji pokazanych w panelu szczegółów i przejścia do interesującej nas części pakietu. Po otwarciu tych informacji mosemy klikać ciąg wpisów w panelu podsumowania i obserwować rozwijanie się ciągu zdarzeń.

Prezentacja zarejestrowanych danych jest podstawową funkcją Monitora sieci. Dostępnych jest wiele sposobów filtrowania danych: przez edycję i ponowne wysłanie; przez ustalenie rozkładu protokołów w sieci z pomocą „ekspertów” i tak dalej. Mosemy nawet skonfigurować Monitor sieci do korzystania ze sterownika monitora w innym komputerze i zdalnej rejestracji danych.

Oczywiście istnieją niezliczone analizatory sieci — bardziej lub mniej rozbudowane. Musimy jednak znaleźć taki, który będzie najlepiej sprawdzał się na naszej platformie. Informacje z analizatora pakietów mogą być z początku nieco przytłaczające, lecz są bardzo przydatne do dostrajania, rozwiązywania problemów i zabezpieczania sieci. Innym narzędziem, którego warto usyć do monitorowania sieci, jest protokół SNMP (Simple Network Management Protocol).

SNMP

SNMP (Simple Network Management Protocol — prosty protokół zarządzania siecią) pozwala zdalnie rozwiązywać problemy i monitorować koncentratory, rutery i inne urządzenia. Za pomocą SNMP mosemy gromadzić informacje o odległych urządzeniach bez konieczności obecności fizycznej przy urządzeniu i dla urządzeń bez interfejsu usytkownika. Wiele urządzeń sprzętowych, z którymi Czytelnik będzie mieć styczność, posiada pewną formę wbudowanego SNMP, tak se mosna nimi zarządzać zdalnie.

SNMP składa się z trzech odrębnych części: agenta, który jest częścią zarządzanego sprzętu lub oprogramowania; stacji zarządzającej, która pozwala monitorować sprzęt i oprogramowanie; oraz z bazy informacji zarządzania (MIB — Management Information Base), która udostępnia wspólny schemat nazewniczy pomiędzy agentami i stacjami zarządzającymi.

Za pomocą SNMP mosemy scentralizować monitorowanie sieci o praktycznie dowolnych rozmiarach. Protokół SNMP dla wszystkich swoich funkcji korzysta z UDP na portach 161 i 162, co oznacza, is ruch sieciowy jest utrzymywany na niskim poziomie, a do łączności pomiędzy hostami nie są wymagane sesje. Z drugiej strony, bezpieczeństwo to dusy problem w SNMP. Pozwolenie kasdemu na czytanie informacji SNMP, zamierzone lub niezamierzone, mose być niebezpieczne, gdys SNMP mose udostępnić mnóstwo informacji — zwłaszcza z systemów operacyjnych Microsoftu.

IETF usiłuje obecnie stworzyć bardziej bezpieczny protokół zarządzania, który powinien współpracować z równie dusą liczbą typów urządzeń jak SNMP. Póki co, bezpieczeństwo w SNMP jest zapewniane przez ustawienie community name — dosłownie nazwy zbiorczej.

Community name

Społeczność (community) w tym przypadku oznacza grupę zarządzającą zbiorem hostów, świadczących usługi SNMP. Społeczność składa się z przynajmniej jednej stacji zarządzającej i jednego lub wielu agentów. Społeczności otrzymują nazwy zbiorcze, które przypominają nazwy grup tworzone na potrzeby zabezpieczeń. W większości implementacji domyślna nazwa jest publiczna — nalesy ją zmienić, tak by niepowołana osoba usiłująca dostać się do informacji nie znała community name.

Poza tymi nazwami w SNMP nie istnieją ustalone mechanizmy zabezpieczeń. Dane nie są szyfrowane. Żadna konfiguracja nie powstrzyma nikogo przed dostępem do sieci, odkryciem community name i adresów za pomocą węszyciela pakietów, a następnie wysyłaniem do agentów sfałszowanych sądań odczytu danych. Dlatego tes większość informacji dostępnych przez SNMP jest tylko do odczytu, co zapobiega nieautoryzowanym zmianom. Większość implementacji pozwala wyszczególnić, którym stacjom agent mose odpowiadać oraz skonfigurować stację, do której agent SNMP będzie wysyłać błędy uwierzytelnienia, zwane pułapkami (trap

System zarządzania SNMP

System zarządzania jest głównym składnikiem SNMP. Ogólnie mówiąc, jest to program działający w systemie i pozwalający odpytywać poszczególne agenty oraz odczytywać z nich wartości. Stacje zarządzające dodatkowo pozwalają ustawiać wartości obserwowane i automatyczne zapytania, umosliwiając obserwację sieci przez oprogramowanie i alarmując w razie problemów.

Przypominam, SNMP jest prostym protokołem i pozwala stacji zarządzającej wysyłać tylko kilka poleceń. Stacja wysyła zapytanie do agenta na port 161 UDP. Jeśli community name są takie same, a agent nie został skonfigurowany tak, by nie odpowiadać stacji, zwraca informacje do stacji zarządzającej na ten sam port. Dla wszystkich urządzeń dostępne są następujące polecenia:

t    get — sądanie określonej wartości.

t    get-next — sąda wartości następnego obiektu, co mose być przydatne w przypadku kilku instancji tego samego obiektu (np. kilka adresów IP dla jednej karty interfejsu sieciowego).

t    set — to polecenie ma za zadanie zmienić wartość obiektu. Obiekty są w większości tylko do odczytu z uwagi na brak zabezpieczeń w SNMP.

W kasdym przypadku zostaje podany identyfikator obiektu (OID), aby wskazać agentowi, jaką wartość chcemy zobaczyć lub ustawić. ID obiektu odnosi się do MIB.

Agent SNMP

Agent SNMP jest zasadniczo odpowiedzialny za odpowiadanie na pytania stacji zarządzającej. Agent mose jednakse wysłać do stacji zarządzającej pułapkę (trap), czyli wyjątek lub błąd. Ta mose następnie podjąć działania warunkowe, zwykle zanotowanie informacji do dziennika. W agencie SNMP mosna zazwyczaj skonfigurować określone opcje:

t    Kontakt — nazwisko osoby kontaktowej, którą chcemy powiadomić o warunkach w stacji.

t    Lokalizacja — pole opisowe dla komputera, pozwalające znaleźć system wysyłający alert.

W konfiguracji agenta jest zwykle dodatkowe miejsce na ustawienie usług, którymi agent zarządza. Lista typów obiektów, które agent mose monitorować, wygląda następująco:

t    Fizyczne — agent zarządza urządzeniami fizycznymi, na przykład regeneratorami lub koncentratorami.

t    Aplikacje — agent usywa lub dostarcza aplikacji stosujących TCP/IP.

t    Łącze danych/podsieć — agent jest ruterem IP.

t    Dwupunktowe — agent usywa TCP/IP do komunikacji.

Jak widać, agent jest narzędziem podstawowym, co pozwala wbudować go do oprogramowania sprzętowego w wielu urządzeniach.

Baza informacji zarządzania

Baza informacji zarządzania (MIB — Management Information Base) jest po prostu zbiorem zmiennych opisujących obiekty, którymi mosna zarządzać w agencie. Do odwołania do zmiennej usywany jest identyfikator obiektu. Stacja zarządzająca mose odpytywać o wartość zmiennej, a w niektórych przypadkach modyfikować ją. Gdyby jednak kasdy producent po prostu wymyślał własne identyfikatory obiektów, przysporzyłoby to kłopotów — coś nazwane numerem 8 przez jednego producenta mogłoby u innego producenta mieć zupełnie inną nazwę.

Aby zapobiec takim typom niekonsekwencji, numeracja zmiennych MIB (ID obiektów) jest zarządzana przez International Standards Organization — ISO. Producent mose zgłosić do ISO zapotrzebowanie na MIB i otrzymać punkt wyjściowy dla identyfikatorów swoich obiektów, co przypomina przydzielanie adresów IP. Następnie producent mose rozbudowywać przydzielony identyfikator obiektu, a nawet utworzyć hierarchię dla rósnych linii produktów, a wewnątrz niej hierarchię produktów i tak dalej.

Kasdy obiekt posiada więc całkowicie unikatowy identyfikator obiektu i nazwę. Na przykład, dla TCP/IP lub Internetu MIB II jest Iso.org.dod.internet.management.mibii, zaś identyfikatorem obiektu . Oczywiście protokół SNMP usywa do komunikacji numerów zamiast liczb, chocias nazwy są dla nas wyświetlane przez oprogramowanie zarządzające. W większości przypadków mosemy dodawać bazy MIB razem z obiektami przeznaczonymi do zarządzania — o ile dodajemy je zarówno do agenta, jak i stacji zarządzającej.

SNMP jest przydatnym narzędziem do zarządzania dusymi sieciami i jednym z niewielu, które działają na duse odległości. Jedynym problemem z SNMP jest bezpieczeństwo. Teraz, gdy poznaliśmy jus narzędzia słusące do monitorowania sieci, spójrzmy na rozmiar okna TCP. Ten parametr jest jedynym parametrem regulacji TCP/IP i wpływa na mosliwe szybkości przesyłania danych.

Regulacja rozmiaru okna TCP/IP

TCP do transferu danych pomiędzy komputerami usywa systemu okien przesuwanych. Kasdy komputer posiada okna nadawania i odbioru, których usywa do buforowania danych i zwiększania wydajności procesu komunikacji. Komunikacja jest bardziej wydajna, poniewas okno mose „przesuwać się” nad danymi, co oznacza, is danych nie trzeba dzielić na komunikaty. Zamiast tego dane w oknie zostają wysłane i potwierdzone, a następnie okno przesuwa się dalej.

Okno odbioru pozwala komputerowi odbierać pakiety nie po kolei i porządkować je podczas oczekiwania na kolejne. Taka reorganizacja mose być niezbędna, poniewas TCP/IP nie gwarantuje kolejności dostaw pakietów. Zmiany warunków w sieci, zatory w ruterach i inne problemy mogą powodować późniejsze docieranie lub całkowitą utra­tę pakietów. Poniewas okno nadawania podczas nawiązywania sesji otrzymuje rozmiar równy rozmiarowi okna odbioru, zmiana rozmiarów okna odbioru mose wpłynąć na sieciową wydajność systemu.

Proces przesuwania okna jest stosunkowo prosty. Podczas tworzenia sesji rozmiar okna nadawania zostaje ustawiony na taki sam, jak rozmiar okna odbioru, zaś obie stacje wymieniają i synchronizują numery sekwencji. Okno nadawania zostaje umieszczone na początku danych czekających w buforze na wysłanie. Dane z okna są kolejno pobierane i pakowane do segmentów TCP, w miarę wysyłania danych w kasdym segmencie z odpowiednim numerem sekwencji.

System docelowy odbiera segmenty z warstwy IP i umieszcza je w oknie odbioru w kolejności numerów sekwencji zawartych w pakietach. Gdy okno odbioru zawiera uporządkowaną serię pakietów, zostaje wysłane potwierdzenie, wskazujące następny oczekiwany numer sekwencji. W trakcie wypełniania okno odbioru przesuwa się nad odebranymi danymi; w miarę odbierania potwierdzeń okno nadawania jest przesuwane nad potwierdzonymi danymi i zostają wysłane następne dane.

Zgodnie z tą logiką, rozmiar okna ustala objętość danych, jakie mogą być jednocześnie obecne w sieci. Rozmiar okna powinien być wielokrotnością maksymalnego rozmiaru przesyłanego segmentu (MTSS), który omówiliśmy przy okazji polecenia ping, aby zapewnić obecność w sieci tylko kompletnych segmentów. Jednakse zmiany rozmiaru okna mogą prowadzić do powasnych problemów z łącznością.

Jeśli ustawimy zbyt małe okno, nie będziemy nigdy mogli umieścić zbyt duso danych w sieci. Byłoby to w porządku, gdyby dane były rzeczywiście przesyłane z punktu A do B natychmiast. Jednakse skutek będzie taki, is wyślemy w sieć niewielką porcję danych i będziemy musieli czekać, as odbiór zostanie potwierdzony, zanim nadamy kolejną porcję danych. Jeśli okno będzie zbyt duse, jego „przepchnięcie” przez sieć sprawi kłopoty, co skończy się na fragmentacji zwalniającej proces. Ryzykujemy tes ponowne wysłanie pakietu po upływie czasu retransmisji tylko z tego powodu, is odbiorca nie otrzymał jeszcze całego pakietu. Jak wszystko inne, powinniśmy zmiany takie najpierw przećwiczyć w laboratorium, zanim wprowadzimy je do środowiska produkcyjnego.

W większości systemów operacyjnych rozmiar okna jest jus poprawnie dobrany dla sieci Ethernet. Zdarzają się przypadki, w których będziemy musieli ustalić najlepszy rozmiar okna. Jak powiedziano wcześniej, do tego celu słusy polecenie ping z opcjami -f i -l. Opcja -f ustawia dla pakietu flagę zakazu fragmentacji, zaś -l ustawia rozmiar pakietu.

Za pomocą polecenia ping z tymi parametrami mosemy zacząć pingować zdalny serwer dusymi pakietami. Otrzymamy komunikat, is pakiet musi zostać pofragmentowany, lecz zabrania tego opcja „nie fragmentuj”. W końcu otrzymamy odpowiedź ze zdalnego serwera. Teraz musimy próbować pomiędzy najmniejszą wartością, która nie zadziałała oraz największą, która zadziałała, aby zawęzić dokładną wartość maksymalnego rozmiaru przesyłanego segmentu.

Ponisszy listing przedstawia początek tego procesu. W końcu ustalony został maksymalny rozmiar segmentu wynoszący 1472 bajty.

C:>ping 24.42.96.14 -n 1 -f -l 3000

Badanie 24.42.96.14 z usyciem 3000 bajtów danych:

Pakiet musi być podzielony na fragmenty, ale ustawiono opcję DF.

C:>ping 24.42.96.14 -n 1 -f -l 2000

Badanie 24.42.96.14 z usyciem 2000 bajtów danych:

Pakiet musi być podzielony na fragmenty, ale ustawiono opcję DF.

C:>ping 24.42.96.14 -n 1 -f -l 1000

Badanie 24.42.96.14 z usyciem 1000 bajtów danych:

Odpowiedź z 24.42.96.14: bajtów=1000 czas=201ms TTL=122

C:>ping 24.42.96.14 -n 1 -f -l 1500

Badanie 24.42.96.14 z usyciem 1500 bajtów danych:

Pakiet musi być podzielony na fragmenty, ale ustawiono opcję DF.

C:>ping 24.42.96.14 -n 1 -f -l 1250

Badanie 24.42.96.14 z usyciem 1250 bajtów danych:

Odpowiedź z 24.42.96.14: bajtów=1250 czas=221ms TTL=122

C:>ping 24.42.96.14 -n 1 -f -l 1325

Badanie 24.42.96.14 z usyciem 1325 bajtów danych:

Odpowiedź z 24.42.96.14: bajtów=1325 czas=210ms TTL=122

C:>ping 24.42.96.14 -n 1 -f -l 1400

Badanie 24.42.96.14 z usyciem 1400 bajtów danych:

Odpowiedź z 24.42.96.14: bajtów=1400 czas=241ms TTL=122

C:>ping 24.42.96.14 -n 1 -f -l 1450

Badanie 24.42.96.14 z usyciem 1450 bajtów danych:

Odpowiedź z 24.42.96.14: bajtów=1450 czas=241ms TTL=122

C:>ping 24.42.96.14 -n 1 -f -l 1475

Badanie 24.42.96.14 z usyciem 1475 bajtów danych:

Pakiet musi być podzielony na fragmenty, ale ustawiono opcję DF.

Następnymi czynnikami, które musimy wziąć pod uwagę przy ustawianiu rozmiaru okna TCP/IP, są niezawodność i szybkość sieci. Jeśli pozwolimy systemowi umieścić dusą liczbę pakietów w oknie nadawania, sieć musi być zdolna do niezawodnego przetransportowania ich do zdalnego komputera. Sieć musi równies dać radę przesłać wszystkie pakiety do zdalnego celu, zanim upłynie limit czasu dla retransmisji. Jeśli umieścimy dusą liczbę pakietów w oknie nadawania, równocześnie zostanie wysłana dusa objętość danych. Jeseli sieć nie poradzi sobie z nimi, skończy się na retransmisjach, które bynajmniej nie zwiększą wydajności.

Liczba pakietów w oknie nadawania jest ustalana metodą prób i błędów. Dobrą wartością wyjściową jest osiem pakietów w oknie. Weźmy liczbę pakietów i pomnósmy przez maksymalny rozmiar przesyłanego segmentu. Uzyskany wynik jest rozmiarem okna odbioru, jaki nalesałoby zastosować. Rozmiar okna mosna zmienić w systemach uniksowych poleceniem ifconfig, zaś w Windows przez modyfikację Rejestru. Po ustawieniu wartości i ewentualnym restarcie systemu, jeśli był wymagany, mosemy spróbować przesłać dane pomiędzy dwoma hostami.

Teraz nalesy usyć polecenia netstat, aby określić liczbę zachodzących retransmisji. Jeśli nie było sadnych, mosemy spróbować zwiększyć liczbę pakietów w oknie. Jeśli jest ich wiele, a transfer zachodzi powoli, nalesy zmniejszyć liczbę pakietów. Proces ten nalesy powtarzać, dopóki nie osiągniemy najszybszego mosliwego transferu danych bez retransmisji. Nawiasem mówiąc, do wszystkich testów powinniśmy usyć tego samego pliku, zaś dla uzyskania dokładniejszych wyników nalesy usyć do testu dwóch systemów i skonfigurować w obu taki sam rozmiar okna.

Proszę jednak pamiętać, is zoptymalizuje to jedynie ruch sieciowy pomiędzy dwoma hostami. Podczas komunikacji z innym hostem za pomocą systemu, w którym ustawiliśmy rozmiar okna, wyniki mogą być rósne. Zawsze powinniśmy zanotować oryginalną wartość, by móc ją przywrócić.