Date: Wed, 08 Jan 2020 05:26:13 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 243164] blacklistd not handling masks correctly Message-ID: <bug-243164-227-7sF4O7lLQD@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-243164-227@https.bugs.freebsd.org/bugzilla/> References: <bug-243164-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243164 --- Comment #6 from Helge Oldach <freebsd@oldach.net> --- (In reply to Conrad Meyer from comment #4) > Helge, does this fix the issue? Yes it does; we are now seeing a mismatch in case the source and [remote] addresses are different: Jan 8 06:06:57 latitude blacklistd[14144]: processing type=1 fd=6 remote=192.168.134.1:61909 msg=ssh uid=22 gid=22 Jan 8 06:06:57 latitude blacklistd[14144]: listening socket: 192.168.134.3:22 Jan 8 06:06:57 latitude blacklistd[14144]: look: target:192.168.134.3:22, proto:6, family:2, uid:22, name:=, nfail:*, duration:* Jan 8 06:06:57 latitude blacklistd[14144]: check: target:22, proto:6, family:*, uid:*, name:*, nfail:3, duration:180 Jan 8 06:06:57 latitude blacklistd[14144]: found: target:22, proto:6, family:*, uid:*, name:*, nfail:3, duration:180 Jan 8 06:06:57 latitude blacklistd[14144]: conf_apply: merge: target:22, proto:6, family:*, uid:*, name:*, nfail:3, duration:180 Jan 8 06:06:57 latitude blacklistd[14144]: conf_apply: to: target:192.168.134.3:22, proto:6, family:2, uid:22, name:=, nfail:*, duration:* Jan 8 06:06:57 latitude blacklistd[14144]: conf_apply: result: target:192.168.134.3:22, proto:6, family:2, uid:*, name:*, nfail:3, duration:180 Jan 8 06:06:57 latitude blacklistd[14144]: Applied address 192.168.134.1:22 Jan 8 06:06:57 latitude blacklistd[14144]: check: target:192.168.134.99:22, proto:*, family:*, uid:*, name:=, nfail:*, duration:* Jan 8 06:06:57 latitude blacklistd[14144]: conf_amask_eq: a1: c0a88601 != a2: c0a88663 [0xffffffff] Jan 8 06:06:57 latitude blacklistd[14144]: Applied address 192.168.134.1:22 I followed the logic of your patch, it appears OK to me. So it's not a documentation error as I was thinking but indeed a bug. While not being a security issue as such, it's kind of scary, as it might leave ports open unnecessary. Also this should probably be backported upstream to NetBSD. What I still don't understand however is why the netmask can be FSTAR at all? What is the point? I can't follow the semantics. Why would we want to compare an incoming IP address (with implied /32 mask) to a template with an "unknown" netmask? I suspect a proper fix might involve setting it to 32 (or 128 in the IPv6 case) right away if no mask is specified? -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-243164-227-7sF4O7lLQD>