Note: This is part of a series on BackTrack 5 tool reviews. It is not meant to be an exhaustive analysis of any tool, just a demonstration of the tool using real-world targets.
No, I'm not going to review "Nmap" in a single blog post; you could write an entire book about Nmap (Fyodor did, you should buy it).
This post is based upon a recent client experience: you run a UDP scan and you get the dreaded open|filtered. In the scan below, some UDP ports appear to be open (111, 177, 2049), but all others are open|filtered, which means Nmap doesn't know:
nmap -sU ###.###.###.### -p 1-65535
--- snip ---
PORT STATE SERVICE
67/udp open|filtered dhcps
69/udp open|filtered tftp
111/udp open rpcbind
123/udp open|filtered ntp
177/udp open xdmcp
514/udp open|filtered syslog
657/udp open|filtered rmc
832/udp open|filtered unknown
2049/udp open nfs
2279/udp open|filtered xmquery
3161/udp open|filtered unknown
32820/udp open|filtered unknown
32825/udp open|filtered unknown
32827/udp open|filtered unknown
32870/udp open|filtered unknown
32871/udp open|filtered unknown
32872/udp open|filtered unknown
32897/udp open|filtered unknown
-- snip --
Obviously, this isn't very useful. The goal here is to disambiguate open ports from filtered reports. One way to do that is to add service detection (-sV):
nmap -sU -sV ###.###.###.### -p 1-65535
-- snip --
PORT STATE SERVICE VERSION
67/udp open|filtered dhcps
69/udp open|filtered tftp
111/udp open rpcbind 2-4 (rpc #100000)
123/udp open|filtered ntp
177/udp open xdmcp XDMCP (willing; status: 6 users load: 14., 14., 12.)
514/udp open|filtered syslog
657/udp open|filtered rmc
832/udp open pcnfsd 1-2 (rpc #150001)
2049/udp open nfs 2-3 (rpc #100003)
2279/udp open|filtered xmquery
3161/udp open snmp Lexmark SNMP service
32820/udp open rpcbind 2-4 (rpc #100000)
32825/udp open pcnfsd 1-2 (rpc #150001)
32827/udp open cmsd 2-5 (rpc #100068)
32870/udp open mountd 1-3 (rpc #100005)
32871/udp open mountd 1-3 (rpc #100005)
32872/udp open status 1 (rpc #100024)
32897/udp open nlockmgr 1-4 (rpc #100021)
-- snip --
You can see here that a number of additional services are running which we could not detect with the simple UDP scan. One additional thing you can do is add the --reason switch, which describes which discovery test the port responded to:
nmap -sU -sV ###.###.###.### -p 1-65535 --reason
-- snip --
PORT STATE SERVICE REASON VERSION
67/udp open|filtered dhcps no-response
69/udp open|filtered tftp no-response
111/udp open rpcbind udp-response 2-4 (rpc #100000)
123/udp open|filtered ntp no-response
177/udp open xdmcp udp-response XDMCP (willing; status: 6 users load: 14., 14., 12.)
514/udp open|filtered syslog no-response
657/udp open|filtered rmc no-response
832/udp open pcnfsd udp-response 1-2 (rpc #150001)
2049/udp open nfs udp-response 2-3 (rpc #100003)
2279/udp open|filtered xmquery no-response
3161/udp open snmp udp-response Lexmark SNMP service
32820/udp open rpcbind udp-response 2-4 (rpc #100000)
32825/udp open pcnfsd udp-response 1-2 (rpc #150001)
32827/udp open cmsd udp-response 2-5 (rpc #100068)
32870/udp open mountd udp-response 1-3 (rpc #100005)
32871/udp open mountd udp-response 1-3 (rpc #100005)
32872/udp open status udp-response 1 (rpc #100024)
32897/udp open nlockmgr udp-response 1-4 (rpc #100021)
-- snip --
Lastly, a somewhat unrelated tip: I didn't include it here for reasons of space, but I always use the -v (verbose) option. Always nice to have more information, especially when documenting your penetration test.
No comments:
Post a Comment