Hacker News Reader

Comment by tdicola | Hacker News Reader

If you haven't already, get fail2ban setup on the box to slow down all the attacks. And disable password login and switch to certs instead.

View on HN

tdicola: To authenticate myself, I use an ssh key. However, the goal of this project was to log all attacks over ssh. So setting up fail2ban and disabling password login would prohibit this collection of data. I have a massive password in place, so I'm not worried in the least.

Better yet, deploy OSSEC there. I would recommend it with the latest patches from here:

https://dcid.me/ossec/

It's just another thing you need running on the server that must stay patched forever.

In my opinion less is better. RSA/4096-bit key encryption only. I don't even care if you use the root user. The ability for someone to crack a 4096-bit key is impossible in practice, and if your SSH server has a bug then it doesn't matter what fancy things you have setup.

It is fine for a 1-man server, but if you have multiple users and you have to be on top of things, then you need a bit more than that.

Specially to look at successful logins and audit where they come from. This is a good blog post on the subject:

https://blog.sucuri.net/2016/03/server-security-anomaly-beha...

SSH key based auth does not use certificates.

In the case of key-based-auth only, fail2ban is pointless.

I wouldn't say pointless. It wastes an attacker's time if nothing else, otherwise you're essentially allowing that attacker to continue interacting with your server, and perhaps SSH isn't their only target.

I disagree. I run it because I drop all traffic from the /24 the scan comes from. Harsh, yes, but tough luck. It cuts down on unwanted network traffic.

That's a pretty significant denial of service you open yourself up to. If someone shows up bruteforcing you from randomly allocated AWS or Digital Ocean cloud instance public IPs that happen to land in the same /24 as other AWS- or DO-hosted services (Heroku comes to mind, but also any other monitoring, log aggregation, analytics, data processing, et c) your machine depends on, they've convinced your system to cut connectivity to them. Not the best setup...

Actually it can use certificates. Not X509, but still simplified ones.

fail2ban also reduces spam in your auth log and prods the bot to move along to the next target.

It can quite easily protect against things other than failed ssh attempts - I used to regularly configure it to blackhole IPs failing to log in correctly to WordPress backends... Anything else the box does that uses some form of authentication that writes out failures to a log file can be hooked up to fail2ban.

Reply on news.ycombinator.com