26

I reviewed the auth.log file on my Ubuntu server to find:

[preauth]
Feb 22 17:39:18 code-storage sshd[17271]: Disconnected from 147.135.192.203 port 49408 [preauth]
Feb 22 17:40:15 code-storage sshd[17273]: Invalid user ellen from 147.135.192.203
Feb 22 17:40:15 code-storage sshd[17273]: input_userauth_request: invalid user ellen [preauth]
Feb 22 17:40:15 code-storage sshd[17273]: Received disconnect from 147.135.192.203 port 50193:11: Normal Shutdown, Thank you for playing [preauth]
Feb 22 17:40:15 code-storage sshd[17273]: Disconnected from 147.135.192.203 port 50193 [preauth]
Feb 22 17:40:34 code-storage sshd[17275]: Connection closed by 103.237.147.107 port 17583 [preauth]
Feb 22 17:41:12 code-storage sshd[17277]: Invalid user emil from 147.135.192.203
Feb 22 17:41:12 code-storage sshd[17277]: input_userauth_request: invalid user emil [preauth]
Feb 22 17:41:12 code-storage sshd[17277]: Received disconnect from 147.135.192.203 port 50841:11: Normal Shutdown, Thank you for playing [preauth]
Feb 22 17:41:12 code-storage sshd[17277]: Disconnected from 147.135.192.203 port 50841 [preauth]
Feb 22 17:42:05 code-storage sshd[17280]: Invalid user enzo from 147.135.192.203
Feb 22 17:42:05 code-storage sshd[17280]: input_userauth_request: invalid user enzo [preauth]
Feb 22 17:42:05 code-storage sshd[17280]: Received disconnect from 147.135.192.203 port 51356:11: Normal Shutdown, Thank you for playing [preauth]
Feb 22 17:42:05 code-storage sshd[17280]: Disconnected from 147.135.192.203 port 51356 [preauth]
Feb 22 17:42:14 code-storage sshd[17282]: Connection closed by 103.237.147.107 port 64695 [preauth]
Feb 22 17:43:00 code-storage sshd[17285]: Invalid user felix from 147.135.192.203
Feb 22 17:43:00 code-storage sshd[17285]: input_userauth_request: invalid user felix [preauth]
Feb 22 17:43:00 code-storage sshd[17285]: Received disconnect from 147.135.192.203 port 52145:11: Normal Shutdown, Thank you for playing [preauth]
Feb 22 17:43:00 code-storage sshd[17285]: Disconnected from 147.135.192.203 port 52145 [preauth]
Feb 22 17:43:52 code-storage sshd[17287]: Connection closed by 103.237.147.107 port 55122 [preauth]
Feb 22 17:43:56 code-storage sshd[17289]: Invalid user fred from 147.135.192.203
Feb 22 17:43:56 code-storage sshd[17289]: input_userauth_request: invalid user fred [preauth]
Feb 22 17:43:56 code-storage sshd[17289]: Received disconnect from 147.135.192.203 port 52664:11: Normal Shutdown, Thank you for playing [preauth]

There is much more than this, but this is from the last few minutes before I copied the log file.

Is this a brute force SSH attack, and if so should I be worried and what are the best mitigation steps and/or solutions other than changing the server IP?

David Kamer
  • 456
  • 1
  • 4
  • 13

3 Answers3

44

Is this a bruteforce attack

This looks like the background scanning that any server on the internet will experience.

Should I be worried

Not really, background scanning is completely normal, as long as your passwords are secure background scanning should pose no risk.

What are the best mitigation steps

You can use the following to make the server more secure:

  • Disable SSH service when you don't need it.
  • Only allow login using key auth
  • Disable root ssh access
  • Use a system like Fail2Ban to block brute force attempts

Should I change IPs

Changing IPs will probably not affect automated background scanning much

U. Windl
  • 137
  • 7
jrtapsell
  • 3,169
  • 15
  • 30
  • 9
    It's probably easier (and more effective) to change your SSH port. Since this is background scanning, it (or someone else) will find you at your new IP address. But if you use an obscure port, background scanning is far less likely to find you. – PopularIsn'tRight Feb 22 '18 at 19:35
  • 8
    I agree, changing the service to a non-standard port will work wonders, but it doesn't make the system more secure, it just hides it from simple automated scanners. Something else you can do if valid logins only come from a few IP ranges is to set an iptables firewall rule to only accept connections from these ranges. This reduces the possible source locations an attack can be launched from. – Out of Band Feb 22 '18 at 19:57
  • 3
    Disabling root SSH access is unnecessary (and can sometimes be harmful) if you are only using public key auth, assuming you actually do need to use root for management and aren't just SSHing in to a personal account. Using `su` to get to root from a potentially compromised account is less secure than simply SSHing in as root directly via public key auth. – forest Feb 23 '18 at 04:37
  • If you want to get a little fancy, although a bit OTT, you could look into port knocking – ScottishTapWater Feb 23 '18 at 10:35
  • @forest except these attacks seem to target root overwhelmingly more often than ordinary accounts, which is thus much _more_ likely to get compromised directly. – leftaroundabout Feb 23 '18 at 11:41
  • 2
    @leftaroundabout: This is why forest limits it to setups which use public key auth. The chance that an attacker will guess your private key is very, very close to 0, so it doesn't matter that he knows your user name (root). Personally I've never seen anyone trying to brute-force public key auth on any of my servers (because everybody knows it's pointless). – Out of Band Feb 23 '18 at 11:55
  • what do you mean with background scanning? – luizfzs Feb 23 '18 at 13:35
  • 3
    @luizfzs It just means the general "background noise" of the internet. That is, it's pervasive and is not out of the ordinary. Bots do it all the time to every IP address that exists. – forest Feb 23 '18 at 14:22
  • You can also use port-knocking to only open port `22` when you do a random sequence of SYN requests to certain ports. I did this because the logs of fail2ban were so annoying. Sure: changing to a non standard port works too, but someone will find it anyway. Much harder to try a sequence of 5 randomly generated ports. – Bakuriu Feb 23 '18 at 20:38
  • @Bakuriu The issue with port knocking is that it can become harder for _you_ to log in. When using a non-standard port (**remember to keep it a low port!**), there will still be far fewer attack attempts. Port knocking would only work well for a situation where the server needs to stay under the radar, not giving away what services it is running even to a determined attacker. – forest Feb 24 '18 at 02:38
  • @forest It **always** work; a non-standard port works far fewer times. Sure you now have to `knock`+`ssh` to login, but that's not an issue *for me*. – Bakuriu Feb 24 '18 at 09:14
5

As previous comments pointed out already, changing IPs will NOT prevent you from being scanned by malicious scanners.

I will sum up the necessary steps to really secure your SSH-service :

  • as people have mentioned beforehand : change the port to a non-standard (highport) value, e.g. a value like 13322. This is not a real security advantage, but it makes it harder for any bot to find the active SSH-port.
  • ONLY use secure keys for authentication, if possible, deactivate keyboard-auth with passwords completely !!
  • Use fail2ban - service, which is available for any unix-like system / linux-derivate. This service will automatically ban a specific ip after n failed auth-tries for a defined time. Ban is realized via iptables rules, so iptables is a requirement.
Oliver
  • 51
  • 1
  • See https://security.stackexchange.com/questions/32308/should-i-change-the-default-ssh-port-on-linux-servers for arguments for changing the port. TL;DR: It is be useful, but you may want to use a port less than 1024 . – allo Jul 20 '18 at 09:17
1

An alternative to fail2ban, you could set up an hourly cron job to run a simple script like the one below. Adjust the first 4 parameters as you see fit. It works with pf.

if you are not using pf you would need to replace the pfctl ... line to something that works with your firewall.

Also set up a daily cron job to flush pf table: pfctl -t bruteforce -vT expire 86400

#!/bin/sh -f
#
# Check 'Invalid user' attempts on sshd in auth.log (LOGFILE).
# If there are more than (MAX_TRY) attempts within
# the last hour (EARLIEST), source ip is added to PF_TABLE table in pf
#
MAX_TRY=5
LOGFILE=/var/log/auth.log
# last 48 hour
EARLIEST=`date -v-48H +%s`
PF_TABLE=bruteforce

grep "Invalid user" $LOGFILE | while read d0 d1 d2 rest; do
    timestamp=`date -j -f "%b %d %H:%M:%S" "$d0 $d1 $d2" +%s`
    test $timestamp -lt $EARLIEST && continue
    echo $rest | cut -d ":" -f2- | cut -d " " -f6
done | sort | uniq -c | while read count ip; do
    test $count -lt $MAX_TRY && continue
    pfctl -v -t $PF_TABLE -T add $ip
done
schroeder
  • 123,438
  • 55
  • 284
  • 319
ping mai
  • 11
  • 1
  • What is date -j annd -v supposed to do? Neither exist as options in my systems "date" command. – Ken Ingram Oct 10 '19 at 11:39
  • 1
    @KenIngram it converts the timestamp in syslog to seconds since epoch. you're probably using gnu date instead of the posix version, which has '-j'. in your case change the date cmd to: `date --date="$d0 $d1 $d2" +%s` – ping mai Jan 21 '20 at 02:25