W tym dodatku zamieszczono kilka podstawowych zrzutów ekranów działania narzędzia Microsoft Network Monitor (NetMon). Wersja o pełnych możliwościach, pozwalająca na rejestrację ruchu pakietów wysyłanych i odbieranych przez dowolny komputer w sieci, zawarta jest w Systems Management Server (SMS). Wersja o bardziej ograniczonej funkcjonalności, dostarczana z Windows 2000, pozwala na śledzenie ruchu pakietów przychodzących i wysyłanych z komputera, na którym jest uruchomiona.
NetMon posiada podstawowe możliwości rejestracji i dekodowania pakietów. Rysunki przedstawione w tym dodatku przedstawiają sekcje nagłówków pakietów zarejestrowanych w serwerze nazw dla kilku zapytań DNS zgłoszonych za pomocą programu nslookup.
Rysunek E.1 przedstawia wysłane pytanie dotyczące reston.va.us. Listing informacji zawartych w nagłówku przedstawia po kolei właściwości ramki, Ethernet, nagłówki pakietu protokołu internetowego IP, protokołu datagramów użytkownika UDP i w końcu informacje usługi DNS. Zaznaczona linia przedstawia pytanie w pakiecie DNS.
Rys. E.1 Pakiet zapytania DNS widziany w programie NetMon
Zgodnie z wyświetlonymi informacjami pakiet można zidentyfikować jako zapytanie DNS o adres hosta klasy Internet dla reston.va.us. Górna ramka przedstawia zarejestrowane pakiety w kolejności chronologicznej. Szczegóły pakietu zaznaczonego w górnej ramce wyświetlone są w ramce dolnej. Kolejny poziom widoku pakietu na poziomie liczb szesnastkowych nie został tutaj pokazany. Jeśli spojrzeć na górne okno, wyświetlona lista zaczyna się od dwóch pakietów, których protokołem jest DNS. Pierwszy jest zapytaniem wysłanym przez nslookup do serwera o nazwie DC1, a następny, wyświetlony za szczegółami, wynikowym zapytaniem wysłanym przez serwer DNS w hoście DC1, który działa rekurencyjnie w celu rozwiązania zapytania [zgłoszonego przez] nslookup. Szczegóły obu pakietów są niemal identyczne.
Rysunek E.2 przedstawia odesłany pakiet z odpowiedzią na zapytanie. Analizując linie odpowiedzi DNS-u w pierwszej kolejności należy stwierdzić, że reston.va.us został rozwiązany poprzez rekord adresu (A) zawierający adres IP.
W górnej ramce rysunku można zauważyć, że wyświetlony pakiet został odebrany przez DC1 z tego samego hosta do którego wysłano zapytanie DNS. Następnie, kolejny pakiet DNS wysyłany jest z DC1 z odpowiedzią do systemu z którego pochodzi zapytanie nslookup. Jednakże, przyglądając się szczegółom można zauważyć w pakiecie odpowiedzi, że z reston.va.us związany jest nie tylko rekord A. Na tym samym poziomie co Answer Section (sekcja odpowiedzi) znajduje się Authority Section (sekcja pełnomocnictwa) oraz Aditional Records Section (sekcja dodatkowych rekordów). Rysunek E.3 przedstawia ten sam pakiet, w którym te dodane sekcje zostały częściowo rozwinięte.
Rys. E.2 Ślad odpowiedzi na zapytanie DNS w programie NetMon
Rys. E.3 Informacje o rekordach zasobów DNS w pakiecie z odpowiedzią DNS-u
Sekcja pełnomocnictwa wskazuje, że nazwa reston.va.us została również znaleziona w trzech rekordach NS. Pierwszy z nich został rozwinięty aby pokazać serwer DNS który rekord ten oddelegowuje w domenie reston.va.us. Następnie, w sekcji rekordów dodatkowych, rozwinięty został odpowiadający mu rekord A aby pokazać, że adres IP do wykorzystania w dalszych zapytaniach został zawarty w odpowiedzi.
W tym przykładzie ustawienia nslookup kazały pytać o rekordy dowolnego typu (type=any), wobec czego zwrócone zostały również rekordy A i NS z nazwą reston.va.us.
Przy aktywowanym wyszukiwaniu w usłudze WINS serwer DNS może odpytywać o hosty zarejestrowane w tej usłudze i jeśli takie istnieją, zgłaszać je jako członków domeny internetowej obsługiwanej przez serwer nazw. Proszę przypomnieć sobie że w domenach, w których aktywne jest rozwiązywanie przez usługę WINS, wszelkie nazwy NetBIOS-u w bazie danych WINS są rozwiązywane przez DNS, jakby były reprezentowane przez rekordy A. Z tego powodu jedna nazwa NetBIOS potencjalnie może być rozwiązana na szereg nazw pełnych złożonych (FQDN), jeśli rekord WINS zostanie użyty w strefie zawierającej wiele domen DNS.
W stosunku do programu NetMon w wersji 1.1, dostarczanej z Windows NT 4, w wersji 2.1 dostarczanej z Windows 2000 wprowadzono pewne zmiany. Z powodu pewnych niejasności powodowanych sposobem przedstawiania pakietów przez program NetMon w Windows NT 4 najpierw przyjrzymy się rysunkowi E.4 oraz E.5 w wersji śladu NetMon 1.1. Rysunek E.4 przedstawia zapytanie o adres hosta przekazywane z serwera DNS do serwera WINS.
Rys. E.4 Ślad odpytywania przez DNS usługi WINS w Windows NT 4.0 przedstawiony w NetMon 1.1
Zapytanie to zawiera kilka ciekawych szczegółów. Pierwszym jest linia nagłówka UDP, w którym portem źródłowym jest 53 (standardowy DNS), lecz portem przeznaczenia 137 (usługa nazewnicza NetBIOS).
Drugim ciekawym detalem jest zakodowanie nazwy, której dotyczy zapytanie, w postaci jakiegoś łańcucha alfanumerycznego i jej typ - “Unknown” (nieznany). Stanowi to najwyraźniej problem. Microsoft przyznał jego istnienie w artykule Knowledge Base Q160828, Network Monitor Parses DNS WINS Lookup Queries as DNS Packets. W artykule napisano: “... w kolumnie protokołu podany będzie DNS nawet jeśli pakiet wysyłany do WINS będzie pakietem NetBT (NetBIOS przez TCP) wysłanym na port 137”.
Rysunek E.5 przedstawia odpowiedź na zapytanie, rozwiązane za pomocą usługi WINS. Ponownie w pakiecie DNS przesyłane są jakieś niestandardowe informacje. Ta sama nazwa zwracana jest z typem zasobu równym 20hex, co w standardowym DNS-ie oznacza kod nieznanego typu, zaś pole RDATA które standardowo zawierałoby adres IP jest nieobecne. Zamiast tego, pod nagłówkiem “Additional Resource Data” (dodatkowe dane zasobu) pojawia się ciąg liczb wyglądający trochę podobnie do adresu MAC.
Taka odpowiedź nie jest nazbyt przydatna i w sposób oczywisty pomiędzy serwerem DNS i WINS przesyłane są jakieś ukryte, nieudokumentowane dane. Problem w przypadku tego śladu polega na tym, że właściwie brak jest jakichkolwiek informacji o zachodzącym procesie.
Rys. E.5 Ślad odpowiedzi WINS na zapytanie DNS w Windows NT 4.0 przedstawiony w NetMon 1.1
Pytanie zostaje wysłane do serwera i wraca z odpowiedzią, lecz jak ktokolwiek mógłby się upewnić, że dane są poprawne? Przy okazji; ciąg liczb odsyłany z serwera WINS nie jest adresem MAC, co można stwierdzić żądając od stacji roboczej adresu MAC:
> arp -d machine.example.NET
Net to Media Tablee
Device IP Address Mask Flags Phys Addr
---- ------------------- --------------- ----- -----------------
ie0 machine.example.NET 255.255.255.255 00:20:af:f0:77:0e
Analizator pakietów programu NetMon 2.1 rozprowadzanego z Windows 2000 rozpoznał te pakiety, które zwykle trudno rozszyfrować za pomocą jakiegokolwiek innego narzędzia. Rysunek E.6 przedstawia wstępne zapytanie o komputer eof5.pc.example.local, wysłane do serwera DNS przez program nslookup.
W tym przypadku dla nazwy hosta brak rekordu A w strefie, lecz strefa zawiera rekord WINS. W wyniku serwer DNS wysyła do serwera WINS zapytanie o nazwę [niekwalifikowanego] hosta. W górnej ramce rysunku E.6 widać parę pakietów NBT (NetBT), po których następuje odpowiedź DNS na zapytanie. Rysunki E.7 i E.8 przestawiają te dwa pakiety NBT.
Rys. E.6 Ślad rekurencyjnego zapytania DNS przedstawiony przez program NetMon 2.1
Spoglądając na rysunek E.7 można stwierdzić że jest to normalne zapytanie o nazwę NetBIOS (skierowane na port 137 UDP). W dolnej części rysunku
Nie ma czegoś takiego jak Query Name w rysunku - może Question Name?
w linii Query Name (nazwa zapytania) że pierwsza etykieta została pobrana z oryginalnego zapytania DNS i uzupełniona do długości 15 znaków przed dodaniem znaku 0h, w wyniku czego zapytanie dotyczy nazwy NetBIOS.
Rys. E.7 Ślad przekazu zapytania o nazwę z DNS-u do usługi WINS w programie NetMon 2.1
Rysunek E.8 przedstawia normalną odpowiedź [z rozwiązaniem nazwy WINS zakończonym powodzeniem] dla jednoznacznej nazwy. Gdybyśmy spojrzeli na następny z ciągu czterech pakietów, z nagłówkiem “DNS 0x24 Std Qry Resp.”, zobaczylibyśmy całkowicie normalnie wyglądającą odpowiedź DNS odesłaną do resolwera nslookup który pierwotnie wysłał zapytanie.
Mimo pewnych niedociągnięć NetMon jest doskonałym narzędziem dla administratorów, ponieważ dekoduje i analizuje komunikaty SMB (Server Message Block - blok komunikatów serwera) i NBT, oraz analizuje komunikaty LDAP. Tak długo jak w sieci stosowane będą stare aplikacje, NetMon jest całkiem przydatnym narzędziem choćby dla samej analizy pakietów związanych z NetBIOS-em (traktowanych przez szereg narzędzi innych producentów jako nieznane).
Rys. E.8 Ślad odbioru odpowiedzi z WINS przez DNS w programie NetMon 2.1
paradoks24h