Keep your ports open - for yourself.
Port knocking: a stealthy system for network authentication across closed ports
Port Knocking has not been seen on TV
port knocking > about > obscurity

Port Knocking

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

Learn about firewalls and discover port knocking. Find out how to use port knocking to secure your servers with a Perl prototype or other implementations. Play with knocks in the knock lab. Contribute to the port knocking project. See what others are saying. Is port knocking a form of security through obscurity? The author doesn't think so and also has some other opinions.

Logos and Banners

Port Knocking (c) 2002,2003 Martin Krzywinski Port Knocking (c) 2002,2003 Martin Krzywinski

Port Knocking (c) 2002,2003 Martin Krzywinski

Port Knocking (c) 2002,2003 Martin Krzywinski

Port Knocking (c) 2002,2003 Martin Krzywinski

More images are available.

Is port knocking an obscurity hack?

It has been pointed out by some that port knocking is a form of security through obscurity. I don't agree with this interpretation, for reasons outlined below.

The concept of security through obscurity is well described (local copy) by Jay Beale of the Bastille Linux Project. This article was written independently of port knocking and I'm using it here to help define the notion of obscurity. Jay writes (emphasis is my own)

First, what does the security professional mean by bad "security through obscurity?" We really mean "security implemented solely through obscurity." This describes the state where your entire method of security resides in hoping that the attacker doesn't know something about the setup of your network, computer or program. One simple case is where you put your company's secrets on an internal webserver, with no password-protection on the pages. Instead of relying on passwords or another acceptable method of access control, you're relying on something different. You're assuming that no one will know about that webserver except for the internal company employees who you've told. This almost seems like a decent assumption, except that anyone with some network discovery tools (like cheops, firewalk, snmpwalk and nmap) can find just about every webserver on your network. See, the problem is that you've used the obscurity of the data's location as your sole method of access control. This just doesn't work. While some attackers will never expend the effort to find that webserver, many others can and will. Those will obtain access to information that you wanted to keep them away from.

Security Through Obscurity" Ain't What They Think It Is
by Jay Beale (local copy)

Bob's Secret URL

There is a strong negative connotation with the notion of achieving security through obscurity. To mind springs the image of a system administrator who, being less clever than they think, hides their sensitive knowledge in the vast phase space of potential locations, such as an obscure URL while knowing (hoping) that nobody will be able to access the information. For example, suppose Bob puts up a super secret document on his web server at the URL

and assumes that his information is safe because, after all, nobody could simply guess the URL. This is security through obscurity and it is not safe.

But why is the information at this location not safe? What is the difference between this form of protection and a password protected SSL web site with the password "2039482919384829293842882838491". After all, are these forms of protection not equivalent? In one case, someone has to guess the URL and in the other someone would have to guess the password. Since these are both complex strings, one could argue that Bob's complex URL achieves the same protection.

Or does it? Suppose Mary, one of Bob's trusted friends, knows the secret URL. She goes to the web site, reads the document and clicks on a link on Bob's page that brings her to another location. Since the server Mary browses to records the referer, suddenly Bob's secret URL appears on someone's log file. Oh-oh. - - [06/Jul/2003:17:02:34 -0700] "GET /index.html HTTP/1.1" 
200 23765 "" 
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 1 -

After all, Bob's method is not equivalent to the password composed of the same characters on an SSL-enabled web page. For one, Bob's method does not involve any encryption permitting anyone to intercept and learn the URL.

Access Control

Security through obscurity relies on protection through a controlled secret, such as the complex URL above. However, forms of security categorized as "through obscurity" do not implement access control, logging, or an active defense mechanisms. If they did, they would no longer be depending solely on obscurity.

Bob's system is likely not set up to monitor whether (a) someone is trying to guess the secret URL, or (b) someone has already guessed the URL, or learned the secret somehow, and has viewed the page. Bob's system has a single secret which does not allow a finer-grain control over who can view the document. An important feature of any security system is that access can be finely controlled and breaches can be detected. It would be disasterous, more so than hiding secrets poorly, if your secrets became unwittingly public.

Port knocking relies on a secret - the secret knock. This fact does not make port knocking an obscure system. First, the knock should be encrypted to make it more difficult to deconstruct it and reassemble the knock information with a malevolent payload. Second, port knocking is fully compatible with the notion of access control. The knocking daemon monitors knock attempts by way of a firewall log file. Third, attempts at breaching the system through brute-force guessing can be easily detected.

Trying to Guess a Knock Sequence

If someone is trying to guess a knock sequence, such attempts can be easily detected and their IP can be blocked. If someone is blindly attempting to connect to closed ports and triggers their IP to become banned, they cannot detect that they have become banned because at no point have they made a successful connection. The only way you know you are banned from connecting is that (a) you know the host exists and (b) you were once able to connect and (c) now you cannot connect.

Trying to Guess Whether Port Knocking is Being Used

It is not possible to detect whether a certain server is using port knocking to secure communication. Because port knocking uses closed ports and does not return any information to the client during the authentication process, the client cannot detect the mechanism, except by inference when they supply the correct knock and a port becomes open to them.

If the fact that port knocking is being used becomes public, and even the list of the ports, the system is not compromised. After all, everyone knows that passwords are used to protect login sessions, but this information does not, by itself, make systems less secure. It is possible, and encouraged, to monitor all connection attempts to the closed ports used in port knocking for signs of tampering.

Why Protect Encrypted Services?

Why not just encrypt the data you want to transfer, like passwords through an ssh session, rather than fiddle with port knocking and encrypting knock sequences? What is the point of securing encrypted services?

Port knocking is meant to protect vulnerable network services against public access. It is an added form of security, and not meant as a replacement for regular security maintenance. If you go on holidays and someone discovers and disseminates a vulnerability in an ssh implementation, and you are unlucky enough to be running this implementation, your system is vulnerable. You may come back in time to read the bulletin and patch your server - or not. In such a case, port knocking would be used to keep port 22 closed. Of course, you would still patch your server as soon as you got back, right?

last updated 2009-Mar-04 17:00
Port Knocking (c) 2002-2014 Martin Krzywinski