45
votes

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?
1
  • Security Through Obscurity? That's hardly a fact. More like Security Through Policy. Sep 1, 2017 at 5:39

7 Answers 7

39
votes

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.

5
  • 3
    If you're concerned enough about security to consider port knocking, why not just go with real two-factor authentication instead of adding another layer of plain text auth?
    – Alex Holst
    Dec 16, 2010 at 22:16
  • 4
    I absolutely agree. Among the options I am considering for deployment in my network setup are crytographic tokens and one-time-pads. Dec 16, 2010 at 22:18
  • 8
    If its a linux based system (althuogh I imagine that the approach would be portable to most stateful packet filtering firewalls) you can implement a complete solution in iptables - which eliminates a lot of the complexity / reliability problems of a userspace program or custom kernel module. Have google.
    – symcbean
    Dec 17, 2010 at 9:54
  • 2
    something like this - using only iptables ???
    – Midhun KM
    Mar 9, 2015 at 8:52
  • 2
    The second paragraph is confusing, as others have pointed out, kernel only solutions exist for Linux, and you should not have to worry about logs filling up since most port knocking software only requires 10mins of logs maximum, if your daemon gets killed, sshd is going to die too, so why is this the primary issue? no amount of "kernel driver" is going to help when the system is completely unresponsive. any half decent sys-admin can setup reasonable limits for logs, and change app kill policies. Aug 14, 2020 at 2:44
14
votes

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.).

9
votes

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.

8
votes

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.

8
votes

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.

1
  • This is correct... while it doesn't answer the question it does address that all the other comments so far claim knocking is an authentication mechanism that it replaces some other mechanism. It doesn't: It is merely a way to run a command given a semi secret pw sequence. Typically, the command is to allow a port to be connected to... any or all other layers of auth remain untouched. The question did not imply it would be used as a sole auth mechanism.
    – Rondo
    Aug 31, 2018 at 3:23
4
votes

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.

1
  • It has changed though.
    – chiggsy
    Apr 24, 2011 at 19:34
1
vote

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.

5
  • 3
    To be fair port knocking is laid on top of SSH so it's not the same as telnet. Also, even if it is plaintext, your attacker now has to capture that password and then try brute SSH. The people brute forcing SSH accounts, generally aren't the same people that have ways to sniff your traffic. Dec 18, 2010 at 7:34
  • 7
    Port knocking is not a plain text password.
    – Rory Alsop
    Jan 10, 2011 at 1:09
  • I submit section 4 of rfp2k03.txt as proof that port knocking is just another password. If there's no encryption, it's even plain text. wiretrip.net/rfp/txt/rfp2k03.txt
    – Alex Holst
    Jan 10, 2011 at 17:28
  • Link in above comment appeared dead, here's an alt - packetstormsecurity.com/files/17647/RFP2K03.txt.html.
    – slm
    Apr 29, 2020 at 21:26
  • 1
    I think that you've stretched the concept of a "shared secret" well past its breaking point. You cannot equate a "plain text password" with a "process". That's a false equivalence.
    – schroeder
    Oct 14, 2021 at 10:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .