Nyitott és szűrt UDP-portok megkülönböztetése
A Felix-ellenőrzés esetében a három open|filtered port kivételével mindegyik closed volt.Tehát a vizsgálat még mindig sikeresen leszűkítette a potenciálisan nyitott portokat egy maroknyira. Ez nem mindig van így. Az 5.5. példa egy UDP-ellenőrzést mutat az erősen szűrt Scanme webhely ellen.
5.5. példa. UDP-ellenőrzési példa
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
Ez esetben a vizsgálat egyáltalán nem szűkítette le a nyitott portokat. 1000 mindegyike open|filtered. Új stratégiára van szükség.
Az 5.3. táblázat, “Hogyan értelmezi az Nmap az UDP-szondára adott válaszokat” azt mutatja, hogy a open|filtered állapot akkor fordul elő, amikor az Nmap nem kap semmilyen választ az UDP-szondáktól egy adott portra.Ugyanakkor azt is mutatja, hogy ritkán előfordul, hogy a porton hallgató UDP-szolgáltatás válaszol, ami bizonyítja, hogy a port nyitva van. Azért nem válaszolnak gyakran ezek a szolgáltatások, mert az Nmap által küldött üres csomagokat érvénytelennek tekintik. Sajnos az UDP-szolgáltatások általában saját csomagstruktúrát határoznak meg, ahelyett, hogy betartanának egy közös általános formátumot, amelyet az Nmap mindig el tudna küldeni. Egy SNMP csomag teljesen másképp néz ki, mint egy SunRPC, DHCP vagy DNS kérési csomag.
Hogy minden népszerű UDP szolgáltatásnak megfelelő csomagot küldjön, az Nmapnek egy nagy adatbázisra lenne szüksége, amely meghatározza a szondák formátumát.Szerencsére az Nmap rendelkezik ezzel anmap-service-probes formájában, amely a 7. fejezetben, Szolgáltatás- és alkalmazásverzió-érzékelés című fejezetben leírt szolgáltatás- és verzióérzékelő alrendszer része.
Ha a verzióellenőrzés a -sV (vagy-A) kapcsolóval van engedélyezve, akkor mindenopen|filtered portra (valamint az ismertopen portokra) UDP szondát küld. Ha bármelyik szonda választ kap egy open|filtered portról, az állapot open-ra változik. Az 5.6. példa mutatja az 5.6. példa a-sV hozzáadásának eredményeit.
5.6. példa. A Felix UDP-ellenőrzés eredményeinek javítása verzióérzékeléssel
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
Ez az új vizsgálat azt mutatja, hogy a 111-es és az 53-as port biztosan nyitva van.A rendszer azonban nem tökéletes – a 67-es port még mindigopen|filtered. Ebben a konkrét esetben a port nyitva van, de az Nmapnak nincs működő verziószondája a DHCP-hez.Egy másik nehéz szolgáltatás az SNMP, amely általában csak akkor válaszol, ha a megfelelő közösségi karakterláncot adjuk meg. Sok eszköz a public közösségi karakterlánccal van konfigurálva, de nem mindegyik.Bár ezek az eredmények nem tökéletesek, a három vizsgált port közül kettő valódi állapotának megismerése még mindig hasznos.
A Felix eredmények egyértelművé tételének sikere után Ere visszaveti figyelmét a Scanme-ra, amely legutóbb minden portot open|filtered-ként listázott. Újra megpróbálkozik a verziófelismeréssel, ahogyan az az 5.7. példában látható.
5.7. példa. A Scanme UDP-ellenőrzési eredményeinek javítása verzióérzékeléssel
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
Míg Ereet végül megtalálta a nyitott portot, hibát követett el, amikor először nem frissítette az Nmap verzióját. Az Nmap 5.10BETA1 és újabb verziói olyan hasznos rendszerrel rendelkeznek, amely több mint három tucat jól ismert UDP-portra küld megfelelő szolgáltatási protokollkéréseket, ha azokat portellenőrzésre vagy állomásfelfedezésre választják ki. Bár ez nem olyan átfogó, mint a verzióérzékelés, de gyorsan azonosította volna az 5.5. példában szereplő nyitott 53-as portot.
Ez az eredmény egy órát vett igénybe, szemben az előzőScanme-ellenőrzés öt másodpercével, de ezek az eredmények valóban hasznosak. Ereet mosolya szélesedik, és szemei csillognak a nyílt ISC BINDnameserver bizonyítékára egy olyan gépen, amelyet kompromittálni akar. Ennek a szoftvernek hosszú története van a biztonsági résekről, így talán találhat hibát ebben a legújabb verzióban.
Ereet az UDP-támadásait az 53-as portra összpontosítja, mivel az bizonyítottan nyitva van, de nem feledkezik meg a többi 999 portról sem, amelyek aopen|filtered listán szerepelnek. Amint azt a Felixen a dhcpserver port esetében is láthattuk, bizonyos nyitott UDP-szolgáltatások még az Nmap verziófelismerése elől is elrejtőzhetnek. Ő is csak az alapértelmezett portokat vizsgálta eddig, van még 64529 másik, ami esetleg nyitva lehet. Az 53 az egyetlen nyitott UDP port a Scanme-on.
Míg ez a verzióérzékelési technika az egyetlen módja annak, hogy az Nmapto automatikusan szétválassza a open|filtered portokat,van néhány trükk, amit manuálisan is ki lehet próbálni. Néha a specializált traceroute segíthet. Elvégezhet egy traceroute-t egy ismert nyitott TCP vagy UDP porttal szemben az Nmap vagy egy olyan eszközzel, mint azNping.Ezután próbálja meg ugyanezt a kérdéses UDP porttal szemben. Az ugrásszámok különbségei alapján meg lehet különböztetni a nyitott és a szűrt portokat. Ereet az 5.8. példában ezt próbálja meg a Scanme ellen. Az első parancs UDP traceroute-t végez az ismerten nyitott 53-as porttal szemben. A második parancs ugyanezt teszi az 54-es feltételezett zárt porttal szemben. Az első néhány ugrást helytakarékossági okokból kihagytuk.
5.8. példa. Kísérlet a TTL-eltérésekkel rendelkező UDP-portok megkülönböztetésére
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
Ebben a példában az Ereet csak a tizenegyedik hopot tudta elérni mind a nyitott, mind a zárt portok közül. Így ezek az eredmények nem használhatók a portállapotok megkülönböztetésére ezzel az állomással szemben. Egy próbát megért, és az esetek jelentős részében működik is. Valószínűbb, hogy olyan helyzetekben működik, amikor az átvilágító tűzfal legalább egy vagy két hoppon belül van a célállomás előtt. A Scanme viszont saját Linuxiptableshost-alapú tűzfalat futtat. Így nincs különbség a hopok számában a szűrt és a nyitott portok között.
Egy másik technika az alkalmazásspecifikus eszközök kipróbálása a gyakori portok ellen. Például a 161-es porton kipróbálható egy durva erővel működő SNMP community stringcracker. Ahogy az Nmap verzióérzékelő szondaadatbázisa növekszik, úgy csökken az igény arra, hogy az eredményeit külső, speciális eszközökkel egészítsük ki. Ezek továbbra is hasznosak lesznek speciális esetekben, például az egyedi közösségi karakterlánccal rendelkező SNMP eszközök esetében.