[Bug 270928] Blacklistd does not handle SSHD failed logins

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270928

            Bug ID: 270928
           Summary: Blacklistd does not handle SSHD failed logins
           Product: Base System
           Version: 13.1-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: bin
          Assignee: bugs@FreeBSD.org
          Reporter: bc979@lafn.org

Created attachment 241577
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=241577&action=edit
A patch to blacklistd to have BL_BADUSER handled as BL_ADD

Blacklistd with SSHD does not work properly.  To create the problem, configure
/etc/ssh/sshd.config to enable UseBlacklistd.  Then start Blacklistd.  Use ssh
from another system to login with an invalid id and password.  Try again. 
Blacklistd should have locked you out.  Check with "blacklistctl dump -a" 
There will not be any entries.  The problem is that sshd uses the type
BL_BADUSER when calling blacklistd.  The code in blacklistd.c says that this
type is "ignore for now".

The BL_BADUSER type was supposed to immediately block the IP on the first time
regardless of the configuration in /etc/blacklistd.conf.  However, at this time
it never does anything.  As a result the calling IP is never blocked.  The
simple solution is the attached patch.  However, after some consideration, I
believe that BL_BADUSER should always be handled as BL_ADD.  The purpose of the
configuration file is to give the system administrator control over when
callers are blocked.  By sshd using BL_BADUSER, the configuration in the config
file is never used.  That will certainly confuse the administrator and removes
control over blocking from the administrator to the programmer who develops the
code that calls blacklistd.

Having sshd block the IP after the first invalid id or password is not a great
idea.  A simple fat fingered user will be blocked for 24 hours after the first
login attempt.  It is not uncommon for there to be typos in login attempts. 
That is a severe penalty for the user.  There is no way for the administrator
to remove the entry from blacklistd (presuming the user can actually contact
the administrator).  The administrator can only remove the IP address from the
pf blocking table.  That will "work" until something causes blacklistd to be
restarted.  On restart, blacklistd will reenable the block in pf.

I believe that blacklistd should not override the administrator's
configuration.

-- 
You are receiving this mail because:
You are the assignee for the bug.