On 8/4/24 13:25, John Fawcett via dovecot wrote:
On 04/08/2024 13:17, Serhii via dovecot wrote:
I am trying to implement logging of all failed authentication attempts to catch
bruteforce automatically. Currently, I have the following configuration:
...
But for me it doesn't look like what is specified in docs[1]:
Field | Description
---
error | Set when error happens
success | yes, when authentication succeeded
policy_penalty | Time of penalty added by policy server
policy_result | Values: ok, delayed, refused
Why I don't see neither "success" and "error" field in logs? Also, why
policy_result is ok despite I am logging only failed authentication attempts? From postfix I can
see that those attempts were actually failed:
Hi Serhii
the way the code currently works is that "success: yes" is the only possible value. When the
authentication is not successful the "success" is not present. i.e. there is no "success:
no".
You're not seeing any "success" values since the code only produces "success:
yes" and you've filtered that out.
As to why you're not seeing any error, my suspicion is that it is
unintentional. If I am right about that then the following patch in the
function auth_request_fail_with_reply(...) could solve it. It now logs error:
authentication failed.
--- dovecot-2.3.21-orig/src/auth/auth-request.c 2023-09-14
15:17:46.000000000 +0200
+++ dovecot-2.3.21/src/auth/auth-request.c 2024-08-04 14:43:03.837000812
+0200
@@ -303,7 +303,7 @@
stats = auth_request_stats_get(request);
stats->auth_failure_count++;
}
-
+ request->failed = TRUE;
auth_request_set_state(request, AUTH_REQUEST_STATE_FINISHED);
auth_request_refresh_last_access(request);
auth_request_log_finished(request);
For my usecase it solves the problem, thank you!
So, with this patch I can see both cases when user was not found:
{
"event": "auth_request_finished",
"hostname": "cheems",
"start_time": "2024-08-10T07:20:02.159360Z",
"end_time": "2024-08-10T07:20:48.092606Z",
"categories": [
"service:auth",
"auth"
],
"fields": {
"duration": 45933175,
"error": "authentication failed",
"mechanism": "LOGIN",
"transport": "trusted",
"service": "smtp",
"local_ip": "2a01:4f8:231:76a::2",
"real_local_ip": "2a01:4f8:231:76a::2",
"remote_ip": "redacted",
"real_remote_ip": "redacted",
"original_user": "no-such-u...@example.com",
"user": ""
}
}
and when password is not correct:
{
"event": "auth_request_finished",
"hostname": "cheems",
"start_time": "2024-08-10T07:21:31.952608Z",
"end_time": "2024-08-10T07:21:47.588093Z",
"categories": [
"service:auth",
"auth"
],
"fields": {
"duration": 15635410,
"error": "authentication failed",
"policy_result": "ok",
"mechanism": "LOGIN",
"transport": "trusted",
"service": "smtp",
"local_ip": "2a01:4f8:231:76a::2",
"real_local_ip": "2a01:4f8:231:76a::2",
"remote_ip": "redacted",
"real_remote_ip": "redacted",
"original_user": "u...@example.com",
"user": "u...@example.com",
"translated_user": "u...@example.com"
}
}
Error message is not that descriptive, but it is way better than it was
originally.
The need for something like this also seems to be warranted by the fact that
internal failures on authentication only get reported by the event logging if
request->failed is set and I couldn't see anywhere that happens. With the above
patch these will also now be logged if there is a call to the function
auth_request_internal_failure(...)
I also think that the above patch may not deal with all the cases where there
is an internal failure in authentication, but those are a bit harder to test.
There may still be some cases where there is neither a success or error, and
those cases should still be treated as failures or subject to further patching.
John
--
Send unsolicited bulk mail to carl...@at.encryp.ch
_______________________________________________
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
