25

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?

Improve this question
2

3 Answers 3

Reset to default
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

Improve this answer
11
  • 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
    Commented Feb 22, 2018 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
    Commented Feb 22, 2018 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
    Commented Feb 23, 2018 at 4:37
  • 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
    Commented Feb 23, 2018 at 11:55
  • 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
    Commented Feb 23, 2018 at 14:22
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.
Improve this answer
1
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
Improve this answer
2
  • What is date -j annd -v supposed to do? Neither exist as options in my systems "date" command.
    – Ken Ingram
    Commented Oct 10, 2019 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
    Commented Jan 21, 2020 at 2:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .