There are two broad classes of attackers: targeted attackers, who specifically want to get into your system, and script kiddies who are scanning broad swaths of the Internet looking for an easy target. Most of these countermeasures, like port knocking and moving sshd to a different port, do very little to dissuade the first group. But they make you much less of a target for the second group.

These discussions (and so many security discussions on the internet) make the argument that unless something is effective against targeted attackers, it's not worth doing. That's ridiculous. In the 20+ years I've been running computers on the internet, targeted attackers are outnumbered by random scans thousands to one. Of course, you'll say, any countermeasure that's good enough to stop targeted attackers is good enough to stop these guys as well. And that's true, but for two things:

1. I like my logging and alerting to intentionally be loud when a targeted attacker is messing with my system. By raising the bar enough so that only targeted attackers get through, I'm able to do that.

2. There have been zero-day vulnerabilities in probably most of the daemons I've run over the years. And when those zero-days come, I inevitably get hit with random scans looking for vulnerable versions. Those are almost always stopped cold by things as simple as running on a different port. I'd like to think I'm pretty good at keeping up with vulnerability alerts and updating my software when something like that happens, but simple changes that buy me a little time aren't a bad thing.

Afaik passwords aren't bad option either. You should consider password as shared secret blob, not as password. It's as unlikely that someone is going to guess 256 bit password as it is that they guess any other 256 bit secret.

http://www.portknockiewebsite.co.uk/

[NB I say home as my family has been there pretty much forever, I live in Edinburgh]

For me, the answer is simple: It violates Kerckhoffs’s principle¹. If you want more secret bits that users need to know in order to access your system, increase your password lengths. If you want to keep log sizes manageable, adjust your logging levels.

1) https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle

Which I agree with. But if you use a port sewquence derived from a S/KEY, then each port knock sequence is a one time sequence never to be repeated.

It is a simple and dirty level of security using the much hated obscurity approach, but by varying the ports via a aranged S/KEY sequence you can move it up a whole level. S/KEY easy to do and worked well on old old old nokia over 10 years ago as a little simple java app. Just using it to derive a port sequence instead of a one time password.

"all implementations had the downside of adding yet another piece of clearly experimental software to my system along with somewhat convoluted procedures for setting the thing up" what? you can add port knocking with literally 3 iptables rules, netfilter is a rock-solid proven piece of software.

"explain to me what problem this is supposed to solve." visibility: if target cannot be found there's no target to attack; security by obscurity is good (as long as security doesn't depend just on it).

I use bastion host to ssh to my servers with key and different port (yes different port is good; for a couple of sysadmins who cares we broke some standard?)

Is the brute force effort being simplified too much? Wikipedia entry says this about brute force attack on port-knocking: As a stateful system, the port would not open until after the correct three-digit sequence had been received in order, without other packets in between.

That equates to a maximum of 655363 packets in order to obtain and detect a single successful opening, in the worst case scenario. That's 281,474,976,710,656 or over 281 trillion packets. On average, an attempt would take approximately 9.2 quintillion packets to successfully open a single, simple three-port TCP-only knock by brute force.

https://en.wikipedia.org/wiki/De_Bruijn_sequence

And the main reason to have port knocking (over, i.e. fail2ban) is not stopping brute force attacks, but future vulnerabilties and exploits in services that should not be used by the whole internet. If there are very few persons, or machines that should connect to a service (and the origin IPs are not fully known to enable just them in the firewall) putting a fwknop or similar layer over that services should avoid external people to even try to connect to those services.

And there actually had been vulnerabilities in ssh, vpns, puppet (a remote code execution vulnerability for it has been patched this very week) and more that could had been exploited before you knew about them.

Also, "plain" port knocking could be protected against brute force scanning by having trap ports, if you hit them, then your IP is blocked. That won't protect from MITM that see how you connect (NSA at the very least), but will prevent scanning.

The article didn't really mention that angle.

The article hasnt anyway delivered any meaningful reason not to use port knocking, just a few straw-man arguments such as "most people only setup 3 port sequences".

The idea presented though is an interesting one, run your ssh on one port, and when that one authenticates with any method, only then allow connections to a second ssh on another port, which has perhaps only then begun listening or being allowed to accept connections from that specific uid, and if that authenticates then the user is in. Like having two gates infront of a city instead of a secret handshake with 16 port sequences say.

Changing the port is a really good and simple fix. If you also drop packets to closed ports instead of rejecting them, you slow the scan down enough that only a targeted attack is likely to find your ssh port.

All that with no performance penalties, no cumbersome configuration, no experimental software, with one change to one config file. I say do it.

I don't use port knocking, nor do I run sshd on a nonstandard port, but I perfectly understand the people who do that just to keep the log spam down.

What I think is that you should disable password authentication anyway, and adding port knocking to a ssh server that doesn't accept passwords is equivalent to adding a thin wood plank to a 20" steel door with an state of the art lock.