Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 31 Mar 2023 11:01:24 +0100
From:      Norman Gray <gray@nxg.name>
To:        questions@freebsd.org
Subject:   Understanding blacklistd blocklists -- 'bad user' doesn't get blocked
Message-ID:  <91FB3707-BE92-4B35-ACD6-08AB6E8735B5@nxg.name>

next in thread | raw e-mail | index | archive | help

Greetings.

I'm trying to understand why some connection attempts to sshd result in b=
lacklistd entries, and some don't.

Looking at sshd logs, on a machine connected to the open internet, I see =
a large number of errors such as

=2E..
Mar 30 20:49:18 <auth.info> haumea sshd[65830]: Invalid user nagios from =
42.225.207.234 port 41804
=2E..
Mar 30 21:32:28 <auth.info> haumea sshd[66203]: Invalid user administrato=
r from 194.55.224.179 port 60145
=2E..

The second one finds its way into the blacklist, but the first, like many=
 others, doesn't.  This surprises me.  As I write, "Mar 30 21:32:28" is c=
omfortably within the last 24 hours.

On investigation, the reason for this is that OpenSSH auth.c [1, around l=
ine 500] logs 'Invalid user...' as BLACKLIST_BAD_USER, which gets transla=
ted by blacklistd [2] into blacklistd's BL_BADUSER, which is handled in b=
lacklistd.c [3, line 257] as /* ignore for now */.

I think that the probes from 42.225.207.234 resulted in a block only beca=
use they appear to have tried to authenticate as root which (via BLACKLIS=
T_AUTH_FAIL) does increment the counter.

That BL_BADUSER notifications are ignored seems the opposite of what I'd =
expect, since someone hammering a login server with large numbers of spec=
ulative logins seems to be the very definition of abusive behaviour.  Doe=
s anyone know the rationale, here?

I suppose one possibility is that (a) if repeatedly connect as user 'foo'=
 and don't get blocked, but (b) I know that the site is using blacklistd,=
 then I can conclude that user 'foo' is valid.  But that seems an _extrem=
ely_ roundabout way of leaking information.

I see that in January last year, 'tanis' noted the same thing in the foru=
m [4], and remarked that a patched version of blacklistd.c, which increme=
nted the wickedness count for such users, didn't cause any surprising pro=
blems.  Is there a case for having BL_BADUSER optionally/configurably inc=
rement the wickedness counter?

Best wishes,

Norman

[1] https://github.com/freebsd/freebsd-src/blob/main/crypto/openssh/auth.=
c
[2] https://github.com/freebsd/freebsd-src/blob/main/contrib/blacklist/li=
b/blacklist.c
[3] https://github.com/freebsd/freebsd-src/blob/main/contrib/blacklist/bi=
n/blacklistd.c
[4] https://forums.freebsd.org/threads/blacklistd-and-sshd-not-acting-imm=
ediately-according-to-logs.82523/


-- =

Norman Gray  :  https://nxg.me.uk



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?91FB3707-BE92-4B35-ACD6-08AB6E8735B5>