Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
add comment

15 Answers

up vote 20 down vote accepted

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
share|improve this answer
add comment
share|improve this answer
add comment

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...

share|improve this answer
add comment

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)

share|improve this answer
add comment

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 ;)

share|improve this answer
add comment

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
share|improve this answer
    
I might be misunderstanding something, but many mainstream browsers connect between 4-6 connections at a time - even though the HTTP standard sets it at 2. –  Joshua Enfield Jul 2 '10 at 19:51
1  
Yes, that would be a problem if you were trying to rate-limit port 80. You're not connecting to ssh with your web-browser, and ssh sessions are long-lived sessions that maintain state, not short-lived stateless sessions like http. Parallelizing ssh sessions like that doesn't make sense. That's not to say that there isn't some niche use of ssh that this would break, but it's rare. –  sherbang Aug 25 '11 at 12:03
    
This solution is not so good if, like me, you are serving Subversion via ssh. A single SVN query can make a great number of connections in quick succession. If providing that service, you could either use a second sshd service on another port, or whitelist known IPs. I am thinking of using fail2ban or sshdfilter to catch obvious attacks the first time around, without punishing my legitimate users. –  paddy Jan 6 '13 at 21:52
add comment

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 user2@host.example.com

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.

share|improve this answer
add comment

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
share|improve this answer
add comment

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.

share|improve this answer
2  
Whitelisting is hugely important if you are doing any kind of blacklisting unless you want to get locked out. –  Ryaner May 5 '09 at 7:42
2  
+1 for proactively whitelisting. –  Chris Ballance May 5 '09 at 15:37
3  
+1 for having the absolute best answer. Those two things are the only reasonable steps, and they are very effective indeed. Either alone is worthwhile, and both together more so. Boo on the other answers advocating security through obscurity! –  dwc May 23 '09 at 17:44
add comment

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

share|improve this answer
    
-1 Ever heard of DoS attacks? –  Chris Ballance May 5 '09 at 15:38
6  
Yeah, because SSH is the only service susceptible to brute force attacks. If you've got a port open to the Internet, it can be used to hammer your machine into oblivion. You probably put your HTTP server on weird ports too, and behind port knocking, to "avoid DoS attacks"... –  womble May 6 '09 at 0:07
add comment

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.

share|improve this answer
1  
That's what I use. Very easy to set up. –  Magus May 4 '09 at 20:57
add comment

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.

share|improve this answer
3  
Fail2ban is excellent. It was simple to extend it to monitor /var/log/maillog and get it to ban persistent spammers from hitting my mail server –  Dave Cheney May 5 '09 at 15:50
    
Fail2ban can be combined with an iptables chain that sends tcp traffic to the TARPIT target, if you are feeling nasty (from xtables-addons). –  Tobu Jul 2 '10 at 19:19
add comment

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.

share|improve this answer
    
I have tried this and users find it annoying. If it's only one or two people, this could be a good option, and would nearly eliminate brute-force attacks –  Brent May 4 '09 at 17:54
add comment

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

share|improve this answer
1  
If, of course, you system can stand it. –  C. Ross May 4 '09 at 23:23
12  
Security through obscurity, effective every single time. –  Chris Ballance May 5 '09 at 0:59
1  
I wouldn't mind changing the port all that much, but I have learned that most firewalls (other than my own) tend to lock down all ports other than the common ones (80,22, 443, etc). If I am behind those firewalls I cannot get to my home server on that nonstandard port. For me that is a no go. –  grieve May 27 '09 at 20:59
    
@grieve then change our firewall to let that port out? –  Rory Aug 5 '09 at 13:32
    
@Roy I am talking about firewalls other than the ones I own. For example if I want to ssh into my home machine from Starbucks, their firewall blocks the outgoing port. I cannot change that. (I just used Starbucks as an example. I have no idea what ports they actually block or not). –  grieve Mar 6 '12 at 21:16
add comment

Your Answer

 
discard

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.