Project

General

Profile

Actions

Feature #2943

closed

mod_auth log digest, log failed authentications

Added by TestudoAquatilis about 5 years ago. Updated about 5 years ago.

Status:
Invalid
Priority:
Low
Category:
mod_auth
Target version:
-
ASK QUESTIONS IN Forums:

Description

It would be good to log failed authentications with IP addresses for blocking attackers via fail2ban and similar tools.
Currently only failed passwords for correct users are logged but incorrect users are not (for digest mode at least).

I locally tried the following modification to mod_auth.c, which seems to work, but I am unsure whether I missed relevant cases and it only covers the digest mode.

diff -aur lighttpd-1.4.53.orig/src/mod_auth.c lighttpd-1.4.53.patched/src/mod_auth.c
--- lighttpd-1.4.53.orig/src/mod_auth.c 2019-01-27 10:22:20.000000000 +0100
+++ lighttpd-1.4.53.patched/src/mod_auth.c      2019-03-16 23:30:33.639536706 +0100
@@ -733,6 +733,9 @@
                return HANDLER_FINISHED;
        case HANDLER_ERROR:
        default:
+               log_error_write(srv, __FILE__, __LINE__, "sssB",
+                               "digest: auth failed for ", username, ", IP:", con->dst_addr_buf);
+
                buffer_free(b);
                return mod_auth_send_401_unauthorized_digest(srv, con, require->realm, 0);
        }
@@ -796,6 +799,9 @@

        /* value is our allow-rules */
        if (!http_auth_match_rules(require, username, NULL, NULL)) {
+               log_error_write(srv, __FILE__, __LINE__, "sssB",
+                               "digest: auth failed for ", username, ": no auth rule match, IP:", con->dst_addr_buf);
+
                buffer_free(b);
                return mod_auth_send_401_unauthorized_digest(srv, con, require->realm, 0);
        }

Actions #1

Updated by gstrauss about 5 years ago

  • Priority changed from Normal to Low
  • Target version deleted (1.4.54)

Your patch may produce voluminous error logs for yourself or others. If you're worried about invalid usernames today, then tomorrow someone may worry about something else.

You can use mod_accesslog to log IP address and 401 HTTP response code, along with the Authorization request header to determine types of failures. Generically speaking you should be interested in whether or not a 401 was returned when an Authorization header was provided (as opposed to without an Authorization header)

Another alternative is for you to write a FastCGI authorizer and handle the authorization yourself so that you can choose arbitrary metrics for rate limiting, tarpitting, blocking, or other.

Actions #2

Updated by TestudoAquatilis about 5 years ago

If this is generally not what you want, might it be possible to add it as a configurable feature?

Although I cannot say much about other use cases, at least for my one I would expect the typical harmless case to be a correct username with mistyped password, which already creates a log message. So the log-flood in a non-attack scenario would not increase much. If the current state is used for blocking, then it would be easy for an attacker to guess a valid user name by trying to get blocked in a first iteration with correct username and wrong password. You might see this as only a theoretical scenario, but I would feel a little bit uncomfortable with this.

As for the access-log: Unless there is some option I did not find, the first access to a restricted page already creates a 401, which would lead to many false positives for blocking as you cannot prevent the first 401.

In general, I see this as a feature worth thinking about. I know that the patch is of arguable quality - it was just my local experiment and if this is a useful feature there are many more authentication methods to consider, which I cannot test with my comparably simple setup.

Actions #3

Updated by gstrauss about 5 years ago

It would appear that you did not read my response carefully enough, and you are too focused on what you have deemed your specific need, than to heed the more general statement I made about security.

You might see this as only a theoretical scenario, but I would feel a little bit uncomfortable with this.

You obviously did not understand my more general statement about security.

Unless there is some option I did not find

You obviously did read what I wrote very carefully.

Please re-read my response more carefully and then, if you think that I have not addressed the points you tried to (re)make in your second post, then please post some follow-up questions.

Actions #4

Updated by TestudoAquatilis about 5 years ago

Ok - very sorry for the inconvenience - I just needed to learn to distinguish authentication header from response code - for me this was not obvious, but now I know.
Of course you are right, everything needed is already there, it joust needs to be configured according to ones needs.

But you might at least want to admit that even if my naive "patch"

may produce voluminous error logs

as it logs failed authentications due to invalid user names (instead of only due to invalid passwords) for every authentication failure, it might be hard to find some term for the logs generated by mod_accesslog. Unless I'm still too stupid to set it up properly (which might still be the case).

Even before I understood how to use it for failed authentication I thought it to be quite a flood of messages - but adding the authentication header blows it up by something like a factor of 3 or 4 and not only for failed authentications but also for every single valid access. For me this seemed rather to be some sort of debug log opposed to the error-log which I see as the productive log (although I might be wrong here as well - I don't know how others set this up in real use cases).

Don't get me wrong here: This is a great project and this was just meant as a suggestion of the form "might be useful" (to me it still seems so). But of course I accept your opinion here - this is your project and if this is something you do not want in there I definitely accept this - you already give me the possibility to use it and adapt it locally to my needs (although I only half know what I do here), which is great - so please do not see this as any complaint or offence, and sorry again that I did not get your point directly.

Actions #5

Updated by gstrauss about 5 years ago

  • Status changed from New to Invalid

As you now know, there are already multiple ways to achieve the feature you desire.

Sure, some people might find it useful if lighttpd were to log detailed debug info for different types of auth rejection (and not merely invalid passwords or invalid usernames). However, simply because it is not a bad idea does not mean that it is suddenly of critical value. There are many other more valuable places for developers to spend their time.

My recommendation is to use a mod_accesslog with piped logger which parses out the Authorization header, keeps statistics/takes actions, and then passes through the rest of the access log to be written to a file. It's not good security practice to write the Authorization header to disk if it contains unencrypted passwords, and if the utility of the Authorization header is short-lived, then for that reason, too, it would be better to parse it at generation time, and not write it to disk for later analysis. And just look at that: all the info you want, none of the log noise, no need for a new feature, no need to inconvenience others with log noise.

[Edit: "Authorization" request header]

Actions

Also available in: Atom