Nmap, if you are a practitioner in the computer security field, then you know about nmap. Basically nmap is free quick and easy to use port scanner. I have no qualms about the program, but what people must learn is that there is a time to use nmap and a time not to.
Just to give some background, computers have software ports, these ports are used to map data to a particular process on a computer. For example, when you browse the web your computer uses port 80 to query web servers in order to receive the web pages. For every process that you have running on your computer that transmits and receives data across the network, there is a specific port associated with it. So in theory using a port scanner allows us to determine the processes that are running. This in turns allows us to determine if any vulnerable services are running. Now port scanning is performed on TCP and UDP ports, because these are the two protocols designated by IP
Now for TCP protocol port scanners work really well, because as part of the protocol there exists the three-way handshake. Your computer sends a packet to say hi (SYN) and the other computer answers back ( hi (SYN-ACK), and then your says lets transfer some data (SYN-ACK-ACK). So for TCP port scanning unless a firewall is filtering or blocking the target computer, it will answer back on all open TCP ports to SYN packets.
Now for UDP there is no handshake process, basically a UDP service just accepts all data it receives and processes it with no response back to your computer. So unless the UDP service is set to answer back or the operating system sends a message saying that port is closed, you will never know the status of a UDP port.
Back to my compliant, I deal with computer security people on a daily basis. I am not knocking them, but at least 50% think that nmap is the be all end all in the security world. We receive software to test, we load it up and the first thing they want to do let’s run nmap. My response is why? – for some reason by running nmap makes you some super uber hacker – hey look guys I can run nmap yeah!
Our setup:
- we are in a network lab and not on an operational network, so we have control of all resources on the network
- we are dealing with <3 machines, with admin access to each machine
Remember a port scan is only useful if a port answers back, and we can track that port back to a single process (For uber hackers, at least ensure the software is running when you perform a port scan)
Countless times, I receive responses that this software does not use any network resources, because we ran nmap and there were no ports showed up.
My first two questions:
- Did you have the software running during the port scan? (usually No)
- Is the firewall blocking your scan? (usually I don’t know)
Then the response…But I can run nmap so I am an uber haxor!
So what do I suggest, why not netstat, yes the built-in windows utility (same for linux). If you are in a testing environment, and you only have a few computers to determine open ports – why even consider nmap. Netstat –nb will give you all the open ports and the process that opened it. I know running netstat is not as cool as running nmap, but with netstat you don’t have to rely on the computer to answer you back. So there is no guess work with determining if a port is open.
But ecore what about software that only opens a port every so often to communicate, guess what you can script netstat to run every so often. netstat –nb 5 > log.txt , will write all port information into the log file every 5 seconds (If you are doing this consider using a protocol analyzer.. WireShark).
Point is if you are trying to determine ports on a computer you have admin access to, nmap is not the way to go. Reserve nmap for those remote scans or when you have to test hundreds of computers. Part of being an 31337 uber haxor is knowing when and when not to use your tools.
Friday, November 23, 2007
Nmap - not for every occasion
Posted by
ecore
at
10:10 AM
Labels: computer security, networking
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment