How to setup IPFW working with blacklistd

Kurt Lidl lidl at
Thu Nov 16 14:57:40 UTC 2017

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.

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.

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

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


More information about the freebsd-questions mailing list