Port Knocking is it a good idea?

Question

Normally for a server I like to lock down SSH and other non-public service to only be accessible by certain IP addresses. However this is not always practical if the business doesn’t have static IP addresses or if outside developers need access.

I heard about Port Knocking a while ago and have finally had chance to look into it as a solution to the above problem. As a result of this I have a load of questions I hope people can help me out with.

• Has anyone deployed it within their Business / Organisation and can offer any advise?
• What is the best knocking Daemon to run under Linux?
• What are the best clients for Linux, Windows and OSX?
• What is the recommend length for knock sequence and is it best to use TCP, UDP or Both?
• What are the associated downsides and issues with using it?
• Is it just Security Through Obscurity?
• Are there any alternatives to the port knocking approach?

Answer 1

While I have not deployed it yet, I know many people who have deployed it. Every single one of them have noted a significant reduction in the amount of bandwidth consumed by things like SSH brute-force attacks as a result.

However, that is not to say that there are not downsides. AFAIK, there are no kernel-based port knocking implementations available, which for me would be the real key to adoption. Port knocking daemons rely on reading failed (and filtered/prohibited) log file entries from a firewall system. That's all fine and dandy, but what happens if the filesystem gets full? What happens when the daemon gets killed because of some runaway process eating up the system's RAM and swap? What happens if something else which either of those two things depend on just up and stop working? You most likely end up with a server that you will have to physically access. That could wind up being more costly than is reasonable, especially if you are more than a few tens of miles away from the server and do not have anyone that you can call to get there in a hurry.

One thing that I can say is that it is not "security through obscurity". Port knocking is a form of authentication, and like any authentication system it can be made to be as simple or complex as desired. Something as simple as "knock on port 10,000 + realPortNumber" can be done, which would amount to a trivial break, or the port knocking might itself be used to transmit some form of real authentication (say, 1 block of AES encoded data given a key derived by some other method). It would not be feasible to use port knocking to transmit large amounts of data, though, because it would take significantly longer than just sending a single packet, and if the packet is over TCP than at least it can be known if it was received successfully or encountered some form of error.

One interesting question that this brings up, however, is how to manage the log files---userland implementations mostly require the log files in order to determine whether or not a knock has been successfully sent, and what happens if those logs are leaked? Authentication data becomes known, and that is obviously not a very good thing.

I cannot tell you whether or not to use port knocking in your setup. I am not yet, and I am not 100% certain that I ever will be. It makes more sense to me to use strong authentication systems that are based on strong cryptography (such as a PKI infrastructure) than it does to throw port knocking in the way. Also, adding a single point of failure to access critical infrastructure, to me anyway, seems like a bad idea, and way more difficult to properly support with any sort of guarantee. Again, though, that is based on the notion of the port-knocking software being not integrated with the firewall at the operating system kernel level; if that ever changes, I may also change how I feel about using it.

Answer 2

Port knocking is not just another plain text password - at least when used to protect services that listen on a TCP port like SSH. Port knocking implies that service discovery with nmap is no longer possible because of the use of a default-drop firewall policy. SSHD has had remotely exploitable vulnerabilities too, and these have nothing to do with weak passwords. I don't want anyone to be able to fire up nmap and see that I have SSHD listening.

Also, there is a stronger variant of port knocking called "Single Packet Authorization", but it also is a completely passive authentication scheme so it retains the benefits of port knocking but solves its limitations (replay attacks are easy, DoS attacks are easy, etc.).

Answer 3

It is an easily verified fact that all internet facing services have security vulnerabilities relatively often - services such as SSH, OpenSSL, etc. Attacks on these are tried en masse on the internet, targeting any systems that have suitable open ports.

Port knocking, in my mind, has the purpose of keeping away these random attackers from the internet, that are looking for generic vulnerabilities. That is, it is not supposed to keep away a dedicated attacker, or form any part of the actual security of the services. The benefit of port knocking should be that it would, really, be simple enough that it wouldn't be likely that there are any exploitable bugs in it, ever.

This usage means that port knocking can be as lax as can be, as long as it keeps away the majority of attackers. It may be just security by obscurity, but a better way is to have it as a weak form of "password" authentication.

So the "best" port knocking service would be one which it is inconceivable to imagine any attacks against, yet be trivial enough for any legitimate user to use from any sort of client machine.

Answer 4

As per my comments elsewhere, although there are lots of implementations that use all sorts of special tricks to respond to the knock, it can be implemented purely using iptables on a Linux system. i.e. this is effectively a kernel-based port knocking implementation

Since the knock is visible on the network, using sequences of more that 3 knocks gives little benefit. I'd recommend using TCP - although it will be slower, you've got a better guarantees that the knock was delivered.

However, although it relies on userspace programs, my preference is for fail2ban since it requires no additional steps / software to connect, runs reliably, and if it did ever fail it wouldn't prevent me accessing the servers.

It does surprise me that there's is so little adoption of encrypted ident - although RFC1413 merely mentions this a possible approach using the protocol rather than defining how it should work.

But of course you should ensure that you've restricted access as much as possible independently of this (i.e. no root login, restrict access to nominated group, if practical, require key pairs). SSH is designed to be secure - and historically there have been relatively few vulnerabilities in the main stream implementations. The reason that attacks are successful is usually down to a combination of guessable usernames, simple passwords and brute-force attacks or social engineering. Note that I'm not advocating you enforce a complex passphrase validation (other than minimum length) nor that you require users to keep changing their passwords, there are better approaches (e.g. two-factor), but unfortunately very few implementations.

Answer 5

Port knocking is not security through obscurity. It is defense in depth. It's like parking your car next to a more stealable car - it won't do a lot to prevent a targetted attack, but it might just send opportunists looking in the other direction.

Answer 6

I have not implemented port knocking in a number of years, however, I suspect that it has not changed significantly in principle. Other comments contain many valid points and I will not simply repeat them here.

One aspect of port knocking that I always implemented as a matter of course is to base the knock sequence off of a pseudo-random but repeatable value, such as the current date and time. This strategy does not eliminate wholesale the danger of a replay attack, however, it does limit the exposure of a given knock sequence. Obviously for this to be successful a synchronized time, in my example, source would be required for consistency.

Answer 7

Port Knocking is just another plain text password. It can be brute-forced, discovered, captured and replayed like any other plain text password. Why re-invent telnet logins?

You have to trust something. So let's assume your trust your OS networking stack and you trust sshd when running with delayed compression, privilege separation and only allows some reasonable form of two-factor authentication (say, key-based).

You can use "simple" services like sshd that invokes authpf to protect your more complex, vulnerable services.

authpf allows you to modify your firewalls rulesets based on who authenticates successfully against sshd, so only IP addresses that manage to login to your ssh gateways are allowed to connect to your compile/compute/database farm.