następny punkt » |
Zdalna identyfikacja systemu operacyjnego ma na celu ułatwienie późniejszego oddziaływania intruza na nasz system. Wiedza odnośnie zainstalowanego systemu pozwala mu poprawnie identyfikować wyniki niektórych technik skanowania. Pozwala również ograniczyć swoje działania jedynie do technik agresywnych, które mają szanse być skuteczne w stosunku do danego systemu. Jeżeli napastnik będzie wiedział, że atakowany system pracuje pod kontrolą systemu operacyjnego Solaris, to nie będzie stosował technik, których skuteczność ogranicza się jedynie do systemów Windows.
Poniżej przedstawiono klasyfikację typowych metod zdalnej identyfikacji systemów operacyjnych
Pozyskiwanie banerów (banner grabbing)
Najprostszą metodą jest połączenie się za pomocą programu telnet do usługi na zdalnej
maszynie i obejrzenie informacji wyświetlanej na powitanie. Są to banery informacyjne, często zawierające nazwę i wersję używanego oprogramowania jak również system operacyjny. Technika to ma jednak tą wadę, że administratorzy systemów często usuwają te informacje lub je zmieniają tak by wprowadzić skanującego w błąd. Nie jest to więc metoda dająca wiarygodne wyniki. Niektóre garnki miodu starają się w ten sposób przekonać intruza, że są bardzo ważnymi i zarazem źle skonfigurowanymi serwerami.
ftp> open ftp.netscape.com Connected to 207.200.85.53 (207.200.85.53)< 220 ftp.netscape.com FTP server (SunOS 5.8) ready Name (ftp.netscape.com:anonymous): anonymous 331 Guest login ok, send your complete e-mail address as password. Password: 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> SYST 215 UNIX Type: L8 Version SUNOS
[~]# telnet 192.168.9.130 Trying 192.168.9.130 ... Connected to potato. Escape character is '^]'. Debian GNU/Linux 2.2 potato login:
Analiza stosu TCP/IP
Ta metoda daje lepsze wyniki. Bazuje ona na spostrzeżeniu, że stos TCP/IP każdego systemu operacyjnego jest inaczej zaimplementowany. Różne są więc reakcje systemu na błędne pakiety, szczególnie nie zdefiniowane w dokumentach RFC. W takich przypadkach indywidualna interpretacja zaleceń RFC przez programistów tworzących systemy operacyjne pozwala na ustalenie rodzaju systemu na podstawie odpowiedzi maszyny
Analiza może być przeprowadzana w sposób pasywny lub aktywny. Pierwsza z nich polega na obserwowaniu normalnego zachowania się systemu, bez wysyłania do niego żadnych pakietów. Możliwa jest ona tylko wówczas, gdy skanujący znajduje się w tej samej domenie rozgłoszeniowej (jeszcze lepiej kolizyjnej) co skanowany host. Tak działa linuxowy program Ettercap. Najwięcej informacji dostarczają pakiety z początku połączenia z ustawioną flagą SYN. Pakiety takie różnią się w zależności od stosu TCP/IP z którego pochodzą między innymi wartościami w następujących polach:
Testy FIN
Pakiet z ustawioną flagą FIN (lub dowolny bez flagi SYN lub ACK) jest wysyłany na otwarty port. RFC793 zaleca w takim przypadku brak odpowiedzi. Niektóre implementacje stosu TCP/IP odpowiadają jednak pakietem RST. Należą do nich: Windows, BSDI, Cisco, HP-UX, MVS i IRIX. Metoda ta ma jednak wiele wad i przez to niewielkie zastosowanie.
Test z nieistniejącą flagą (Bogus Flag Probe Test)
Kolejny test to wysłanie pakietu z ustawioną nieistniejącą flagą. Najczęściej jest to wartość 64 lub 128 w nagłówku pakietu TCP w pakiecie SYN. Niektóre systemy po odebraniu takiego pakietu wysyłają pakiet RST. Linux na przykład odsyła pakiety z tą samą flagą.
Technika opracowana przez Thomasa H. Ptaceka z Secure Networks polega na wysyłaniu do skanowanego systemu pofragmentowanych pakietów i obserwacji zachowania systemu. Różne implementacje w różny sposób składają zdefragmentowane pakiety. Aby ustrzec się przed atakami DoS z dużą liczbą fragmentowanych pakietów systemy operacyjne mają wprowadzone różne ograniczenia co do wielkości pakietów, czasu ich odbioru i liczby.
Próbkowanie początkowego numeru sekwencyjnego (Initial Sequence Number)
Obserwując generowanie numerów ISN można zaobserwować pewne prawidłowości. Daje się je zaklasyfikować w czterech grupach:
Opcje TCP
Jedynymi opcjami zdefiniowanymi w oryginalnej specyfikacji TCP były:
Z czasem zdefiniowane zostały nowe opcje (RFC 1323), które nie są obsługiwane we wszystkich specyfikacjach, lub są obsługiwane błędnie. Do bardziej interesujących, a nie zaimplementowanych należą opcje pozwalające na selektywne potwierdzanie odebranych pakietów. TCP standardowo nie pozwala na selektywne potwierdzanie - potwierdzane są paczki pakietów (a jeszcze dokładniej liczba odebranych bajtów), tzn.: każde potwierdzenie mówi, że zostały odebrane wszystkie pakiety (wszystkie bajty) do konkretnego numeru sekwencyjnego.
Inne opcje zajmują się zagadnieniami związanymi ze skalowaniem okna w sieciach o dużej przepływności (sieci gigabitowe) oraz znacznikami czasu rzeczywistego przesyłanymi razem z pakietami.
Ze względu na to, że wiele systemów operacyjnych różnie obsługuje powyższe opcje lub nie obsługuje ich wcale możliwe jest na tej podstawie rozpoznanie systemu operacyjnego. Kiedy komputer otrzyma pakiet z włączonymi opcjami zobowiązany jest on w odpowiedzi przesłać listę opcji, które obsługuje. Jest to dodatkowa informacja dla skanującego. Dla przykładu: niemal każdy pakiet wysłany przez program nmap zawiera poniższe opcje:
Window Scale=10; NOP; Max Segment Size = 265; Timestamp; End of Ops;
Nawet kiedy zdalny system obsługuje pełen zestaw opcji (co samo w sobie jest informacją) można na podstawie odpowiedzi (np.: wysłanie ustawionej opcji MSS na konkretną wartość niektóre systemy odsyłają zmieniają, inne nie) dokonać rozróżnienia.
Czas retransmisji pakietów
Różnice w implementacji ICMP
Różnice implementacji ICMP pozwalają z dużą dokładnością ustalić system operacyjny. Najprostszym sposobem jest wysłanie pakietu ICMP Echo request na adres rozgłoszeniowy sieci. Pakiet ten jest ignorowany przez niektóre systemy, np.: Windows, co jest informacją samą w sobie. Badać można również funkcję limitowania liczby pakietów ICMP zwracających informację błędach. Wiele systemów ma wprowadzone ograniczenia
Można również badać implementację pod kontem nieuwzględnienia niektórych funkcji protokołu ICMP. Na przykład niektóre komunikaty, rzadko wykorzystywane nie są zaimplementowane.
ICMP Error Message Quoting Size (rozmiar cytowanych błędów)
Każdy datagram ICMP zawiera nagłówek IP pakietu, który wywołał błąd wraz z co najmniej ośmioma bajtami. Pakiet, który wywołał błąd nazywany jest datagramem obrażającym (ang: offending datagram). Więcej niż 8 bajtów może jednak zostać wysłane według RFC 1122. Systemy takie jak Linux (kernel 2.0.x, 2.2.x, 2.4.x), Sun Solaris 2.x, HPUX 11.x, MacOS 7.x-9.x, Foundry Switches (oraz kilka innych urządzeń sieciowych) to tylko niektóre z przykładów.
ICMP Error Message Echoing Integrity (test integralności odpowiedzi ICMP)
Niektóre systemy operacyjne nie zwracają poprawnie kilku specyficznych pól nagłówka. Pozwala to na szybszą analizę oraz ustalenie rodzaju zdalnego systemu.
Bardzo popularnym programem do zdalnego ustalania rodzaju systemu operacyjnego jest narzędzie napisane przez Ofir'a Arkin'a - Xprobe. Działa ono pod Linux'em. Xprobe pozwala za pomocą maksymalnie czterech pakietów ICMP ustalić z dużą dokładnością zdalny system operacyjny
Xprobe nie wysyła uszkodzonych lub nietypowych pakietów ICMP, dzięki czemu istnieje duża szansa, że skanowanie umknie uwadze systemów IDS zaszyte w normalnym ruchu sieci. Ponadto komputery z zainstalowaną prywatną ścianą ogniową przepuszczającą pingi są poprawnie identyfikowane. Xprobe pozwala skrócić fazę analizy zdalnego systemu, ponieważ dwie fazy - sprawdzanie, czy zdalna maszyna jest włączona, oraz druga, identyfikacja systemu operacyjnego - są połączone.
Dwa przykładowe drzewa wnioskowania opracowane przez Arkina zamieszczono poniżej.
Przykład 1
Przykład 2
następny punkt » |