Lighttpd

BTW, using lighttpd mod_accesslog today, you can already log the "Authorization" request header along with the IP address of client and HTTP status code of the response. If you use HTTP Digest auth and log the Authentication header, then a simple post-processing could determine whether or not the request was sent with an Authentication header and a nonce. Similarly, you could log the "WWW-Authenticate" header and look for stale=true.

Here's an untested sample patch against the HEAD of my development which prints the IP address of failed HTTP Digest attempts in the case of 401 Unauthorized response, except if Authorization header is not provided or if the nonce is stale. (In the next version of lighttpd, some interfaces may be changing, but you should get the picture and can change log_error() to log_error_write() along with some arguments)

diff --git a/src/mod_auth.c b/src/mod_auth.c
index cf4754d0..221621a1 100644
--- a/src/mod_auth.c
+++ b/src/mod_auth.c
@@ -976,7 +976,7 @@ static handler_t mod_auth_check_digest(connection *con, void *p_d, const struct
        }

        if (NULL == vb) {
-               return mod_auth_send_401_unauthorized_digest(con, require, 0);
+               return mod_auth_send_401_unauthorized_digest(con, require, -1);
        }

        if (!buffer_eq_icase_ssn(vb->ptr, CONST_STR_LEN("Digest "))) {
@@ -1187,6 +1187,10 @@ static handler_t mod_auth_check_digest(connection *con, void *p_d, const struct

 static handler_t mod_auth_send_401_unauthorized_digest(connection *con, const struct http_auth_require_t *require, int nonce_stale) {
        buffer * const tb = con->srv->tmp_buf;
+       if (0 == nonce_stale)
+               log_error(con->conf.errh, __FILE__, __LINE__,
+                 "digest: auth failed (IP: %s)", con->dst_addr_buf->ptr);
+       if (nonce_stale < 0) nonce_stale = 0; /*(no Authorization request header)*/
        mod_auth_digest_www_authenticate(tb, log_epoch_secs, require, nonce_stale);
        http_header_response_set(con, HTTP_HEADER_OTHER, CONST_STR_LEN("WWW-Authenticate"), CONST_BUF_LEN(tb));

Given the simplicity of the above, which should be easy to plug into fail2ban (possibly with slight modification to the error message), I do not see much benefit to any further work on the patch proposed by Mr. Wozniak. In the future, please consider opening a discussion in the lighttpd Development forum before posting to the issue tracker. Thank you.

What are the goals of the patch? What is it actually trying to do or protect against?

Rationale: Why not use existing solutions such as fail2ban?
fail2ban works by inspecting a log acquired from the relevant service. However, lighttpd does not emit the relevant information in the log. A digest authentication request can be rejected due to a missing/stale nonce or due to an actual authentication failure. The relevant log entry does not distinguish these situations.

Why did the patch not focus on adding such desired information to enable use of fail2ban? mod_accesslog.c can log the 401 HTTP status. If additional pieces of information are required in the log, then I might consider a patch where mod_auth adds those pieces of information to the request environment, which can be logged in mod_accesslog.

.

Still awaiting feedback here. I may soon mark this issue invalid and suggest a discussion in the forums instead.

Thank you for looking into the feature request and the patch.

I somehow missed the forum as the appropriate communication medium for RFC patches and will use it next time. Should we move the discussion there and close this ticket or continue here?

You asked about the goals of the patch and you observed that it is trivially DoSable. That is correct. In our application DoS is considered unprotectable. The patch defends against password brute force however and thus makes unauthorized access harder at the cost of making DoS simpler. That can be a reasonable trade-off. In the particular environment we are targeting, ip spoofing needs to be considered, so making the blocks by ip address would have been a trivial circumvention technique. Nevertheless, I see that limiting such blocks per ip would be useful for others.

You asked about why we did not focus on improving the integration with fail2ban. Compared to lighttpd, fail2ban is quite heavy in resource consumption and thus unsuitable for our application. We'd have to reimplement a stripped down version of fail2ban.
Plugging this functionality into lighttpd seemed like the easiest option to us and the size of the patch indicates that our expectation was reasonable.

When submitting it, I was aware that it was solving a niche use-case and I was kinda expecting you to reject it as is. I did see two benefits from submitting it anyway:
1. Document the use case and why it could make sense to have lighttpd support it.
2. Make a simple solution available for others.

Given that you seem to fundamentally disagree with adding brute force defense to lighttpd itself (as opposed to enabling brute force defense in another layer such as fail2ban), I suggest closig the ticket as invalid. Thank you for considering it anyway and presenting your reasons.

@helmut: I believe that your statement about fail2ban is incorrect.

Rationale: Why not use existing solutions such as fail2ban?
fail2ban works by inspecting a log acquired from the relevant service. However, lighttpd does not emit the relevant information in the log. A digest authentication request can be rejected due to a missing/stale nonce or due to an actual authentication failure. The relevant log entry does not distinguish these situations.

I took a look at fail2ban filter config/filter.d/lighttpd-auth.conf and it (correctly) picks up only the IP for password comparison failure for Basic and Digest, not other failures. It does not flag missing or stale nonce. lighttpd does emit relevant information in the error log for this to work. Please detail why you think this is not the case.

When submitting it, I was aware that it was solving a niche use-case and I was kinda expecting you to reject it as is. I did see two benefits from submitting it anyway:
1. Document the use case and why it could make sense to have lighttpd support it.
2. Make a simple solution available for others.

BTW, another limiting assumption of Mr. Wozniak's patch is that it assumes no valid account. Given a valid account, even with Mr. Wozniak's patch, it is possible to brute-force attack another account (e.g. 'admin') simply by periodically logging in with the valid account in order to reset counters in Mr. Wozniak's patch.

==> The patch is so limited in its niche-use case that I strongly recommend against anybody using it, including you.

Further discussion in https://redmine.lighttpd.net/boards/3/topics/8885

I stand corrected. I was looking at the access log, but the error log contains everything that is needed for fail2ban to work correctly.