Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 15 down vote accepted

You can use different solutions.The best one is using RSA authentication which uses public/private keys to authenticate user and you can disable the keyboard login, But if you don't want use this one, you can use other ways.

Check this great manual for different ways (RSA authentication included):

I'm using the 3rd solution on my server because I don't want the users be uncomfortable.Using iptables to limit number of connection per minute which makes bruteforce attacks slow and useless.

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 said 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 said in the mentioned guide it's better to use a white list to separate trusted users from these rules:


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
share|improve this answer
Regarding 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 Mar 27 '11 at 18:55
Public 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 Mar 27 '11 at 19:46
Read more here: – Pedram Mar 27 '11 at 19:46
Is there a way to set up server to reveal its public key when asked? – Dziamid Mar 27 '11 at 21:29
Using ssh, I don't think so.if you have a web server installed such as apache you can share the key using web. – Pedram Mar 27 '11 at 21:43

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.

share|improve this answer
My /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 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= user=root indicate of an attack? – Dziamid Mar 27 '11 at 23:11
Well, this means someone at IP tried to login as root. Could have been you, but likely not because using , 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) – DrSAR Mar 28 '11 at 4:40
  1. Change the sshd port to something nonstandard
  2. Use knockd to implement a port-knocking system
  3. Use iptables' recent and hashlimit matches to limit consecutive SSH attempts
  4. Do not use passwords, but use SSH keys instead
share|improve this answer
-1 for the first advice, complicates things for actually no real security increase – steabert Mar 28 '11 at 9:18
If you use ssh keys and turn off password authentication via ssh, do I really need 1,2,3 ? – Dziamid Mar 28 '11 at 11:48
@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 Mar 28 '11 at 13:05
@Dziamid ssh keys prevent someone breaking into your system. but it doesn't stop them from trying to connect to port 22. – pepoluan Mar 28 '11 at 13:06
@Dziamid No, not correct. Other authentication methods (RSAAuthentication, PubkeyAuthentication, #KerberosAuthentication etc) all still make contact via port 22. – DrSAR Mar 28 '11 at 18:45

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.

Using fail2ban, could be an option as well.

share|improve this answer
How do I connect to a server if I loose its public key? – Dziamid Mar 27 '11 at 18:56
Only via console or direct access. I am quite sure that you will not lose your key if you are able to administer a server. – ddeimeke Mar 28 '11 at 3:34

How widely is the server exposed on the network? Perhaps you can have a talk with the network admin and check if it's possible to monitor and restrict network access to the server. Even if the account logins are safe, it seems that the server could suffer from simple DoS / DDoS attack.

share|improve this answer

An alternative to fail2ban is CSF: ConfigServer Security & Firewall.

It comes with LFD: a Login Failure Daemon that can detect multiple failed login attempts on various services, and will block the offending IP address (temporarily or permanently).

It has some other options that can help against flood attacks, and possibly detect intrusions.


  • You must use CSF as your firewall in order for LFD to do its job. So if you have an existing firewall, you will need to replace it with CSF, and port your configuration over.
  • It is not packaged for Ubuntu. You will have to trust the auto-updates from, or disable automatic updates.
  • I have heard it is quite popular, so smart intruders will probably know how to disable intrusion detection before they are detected!
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.