From nobody Tue Apr 18 06:05:21 2023 X-Original-To: questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q0th00X8Zz45nmk for ; Tue, 18 Apr 2023 06:05:36 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from mail.sermon-archive.info (sermon-archive.info [47.181.130.121]) by mx1.freebsd.org (Postfix) with ESMTP id 4Q0tgy5flDz49Kq for ; Tue, 18 Apr 2023 06:05:34 +0000 (UTC) (envelope-from bc979@lafn.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of bc979@lafn.org designates 47.181.130.121 as permitted sender) smtp.mailfrom=bc979@lafn.org; dmarc=none Received: from smtpclient.apple (mini [10.0.1.251]) by mail.sermon-archive.info (Postfix) with ESMTPSA id 4Q0tgv6d1Xz2fjx2 for ; Mon, 17 Apr 2023 23:05:31 -0700 (PDT) From: Doug Hardie Content-Type: multipart/alternative; boundary="Apple-Mail=_AD600E8F-ED7D-4073-86DF-9275C4AD4955" List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: Blacklistd Issues - Problem Identified Date: Mon, 17 Apr 2023 23:05:21 -0700 References: <8B1C1DCE-75CA-4CE9-A589-329519FB792E@sermon-archive.info> <4E4A4B99-D8DF-4C5C-9700-C56F354A9991@sermon-archive.info> To: questions@freebsd.org In-Reply-To: <4E4A4B99-D8DF-4C5C-9700-C56F354A9991@sermon-archive.info> Message-Id: <24171551-4181-49C8-B1DE-2C3D9A00DC4C@sermon-archive.info> X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Virus-Scanned: clamav-milter 1.0.1 at mail X-Virus-Status: Clean X-Spamd-Result: default: False [-2.68 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.98)[-0.981]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[questions@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_DKIM_NA(0.00)[]; DMARC_NA(0.00)[lafn.org: no valid DMARC record]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:5650, ipnet:47.181.128.0/18, country:US]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[questions@freebsd.org]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4Q0tgy5flDz49Kq X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_AD600E8F-ED7D-4073-86DF-9275C4AD4955 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii -- Doug > On Apr 17, 2023, at 16:42, Doug Hardie wrote: >=20 > After digging through the code for blacklistd I find that postfix and = my web server call blacklistd with a type of 1 (BL_ADD) and sure enough, = blacklistd calls the helper to add the pf rule. However. sshd calls = with type 4 (BL_BADUSER) and there is a note in the handling of that = type that says "Ignore for now". And that it does, i.e., nothing. So = the problem is in sshd using a type that is not implemented, or in = backlistd which does not implement the BADUSER type. I wonder if = Release 13.2 will fix either of those. >=20 The following patch is a temporary fix for the problem: --- blacklistd.c.orig 2023-04-17 22:58:47.552759000 -0700 +++ blacklistd.c 2023-04-17 22:46:32.069666000 -0700 @@ -225,6 +225,7 @@ if (c.c_nfail !=3D -1) dbi.count =3D c.c_nfail - 1; /*FALLTHROUGH*/ + case BL_BADUSER: case BL_ADD: dbi.count++; dbi.last =3D ts.tv_sec; @@ -260,9 +261,9 @@ dbi.count =3D 0; dbi.last =3D 0; break; - case BL_BADUSER: - /* ignore for now */ - break; +// case BL_BADUSER: +// /* ignore for now */ +// break; default: (*lfun)(LOG_ERR, "unknown message %d", bi->bi_type);=20 } Basically the BADUSER call from sshd is moved to the ADD function. So = instead of what was supposed to be an immediate shutdown on one bad = authentication regardless of the conf settings, it now follows the = config settings rule. I am not convinced that sshd should use the = BADUSER call. It causes a single typo to lock you out. It seems to me = that it should use the ADD function so the admin gets to chose the = proper number of bad authentications before lockout. I'd submit a PR on this, but all the PRs I have submitted have been left = to wither on the vine. -- Doug --Apple-Mail=_AD600E8F-ED7D-4073-86DF-9275C4AD4955 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
-- Doug

On Apr 17, 2023, at 16:42, Doug = Hardie <bc979@lafn.org> wrote:

After digging through the = code for blacklistd I find that postfix and my web server call = blacklistd with a type of 1 (BL_ADD) and sure enough, blacklistd calls = the helper to add the pf rule.  However. sshd calls with type 4 = (BL_BADUSER) and there is a note in the handling of that type that says = "Ignore for now".  And that it does, i.e., nothing.  So the = problem is in sshd using a type that is not implemented, or in backlistd = which does not implement the BADUSER type.  I wonder if Release = 13.2 will fix either of = those.


The following = patch is a temporary fix for the = problem:

--- blacklistd.c.orig = 2023-04-17 22:58:47.552759000 -0700
+++ = blacklistd.c = 2023-04-17 22:46:32.069666000 -0700
@@ -225,6 +225,7 = @@
  if (c.c_nfail !=3D = -1)
  dbi.count =3D = c.c_nfail - 1;
  = /*FALLTHROUGH*/
+ case = BL_BADUSER:
  case = BL_ADD:
  = dbi.count++;
  dbi.last =3D = ts.tv_sec;
@@ -260,9 +261,9 @@
  = dbi.count =3D 0;
  dbi.last =3D = 0;
  break;
- case = BL_BADUSER:
- /* ignore for now = */
- = break;
+// case = BL_BADUSER:
+// /* ignore for now = */
+// = break;
  default:
  = (*lfun)(LOG_ERR, "unknown message %d", = bi->bi_type); 
  = }


Basically the BADUSER = call from sshd is moved to the ADD function.  So instead of what = was supposed to be an immediate shutdown on one bad authentication = regardless of the conf settings, it now follows the config settings = rule.  I am not convinced that sshd should use the BADUSER call. =  It causes a single typo to lock you out.  It seems to me that = it should use the ADD function so the admin gets to chose the proper = number of bad authentications before = lockout.

I'd submit a PR on this, but all the = PRs I have submitted have been left to wither on the = vine.

-- = Doug


= --Apple-Mail=_AD600E8F-ED7D-4073-86DF-9275C4AD4955--