Slashdot Mirror

← Back to Stories (view on slashdot.org)

Coping With 1 Million SSH Authentication Failures?

Posted by kdawson on from the some-definitions-of-managed dept.

An anonymous reader writes "I own a small Web development studio that specializes in open source software, primarily Drupal, WordPress, and Joomla for small businesses. Our production servers, which host about 50 sites and generate ~20K hits/week, are managed by a 3rd party that I'm sure many on Slashdot would recognize. Earlier today I was researching some problems on one of our sites and found that there have been over 1 million SSH authentication failures from ~1200 IP addresses on one of our servers over the last year. I contacted the ISP, who had promised me that server security would be actively managed, and their recommendation was, 'change the SSH port!' Of course this makes sense and may help to an extent, but it still doesn't solve the problem I'm facing: how do you manage server security on a tight budget with literally no system admin (except for me and I know I'm a n00b)? User passwords are randomly generated, we use a non-standard SSH port, and do not use any unencrypted services such as FTP. Is there a server monitoring program you would recommend? Is there an ISP or Web-based service that specializes in this?"

6 of 497 comments (clear)

  1. fail2ban by Anonymous Coward · · Score: 5, Informative

    fail2ban, key-auth

    1. Re:fail2ban by jimpop · · Score: 5, Informative

      > fail2ban, key-auth

      +1

      Change port. Use iptables to only allow access from known subnets/hosts.

    2. Re:fail2ban by gmack · · Score: 5, Informative

      fail2ban firewalls off the port for a time you specify

      DenyHosts blocks the ip in /etc/hosts.deny

      I find fail2ban to be much more effective since I can use it for more than just SSH (on my system: ftp, imap, pop3, ssh, smtp). Some of the newer botnets will attempt to crack the password using another service and then try the resulting password on ssh so it's important to have more complete coverage.

  2. Re:Move to a higher order port and use denyhosts by sootman · · Score: 5, Funny

    1. Move the default ssh port to a higher order port (5000+)

    Agreed. The higher the better. For the ultimate in security, I recommend 65536.

    --
    Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
  3. Re:Tar Pitting by Anonymous Coward · · Score: 5, Interesting

    I use a variation on tarpitting that has worked very well for me.
    It cut the attempts down from 60,000/day to 20 or 30 per day.

    I just add a small delay between the initial connection attempt
    and when I send the username/password prompt. The delay (in
    seconds) is the number of attempts in the last 30 minutes,
    squared. This makes all but the most determined attacker
    give up and go away very quickly.

    I have been using this with both FTP and SSH for the last
    year, and it works great.

  4. Throttle Inbound Connections by Padrino121 · · Score: 5, Informative

    I have a similar situation and cannot limit to very specific IP ranges. I have done the following with good success. I pulled some examples from my configuration that can be tweaked for yours if you like.

    1. Limit incoming SSH attempts to a low number. In my case I limit to 2 connections in 60 seconds. I can tighten it even more but this did a lot to kill brute force attempts.
    iptables -I INPUT -p tcp -i vlan1 --dport 2242 -j DROP
    iptables -I INPUT -p tcp -i vlan1 --dport 2242 -m state --state NEW -m limit --limit 2/min -j ACCEPT
    iptables -I INPUT -p tcp -i vlan1 --dport 2242 -m state --state RELATED,ESTABLISHED -j ACCEPT

    2. Automatic blacklist via DenyHosts. This helps cut down attempts from known ranges without even giving them the chance even at a slow rate. http://denyhosts.sourceforge.net/