Not the law, but a good idea.
Port knocking: a stealthy system for network authentication across closed ports
Port Knocking has not been seen on TV
port knocking > faq > security


Perl prototype: v0.30

  • pcaplib support added; daemon no longer requires firewall log file

2004-Nov-14 18:59 | ...more

new Net::Pcap support added to sniff packets directly ...more

Is port knocking secure?

Security is measured along a continuous scale. The only way to have a secure server (from the point of view of network security) is to disconnect the server. This is hardly a practical answer, however.

Port knocking can have the nearly the equivalent effect of disconnecting a server from the network. Since in the most secure use of PK, all the server's ports are rejecting packets, a sniffing client cannot detect the presence of the server by port probes.

Port knocking is another security layer. It adds to the security of a system and does not replace, nor require any modification of, existing password-based or key-based methods (e.g. SSH, IMAP).

If you manage to break into a port knocking system, you've simply peeled one layer of the security measure away. You are still required to authenticate yourself with the server's application. The fact that PK has been breached adds no information to assist in exploiting the protected application.

How should I approach security?

The approach to security should be pragmatic. In other words, ask yourself "What do I need to do to make my system as secure as possible while maintaining the ability to flexibly access the system?" Sometimes the balance should swing on the side of security, if you have very sensitive data or if the consequences of a system breach are unacceptable. At other times the balance should favour flexibility, if imposing strict security measures will negatively impact the indended function of your system.

The ultimate goal of a successful security system is not to make it impossible for someone to break into your system. The purpose is to prevent them from breaking into your system. Prevention may be done by deterrence of the attacker, frustrating the attacker, slowing down the attacker, misleading the attacker, or redirecting the attacker. Therefore, it doesn't matter why the attempted attack was not successful, as long as no attack is successful.

the system should deter attackers

Deterrence will remove the threat posed by attackers that are unsophisticated and/or unmotivated. Some attackers (script-kiddies) are simply executing tools created by others. If the tool fails to function in the anticipated way, the script-kiddie usually does not have the knowledge to continue the attack. Such attack scripts usually take advantage of well known exploit. On the other hand, unmotivated attackers may have the knowledge to break into your system but do not wish to expend the effort. Therefore, if the break-in is clearly difficult, these individuals will look for other targets.

the system should slow down the attacker

If the system is designed to be sufficiently difficult to break into, the motivated attacker will require time to gain access. Usually during the break-in there are signs which can be detected which indicate that a break-in is taking place. If the system forces the attack to be loud (e.g. easily detectable), an active reponse system can respond to the attacker. Responses may include blocking the attacker's IP, shutting down the targeted service, or closing all ports for a specified period of time.

the system should make the attack very loud

If the attack can be camouflaged as legitimate traffic, it is less likely that it will be detected. If the attack is forced to tranverse a "quiet zone", in which the attack is made obvious, the probability of detection is increased.

Consider this: where would you hide a $20 bill, if you wanted to detect anyone trying to take it? I would "hide" it in the middle of very large, very empty room. Everyone can see the $20, but it's very easy to detect whether anyone is trying to take it, because they have to make themselves obvious by walking across the room. Now suppose the lights were turned off and you had a infrared detector. Nobody could see the $20 but you could detect whether anyone was trying to look for it.

The analogous empty room in the context of port knocking is the set of closed ports. By looking for connection attempts to incorrect port sequences, something that can be done with intrusion detection systems like Snort, a portential attacker can be easily distinguished from legitimate knockers.

If my application is secure, why use port knocking?

Is your application really secure? It may be configured securely and you may have strict access control to who uses it, but there may exist undiscovered exploits in the application. If you leave your application port open to the public, you risk a break-in as soon as the exploit is discovered. If you filter incoming traffic and allow a select group of IPs to connect, you reduce your flexibility in granting access.

Port knocking wraps your existing security system in a layer which achieves security through an independent mechanism. This layer protects your application by making its port inaccessible to everyone, yet allows anyone capable of generating a valid knock to gain access. The application's existing authentication scheme is maintained, so users are still required to identify themselves to the application.

Can PK make a system less secure?

PK may make you feel that your system is more secure than it actually is. It may induce a false sense of security, leading to less frequent patching. These are not disadvantages of PK. PK increases the security of a system, but you still need to actively participate in monitoring your system and maintaining a baseline of security that you are satisfied with.

Isn't PK just a layer of obscurity? What if someone guesses or sniffs the knock?

The issue of obscurity is one that is frequently raised. It is a key issue to address. After all, what is the point of adding another token-based (the knock plays the role of a password) authentication method, when you already have such authentication from your application.

In order to address the obscurity issue, we have to work out what we mean when we say "security by obscurity". Clearly, when we say "security by obscurity" we do not simply think about a password protected system and the possibility that the password can be guessed. Nearly all security systems function on a password, or generally an authentication-token method, yet not all these systems work by means of obscurity.

Even if the password is completely trivial (e.g. 0 or 1), then the system does not necessarily work through obscurity. Nobody is going to say that the 0/1 password system is secure. The system is not secure but it is also not obscure. It is, however, a system with a very poor choice of the complexity of the password. Obviously, the authentication token shouldn't be trivial to guess. It should be complex enough so that a brute-force approach or an offline dictionary attack will take a frustratingly long amount of time.

To emphasize, a security system predicated on the users' possession of secret knowledge (secret password, secret token, etc) is not necessarily an obscure one. In order to be obscure it usually must also lack access control, monitoring, and logging facilities. In other words, the administrator of the obscure system, after implementing the obscurity (e.g. a hard to guess URL for a web page), walks away with the assumption that the system is safe simply because the secret knowledge is hard to guess.

If secret knowledge were sufficient to characterize a system obscure, it might seem that applications like telnet, therefore, should fall in this category. After all, if someone guesses my telnet system password, they could gain access to the system. Since most people choose insecure (i.e. common) passwords like "password", or "letmein", or maybe a birthdate of someone they know, a large number of passwords can be guessed. Furthermore, if the encrypted version of the passwords can be obtained, a brute-force dictionary attack (e.g. John the Ripper), can quickly discover many more passwords. Regardless of the fact that my password _may_ be guessed, telnet and other network services are not protected by obscurity because they are part of a larger system which is designed to address security methodically, including monitoring access, the ability to grant/deny access and to change the password on an individual basis. Obscurity is that small part of a successful security system - the secret knowledge. When it is complemented by individualized access control, logging and monitoring then the system ceases to be obscure.

Can a password-based system be obscure?

Yes. If a system administrator felt that their users were strained to remember their passwords, and assigned everyone the same password, then wrote the password on a sticky note and stuck it underneath the case of the server – that's obscurity. Potentially, someone may stumble across the crib sheet and figure out that this is a password. Conveniently, it is already attached to the server to which the password grants access.

Look at it this way: when do you discover that you broke into a system ruled by obscurity? The answer is: when you happen stumble across a password, or any other secret, while you're looking under the server case. Note that stumbling here does not mean guessing for a million years until you inevitably find the correct password. To continue with the example, suppose that the secret password under the server was discovered. Given this particular admin's approach to security, it's probable that the discovery would never be detected. Furthermore, would the admin detect a change in his system that would indicate that the password was being used by illegitimate users? Again, probably not. Implementing obscurity is usually followed by a phase of complacency.

Is port knocking susceptible to DoS attacks?

No more than regular services. Any physical system offering a service will have a load limit. No matter how much hardware or load-balancing you throw in, there will always be such a limit. An application or the TCP/IP stack of a server may be overloaded with requests regardless whether PK is being used.

PK works by keeping a queue of ports associated with client IPs. Everytime a client performs a knock, its queue is augmented with the port's number and then analyzed for the presence of a valid knock. One client does not have the ability to swamp out the queues of other clients, unless the server becomes so overloaded with knocks that it can no longer capture the incoming packets. However, at this point any system would be affected.

PK can be made more robust by implementing it internal to the firewall, rather than running it as a separate process that monitors the log file (see below).

Is port knocking susceptible to replay attacks?

By encrypting the knock, you protect yourself against replay attacks. When the knock is protected, even if it is intercepted, the third party would need to decrypt the knock to adjust it for their purposes.

Additionally, you can protect yourself from replay attacks by

  • programming the monitoring daemon to accept a given knock only once
  • create a parametrized schedule, used to modify a part of the knock in a deterministic manner known only to you. A knock must adhere to the schedule, or be deemed invalid.
  • use one-time pads
last updated 2005-Aug-03 13:40
Port Knocking (c) 2002-2019 Martin Krzywinski