Of course you’ve heard about the baddies out there who will try to scan the ports on your server to see which ones they can access. But there’s a lot more to port scanning than just getting a list of the ports that reply. So what other sort of information can be found out, what can you do about it, and how do you test your server for vulnerabilities yourself?

Basic port scans
If you have a properly configured firewall and network and host IDSs, you shouldn’t have to worry about any of these. If you don’t, this is what people might be doing to your hosts. Most of these will be preceded by a ping sweep, to identify hosts to interrogate, but not all scanners do this by default nowadays, so don’t rely on that as your early warning system.

TCP connect - the basic form of port scanning. The scanner tries to open a TCP connection to every port on the box. If the port is open, this will work: if it’s closed, it won’t. Quick and easy, it should also be easy for you to stop with a firewall, or detect using network IDS, or even the logs of the host itself, since it will show a large number of connections that are immediately shut down. Watch that scanners nowadays can run multiple scans on one host in parallel and won’t necessarily work through the ports sequentially.

TCP SYN - scanners send a SYN packet, to which a host will either reply with a SYN/ACK if the port is open, or a RST if it’s not. This isn’t a proper connection so host logs might not report it - your IDS should though.

TCP FIN - if your firewall only blocks non-established SYNs, but does nothing to FIN packets, you may get hit with this one. This works differently to the scans above, in that a closed port will reply with a RST, while an open port will typically ignore it. If it’s a Windows device, however, it will probably reply with a RST regardless of port state, which, if used in conjunction with one of the other scans, will give the scanner a good idea what type of platform he’s dealing with.

UDP ICMP - sending a UDP packet to a closed port will usually (though not always) result in an ICMP port unreachable error message being returned. Like TCP FIN, by identifying the closed ports, you can determine the open ones.

OS and version detection
If someone wants to do something clever to your hosts, they will need as much information as possible about the OS running, and which version, so that they can exploit any relevant security vulnerabilities.

Scanners can use TCP stack fingerprinting to gather enough information to be able to determine what OS is running. Each stack does things just a little bit differently, in the way each creates sequence numbers, uses timestamp values or reacts to the TCP options fields - do enough probing and you can tell not just whether it’s a Windows or Linux box, but also pretty much which version too.

Of course, you can save potential intruders all this extra work if you just don’t bother to change your default banners.

For example, an attempted telnet will often result in something like the following:

Trying x.x.x.x (address removed to protect the careless) ...
Connected to hpux.test.ac.jp.
Escape character is '^]'.

HP-UX hpux B.10.01 A 9000/715 (ttyp2)

login:

While a determined attacker can probably find ways to extract this information, as described above, why make it easy for any casual, less sophisticated intruder?

Idlescanning
All of the scans mentioned so far have been initiated from an intruder’s PC somewhere out on the Internet. You may have your firewall configured to be able to stop most of these probes. So they’ve thought of something else. This is one way that port scanning can seem to come from a trusted device, and so stand a better chance of being answered.

It all revolves round IP identification numbers. When you communicate with a device, the header will contain an ID. If an attacker’s PC probes a host, it will find out, among other things, the ID number it’s using at that time.

The attacker can then, theoretically, probe a second device belonging to the same organisation - the real target - pretending to be the first ‘trusted host’. It may have more success than using the above techniques directly, since the traffic seems to come from a trusted source. If it sends a TCP SYN, then the target device will reply to the ‘trusted host’ with a SYN/ACK. Of course the host won’t have been expecting that, since it didn’t actually try to initiate a session, so it’ll send a RST and clear the connection.

So how does this help an attacker? Many systems just increment the ID number sequentially with each packet transmitted, so if the attacker now probes the ‘trusted host’ again, the ID number on the reply packet will have incremented by two if the above scenario was followed. Once when it sent the RST to the real target, and another time to reply to the attacker’s device. This way, even though the attacker doesn’t directly receive a reply from the target, it knows that one was sent, so can infer that the port it attacked was open.

Now assume that the port attacked was closed. The target would instead have sent a RST to the ‘trusted host’, which would have just ignored it. This time, when the attacker probed that host, the reply would have had the ID incremented by just one (since it wouldn’t send a reply to the RST).

This has the obvious effect that any attack seems to come from a device other than the one it really did. This means that if your IDS does pick it up, you may spend ages looking at the wrong device. It’s also more likely that traffic will be let through, as it seems to come from a known source.

To prevent this type of attack it is essential therefore that you implement IP spoofing at the network edge, and also make use of stateful firewall rules. Since the success of this type of attack hinges around the predictability of the IP ID, using systems that don’t succumb to this (mainly newer versions of Linux and Solaris) would be best, although not necessarily possible.

Port scanning tools are freely available (NMAP being one of the most common), and while we think of them as hackers’ toys, it’s well worth trying them out on your own network to see what kind of information you’re giving away about your servers.