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/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D243164 --- 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=3D1 fd=3D6 remote=3D192.168.134.1:61909 msg=3Dssh uid=3D22 gid=3D22 Jan 8 06:06:57 latitude blacklistd[14144]: listening socket: 192.168.134.3= :22 Jan 8 06:06:57 latitude blacklistd[14144]: look:=20=20=20=20=20=20 target:192.168.134.3:22, proto:6, family:2, uid:22, name:=3D, nfail:*, dura= tion:* 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:=20=20=20=20 target:192.168.134.3:22, proto:6, family:2, uid:22, name:=3D, nfail:*, dura= tion:* 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:=20=20=20=20=20 target:192.168.134.99:22, proto:*, family:*, uid:*, name:=3D, nfail:*, dura= tion:* Jan 8 06:06:57 latitude blacklistd[14144]: conf_amask_eq: a1: c0a88601 != =3D 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 NetBS= D. What I still don't understand however is why the netmask can be FSTAR at al= l? What is the point? I can't follow the semantics. Why would we want to compa= re an incoming IP address (with implied /32 mask) to a template with an "unkno= wn" netmask? I suspect a proper fix might involve setting it to 32 (or 128 in t= he IPv6 case) right away if no mask is specified? --=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-7sF4O7lLQD>