Port scanning and Nmap 3.5

Inspired by the release of Nmap 3.5, the latest version of the award-winning network security tool, I’ve been exploring network security issues for a couple of weeks now. Nmap’s major skill is port scanning — learning which ports on a machine are “open” and what applications are using them. Sound network security planning dictates that you take a look at your network machines to see what the bad guys can see from outside.Think of a port as being an extension of a machine’s IP address. The IP address itself equates to a street address for an apartment complex. The port number equates to a specific apartment. When packets are sent across the Internet, they include the port number they are destined for as well as the machine address.

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.

Making and breaking the connection

To understand why you need to scan IP ports, it helps to know a little about how the networking protocol makes and breaks connections. When a TCP/IP connection has been established, each end knows the other’s IP address, port number, and the initial sequence number (ISN) the other will use. They learn this information about each other via a “three-way handshake.” Here is how two computers (A and B) negotiate the deal. A sends B a SYN request. The SYN request is directed at a specific port and includes the ISN A will use. If B is listening on the port, it sends A an ACK (acknowledgment) of the SYN request. The ACK includes the ISN B will use. If B is not listening on the port, it sends A a RST (reset) to indicate the connection failed. A sends B an ACK for the ACK B sent in response to the SYN request. When B receives the ACK, the connection is made. Note that as far as A is concerned, the connection is established when it receives the ACK from B. At that point, A knows everything it needs to know. That’s not true for B. This condition is called “half-open.” More on that later when we discuss stealth scans. Now let’s end the connection. Here is how the conversation goes when A decides to break it off with B. A sends B a FIN request, indicating it is finished sending data. B sends A an ACK for the FIN. B may or may not have additional packets to send to A. If it does, it continues the connection until they’ve all been sent. B sends A a FIN request of its own after all its packets to A have been sent. A sends B an ACK for the FIN. The connection is now officially closed. But note that once more we had a period of time (between the receipt by A of B’s ACK for the FIN and the receipt by B of A’s ACK) where the connection was in a “half-open” condition.

Of course, there isn’t anything to keep the bad guys from using Nmap too. Well, not all the bad guys anyway. A licensing change in Nmap 3.5 prohibits SCO from distributing the tool, as noted in the box at the bottom of this story.

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.

Nmap terminates SCO’s license

When Nmap 3.5 was released, the following paragraph was included in the Release Notes: SCO Corporation of Lindon, Utah (formerly Caldera) has lately taken to an extortion campaign of demanding license fees from Linux users for code that they themselves knowingly distributed under the terms of the GNU GPL. They have also refused to accept the GPL, claiming that some preposterous theory of theirs makes it invalid (and even unconstitutional)! Meanwhile they have distributed GPL-licensed Nmap in (at least) their “Supplemental Open Source CD”. In response to these blatant violations, and in accordance with section 4 of the GPL, we hereby terminate SCO’s rights to redistribute any versions of Nmap in any of their products, including (without limitation) OpenLinux, Skunkware, OpenServer, and UNIXWare. We have also stopped supporting the OpenServer and UNIXWare platforms. As you might expect, news of that termination of rights for SCO resulted in major posting activity on two of the Web’s most popular sites for geeks, Slashdot and Groklaw. I asked Fyodor by email what sort of feedback he received about the issue. He replied: Many posters suggested good angles for pursuing this and found damning SCO court filings, such as their claim in the IBM suit that “The General Public License (“GPL”) is unenforceable, void and/or voidable.” If they don’t accept the GPL, then they have no right to redistribute Nmap. And to claim that the GPL is invalid in the IBM case while arguing that it gives them valid rights to distribute Nmap would not only expose their hypocrisy but also leaves them vulnerable to equitable estoppel claims. Of course IANAL. As it stands, SCO has ceased distribution of Nmap from some of their sites, but it is still available from ftp.iso.caldera.com. I am evaluating my legal options. Refusing to support SCO systems has also been successful. I have convinced several people who have written me with UNIXWare/OpenServer issues to try Nmap on Linux instead. All of the email responses to these actions have been positive, except for one person who questioned rather the move is in compliance with the Open Source Definition. Fyodor went on in his response to point out that Eric Raymond replied to that question of whether or not excluding SCO was a violation of Paragraph 5 of the Open Source Definition by saying: The answer is no. OSD Clause 5 is intended to prevent discriminatory clauses from being written into licenses, not to prevent the enforcement of non-discriminatory licenses.”