fail2ban sucks
fail2ban sucks 2020-03-22 -> fail2ban sucks i've made this argument countless times on the internet, so i figure i'd write it down so that i can just link to it instead. this tends to be a controversial opinion, i think. critical note: i am not saying that fail2ban sucks for every use-case, i am mostly writing this in such a way to try and counteract the fervant fail2ban recommendations that i see everywhere, which i think are dangerous. if you like fail2ban, fine, use it - but these are my thoughts. for those unfamiliar with fail2ban, generally speaking, it is a piece of software that monitors log files for login failures, and then interacts with your firewall to block the IP addresses belonging to those failures. It is configurable such that one can say "if an IP fails to login via SSH 10 times in a row, block it for 1 hour." i see fail2ban commonly recommended on the internet. typically when someone new to server administration sets up a server and asks about all of these weird SSH attempts, that's when fail2ban comes up. here are some quotes from fail2ban fans: > One handy service is fail2ban, which will automatically > IP addresses to the firewall if enough failed attempts > are tried > To ban those, you could try to use fail2ban. Seems to be a common approach to > this kind of bot activity. > In this case, a good password with iptables rate limiting, fail2ban & log > monitoring is better. > Non-standard port and/or fail2ban for logspam if you're having fun. > I find the best/laziest combo is ufw/ssh/fail2ban/f2b-loop/logwatch. i have a few arguments, this is the summary: do not change your standard ports. do not use fail2ban. do harden your applications with their built-in mechanisms. if you need super extra security for certain apps, only allow trusted IP ranges - use an IP whitelist. most everyone else is overengineering. fail2ban sucks, let me count the ways. fail2ban: * will not stop an advanced persistent threat * will inconvinience you at some point * may inconvinience *your users* at some point * opens you up to fail2ban vulnerabilities * may make you feel like your system is more secure than it is * is no more secure than a properly configured application * is actually _less_ secure than a properly configured application at best, fail2ban: does nothing at worst, fail2ban: causes you massive inconvinience or total lockout let's put ourselves in the mindset of a new system administrator. they spun up a new capsul[1], they're peeking around their new system. suddenly they notice their SSH logs - hundreds of ip addresses from russia and china attempting to log into their systems over and over. naturally, this triggers what one might call "bad vibes." it makes the system feel less clean. who decided that this was okay? i just finished setting this system up and it's already under attack!? do not listen to their advice, new admin. simply setup SSH properly, and don't worry about a thing. here is my rationale. first, let's think about who exactly those IPs belong to. * bots there are tens of thousands of bots trying common username/password combination against every service known on earth - SSH isn't special. This goes for every login page on the internet that expects a username and a password. Think email and neocities. Think wordpress admin pages and databases interfaces left wide open. if you do not leave your services listening on public interfaces while they're configured with usernames like "admin" and passwords like "admin", you have nothing to worry about. * curious users friends looking to prank you, kids with no idea what SSH even is, maybe that one girl at the bar you pissed off who has Kali installed on her laptop. pro tip: these attempts will likely be less successful than the bots. * advanced persistent threads usually state actors, maybe a botnet operator with a grudge. in either case, fail2ban does nothing - these users can scream through proxies like they're seeing the matrix. they can change their IP address nineteen million times a second without blinking. you can ban a quarter of the IP addresses on earth with fail2ban - the attacker will use another quarter. what i'm saying is, if you're fucked, you're fucked. fail2ban will not help. but if you're secure, you're secure, fail2ban will not help. see what i'm getting at? OpenSSH i'll speak about OpenSSH specifically, but only because it's brought up so often. here are the hardening guidelines that you should abide by. * generate a password protected private/public keypair * use key-based authentication to your system(s) * turn off username/password auth you will still see the failed login messages. ignore them. unless someone hacks your key _and_ the decryption password, they **are not getting in via SSH**. it would take roughly 2,000 years using the dedicated compute power of every computer on earth put together to bruteforce that key. don't sweat it. they are not getting in. fail2ban is good for freeing up resources though, right? wrong. fail2ban has to fuck with a live firewall. it'll probably block you out. every second of your time is worth more than a hundred hours of your compute operating properly. setting up fail2ban takes time, and so does getting yourself unblocked from it. the resources consumed by 10 SSH login attempts per minute is staggeringly low. * if someone is trying to DDOS you, sorry, _you are going to get DDOS'd_, fail2ban will not help. but j3s i have a very valid super-dooper good reason for changing the default OpenSSH port of 22 to some other port well, okay fine. go ahead. but please take the following into account: * changing your SSH port to non-root port (>1024) means that if the SSH daemon dies, any userland process can take its' place. this is bad. * changing your SSH port means that you'll have to do a bunch of fuckery to get basic functionality working. you will very likely waste hours of your life. you will have to google "rsync ssh non standard port" every time you want to use rsync. you will have to remember scp flags. this is also bad. probably worse. * you will have to tell the port to anyone else who tries legitimately accessing your system. in my mind, the only valid use-case for switching your default SSH port is that flipping it to listen on port 80 or 443 will get around most workplace firewalls. well okay fine, OpenSSH is a special case though, right? any application that is used to being bruteforced will likely have protections implemented that you can use against such bruteforcing. for an interesting read, check out spamd: https://man.openbsd.org/spamd > When a sending host talks to spamd, the reply will be > stuttered. That is, the response will be sent back a > character at a time, slowly. For blacklisted hosts, the > entire dialogue is stuttered. For greylisted hosts, the > default is to stutter for the first 10 seconds of > dialogue only. hilarious. are you okay? not really aka, my recommendations: * understand the security mechanisms built-in to your application/daemon * use those mechanisms * get on with your life misc [1]: https://capsul.org fail2ban CVEs: https://www.cvedetails.com/vendor/5567/Fail2ban.html SSH hardening: https://linux-audit.com/audit-and-harden-your-ssh-configuration/
follow me on mastodon!
last updated 2020-03-22T00:00:00.000Z