What is Port Scanning?
Originally posted by Chuck McAuley
Port scanning is the one of the oldest mechanisms used in network security scanning, service assessment, and discovery. However, just because it's old doesn't mean its utility has diminished. Port scanning takes advantage of a network protocol's handshake as a service discovery mechanism. Port scanning typically refers to TCP or UDP port discovery, but it can relate to any network protocol, from the weird (SCTP) to the obsolete (IPX) to the most basic network building blocks (IP).
Here is an example of TCP port scanning:
Before you attack something on a network, you need to find it. Port scanning is the answer to finding assets across a network. Consider a standard webserver in a large network of 1000 IP addresses. It listens on TCP port 80. We need a quick way to find which IP address this host has. Looking at the TCP handshake protocol, we can find a quick way to figure out if a host is listening and available for a connection.
As you can see, to quickly test if a TCP socket is open, you can send a TCP SYN packet and then (based on the response) decide if it is open, closed, or filtered. If a server responds with the flags SYN and ACK set, this indicates that the port is open and the web server is accessible. However, if the server responds with an RST flag set, this indicates that the port is closed, which means there is no listening service. The third case, in which there is no response, means that it's indeterminate if the port is open or closed. The host was not be present (none allocated) or a firewall could be filtering that port. Filtered sometimes gets confused for "open but I can't reach it." Most of the time however, it is due to broad firewall policies that simply filter all ports that should not be listening, regardless of if there is a listening service or not.
Here is an example of UDP port scanning:
Port scanning UDP services get trickier, since they are not a connection-oriented protocol like TCP. UDP is a “lossy” protocol, which means that no response from the server is required before transmitting data. Instead of being able to scan with flags as seen above, you'll need to move up the stack into the application layer in order to detect if a service is available or not. A good example is DNS. In order to elicit a response from a DNS server, you need to formulate a query which the DNS server understands, otherwise it will simply discard the request.
Looking at the diagram above, we can see that if a host is not listening, it may respond with an ICMP error message of "Port Unreachable." However, based upon real-world testing data, most operating systems either ignore this capability or have it administratively disabled by default. This in turn makes hosts that are not actively listening appear the same as filtered hosts for the most part.
There is one more very important item to keep in mind. While I’ve described port scanning as an attack vector so far, you can turn the tables and use it as a proactive technique to discover your own security weaknesses. You may find some shocking insights, i.e. some holes that your predecessor, someone else in IT, the engineering department, or maybe even a previous security attack has left open. And if you find nothing, that is the best news yet. Now you can sleep easier. Happy Hunting!