Date: Thu, 16 Nov 2017 09:57:31 -0500 From: Kurt Lidl <lidl@FreeBSD.org> To: Cos Chan <rosettas@gmail.com>, Ian Smith <smithi@nimnet.asn.au> Cc: freebsd-questions <freebsd-questions@freebsd.org>, Michael Ross <gmx@ross.cx> Subject: Re: How to setup IPFW working with blacklistd Message-ID: <5bfc5ffc-dc78-78e5-4bb8-a166db2027b5@FreeBSD.org> In-Reply-To: <CAKV%2BxLCB-ZkU0XNv9COa3p=xXAf3TutLZ=BwhQeu4KTxR1gupw@mail.gmail.com> References: <mailman.87.1509969603.28633.freebsd-questions@freebsd.org> <20171106235944.U9710@sola.nimnet.asn.au> <CAKV%2BxLCizjt5M%2BmJmTZj-cr=D6rhXRwDjCkE=6Q-VQX73iY%2B4A@mail.gmail.com> <20171107033226.M9710@sola.nimnet.asn.au> <CAKV%2BxLBWgU6zmc7tQNA=0%2B=2aF23C1QfJ2i3q1gKYDttwsCTkg@mail.gmail.com> <20171107162914.G9710@sola.nimnet.asn.au> <CAKV%2BxLDQQcG3bvo1b2nUAu7oOVhdNzDDrPWTVp2qOmkWVV89BQ@mail.gmail.com> <20171108012948.A9710@sola.nimnet.asn.au> <CAKV%2BxLCQ9NE6%2BEg6NvHZuEED8Cf6ZX74unvk9ajfLyG-yA2rXA@mail.gmail.com> <CAKV%2BxLAkfiQCLXfgZOtQGUXOW8gYN7sjOD5uWezv-N%2BTBjybMQ@mail.gmail.com> <20171111213759.I72828@sola.nimnet.asn.au> <CAKV%2BxLDicLze3Dvd2i7HGWJUxCdSLjvhuWWZUJ65pMi%2Bx483=A@mail.gmail.com> <20171115185528.V72828@sola.nimnet.asn.au> <CAKV%2BxLC=ABe2i3TN8bo4XaVg3KfUbKsS96=6iyVDnsmWw-e8ag@mail.gmail.com> <CAKV%2BxLCB-ZkU0XNv9COa3p=xXAf3TutLZ=BwhQeu4KTxR1gupw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <http://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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5bfc5ffc-dc78-78e5-4bb8-a166db2027b5>