Date: Wed, 19 Apr 2023 05:41:51 UTC
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: firstname.lastname@example.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.