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.

I get a lot of SSH connection attempt from different IP on my server (with different username). 1 to 5 per seconds. It look like a brute force attack. What can I do to prevent that? Block the IP? change the SSH port? Something else?

Thanks!

share|improve this question

migrated from stackoverflow.com Feb 8 '10 at 19:47

This question came from our site for professional and enthusiast programmers.

add comment

10 Answers 10

The DenyHosts package is one that is freely available and will block "bots" from attempting repeated attacks to your ssh port.

http://denyhosts.sourceforge.net/

Great software for blocking them.

Note: it's also included in many distros by default.

share|improve this answer
add comment
  • You can install fail2ban. It serve exactly this purpose, blocking brute force attempts. It works with other servers like http/ftp/etc too.
  • You can block the ip manually but this is more a temporary solution.
  • You can change the SSH port as you suggest. Unless it is a requirement for you to run it on the standard port, this is a very good idea. Most attackers won't take time to find out if you have a public ssh server running and on what port, except maybe if the attack is targeted specifically at you.
share|improve this answer
    
fail2ban is useless because the bots connect once per botnet IP. –  chris Feb 9 '10 at 13:31
    
it bans IPs every day on my ssh server –  f4. Feb 17 '10 at 23:21
add comment

Changing the ssh port solves it quite well. Never had any problems (it is just too costy for brute forcers to scan the range once there are so many machines with the defaut port).

share|improve this answer
1  
Requiring a key-file also adds a lot to security, on the price of sacrificing some of your mobility (no access-from-any-netcafe, but that is not too safe anyway). –  ron Feb 8 '10 at 18:45
    
I've done this too, but some bots eventually find the port. I wouldn't rely on this alone. It certainly wouldnt stop a brute force attack. A quick scan with nmap and I'd have your SSH port in a heartbeat. :) –  Mech Software Feb 8 '10 at 19:00
add comment

Don't change the port (permanently) it's pointless against any sophisticated attack and only creates obstruction. Good security is in good policy, not obscurity. If you can consider limiting access to a set of known IPs, if you can't consider denyhosts, as mentioned above. You should also talk to your ISP about this, maybe there is an attack on a segment o their network and they are unaware.

share|improve this answer
    
changing the SSH port is the single most useful thing you can do to secure your SSH server. –  Justin Feb 9 '10 at 12:44
1  
no, but it's a single most useful thing you can do to fool yourself that you did improve security. –  monomyth Feb 10 '10 at 19:10
add comment

You might find http://www.snowman.net/projects/ipt_recent/ useful for this - you can do something like this:-

iptables -A INPUT -m recent --rcheck
--seconds 60 -j DROP iptables -A INPUT -i eth0 -d 192.2.0.1 -m recent --set -j DROP
share|improve this answer
add comment
up vote 1 down vote accepted

So I did a combination of :

share|improve this answer
add comment

If you are setting lots of failures from different IP addresses your server is being targeted by a distributed brute force attack. some key points:

  • if you were running ssh on a port other than 22 this attack would have never targeted you
  • running something like denyhosts generally will not help at all because attacks like these are tuned to have a low enough number of attempts per IP - the last attack like this I saw used a few thousand IPs

So, steps to securing your SSH server:

  1. Change the port. Every automated attack only scans port 22. If you are running ssh on port 22 and you start seeing login failures, it just means that you got picked up in a port 22 sweep at some point. If you are running ssh on port 12501 and you start seeing login failures, you have much bigger problems. If all else fails, not having port 22 open prevents you from being an easy target.
  2. Block access to the ssh port from everywhere but your network. If you don't have a static IP, then setup knockd or a VPN to allow you to connect from anywhere. Setting up knockd is considerably simpler than setting up a VPN.

Requiring key based authentication doesn't really secure the ssh server, it secures authentication. If you only rely on key based authentication to secure the server, you open yourself up to any potential exploits against openssh. If a 0day exploit was released against openssh and you are running ssh on port 22 and relying on keys to "secure" your server, it will be hacked within hours.

A much better practice is to not even allow people to connect to the ssh server in the first place.

share|improve this answer
add comment

+1 for changing the port.

If you always have a static IP, block all access from everything but that IP.

It's difficult to block IPs if either you have a dynamic IP, or your brute force attack is coming from multiple IPs.

If the IPs are common, i.e. it's always a range of 10 IP addresses doing the attack, find out which ISP owns them and submit an abuse report with log entries.

share|improve this answer
add comment

another +1 for changing ports - at a bare minimum. Otherwise, set up a VPN and firewall everything except the VPN connection. It's the best of both worlds in my opinion.

share|improve this answer
add comment

If it is a single (or only a few) remote IPs trying to log in, you can install a host route for the IP(s), with a gateway of 127.0.0.1 (the loopback interface). That way, they cannot establish a TCP session, but you run the risk of running out of kernel resources (at 1-5 attempts per second, it should be OK, though).

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