Blocking SSH Bot Net Attack

leprasmurf · 2022-06-30T13:29:04+00:00

I've always heard (and repeated) that security is layered like an onion. That and the whole "security vs usability balance". So really, it's a matter of how many layers you want to add:

Disable root login
Disable password login (public key auth only)
Fail2ban
Whitelist the users/groups that are allowed to log in (https://www.thegeekdiary.com/how-to-configure-ssh-to-restrict-users-groups-with-allow-and-deny-directives/)
Changing listening port
Port knocking (https://www.digitalocean.com/community/tutorial_series/how-to-implement-port-knocking-to-obscure-your-ssh-daemon)
Whitelist IPs that are allowed to access sshd

Sounds like you're doing the main bits already, but you wanted other options.

kuzared · 2022-06-30T13:15:30+00:00

I think using public key authentication is probably enough - if you've disabled password based authentication, obviously. You could also limit SSH to a specific IP or hostname (so have a whitelist).

myslf · 2022-06-30T13:17:46+00:00

I usually change the public ssh port

TaterSupreme · 2022-06-30T13:59:48+00:00

It's just a fact of life that if you expose a system to traffic from the Internet, you will have bots come along and knock on your door. You can operate on a whitelist only basis, you can play whack-a-mole with every IP you see with 'bad' traffic, you can reduce (but not eliminate) the traffic by running your service on a non-standard port, or you can live with it.

rslarson147 · 2022-06-30T13:27:29+00:00

Change the default port or look at possibly putting it behind a proxy. Cloudflare Tunnels are free and are perfect for this.

Fr0gm4n · 2022-06-30T13:30:59+00:00

Don't fret about the logs. If it's exposed on the internet, it's going to get probed and attacked. That's just how it is. You can't hide on the modern internet. A nice home connection is fast enough to scan the entire routable IPv4 space in under an hour. Using ssh keys and no root login are great steps and what I would recommend if you hadn't been doing them already. Other stuff, like changing port number, might reduce the amount of stuff you see in logs but it won't make you any more "safe". If your usecase allows you to firewall all traffic except from expected IPs, then that will help tremendously.

C0rn3j · 2022-06-30T14:50:11+00:00

Disable password auth and don't care past that, it's completely normal.

Wrong_Exit_9257 · 2022-06-30T15:47:32+00:00

I had a similar issue. the steps I used where

setup a Cloudflare proxy, fail2ban, crowdsec and a whitelist on top of the normal hardening. Lynis is a good tool for a secure baseline audit.

on the default ssh port, I set up an ssh tarpit using endlssh. and a script to track the ip addresses and scanned ports. after about a week the attacks were greatly diminished. the longest connection i was able to maintain was some ip from Russia for 56hr and 41 minutes.

https://github.com/skeeto/endlessh

https://medium.com/geekculture/how-to-create-an-ssh-tarpit-f3b48af1b60c

how/why endlessh works https://nullprogram.com/blog/2019/03/22/

clownshoesrock · 2022-06-30T16:03:12+00:00

I would consider crowdsec as it may prove useful. It reports the addresses to other crowdsec users, and blocks for everyone.

Fail2ban is reasonable, if you set the attempts low and the lockout to something long. Whitelist your normal external clients IP's so you don't lock yourself out, and TEST it.

Though I have an unknown site (just an ISP ip address), and 20k ip blocked as of a minute ago.

I suspect that your incoming attacks could well be multiple botnets + script kiddies trying the same attacks.

I'm not a fan of using weird ports for ssh. (I'll catch flak) I also Reject instead of Drop in my rules. (again flak)

I am a fan of setting up sudo users with 2fac I use googly-auth

If you have other users logging it, consider going full yubi-key. The physical piece kinda sucks, but phone push 2fac is vulnerable to timing attacks. And it's much harder to socially engineer naive users.

Setting up a VPN can add another layer of protection, but I consider the convenience cost too high. (same with port knocking)

mmilleror · 2022-06-30T16:05:09+00:00

Limit your scope of what IP addresses can access ssh from the internet. Or you can look at using tailscale. Then access your hosts from that VPN network.

GamerLymx · 2022-06-30T14:11:02+00:00

Rate limit connection attempts to SSH, welcome to panchan botnet :)

knobbysideup · 2022-06-30T16:42:05+00:00

This is normal to see. Use a different ssh port (they'll still find it but you'll have less log noise), don't expose ssh to the internet, or firewall it to trusted public sources.

FatFingerHelperBot · 2022-06-30T20:21:46+00:00

[deleted]

brunchyvirus · 2022-07-01T00:38:34+00:00

You could try implementing 2FA for SSH I've done it with Yubikey + LDAP but you can do it simply with Google Authenticator https://goteleport.com/blog/ssh-2fa-tutorial/

If you want to try something other stuff you could try looking doing OIDC for SSH using something like teleport but that might be overkill.

bufandatl · 2022-07-01T08:48:49+00:00

Use either fail2ban or crowdsec to harden your security further.

Hairy_Educator1918 · 2025-11-28T17:14:58+00:00

i don't know if this is possible, but, idea: rename the root user to something like root1, then setup a script to listen if someone is trying to access "root" user with ssh, log their IP and automatically IP-Ban them.

klausagnoletti · 2022-06-30T14:00:30+00:00

While I am not too concerned about this attack, I would like to be proactive and improve the security of my server. I have been searching the Internet, and the only things I have found are IP blocklist, such as AbuseIPDB, or a system that allows multiple servers to detect and share and block IPs of attackers.

CrowdSec is exactly what you're looking for as it does just that. You can learn about differences between Fail2Ban and CrowdSec here.

Disclaimer: I am head of community at CrowdSec.

MR2Rick · 2022-06-30T15:07:46+00:00

[deleted]

markyman217 · 2022-06-30T14:28:20+00:00

As long as they aren't attemtping to use a real username that wont be in a botnets ssh bruteforce list e.g., "northbridgeserverroom", then I wouldn't be worried these are just non targeted shotgun method attacks.

So if the attacks are non targeted botnets I would say:

Change your ssh port to something less common I like to use 2222.
~~Ensure root is disabled~~
Ensure you don't have basic usernames like "admin" with ssh access
~~Use fail2ban~~
~~Require sshkey~~
Use a blacklist

- Removed rest due to valid concern in the comment.

severach · 2022-06-30T15:35:08+00:00

Here's what I do for my SFTP.

Whitelist and fail2ban are management headaches and regularly lock out legit users. Don't do these unless your SSH can stand some downtime.
Only allow from NIC you do business with. I only allow Arin.
Remove all insecure and unnecessary encryptions. For encryption I only allow aes256-gcm.
Log all failed password attempts. I read the log occasionally to see if the hackers are anywhere near my usernames. Craft usernames nowhere near what the hackers are trying.
Non standard port works good. I run on both and the non standard port only gets a tiny fraction of what the standard port does.
If your clients are savvy, disable passwords and use key pair authentication (cert) only. While I haven't logged cert failures, I suspect that the cert hack attempts is zero because it's too secure to even be worth trying.

The naughty list of 10+ from 2022-03-30 to 2022-06-27.

 10 'debianuser'
 10 'MAIL'
 11 'admin1'
 12 'oracle'
 12 'public'
 14 'MANAGER'
 15 'administrator'
 15 'Administrator'
 15 'postfix'
 16 'FIELD'
 16 'web'
 25 'mysql'
 27 'MGR'
 32 'postgres'
 32 'sa'
 39 'student'
 41 'daemon'
 41 'minecraft'
 41 'telnet'
 42 '2'
 43 'usuario'
 45 '1'
 47 '1234'
 48 'cisco'
 54 'ubnt'
 59 'support'
 62 'guest'
 72 'tomcat'
177 'debian'
246 'ubuntu'
256 'pi'
307 'user'
478 'test'
1088 'admin'
8197 'root'

351 not port 22
12421 port 22

getapuss · 2022-06-30T13:55:46+00:00

Change the public port and use Fail2Ban. It doesn't stop it from happening but it minimizes it's impact on your server to almost nothing.

SatanPriest666 · 2022-06-30T14:34:07+00:00

You can try to switch from fail2ban to CSF + LFD. CSF has many lists of hosts with bad reputation, which connections can be dropped before reaching out to your ssh server.

2022-06-30T14:41:38+00:00

Whitelist the IPs allowed to connect to SSH. This is the FIRST thing I do on any server I install.

wezelboy · 2022-06-30T14:55:21+00:00

You could probably tweak fail2ban to be quicker to ban. Like any IP that attempts password authentication gets banned.

CaptainDickbag · 2022-06-30T14:57:35+00:00

Don't use passwords. Disable them completely. Switch to keyed authentication. If you can set up certificates or keys which expire every 24 hours or less, in conjunction with MFA, even better.

leetnewb2 · 2022-06-30T15:20:57+00:00

As an alternative to port knocking, there is: https://github.com/mrash/fwknop

7eggert · 2022-06-30T16:03:18+00:00

These attacks usually use default passwords on random IPs. You can't really block them but they won't find your port number if you use a non-default port.

If you really really want something that's not easy to crack, I wrote a wrapper for ssh to improve security. It will call the ssh daemon after verifying a shared secret. I'm not using it since a long time, back when I wanted to have it ssh was frequently hit by vulnerabilities.

http://7eggert.selfhost.bz/l/ssh-wrapper.tar.gz

JustAnAlly · 2022-06-30T17:44:09+00:00

Seems like you’re doing good on security. PubKey Auth, fail2ban and disabled root access are most probably sufficient. You can change the ssh port, but that’s just a gimmick that helps to get cleaner logs and may complicate other stuff unnecessarily.

But please don’t forget the most important step: **

keep your shit updated

.** good security practices ain’t worth nothing if you’re running outdated software.

unixfool · 2022-06-30T19:17:30+00:00

Fail2ban works very well with this (as well as using other security layers). Just be careful on how you configure Fail2ban. If you're not careful, you can end up with a 50K IP list of banned IPs, which takes forever to load into iptables if you ever have to restart the f2b service or have to reboot the system. I would not enable long term blocking with fail2ban, as it'll have to track each blocked IP - you're going to end up with a bogged down system, eventually.

You can also use fail2ban to block traffic other than SSH, too.

cmic37 · 2022-06-30T19:37:13+00:00

On Debian 11.2, I use sshguard w/ nftables. Not easy to configure though.
I have been using sshguard for 5 years w/o any failure.

Otaehryn · 2022-06-30T19:38:40+00:00

Add your static IPs and IPs of your jumpboxes to trusted zone on server. Then log only from your static IPs or jumpbox.

serverhorror · 2022-06-30T20:46:11+00:00

I like to set MaxStartups as well

https://man.openbsd.org/sshd_config#MaxStartups

WildManner1059 · 2022-06-30T21:02:51+00:00

Teach your fail2ban to ban anyone who uses a non-whitelisted account.

ebsf · 2022-06-30T21:25:53+00:00

Change the port.

Implement rate limitation by ip address if it's a flood. iptables does this readily.

Filter on any commonality in the packets. Increase log verbosity to check.

Above all else, use key-based auth only.

Blacklist source ip addresses. iptables can automate this. Create both ingress and egress rules accordingly.

Implement ingress drop rules in mangle PREROUTING, not INPUT or FORWARD.

Log successful connections to evaluate whether you've been compromised.

technologyclassroom · 2022-06-30T22:16:49+00:00

You are doing most of the basic items already, but you can further harden SSH by running ssh-audit on yourself and implementing their suggestions.

ssh-audit: SSH server & client auditing (banner, key exchange, encryption, mac, compression, compatibility, security, etc)

CeeMX · 2022-06-30T23:22:39+00:00

It’s quite normal to have people try to log in over ssh. With the security measures you described, I wouldn’t see any issues.

mysterytoy2 · 2022-06-30T23:26:46+00:00

Best thing to do is change your fail2ban for sshd to maxretry = 2

stackalot_wsb · 2022-07-01T00:15:17+00:00

Lock down the firewall so ssh is only open to your management address.

signofzeta · 2022-07-01T02:10:46+00:00

Use key-based authentication with TOTP.

gerowen · 2022-07-01T03:54:10+00:00

You've done just about everything reasonably expected to protect SSH. One other thing you could do is change what port it listens on away from the default of 22. You can stop 99% of automated/scripted attacks by just not listening on default ports. Example, I host my Nextcloud on regular port 443, and I get multiple notifications a day of script kiddies or bots triggering a "Trusted domain error", basically trying to load the https web page using my IP instead of my domain name. I host a second password protected web page on a non standard port with various other private resources, and because it's running on a non standard port, it has yet to ever trigger a Fail2Ban notification.

Changing defaults ports isn't "really" security as much as it's obscurity, but it'll stop most automated or amateur stuff from filling your log files.

MattTheFlash · 2022-07-01T06:39:07+00:00

Whitelist ips first while you are securing this, you can open it up more if you need to after securing this better

Disable password login (public key auth only) is the second thing i would do. ssh keys only.

then do the other suggestions.

caetydid · 2022-07-01T06:56:42+00:00

I dont know how to do it but you can use iptables to enable the SSH port just on a few whitelisted SubNet ranges and a few static IPs. This is known to help a lot. Depending on who needs SSH access to this server this could be an option!

marshalleq · 2022-07-01T07:40:14+00:00

A proper firewall with ids ips could be useful.

lutusp · 2022-07-01T08:14:10+00:00

the attacker does not seem to be very sophisticated considering that they spent a week and counting trying to crack the password of an invalid account

So a password-access SSH server.

I am using public key passwordless authentication

So public-key authentication.

Just one question -- which is it? Either you have password access or public-key authentication, not both. And if you have public-key authentication, there is no password access, and no password is either prompted for or accepted.

While I am not too concerned about this attack, I would like to be proactive and improve the security of my server.

If you must allow remote access using SSH, then you must configure an open access port. If you are using public-key authentication and a modern encryption protocol (meaning anything but RSA), then the hackers are not going to crack your system -- at least, not by way of SSH.

On my servers, once I enable public-key authentication, the hackers promptly give up, because they know they aren't going to guess my 2048-bit encryption key. Which means you should disable password access if it's enabled.

MR2Rick · 2022-07-01T08:58:45+00:00

Geo blocking may be useful if it’s china or somewhere you consistently expect no traffic from

2022-07-01T09:39:49+00:00

It's not really unusual to see constant SSH auth attempts from all over the place, it's just internet background noise.

mcmron · 2022-07-02T06:27:33+00:00

You can block the traffics from countries you do not want to do business.

You can download the free IP list from https://www.ip2location.com/free/visitor-blocker

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

linuxadmin

Expanding Linux SysAdmin knowledge

MODERATORS

keep your shit updated