5

I recently received a notification from OSSEC HIDS that warns me about a SSHD brute force attack. Below I report the whole message for the sake of completeness:

OSSEC HIDS Notification.
2020 Mar 03 12:00:17

Received From: commodore->/var/log/auth.log
Rule: 5712 fired (level 10) -> "SSHD brute force trying to get access to the system."
Src IP: 188.166.xxx.xxx
Portion of the log(s):

Mar  3 12:00:16 commodore sshd[21661]: Disconnected from invalid user www 188.166.xxx.xxx port 45788 [preauth]
Mar  3 12:00:16 commodore sshd[21661]: Invalid user www from 188.166.xxx.xxx port 45788
Mar  3 11:59:53 commodore sshd[21204]: Disconnected from invalid user weblogic 188.166.xxx.xxx port 34582 [preauth]
Mar  3 11:59:53 commodore sshd[21204]: Invalid user weblogic from 188.166.xxx.xxx port 34582
Mar  3 11:59:08 commodore sshd[21198]: Disconnected from invalid user stack 188.166.xxx.xxx port 40352 [preauth]
Mar  3 11:59:08 commodore sshd[21198]: Invalid user stack from 188.166.xxx.xxx port 40352
Mar  3 11:58:28 commodore sshd[21193]: Disconnected from invalid user jira 188.166.xxx.xxx port 46186 [preauth]
Mar  3 11:58:28 commodore sshd[21193]: Invalid user jira from 188.166.xxx.xxx port 46186

In order to harden SSH Access to my machine I uploaded my public key to my VPS and disabled SSH password authentication. To sum up, I edited /etc/ssh/sshd_config as follows:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
Banner none
AllowTcpForwarding no
GatewayPorts no
AddressFamily inet

At present my iptables rules are:

-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-N DOCKER
-N DOCKER-ISOLATION-STAGE-1
-N DOCKER-ISOLATION-STAGE-2
-N DOCKER-USER
-A INPUT -i lo -j ACCEPT
-A INPUT -s 127.0.0.0/8 ! -i lo -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p icmp -m state --state NEW -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -m state --state NEW -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables_INPUT_denied: " --log-level 7
-A INPUT -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A FORWARD -m limit --limit 5/min -j LOG --log-prefix "iptables_FORWARD_denied: " --log-level 7
-A FORWARD -j REJECT --reject-with icmp-port-unreachable
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURN

Since I am not an experienced administrator, I would appreciate if you could suggest what response am I expected to use against this kind of attacks. Are my sshd and firewall configurations enough or some further action is required, such as block the 188.166.xxx.xxx ip address?

Asarluhi
  • 1,607
  • 6
    Looks like you did what you need to do (key-based ssh authentication instead of passwords) already. – user535733 Mar 04 '20 at 17:32
  • 1
    I use the key-based authentication on mine as well (which is the best to use), but I have gone some steps further to prevent as far as whole countries and odd IP addresses out there from even getting to my system at all. https://askubuntu.com/a/983591/231142 – Terrance Mar 04 '20 at 18:20

2 Answers2

5

You can use fail2ban. That will do a temporary block of ip addresses with too many tries.

You can check this: How to install fail2ban on Ubuntu Server 18.04. It works for other versions as well.

Eduardo Trápani
  • 1,088
  • 1
  • 7
  • 10
3

You can use the recent module in iptables to automatically identify and ban bad guys. However, in recent years the big players (mainly China) have been merely switching to another ip address on the same sub-net and continuing their attack, so I now block with an arbitrary bit mask. (I don't care about collateral damage, but others might.) Actually, I now use ipsec and block all of China, but that is a different subject. Example iptables rules:

# Dynamic Badguy List. Detect and DROP Bad IPs that do password attacks on SSH.
# Once they are on the BADGUY list then DROP all packets from them.
# Sometimes make the lock time very long. Typically to try to get rid of coordinated attacks from China.
$IPTABLES -A INPUT -i $EXTIF -m recent --mask $BIT_MASK --update --hitcount 3 --seconds 90000 --name BADGUY_SSH -j LOG --log-prefix "SSH BAD:" --log-level info
$IPTABLES -A INPUT -i $EXTIF -m recent --mask $BIT_MASK --update --hitcount 3 --seconds 90000 --name BADGUY_SSH -j DROP
$IPTABLES -A INPUT -i $EXTIF -p tcp -m tcp --dport 22 -m recent --mask $BIT_MASK --set --name BADGUY_SSH -j ACCEPT

Where these rules would have been preceeded somewhere by this:

# Allow any related traffic coming back to the server in.
#
#
$IPTABLES -A INPUT -i $EXTIF -s $UNIVERSE -d $EXTIP -m state --state ESTABLISHED,RELATED -j ACCEPT

And in my case:

#Arbitrary bit mask for the automatic IP blocking stuff (v2.08)
#
BIT_MASK="255.255.252.0"

Note that I also do one other change to the /etc/ssh/sshd_config file to reduce the number of login attempts per connection:

#Smythies.com
#Limit the number of bad passwords per connection to 2. Default is 6.
#Then the iptables connection counter will kick in sooner to drop
#password attack hackers.
MaxAuthTries 2
Doug Smythies
  • 15,448
  • 5
  • 44
  • 61