Date: Tue, 07 Jan 2020 17:52:41 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 243164] blacklistd not handling masks correctly Message-ID: <bug-243164-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D243164 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: bugs@FreeBSD.org Reporter: freebsd@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 * * * =3D * * 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 connect= ing 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=3D2 fd=3D6 remote=3D192.168.134.1:61329 msg=3Dssh uid=3D0 gid=3D0 Jan 7 18:12:08 latitude blacklistd[1565]: listening socket: 192.168.134.3:= 22 Jan 7 18:12:08 latitude blacklistd[1565]: look:=20=20=20=20=20=20=20 target:192.168.134.3:22, proto:6, family:2, uid:0, name:=3D, nfail:*, durat= ion:* 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:=20=20=20=20=20 target:192.168.134.3:22, proto:6, family:2, uid:0, name:=3D, nfail:*, durat= ion:* Jan 7 18:12:08 latitude blacklistd[1565]: conf_apply: result:=20 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:=20=20=20=20=20=20 target:192.168.134.99:22, proto:*, family:*, uid:*, name:=3D, nfail:*, dura= tion:* Jan 7 18:12:08 latitude blacklistd[1565]: found:=20=20=20=20=20=20 target:192.168.134.99:22, proto:*, family:*, uid:*, name:=3D, nfail:*, dura= tion:* Jan 7 18:12:08 latitude blacklistd[1565]: conf_merge: merge:=20=20 target:192.168.134.99:22, proto:*, family:*, uid:*, name:=3D, nfail:*, dura= tion:* Jan 7 18:12:08 latitude blacklistd[1565]: conf_merge: to:=20=20=20=20=20 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:=20 target:192.168.134.1:22, proto:6, family:2, uid:*, name:*, nfail:*, duratio= n:* 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 o= ne 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 * * * =3D * * 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=3D2 fd=3D6 remote=3D192.168.134.1:61301 msg=3Dssh uid=3D0 gid=3D0 Jan 7 18:07:13 latitude blacklistd[1506]: listening socket: 192.168.134.3:= 22 Jan 7 18:07:13 latitude blacklistd[1506]: look:=20=20=20=20=20=20=20 target:192.168.134.3:22, proto:6, family:2, uid:0, name:=3D, nfail:*, durat= ion:* 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:=20=20=20=20=20 target:192.168.134.3:22, proto:6, family:2, uid:0, name:=3D, nfail:*, durat= ion:* Jan 7 18:07:13 latitude blacklistd[1506]: conf_apply: result:=20 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:=20=20=20=20=20=20 target:192.168.134.99/32:22, proto:*, family:*, uid:*, name:=3D, nfail:*, duration:* Jan 7 18:07:13 latitude blacklistd[1506]: conf_amask_eq: a1: c0a88601 !=3D= 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-243164-227>