Linux.com

Web servers normally listen on port 80, for example. Port 80 is a "well-known" port number, meaning that is where Web servers are usually found. But port numbers are not set in stone. If you're running a private Web site that you only want your friends to visit, you might decide to have it listen on some other port, and tell only your friends what that port is. Very sneaky -- but not sneaky enough. These days port scanners can identify applications regardless of the ports they use.

As a matter of fact, one of the major improvements to Nmap 3.5 is (quoting from the CHANGELOG), "Integrated a ton of service fingerprints, increasing the number of signatures more than 50%. It has now exceeded 1,000 for the first time, and represents 180 unique service protocols from acap, afp, and aim to xml-rpc, zebedee, and zebra."

If the bad guys know what applications you have exposed to the Internet, the only thing standing between them and your root password is an exploit for the one you're running. There may not be an exploit -- or a gap between exploit and patch -- to let them in today, but who can say about next week. That's one reason for the rampant scanning activity on the Net these days.

Fourteen ways to scan your lover

Nmap 3.5 provides more than a dozen methods to scan a target. They range from the simplest and fastest (the TCP Connect scan) to those conducted with the aid of an unsuspecting third party, like the FTP Bounce and the Idle scans. Here is a brief recap of some of the scan types covered in that paper that are found in Nmap 3.5.

TCP Connect -- Tries to establish a connection on every port being probed. Simple, fast, and does not require root access. Also very obvious and likely to set off alarms at the distant end if any intrusion detection system is being run.

TCP SYN -- Tries to determine if ports are open or not without establishing a connection. Nmap begins the three-way handshake described above, but if it receives an ACK to its SYN request, it aborts the negotiations by sending a reset (RST). And why not? It already knows the port is open because it received the ACK. This is a so-called "stealth scan" because it isn't quite as visible in the logs of the target simply because a connection wasn't made.

TCP FIN -- This is another stealth scan, and is even sneakier than the SYN scan. Nmap sends the target a FIN request as if to close a connection, knowing full well, of course, that there is no connection to end. Well-mannered implementations of TCP will respond with an RST if they are not listening on that port and simply ignore the FIN if they are. Fyodor pointed out in his paper that Microsoft boxes are broken in this regard and send an RST in either case.

FTP bounce -- This scan brings a third party into the picture. It relies upon FTP servers that allow proxy FTP connections to work. Thus the scan of the target is done by the FTP server, not your box. After you locate a compliant FTP server, you tell it to send the data to a specific port on the target machine. The response tells you whether the port is open or closed on the target machine. Fyodor noted in his paper that "The advantages to this approach are obvious (harder to trace, potential to bypass firewalls). The main disadvantages are that it is slow, and that some FTP servers have finally got a clue and disabled the proxy 'feature'."

Attackers, targets, and zombies, oh my!

Nmap's author, known as Fyodor, wrote a paper called The Art of Port Scanning in 1997. It's a great place to start learning about the various types of scans. The definitive source for learning about Nmap itself is the product's man page. From it, we can learn a little about the "idlescan" technique, which provides a truly blind port scan of the target. Actually, this particular form of attack is important enough that Fyodor also wrote a separate informal paper on it.

Like FTP bounce, idlescan requires a suitable partner, called a "zombie" host. Following Fyodor's lead, we will refer to three machines as the Attacker, the Zombie, and the Target. Here is how it works:

• The Attacker sends the Zombie an IPID request.
• The Zombie responds with its current IPID (in Fyodor's elite example, the IPID was 31337).
• The Attacker sends a forged SYN request to the Target, using the Zombie's IP address.
• The Target replies to the Zombie with either an ACK if the port is open or an RST if not.
• If the Zombie receives an ACK from the Target, the Zombie replies with an RST and increments its IPID. If it receives an RST, it does nothing.
• The Attacker sends the Zombie another IPID request.
• The Zombie responds with its current IPID. If it is 31338, the Attacker knows that the port on the Target is closed. If it is 31339, it knows it is open.

Obviously, this technique requires two things of the Zombie host in order to work correctly. It must be idle, so that its own traffic doesn't increment the IPID number, and it must have a predictable IPID scheme. Fyodor notes in his paper that "Printers, Windows boxes, older Linux hosts, FreeBSD, and Mac OS boxes generally work fine" as Zombies.

Lest you think that Fyodor is producing Nmap only for black hats and other bad guys, let me point out that the informal paper he wrote on idlescans states:

I assumed that a problem of this magnitude would generate an immediate response and patches from the OS vendors. Unfortunately, many have chosen to ignore the problem for years. Apparently, they believe this is just a "theoretical" issue which is not practical to exploit in the real world. To refute that position, and increase the pressure on vendors to fix the problem, I have released a robust Idlescan implementation in recent versions of Nmap. This paper describes the technique in detail and offers defenses that network administrators, ISPs, and OS vendors can use to mitigate the vulnerability.

Conclusion

Nmap is great. I'll be the first to admit that on the NASCAR circuit, putting Nmap and me together would be seen as a clear case of "more car than driver." That's proof you don't need to be a TCP guru to use and appreciate Nmap.

Nmap is one of the jewels of the free software world. It probably does as much or more to help network administrators find weak spots in their defenses as any tool at their disposal. It's getting easier to use and more powerful all the time. This may alarm some, especially when they think of all the wannabe crackers and script kiddies out there using it for recon. But they were scanning systems before Nmap arrived and they will be scanning systems after it's gone. I, for one, am simply grateful that Fyodor is on our side, not theirs.

Share    Print    Comments