https://j3s.sh/thought/fail2ban-sux.html

|return

fail2ban sucks

another pufferfish drawn by rekka

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/

last updated 2020-03-22T00:00:00.000Z