The process of initiating a series of connections to a remote host on pre-defined port numbers, in order to determine which of the ports are "open", thereby giving a suggestion of what services might be running on that host. Port scanning is often used by crackers to glean information about a potential victim. Port scanning can also be a useful tool for network engineers attempting to troubleshoot a bothersome network.

There are many different types of port scans, ranging from the stealthy to the overt.

The primary types of port scan, according to Fydor's "The Art Of Port Scanning" (Phrack Magazine Volume 7, Issue 51 September 01, 1997, article 11) are as follows:

" - vanilla TCP connect() scanning,
- TCP SYN (half open) scanning,
- TCP FIN (stealth) scanning,
- TCP ftp proxy (bounce attack) scanning
- SYN/FIN scanning using IP fragments
- UDP recvfrom() scanning,
- UDP raw ICMP port unreachable scanning,
- ICMP scanning (ping-sweep), and
- reverse-ident scanning.
"

You should be aware that doing a port scan, while harmless in itself, is often considered an aggressive act by network administrators.

There is some debate as to whether a port scan can be considered a form of attack, as it does not involve any actual breaking in. It is however often used for preparing an attack, and therefore considered an aggression, much like someone trying all the doorknobs in an appartment building to see which appartments are locked.

So only try to port scan computers where you know the administrator does not mind (or if you're sure you will not be found out).

A portscan is an attempt to discover information about the network services on one or more hosts by opening connections to multiple TCP and UDP ports. Since a host will respond differently on a port if a service is running, and since there are only 65536 total ports, one can relatively quickly characterize a host's services by portscanning. At the same time, a host's responses can tell you facts about the kind of operating system or network stack it is running.


Portscans and Security

You will usually hear about portscans in the context of network security. A cracker attempting to break into a given host will often portscan that host in order to discover possible attack paths. Since every network service a host is running represents a possible path of attack, the portscan results are essential intelligence to an attacker. A script kiddie looking to break into as many hosts as possible with a single script, on the other hand, is likely to use a different sort of scan: scanning a large number of IP addresses on a single port. This is sometimes called an "address scan" or breadth-first portscan.

Because portscans are so frequently used by attackers, sysadmins and security technicians see them almost invariably as preludes to attack. As a result, even though you might consider portscanning someone else's host out of curiosity, this is probably not a good idea. On the other hand, portscanning your own hosts from a remote system can be a useful way to make sure that you are not exposing unnecessary services.


Types of Portscan

The most common type of portscan is also the most primitive, and is known as a TCP connect scan. In this scan, your scanning program attempts to open a socket to each possible target port (whether on one machine or several). On Unix and POSIX systens, this is done with the connect() system call; hence the name. Your program can tell if a port is open on the target host quite easily: if the connect() succeeds, the port is open; if it fails, the port is closed or filtered.

Simple enough. However, a TCP connect scan does not always work. For starters, it depends on the TCP three-way handshake working predictably: that is, the remote system must either accept the connection or return an ICMP packet indicating refusal. If the remote host sends back nothing -- for instance, if it's behind a firewall -- then you wait. And wait ... until TCP opening timeout, which is usually around 30 seconds. That's a potential wait of 30 seconds per port, and you've got 65535 of those to do.

As a result, people have invented other kinds of portscans, which do not use the OS implementation of TCP. Instead, they send custom-crafted packets which elicit a response from the target system's TCP stack. By sending a SYN packet, for instance, one pretends to be a client system attempting to set up a connection. A SYN ACK packet in response indicates the port is open, while an ICMP error packet indicates it is closed. A program can easily test several thousand ports in parallel in this fashion -- or the same ports on several thousand hosts at once. Other sorts of packets besides SYN can be used, though responses can vary from target OS to OS.

You may have noticed that all the above scans cover TCP services only. Scanning for UDP services is trickier, because UDP is by nature connectionless -- there's no standard setup negotiation as there is for TCP. A listening UDP service may respond with a UDP datagram in response -- and a closed UDP port still responds with an ICMP error. It may not be possible to tell a filtered UDP port (one blocked by a firewall or other obstruction) from a service that simply accepts a datagram and doesn't respond.


Defense against Portscanning

Since portscanning is so commonly a prelude to attacks, it is useful to consider defenses against it. Though it is commonly said that security by obscurity is inadequate defense, it is equally true (as Sun Tzu might have put it) that denying an attacker intelligence about your forces is one part of defending yourself.

The butt-obvious way to stop a portscan from discovering target ports on your system is to not have the target ports open or accessible. Closing down unnecessary services is essential to security these days. A firewall -- as well as host-level policy tools such as TCP Wrappers or Linux iptables -- can selectively allow and deny access to ports and hosts.

It is also possible to detect and respond to portscans. Portscan-detection software has been around for years; one early program to do it was written in Perl and called courtney. Many models of integrated firewall -- such as those made by Netscreen -- can flag activity as a portscan if a remote host attempts to connect to large numbers of ports on a client system quickly, and block the scan in progress. This is no defense against a slow portscan, but it will discard those done by most quick attacks and worms. A network intrusion detection system, or NIDS -- such as Snort -- can also detect portscans for manual investigation.

Another more recent defense against portscans -- at least, against the simple connect scans and SYN scans -- is to slow down the rate at which the OS sends back ICMP error messages in response to SYNs on closed ports. In recent versions of the Linux kernel, these errors will be sent out no more often than once every half-second to any one client host.


Portscanning Tools

Okay, so how do you do a portscan? There are several tools available to do the job. The most popular by far on Unix-like systems is called nmap, for "Network Mapper". It can do several flavors of TCP scan, using different kinds of packets as described above. It can also scan for UDP services. There are various other tricks up its sleeve, such as emitting bogus packets to confuse a person looking for scans, or scanning very slowly to confound portscan detectors.

If you use Mac OS X, you might be amused at this point to note that Apple has written a portscanning tool right into one of the built-in utilities, the Network Utility. You can find this in the Applications:Utilities folder. The Network Utility has a nice range of standard Unix network exploration tools in a convenient GUI layout: ping, traceroute, whois, finger ... and right there on the last tab, "Port Scan".

How nice of them.

Log in or register to write something here or to contact authors.