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?
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):
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.
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.
Are you in India? All those IP addresses listed are in the block:
which according to the WHOIS database is allocated to
One short-term solution is to block the whole block
223.196.160.0/19at 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.
Here is a simple script I wrote to block all unauthorized attempts at logging into my dev server.
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 ACCEPTA log of all IPs banned will be generated.
1. Change your
sshdlistening portAs simple as it sounds, changing your port from the default
22to 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
iptablesto 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
iptablesvia method #4: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:
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/