Fail2ban Middleware does not recognise 200 status code #136
Comments
|
I had the same problem :( |
|
I think I'm seeing the same things myself. Is this plugin working? 🤔 |
|
Hello all, Thanks for your interest in this Traefik plugin ! I've released https://github.com/tomMoulard/fail2ban/releases/tag/v0.8.2 with an intensive logging approach. Can you try again your issue with the latest version and tell me if it's still relevant ? Thanks ! |
|
I'm immediately hit with an error when trying to load the latest version into Traefik:
experimental:
plugins:
GeoBlock:
moduleName: "github.com/PascalMinder/geoblock"
version: "v0.2.8"
fail2ban:
moduleName: "github.com/tomMoulard/fail2ban"
version: "v0.8.2" |
|
indeed, my bad, I've released https://github.com/tomMoulard/fail2ban/tree/v0.8.3 that should fix this particular panic issue. |
This new version loads fine, but doesn't log anything beyond the initial first message. The middleware configuration I've got is: http:
middlewares:
fail2ban:
plugin:
fail2ban:
logLevel: DEBUG
# allowlist:
# ip: 10.150.0.0/16
# denylist:
# ip: 192.168.0.0/24
rules:
bantime: 5m
enabled: true
findtime: 30s
maxretry: 5
statuscode: "400,401,403-499"And much like with the initial case described by @PS1TD, this version blocks connectivity after just opening a loading screen, as if 200s were 400s... |
|
Did you enable traefik DEBUG log level ? If so, have you the following log ? |
|
Good point. I failed to notice this bit from the documentation: After setting this I'm... well, I'm getting a bit overly swarmed with logs now. But I think I've managed to isolate a fragment of Note: I've removed all routing information from the logs as other services are being frequently accessed and add a lot of noise, and I've stripped a Like @PS1TD I'm not using any |
|
Hi, I just stumbled upon the same problem and think that the issue is here: Line 143 in 6b3824f The f2b-handler is called in the chain before the status-code-handler and thus fail2bans EVERY request (see also here: Line 84 in 6b3824f I think that |
|
Indeed I could try reversing the order in the chain but I doupt I will work as you intend. For you last part, removing the handler will remove it's ability to catch status codes. But indeed, it will count twice the request in the handler. |
|
The status-code handler internally calls the f2b if a proper status-code is detected. Why call the f2b-handler "naked" (without any preconditions) in the chain at all? It then counts every request against the "maxRetry", even "legal" ones with a 200 response-code. |
|
I'd think that inside the chain one would need a handler that continues blocking, if an IP is already on the ban-list, but that does not blindly increase ip.count towards maxRetries. Increasing the counter for an IP may only happen if a precondition for a "failed"-request is met (like inside the URLRegexBan or the http-status-handler). (I'm not able to write Go-code myself, otherwise I'd create a merge-request) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For some reason my setup does not recognize successful status codes and bans on the 11th request.
I also don't see anything in the logs even though I have enabled DEBUG logging.
Setup:
The text was updated successfully, but these errors were encountered: