Zaawansowane techniki wykrywania komputerów w sieci
Ogólnie
Specjaliści od zabezpieczeń spędzają wiele czasu, usiłując blokować i filtrować niepoprawne pakiety w środowisku sieciowym. Zaawansowane wykrywanie komputerów w sieci oszukuje wiele systemów detekcji intruzów (IDS), filtrów i routerów, szczególnie poprzez umożliwienie atakującemu mapowania i odkrywania nieznanych wcześniej komputerów znajdujących się za zaporą ogniową
Wprowadzenie
Ten dokument jest próbą opisania technik używanych do wykrywania silnie filtrowanych i chronionych zaporami ogniowymi komputerów w sieci, które nie odpowiadają na standardowe komendy PING. Zakładam, że czytelnik ma wiedzę na temat protokołów w Internecie (TCP, IP, UDP, ICMP). Inne protokoły nie będą omawiane, jednak techniki opisywane tutaj odnoszą się do wielu z nich.
Metody wykrywania komputerów w sieci
Coraz częściej stosowanym rozwiązaniem staje się podłączenie komputerów do Internetu, chronionych przy tym zaporami ogniowymi. Odpowiednio skonfigurowane i zabezpieczone wewnątrz sieci komputery często nie odpowiadają na próby wykrycia ich aktywności. Podstawowym przykładem takiej sytuacji jest standardowe polecenie PING. Wysyła ono zapytanie ICMP typu 8 (prośbę o odpowiedź) do dowolnego komputera w sieci, aby sprawdzić jego stan podłączenia.
Jednak z powodu zwiększającej się ilości serwerów blokujących wszelkie formy ICMP, odpowiedź zazwyczaj jest blokowana lub odrzucana, a zatem nie dojdzie do adresata.
Klient może wtedy przypuszczać, że sieć (komputer) jest wyłączony lub silnie zabezpieczony.
Jak dokładnie można określić aktywną obecność komputera w sieci?
Zrozumienie sposobów zabezpieczeń i pewnych ustawień zapór ogniowych umożliwi klientowi wykrycie podłączenia komputera do sieci lub jego ukrycie przez ścianę ogniową. Technika ta znana jest jako "Host Detection".
"Host detection", czyli wykrywanie komputerów w sieci, jest podobne pod wieloma względami do skanowania, jednak wykrywanie komputerów nie sprawdza istnienia otwartych portów lub modyfikacji danych, właściwych dla nagłówków protokołów, np. ustawień odpowiedzi na pakiety oflagowane. Wykrywanie sprawdza raczej każdą możliwą oznakę odpowiedzi, wysłaną ze zdalnego komputera. W tym rozumieniu, wykrywanie komputerów w sieci jest rodzajem skanowania PING, które wykrywa każdą formę odpowiedzi, oznaczającą stan podłączenia serwera do sieci. Ten dokument analizuje dwie techniki wykrywania komputerów "PING sweep", które mogą zostać wykorzystane w środowisku sieciowym do zaawansowanego wykrywania komputerów:
uzyskiwanie poprawnych odpowiedzi protokołów,
generowanie nieprawidłowych odpowiedzi protokołów po stronie serwera.
Pierwsza metoda oznacza uzyskiwanie poprawnych odpowiedzi przez obsługiwane na danym komputerze protokoły. Każde poprawne żądanie klienta wysłane do serwera za pomocą TCP/IP/UDP/ICMP, które wymaga odpowiedzi, jest kwalifikowane do tej metody. Takie metody zawierają:
UDP Echo
TCP Echo
UDP Closed Ports
TCP ACK
TCP SYN
TCP SYN|ACK
TCP FIN
TCP NULL FLAGS
TCP XMAS
ICMP Echo Request (Type 8)
ICMP Broadcast
ICMP Router Solicitation (Type 10)
ICMP Timestamp Request (Type 13)
ICMP Information Request (Type 15)
ICMP Address Mask Request (Type 17)
Oprócz odpowiedzi zgodnych z RFC, istnieją jeszcze metody generowania nieprawidłowych odpowiedzi z komputera docelowego, aby określić jego ukryte istnienie w sieci. Oczywiście otrzymywanie odpowiedzi jedną z tych metod pozwoli nam wykryć, czy komputer jest obecny w sieci i/lub ukryty za zaporą ogniową. Metody te zawierają:
przekroczenie czasu pofragmentowanego pakietu (Timedout Packet Fragmentation),
niepoprawną długość nagłówka IP (Invalid IP Header Length),
niepoprawne wartości pól IP (Invalid IP Field Values).
Uzyskiwanie poprawnych żądań protokołu
Pierwszą istotną kategorią wykrywania komputerów jest uzyskiwanie poprawnych zapytań protokołu. Kilka takich metod używanych jest w poprawnych żądaniach pakietów:
metoda Echo port,
metoda UDP,
metoda TCP FLAG,
metoda żądania ICMP.
Wszystkie z powyższych kategorii są metodami umożliwiającymi dowolnemu klientowi zażądać odpowiedzi na pakiet, aby określić dostępność komputera. Pakiety powracające i transmitowane są prawidłowymi odpowiedziami protokołu i przez to odmienne od generowanych niepoprawnych, ponieważ każde żądanie używa protokołów TCP/IP/UDP/ICMP bez szczególnego sprawdzania dostępnych pól.
Metoda ECHO Port
Ta staromodna i przestarzała technika wykrywania komputerów na bardzo podstawowym poziomie, może być nadal używana w słabo skonfigurowanych komputerach UNIX. Jednak rozważny administrator zablokuje ruch na port 7 TCP/UDP lub wyłączy usługę uruchamianą z inetd.
TCP/Echo Port
Ta prosta metoda używa standardowego trzyetapowego porozumienia TCP (handshake), która ustanawia połączenie na port echo (7/tcp). Jeśli połączenie zostanie ustanowione, można przypuszczać, że komputer jest dostępny w sieci. W ten sposób, procedura wykrywania komputera została wykonana na bardzo podstawowym poziomie. Metoda ta jest trudna do zrealizowania i mało prawdopodobna, ponieważ trzyetapowe porozumienie łączy się z potencjalnym otwarciem lub nawet zablokowaniem portu echo.
Mimo, że większość dystrybucji UNIXa/Linuxa ma domyślnie wyłączony port echo, nadal jest on używany w wielu systemach. Cele diagnostyczne, które taki serwer miał początkowo wypełniać, zostały odsunięte przez implikację zabezpieczeń, wprowadzonych jako rezultat zwiększającego się natłoku generowanego przez podłączających się klientów (co w rezultacie zmniejsza jego przepustowość i wydajność).
Po rozpoczęciu trzyetapowego porozumienia przez wysłanie początkowego pakietu z flagą SYN i otrzymanie w odpowiedzi SYN|ACK, klient nie musi kontynuować porozumienia, aby określić dostępność odległego komputera. Połączenie klienta nie tylko zostanie zapisane, ale ma on również największą szansę zostania zauważonym i zablokowanym przez zdalny komputer. Przy tak prostej konfiguracji, firewall przepuściłby pakiety z flagą SYN. Właśnie dlatego metoda TCP echo port powinna być używana, jako ostatnia deska ratunku. Nawet wtedy nie jest to dobry pomysł, chyba, że Twoim celem jest sprawdzenie większości rodzajów systemów wykrywania intruzów (Intrusion Detection Systems) i zaalarmowanie administratorów.
Przykład użycia tej metody w środowisku sieciowym ukazuje następujące połączenie przez telnet:
dethy@dev:~ $ telnet XXX.XXX.XXX.XXX 7
Trying XXX.XXX.XXX.XXX...
Connected to XXX.XXX.XXX.XXX
Escape character is "^]".
Hello.
Hello.
Jak pokazano powyżej, zdalny komputer odpowiada na nasze powitanie "Hello." swoim własnym "Hello.". Najwyraźniej serwer istnieje w sieci i jest aktywny. Utworzenie skanera do tej metody nie jest konieczne, ponieważ nie potrzebujemy wysyłać danych na port, ustanowione połączenie jest w zupełności wystarczające.
Uwaga: Inne metody określenia, czy usługa jest uruchomiona na komputerze zdalnym, pomijające trzyetapowe porozumienie TCP, mogą alternatywnie zostać wykorzystane do takich celów, jak oszukiwanie programów logujących pakiety. Przeczytaj http://www.synnergy.net/Archives/Papers/dethy/portscan.pdf, aby uzyskać więcej informacji o zaawansowanych technikach skanowania portów.
UDP/Echo Port
Podobnie do metody TCP echo port, UDP port 7 będzie odpowiadał na datagramy klientów swoim własnym datagramem UDP. Zanim jeszcze otrzymamy od komputera odpowiedź na nasz wysłany pakiet, wiemy, że jest on aktywny.
Używając narzędzia hping (dostępnego pod adresem http://www.kyuzz.org/antirez/hping2.html) jako generatora pakietów wysyłamy, co następuje:
dethy@dev:~ # hping XXX.XXX.XXX.XXX -c 1 -2 -p 7
eth0 default routing interface selected (according to /proc)
HPING XXX.XXX.XXX.XXX (eth0 XXX.XXX.XXX.XXX): udp mode set, 28 headers + 0
data bytes
50 bytes from XXX.XXX.XXX.XXX: seq=0 ttl=64 id=1255 rtt=0.9 ms
Metoda UDP
Ta technika wykorzystuje protokół User Datagram Protocol i jego generowanie odpowiedzi na zamknięte porty. Technika ta polega na wysłaniu datagramu UDP na zamknięty, NIE-NASŁUCHUJĄCY port, dowolny komputer powinien odpowiedzieć komunikatem błędu ICMP_PORT_UNREACH. Dzięki temu, że komputer odpowie w ten sposób, mamy możliwość określenia stanu jego podłączenia do sieci - czyli jego aktywności.
Cykl tej metody jest następujący:
klient ---> UDP (na zamknięty port),
serwer ---> ICMP_PORT_UNREACH.
dethy@dev:~ # hping XXX.XXX.XXX.XXX -c 1 -2 -p 65
eth0 default routing interface selected (according to /proc)
HPING XXX.XXX.XXX.XXX (eth0 XXX.XXX.XXX.XXX): udp mode set, 28 headers + 0
data bytes
ICMP Port Unreachable from XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX)
Znajdowanie zamkniętego portu jest bardzo proste. Spróbuj wybrać wysoki port (wyższy, niż 1024 i mniejszy, niż 65536). Oczywiście, jeśli odpowiedź na datagram UDP nie jest wysyłana do klienta, oznacza to, że pakiet został odrzucony przez jądro, ponieważ port docelowy był otwarty lub system filtrujący zablokował pakiet. Naturalnie, jeśli taka sytuacja ma miejsce, wybierz inny port, aby przetestować jego stan.
Jednak należy bardzo uważać z pakietami UDP, ponieważ UDP są często odrzucane podczas transmisji, i/lub blokowane przez firewalle, odpowiedź ICMP_PORT_UNREACH może wcale nie dotrzeć do klienta. W tym przypadku powinno się ponowić transmisję, aby mieć pewność.
Metody TCP FLAG
Przesyłanie różnie oflagowanych pakietów przez sieć jest prawdopodobnie najbardziej efektywną metodą określania aktywności komputerów. Pakiety te są nieuchwytne w rozumieniu transmisji i wyglądają na całkiem zwyczajne, więc są raczej trudne do odróżnienia od zwykłego ruchu w sieci. Jest to niezbędne do wykorzystania tej techniki wykrywania komputerów, za pomocą pojedynczego, tak oflagowanego pakietu, jak we wcześniejszej metodzie TCP/UDP echo port, wykorzystującej trzyetapowe porozumienie.
Próba TCP SYN
Metoda flagi SYN jest bardzo skuteczną implementacją "PING sweep". Ponieważ odpowiedź jest wysyłana na każdy pakiet SYN na zamkniętym lub otwartym porcie, daje klientowi pewność wykrycia obecności komputera. Manipulowanie nagłówkiem pakietu tak, aby zawierał flagę SYN i transmitował go na otwarty port, spowoduje wysłanie pakietu z ustawionymi bitami SYN|ACK, jako odpowiedź. Jeśli żaden pakiet nie zostanie zwrócony, klient może przypuszczać, że komputer jest za firewallem lub port jest filtrowany.
dethy@dev:~ # hping XXX.XXX.XXX.XXX -c 1 -S -p 23
eth0 default routing interface selected (according to /proc)
HPING XXX.XXX.XXX.XXX (eth0 XXX.XXX.XXX.XXX): S set, 40 headers + 0 data bytes
50 bytes from 192.168.1.1: flags=SA seq=0 ttl=64 id=1252 win=32696 rtt=0.9 ms
Jak zostało pokazane, SA (SYN|ACK) jest ustawiony w pakiecie powracającym. Bycie "ślepym klientem", czyli takim, który nie wie, czy port jest otwarty lub zamknięty, nie ma znaczenia w tej metodzie. Ponieważ oba (otwarty/zamknięty) porty odpowiedzą na pakiet SYN, nie musimy właściwie wysyłać pakietu inicjującego, ani znać stanu portu. Przykład wysłania SYN na zamknięty port został pokazany poniżej:
dethy@dev:~ # hping XXX.XXX.XXX.XXX -c 1 -S -p 2
eth0 default routing interface selected (according to /proc)
HPING atlanta (eth0 XXX.XXX.XXX.XXX): S set, 40 headers + 0 data bytes
50 bytes from XXX.XXX.XXX.XXX: flags=RA seq=0 ttl=255 id=1254 win=0 rtt=0.7 ms
Flagi RA (RST|ACK) powracające w tym pakiecie wskazują na zamknięte porty. Ponieważ otrzymaliśmy zwrócony pakiet, wiemy, że komputer jest aktywny.
Próba TCP ACK
Metoda ta jest najbardziej efektywną próbą skanowania PING zdalnego komputera. Umieszczenie bitu ACK w nagłówku TCP i transmitowanie pakietu na otwarty lub zamknięty port, powinno zwrócić pakiet z bitem resetującym (RST). Ta metoda wygląda z zewnątrz, jak normalny ruch sieciowy, ale jest również elastyczna w takim rozumieniu, że otwarty/zamknięty port nie determinuje końcowego rezultatu. Stan portu dla tej metody nie jest restrykcyjny, korzystnie dla klienta - umożliwiając mu odpytywanie celu na danym porcie (1-65536) i prawie gwarantowaną odpowiedź. Oczywiście, komputery mogą odrzucić te pakiety za pomocą efektywnych zasad na routerach i firewallach. Jest to bardzo wiarygodny sposób określenia, czy komputer jest chroniony przez jakiś rodzaj systemu filtrującego, używającego kombinacji technik opisywanych w tym artykule. Na przykład, jeśli zostanie odkryte, że maszyna blokuje połączenie na port TCP echo i nie wracają żadne odpowiedzi na pakiety, wtedy, używając próby TCP ACK skierowanej na port echo 7, można umożliwić klientowi przewidywanie zasad blokady, używając metody TCP ACK, jako diagnozy. Serwer może odpowiedzieć bitem RST, co oznacza:
port TCP echo 7 jest filtrowany przez jakieś dowolne zasady,
pakiety z włączoną flagą SYN są blokowane na porcie 7,
pakiety TCP ACK mają pozwolenie na przejście.
Wszystkie powyższe punkty są dość oczywiste, ale przypuszczenia na podstawie flagi SYN mogą być nieprawidłowe. Metodą eliminacji możemy wywnioskować, że port echo jest filtrowany oraz, że aby ustanowić połączenie na tym porcie, musimy używać trzyetapowego porozumienia, które wywołuje następujące odpowiedzi:
SYN ---> SYN|ACK ---> ACK
Teraz wiemy także, że pakiety ACK wróciły do klienta z bitem RST . Eliminując flagę ACK z powyższego równania, zostaje nam SYN i SYN|ACK. Ponieważ flaga SYN jest najpierw transmitowana z klienta do celu i odpowiedź SYN|ACK nie wraca z celu, mamy możliwość anulowania bitu SYN|ACK (ponieważ pakiet SYN nie został otrzymany, oznacza to, że niektóre firewalle blokują jego transmisję). Dlatego, poprzez jakieś zasady lub firewalle, pakiety pasujące do flagi SYN są odrzucane na końcu u odbierającego. Jest to technika znana, jako firewalking, czyli analiza typów pakietów, które są lub nie są przepuszczane, służąca do wykrywania typów zasad zaimplementowanych na dowolnym komputerze (i na tym, który ich nie ma). Używając HPING do wysłania pakietu ACK na zamknięty, a następnie na otwarty port wywołujemy:
dethy@dev:~ # hping XXX.XXX.XXX.XXX -A -c 1 -p 2
eth0 default routing interface selected (according to /proc)
HPING XXX.XXX.XXX.XXX (eth0 XXX.XXX.XXX.XXX): A set, 40 headers + 0 data bytes
50 bytes from XXX.XXX.XXX.XXX: flags=R seq=0 ttl=255 id=1048 win=0 rtt=0.5 ms
Argument -p oznacza port, na który wysyłamy pakiet. W tym przypadku transmisja pakietów została skierowana na port 2 (NIE-NASŁUCHUJĄCY port).
dethy@dev:~ # hping XXX.XXX.XXX.XXX -A -c 1 -p 23
eth0 default routing interface selected (according to /proc)
HPING XXX.XXX.XXX.XXX (eth0 XXX.XXX.XXX.XXX): A set, 40 headers + 0 data bytes
50 bytes from XXX.XXX.XXX.XXX: flags=R seq=0 ttl=255 id=1052 win=0 rtt=0.5 ms
Port 23 był otwartym, NASŁUCHUJĄCYM portem. Jak pokazano wyżej, obie odpowiedzi z komputera XXX.XXX.XXX.XXX wróciły z flagą RST na portach otwartym i zamkniętym. Dlatego określiliśmy, że komputer ten jest aktywny (online).
Próba TCP SYN|ACK
Metoda ta nie jest najbardziej elastyczna w sensie kompatybilności. Kod sieciowy BSD nie wysyła żadnego oflagowanego pakietu z powrotem na pakiet zapytania SYN|ACK. Blokadę stanowi architektura zależna. Mimo to, można wykryć tą techniką Linuxa/Windowsa (i inne). Pakiet SYN|ACK jest początkowo wysyłany na dowolny port (otwarty/zamknięty - stan nie ma znaczenia). Pakiet powracający powinien być ustawiony z bitem RST.
Ponieważ stan portu nie gra roli w tej sytuacji, dowolny port może zostać wykorzystany do testów. Poniższy przykład jest pakietem SYN|ACK, wysłanym na komputer Windows 95 z nie-nasłuchującym portem (23). Rezultatem jest pakiet z flagą RST.
dethy@dev:~ # hping XXX.XXX.XXX.XXX -c 1 -S -A -p 23
eth0 default routing interface selected (according to /proc)
HPING XXX.XXX.XXX.XXX (eth0 XXX.XXX.XXX.XXX): SA set, 40 headers + 0 data bytes
50 bytes from XXX.XXX.XXX.XXX: flags=R seq=0 ttl=128 id=31029 win=0 rtt=0.5 ms
Podobnie ten sam pakiet jest wysyłany do Linuxa na port nasłuchujący 23. W rezultacie otrzymujemy pakiet z flagą RST.
dethy@dev:~ # hping XXX.XXX.XXX.XXX -c 1 -S -A -p 23
eth0 default routing interface selected (according to /proc)
HPING XXX.XXX.XXX.XXX (eth0 XXX.XXX.XXX.XXX): SA set, 40 headers + 0 data bytes
50 bytes from XXX.XXX.XXX.XXX: flags=R seq=0 ttl=255 id=1258 win=0 rtt=0.5 ms
Próba TCP FIN
Znacznie bardziej ukrytą próbą skanowania komputera jest technika TCP FIN. Wysłanie pakietu z tą flagą na zamknięty port zwróci pakiet RST|ACK ze zdalnego komputera. Alternatywnie otwarty port odrzuci pakiet i dlatego jest on dla nas bezużyteczny przy wykrywaniu. Zlokalizowanie zamkniętego portu jest proste: weź dowolny port z zakresu 1-1024, gdzie nie działa żadna usługa.
dethy@dev:~ # hping XXX.XXX.XXX.XXX -c 1 -F -p 2
eth0 default routing interface selected (according to /proc)
HPING XXX.XXX.XXX.XXX (eth0 XXX.XXX.XXX.XXX): F set, 40 headers + 0 data bytes
50 bytes from XXX.XXX.XXX.XXX: flags=RA seq=0 ttl=255 id=1260 win=0 rtt=0.5 ms
Pakiet wychodzący został wysłany na port zamknięty i wrócił z bitem RST|ACK. Ponieważ dostaliśmy odpowiedź od serwera na nasz pakiet, wiemy, że komputer jest aktywny. Alternatywnie, pakiet-zapytanie nie wywołuje odpowiedzi ze zdalnego komputera, co zostanie wyjaśnione poniżej.
przychodzące pakiety FIN są blokowane przez firewall/router/ACLS,
przychodzący ruch na ten port jest filtrowany,
zapytany port był otwarty (spróbuj innego),
komputer jest wyłączony (wyłączony z sieci).
Próba TCP NULL
Metoda ta działa poprzez wyłączenie wszystkich flag w nagłówku TCP i wysłanie go na zamknięty, NIE-NASŁUCHUJĄCY port. Odpowiedzią powinien być pakiet z ustawionym bitem RST|ACK. Otwarty port nie odpowie na ten pakiet (zostanie odrzucony), tak więc wybierz jeszcze raz port, na którym domyślnie nie działają żadne usługi.
Przykład zamkniętego portu bez ustawionych flag w nagłówku jest pokazany poniżej:
dethy@dev:~ # hping XXX.XXX.XXX.XXX -c 1 -p 2
eth0 default routing interface selected (according to /proc)
HPING XXX.XXX.XXX.XXX (eth0 XXX.XXX.XXX.XXX): NO FLAGS are set, 40 headers + 0
data bytes
50 bytes from XXX.XXX.XXX.XXX: flags=RA seq=0 ttl=255 id=1267 win=0 rtt=0.5 ms
Definiowanie portu, który ma zostać wykorzystany do testów jest relatywnie proste. Rezultaty tego skanowania mogą często nie docierać do klienta, ponieważ ACLe i zasady konkretnie sprawdzają, czy pakiet posiada jakieś flagi. Z tego powodu, metoda ta nie jest tak efektywna, jak wspomniane wcześniej techniki ACK i SYN, ale oczywiście jest przydatną metodą, jeśli komputer nie odpowiada na standardowe zapytania echo ICMP typu 8.
Próba TCP XMAS
Podobnie do metody z flagą NULL, skanowanie XMAS testuje odpowiedź na pakiet wysłany na zamknięty port. Pakiet ten posiada włączone wszystkie bity nagłówka TCP: SYN, ACK, FIN, RST, URG, PSH (dwa zarezerwowane bity nie wprowadzają modyfikacji). Ta metoda jest oparta na implementacji stosu TCP/IP w UNIX/Linux/BSD i nie zawsze działa w systemach operacyjnych Windows.
dethy@dev:~ # hping XXX.XXX.XXX.XXX -c 1 -p 2 -F -S -R -P -A -U -X -Y
eth0 default routing interface selected (according to /proc)
HPING XXX.XXX.XXX.XXX (eth0 XXX.XXX.XXX.XXX): RSAFPUXY set, 40 headers + 0
data bytes
50 bytes from XXX.XXX.XXX.XXX: flags=RA seq=0 ttl=255 id=1380 win=0 rtt=0.6 ms
Bity RST|ACK wskazują, że komputer otrzymał naszą odpowiedź i potwierdził ją przesłanym pakietem. Dlatego klient może interpretować ten komputer, jako aktywny i podłączony do sieci. Ponieważ otwarte porty nie odpowiadają na to spreparowane żądanie, używanie otwartego portu do wykrywania komputerów jest trywialne.
Komentarz
Z powyższych informacji wynika, że wykrywanie komputerów działających w systemach UNIX/Linux/BSD jest stosunkowo łatwe, ponieważ mają one tendencję do odpowiadania na wiele spreparowanych pakietów. Systemy operacyjne Windows odrzucają wiele z nich, co uniemożliwia wykrycie tych komputerów (jednak nie są one przezroczyste na część z opisanych powyżej technik) w środowisku sieciowym.
Metody ICMP
Internet Control Message Protocol (ICMP) jest używany do zgłaszania błędów w przetwarzanych datagramach i jest integralną częścią protokołu IP. ICMP nie został wynaleziony do używania przy wykrywaniu komputerów, jednak kiedy Ofir Akfin opisał sposoby wykorzystania ICMP w wielu sytuacjach, łącznie z metodami "fingerprinting" i "inverse mapping", uległo to zmianie. Wraz ze wzrostem ważności danych i ich zabezpieczeń, osoby analizujące systemy implemetują ACLe oraz efektywne zasady, służące blokowaniu wszelkich form ICMP. Oczywiście nie wszystkie formy są złośliwe (broadcasty smurf, nadmierne komunikaty błędów "niedostępny"), wiele form ICMP wspomaga komunikację serwera w środowisku sieciowym (np. timestamping). Wykrywanie komputerów lekceważy filtrowanie typu ICMP i poszukuje jakichkolwiek oznak życia, wydobytych przez dowolny typ datagramu ICMP. Dziś, większość komputerów posiada jakąś formę filtrowania przeciwko ICMP typ 8 (żądanie echo), ale pozostawiło inne typy, wszystkie najlepsze do wykrywania komputerów.
Żądanie echo ICMP (typu 8)
PING? PONG! Nareszcie osiągnęliśmy standardową i obowiązkową metodę używaną do wykrywania komputerów. "PING" - narzędzie diagnostyczne wydobywa datagramy ICMP echo_request, aby zanalizować połączenie z siecią. Odpowiedź datagramu echo_reply typu 0 ICMP zostanie zwrócona, jeśli komputer jest aktywny (online). Ponieważ metoda została zaprojektowana, jako standardowa metoda rozpoznawania komputerów w sieci; firewalle, routery i ACLe mają zaprojektowane zasady dotyczące tej metody i blokują konsekwentnie wszystkie formy ruchu przychodzącego ICMP typu 8. Daje to powody do używania wszystkich innych technik opisanych powyżej, które unikają standardowych odpowiedzi echo (i są równie skuteczne). Skupiając się bardziej bezpośrednio na pakietach ICMP typu 8 można zobaczyć:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Odpowiedź jest następująca:
dethy@dev:~ # hping -1 XXX.XXX.XXX.XXX -c 1 -C 8
eth0 default routing interface selected (according to /proc)
HPING XXX.XXX.XXX.XXX (eth0 XXX.XXX.XXX.XXX): icmp mode set, 28 headers + 0
data bytes
50 bytes from XXX.XXX.XXX.XXX: icmp_seq=0 ttl=255 id=1273 rtt=0.4 ms
Powyżej pokazano 50 bajtów odpowiedzi ICMP echo_reply zwróconych z komputera docelowego. Podobnie, jak w przypadku innych metod, otrzymaliśmy pakiet - odpowiedź, czyli można przypuszczać, że komputer "żyje".
Broadcast ICMP
Broadcasting jest sposobem transmitowania pakietów do wszystkich połączonych komputerów w sieci, poprzez wysyłanie żądania echo (typ 8) do sieci lub adresu broadcast. Rezultaty będą zwielokrotnieniem pierwszego pakietu inicjującego, a każdy połączony komputer wyśle swój własną odpowiedź do klienta. Faktycznie, broadcasting ICMP jest niezwykle przydatną metodą wykrywania dowolnych komputerów połączonych siecią. Ponieważ każde zapytanie echo nie jest pozostawione bez odpowiedzi, umożliwia to proste wykrywanie komputerów, jako drogę do odkrycia całej sieci. Jednak istnieje pewna wada. Domyślnie komputery Windows (poza NT 4 z Service Pack < 4) nie odpowiadają na żądania echo ICMP typu 8 skierowane do adresów broadcast lub sieciowych, ale zamiast tego, "po cichu" odrzucają wszystkie takie pakiety. Jeszcze raz staje się jasne, że Windows mogą być raczej nieuchwytne w rozumieniu zdalnego wykrywania komputerów. Poniżej przykład pakietu - żądania ICMP echo wysłanego do adresu sieciowego jakiegoś serwera.
Uwaga: Adres IP XXX.XXX.XXX.4 nie zwrócił żadnej odpowiedzi, ponieważ był to system Windows 95.
dethy@dev:~ # hping -1 XXX.XXX.XXX.0 -c 2
eth0 default routing interface selected (according to /proc)
HPING XXX.XXX.XXX.0 (eth0 XXX.XXX.XXX.0): icmp mode set, 28 headers + 0
data bytes
28 bytes from XXX.XXX.XXX.3: icmp_seq=0 ttl=255 id=13013 rtt=0.4 ms
50 bytes from XXX.XXX.XXX.1: icmp_seq=0 ttl=255 id=426 rtt=0.6 ms
50 bytes from XXX.XXX.XXX.2: icmp_seq=0 ttl=255 id=15319 rtt=0.8 ms
--- XXX.XXX.XXX.0 hping statistic ---
1 packets tramitted, 3 packets received, -100% packet loss
round-trip min/avg/max = 0.4/0.6/0.8 ms
Można zauważyć, że pojedynczy pakiet otrzymał trzy odpowiedzi, kiedy został skierowany do adresu sieciowego. Alternatywnie, pakiet wysłany do adresu broadcast również będzie produkował trzy datagramy odpowiedzi.
dethy@dev:~ # hping -1 XXX.XXX.XXX.255 -c 2
eth0 default routing interface selected (according to /proc)
HPING XXX.XXX.XXX.255 (eth0 XXX.XXX.XXX.255): icmp mode set, 28 headers + 0
data bytes
28 bytes from XXX.XXX.XXX.3: icmp_seq=0 ttl=255 id=13098 rtt=0.4 ms
50 bytes from XXX.XXX.XXX.1: icmp_seq=0 ttl=255 id=730 rtt=0.7 ms
50 bytes from XXX.XXX.XXX.2: icmp_seq=0 ttl=255 id=15327 rtt=0.8 ms
--- XXX.XXX.XXX.255 hping statistic ---
1 packets tramitted, 3 packets received, -100% packet loss
round-trip min/avg/max = 0.4/0.7/0.8 ms
Jeszcze raz, ta technika pokazała, że jest skuteczną metodą używania adresów broadcast, jako mechanizmu wykrywania komputerów w sieci.
ICMP Router Solicitation (typu 10)
Żądania ICMP wykrywania routerów są nazywane "router solicitations". Każdy router okresowo rozgłasza informacje o swojej dostępności (ICMP typu 9) z każdego swojego interfejsu multicast, w rezultacie rozgłaszając adres IP tego interfejsu. Ta technika jest użyteczna do wykrywania systemu zachowującego się, jak router. Wiadomo, że ICMP Router Solication jest formatem opcjonalnej wiadomości na standardowym komputerze. Obowiązkowe jest, aby router miał włączoną implementację ICMP Router Solicitation. Dzięki temu, że istnieje kilka odpowiedzi ICMP typu 9 lub ICMP typu 10, można być pewnym, że serwer jest routerem lub urządzeniem sieciowym. Co więcej, jeśli komputer otrzyma ICMP typu 10, ale nie jest skonfigurowany na wysyłanie tych wiadomości, nie możne wysłać odpowiedzi. Format pakietu dla wiadomości wykrywającej router wygląda następująco:
0 1 2 3
0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(Niestety HPING nie ma zaimplemetowanych formatów wiadomości ICMP typu 10,13,15 i 17. Zamiast tego, ICMPUSH (dostępny pod adresem http://hispahack.ccc.de został wybrany alternatywnie, jako narzędzie do generowania/analizowania pakietów).
dethy@dev:~ # ./icmpush -vv -rts XXX.XXX.XXX.XXX
-> Outgoing interface = XXX.XXX.XXX.XXX
-> ICMP total size = 20 bytes
-> Outgoing interface = XXX.XXX.XXX.XXX
-> MTU = 1500 bytes
-> Total packet size (ICMP + IP) = 40 bytes
ICMP Router Solicitation packet sent to XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX)
Receiving ICMP replies ...
XXX.XXX.XXX.XXX -> Router Advertisement (XXX.XXX.XXX.XXX)
./icmpush: Program finished OK
Kolejne dobre trafienie! Wiemy, że znaleźliśmy router w tej sieci. Być może router filtruje inne typy ICMP lub blokuje porty, ale na szczęście artykuł ten omawia alternatywne metody omijania tych form ACL.
Żądanie ICMP Timestamp (typu 13)
Odpowiedzią (ICMP typu 14) na żądanie "timestamp" jest inicjacja przepływu danych. Żądania "timestamp" są wykonywane, aby zapytać serwer o aktualny czas. Często, kompatybilność między platformami powoduje porozumienie, kiedy żąda się odpowiedzi "timestamp". Windows 95 i Windows NT nie odpowiedziały na wysłane zapytania, a UNIX/Linux/BSD odpowiedziały poprawnymi danymi. Po przyjrzeniu się pakietowi ICMP odkrywamy, co następuje:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originate Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transmit Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pierwszy przykład pokazany poniżej transmituje żądanie ICMP timestamp do serwera Linux, co w rezultacie daje godzinę 03:50:32 enkapsulowaną w polu danych.
dethy@dev:~ # ./icmpush -vv -tstamp XXX.XXX.XXX.XXX
-> Outgoing interface = XXX.XXX.XXX.XXX
-> ICMP total size = 20 bytes
-> Outgoing interface = XXX.XXX.XXX.XXX
-> MTU = 1500 bytes
-> Total packet size (ICMP + IP) = 40 bytes
ICMP Timestamp Request packet sent to XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX)
Receiving ICMP replies ...
XXX.XXX.XXX.XXX -> Timestamp Reply transmited at 03:50:32
./icmpush: Program finished OK
Następny przykład przedstawia wysłanie tego samego pakietu, ale do komputera Windows 95 - nie został zwrócony żaden pakiet.
dethy@dev:~ # ./icmpush -vv -tstamp XXX.XXX.XXX.XXX
-> Outgoing interface = XXX.XXX.XXX.XXX
-> ICMP total size = 20 bytes
-> Outgoing interface = XXX.XXX.XXX.XXX
-> MTU = 1500 bytes
-> Total packet size (ICMP + IP) = 40 bytes
ICMP Timestamp Request packet sent to XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX)
Receiving ICMP replies ...
./icmpush: Program finished OK
Żądanie ICMP Timestamp stanowi dobrą metodę wykrywania komputerów, szczególnie serwerów *NIX.
Żądanie informacji ICMP (typu 15)
Żądane to jest wykorzystywane do odpytania komputera, aby wykryć jego adres sieciowy. W RFC napisano, że ICMP typu 15 (żądanie informacji) i ICMP typu 16 (odpowiedź) są podstawowymi, ale nie znaczy to, że nadal są używane. Podgląd sekcji ICMP odkrywa, co następuje:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pakiet z ICMP typu 15 został wysłany do komputera, co w rezultacie zwróciło żądanie i poprzez to poinformowało o istnieniu danego komputera.
dethy@dev:~ # ./icmpush -vv -info XXX.XXX.XXX.XXX
-> Outgoing interface = XXX.XXX.XXX.XXX
-> ICMP total size = 8 bytes
-> Outgoing interface = XXX.XXX.XXX.XXX
-> MTU = 1500 bytes
-> Total packet size (ICMP + IP) = 28 bytes
ICMP Info Request packet sent to XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX)
Receiving ICMP replies ...
XXX.XXX.XXX.XXX -> Info Reply (XXX.XXX.XXX.XXX)
./icmpush: Program finished OK
Jeszcze raz, nie potrafię uzyskać takich wyników przeciwko systemowi Windows 95/NT, ale kilka dystrybucji *NIX odpowiedziało pomyślnie.
Żądanie adresu maski ICMP (typu 17)
Żądania adresu maski są generowane po to, aby uzyskać adres maski podsieci w sieci lokalnej. Odpowiedzią na pakiet inicjujący będzie komunikat ICMP typu 18 (odpowiedź adresu maski), który powinien zawierać adres podsieci.
Szczegółowe spojrzenie na adres maski ICMP odkrywa, co następuje:
0 1 2 3
0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subnet Address Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Wysłanie wystarczająco dużo ICMP do różnych maszyn Linux nie zwróciło odpowiedzi ICMP typu 18, w przeciwieństwie do systemów Windows. Poniższy przykład pokazuje rezultat pakietu - żądania adresu maski, zainicjowanego przeciwko maszynie Windows.
dethy@dev:~ # ./icmpush -vv -mask XXX.XXX.XXX.XXX
-> Outgoing interface = XXX.XXX.XXX.XXX
-> ICMP total size = 12 bytes
-> Outgoing interface = XXX.XXX.XXX.XXX
-> MTU = 1500 bytes
-> Total packet size (ICMP + IP) = 32 bytes
ICMP Address Mask Request packet sent to XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX)
Receiving ICMP replies ...
XXX.XXX.XXX.XXX -> Address Mask Reply (255.255.255.0)
./icmpush: Program finished OK
Tak więc maska podsieci została otrzymana. Kolejna metoda wykrywania komputerów jest możliwa do wykonania przeciwko systemom Windows w środowisku sieciowym, blokującym żądania echo ICMP.
Komentarze
Niektórzy czytelnicy mogą się zastanawiać, dlaczego nie wydobywać odpowiedzi ICMP od komputerów i wykorzystać ich odpowiedzi do wykrywania komputerów. RFC 1122 znacząco podkreśla:
Komunikat błędu ICMP NIE MUSI być wysłany, jako rezultat otrzymania:
komunikatu błędu ICMP, lub
datagramu przeznaczonego do broadcastu IP lub adresu multicast IP, lub
datagramu wysłanego, jako broadcast w warstwie łącza, lub
nie-inicjującego fragmentu, lub
datagramu, którego adres źródłowy nie definiuje pojedynczego komputera, np. adres zerowy, adres interfejsu zwrotnego (loopback), adres broadcast, adres multicast lub adres klasy E.
Pierwszy punkt wyjaśnia, że komputer nie wyśle odpowiedzi na datagram ICMP, tak więc nici z wykrywania komputerów przy użyciu odpowiedzi na datagramy. Cóż, czas ruszyć szare komórki.
Generowanie nieprawidłowych odpowiedzi na protokoły
Ta sekcja opisuje metody używania protokołu Internet Protocol (IP) do otrzymania komunikatów błędów, aby wykryć dowolny komputer. Odpowiadający enkapsulowany protokół (TCP/UDP/ICMP) nie ma wpływu na rezultat tej metody, kiedy pakuje datagramy. Główną ochroną przed analizą podłączenia komputera są efektywne ACLe i filtrowanie wychodzących pakietów. Podstawa tej techniki leży w generowaniu nieprawidłowych datagramów i wykrywaniu zewnętrznych odpowiedzi, które wymusza spreparowany pakiet, jako rezultat anormalnej pracy.
Próba nagłówka IP (IP Header)
Tworzenie w transmisji anomalii w nagłówkach IP podniesie szanse wykrycia komputera fitrowanego i chronionego firewallem. Wiele form systemów detekcji intruzów i routerów odrzuca pakiety zawierające spreparowane nagłówki takie, jak nieprawidłowe wartości pól. Poniższe techniki należą do takich sytuacji:
przekroczenie czasu pofragmentowanego pakietu (Timedout Packet Fragmentation),
nieprawidłowa długość nagłówka (Invalid Header Length),
nieprawidłowe wartości pól (Invalid Field Values).
Przekroczenie czasu pofragmentowanego pakietu (Timedout Packet Fragmentation)
Jeszcze inną metodą używaną w zaawansowanym wykrywaniu komputerów jest fragmentowanie nie-wysłanych pakietów. Po pierwsze należy skonstruować pakiet z pofragmentowanym offsetem i wysłać go do komputera. Zamiast zebrania innego pofragmentowanego datagramu do zakończenia pakietu, klient pozwoli inicjującemu pofragmentowanemu pakietowi przekroczyć czas, pozostawiając serwer oczekujący na następny pakiet w sekwencji. Efektem tego jest wydobycie ICMP typu 11 kod 1 (zbieranie fragmentów przekroczyło zadany czas) wygenerowany przez serwer.
Przykład:
dethy@dev:~ # hping -c 1 -x -y XXX.XXX.XXX.XXX
eth0 default routing interface selected (according to /proc)
HPING dev (eth0 XXX.XXX.XXX.XXX): NO FLAGS are set, 40 headers + 0 data bytes
--- dev hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Uwaga: Mimo,że HPING zwraca 100% utraty pakietów, jeśli nie sprawdzi wygenerowanego przez zdalny komputer datagramu ICMP, to tcpdump pokazuje następujące informacje:
20:41:09.309085 YYY.YYY.YYY.YYY > XXX.XXX.XXX.XXX: icmp: ip reassembly time exceeded [tos 0xc0] (ttl 255, id 3375)
Jeszcze raz stworzyliśmy odpowiedź z serwera przy użyciu nieprawidłowej komunikacji protokołu.
Nieprawidłowa długość nagłówka (Invalid Header Length)
Użycie nieprawidłowej długości nagłówka IP doprowadzi do wygenerowania przez zdalny komputer ICMP typu 12 - komunikatu błędu oznaczającego problem z parametrem. Typ kodu w tym datagramie ICMP może być równy:
0 - wskaźnik informuje o błędzie
2 - nieprawidłowa długość (Bad Length)
Kod równy 0 zwróci dokładnie ten bajt, który spowodował błąd enkapsulowany w polu wskaźnika. Alternatywnie, kod równy 2 oznacza, że cały pakiet zawiera błąd. W każdym z przypadków, komputer odbierający pakiet wysyła najpierw zaproszenie ICMP typu 12 kod (0 | 2), a później informuje wysyłającego, że pakiet został odrzucony. Poniżej ISIC (IP Stack Integrity Checker - tester integralności stosu IP) został wykorzystany do odebrania pakietu z nieprawidłowym nagłówkiem IP o długości 66 bajtów.
dethy@dev:~ # ./isic -s YYY.YYY.YYY.YYY -d XXX.XXX.XXX.XXX -p 1 -V 0 -F 0 -I 66 -D
Compiled against Libnet 1.0.1b
Installing Signal Handlers.
Seeding with 5099
No Maximum traffic limiter
Bad IP Version = 0% Odd IP Header Length = 100% Frag"d Pcnt = 0%
YYY.YYY.YYY.YYY -> XXX.XXX.XXX.XXX tos[137] id[0] ver[4] frag[0]
Wrote 1 packets in 0.00s @ 5649.72 pkts/s
śledzenie za pomocą tcpdump odkryło, co następuje:
21:39:03.755839 XXX.XXX.XXX.XXX > YYY.YYY.YYY.YYY: icmp: parameter problem -
octet 20 [tos 0xd0] (ttl 255, id 21508)
Zgodnie z oczekiwaniami, nieprawidłowa długość nagłówka wymusiła dowolną odpowiedź z serwera. Ta metoda może również zostać wykorzystana do ominięcia wielu form ACLi i filtrowania systemów, jeśli nie są one odpowiednio skonfigurowane.
Nieprawidłowe wartości pól
Na bardziej ogólnym poziomie, specyfikowanie nieprawidłowych wartości w polach nagłówka IP wyprodukuje komunikaty błędów ICMP na komputerze docelowym. Taki przypadek jest z polem IP PROTO, który ma długość 8 bitów i dlatego możliwe jest 256 (2^8) kombinacji. Trick wykorzystywany w tym przypadku polega na wybraniu wartości protokołu, która nie wskazuje poprawnej wartości protokołu na tym komputerze. Na szczęście klient ma możliwość określenia, czy komputer nie wspiera protokołu, jak serwer będzie generował ICMP typu 3 kod 3 - Destination Unreachable Protocol Unreachable. Jeśli odpowiedź nie zostanie odesłana, klient może przypuszczać, że protokół wyspecyfikowany jest wspierany przez ten komputer. W następnym przykładzie wykorzystano APSEND (http://www.elxsi.de) do wygenerowania pakietu.
dethy@dev:~ # perl apsend -s YYY.YYY.YYY.YYY -d XXX.XXX.XXX.XXX -b 8 -p 8
--protocol 0
Packet: 1 from YYY.YYY.YYY.YYY(port: 8) to XXX.XXX.XXX.XXX(port: 8).
Protocol: 0 Type of Service(ToS): 16 ID: 0
W powyższym przykładzie datagram został wysłany protokołem równym 0, i dlatego powinien zawsze zwrócić błąd ICMP. Śledzenie tcpdump zwróciło następujące dane:
21:58:21.128201 YYY.YYY.YYY.YYY > XXX.XXX.XXX.XXX: icmp: dev.synnergy.net
protocol 0 unreachable [tos 0xd0] (ttl 255, id 24133)
Jak oczekiwano, XXX.XXX.XXX.XXX został zwrócony z datagramem ICMP typu 3 kod 3 i jeszcze raz wiemy, że komputer jest aktywny, dlatego jest to jeszcze jedna skuteczna metoda wykrywania komputerów.
Uwaga końcowa:
Dalsze spreparowane pakiety mogą zostać wykorzystane do generowania dowolnych odpowiedzi na komputerze używającym nieprawidłowych wartości w polach IP, zostało to jednak pozostawione do analizy dla czytelnika. Większość tych metod może zostać zaaplikowanych do wielu protokołów takich, jak IGMP lub ARP jako użyteczny mechanizm wykrywania komputerów chronionych zaporą ogniową. Implementacja filtrów przychodzącego i wychodzącego ruchu jest koniecznością dla każdej sieci, jeżeli chcemy uniknąć wielu form wykrywania zdalnych komputerów. Odpowiednią zasadą i efektywnymi ACLami powinny być szczegółowo przejrzane i przetestowane jako standardowe ćwiczenia ustawiania zabezpieczeń. Teraz czytelnik powinien być wyposażony w wiedzę wystarczającą, aby uniemożliwić takim protokołom generowanie odpowiedzi z serwera i tym samym wykrywanie komputerów.
Źródła:
ICMP Scanning - by Ofir Afkin - www.sys-security.com
RFC 792 - Internet Control Message Protocol
RFC 1122 - Requirements for Internet hosts - communication layer
--------------------------------------------------------------------------------
autor oryginału: dethy@synnergy.net - Synnergy Networks - Copyright - 1998-2001
--------------------------------------------------------------------------------
Autor: dethy@synnergy.net, Tomasz Polus