From owner-freebsd-bugs@freebsd.org Wed Jan 8 05:26:13 2020 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 587D21FC445 for ; Wed, 8 Jan 2020 05:26:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 47syQY1mclz45lX for ; Wed, 8 Jan 2020 05:26:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 3AB5C1FC444; Wed, 8 Jan 2020 05:26:13 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3A7991FC443 for ; Wed, 8 Jan 2020 05:26:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47syQY0n9Kz45lV for ; Wed, 8 Jan 2020 05:26:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 1190DAF14 for ; Wed, 8 Jan 2020 05:26:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 0085QC2h077290 for ; Wed, 8 Jan 2020 05:26:12 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 0085QCCp077289 for bugs@FreeBSD.org; Wed, 8 Jan 2020 05:26:12 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 243164] blacklistd not handling masks correctly Date: Wed, 08 Jan 2020 05:26:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 12.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: freebsd@oldach.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 05:26:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D243164 --- Comment #6 from Helge Oldach --- (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.=