How to secure ubuntu server from bruteforce ssh attacks?
Solution 1
There are different solutions. The best one is using RSA authentication that uses public/private keys to authenticate users.
Check this great manual for different approaches (RSA authentication included): http://www.la-samhna.de/library/brutessh.html
I'm using the 3rd solution on my server because I don't want to make it complicated for my non-technical users: using iptables
to limit the number of connections per minute that makes bruteforce attacks inefficient and ineffective.
Here is the solution I'm using:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
As mentioned here: this will allow three port 22 connections from any given IP address within a 60 second period, and require 60 seconds of no subsequent connection attempts before it will resume allowing connections again. The --rttl option also takes into account the TTL of the datagram when matching packets, so as to endeavour to mitigate against spoofed source addresses.
As stated in the mentioned guide, it's better to use a white list to separate trusted users from these rules:
iptables -N SSH_WHITELIST
then add trusted hosts:
iptables -A SSH_WHITELIST -s $TRUSTED_HOST -m recent --remove --name SSH -j ACCEPT
and after that make the rules:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Solution 2
I get brute-force ssh attacks on my servers with a rate of 1 to 2 per day. I have installed denyhosts (ubuntu package: denyhosts). It's a very simple but effective tool for that purpose: essentially it periodically scans your logs to detect brute-force attacks and puts IPs from where these attacks originate into your /etc/hosts.deny file. You won't hear from them again and your load should be reduced considerably. It is very configurable via its config file /etc/denyhosts.conf to tweak issues like how many wrong attempts consitute an attack etc.
Due to its transparent workings you can easily see what's going on (email notification: 'aha, another dastardly attack thwarted!') and undo mistakes due to your users mistyping their passwords repeatedly .
Of course, everything previously said about switching to other authentication methods holds but sometimes your requirements disagree with those of your users.
Also, new-connection rate limiting in iptables might be a better choice then denying access via hosts.deny. So, have a look at fail2ban as well. But if you know that ssh brute-force is your main concern (manually look through /var/log/auth.log to determine this), go with this very easy and low impact tool.
Solution 3
- Change the sshd port to something nonstandard
- Use
knockd
to implement a port-knocking system - Use iptables'
recent
andhashlimit
matches to limit consecutive SSH attempts - Do not use passwords, but use SSH keys instead
Solution 4
First of all you should consider not using passwords and use keys instead. There is no need to use a password. If this works for you, you can configure the OpenSSH-server not to react on password logins.
https://help.ubuntu.com/10.04/serverguide/C/openssh-server.html
Using fail2ban, could be an option as well.
Related videos on Youtube
Dziamid
I am a web developer with a focus on automation of human labour. My server side tools: Symfony, Doctrine. Client side tools: jQuery, Prototype, dhtmlx.
Updated on September 18, 2022Comments
-
Dziamid over 1 year
I have my passwords secure, but I heard people complaining about perfomance of a server going down drastically when a bruteforce attack is taking place. How can I secure my ubuntu 10.10 server from such attacks? Is there an apparmor profile for this? Or some other way to address it?
-
Dziamid about 13 yearsRegarding turnign off password authentication, how do I login to a server if I loose its public key then? (I don't have a phisical access to a server, it is a VPS)
-
Dziamid about 13 yearsHow do I connect to a server if I loose its public key?
-
Pedram about 13 yearsPublic key can be published everywhere you want.So don't worry about that.You can put it somewhere that you're sure you won't forget it even public places.
-
Pedram about 13 yearsRead more here: en.wikipedia.org/wiki/Public-key_cryptography
-
Dziamid about 13 yearsIs there a way to set up server to reveal its public key when asked?
-
Pedram about 13 yearsUsing ssh, I don't think so.if you have a web server installed such as apache you can share the key using web.
-
Dziamid about 13 yearsGood idea, thank you. Are there any brute-force attacks against RSA?
-
Pedram about 13 yearsNo problem :) / No.Since server won't ask for password, attacker can't use brute force attack.But don't forget every security feature can have a problem which can be used to launch attacks. :D Anyway, it's always reasonable to use the most secure way.
-
Dziamid about 13 yearsAs far as I understood from the manual, you generate and store your private key on your machine and upload your public key to a server's authorized_keys file. Is this correct? Or the other way around?
-
Dziamid about 13 yearsMy /var/log/auth.log has been growing considerably lately. Does an entry like this
Mar 27 10:28:43 smartfood sshd[17017]: Failed password for root from 218.15.136.38 port 33119 ssh2 Mar 27 10:28:47 smartfood sshd[17019]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.15.136.38 user=root
indicate of an attack? -
Pedram about 13 yearsYeah, that's correct.
-
ddeimeke about 13 yearsOnly via console or direct access. I am quite sure that you will not lose your key if you are able to administer a server.
-
DrSAR about 13 yearsWell, this means someone at IP 218.15.136.38 tried to login as root. Could have been you, but likely not because using tools.whois.net/whoisbyip , I can see that this IP is registered in China which is quite a ways from Minsk ;-) So, yes, this looks like a guess of your password. Moral: Disable root login via ssh (PermitRootLogin no in /etc/ssh/sshd_config) because there is no good reason to leave this on. And then consider denyhosts or fail2ban. Also, make sure you have a firewall to let only essential access through port 22 and whatever else you need (but not more)
-
Gaurav Bindal about 13 years-1 for the first advice, complicates things for actually no real security increase
-
Dziamid about 13 yearsBut, in this case there is no such thing as a server's public key, hence nothing to publish. So, loosing my private key = loosing access to server. Correct?
-
Dziamid about 13 yearsIf you use ssh keys and turn off password authentication via ssh, do I really need 1,2,3 ?
-
pepoluan about 13 years@steabert it helps against script kiddies that just try to bruteforce their way through port 22. that's my experience: someone keeps bruteforcing an Internet-facing server when I was setting it up, making the system send me warnings after warnings. I moved the port, and the warnings subsided.
-
pepoluan about 13 years@Dziamid ssh keys prevent someone breaking into your system. but it doesn't stop them from trying to connect to port 22.
-
Pedram about 13 yearsPrivate key is like your password.If you forget your password you will lose access.Private key is the same.
-
Dziamid about 13 yearsFair enough. To be on the safe side, I've setup my 2 servers to have access via RSA to one another. So if I loose my private key I will be able to ssh from another server.
-
Dziamid about 13 years@pepoluan, I thought that if you turn 'PasswordAuthentication to 'no', server won't even listen to port 22. Is this correct?
-
DrSAR about 13 years@Dziamid No, not correct. Other authentication methods (RSAAuthentication, PubkeyAuthentication, #KerberosAuthentication etc) all still make contact via port 22.
-
Michael over 12 yearsI have browsed the net for about 50 hours reading blogs and forum-logs every where and give this answer/solution +1. It could be improved by listing the brute-force protection to all connection attempts using iptables EXCEPT permitted sources, such as the port address of a webserver, which is locked down tightly anyway.