Home / server / Questions / 110822
Accepted
benjisail
Asked: 2010-02-09 10:39:04 +0800 CST

I get 1 failing SSH connection attempt per second from different IP. What can i do?

  • 772

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!

linux apache-2.2 ssh

11 Answers

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

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

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

    • 4

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

    • 2
  5. Best Answer

    So I did a combination of :

    • 1

  6. 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
    • 1

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

    • 1

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

    • 0

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

    • 0

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

    • 0