18

I check /var/log/secure and I have these logs:

Jul  9 13:02:56 localhost sshd[30624]: Invalid user admin from 223.196.172.1 port 37566
Jul  9 13:02:57 localhost sshd[30624]: Connection closed by invalid user admin 223.196.172.1    port 37566 [preauth]
Jul  9 13:03:05 localhost sshd[30626]: Invalid user admin from 223.196.174.150 port 61445
Jul  9 13:03:05 localhost sshd[30626]: Connection closed by invalid user admin 223.196.174.150 port 61445 [preauth]
Jul  9 13:03:16 localhost sshd[30628]: Invalid user admin from 223.196.169.37 port 62329
Jul  9 13:03:24 localhost sshd[30628]: Connection closed by invalid user admin 223.196.169.37 port 62329 [preauth]
Jul  9 13:03:29 localhost sshd[30630]: Invalid user admin from 223.196.169.37 port 64099
Jul  9 13:03:30 localhost sshd[30630]: Connection closed by invalid user admin 223.196.169.37 port 64099 [preauth]
Jul  9 13:03:45 localhost sshd[30632]: Invalid user admin from 223.196.174.150 port 22816
Jul  9 13:03:46 localhost sshd[30632]: Connection closed by invalid user admin 223.196.174.150 port 22816 [preauth]
Jul  9 13:06:17 localhost sshd[30637]: Invalid user admin from 223.196.168.33 port 33176
Jul  9 13:06:17 localhost sshd[30637]: Connection closed by invalid user admin 223.196.168.33 port 33176 [preauth]
Jul  9 13:07:09 localhost sshd[30639]: Invalid user admin from 223.196.173.152 port 61780
Jul  9 13:07:25 localhost sshd[30641]: Invalid user admin from 223.196.168.33 port 54200
Jul  9 13:07:26 localhost sshd[30641]: Connection closed by invalid user admin 223.196.168.33 port 54200 [preauth]
...

It seems someone tries to log in by SSH. I disable login by root user and enable public/private key login, but is this a DDoS attack? And does it use RAM/CPU?

What should I do?

2
  • 10
    "I [...] enable public/private key login, ..." - But did you also disable password logins?
    – marcelm
    Jul 10, 2021 at 8:23
  • This answer may also be of interest.
    – marcelm
    Jul 10, 2021 at 8:28

7 Answers 7

45

That's just the normal Internet background noise of people scanning for vulnerable servers.

You can add an iptables rule to rate limit incoming connections (e.g. four in four minutes) for a simple fix (but that will also lock you out if you open too many connections or someone forges SYN packets originating from your address):

iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 240 --hitcount 4 --name ssh-v4 --mask 255.255.255.255 --rsource -j REJECT --reject-with tcp-reset
iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name ssh-v4 --mask 255.255.255.255 --rsource -j ACCEPT

The proper solution is to use a tool like fail2ban that parses the log file for failed logins and creates firewall rules on demand -- a bit more work to set up, but it requires an established connection and a failed authentication to trigger, so it will not react to forged connection attempts or successful logins like the simple approach does.

19
  • 4
    how about changing the ssh port?
    – njzk2
    Jul 9, 2021 at 21:43
  • 11
    @njzk2 It only inconveniences yourself. The bots will find your alternate ssh port sooner or later. Jul 10, 2021 at 0:37
  • 3
    More work to set up? On Debian apt-get install fail2ban will get you protection with reasonable defaults
    – Jasen
    Jul 10, 2021 at 4:46
  • 7
    @LinuxSecurityFreak, there is shodan. Jul 10, 2021 at 8:37
  • 11
    I had an infrastructure operator recommend to me that I change sshd ports long ago, and I thought it was complete garbage, like just many of the comments, here, but I did it anyway. And we still get junk. But compared to the servers where we havent changed, the ports, they're practically idle. It's been 15 years and no amount of Shodan-fu has pointed a large number of bots at our servers. YMMV. This is not security by obscurity. It's merely obscurity. The security comes from using strong ssh keys for authentication and not passwords. Also +1 for fail2ban :) Jul 11, 2021 at 2:37
9

As @Simon Richter mentionned, that's just internet background noise and you shouldn't worry. A few things you have to make sure are that:

Changing the port will make the problem go away, but it's security through obscurity and it can create the illusion of safety while providing none.

Here are a few other recommendations surrounding SSH, as well as counter arguments to mainstream "best practices" arguments.

3

Are you in India? All those IP addresses listed are in the block:

223.196.160.0 - 223.196.191.255   

which according to the WHOIS database is allocated to

descr:   Andhra Pradesh State FiberNet Limited
address: 10-2-1,III Floor, FDC Complex,AC Guards,Hyderabad,Andhra Pradesh-500028

One short-term solution is to block the whole block 223.196.160.0/19 at the firewall, but that is micromanaging IP addresses and becomes an uphill battle.


Instead you could deny ALL ssh except for the source IPs that you know are trusted. Simply take care to not lock yourself out of your own host. If you don't have a static IP, you can permit a block, or possibly look at running a VPN server on the host.

Or if you don't need to permit SSH connections from the internet, just deny them and only reenable when its required.

1
  • 1
    Or use port knocking to whitelist yourself when your IP changes.
    – user10489
    Jul 11, 2021 at 13:50
1

Here is a simple script I wrote to block all unauthorized attempts at logging into my dev server.

#!/bin/bash

ban=$HOME/banned.txt
b_log=/var/log/banned.log

log () {
cat $ban | uniq >>  $b_log
}

l_log () {
lastb | awk '{ print $3 }' | sed -r '/(Mon|Tue|Wed|Thu|Fri|Sat|Sun|boot|tty2)/d' | sort | sed '/^$/d' | uniq | tee $ban
}

drop () {
for x in $(cat $ban); do iptables -A INPUT -s $x -j DROP; done
}

l_log
drop
log
rm -f $ban
echo > /var/log/btmp
iptables-save

If you set the script to run via cron every minute, it will dramatically reduce the noise in your logs and block offending IPs giving them just 1 minute to attempt their brute force before being blocked.

It would be a good idea to insert your IP and any other IPs you access your server with to your firewall iptables -I INPUT -s xxx.xx.xxx.xx -j ACCEPT

A log of all IPs banned will be generated.

3
  • So you're taking the output logs of fail2ban, and permanently dropping those source IPs using iptables rules? Why not just tweak iptables to leave the bad addresses blocked for longer? You're also at risk of blocking your local IPs if you mis-key a password or similar, whereas fail2ban has "don't ever block these ranges" options.
    – Criggie
    Jul 11, 2021 at 19:35
  • 1
    No. I do not use fail2ban, just iptables. I am getting my input from lastb, the last failed log ins, then extracting just the IPs and dropping them.
    – HatLess
    Jul 11, 2021 at 19:45
  • 2
    Sounds like you're reinventing fail2ban. F2B is already a comprehensive tool for exactly this task, no reason to refuse it.
    – iBug
    Jul 12, 2021 at 17:02
1
  1. Use only key-based auth. Many bots only attack password-based systems. Using password-based auth is bad idea anyway.
  2. Use https://www.sshguard.net/ : it blocks IPs after a couple of failed logins.
  3. Use random port (not 22), it will stop some bots.
  4. Make sure your system doesn't permit root login
  5. If you only login from your home, consider only open SSH for your IP/ISP or country.
1

1. Change your sshd listening port

As simple as it sounds, changing your port from the default 22 to a custom value (e.g. 2200) on a public IP could reduce the number of port scans from thousands a day to a few dozen. For a tutorial see here.

That being said, while this does reduce the annoyance of being port-scanned, it DOES NOT provide real security. "Security by obscurity" is a myth and nothing more.

2. Use public key login and disable password login

Bots might guess a password right, but they're never going to guess a private key right. As long as you use modern algorithms and don't leak your key accidentally. For a tutorial see here.

Note that this does mean you will no longer be able to login from any random machine, unless you carry the key with you (which you need to secure via some other way).

3. Use fail2ban

If they fail 5 times, ban them from trying again for a day or something. That'll show them. Very effective against brute force attempts. For a tutorial see here.

The downside is that you might lock yourself out if you've got wobbly fingers one day (drunk or something, I don't know).

4. Pre-ban a list of IPs known for abusive use

Sources like AbuseIPDB maintain big lists of known malicious IPs accessible via API. You will need an API key to use it, but you can register a free account easily enough. Pull the list and use something like iptables to ban those known IPs in bulk. Set up a cron job to automate it periodically for best effect. Here's a very simple script I wrote (and am personally using) to do just that. Feel free to use it as reference, but DON'T USE IT IN PRODUCTION.

In my personal experience, this method is equally effective (if not more so) as method #3.


Personally, I use all 4 methods listed above, and my VPS might get one or two malicious login attempts in my security log at most, in a bad month. Here's the interception history of iptables via method #4:

$ abip-hist
Chain abip-ban (1 references)
 pkts bytes target     prot opt in     out     source               destination
  362 14480 DROP       all  --  *      *       45.143.200.6         0.0.0.0/0
  307 12280 DROP       all  --  *      *       185.156.73.104       0.0.0.0/0
  288 12672 DROP       all  --  *      *       212.133.164.75       0.0.0.0/0
  277 19911 DROP       all  --  *      *       146.88.240.4         0.0.0.0/0
  250 11000 DROP       all  --  *      *       212.133.164.14       0.0.0.0/0
  230  9200 DROP       all  --  *      *       45.146.164.213       0.0.0.0/0
  215  8600 DROP       all  --  *      *       185.156.73.67        0.0.0.0/0
  214  8560 DROP       all  --  *      *       5.188.206.18         0.0.0.0/0
  202  8080 DROP       all  --  *      *       193.27.228.63        0.0.0.0/0
  201  8040 DROP       all  --  *      *       193.27.228.64        0.0.0.0/0
  199  7960 DROP       all  --  *      *       193.27.228.59        0.0.0.0/0
  197  7880 DROP       all  --  *      *       193.27.228.65        0.0.0.0/0
  197  7880 DROP       all  --  *      *       193.27.228.61        0.0.0.0/0
  196  7840 DROP       all  --  *      *       45.135.232.119       0.0.0.0/0
  196  7840 DROP       all  --  *      *       193.27.228.60        0.0.0.0/0
  196  7840 DROP       all  --  *      *       193.27.228.58        0.0.0.0/0
  189  7560 DROP       all  --  *      *       45.146.165.149       0.0.0.0/0
  184  7360 DROP       all  --  *      *       45.155.205.247       0.0.0.0/0
  184  7360 DROP       all  --  *      *       195.54.160.228       0.0.0.0/0
  182  7280 DROP       all  --  *      *       45.143.203.12        0.0.0.0/0
  181  7240 DROP       all  --  *      *       45.141.84.57         0.0.0.0/0
  180  7200 DROP       all  --  *      *       45.135.232.85        0.0.0.0/0
  176  7040 DROP       all  --  *      *       45.146.165.148       0.0.0.0/0
...
this goes on for 1700 lines...

$ uptime
06:36:49 up 16 days, 15:24
1
  • +1 for "change your port". Just don't change it to something equally as attractive (or more) to a would-be attacker. Use an obscure, unassigned, higher-numbered port; something above 10000. I used to run ssh on 23 (the telnet port) just for ha-ha's and wow did that get a lot of connections.
    – Z4-tier
    Jul 12, 2021 at 16:56
0

As other answers mentioned, you don't need to worry to much about it, but if you do want to add another layer of security, you can try using port knocking.

The idea is to keep the ssh port closed, and only open it to ips, that perform a specific sequence of operation prior, something like:

syn port 1000
syn port 2000
syn port 3000
# ssh port is now open
ssh ...

can get more details here: https://www.rapid7.com/blog/post/2017/10/04/how-to-secure-ssh-server-using-port-knocking-on-ubuntu-linux/

You must log in to answer this question.

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