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
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
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