# [Shellvent] blacklistd: another example why I heavily favor FreeBSD



## ShelLuser (Feb 16, 2018)

Hi gang,

Please note: all the stuff below is merely my impression combined with some opinions and of course mixed in with plain out facts. I definitely don't want to pretend that what I'm venting is the the right way to do things, but all I'm saying is that this steered my hand a bit and I'm enjoying the ride so far.

I've been working hard in preparation for upgrading a 10.3 server not to 10.4 but straight to 11.1. I'm actually looking forward to it, and one of the reasons for that is blacklistd(8) because this service is going to take away a _serious_ issue I've had over the past months due to the changes within the SSHGuard project.

The problem is simple: when it comes to security I'm a control freak. I don't try to claim that I'm doing things right, heck I'll even admit that in some cases I'm seriously overdoing it, but even so... this is what works for me. Right now I'm using IPF ("ipfilter") as my main firewall because I've grown very used to it thanks to my Solaris heritage. With the upcoming upgrade this is going to change to PF, but that's another story.

When it comes to security / intrusion detection then I consider my firewall to be the "last line of defense", which is why I don't allow for any automated process to mess around in it. It's also why I used to appreciate SSHGuard: when it detected something bad it would then utilize TCPWrappers (/etc/hosts.allow) to apply restriction rules. I definitely understand that this isn't the most ideal way to do that, but at least this created a clear separation between "layers" within my security model.

Then SSHGuard changed and it dropped support for TCP wrappers and instead focused itself solely on the firewall. A change I didn't appreciate because, as mentioned, I don't want any automated process to mess with that. For the simple reason that if you can add something to a firewall you can also remove something. Anything at all, and... I don't like the idea of such a service being capable to poke holes in it.

I started looking for a suitable replacement and eventually found a really good product: security/py-fail2ban. Highly customizable, easily extended and best of all: it supports _dozens_ of different actions (including custom ones). From adding rules to several firewall types, reporting the intruder to specific instances (blocklists, cloudflare, netscaler, etc.) and... hostsdeny.conf. TCP wrappers is back 

Unfortunately I still had something to "whine" about. SSHGuard wasn't going far enough for me but in comparison Fail2Ban was almost taking it over the top   Nothing negative here mind you, but in order to get the most out of this you'd had to write plenty of regular expressions. Sure, you can use pre-made stuff but.. I don't know about that.

Another, more important, issue is that Fail2Ban is basically a logfile parser which does not take immediate action. Something SSHGuard did.

And that brings us to blacklistd.

The first pro for me is that this service is part of the base system. Meaning that whenever I have FreeBSD set up I'll also have access to this security layer. That's a bonus. Another pro is that I'm in complete control, just like with Fail2Ban. By default it will use /usr/libexec/blacklistd-helper which is a shell script that supports several firewall types. But thanks to the -C parameter (in combination with the information from blacklistd(8)) it'll be extremely easy to write my own script for this and customize the entire process.

In the mean time I also learned more about pfctl(8) as well as the provided support for different tables. Basically... all this script is going to do is add (and remove) IP addresses from a dedicated table called blist while only the firewall itself will determine what action(s) to undertake with all those addresses (now referring to `block quick from <blist>`).

It seriously pleases me to see that the concerns I ran into with SSHGuard (and by a much lesser degree with Fail2Ban) will eventually be solved by FreeBSD itself, within the form of blacklistd. It's things like that which really strengthen my support & trust for the OS.

At the time of writing I'm very busy testing blacklistd, setting up the upcoming rules for the 11.1 server and finally I'm rebuilding my current IPF firewall and re-structuring the whole thing for upcoming PF usage. In the new situation I'm most likely going to use both blacklistd as an addition to my "last line of defense" (powered by PF) while I'll continue to use Fail2Ban to help me spot unwanted behavior in my logs (for example hosts which persist in trying to abuse my MTA as a mail relay) where those will end up in my firewall as well.

Figured I'd share, not sure why


----------



## lefsha (Feb 20, 2018)

Well, I did the same at the beginning. But very soon realized PF has internal capability to block undesired traffic or login request, that no other tool is required. A single packet filter one have to run anyway, so why add to is something else?


----------



## Sensucht94 (Feb 20, 2018)

I didn't know about blacklistd, that's fantastic, thanks for sharing, I'll give it a try as soon as I can


----------



## ShelLuser (Feb 20, 2018)

lefsha said:


> A single packet filter one have to run anyway, so why add to is something else?


Because PF is operating on the network level whereas undesired login attempts are happening on the application level. I'm aware that PF provides ways for authentication itself (authpf(8)) but that's not usable for me because my server provides several public services which have their own authentication schemes (think about SMTP, POP3 or IMAP). That's something PF doesn't handle.

But another aspect which is much more important to me: I don't want to rely on one single solution, because that also seriously increases my single point of failure. And I definitely don't want nor need a "smart" firewall. All the firewall needs to do is block (or pass) the IP addresses I tell it to. No more, no less.

(dynamically) Determining what should be (temporarily) blocked will be handled by another process. So if that other process, for whatever reason, should somehow fail then I can still fully depend on the main layer (the firewall) to keep unwanted aspects out of my server and services.


----------



## lefsha (Feb 20, 2018)

ShelLuser said:


> Because PF is operating on the network level whereas undesired login attempts are happening on the application level. I'm aware that PF provides ways for authentication itself (authpf(8)) but that's not usable for me because my server provides several public services which have their own authentication schemes (think about SMTP, POP3 or IMAP). That's something PF doesn't handle.



Frankly, I set up blacklistd together with pf. Did it according the manual. Could not find increasing number of IPs blocked by that.
But from what I saw it does the same thing. PF can be used for SMTP POP3 etc as long as you are able to distinguish the type of connection to put on check. I may be wrong, but could not find any difference between 2.



ShelLuser said:


> But another aspect which is much more important to me: I don't want to rely on one single solution, because that also seriously increases my single point of failure. And I definitely don't want nor need a "smart" firewall. All the firewall needs to do is block (or pass) the IP addresses I tell it to. No more, no less.



Do you know what is the difference between chip with 1000 of transistors and 1000 of transistors? - The probability of failure.
Imagine a single transistor has 0.1 % probability to fail. The system with 1000 independent components will have probability to fail
of 63% = 1 - power((1-0.001),1000). With 10 000 components we reach 99.99% failure. It's a law!

N.B. The real failure probability is much lower, than in my example. You need much more components to bring the whole
system down. But the math works exactly as I said.

The Chip is still one single component no matter how many transistors are inside. The whole semiconductor industry is based on that principle
and that is why you've got your PC which runs FBSD and makes you happy. It's totally unfeasible to build the same by using single transistors no matter how much money and electrical power we do have.

In other words if you can rely on a single solution instead of multiple different components you'll better do it. You won't see much difference
with only 2 components. But math won't be on your side


----------

