Page MenuHomeFreeBSD

extend blacklist support with new action types
ClosedPublic

Authored by lidl on May 4 2017, 9:25 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Mar 27, 6:13 PM
Unknown Object (File)
Tue, Mar 19, 4:25 AM
Unknown Object (File)
Tue, Mar 19, 2:50 AM
Unknown Object (File)
Feb 22 2024, 5:19 AM
Unknown Object (File)
Feb 2 2024, 5:03 PM
Unknown Object (File)
Jan 15 2024, 9:30 PM
Unknown Object (File)
Dec 27 2023, 1:43 PM
Unknown Object (File)
Dec 22 2023, 10:16 PM
Subscribers

Details

Summary

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

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

wblock added inline comments.
contrib/blacklist/lib/libblacklist.3
30 ↗(On Diff #28039)

Bump .Dd for this update.

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

s/successful/unsuccessful/
s/authenticatation/authentication/

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.

Updated man page changes according to review comments.

  • 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.

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.

Please add tests [for new support].