3 ms·
> If you're deploying something to mitigate the risk of brute-force attacks on your server, the problem is that it's possible to brute-force your server, not th
by GekkePrutser 4y ago
> If you're deploying something to mitigate the risk of brute-force attacks on your server, the problem is that it's possible to brute-force your server, not that you don't have an autoblocking system enabled.
Well, even when accepting only certificates some brute force bots are dumb enough to keep trying to connect to try passwords, and this can give a lot of unnecessary CPU load due to all the initial connection crypto handshakes.
Though I have to say most of the bots these days are smart enough to quit as soon as password auth is turned off. But 10 years ago most were really dumb. Using fail2ban was more of a DDOS prevention than a security thing.
- akerl_ 4y agoIt seems improbable that the baseline load of a couple concurrent SSH attempts is higher than the load of running an extra Python daemon that's constantly checking your log files.
- loeg 4y agosshguard is C, and the log file for sshd won't have very much output if there are only a couple concurrent SSH attempts. Don't use this, but not because of concerns about performance overhead.
- akerl_ 4y agoFrom the comment I replied to: > Using fail2ban was more of a DDOS prevention than a security thing.
- GekkePrutser 4y agoWhen I still ran my own server it was a pretty heavy load, like 30% or so. Much more than a minor nuisance. But it was a SPARC server with 1 core at a few hundred MHz and no crypto acceleration. As you can tell this is a while ago :) So yeah I guess these days it's much less of an issue. But the number of possible attempts will have increased too of course.
- akerl_ 4y agoI figured I might as well go pull up some numbers from my personal systems. I've got 3 internet-facing VMs that expose SSH to the world. For the past 30 days, I've seen a combined total of 86k SSH attempts. I've not bothered to filter out my own legitimate sessions, given that they're in the ballpark of ~3 connections a day tops. Total load on each of these systems has stayed below 0.5, and that's including the other actual work the servers do. I don't have a great way to pull out sshd specifically, but it's safe to say that these servers haven't had their operations affected at all by the nefarious attempts. For what it's worth, the one thing I'm doing that could potentially impact the resource consumption is hardcoding cipher/keyexchange/MAC selections. Given that I control 100% of the legitimate clients for these SSH daemons, I've hardcoded the settings as follows: Ciphers chacha20-poly1305@openssh.com KexAlgorithms curve25519-sha256@libssh.org MACs hmac-sha2-512-etm@openssh.com HostKey /etc/ssh/ssh_host_ed25519_key Over 95% of the spam connection attempts get dropped before my server ever does any crypto, because the connecting system doesn't support that KeyExchange choice.
- 5e92cb50239222b 4y ago> I don't have a great way to pull out sshd specifically If it's using systemd, try systemctl status sshd If CPU accounting is turned on, you'll see how much CPU time was used by sshd, plus when it was last restarted, which at least gives you something to work with. If not, you can enable it with: systemctl edit sshd then adding: [Service] CPUAccounting=yes and restarting the daemon.
- GekkePrutser 4y agoThis is really useful, thanks!
- akerl_ 4y agoTIL! Thanks for sharing
- loeg 4y agoTIL about systemctl edit, thanks. Note to others: if you want to override an existing setting, rather than just add new settings, you'll need to use 'systemctl edit --full'.
- amelius 4y agoOn the other hand, shouldn't we be stealing resources from bots, even if it costs us resources too?
- GekkePrutser 4y agoNo. Let them bother someone else :P