Page MenuHomeFreeBSD

extend blacklist support with new action types

Authored by lidl on May 4 2017, 9:25 PM.



The original blacklist library supported two operations - a notification of a failed auth attempt, and a notification of a successful auth attempt.

This patch implements a third option - notification of abusive behavior, and accepts, but does not
act on a forth type - "bad username". It is envisioned that a system administrator will configure a small list of "known bad usernames" that should be blocked immediately.

Diff Detail

rS FreeBSD src repository
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

lidl created this revision.May 4 2017, 9:25 PM
wblock added a subscriber: wblock.May 5 2017, 4:10 PM
wblock added inline comments.
30 ↗(On Diff #28039)

Bump .Dd for this update.

91 ↗(On Diff #28039)
parameter can take these values:
94 ↗(On Diff #28039)


94 ↗(On Diff #28039)

These sentences all start with "Signal", but that is implied from the context. Might make sense to leave out the "Signal that" and just define the values. For example:

There was an unsuccessful authentication attempt.
A user has successfully authenticated.
106 ↗(On Diff #28039)

s/is matched/matches/
Or maybe "is detected". Just not sure about "is matched".

127 ↗(On Diff #28039)

Rearranging this makes it a bit more solid:

By default,
.Fn syslog
is used for message logging.
The internal
.Fn bl_create
can be used to create the internal state and specify
a custom logging function.
lidl updated this revision to Diff 28074.May 5 2017, 5:44 PM

Updated man page changes according to review comments.

lidl marked 6 inline comments as done.May 5 2017, 5:45 PM
emaste edited edge metadata.May 15 2017, 3:44 PM
  • what is the state of this work in NetBSD?
  • are AUTH_FAIL and BAD_USER not effectively the same result, just with/without the username?

The BLACKLIST_BAD_USER and BLACKLIST_ABUSIVE_BEHAVIOR actions are original work by me. I sent these patches to Christos and his only comment was that it looked useful and he wanted documentation changes. So I documented the new actions in the manpage.

As for the difference between the BAD_USER and AUTH_FAIL:

With AUTH_FAIL, the username is acceptable to the system, and the password is not. This adds one to the count of failed logins for that IP address, and when the configured limit of failed logins is reached, the remote address is blocked.

The BAD_USER support allows an administrator to configure a list of never acceptable usernames (eg. "admin", "support", "ubnt") and then if any of those usernames are flagged via the BAD_USER notification, the remote address can be blocked immediately. It's a mechanism for the administrator to short-circuit the number of attempts that a remote site will have when operating with popular scripts, probing for weak/default usernames.

emaste accepted this revision.May 22 2017, 3:10 AM

the difference between the BAD_USER and AUTH_FAIL...

What I mean is that the list of unacceptable usernames is maintained within blacklistd, not the individual application, and the same effect could be achieved with a single notification that a login attempt for user user failed (with the username optional)? I don't object to the approach here (and so will 'accept' the review), I just wonder if it's possible to simplify slightly.

This revision is now accepted and ready to land.May 22 2017, 3:10 AM
This revision was automatically updated to reflect the committed changes.
ngie added a subscriber: ngie.May 23 2017, 7:40 PM

Please add tests [for new support].