Linux.com

A critique of port knocking

Port knocking is a method of "message transmission across closed ports." It works like this: initially a firewall blocks all ports on the server. The client issues a series of connection requests (knocks) to different ports; these are, of course, dropped since the ports are blocked. However, there is a daemon that monitors the log files for connection requests, and the sequence of requests serves as an encrypted code. If the code makes sense to the daemon, it enables SSH or another service (for a particular IP address and on a particular port encoded by the knock sequence).

Port knocking acts as an extra layer of security. It is also claimed to have the advantage of stealth: an attacker can't detect whether you're using port knocking or not.

But how effective is it?

Let's dispose of the stealth argument first. Suppose that port knocking becomes widely used (and surely that's the point of its existence?). Say it is running on 10% of all servers. Then an attacker simply assumes that the target machine is using port knocking and proceeds to attack it. The attack succeeds with a probability of one in 10 (of what it would have been if stealth were not employed), but those odds are worthwhile to the attacker, considering that the cost of the attack is far smaller than the expected gains from a successful attack. This kind of technique is quite common in port scanning -- crackers use multiple automated methods, each of which has only a small probability of success, but which taken together prove very effective.

The stealthiness of port knocking is limited in scope -- your machine appears uninteresting to someone who's scanning a whole range of IPs for open ports. A more dedicated attacker has a multitude of methods to infer that the target machine could be using port knocking, such as sniffing the (highly distinctive!) stream of packets in the knock sequence, observing that a machine known to host a service appears to have no ports open, social engineering, or even something as silly as finding a entry like "I got port knocking working today! w00t!" buried deep in the user's Weblog.

Security through obscurity is bad when it is the sole defense. This is true in a general theoretical sense, and there is always a cost associated with making the system more complicated in order to add an extra obscurity layer. In the case of port knocking, the hoops you need to jump through to achieve stealth far outweight the marginal benefits. Furthermore, there are much cleaner ways to achieve stealth, as we will see in a moment.

Once stealth is taken out of the equation, it becomes clear what port scanning really is. A port is not a physical object but merely a 16-bit integer. A sequence of knocks is therefore just a sequence of bits that lets you in -- in other words, a passphrase. So port knocking is simply a method to authenticate yourself with a passphrase. The obvious question then is, in what way is this convoluted and inefficient method of sending a passphrase across a network better than the straightforward method of putting it in a packet and sending it? The obvious answer is, it is not. (The second obvious question is, how is it different from authenticating yourself with a passphrase using SSH? But we'll get to that shortly.)

Think of security as an onion. If properly designed and implemented, each layer presents a new hurdle to the attacker. This is called "defense in depth." But the onion structure comes at a cost: it becomes much more difficult to analyze the security of the system. All too often, the layers serve as obfuscation and give you an illusion of security while leaving a single weak point open to an attacker.

To avoid falling into this trap, build your onion from standard components and to put them together in standard ways. On the other hand, everything about port knocking is about implementing crypto primitives in an obscure manner. If you're using a key, you call it a key. You gain nothing by calling it a sequence of port numbers; in fact, you lose a lot. When you think of a key as a key, it's clear that you shouldn't store it in any public location. On the other hand, log files (which contain the key in the form of port sequences) can lie around for ages. This is a typical example of how nonstandard terminology and implementation complicates analyzing the security of a system.

There are two reasons why a port knocking attacker may be thwarted: one is that only some ports are allowed in knock sequences (customized by the user) and the second is that the knock sequence can be encrypted with a password. The first defense is an extremely poor one. Security should reside only in knowledge of the key, and not in bits and pieces sprinkled throughout the system. That's Kerchoffs' law, often used as a rallying cry against security through obscurity.

The second defense is much better, but amazingly, it is presented as optional in the port knocking overview page. There is in fact little or no security in port knocking without encrypting knock sequences. Even with it, there are problems.

Firstly, the unnecessary only-some-ports-valid "protection layer" complicates things. Suppose you decide on a list of 32 valid ports (the current implementation allows up to 256). How long does the port knock sequence need to be? You might think that since each port is a 16-bit integer, you need 8 knocks, so that you get 8*16 bits or 128 bits of security (virtually unbreakable). But since each port has only 32 possible values (5 bits), what you actually get is only 8*5=40 bits of security (trivially breakable)! Granted, this is a problem for the implementer and not for the end user, and the current (proof-of-concept) implementation appears to take care of the length issue. But it is easy to go wrong. This is a particularly serious problem, since there is bound to be pressure on the implementer to make the knock sequence as short as possible, since it can easily take a minute to complete a port knock. When trying to reach a compromise between the two conflicting goals, security flaws result.

Secondly, there's the matter of what you're going to do about replay attacks. A replay attack is one where a router sitting between the client and the server passively sniffs what the client is sending, and sends the same bitstream after a while to the server, pretending to be the client. The standard defense is a challenge-response protocol, but that is of course ruled out because we don't want the server to send anything until the client authenticates itself. The documentation says that a flag field is added to the knock sequence and incremented for each port knock, preventing replay attacks. But this is nonstandard and dubious. What happens when the server is rebooted? What if the counter resets? As far as I can figure out, only a single-byte field is allocated for the flag, which makes resetting a real threat.

In general, port knocking has too many points of potential attack. In particular, anyone with non-root access to the server should be able to trivially break the system. This does not seem to be of concern to the developers.

Lessons from port knocking

There are several security lessons we can take from port knocking. There is a demand for barebones authentication system without bells and whistles that doesn't require maintenance. The problem with OpenSSH is that it tries to do everything. When designing a barebones system, it is essential to keep the target audience in mind and to decide the scope in terms of what features it will offer and what attacks it is designed to resist. I like the fact that the port knocking implementation is not written in C, a language which is subject to buffer overflow bugs. The approach of layering port knocking over SSH instead of replacing it is certainly sound. On the other hand, reinventing cryptography is definitely unsound.

Let us therefore take the port knocking out of port knocking and see what we get. It is a simple system for manipulating firewall rules based on standard password-based authentication and symmetric key encryption. By implementing this hypothetical daemon in a high level language and zealously resisting the urge to add any other features, we can greatly reduce the bugginess and possibly achieve a reasonable approximation to zero-maintenance. Stealth can be added: have the service run on a UDP rather than a TCP port. Since UDP is connectionless, the concept of closed and open ports is much weaker than for TCP. By having the application send out an ICMP_PORT_UNREACH message whenever a packet is received on that port (but nevertheless processing the packet), it can be made to look like a closed port to anyone who doesn't know the password. The extra obscurity might be useful if the overall system is simple enough. On the other hand we might forgo stealth and implement a challenge-response protocol instead to reliably stop replay attacks.

In conclusion, even though port knocking addresses a problem that many face, the solution is needlessly complicated and far from optimal.