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.
They had a loophole that the network monitoring system would trigger an alert that gets manually verified. If the port was open, they could verify that it was an actual SSH server. If the port was closed, they would write it off as a false alarm.
IMO, If your aim is to provide a clandestine entry point to your network, port knocking is amazingly effective. Your host can be completely silent on the internet and seemly be offline but still provide network services. Keep a honeypot online on the same network and most attackers will be busy for weeks/months.
I think the "clandestine entry point" stuff is mostly a psychological benefit.
That's the gist of the article, but it details why it's silly as well, which is nice.
If you turn off password logins, people will use authorized_keys to in effect get a password-less login. If their public key has a password, this is OK, since they're either using ssh-agent or typing in their password at the time of the login. However, what if their ssh key has no password on it? That gives a password-less login path to my host, which is less secure. The problem is, it is impossible to detect, on the server side, a login with a key with no password.
Personally I would like to have both, in succession, but have not found a way to configure it. This would be simpler than the SSH-to-SSH solution.
Key files can be password protected. Do you mean "(key+password) + password" or just not aware of passworded keyfiles?
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.
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 mean, you could easily stop using the DNS and use raw IP addresses for everything - this should cut down on your attacks and maybe even spam, right? Nobody does this because it it insanely inconvenient, and ignores the solution to this inconvenience which DNS is. Standardized port numbers exist for many reasons - do not abandon them and create complexity for your fellows merely for your personal convenience.
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.
Yes, I agree completely. Which is why it buys you nothing compared to simply increasing your password/key lengths with the equivalent number of bits. On the contrary, it introduces confusing complexity for oneself and one’s fellows. Maybe this is what unconscionable people call “Job security”?
> equivalent to adding a thin wood plank
It is less like a thin wooden plank and more like a hedge maze which all legitimate users also must traverse each time. And all the hedges are made of asbestos.
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?)
<s> (. I think I'll change the protocol numbers of TCP and UDP to use each others' numbers. Complete protection! No standard TCP/IP stack will be able to connect! Yay! .) </s>
Which do you want to know about?
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.
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.
