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: Failed password for root from 220.127.116.11 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 18.104.22.168 port 59666 ssh2 Failed password for invalid user nagios from 22.214.171.124 port 60725 ssh2 Failed password for invalid user nagios from 126.96.36.199 port 32884 ssh2 Failed password for invalid user oracle from 188.8.131.52 port 34008 ssh2 Failed password for invalid user oracle from 184.108.40.206 port 34506 ssh2 Failed password for invalid user weblogic from 220.127.116.11 port 38702 ssh2 Failed password for invalid user weblogic from 18.104.22.168 port 39317 ssh2 Failed password for invalid user ftp1 from 22.214.171.124 port 39995 ssh2 Failed password for invalid user ftp1 from 126.96.36.199 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.
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.
-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.