Allowlist option

Thanks for reaching out. However, I'm not sure I can follow you on this. Do you mean that when bad requests are coming in that Drupal reports the IP address of your load balancer (i.e. the proxy) to CrowdSec? Don't think that's the case if the Drupal site is configured correctly. There are reverse proxy settings to be made which allow Drupal to see the real IP address of the user who's making the request, and then that IP address is reported to CrowdSec, not the one of your load balancer. Or am I missing something?

@jurgenhaas this happens to me as well. We could make a form to enter IPs individually (not ideal, but works) and/or make a button for administrators to exempt them from the ban.

@Kartagis which IPs do you want to put into such a list? As I mentioned in #2, the proxy addresses don't have to be configured there, because if the Drupal site is configured correctly in the first place, Drupal will know the correct IP of the client and ban that one instead of the proxy.

Many related modules have IP address whitelist entry features.
It is absolutely imperative that this module have an IP address whitelist management feature.
No drupal site builder wants to get IP banned from their own website while working on it.
-
When this module IP banned me, I was fortunately, able to quickly pop into my VPN (generating a fresh IP address) and was then able to remove the erroneous IP ban the drupal IP ban module list.

@jurgenhaas active user's IP could be there.

If anything, this would be called an allowlist. We don't want to use anything black and white.

The original post in this issue was about an issue with reverse proxy IP addresses, which must have been misconfigured; otherwise that wouldn't have happened.

The new use case brought up in #5 is about internal users who should be allowed to request invalid URLs. I can't follow that logic. If something like that happens unintentionally on a website to admins or editors, then something with that site is entirely wrong and should be fixed.

If this happens in a local or a test environment, then it's not recommended to have CrowdSec enabled there. This is a module to protect live sites. In other environments it should be disabled.

The terms - allow-list - and - ban-list - seem appropriate.

The original post was mine and at some point we did disable crowdsec because of limitations of our server structure.

Other than that I'm still not completely sure why we don't have an allowlist. Because a recent site I made is a remake of the same site. So it still has some invalide urls which are redirected from within drupal because of the structure and content changed quite a bit. So bookmarks or backlinks etc will hit these invalid pages. (regarding #5)

The admins of the new site are banned from time to time because of crowdsec. No reverse proxy this time :)

I presume invalid urls are our mistake but never the less it could be just user-error where some users on the same network try to enter a non-existing page thus get the ip address banned for the whole network.

@RgnYLDZ in that described scenario, an allow-list would help much. Maybe for some user's whose IP makes it to the list, but not for all the others.

For sites where 4xx responses are expected and acceptable, the Crowdsec module comes with the option to turn whisper protection off. You can find that setting in /admin/config/services/crowdsec. Or you can tailor the settings such that the chances for a ban are less likely.

I had planned to write a separate post, but having come across this one it seems useful to comment on it here.

I use the cPanel cron set up according to Drupal rules like this:

wget -O - -q -t 1 https://mysite.com/cron/<key>.

Today I find a information from Crowdsec:

Anonymous (not verified)
https://mysite.com/cron/<key>
Unexpected response status code: 401. Body was: @“message”: “Unauthorized” { 'type': “WATCHER_REQUEST_LOGIN_RETRY”, 'code': 401 }
IP address

It 's not an error message, and the site, although online, is not yet fully active, but I would not want to find myself then with 24 such messages a day and run the risk of finding the ip of the cPanel server banned
So perhaps a white/allow list might be useful for these and similar cases

My 2 cents

@senzaesclusiva If the site isn't ready yet, why enabling crowdsec in such an early stage? But if it's ready enough so that this module makes sense, then it should do its job and 4xx requests should be avoided by that stage. If even that isn't an option, just disable the 4xx whisper with 1 line in your settings.php:

$config['crowdsec.settings']['whisper.enable'] = FALSE;

Yes, I think it is important to start getting familiar with all features of this module before the site is fully accessible to all users.
I will temporarily implement your suggestion
Thank you very much