Lots of failed authentication requests from all over the world on brand new GGL cloud SFTP server

Question

I created my first public server - an SFTP server hosted on google cloud. I was checking the auth log during the 2nd day of testing and noticed that I'm getting 4-10 hits from random people every minute!! 3700 failed requests in 16 hrs - this seems ridiculous, so I want to know if there is any way to stop them. I have almost zero experience with firewalls - I was hoping to avoid defaulting to reject everyone and only allow whitelisted IPs, but maybe I'll have to consider it.

Apr  4 13:34:05 nfp sshd[12034]: Failed password for invalid user tjkim from 134.122.9.249 port 48930 ssh2
Apr  4 13:34:13 nfp sshd[12107]: Failed password for invalid user barman from 198.58.119.132 port 39626 ssh2
Apr  4 13:34:16 nfp sshd[12119]: Failed password for invalid user rscreen from 203.205.37.233 port 33740 ssh2
Apr  4 13:34:16 nfp sshd[12121]: Failed password for invalid user oakda from 164.90.194.36 port 41566 ssh2
Apr  4 13:34:18 nfp sshd[12123]: Failed password for invalid user lia from 43.130.60.190 port 46610 ssh2
Apr  4 13:34:20 nfp sshd[12125]: Failed password for invalid user hongphong from 193.106.60.145 port 33020 ssh2
Apr  4 13:34:23 nfp sshd[12127]: Failed password for invalid user uucpsh from 157.245.101.31 port 59112 ssh2
Apr  4 13:34:27 nfp sshd[12129]: Failed password for invalid user legaltech from 43.154.249.125 port 33970 ssh2
Apr  4 13:34:51 nfp sshd[12132]: Failed password for invalid user dhamu from 164.90.198.71 port 36212 ssh2
Apr  4 13:34:57 nfp sshd[12134]: Failed password for invalid user onapp from 115.182.105.68 port 46286 ssh2

Any guidance for a newbie?

Answer 1

Your server is on the public Internet. Hackers will attempt to break into anything, so what you are seeing is normal and annoying.

Provided that you have only enabled SSH keypairs and not password-based authentication you are OK regarding security.

I prefer to only allow SSH from known IP addresses via VPC firewall settings. Modify the default-allow-ssh rule to allow only your public IP address (from home, the office, etc).

Answer 2

Tried fail2ban with these settings:

[sshd]
enabled = true
filter = sshd
logpath = /var/log/auth.log
maxretry = 2
bantime = -1

That didn't work. It only banned the IPs for a very short period of time even though bantime = -1.

After fixing it (by creating and tweaking jail.local as specified above) it works as expected. /var/log/fail2ban.log

2022-04-06 18:23:42,470 fail2ban.filter         [578]: INFO      maxLines: 1
2022-04-06 18:23:42,471 fail2ban.filter         [578]: INFO      maxRetry: 2
2022-04-06 18:23:42,471 fail2ban.filter         [578]: INFO      findtime: 600
2022-04-06 18:23:42,471 fail2ban.actions        [578]: INFO      banTime: 691200
2022-04-06 18:23:42,471 fail2ban.filter         [578]: INFO      encoding: UTF-8
2022-04-06 18:23:42,471 fail2ban.server         [578]: INFO    Jail 'sshd' reloaded

Also tried to cut down on attacks by:

sudo grep "Apr  4.*Fail.*from.*port" /var/log/auth.log | sed 's/.*from //g;s/ port.*//g'|sed '/.*COMMAND.*/d' | sort | uniq > ban_these

while read ip; do sudo ufw deny from $ip to any; done < ban_these

That didn't help much. The traffic came back in a day (different IPs).

Had to finally run:

sudo ufw default deny incoming
sudo ufw allow from m.y.i.p/24

That stopped the pests but now I have to whitelist everyone I want to give access to. So a trade-off.

Unfortunately, this resulted in me being locked out of my server when I took my laptop elsewhere. Here is a link to help if this happens to you: How to access GCP server after being locked out due to ufw

Update:

It turns out the tutorial I initially followed was not very good (it had the settings in fail2ban.local). That's why my implemenation of fail2ban wasn't working as expected. It was a good lesson about the importance of official documentation! After finding official documentation here the jail settings should be in jail.local (which starts as a copy of jail.conf), and not fail2ban.local.