How to setup IPFW working with blacklistd

[Cos Chan]

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.
>
> Anyway.
>
> 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
i386


>
> 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
> effect.
>
> 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
> [...]
>  61.126.187.219/32:22   OK      3/3     2017/11/12 17:31:40
>   156.212.51.78/32:22   OK      23/3    2017/11/12 19:09:38
>  179.53.156.109/32:22   OK      3/3     2017/11/12 19:58:57
> 220.174.236.220/32:22           2/3     2017/11/12 23:39:58
>  198.245.63.120/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
blocked.


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


That is great. My problem is one connection one fail from sshd was not
registered into blacklistd as one fail.


> Hopefully this will help.
>
> -Kurt
>
>
>>


-- 
with kind regards