https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243164
Bug ID: 243164
Summary: blacklistd not handling masks correctly
Product: Base System
Version: 12.1-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: bin
Assignee: b...@freebsd.org
Reporter: free...@oldach.net
I am afraid the blacklist.conf syntax and description might be a bit
misleading. According to the manpage, an IP address may be specified without
mentioning an explicit mask. The usual assumption obvioulsy being that lack of
a mask spec represents a host address: 192.168.134.99 would be identical to
192.168.134.99/32.
It appears that blacklistd behaves differntly. For the sake of the exercise
consider the following trivial (and complete) /etc/blacklistd.conf:
# adr/mask:port type proto owner name nfail disable
[local]
ssh stream * * * 3 3m
# adr/mask:port type proto owner name nfail disable
[remote]
192.168.134.99:ssh * * * = * *
Basically meaning, ssh would be blocked for 3 minutes after 3 unsuccessful
attempts - except when ssh originates at 192.168.134.99, which will always
succeed even if invalid.
Now, I'm not connecting from that host but from 192.168.134.1. When connecting
with an invalid user, access is *NOT* blocked after 3 unsuccessful attempts.
Indeed the debug log shows a successful match:
Jan 7 18:12:08 latitude blacklistd[1565]: processing type=2 fd=6
remote=192.168.134.1:61329 msg=ssh uid=0 gid=0
Jan 7 18:12:08 latitude blacklistd[1565]: listening socket: 192.168.134.3:22
Jan 7 18:12:08 latitude blacklistd[1565]: look:
target:192.168.134.3:22, proto:6, family:2, uid:0, name:=, nfail:*, duration:*
Jan 7 18:12:08 latitude blacklistd[1565]: check: target:22, proto:6,
family:*, uid:*, name:*, nfail:3, duration:180
Jan 7 18:12:08 latitude blacklistd[1565]: found: target:22, proto:6,
family:*, uid:*, name:*, nfail:3, duration:180
Jan 7 18:12:08 latitude blacklistd[1565]: conf_apply: merge: target:22,
proto:6, family:*, uid:*, name:*, nfail:3, duration:180
Jan 7 18:12:08 latitude blacklistd[1565]: conf_apply: to:
target:192.168.134.3:22, proto:6, family:2, uid:0, name:=, nfail:*, duration:*
Jan 7 18:12:08 latitude blacklistd[1565]: conf_apply: result:
target:192.168.134.3:22, proto:6, family:2, uid:*, name:*, nfail:3,
duration:180
Jan 7 18:12:08 latitude blacklistd[1565]: Applied address 192.168.134.1:22
Jan 7 18:12:08 latitude blacklistd[1565]: check:
target:192.168.134.99:22, proto:*, family:*, uid:*, name:=, nfail:*, duration:*
Jan 7 18:12:08 latitude blacklistd[1565]: found:
target:192.168.134.99:22, proto:*, family:*, uid:*, name:=, nfail:*, duration:*
Jan 7 18:12:08 latitude blacklistd[1565]: conf_merge: merge:
target:192.168.134.99:22, proto:*, family:*, uid:*, name:=, nfail:*, duration:*
Jan 7 18:12:08 latitude blacklistd[1565]: conf_merge: to:
target:192.168.134.1:22, proto:6, family:2, uid:*, name:*, nfail:3,
duration:180
Jan 7 18:12:08 latitude blacklistd[1565]: conf_merge: result:
target:192.168.134.1:22, proto:6, family:2, uid:*, name:*, nfail:*, duration:*
Jan 7 18:12:08 latitude blacklistd[1565]: Applied address 192.168.134.1:22
Note there are *two* "found:" tokens in the log (one for the [local], and one
for the [remote] part) which states that our source address (192.168.134.1)
does match against 192.168.134.99. This is obviously incorrect.
Now, let's add a proper (host) network mask to /etc/blacklistd.conf
...
# adr/mask:port type proto owner name nfail disable
[remote]
192.168.134.99/32:ssh * * * = * *
In this case, access *IS* blocked after three unsucessful attempts. Indeed the
debug log reflects this (first attempt):
Jan 7 18:07:13 latitude blacklistd[1506]: processing type=2 fd=6
remote=192.168.134.1:61301 msg=ssh uid=0 gid=0
Jan 7 18:07:13 latitude blacklistd[1506]: listening socket: 192.168.134.3:22
Jan 7 18:07:13 latitude blacklistd[1506]: look:
target:192.168.134.3:22, proto:6, family:2, uid:0, name:=, nfail:*, duration:*
Jan 7 18:07:13 latitude blacklistd[1506]: check: target:22, proto:6,
family:*, uid:*, name:*, nfail:3, duration:180
Jan 7 18:07:13 latitude blacklistd[1506]: found: target:22, proto:6,
family:*, uid:*, name:*, nfail:3, duration:180
Jan 7 18:07:13 latitude blacklistd[1506]: conf_apply: merge: target:22,
proto:6, family:*, uid:*, name:*, nfail:3, duration:180
Jan 7 18:07:13 latitude blacklistd[1506]: conf_apply: to:
target:192.168.134.3:22, proto:6, family:2, uid:0, name:=, nfail:*, duration:*
Jan 7 18:07:13 latitude blacklistd[1506]: conf_apply: result:
target:192.168.134.3:22, proto:6, family:2, uid:*, name:*, nfail:3,
duration:180
Jan 7 18:07:13 latitude blacklistd[1506]: Applied address 192.168.134.1:22
Jan 7 18:07:13 latitude blacklistd[1506]: check:
target:192.168.134.99/32:22, proto:*, family:*, uid:*, name:=, nfail:*,
duration:*
Jan 7 18:07:13 latitude blacklistd[1506]: conf_amask_eq: a1: c0a88601 != a2:
c0a88663 [0x20]
Jan 7 18:07:13 latitude blacklistd[1506]: Applied address 192.168.134.1:22
Note there is only a "found:" token against the [local] part of the
configuration file, but not against the [remote] part. Further the "check:"
line clearly states that the (hex) IP addresses 192.168.134.1 and
192.168.134.99 are not identical.
Documentation error or bug?
Note the blacklist.conf manpage contains an example without netmask, however
the description seemingly does not match behaviour:
# Never block 1.2.3.4
1.2.3.4:ssh * * * * * *
Also please not I have manually applied the review D22259 updates to my
12-STABLE machine. That does not change behaviour.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
