How to setup IPFW working with blacklistd

Cos Chan rosettas at
Thu Nov 16 21:03:26 UTC 2017

On Thu, Nov 16, 2017 at 3:57 PM, Kurt Lidl <lidl at> wrote:

> On 11/16/17 2:27 AM, Cos Chan wrote:
> In that case I test sshd MaxAuthTries=1 and blacklistd nfail=1 and still
>> get wired entry.
>> $ sudo blacklistctl dump
>>          address/ma:port id      nfail   last access
>> <>           0/1     1970/01/01
>> 01:00:00
>> $ sudo cat auth.log | grep
>> Nov 16 07:04:17 res sshd[31112]: Invalid user pi from
>> Nov 16 07:04:17 res sshd[31113]: Invalid user pi from
>> Nov 16 07:04:17 res sshd[31112]: Connection closed by port
>> 51140 [preauth]
>> Nov 16 07:04:17 res sshd[31113]: Connection closed by port
>> 51144 [preauth]
>> $ cat blacklistd-helper.log | grep 'Nov 16'
>> ...
>> Thu Nov 16 07:01:28 CET 2017 /usr/libexec/blacklistd-helper run add
>> blacklistd tcp 32 22
>> Thu Nov 16 07:14:05 CET 2017 /usr/libexec/blacklistd-helper run add
>> blacklistd tcp 32 22
>> No action from blacklistd-helper? how could that entry be added to
>> database?
>> no logs concerning from blacklistd either
>> $ cat blacklistd.log | grep 'Nov 16'
>> ...
>> Nov 16 07:01:28 res blacklistd[23916]: blocked <
>>> for -1 seconds
>> Nov 16 07:14:05 res blacklistd[23916]: blocked <
>>> for -1 seconds
> Pre-auth failures from sshd, where the username isn't found ("Invalid user
> pi"), don't count against failed login attempts, because no
> authorization was ever attempted by sshd.
> I made the decision not to count these against the limit in blacklistd.

 I am curious why not. In my opinion the text in blacklistd man page is
quite good and clear:
 "The nfail field contains the number of failed attempts before access is

In my opinion the bad username attempts are exactly same as bad password
attempts, all of them are failed attempts.

> There is a message sent from sshd to blacklistd when this occurs (bad
> username), but this is the part that isn't implemented in the backend,
> for banning addresses that hit known-bad usernames.
> I suppose the case could be made that a bad username is just as serious
> as a bad password for an existing username.  But that's not what the
> code does currently.  Obviously, the code could be changed to act
> differently in this case.

agree, same serious as bad password.

> Blacklistd did not originally have any message types, other than
> "login successful" and "login failed" for each address.
> The "login successful" messages cleared all failed login attempts
> for a given address.  The "login failed" messages added one to the
> count of failed logins for an address. If the count was over the
> limit for that service (aka port), an attempt to insert rule(s)
> into the packet filter to block that address.
> I've added the "abusive behavior" message type, so an application
> can signal blacklisted that they want the remote address blocked
> immediately. The only thing that sends that is the patches to
> sendmail that I have been testing.  (Not even the patches in the
> /usr/ports do it yet, as that capability didn't exist when I wrote
> that set of patches.) The sshd daemon (currently) never sends
> "abusive behavior" messages.
> The "bad username" message (again, not yet implemented in the backend),
> is intended to allow the administrator to configure a list of
> bad usernames.  If usernames on this list are flagged from an
> application, the remote address is should be blocked immediately.
> I've struggled a bit in terms of the design for this -- the list of
> usernames cannot be tied to password file entries - obviously
> one might like to have "pi" on the list of forbidden names, even
> though no account exists.  I've also torn about the right way
> to link up the blacklist rules with the name of the list of
> bad usernames to check against.
> While I imagine more admins would like to have a single list of
> bad usernames, and use that one list for smtp, sshd and whatever
> else, others might want to have different lists for one or more
> services.

I don't fully understand the reason to design different policy for bad
username than bad password.
To my knowledge there could be 3 kinds of bad login attempts: bad username,
bad password and bad authentication method (this one only for sshd?).

Forget username and try several times is acceptable, same as other 2 kinds
of attempts.
And if tried too many times, it should be blocked as attack. Also same as
other 2 kinds of attempts.

I would like to see blacklistd only managing bad attempts no matter which
kind of attempt it is.

> I really should implement *something* and just accept that it will
> be flawed and need refinement.
> -Kurt

with kind regards

More information about the freebsd-questions mailing list