Hacker News Reader

Comment by Dobbs | Hacker News Reader

Wouldn't it be much easier to just restrict access to keyfiles and block anyone who fails more than 3 attempts?

Not sure why but the idea of port knocking always seems over complex for little benefit.

Yeah, at least as far as my logs go, just disabling password login seems to cover a superset of the attacks that changing ports would cover, so I don't see much reason to avoid the default port. Every automated attack I've found in my logs is: 1) on the default port; and 2) a password attempt. It seems the recommendation here is to change #1, but to me just changing #2 is easier, and has some other benefits as well. The main place I could see an argument for #1 is if you run a large multiuser server, where it's quite possibly easier to explain to your users how to use a nonstandard ssh port, versus trying to explain to them how to use ssh keys.

Hostgator's nonstandard port for hosting is my biggest complaint about their service, especially because I cannot set up key-based authentication, and I have to ad -e 'ssh -p 2222' to my rsync statements.

But if I'm being honest, back when I signed up with them keypairs would have been a little more difficult than working out that option for rsync.

the advantage of port knocking is that it's a separate line of defence from your ssh server. It'd be damn useful in the case of a remote SSH exploit.

Great point - port knocking would have provided a separate line of defense when that horrible Debian/Ubuntu keygen flaw hit a few years back.

I agree with you -- port knocking and even changing ssh's listening port look a lot like security theatre. They're cool, they're hackish ... and they're completely unnecessary, assuming that you don't allow root ssh logins and have a relatively small subset of ssh users, along with a reasonable password policy.

At worst, the internet will just keep filling your logs with access attempts, none of which will actually accomplish anything.

I did recently decide to start using fail2ban though, not because I'm worried about someone hacking ssh, but because I wanted a centralized system that would monitor various forms of abuse (including obvious spammers).

I see another benefit of using fail to ban. That is, it helps a little to keep the log files (a little) shorter.

It's a reasonable enough way of protecting hosted websites, especially if you're running more than one server. You can monitor multiple logs for abuse from different sources, and then update all servers to drop traffic from those sources. So, if someone runs a WordPress vulnerability scan on a hosted website, you can detect that and immediately refuse any mail/ssh/dns/www/ftp/other service from that IP.

It requires a little bit of kludging to do this though. :-( As packaged, it's not much more useful than a hacky shell script.

I'm just gonna rephrase and repeat this bit, because it seems to be not completely understood:

Do not allow password logins. Do. Not.

Have a method to redact keys quickly. The advice of the article becomes irrelevant. If someone gets hold of an unencrypted/crackable private key, they'll likely also have access to the secret portnumber, knock sequence and username, so nothing much gained there.

It seems to me (no security expert by any means) that port knocking and similar schemes are useful because they're orthogonal to SSH infrastructure and thus can provide a certain amount of defense against sshd 0-days and the like.

Consider the Debian PRNG flaw from a couple years ago. As I understand it, most SSH/SSL keys generated on Debian and Debian-derived boxes over a period of about two years were (rather) easily guessable. Even if you were able to redact any compromised keys as soon as this was publicly revealed, who knows how long malicious attackers may have known about it before it was made public. If your server had port knocking enabled you would have had a bit of insulation from this attack.

that's what these try to do:

http://www.fail2ban.org/wiki/index.php/Main_Page

http://denyhosts.sourceforge.net/

denyhosts has the difference that it synchronises this data amongst many hosts.

Heh. I've been working for the last little bit on setting fail2ban up to work with MySQL and sync between three servers. It's actually not nearly as hard to do correctly as I thought.

I think the main goal behind port knocking is to prevent someone from exploiting a pre-authentication vulnerability in the ssh daemon.

Reply on news.ycombinator.com