From owner-freebsd-questions@freebsd.org Thu Nov 16 14:57:40 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 3A633DE01B1 for ; Thu, 16 Nov 2017 14:57:40 +0000 (UTC) (envelope-from lidl@FreeBSD.org) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F0BF07DA9C for ; Thu, 16 Nov 2017 14:57:39 +0000 (UTC) (envelope-from lidl@FreeBSD.org) Received: from torb.pix.net ([IPv6:2001:470:e254:11:ac3b:829b:fc19:b4dc]) (authenticated bits=0) by hydra.pix.net (8.15.2/8.15.2) with ESMTPA id vAGEvVAR073774; Thu, 16 Nov 2017 09:57:38 -0500 (EST) (envelope-from lidl@FreeBSD.org) X-Authentication-Warning: hydra.pix.net: Host [IPv6:2001:470:e254:11:ac3b:829b:fc19:b4dc] claimed to be torb.pix.net Reply-To: lidl@FreeBSD.org Subject: Re: How to setup IPFW working with blacklistd To: Cos Chan , Ian Smith Cc: freebsd-questions , Michael Ross 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> From: Kurt Lidl Message-ID: <5bfc5ffc-dc78-78e5-4bb8-a166db2027b5@FreeBSD.org> Date: Thu, 16 Nov 2017 09:57:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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 14:57:40 -0000 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 > for -1 seconds > Nov 16 07:14:05 res blacklistd[23916]: blocked 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. 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. 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 really should implement *something* and just accept that it will be flawed and need refinement. -Kurt