Saturday, January 21, 2006

Port Knocking is Worthless

As I read about Port Knocking and whether or not it qualifies as security through obscurity, it strikes me that not only is Port Knocking useless, it's wrong minded as well. It fails to solve the very problem it purports to address, and creates the illusion of greater security. I believe this is the worst form of snake oil. In any security assessment one must produce a threat model and an construct your security system in response to that, but a system like Knocking doesn't appear to have gone through that process.

Security through Obscurity (StO) is widely and correctly derided as being entirely inappropriate for any practical, valuable purpose. Martin Krzywinski points out that just because the pattern of ports accessed in the SYN sequence is a secret, this isn't any more StO than having secret keys is StO. However, he relies upon an analogy 0f a secret web page with a magic name which is designed to be inaccessible and compares that to a passworded file. While this example is illustrative, it is someone beside the point, especially when one considers that HTTP-Auth is in most cases a plaintext authentication scheme. Ironically, HTTP-Auth is just as "secure" as port knocking.

The only place Mr. Krzywinski comes close to being accurate in describing the benefits of Port Knocking is when he says that the scheme forces potential random attackers to identify themselves in addition to being difficult to detect security model. Well, it is true that one doesn't necessarily want your security systems to be easily detected, however one must perform all risk assessments under the assumption that your opponent knows what techniques you are using. Otherwise you are most certainly right back into a StO setup. Therefore the second argument boils down to "this is an obscurity setup that is difficult to divine." Not exactly confidence inspiring. The former advantage is simply silly in that one can't imagine an attacker that would continue to blindly probe ports in an attempt to unlock the target. Someone attempting brute force password auth can at least be detected just as easily and stopped just as easily as someone doing probes of a port knocking attempt. Except that someone doing brute forcing cannot forge the return address as one can on a SYN packet.

Port Knocking falls into a class of systems where any casual observer of legitimate traffic can completely detect and defeat the system. This makes it no different from any other plaintext password protocol like POP or FTP or Telnet and furthermore renders it useless in the very situations it is suggested to address.

Port knocking is a suitable form of hardening hosts that house users who require continual access to services and data from any location and that are not running public services, such as SMTP or HTTP. (sic)

Anyone in a position to observe the data stream and subvert one of those protocols is in a position to subvert a port knocking protected system. This begs the question: If port knocking is no more secure than plaintext authenticated protocols, why would anyone protect a service like SSH with it?. Obviously one wouldn't. While Port Knocking is an interesting intellectual exercise, it is an entirely worthless security setup. While it is true that one may not want to run a general purpose protocol like SMTP or HTTP through which one could have a 'POP before SMTP' type security setup, this doesn't mean that one would want to go so far as to modify your IP stack just to enable hidden or conditional services to be accessed.

The correct solution to the problem Mr. Krzywinski describes is to run a service on UDP which accepts requests to open up the protected service to a particular location. This request would consist of a signed message from a known authorized user utilizing any number of public key crypto systems packed into a UDP datagram (with the request containing the desired origin as well as a service identifier). Of course this does not solve the problem of the MITM, however it does prevent the MITM from being able to subvert the system of opening up the ports. The MITM could take advantage of the window of opportunity provided by the port being open, but certainly whatever service you are opening up access to utilizes its own cryptographic authentication. To do otherwise is silly.


  1. I believe you partially misunderstand the point of Port Knocking and the point that Martin Krzywinski was making. His representation of port knocking is made simple for one purpose, to help communicate the metaphor of a 'secret knock' on a door. He does not claim that port knocking on its own is sufficient, nor are his implementations of the only ones. Port knocking in itself can be made quite secure, by employing (as you mentioned) techniques which provide cryptographic services such as data origin authentication and message freshness. There are port knocking implementations which use specially crafted hashes which can be reconstructed by the server, and acted upon to open the proper port to the proper IP. This is STILL port knocking.

    You ask "If port knocking is no more secure than plaintext authenticated protocols, why would anyone protect a service like SSH with it?" As I just stated, Port Knocking itself can be made quite secure, however you misunderstand the point of its use. If your ports are open then the services running on those ports are easily open to attack. If I have a 0day ssh exploit... or even an exploit for an FTP server you have not yet patched, you will be owned, simple as that. I know that my box gets scanned constantly and random IPs connect to my open ports trying for ways to get in. Port knocking allows you to hide those ports from the world, and, with the proper implementation, no amount of network sniffing will help an attacker get in.

    To sum things up, although Port Knocking is in the realm of 'security through obscurity', one must remember that there is nothing wrong with that. StO is only a bad thing when it becomes your ONLY line of defence. In this case, with a strong implementation, it provides an excellent extra layer of protection for many different services, each of which may be vulnerable to countless different types of attacks. And even if the port knocking layer is circumvented... what do you lose? Nothing... the attacker then has to deal with the access control of the service he is attacking. You have only gained by: a) Thwarting most attacks by making your ports invisible. b) Being able to detect a potential attack if your firewall detects some unusual 'knocking activity'.

    I'd say that PKing is not quite 'worthless' as you implied.

  2. I did more than imply, I stated that it is worthless.

    A service that selectively opens holes in a firewall when it receives a request is far simpler than 'port knocking' and removes the silly random sequence of ports requirement. This request can arrive in any one of a hundred ways which do not acknowledge their receipt. Email, UDP, whatever.

    However, an equivalent amount of security is gained against so-called 0 day scanners/worms by simply moving your services to a non-standard port.

    The point I was trying to make is that port knocking is a complicated solution which does not add a significant level of security to a system. If your threat model is 0day exploits of a service only accessible to trusted clients running special software, then there are many better solutions which do not employ simple StO techniques. Alternate ports, IPSec and VPNs are those that come to mind immediately. Both place similar requirements upon your user base yet have far, far simpler deployment and support needs.

    Based upon these things, I contend that port knocking is an inferior, insufficient and weak solution to a problem with many other valid solutions. Thus, "worthless". Of no value.

  3. However, an equivalent amount of security is gained against so-called 0 day scanners/worms by simply moving your services to a non-standard port.

    Alternative ports are not more secure. A 5 minute scan with nmap will reveal services which are running on nonstandard ports. And as you pointed out above, any casual observer of legitimate traffic can completely detect your alternative port, and defeat the system.

  4. Frederic KruegerMay 3, 2006 at 3:11 AM

    I surely don't think Port Knocking helps totally prevent any exploit whatsoever, but still it _is_ making things a bit more difficult than without it.
    Changing the listening port helps a little..
    Port knocking helps a little..
    Having some crypto-approach in your service helps..

    So it is ok for me.
    I'm off the opinion since you can't make your system 100% secure _ever_ making your system as undesirable for an attacker as you can is the best protection for general server purposes.
    Of course, _if_ someone is inclined to get in (commercial / governmental / person-based hacks) this still is worthless since if they aren't totally braindead over time they _will_ find a way in.. No matter how steep the security measures are.

    So from my point of view making the system less desirable as a target is one of port knocking's main purposes and this is what it's good at.

    Anyways you are right that the original proof-of-concept-like implementation of port knocking doesn't make too much sense (i.e. using a protocol that provides feedback.. But then who tells you my firewall gives any feedback for not purposefully opened ports? No change there really.).

    MitM still is one of the bigger things, but there is public-key-crypto for this.. Generally speaking.


  5. When the "secret knock" is defined by a one time password scheme like RSASecureID and the port is only opened to allow connections from the IP doing the knock, it does provide real security and not through obsecurity.