From owner-freebsd-bugs@freebsd.org Tue Jan 7 17:52:41 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 AAF2E1EE280 for ; Tue, 7 Jan 2020 17:52:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 47sg2K44GVz4Ppl for ; Tue, 7 Jan 2020 17:52:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 8B8D91EE27E; Tue, 7 Jan 2020 17:52:41 +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 8B0041EE27D for ; Tue, 7 Jan 2020 17:52:41 +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 47sg2K1dn9z4Ppk for ; Tue, 7 Jan 2020 17:52:41 +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 33A722AF2 for ; Tue, 7 Jan 2020 17:52:41 +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 007Hqfa3023639 for ; Tue, 7 Jan 2020 17:52:41 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 007HqfBP023638 for bugs@FreeBSD.org; Tue, 7 Jan 2020 17:52:41 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: Tue, 07 Jan 2020 17:52:41 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new 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: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: 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: Tue, 07 Jan 2020 17:52:41 -0000 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.=