A portscan is an attempt to discover information about the network
on one or more hosts
by opening connections to multiple
and UDP ports
. Since a host will respond differently on
a port if a service is running, and since there are only 65536
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
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.
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
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.