Years ago when I got my first server I remember installing some scripts to check its integrity and warn me about attacks. I was amazed and quite frightened by the number of SSH attempts. I soon learnt, however, that this was quite normal. It maybe worrying, but it’s normal.
Put a server on a public IP and people will try to crack it.
There’s no avoiding that. Well, there is, but it’s a bit impractical to disconnect a web server from the internet 🙂
So what can you do?
One of the solutions is to use iptables to block the IPs of failed login attempts. If someone (or something) makes more than X connection attempts from a particular IP then you block it.
Of course that’s easy if you can program. I can’t!
Luckily I don’t have to, as there are solutions like the rather excellent Fail2Ban available:
Fail2ban scans log files like /var/log/pwdfail or /var/log/apache/error_log and bans IP that makes too many password failures. It updates firewall rules to reject the IP address.
So not only can you block SSH attacks, you can also use it to defend yourself from other bruteforce attempts.
There are debian / Ubuntu versions available, so all you need to do (as root) is run:
apt-get install fail2ban
This will install the daemon and its basic config, which is to silently block SSH attacks.
You can easily customise the configuration by editing /etc/fail2ban.conf
The developers have left nice clear comments in the file, so even I was able to make the necessary changes, including whitelisting my own IPs ie. you don’t want to lock yourself out just because you’ve forgotten your login details.
There’s also a nice writeup here which goes into some depth about the various options available.
There’s a /way/ simpler way to stop the brute force attacks: change the ssh port. 99.9% of the scans are done by bots, which don’t port scan. Suck it and see, I guarantee they’ll disappear immediately. Of course this is only of use on private servers, or where you have customers with clue. 🙂
Adam
Security through obscurity isn’t my thing
Michele
It isn’t security through obscurity Michele, it’s a way of stopping the automated bot attacks. Like I said. This with disabled root logins and a good password policy negate the need for anything else. But hey, if you want to keep trawling through garbage in your logfiles, work away fella.
I change the SSH port of any public facing machine I have. It means alot less crap in /var/log/secure to look through
You could also just not run ssh on a public facing port. Setup an IPSEC or SSL VPN, and run sshd only on an internally accessible/vpn accessible port…
If you’ve got a real network instead of just a colocated box somewhere, I just dual-home my machines, and only run management stuff on an entirely separate interface, and don’t expose anything to the world that they dont need to see.
Looks very similar as denyhosts.
I like to use iptables limit option.
Something like:
iptables -A INPUT -p tcp –dport 22 -m limit –limit 2/minute –limit-burst 1 -j ACCEPT
iptables -A INPUT -p tcp –dport 22 -j REJECT –reject-with tcp-reset
Will reject any ssh connections after 1 failed ssh session for 30 seconds. It works fairly nicely. The only problem is connecting to the host from a dynamic IP during an ssh attack. Static IPs are fine since you can create a rule which gets matched before the rate limiting rule.
changing ssh-port might be a nice solution but only worked one week on my servers! I assume that once the new port is dicovered, the “discovery” travels around the world to several attackers.
I confirm that the best results are still to be reached using fail2ban with a very sharp rule: e.g. block any failed connection 1 or 2 days after one trial.
If you use Fail2Ban, you can report the Attacker-IPs automatically over https://www.blocklist.de and there Abuse-Department can parse the Reports automatically too.
You can help to make the internet clean 😉
Martin
I’m not a big fan of automated reports as often they get sent to the wrong email addresses.
Michele
Hi Michaele,
thats true, so the Abuse-Team can rewrite the Address to a special address who can parse the Reports automatically.
We look first for the irt-object, than abuse-mailbox-field, than abuse-c, than all other fields with abuse@, security@ and at the last, we used abusix.org.
If there overall no Address, we call the Cert from the Country of the Attacker.
When a provider does not work against the abuser, we can stop the Reports for there network or address 🙂
E.G. in .BR there are 2 AS-Networks there not longer exists under the company from the whois. So the Cert.BR send us the new Addresses to rewrite, now all Reports for these AS-Number goes to ..@oi.net.br
In two years, we haved two false-positives, there network was changed and the whois not up to date, so we send it to the old noc.