blacklistd: what does it detect?

[Norman Gray]

Greetings (again).

On 23 Apr 2020, at 11:24, Norman Gray wrote:

> On 20 Apr 2020, at 12:43, Norman Gray wrote:
>
>
>> I've enabled blacklistd on a 12.1 machine accessible to the open 
>> internet, but it's not blocking as many failed ssh attempts as I 
>> expect.  Am I misunderstanding something?
>
>
> Is there documentation anywhere (outside of the source) of how 
> blacklistd and sshd interact?
>
> There seems to be very little correlation between what I find in 
> auth.log and what blacklistd is acting on, as reported by 
> blacklistctl.  Addresses seem to be blocked which barely appear in the 
> log, and not blocked after making multiple appearances in one message 
> or another.

I received an off-list pointer to <https://youtu.be/fuuf8G28mjs> (thank 
you!), which is a YouTube video of a good 2015 talk by the blacklistd 
developer, Christos Zoulas, talking about the design of the daemon.

There's nothing here which isn't, really, in the other documentation in 
the FreeBSD manual and the various manpages, but it provides a very 
useful overview of the approach and goals, which has given me, at least, 
a much clearer idea of what blacklistd is and isn't doing.

Basically:

   * blacklistd-supporting daemons, such as the sshd in FreeBSD, tell 
the blacklistd daemon 'consider blocking this IP' or 'this IP is OK', on 
the basis of some criterion compiled into that daemon (ie, there's 
nothing to configure here)
   * any other logging the (eg) sshd daemon does is for human 
information only, and may or may not straightforwardly correspond to 
what it said to the blacklistd daemon.

Thus...

> My immediate goal is to cut down noise in the 'daily security run' 
> log, and if that's chattering about connection attempts that 
> sshd/blacklistd think aren't worth acting on, then I'm going to feel 
> tempted to start fiddling with /etc/periodic/security/800.loginfail 
> (which would probably be a bad idea).

...if blacklistd is up and running, then there seems to be a case for 
omitting at least some reporting of login failures.  How I do that in a 
neat and maintainable way is of course a separate question.

Best wishes,

Norman


-- 
Norman Gray  :  http://www.astro.gla.ac.uk/users/norman/it/
Research IT Coordinator
SUPA School of Physics and Astronomy, University of Glasgow, UK
Charity number SC004401