Preventing brute force attacks against ssh?

Question

What tool or technique do you use to prevent brute force attacks against your ssh port. I noticed in my Security logs, that I have millions of attempts to login as various users through ssh.

This is on a FreeBSD box, but I imagine it would be applicable anywhere.

Answer 1

Here's a good post on that subject by Rainer Wichmann.

It explains pros and cons on theses methods to do it :

• Strong passwords
• RSA authentication
• Using 'iptables' to block the attack
• Using the sshd log to block attacks
• Using tcp_wrappers to block attacks
• Port knocking

Answer 2

I use fail2ban which will lock an IP out after several failed attempts for a configurable amount of time.

Combine this with password strength testing (using john (John the Ripper)) to ensure brute-force attacks will not succeed.

Answer 3

Ons small thing you can do is use something like DenyHosts:

http://denyhosts.sourceforge.net/

It uses the built-in hosts.allow/hosts.deny to block out SSH abusers.

Answer 4

• Change the port used (as Trent mentioned)
• Require encryption keys instead of passwords. http://novosial.org/openssh/publickey-auth/
• Blacklist attacker ips
• Whitelist known users to prevent accidental blacklisting. (as Samiuela mentioned)

Answer 5

One of the easiest ways to avoid these attacks is to change the port that sshd listens on

Answer 6

As Chris points out, use encryption keys instead of passwords.

Add to that:

• use a whitelist where possible.

How many people or locations (with floating public IPs) do you really need accessing your public ssh connections ?

Depending on the number of public ssh hosts you are maintaining and whether you can narrow down your general connection criteria's then it may be a simpler, maintanable configuration to limit access to a few external hosts.

If this works for you, it can really simplify your administration overhead.

Answer 7

In addition to the other good suggestions, one really easy thing to do is rate-limit incoming connections. Limit to 3 connections per minute per IP:

iptables -A INPUT -p tcp --dport 22 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m limit --limit 3/min --limit-burst 3 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

Answer 8

Use the "AllowUsers" option in sshd_config to ensure only a small set of users can log in at all. All others will get rejected, even if their username and password are correct.

You can even restrict users to logins from a particular host.

e.g.,

AllowUsers user1 [email protected]

This will reduce the search-space and avoid those old users which have accidentally been left laying around or enabled (although these of course should be disabled anyway, this is an easy way to stop them being used for an SSH-based entry).

This doesn't entirely stop the brute-force attacks, but helps reduce the risk.

Answer 9

Use something like that with PF:

table <ssh-brute> persist
block in quick log from label ssh_brute
pass in on $ext_if proto tcp to ($ext_if) port ssh modulate state \
(max-src-conn-rate 3/10, overload flush global)

Answer 10

Port-knocking is a pretty solid way to keep this sort of thing out. Slightly fiddly, sometimes annoying, but it definitely makes the issue go away.

Answer 11

I just don't care about it. Let them belt away at the port, they're not going to brute-force a key.

Answer 12

Context is important, but I'd recommend something like so:

• Since you're using FreeBSD, consider running the PF firewall and using its solid connection rate-limiting features. This will allow you to send the brute forcers to a black list if they connect on a frequent basis
• If this box must be accessed from the outside world, consider using a PF rdr rule to not allow traffic to port 22, but to redirect some obscure port to it. Meaning, you have to connect to port 9122 instead of 22. It is obscure, but it keeps the knockers away
• consider moving to key-based authentication only, making dictionary attacks useless

Answer 13

Further to sherbang's rate-limiting suggestion, the length of the delay is important. By increasing the delay between groups of 3 login attempts from 2 minutes to 20 minutes, the number of different IP addresses that made more than three attempts to login dropped, comparing two week-long periods on one machine of mine, from 44 attempts to 3. None of those three addresses kept trying for longer than 11 hours.

Very anecdotal, but auth.log became a whole lot more readable for me...

Answer 14

install OSSEC. not only it monitors for repeated logins, it will enter a temporary block with iptables for the offending ip. And at the end it will send you a report stating the details. it logs everything, which is nice. Somone once tried over 8000 login names to log in with. i parsed the logs and got a nice user list out of deal ;)