f



blacklistd and sshd?

I'm just starting to play with FreeBSD 11.  I see it has a new 
blacklistd daemon which provides a function similar to fail2ban, 
blocking ports that are the source of repeated failed login attempts.

I'm trying to use it, but it doesn't seem to be doing anything.  
Available doc is limited, but it implies that daemons like sshd can 
communicate with it.  It seems logical that I might have to change 
something in sshd config to enable this support, but I haven't found 
anything in sshd doc that tells how to do that.  Is sshd smart enough 
to detect that blacklistd is running and automagically use it?  Or is 
there some (undocumented?) option I need to set to make it happen?

0
Matt
12/18/2016 3:18:11 PM
comp.unix.bsd.freebsd.misc 13187 articles. 1 followers. Post Follow

1 Replies
637 Views

Similar Articles

[PageSpeed] 48

> I'm just starting to play with FreeBSD 11.  I see it has a new 
> blacklistd daemon which provides a function similar to fail2ban, 
> blocking ports that are the source of repeated failed login attempts.
> 
> I'm trying to use it, but it doesn't seem to be doing anything.  
> Available doc is limited, but it implies that daemons like sshd can 
> communicate with it.  It seems logical that I might have to change 
> something in sshd config to enable this support, but I haven't found 
> anything in sshd doc that tells how to do that.  Is sshd smart enough 
> to detect that blacklistd is running and automagically use it?  Or is 
> there some (undocumented?) option I need to set to make it happen?


I haven't gotten much beyond the "play with it" stage with blacklistd.

You need to set up blacklistd.conf for it to actually *DO* (that
is, block) anything.  You might, however, be able to see failed
login attempts with blacklistctl even if there are no directives
to block anything for excessive failed login attempts.  I hope so.
You need to run for a few days to see what would block without
actually blocking to see if you forgot to exempt something
important.

I made the assumption that any executable that reports to blacklistd
will link with a library that has "blacklist" in its name.  So I
ran a script that runs objdump over every executable on the system
it can find looking for such library dependencies.  (This script
has proved useful for finding executables from ports which somehow
managed to link in two different versions of the same library, or
to see what executables are using old library versions and need
relinking).  It found:

	/usr/libexec/fingerd
	/usr/libexec/ftpd
	/usr/libexec/rlogind
	/usr/libexec/rshd
	/usr/sbin/blacklistctl
	/usr/sbin/blacklistd

Note lack of references to sshd and sendmail.  Looking through the
source, I see references to a blacklist for sendmail but this seems
to be references to DNS-based blacklists, not blacklistd.  I do see
a file ssh.diff in /usr/src/contrib/blacklist/diff which you
might have to apply yourself (to what version?).

I would like to see blacklistd integrated with exim.  I may not
have to change any source code:  the configuration file can call
helper programs which call libblacklist.so.0 under appropriate
conditions (e.g. right before it's going to accept or reject a piece
of mail, based, say, on a spamassassin score).

I also see conditionals as to whether the blacklist functionality
will be compiled in, but at a quick glance it seems to default on.

I have to wonder about an approach based on ports.  If I see naughty
port scanning or failed ssh login attempts, I want to block them
from *ALL* of the ports, not just the ones they were abusing.

As near as I can tell, the users of libblacklist.so.0 report
information to blacklistd (unidirectional data flow).  If the program
is configured to use libblacklistd and it's not running, blacklist_open()
will fail, and the program can just not bother calling the reporting
functions.  Or, the library functions can just check for the "cookie"
value returned from blacklist_open() being NULL, and return
immediately.  Or, a shell script or program can test for the socket
(e.g. /var/run/blacklistd.sock, or whatever) existing.

There is lots of room for special utilities that effectively "tail
-f" log files, look for reports of something naughty, and report
it to blacklistd (I'm thinking particularly of kernel reports of
attempts to connect to a closed port).  That might not react
immediately, but it saves you from having to write and run daemons
that listen on odd ports commonly used by botnets and viruses just
to report them.

I once tried something like a crude version of blacklistd, triggered
by incoming email SPAM, but the number of rules generated to block
by IP quickly generated complaints about table overflows from the
kernel.  ipfw has improved a lot since then.

0
gordonb
12/20/2016 5:18:05 AM
Reply: