| Summary: | blacklistd: spurious whitelisting IPv4 | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Norman Gray <gray> |
| Component: | bin | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | New --- | ||
| Severity: | Affects Some People | CC: | emaste, freebsd, jlduran |
| Priority: | --- | ||
| Version: | 12.0-RELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
Please check if the patch outlined in bug #243164 fixes your case. 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. |
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.