greenpau / caddy-security

πŸ” Authentication, Authorization, and Accounting (AAA) App and Plugin for Caddy v2. πŸ’Ž Implements Form-Based, Basic, Local, LDAP, OpenID Connect, OAuth 2.0 (Github, Google, Facebook, Okta, etc.), SAML Authentication. MFA/2FA with App Authenticators and Yubico. πŸ’Ž Authorization with JWT/PASETO tokens. πŸ”
https://authcrunch.com/
Apache License 2.0
1.49k stars 73 forks source link

question: Suppressing noisy auth failure logs #280

Open mechanarchy opened 1 year ago

mechanarchy commented 1 year ago

My Caddy logs are filled with the following errors:

{"level":"error","ts":1696284844.5546117,"logger":"http.handlers.authentication","msg":"auth provider returned error","provider":"authorizer","error":"user authorization failed: src_ip=192.168.1.242, src_conn_ip=192.168.1.242, reason: keystore: failed to parse token"}
{"level":"error","ts":1696284849.554045,"logger":"http.handlers.authentication","msg":"auth provider returned error","provider":"authorizer","error":"user authorization failed: src_ip=192.168.1.242, src_conn_ip=192.168.1.242, reason: keystore: failed to parse token"}
{"level":"error","ts":1696284854.5622492,"logger":"http.handlers.authentication","msg":"auth provider returned error","provider":"authorizer","error":"user authorization failed: src_ip=192.168.1.242, src_conn_ip=192.168.1.242, reason: keystore: failed to parse token"}
{"level":"error","ts":1696284859.5597315,"logger":"http.handlers.authentication","msg":"auth provider returned error","provider":"authorizer","error":"user authorization failed: src_ip=192.168.1.242, src_conn_ip=192.168.1.242, reason: keystore: failed to parse token"}

and

{"level":"error","ts":1696250599.3767776,"logger":"http.handlers.authentication","msg":"auth provider returned error","provider":"authorizer","error":"user authorization failed: src_ip=192.168.1.1, src_conn_ip=192.168.1.1, reason: no token found"}
{"level":"error","ts":1696250611.9230247,"logger":"http.handlers.authentication","msg":"auth provider returned error","provider":"authorizer","error":"user authorization failed: src_ip=192.168.1.1, src_conn_ip=192.168.1.1, reason: no token found"}
{"level":"error","ts":1696251438.8547764,"logger":"http.handlers.authentication","msg":"auth provider returned error","provider":"authorizer","error":"user authorization failed: src_ip=192.168.1.1, src_conn_ip=192.168.1.1, reason: no token found"}

Combined, these two messages make up 68% of my Caddy log:

$ docker logs caddy 2>&1 | wc -l
223383
$ docker logs caddy 2>&1 | grep "failed to parse token" | wc -l
94432
$ docker logs caddy 2>&1 | grep "reason: no token found" | wc -l
58633

I presume this is because I am not persisting the token encryption keys in my install, and a Caddy restart changes the encryption key but the client cache sessions are not updated.

Is there any way I can suppress these noisy log messages? Caddy has the skip_log directive, but I'm not sure of the matcher to use for Caddy Security.

mechanarchy commented 11 months ago

Hi @greenpau , are you able to provide any insight here?

greenpau commented 11 months ago

@mechanarchy , I don’t know the best way to handle this. Never used skip_logs directive.

greenpau commented 11 months ago

@mechanarchy , perhaps it is a good feature to implement.

All logging that happens in the plugin are done via zap.Logger. There is probably a way to intercept a log message, match conditions and drop it.

greenpau commented 11 months ago

the directive for this might look something like this.

security {
   logging skip partial msg "auth provider returned error"
}

or skips of any of them match.

security {
   logging skip partial msg "auth provider returned error"
   logging skip partial error "reason: no token found"
}

or skips if both are the match

security {
   logging skip {
     partial msg "auth provider returned error"
     partial error "reason: no token found"
  }
}
mechanarchy commented 11 months ago

@greenpau Thanks for your time looking into this. The caddy skip_log directive only works on matchers, which after further thought, is unlikely to cooperate with these unbounded/matcher-less auth logs.

Something like your suggestion here would be very helpful! I don't anticipate this would be high on your priority list, and I'm not familiar with Go to attempt a PR myself, so for the meantime I will continue to just ignore the additional logging, or filter it out (grep -v) where required.