Only ban if the response is non 2##?

[AnderssonPeter]

Wouldn't it make more sense if the ban would trigger based on all requests that aren't http 200-299?

Then we could set a much lower limit and thus lowering the number of attempts a hacker has before banning them.

(If i read the code correctly it just count's the number of requests)

[AnderssonPeter]

After looking at the API it doesn't look like this is possible right now.

[tomMoulard]

I don't think that this plugin should differentiate its behavior between status codes. The goal of this plugin is to intercept bad requests coming, as bad requests could be 2XX status codes, filtering them out of the f2b algorithm may be problematic.

[AnderssonPeter]

From what I can se its not possible with the current middleware api? But I still think that it's more logical to block requests that cause a lot of 401 and 403 or at least being able to set a lower limit when it comes to those 2 (But as its not possible in the current API its fine with me if you close this)

[ImranR98]

I think this would be useful, that way we can block attempts to brute-force login screens (like basic auth) without accidentally banning legitimate (but frequent) requests.

[AnderssonPeter]

I'll think this can actually be done, can't remember what plugin did it but there is some way to intercept the response before it's sent to the client.

That would allow the plugin to read the http status code.

Edit: found one example here https://github.com/traefik/plugin-rewritebody/blob/082c42bffdd33b8d6351ef7146d48b56012838f9/rewritebody.go#LL68C5-L68C5

[tomMoulard]

The issue is not on whether this could be done, it is whether this should be done.

Following @ImranR98 message,

I think this would be useful, that way we can block attempts to brute-force login screens (like basic auth) without accidentally banning legitimate (but frequent) requests.

An over-engineered plugin could do the F2B mechanism with different settings on different status code. This would lead to a config looking like this:

apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: my-fail2ban
  namespace: my-namespace
spec:
  plugin:
    fail2ban:
      rules:
        - statusCode: 400-500
          fail2ban:
            # f2b config here
            ... 

But This would require a huge breaking change in the configuration.

A first step in this direction could be to have this plugin work only on a specified status code range, and have multiple instances of this plugin with multiple configuration for all the use cases.

This means that we could add a statusCode config that when filled would filter the use of this plugin.

WDYT ?

[AnderssonPeter]

While I'm clearly biased for this change as I created the issue I think this would be great. But like you said I don't see any way to do this without causing a breaking change :(, but as long as you increase the major version number I don't see this as a issue.

[exhuma]

I discovered this plugin only recently. In the past I have already used the original fail2ban service on Linux machines. That service only consideres failures for the detection (bad login attempts e.t.c.). Hence the name "fail2ban" (too many failures lead to a ban). It's in their first line of the README:

Fail2Ban scans log files like /var/log/auth.log and bans IP addresses conducting too many failed login attempts.

The current name of the plugin is a misleading as it also includes successful requests.

It is likely unfeasible to implement the full configurability of the original fail2ban into this plugin (due to the complexity). But I would fully expect this traefik middleware to only consider failed requests for banning requests.

It is perfectly legitimate for an authenticated client to an API behind traefik to execute hundreds of requests per minute (without being banned). But if you see, let's say, 50 requests leading to a 401 or 404 from the same IP within even 10 minutes, something is fishy and should trigger a block.

I would be more careful about 403 responses though. They may still be legitimate.

I really think that this is a legitimate request, even if it breaks the config. It would make the plugin a lot more usable. I'm currently forced to increase the find-time and max-retries so much that I'm afraid that malicious requests fall through the net.

[AnderssonPeter]

I'm not 100% sure but https://github.com/safing/scanblock/tree/master seems to do what we need, but sadly it lacks any options to only bock certain types of requests, currently it counts all 4XX.

I also found https://github.com/juitde/traefik-plugin-fail2ban that seems to be in active development!

[dberardo-com]

i am definitely upvoting this. fail2ban is used in very different applications and it usually checks log files, as well as status code, etc. so this is definitely something the user would expect.

otherwise this would end up being only a rate-limiting plugin, wouldnt it ? like: https://plugins.traefik.io/plugins/63993c3dba1f6c0a1e5bfb88/rate-limit