From owner-freebsd-questions@freebsd.org Thu Nov 16 21:03:26 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B645DE921A for ; Thu, 16 Nov 2017 21:03:26 +0000 (UTC) (envelope-from rosettas@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DC1446A522; Thu, 16 Nov 2017 21:03:25 +0000 (UTC) (envelope-from rosettas@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id y80so2771000wmd.0; Thu, 16 Nov 2017 13:03:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=p6tzpLfRtFTJ5+FHhiCAV/ZhvjehDukIkzPuuA4Mu5c=; b=BC2EGrbySKeU6z18gaou902/ProMDF4rIMQAVjOnF8E4EgP6ZzoPNrrg461HRGfGNO 3bFfN5geUat4W07eNxdZ/SLMcihhwlxZCQLYOGaCVl5FI+UlTmhBAZhR/fhooJOgvzk/ YAS49ozWKNch61cEQ7szPVgZ8wrmICoTyuId110UjHYA1Tgv605K+zUYOqVsRQZ265FE TJGmlH2Y4+193ukSzVma02EsLOYjckw9/OcChjDz4WHW76DCRrFJVK7irWU7dYmMseLE fgFfMxhDrf9FKzsK/NcYpdLSTTWZRNnIJoRSWFszIS1tfeQoOQ4Ranfsw3/i5E1a6Peg PpxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=p6tzpLfRtFTJ5+FHhiCAV/ZhvjehDukIkzPuuA4Mu5c=; b=t3t90usqDuWfp8y993GG7LXZgSZWlEp+IbrB/H7ZmukBy0Xzuu2IJ1Ea8hLvmMufrD 1nV0eAnJjoTiIaIuPmS53sVZEqzBzK9SDedQ1duabq0fM6L9xWxCr/YUQ/ZQxcZfn1oq w+7Cxayj6r2y+KIKli1lCqiUhdzEFwuGgR9Pvgh2QTaFvncE56Cgh0x6azwKiK12HZ6a y/8Qyxl+rfaoAXWB4U6oojGiDOPwYBSpwieR/uztC+68Sz0E+dLCc6cAPzcWL+8v3mXo Twyc3d1g6ue85jDQ4Mh6hBiQ53G3BXUoP0F/iZ9rEwSaDGy9D2Ht8baop3JLRniOOuSn QS5A== X-Gm-Message-State: AJaThX4jWVVZS/xh6Zio47bsoTzuUWH7O6H0hRinvYEBAQZqKveMDNnI Vyhp+GrHaXnEFaVZO/jbGGy6SKxwKw4TE45p2G8KC883 X-Google-Smtp-Source: AGs4zMYERyK9hzIbk1egKx3+e9gf1c62TiRk5/GgWVcAL14HWAE2tLSfmA/CxHLCJNjFm/sNRK7EV9BDykijib0Nkyw= X-Received: by 10.28.57.11 with SMTP id g11mr2266778wma.92.1510866203697; Thu, 16 Nov 2017 13:03:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.125.8 with HTTP; Thu, 16 Nov 2017 13:03:22 -0800 (PST) In-Reply-To: <5bfc5ffc-dc78-78e5-4bb8-a166db2027b5@FreeBSD.org> References: <20171106235944.U9710@sola.nimnet.asn.au> <20171107033226.M9710@sola.nimnet.asn.au> <20171107162914.G9710@sola.nimnet.asn.au> <20171108012948.A9710@sola.nimnet.asn.au> <20171111213759.I72828@sola.nimnet.asn.au> <20171115185528.V72828@sola.nimnet.asn.au> <5bfc5ffc-dc78-78e5-4bb8-a166db2027b5@FreeBSD.org> From: Cos Chan Date: Thu, 16 Nov 2017 22:03:22 +0100 Message-ID: Subject: Re: How to setup IPFW working with blacklistd To: Kurt Lidl Cc: Ian Smith , freebsd-questions , Michael Ross Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 21:03:26 -0000 On Thu, Nov 16, 2017 at 3:57 PM, Kurt Lidl wrote: > On 11/16/17 2:27 AM, Cos Chan wrote: > > In that case I test sshd MaxAuthTries=1 and blacklistd nfail=1 and still >> get wired entry. >> >> $ sudo blacklistctl dump >> address/ma:port id nfail last access >> 57.83.1.58/32:22 0/1 1970/01/01 >> 01:00:00 >> >> $ sudo cat auth.log | grep 57.83.1.58 >> Nov 16 07:04:17 res sshd[31112]: Invalid user pi from 57.83.1.58 >> Nov 16 07:04:17 res sshd[31113]: Invalid user pi from 57.83.1.58 >> Nov 16 07:04:17 res sshd[31112]: Connection closed by 57.83.1.58 port >> 51140 [preauth] >> Nov 16 07:04:17 res sshd[31113]: Connection closed by 57.83.1.58 port >> 51144 [preauth] >> >> $ cat blacklistd-helper.log | grep 'Nov 16' >> ... >> Thu Nov 16 07:01:28 CET 2017 /usr/libexec/blacklistd-helper run add >> blacklistd tcp 120.237.88.186 32 22 >> Thu Nov 16 07:14:05 CET 2017 /usr/libexec/blacklistd-helper run add >> blacklistd tcp 139.59.111.224 32 22 >> >> No action from blacklistd-helper? how could that entry be added to >> database? >> >> no logs concerning from blacklistd either >> >> $ cat blacklistd.log | grep 'Nov 16' >> ... >> Nov 16 07:01:28 res blacklistd[23916]: blocked 120.237.88.186/32:22 < >> http://120.237.88.186/32:22> for -1 seconds >> Nov 16 07:14:05 res blacklistd[23916]: blocked 139.59.111.224/32:22 < >> http://139.59.111.224/32:22> for -1 seconds >> > > Pre-auth failures from sshd, where the username isn't found ("Invalid user > pi"), don't count against failed login attempts, because no > authorization was ever attempted by sshd. > > I made the decision not to count these against the limit in blacklistd. > I am curious why not. In my opinion the text in blacklistd man page is quite good and clear: "The nfail field contains the number of failed attempts before access is blocked" In my opinion the bad username attempts are exactly same as bad password attempts, all of them are failed attempts. > > There is a message sent from sshd to blacklistd when this occurs (bad > username), but this is the part that isn't implemented in the backend, > for banning addresses that hit known-bad usernames. > > I suppose the case could be made that a bad username is just as serious > as a bad password for an existing username. But that's not what the > code does currently. Obviously, the code could be changed to act > differently in this case. > agree, same serious as bad password. > > Blacklistd did not originally have any message types, other than > "login successful" and "login failed" for each address. > The "login successful" messages cleared all failed login attempts > for a given address. The "login failed" messages added one to the > count of failed logins for an address. If the count was over the > limit for that service (aka port), an attempt to insert rule(s) > into the packet filter to block that address. > > I've added the "abusive behavior" message type, so an application > can signal blacklisted that they want the remote address blocked > immediately. The only thing that sends that is the patches to > sendmail that I have been testing. (Not even the patches in the > /usr/ports do it yet, as that capability didn't exist when I wrote > that set of patches.) The sshd daemon (currently) never sends > "abusive behavior" messages. > > The "bad username" message (again, not yet implemented in the backend), > is intended to allow the administrator to configure a list of > bad usernames. If usernames on this list are flagged from an > application, the remote address is should be blocked immediately. > > I've struggled a bit in terms of the design for this -- the list of > usernames cannot be tied to password file entries - obviously > one might like to have "pi" on the list of forbidden names, even > though no account exists. I've also torn about the right way > to link up the blacklist rules with the name of the list of > bad usernames to check against. > > While I imagine more admins would like to have a single list of > bad usernames, and use that one list for smtp, sshd and whatever > else, others might want to have different lists for one or more > services. > I don't fully understand the reason to design different policy for bad username than bad password. To my knowledge there could be 3 kinds of bad login attempts: bad username, bad password and bad authentication method (this one only for sshd?). Forget username and try several times is acceptable, same as other 2 kinds of attempts. And if tried too many times, it should be blocked as attack. Also same as other 2 kinds of attempts. I would like to see blacklistd only managing bad attempts no matter which kind of attempt it is. > > I really should implement *something* and just accept that it will > be flawed and need refinement. > > -Kurt > -- with kind regards