Rozróżnianie otwartych i filtrowanych portów UDP
W przypadku skanowania Felixa, wszystkie oprócz trzechopen|filtered portów były closed.Tak więc skanowanie nadal było skuteczne w zawężaniu potencjalnie otwartych portów do garstki. Nie zawsze tak jest. Przykład 5.5 pokazuje skanowanie UDP silnie filtrowanej witryny Scanme.
Przykład 5.5. Przykład skanowania UDP
krad# Starting Nmap ( http://nmap.org )All 1000 scanned ports on scanme.nmap.org (64.13.134.52) are open|filteredNmap done: 1 IP address (1 host up) scanned in 5.50 seconds
W tym przypadku skanowanie w ogóle nie zawęziło liczby otwartych portów. Wszystkie 1000 to open|filtered. Tabela 5.3, „Jak Nmap interpretuje odpowiedzi na sondy UDP” pokazuje, że stan open|filtered występuje, gdy Nmap nie otrzymuje żadnych odpowiedzi od swoich sond UDP na konkretny port. Jednak pokazuje również, że w rzadkich przypadkach usługi UDP nasłuchujące na porcie odpowiedzą, udowadniając, że port jest otwarty. Powodem, dla którego usługi te nie odpowiadają często jest to, że puste pakiety wysyłane przez Nmapa są uważane za nieważne. Niestety, usługi UDP generalnie definiują swoją własną strukturę pakietów, zamiast stosować się do jakiegoś wspólnego ogólnego formatu, który Nmap mógłby zawsze wysyłać. Pakiet SNMP wygląda zupełnie inaczej niż pakiet żądania SunRPC, DHCP czy DNS.
Aby wysłać właściwy pakiet dla każdej popularnej usługi UDP, Nmap potrzebowałby dużej bazy danych definiującej ich formaty sond.Na szczęście Nmap posiada ją w postacinmap-service-probes, która jest częścią podsystemu wykrywania usług i wersji opisanego w rozdziale 7, Wykrywanie wersji usług i aplikacji.
Gdy skanowanie wersji jest włączone za pomocą -sV (lub-A), wyśle sondy UDP na każdyopen|filtered port (jak również na te znaneopen). Jeśli którakolwiek z sond wywoła odpowiedź z portu open|filtered, jego stan zostanie zmieniony na open. Wyniki dodania-sV do skanowania Felixa są pokazane w przykładzie 5.6.
Przykład 5.6. Poprawa wyników skanowania UDP Felixa za pomocą wykrywania wersji
krad# Starting Nmap ( http://nmap.org )Nmap scan report for felix.nmap.org (192.168.0.42)Not shown: 997 closed portsPORT STATE SERVICE VERSION53/udp open domain ISC BIND 9.2.167/udp open|filtered dhcpserver111/udp open rpcbind 2 (rpc #100000)MAC Address: 00:02:E3:14:11:02 (Lite-on Communications)Nmap done: 1 IP address (1 host up) scanned in 1037.57 seconds
Nowe skanowanie pokazuje, że porty 111 i 53 są na pewno otwarte. System nie jest jednak doskonały – port 67 nadal jestopen|filtered. W tym konkretnym przypadku port jest otwarty, ale Nmap nie ma działającej wersji sondy dla DHCP.Inną trudną usługą jest SNMP, który zwykle odpowiada tylko wtedy, gdy podany jest prawidłowy ciąg społeczności. Wiele urządzeń jest skonfigurowanych z łańcuchem społeczności public, ale nie wszystkie. Chociaż wyniki te nie są idealne, poznanie prawdziwego stanu dwóch z trzech testowanych portów jest wciąż pomocne.
Po sukcesie w rozszyfrowaniu wyników Felixa, Ereett zwraca swoją uwagę z powrotem na Scanme, który ostatnim razem wykazał wszystkie porty jako open|filtered. Próbuje ponownie z wykrywaniem wersji, jak pokazano w przykładzie 5.7.
Przykład 5.7. Poprawa wyników skanowania UDP Scanme za pomocą wykrywania wersji
krad# Starting Nmap ( http://nmap.org )Nmap scan report for scanme.nmap.org (64.13.134.52)Not shown: 999 open|filtered portsPORT STATE SERVICE VERSION53/udp open domain ISC BIND 9.3.4Nmap done: 1 IP address (1 host up) scanned in 3691.89 seconds
Chociaż Ereet w końcu znalazł otwarty port, popełnił błąd nie aktualizując najpierw wersji Nmapa. Nmap w wersji 5.10BETA1 i nowszych posiada system payload, który wysyła żądania odpowiedniego protokołu serwisowego na ponad trzy tuziny dobrze znanych portów UDP, jeśli zostały one wybrane do skanowania portów lub wykrywania hostów. Chociaż nie jest to tak wszechstronne jak wykrywanie wersji, szybko zidentyfikowałoby otwarty port 53 w przykładzie 5.5.
Ten wynik zajął godzinę, w porównaniu z pięcioma sekundami dla poprzedniego skanowaniaScanme, ale te wyniki są rzeczywiście użyteczne. Uśmiech Ereeta poszerza się, a oczy błyszczą na widok otwartego serwera ISC BINDnameserver na maszynie, którą chce skompromitować. To oprogramowanie ma długą historię dziur w zabezpieczeniach, więc może uda mu się znaleźć dziurę w tej najnowszej wersji.
Ereet skoncentruje swoje ataki UDP na porcie 53, ponieważ potwierdzono, że jest on otwarty, ale nie zapomina o innych 999 portach wymienionych jakoopen|filtered. Jak widzieliśmy na przykładzie portu dhcpserver na Felixie, niektóre otwarte usługi UDP mogą się ukryć nawet przed wykrywaniem wersji Nmapa. Do tej pory przeskanował on tylko domyślne porty, jest jeszcze 64529 innych, które mogą być otwarte. Dla przykładu, 53 jest jedynym otwartym portem UDP na Scanme.
Chociaż ta technika wykrywania wersji jest jedynym sposobem na automatyczne rozróżnienie przez Nmapa open|filtered portów, istnieje kilka sztuczek, które można wypróbować ręcznie. Czasami wyspecjalizowany traceroute może pomóc. Można wykonać traceroute na znanym, otwartym porcie TCP lub UDP za pomocą Nmapa lub narzędzia takiego jak Nping, a następnie spróbować tego samego na wątpliwym porcie UDP. Różnice w ilości przeskoków pozwolą odróżnić porty otwarte od filtrowanych. Ereet próbuje to zrobić przeciwko programowi Scanme w przykładzie 5.8. Pierwsze polecenie wykonuje traceroute UDP na znanym, otwartym porcie 53. Drugie polecenie robi to samo na przypuszczalnie zamkniętym porcie 54. Kilka pierwszych węzłów zostało pominiętych, aby zaoszczędzić miejsce.
Przykład 5.8. Próba dezambiguacji portów UDP z rozbieżnościami TTL
krad# Starting Nping ( http://nmap.org/nping )SENT (7.0370s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=8 id=4826 iplen=28RCVD (7.1010s) ICMP 4.69.134.222 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=248 id=38454 iplen=56SENT (8.0400s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=9 id=38166 iplen=28RCVD (8.1050s) ICMP 4.68.18.204 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=247 id=39583 iplen=56SENT (9.0420s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=10 id=6788 iplen=28RCVD (9.1080s) ICMP 4.59.4.78 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=246 id=59897 iplen=56SENT (10.0440s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=11 id=366 iplen=28RCVD (10.1100s) ICMP 69.36.239.221 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=243 id=42710 iplen=56SENT (11.0470s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=12 id=63478 iplen=28SENT (12.0490s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=13 id=56653 iplen=28Max rtt: 73.003ms | Min rtt: 0.540ms | Avg rtt: 48.731msRaw packets sent: 13 (364B) | Rcvd: 10 (560B) | Lost: 3 (23.08%)Tx time: 12.02836s | Tx bytes/s: 30.26 | Tx pkts/s: 1.08Rx time: 13.02994s | Rx bytes/s: 42.98 | Rx pkts/s: 0.77Nping done: 1 IP address pinged in 13.05 secondskrad# Starting Nping ( http://nmap.org/nping )SENT (7.0370s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=8 id=56481 iplen=28RCVD (7.1130s) ICMP 4.69.134.214 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=248 id=22437 iplen=56SENT (8.0400s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=9 id=23264 iplen=28RCVD (8.1060s) ICMP 4.68.18.76 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=247 id=50214 iplen=56SENT (9.0430s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=10 id=9101 iplen=28RCVD (9.1070s) ICMP 4.59.4.78 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=246 id=880 iplen=56SENT (10.0450s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=11 id=35344 iplen=28RCVD (10.1110s) ICMP 69.36.239.221 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=243 id=44617 iplen=56SENT (11.0470s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=12 id=53857 iplen=28SENT (12.0490s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=13 id=986 iplen=28Max rtt: 76.488ms | Min rtt: 0.546ms | Avg rtt: 48.480msRaw packets sent: 13 (364B) | Rcvd: 11 (616B) | Lost: 2 (15.38%)Tx time: 12.02908s | Tx bytes/s: 30.26 | Tx pkts/s: 1.08Rx time: 13.03165s | Rx bytes/s: 47.27 | Rx pkts/s: 0.84Nping done: 1 IP address pinged in 13.05 seconds
W tym przykładzie Ereet był w stanie dotrzeć tylko do jedenastego hopu zarówno otwartego, jak i zamkniętego portu. Więc te wyniki nie mogą być użyte do rozróżnienia stanów portów dla tego hosta. Warto było spróbować, i działa to w znaczącej liczbie przypadków. Jest bardziej prawdopodobne, że zadziała w sytuacji, gdy firewall przesiewający jest co najmniej jeden lub dwa hopy przed hostem docelowym. Scanme, z drugiej strony, używa własnego firewalla opartego na Linuxiptableshost. Nie ma więc różnicy w ilości przeskoków między portami filtrowanymi i otwartymi.
Inną techniką jest wypróbowanie narzędzi specyficznych dla aplikacji przeciwko wspólnym portom. Na przykład, brute force SNMP community stringcracker może być wypróbowany na porcie 161. Wraz ze wzrostem bazy danych sond do wykrywania wersji Nmapa, zmniejsza się potrzeba uzupełniania wyników za pomocą zewnętrznych, wyspecjalizowanych narzędzi. Nadal będą one przydatne w szczególnych przypadkach, takich jak urządzenia SNMP z niestandardowym łańcuchem społeczności.