Tek's Domain

#<NTA:NnT:SSrgS:H6.6-198:W200-90.72:CBWg>

Fail2Ban Behind a Reverse Proxy: The Almost-Correct Way

Fail2Ban is a wonderful tool for managing failed authentication or usage attempts for anything public facing. However, by default, it’s not without it’s drawbacks: Fail2Ban uses iptables to manage it’s bans, inserting a --reject-with icmp-port-unreachable rule for each banned host. The thing with this is that I use a fairly large amount of reverse-proxying on this network to handle things like TLS termination and just general upper-layer routing. Since it’s the proxy that’s accepting the client connections, the actual server host, even if its logging system understands what’s happening (say, with PROXY protocol) and logs the real client’s IP address, even if Fail2Ban puts that IP into the iptables rules, since that’s not the connecting IP, it means nothing. What I really need is some way for Fail2Ban to manage it’s ban list, effectively, remotely. Luckily, it’s not that hard to change it to do something like that, with a little fiddling.

Continue reading

AbuseIPDB Checking With Postfix

Updated Dec 31, 2021

So if you’ve not heard, there’s this website called AbuseIPDB, which, no affiliation, is a website where webmasters can submit reports of abusive IP addresses, and then query those reports, either manually, or using their REST API. And this is how I did exactly that, to help cut down some of the spam on my email server. Let’s get started.

Continue reading

How DNSBLs Work

Ff you’ve dealt with email for any longer than 5 minutes (as an administrator), you already know it’s a mess. There’s so many security measures, so many checks, so many things to combat bad actors and spam. What if we had some way to have some service publish a list of bad DPs, and mail servers could quickly check that mid-transaction so they can have up-to-date information as to if the in-flight message should actually be accepted or not?

Well, we have exactly that. Enter: the DNS Blacklist.

Continue reading