How to setup IPFW working with blacklistd
rosettas at gmail.com
Wed Nov 15 22:13:43 UTC 2017
On Mon, Nov 13, 2017 at 6:37 PM, Kurt Lidl <lidl at freebsd.org> wrote:
> Greetings all!
> Sorry for not being response to your request for help sooner.
> I had a bit of a hardware crisis here last week, where
> what I thought was merely a blown power supply turned
> out to be a failed motherboard. Getting the 2.5" SAS
> drives back up and running in a different machine took
> far longer than I would have guessed. That, along with
> a secondary MX host that was offline for the first 36
> hours after the main mail server went down was a cause
> for additional excitement.
> I've read through the mail exchange, although its a bit
> hard to follow all of it.
> I'll offer a couple of observations about blacklistd
> and how it operates, and maybe that will shed some light
> on the problem at hand. If not, well, I'd like to start
> fresh with the current configuration, and what you're
> seeing on your host.
Sorry I didn't get this email before, thanks Ian forward me this mail.
> Observations that might help:
> 1) The blacklistd support in 11.0 was broken in a couple
> of significant ways. The blacklistd support in 11.1 is
> thought to be fully functional. If you're not running 11.1,
> you will need to update to 11.1.
The FreeBSD is: 11.1-RELEASE-p1 FreeBSD 11.1-RELEASE-p1 #0: Wed Aug 9
11:17:49 UTC 2017
root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
> 2) I only use blacklistd with 'pf' in my day-to-day usage.
> I extended the support in blacklistd-helper to hopefully
> handle both ipfw and ipf, and it seemed to work OK for my
> test setup. HOWEVER, it is entirely possible that the way
> I did the ipf/ipfw support has a flaw (or more) in it.
> 3) The changes to the various daemons to support the
> blacklist just enable sending messages (and a copy of the
> fd of socket) to the blacklist daemon. The blacklist daemon
> will extract information from the kernel about the socket's
> other end (ie, the information about the remote system),
> and stores that information in a database.
> 4) After the information is stored in the database, the
> blacklist daemon calls the blacklistd-helper script and
> that script is responsible for modifying the firewall
> rules that are in effect. If the script has a bug, it's
> entirely possible that the information in the database
> will be out of sync with the current firewall rules in
> 5) If you're experiencing a situation where the number
> of login attempts is greater than the cutoff for the
> service (e.g., the "1662/1" noted in the email thread),
> that means that whatever firewall rule that is supposed
> to be blocking the service isn't blocking the traffic.
> (See next item for a case where the right rules are in
> the filter, but you still get a "modest" overage of
> attempts vs the cutoff.)
> 6) On a slow-ish single-CPU host (like the sparc64 that I use
> as my gateway), it's possible to get more attempts than
> the cutoff for a persist, high-speed attacker.
> Basically, it takes so long before the system context switches
> to the blacklist daemon, and the entry gets added to the pf table.
> Where "so long" is still less than a second, but the machine has
> already seen 10 or 12 attempts!
> For example, here's a partial list of what my gateway is reporting
> right now:
> root at gatekeeper-130: blacklistctl dump -a
> address/ma:port id nfail last access
> 22.214.171.124/32:22 OK 3/3 2017/11/12 17:31:40
> 126.96.36.199/32:22 OK 23/3 2017/11/12 19:09:38
> 188.8.131.52/32:22 OK 3/3 2017/11/12 19:58:57
> 184.108.40.206/32:22 2/3 2017/11/12 23:39:58
> 220.127.116.11/32:22 OK 3/3 2017/11/13 10:36:15
> You can see a couple of "normally blocked" attempts (3/3),
> a single IP address that has 2 of 3 attempts, and a very,
> very persistent/fast host that got in 23 attempts before
> it got blocked.
I understand. but you may see my problem is the number increased after
> 7) There was a note about different usernames from the same
> remote host. The blacklist support currently does not
> differentiate between usernames. It is just counting the
> number of attempts from a remote IP address.
> There's unfinished support for having a "known bad" set of usernames,
> where a single login attempt for that username will block
> the remote address. This will allow (when finished), easy
> blocking of the twenty or so most common usernames that are
That is great. My problem is one connection one fail from sshd was not
registered into blacklistd as one fail.
> Hopefully this will help.
with kind regards
More information about the freebsd-questions