Rozlišení otevřených a filtrovaných portů UDP
V případě skenování Felix byly všechny porty kromě tříopen|filtered
closed
, takže skenování bylo přesto úspěšné při zužování potenciálně otevřených portů na několik málo. Ne vždy tomu tak je. Příklad 5.5 ukazuje skenování UDP proti silně filtrovanému webu Scanme.
Příklad 5.5. Příklad skenování 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
V tomto případě skenování vůbec nezúžilo počet otevřených portů. všech 1000 je open|filtered
. Je třeba zvolit novou strategii.
Tabulka 5.3, „Jak Nmap interpretuje odpovědi na sondu UDP“, ukazuje, že stav open|filtered
nastane, když Nmap neobdrží žádné odpovědi ze sond UDP na určitý port. zároveň však ukazuje, že ve vzácných případech služba UDP naslouchající na portu odpoví in natura, což dokazuje, že port je otevřený. Důvodem, proč tyto služby často neodpovídají, je to, že prázdné pakety, které Nmap posílá, jsou považovány za neplatné. Bohužel služby UDPzpravidla definují vlastní strukturu paketů, místo aby dodržovaly obecný formát, který by Nmap mohl vždy odeslat. Balíček SNMP vypadá úplně jinak než balíček požadavků SunRPC, DHCP nebo DNS.
Chce-li Nmap odeslat správný paket pro každou populární službu UDP, potřeboval by rozsáhlou databázi definující formáty jejich sond.Naštěstí ji Nmap má v podoběnmap-service-probes
,který je součástí subsystému detekce služeb a verzí popsaného v kapitole 7, Detekce verzí služeb a aplikací.
Pokud je povoleno skenování verzí pomocí -sV
(nebo-A
), odešle sondy UDP na každý portopen|filtered
(a také na známé portyopen
). Pokud některá ze sond vyvolá odpověď z portu open|filtered
, změní se stav na open
. Výsledky přidání-sV
do Felixova skenování jsou uvedeny v příkladu 5.6.
Příklad 5.6. Vylepšení výsledků skenování UDP systému Felix pomocí detekce verzí
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
Toto nové skenování ukazuje, že porty 111 a 53 jsou určitě otevřené. systém však není dokonalý – port 67 je stáleopen|filtered
. V tomto konkrétním případě je portotevřený, ale Nmap nemá funkční verzi sondy pro DHCP. další náročnou službou je SNMP, která obvykle reaguje pouze při zadání správného řetězce komunity. Mnoho zařízení je nakonfigurováno s komunitním řetězcem public
, ale ne všechna. i když tyto výsledky nejsou dokonalé, zjištění skutečného stavu dvou ze tří testovaných portů je přesto užitečné.
Po úspěchu při rozklíčování výsledků Felixe se Ereet vrací zpět ke Scanme, který minule uvedl všechny porty jako open|filtered
. Znovu se pokusí o detekci verze, jak ukazuje příklad 5.7.
Příklad 5.7. Zlepšení výsledků skenování UDP programu Scanme pomocí detekce verze
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
Ačkoli Ereet nakonec otevřený port našel, udělal chybu, že nejprve neaktualizoval verzi programu Nmap. Nmap verze 5.10BETA1 a novější mají systém užitečného zatížení, který odesílá požadavky na správný servisní protokol na více než tři desítky známých portů UDP, pokud jsou vybrány pro skenování portů nebo zjišťování hostitelů. Není sice tak komplexní jako detekce verze, ale rychle by identifikoval otevřený port 53 v příkladu 5.5.
Tento výsledek trval hodinu oproti pěti sekundám u předchozího skenováníScanme, ale tyto výsledky jsou skutečně užitečné. Ereetovi se rozšíří úsměv a zajiskří oči při tomto důkazu o otevřeném ISC BINDnameserveru na počítači, který chce kompromitovat. Tento software má dlouhouhistorii bezpečnostních děr, takže možná najde chybu i v tétonejnovější verzi.
Ereet zaměří své útoky UDP na port 53, protože jepotvrzen jako otevřený, ale nezapomíná ani na dalších 999 portů uvedených jakoopen|filtered
. Jak jsme byli svědky u portu dhcpserver na Felixovi, některé otevřené služby UDP se mohou skrýt i před detekcí verze Nmap. Zatím také skenoval pouze výchozí porty, existuje 64529 dalších, které by případně mohly být otevřené. Například 53 je jediný otevřený port UDP na Scanme.
Ačkoli je tato technika detekce verzí jediným způsobem, jak může Nmap automaticky rozklíčovat porty open|filtered
, existuje několik triků, které lze vyzkoušet ručně. Někdy může pomoci specializovaný traceroute. Můžete provést traceroute proti známému otevřenému portu TCP nebo UDP pomocí nástroje Nmap nebo nástroje, jako je například Nping.Pak zkuste totéž proti spornému portu UDP. Rozdíly v počtu skoků mohou odlišit otevřené porty od filtrovaných. Ereet se o to pokusí protiScanme v příkladu 5.8. První příkaz provede trasování UDP proti známému otevřenému portu 53. Druhý příkaz provede totéž proti domněle uzavřenému portu 54. Prvních několik skoků bylo z důvodu úspory místa vynecháno.
Příklad 5.8. Pokus o rozklíčování portů UDP s nesrovnalostmi 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
V tomto příkladu byl Ereet schopen dosáhnout pouze jedenáctého skoku z obou otevřených a uzavřených portů. Takže tyto výsledky nelze použít k rozlišení stavů portů proti tomuto hostiteli. Stálo to za pokus a ve značném počtu případů to funguje. Je pravděpodobnější, že bude fungovat v situacích, kdy je prověřovacífirewall alespoň jeden nebo dva skoky před cílovým hostitelem. Scanme naopak používá vlastní firewall založený na Linuxiptableshost. Takže mezi filtrovanými a otevřenými porty není žádný rozdíl v počtu hopů.
Další technikou je vyzkoušet nástroje specifické pro aplikace proti běžným portům. Například proti portu 161 lze vyzkoušet brute force SNMP community stringcracker. S růstem databáze sond pro detekci verzí Nmapu se snižuje potřeba rozšiřovat jeho výsledky o externí specializované nástroje. Ty budou stále užitečné pro speciální případy, jako jsou zařízení SNMP s vlastním komunitním řetězcem.