How to respond to a SSH brute force attack on a single VPS?

Question

I logged onto my VPS this morning to find millions of failed login attempts for the root user and other users that don't even exist. I took the below measures to try and obfuscate the attackers efforts which (have been going on for months).

Question(s)

1. Is this an appropriate response?
2. What more can be done?
3. Is there anything valuable I can do with a list of these IPs?

System info for a Centos7 vps

uname -a
inux vm01 3.10.0-327.22.2.el7.x86_64 #1 SMP Thu Jun 23 17:05:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

step 1

Created a script to grab all the IP addresses that failed to login from the secure log. (/var/log/secure)

# get_ips.sh
grep "Failed password for" /var/log/secure \
| grep -Po "[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+" \
| sort \
| uniq -c

step 2

Write a script to create firewall rules to block the ip address that are found from the script in step 1. This script is ip_list_to_rules.sh

#!/bin/bash
# ip_list_to_rules.sh
# script to parse output of get_ips.sh and create firewall rules
# to block ssh requests

if [ -z $1 ]; then
  echo "arg1 must be path to a list of the form <COUNT> <IP>\n"
  exit
fi

LIST=$(readlink -f $1)
SSH_IP=$(echo $SSH_CLIENT | head -n1 | awk '{print $1;}')

echo "Reading IPs from ${LIST}"
echo "SSH Client IP will be ignored (${SSH_IP})"

while read COUNT IP; do

  echo "Creating rule for ${IP}"
  firewall-cmd --direct --add-rule ipv4 filter INPUT 1 -m tcp --source $IP -p tcp --dport 22 -j REJECT
  firewall-cmd --direct --add-rule ipv4 filter INPUT 1 -m tcp --source $IP/24 -p tcp --dport 22 -j REJECT

done<<<"$(cat ${LIST} | grep -v ${SSH_IP})"

step 3

Run it all and save rules.

./get_ips.sh > attack_ips.list
./ip_list_to_rules.sh attack_ips.list
firewall-cmd --reload

Update

Below are the measures I took from the answers.

1. Disabled root logins
2. Changed SSH port
3. Install & configured fail2ban
4. Disable password authentication & enable public key auth

I didn't actual do 4 because I usually connect through chrome secure shell client and AFAIK there isn't public key support.

Answer 1

Yes, this is a perfectly reasonable and common approach. However, you've reinvented fail2ban. You probably want to switch to using that instead so you don't have to debug issues with your script and can make use of the existing filters for ssh, apache, and other common services.

Unfortunately, there is not terribly much you can do with these IPs. You can try to report the activity to the abuse contact listed for their IP block, but it's not really worth your time unless they do something more serious.

You should also do the standard ssh hardening, like disabling password-based and root logins unless you absolutely need them.

Answer 2

The most effective way to secure SSH system is to login using ssh private key only. You should disable password authentication and disallow direct root login. After that, you will still get many failed authentication attempt, but there's no chance in hell brute force attacker will be successful.

If you want to keep your logs clean after this, you should move your SSH port to a different port number.

Answer 3

It may be intimidating to see a million failed login attempts, but honestly the bandwidth and processing power these attempts are using ... is trivial.

So the real question becomes, is your system secure:

• Did you disable root login?
• Did you disable password authentication in favor of pub key?
• Did you change the default port of the sshd service on your VPS?

all of these changes can be done in the /etc/ssh/sshd_config file (make sure you restart sshd after making your changes)

You could use fail2ban, or some custom script to block these IPs on the firewall but the sshd authentication by itself is secure enough on its own ... adding more complexity is not necessarily any more secure and will most likely cause you to accidentally lock yourself out of the vps.

Answer 4

As others have mentioned. Fail2ban with pretty harsh rules (for example: 3 wrong password or attempt to login with non-existent user) can be very effective.

I would also suggest moving SSH to a non-standard port. Of course this does not help at all against any kind of intelligent attack but it does weed out the most basic automated scanners of which there are quite a few.

If you combine this with something that detects port scanning and connect that with fail2ban you can even fend quite a large portion of scanners, botnets and other crap.

Answer 5

You can set IP tables which won't lock down your entire server, but slows brute force attacks to a point where they become ineffective.

Restricting SSH access by IP addresses is the most secure method. Changing SSH port may defeat bot scans but does little against targeted attacks.

In terminal, type

/usr/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
/usr/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

This will block new IP address if it connects more than 3 times per minute. Established connections results in successful authentification. You can also log what's being done here by setting a log rule

/sbin/iptables -N LOGDROP
/sbin/iptables -A LOGDROP -j LOG
/sbin/iptables -A LOGDROP -j DROP
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j LOGDROP

Answer 6

You could try installing fail2ban, or you can do things like disable direct root login or change default ssh port

Answer 7

4. Disable password authentication & enable public key auth

I didn't actual do 4 because I usually connect through chrome secure shell client and AFAIK there isn't public key support.

I use the Chrome Secure Shell Client on my Chromebook, and it does support public key authentication. I have disabled password authentication on all of my systems, and have zero trouble accessing them from the Chromebook or from my phone using Juice.

Answer 8

Setup ssh to login through a different port.