Scansione UDP migliorata in Nmap 5.2x
by admin on Feb.04, 2010, under Hacking, Linux, Sicurezza, Tools
Le particolari caratteristiche protocollari fanno sì che la scansione UDP risulti più problematica della corrispondente TCP, ed inoltre pesantemente dipendente da ICMP.
Il metodo “tradizionale” della scansione UDP implica l’invio di un datagramma UDP alla porta di destinazione. Se viene restituito un messaggio di errore ICMP Type 3 Port unreachable, allora la porta viene considerata “closed”.
Differenti tipi di messaggi ICMP possono invece indicare una porta filtrata.
Una scansione UDP fa cioè affidamento sui messaggi diagnostici ICMP al fine di determinare lo stato di una porta remota.
Firewalls che bloccano il traffico ICMP in uscita impediscono perciò alle scansioni UDP di restituire alcuna utile informazione.
Le porte UDP in stato “open” di solito non rispondono all’invio di datagrammi UDP dal momento che non esiste nel protocollo di trasporto, che è “stateless”, alcun meccanismo che preveda l’instaurazione di una sessione.
Se la applicazione in ascolto non riuscisse ad interpretare il contenuto del pacchetto, potrebbe rispondere con un messaggio di errore, ma più probabilmente scarterebbe il pacchetto e non risponderebbe affatto.
Le eventuali risposte a datagrammi UDP sono quindi delegate al livello applicazione.
Per quanto non possa essere assunto come un metodo generale valido per rilevare porte “open”, è proprio in questo che consiste il miglioramento alla scansione UDP apportato in nmap a partire dalla recentissima versione 5.20 (peraltro subito sostituita dalla versione 5.21, che ne corregge solamente alcuni bug).
In altri termini, una scansione UDP di una porta DNS (udp/53) consiste in una valida richiesta dns, mentre quella di una porta NTP in una altrettanto valida richiesta NTP.
Il differente comportamento di nmap rispetto alle versioni precedenti è immeditamente visibile.
Utilizzando infatti una versione precedente (5.0) si ottiene:
# nmap -sU -PN -p 123 ntp1.ien.it
Starting Nmap 5.00 ( http://nmap.org ) at 2010-02-04 10:20 CET
Nmap scan report for ntp1.ien.it (193.204.114.232)
Interesting ports on 193.204.114.232
PORT STATE SERVICE
123/udp open|filtered ntp
[...]
mentre ora si ottiene:
# nmap -sU -PN -p 123 193.204.114.232
Starting Nmap 5.20 ( http://nmap.org ) at 2010-02-04 20:08 CET
Nmap scan report for ntp1.inrim.it (193.204.114.232)
Host is up (0.047s latency).
PORT STATE SERVICE
123/udp open ntp
[...]
ed anche un trace effettuato tramite nmap evidenzia un regolare dialogo protocollare:
# tcpdump -t -i ppp0 host 193.204.114.232
[...]
Client, Leap indicator: clock unsynchronized (192), Stratum 0, poll 4s, precision -6
Root Delay: 1.000000, Root dispersion: 1.000000, Reference-ID: (unspec)
[...]
Server, Leap indicator: (0), Stratum 1, poll 4s, precision -18
Root Delay: 0.000000, Root dispersion: 0.000091, Reference-ID: UTCI
[...]
Se infatti nel primo esempio viene inviato alla porta udp/123 un pacchetto vuoto, ed il server NTP semplicemente lo scarta, nel secondo si ha l’invio di un pacchetto contenente un valido payload NTP.
Attualmente nmap 5.21 supporta degli specifici payloads per i seguenti protocolli:
udp/7 echo
udp/53 domain
udp/111 rpcbind
udp/123 ntp
udp/137 netbios-ns
udp/161 SNMP
udp/177 xdmcp
udp/500 ISAKMP
udp/520 route
udp/1645 RADIUS
udp/1812 RADIUS
udp/2049 NFS
udp/5353 zeroconf
udp/10080 amanda
ma è facilmente prevedibile che il gruppo sia destinato ad ampliarsi.
