25

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.

  • 13
    There's a much easier move you can make that will quiet the vast majority of automated SSH password guessing attacks: change your SSH port number. Now, of course, this won't itself be enough to stop any kind of determined attacker; you need to have substantive security measures in place too. (And it sounds like you understand that). But doing that will declutter your logs from traffic from the countless automated bots that scan the net looking for open common ports to throw user name/password guesses against. Allowing you better visibility vs. potentially more concerning types of threats. – mostlyinformed Jan 1 '17 at 7:45
  • 11
    I'd highly suggest using a proper SSH tool like Bitvise, PuTTy, ... and enable public-key auth instead of using some extension in a browser to perform actions a browser isn't meant for and can't provide sufficient security for. – BlueCacti Jan 2 '17 at 10:23
  • You want to read through Secure Secure Shell. – a CVn Jan 2 '17 at 14:31
  • For Chrome secure shell, try the Termius app. It supports private keys. – Dmitry Kudriavtsev Jan 2 '17 at 22:41
  • This question looks like a better fit for Server Fault. – David Foerster Jan 3 '17 at 11:26
53

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.

  • 2
    Temporary blocking like what fail2ban does is ok for short term solution, but generally a permanent blocking is undesirable as these IP are usually part of a botnet and a large number is likely issued by ISPs with dynamic IP allocation or large networks with NAT where many users share a single public IP address. If you get too many of these IP addresses blocked, you may accidentally block legitimate customers as well. – Lie Ryan Jan 1 '17 at 7:59
  • fail2ban or similar should be one of the first things to add to a VPS. Right after changing the default SSH port! As Lie say's use temporary bans since the attacks shift about very rapidly. Usually 10 minutes is enough, I think I use an hour. – Julian Knight Jan 1 '17 at 14:43
  • 2
    fail2ban can send automated abuse reports as well, I think...I never turned it on. – Michael Hampton Jan 1 '17 at 18:07
23

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.

  • 1
    Or just turn off logging of failed login attempts, since they're meaningless if you don't have password authentication enabled. – R.. Jan 2 '17 at 4:27
  • 1
    Anyway +1 because this is the correct approach. Others are varying degrees of exercises in futility/waste of time. – R.. Jan 2 '17 at 4:28
6

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.

  • 2
    It isn't really the bandwidth or processing power that is the issue with these attacks. It is the fact that it floods the logs and so hides other issues or attacks. – Julian Knight Jan 1 '17 at 14:44
3

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.

3

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
1

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

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

  • 2
    @grochmal, he wasn't asking a question, he was answering a small part of the original question. danofsatx, your answer could be improved by adding a screenshot of where you've configured Chrome Secure Shell Client to use keys. – gowenfawr Jan 2 '17 at 18:36
  • @gowenfawr - good point, with the quote i see it. Thanks. – grochmal Jan 2 '17 at 21:23
  • @danosatx, good catch. I could never get "import..." to work, I assumed that support was just under development. – Aage Torleif Jan 2 '17 at 21:51
-3

Setup ssh to login through a different port.

  • 3
    This is a duplicate suggestion from several other answers, and provides less information than all of them. – Xiong Chiamiov Jan 1 '17 at 21:27

Not the answer you're looking for? Browse other questions tagged or ask your own question.