Bug 247309 - blacklistd: spurious whitelisting IPv4
Summary: blacklistd: spurious whitelisting IPv4
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 12.0-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-16 15:46 UTC by Norman Gray
Modified: 2021-07-05 14:28 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Norman Gray 2020-06-16 15:46:01 UTC
blacklistd appears to whitelist entire netblocks after individual hosts are mentioned in [remote] stanzas in blacklistd.conf

I'm afraid I don't have the resources to do a detailed reduction/reproduction,
but I hope the notes below will be indicative.

What I expect from the configuration described below is that the hosts
listed in the [remote] stanza should be individually whitelisted, but that other nearby hosts should be covered by the [local] rules as usual (ie, not whitelisted).

The actual results are that a large number of hosts are apparently whitelisted (indicated by NNN/-1 in the blacklistctl output).  These appear to be in /16 or /8 netblocks associated with the whitelisted hosts.

My blacklistctl dump -a output currently looks a bit like this (IP addresses partially redacted):

            address/ma:port	id	nfail	last access
     130.209.XX.XX/32:22		0/-1	1970/01/01 01:00:00
     130.209.XX.XX/32:22		6/-1	2020/05/18 11:30:19
      194.XX.XX.XX/32:22		3/-1	2020/05/29 00:35:05
      194.XX.XX.XX/32:22		154/-1	2020/05/29 12:13:21
      [...]
          85.130.2.35/32:22		1/4	2020/05/29 10:28:30
      [...]

The 130.209 is the local /16.  The odd thing is the -1 as the nfail limit, meaning 'do not block' or 'whitelisted', which I can't explain.  That is, I see a number of lines that I expect, but a good number of nfail=-1 lines in these two netblocks 130.209.0.0/16 and 194.0.0.0/8.  I see no nfail=-1 lines outside these netblocks.

My blacklistd.conf looks like:

    [local]
    ssh		stream	*	*		*	4	24h
    ftp		stream	*	*		*	3	24h
    smtp		stream	*	*		*	3	24h
    submission	stream	*	*		*	3	24h
    *		*	*	*		*	3	60
    [remote]
    130.209.NN.NN:ssh *	*	*		*	*	*
    194.NN.NN.NN:ssh *	*	*		*	*	*
    130.209.MM.MM:ssh *	*	*		*	*	*

The [local] stanza is almost the default; the [remote] explicitly whitelists three machines.

But the whitelisted machines _do not_ match the nfail=-1 machines in the blacklistctl output.  They're in the same 130.209.0.0/16 and 194.0.0.0/8, but are not the same IP address.

It's as if the [remote] lines were being parsed as 130.209.0.0/16:ssh and 194.0.0.0/8:ssh, but there's nothing in the by-hand parser of the .conf file that suggests that's what's happening (see <https://github.com/freebsd/freebsd/blob/master/contrib/blacklist/bin/conf.c> lines 224 and 586, last changed March 2018).

Looking around, bug #243164 appears to be a different problem, but also possibly
to do with either the whitelisting logic or the parsing of the config file.  The discussion there also mentions the custom config file parser.

A little background:

The machine this is running on is hosting three jails (one of which is the bastion host that this is really protecting, and the blacklistd is listening on sockets in both the host and that bastion jail), it has four IP addresses (one host plus three jails, two of which are in the 172.16.0.0/12 private IP range), and it has a non-trivial, but not particularly complicated pf firewall configuration.

This is the blacklistd in FreeBSD 12.0-RELEASE-p8 (I can't find a version option on blacklistd nor any version strings in the blacklistd binary).

I posted a question about this on the net@freebsd list (https://lists.freebsd.org/pipermail/freebsd-net/2020-May/055920.html),
since I wondered if this was a documentation issue, and simply didn't understand
the config file format.
Comment 1 Helge Oldach 2021-01-29 08:39:18 UTC
Please check if the patch outlined in bug #243164 fixes your case.
Comment 2 Norman Gray 2021-07-05 14:28:25 UTC
Looking at this is on my to-do list, but not, I'm afraid, very high up it, since I/we would probably have to do a little bit of work to learn how to act on the suggestion.

Is that inactivity holding anything up?  If so, I can probably assign some work at this end.