4 ms·
Get a range of ip addresses where you will log in from (your DSL address ranges from home for example), and block all other ip addresses on that port. You may w
by illumen 11y ago
Get a range of ip addresses where you will log in from (your DSL address ranges from home for example), and block all other ip addresses on that port. You may want to add some other hosts you control to that whitelist as well as a backup in case your ISP changes addresses. If you are the only one that is supposed to access some ports, then block everyone else. (use last -a to see all the places you've logged in recently to start making your whitelist).
You can also rate limit new connections to ssh depending on your use cases. So even if your whitelist is beaten you limit the number of attempts.
Now add fail2ban, so that even at 10 new rate limited connections per minute they get banned after X failed attempts.
Change the default port of ssh, to make it harder to find.
Remove password authentication, and make sure you have good secure keys.
You can also disable sudo, and root logins perhaps. As well you could try 2 factor auth, and perhaps move your keys to a secure(encrypted) USB drive.
But really, whitelisting who can connect to ssh in the first place will stop 99% of the automated brute force attacks, with all the rest stopping the remaining 0.99%.
- johngunderman 11y agoWhile this is a good idea to prevent folks from brute-forcing their way into your machine, the article is talking about DDoS attacks. If you have 150G pointed at your network the issue isn't going to be your servers. It's going to be congestion at your network links. Your SSH settings and Fail2Ban won't help at all in this case. You'll need something like CloudFlare's DDoS protection to identify and block DDoS requests from ever reaching your network. EDIT: Oops, just saw that the article does talk about SSH brute-forcing. Your point is quite valid.
- toufka 11y agoThanks. That's very helpful information that's not easily gleaned by awanderin' around 'how to set up a server' tutorials. Simple things like, 'last -a' is a fantastic little hint. Almost would like to make run that command on every ssh session login.
- greyfade 11y agoIf you configure your SSH server for a limited, secure set of ciphers and HMACs, these automated attacks won't even get to the point of attempting authentication. https://stribika.github.io/2015/01/04/secure-secure-shell.html https://stribika.github.io/2015/01/04/secure-secure-shell.ht... Since following the above guide, my auth log has been filled with nothing but this: Sep 30 09:46:00 myserver sshd[74033]: fatal: no matching mac found: client hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160,hmac-ripemd160@openssh.com server hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com [preauth] Of course, I can't use old SSH clients to connect, but it's a good tradeoff, IMO.
- illumen 11y agoThat's very good hint, thanks. There's only been a couple of remote ssh exploits (that I'm aware of) and both of them were stopped by white listing. If you can figure out your address ranges, I think it still makes sense to white list. I guess also the bots will catch up with modern ciphers.