How constant are the logformats?

[electrofloat]

Describe your question/ So I'm setting up fail2ban for authentik, and since authentik uses a json-like logformat I'm wondering how stable/constant are those logs?

Fail2ban works with regexes ( and I'm also redirecting all the authentik logs to syslog), so I can only match for example a failed login with something like this: failregex = ^%(__prefix_line)s.*login_failed.*"client_ip":\s+"<HOST>" Now this could be way more strict, but I'm afraid that since it is json like, the keys could just be in random order. The above regex asssumes that the login_failed word always appears before client_ip key.

So the question is:

• Can I depend on the order of the keys-values in that json format?
• Can I depend on the overall logformat of authentik? (meaning if I'm creating regexes for failures - not just login ones - the logformat won't be ever changing, or at the very least it will be mentioned in the changelog?

Thanks.

[BeryJu]

The keys should always be in the same order (see https://github.com/goauthentik/authentik/blob/5c8f024d121d8b80fa83b2519a1f36df5fb253cc/authentik/root/settings.py#L411)

The log format won't change unless there's reason (besides new fields potentially being added which might break the regex)

However since you're relying on the logs of events created, you can also create custom logs, by creating a Notification Rule, creating a policy that checks for the event and then prints something custom that can be matched easier (Similar to https://beryju.io/blog/2022-05-authentik-vault/)

[electrofloat]

Thanks.

As long as if and when the log format changes (even if a new filed is added and it will be sorted in a different way) there's a notice in the changelog, this is fine.

For the Notification Rule, that could work for failed logins, but I'm still evaluating the logs to find other usecases for fail2ban. (like for example clicking too many times on resend mail, or accessing the api without authentication, etc.)

[ArjonBu]

Did you come up with a fail2ban jail? If yes, can you please share?

[ngthwi]

I would be great if someone could share a solution.

[mrskizzex]

Got it to work. First you have to configure authentik_server container with logging to journald.

    logging:
      driver: journald

Then I used following filters in fail2ban:

authentik-geo-block.local

[INCLUDES]
before = common.conf

[Definition]

failregex = ^.*?policy_execution.*?"client_ip": "<HOST>".*?ip-geoblock.*?"passing": false.*$

ignoreregex =

authentik-reputation.local

[INCLUDES]
before = common.conf

[Definition]

failregex = ^.*?policy_execution.*?"client_ip": "<HOST>".*?ip-reputation.*?"passing": false.*$

ignoreregex =

authentik-login.local

[INCLUDES]
before = common.conf

[Definition]

failregex = ^.*?login_failed.*?"client_ip": "<HOST>".*$
            ^.*?invalid_identifier.*?"client_ip": "<HOST>".*$

ignoreregex =

Jails: authentik.local

[authentik-login]
backend = systemd
enabled  = true
filter   = authentik-login
maxretry = 3
journalmatch = CONTAINER_NAME=authentik_server

[authentik-geo-block]
backend = systemd
enabled  = true
filter   = authentik-geo-block
maxretry = 1
journalmatch = CONTAINER_NAME=authentik_server

[authentik-reputation]
backend = systemd
enabled  = true
filter   = authentik-reputation
maxretry = 1
journalmatch = CONTAINER_NAME=authentik_server

Login filters don't require any special setup on authentik side but ip-geoblock and ip-reputation do. ip-geoblock expression policy: name has to contain "ip-geoblock" Execution logging < set this to true

if ak_client_ip.is_private:
    result = True
else:
    result = context["geoip"].country.iso_code in ['XX', 'XX']
return result

ip-reputation reputation policy: name has to contain "ip-reputation" Execution logging < set this to true Check IP < set this to true Threshold < set this to -3

This setup results in fail2ban banning 3 attempts at login either with bad password or just bad username and also instantly bans someone whose reputation is lower than -3 or country IP doesn't match what i've set in the expression policy.