Your browser (Internet Explorer 6) is out of date. It has known security flaws and may not display all features of this and other websites. Learn how to update your browser.

Defend Your Server From SSH Attacks

You hear about servers getting hacked all the time but when was the last time you checked to see if anyone has been trying to break into yours? Attacks can target any public facing services on your box but SSH attacks are among the most common.

Quickly peeking into your auth.log file will show you all the login attempts on your server both successful and failed.

View all the entries in your auth.log file.

sudo cat /var/log/auth.log

Depending upon how active your server is and when the file was last rotated will determine how many entries you see. Let’s narrow our focus to the failed attempts.

View failed authentication attempts in your auth.log file.

sudo cat /var/log/auth.log | grep -i "failed"

If you read the quick guide to grep post you’ll notice the grep -i tells grep to match lines containing “failed” regardless of case. It comes in handy for the auth.log file since the word appears as both “Failed” and “failed”.

So what does a failed attempt look like? Lets check out an example.

sshd[7111]: Failed password for root from port 58670 ssh2

The log entry includes some basic info about the account they were trying to access root, the ip address of the machine making the connection and the port on the machine they were connecting from. This is just one line from the file. Over 20 attempts were made from that IP address all trying to gain access to the root account through a brute force SSH attack.

Another common pattern is to see the same ip address try to gain access to a number of different user accounts on the system.

Failed password for invalid user user from port 59666 ssh2
Failed password for invalid user nagios from port 60725 ssh2
Failed password for invalid user nagios from port 32884 ssh2
Failed password for invalid user oracle from port 34008 ssh2
Failed password for invalid user oracle from port 34506 ssh2
Failed password for invalid user weblogic from port 38702 ssh2
Failed password for invalid user weblogic from port 39317 ssh2
Failed password for invalid user ftp1 from port 39995 ssh2
Failed password for invalid user ftp1 from port 40498 ssh2

Here the attacker was trying to access accounts created by common server software (nagios, oracle, weblogic, ftp). This was just a quick snippet from this ip address which had well over 50 entries in the log file.

To put the numbers into perspective. The log file for this particular server was last rotated 4 days ago and it already had a whopping 3,198 failed login attempts! How many are in your log file?

Count the failed login attempts in your auth.log file.

sudo cat /var/log/auth.log | grep -c -i "failed"

Now let’s look at two quick steps you can take to reduce these attacks. The server above was listening on default SSH port (22). One of the easiest steps you can take is to change the SSH server so it listens for incoming connections on a more obscure port.

This is the real-world equivalent of removing the big “entrance” sign from your front door. Its still possible for attackers to figure out the new port but they have to knock on each door or probe each open port on your server to figure it out. That’s just enough security through obscurity to greatly reduce some of the most common attacks which blindly target port 22.

Change the default SSH port

Pop open your SSH server config file in your favorite linux editor (mine’s vi).

sudo vi /etc/ssh/sshd_config

Find the Port configuration line.

# What ports, IPs and protocols we listen for
Port 22

Change it to a higher port that’s not already used by another service.

Port 5430

Restart your SSH server and your back in business!

sudo /etc/init.d/ssh restart

Connect to your server on the new port using the -p option.

ssh user@yourserver -p 5430

Take it one step further with IPTables

Applying these IPTables rules will automatically block ip addresses that attempt more than 3 new connections to your server within 90 seconds. The ip address of each attacker will be blocked for 90 seconds which should be enough to timeout the script running the attack.

IPTables rules

-I INPUT -p tcp --dport 5430 -i eth0 -m state --state NEW -m recent --set
-I INPUT -p tcp --dport 5430 -i eth0 -m state --state NEW -m recent --update --seconds 90 --hitcount 4 -j DROP

These rules only affect new connections so anyone one who authenticates successfully won’t be impacted. If your not sure where to put these rules stay tuned for an upcoming step by step guide to setting up IPTables rules.

  • Njbuk

    how do you actually set the iptable rules?

  • David Feinberg
  • Hans Lootens

    Using denyhosts also helped a lot to me. It blocks IP addresses after x failed attempts for y days and reports those newly denied hosts through e-mail. It’s available as a package in Ubuntu and reduced the number of login failures enormously. While using the iptable rules only slows down brute force attacks, denyhosts starts refusing connections after a few authentication failures.

  • David Feinberg

    Excellent tip Hans! Thanks for sharing.

  • Anonymous

    these stuff are really helpful man.
    Please keep it going

  • Ana

    Where should I add these firewall rules?