You might want to read my previous articles, Port Knocking 101 and Single Packet Authorization, before going further.

While researching informations on “Port Knocking” I realized that something was missing. Every website I went to were offering informations either on Port Knocking or Single Packet Authorization but I couldn’t find any clear information on the force that drives these mechanism as a whole. I then decided to dig in this matter and this paper is the outcome of my thought.

What I found missing was a ten thousand feet above ground definition at the common denominator shared by Port Knocking and Single Packet Authorization. Those two mechanism are only ways of implementing a more general idea that I call “knocking”. In this paper, I’ll define knocking and reveal its mechanism. Of course, when I mention knocking, I mean it in a virtual way. Don’t worry, no doors were harm during this writing.

The usage of knocking mechanism has been around for quite some time. The Wikipedia article situates its appearance around the year 2000 but other peoples were using the technique before that as I remember reading an article on the subject in that time period. I’m also aware that other types of knocking mechanisms exists but I’ll address those in later articles.

Here’s how I would define knocking :

Knocking, in a virtual context, consists of the action of unidirectionaly passing information by the means of a covert channel and with the goal of triggering an action. It differentiates itself from a covert channel by its goal of triggering an action instead of ex-filtering information.

Before going further you might be asking yourself : but why? The big plus in enabling a knocking mechanism is stealthiness of your services in the eye of the outside world while still offering the services to those who know how to access it or, as I prefer to say, to knock. It offers you with an additional layer of protection that can thwart 99% of attacks. In other words, It will add another shell around your security in depth portfolio.

One basic principle of a knocking mechanism is the shared secret. The knocker must know the knock and the knocking mechanism must recognized it in some way.

Another fundamental part of a knocking mechanism is that it must make use of a covert channel. If no covert channel were to be used it would mean that your service needs to be publicly accessible which is bad if your intent was to keep it closed and stealthy. When no covert channels are used, a good user-name/password authentication protocol would protect your asset more effectively.

And the last basic aspect of a knocking mechanism is that the communication needs to be unidirectional. A reply could reveal that you’re using a covert channel. In a Port Knocking setup, the firewall never ever send any reply or acknowledgment. Sending any replies could reveal to an attacker that your firewall isn’t closed after all! Replies aren’t forbidden, only the reliance on them for the mechanism to work is. If the protocol stipulates that an acknowledgment must be sent then so be it. The only logical limitation is that this acknowledgment must not be linkable to a knocking mechanism in any way. I’ll elaborate more deeply on this aspect in another article.

Before implementing a knocking scheme on your servers you must realize that it won’t secure unsecured connections. A unencrypted connection will still be unencrypted… Enabling Port Knocking on a telnet server is useless to thwart a man-in-the-middle attack as your password will be seen in clear text. Also, it is not suitable for all situations. As an example it wouldn’t work on a public website as the knock would also need to be public which would fail the shared secret necessity. It really is only useful to services such as SSH or VPN that are to be used by a limited and known set of people.

I’ll be following this article with an advanced port knocking tutorial and even some original research where I dive deep into knocking mechanism so stay tuned!