Error ::1 has been banned

Sorry @joergM for my late response.

This is not a bug, this is how this is supposed to be working. It tells us (a) that your local environment works with IPv6 and (b) that something is creating too many 4xx requests to the site, which is recognized as malicious behaviour and the IP therefore gets banned for a period of time.

You can turn off the "whisper" monitoring in the crowdsec settings, if you don't bother about such behaviour. However, it is a pretty good feature to keep such requests away from your website, e.g. if somebody is testing all those /wp-* paths.

Good practice seems to be, to only use the crowdsec module in production and not in local development environments, because there it is fairly expected that you get 4xx requests. Or you could use the config_split module and with that keep crowdsec enabled but disable the whisper module locally.

@joergM what's the status on this?

I think this is generally valid that non-public addresses should not be included in the business logic of this module.
We needed to solve it for the sake of our automated tests.
And I am sure crowdsec must be enabled during the tests. If ever it would cause a crash somewhere, the test suite of the site must be aware of that.
Will provide a MR soon.

If the MR is in good direction, we can extend it to handle IPv6, loopback and so on.

Of course we can make it configurable.

Thanks @aron novak for your contribution. However, I'm not in favour of such exceptions. If the whisper feature should not be used in either development or test environments, then use $config['crowdsec.settings']['whisper']['enable'] = 0; in the settings.php of that environment. That will do the same thing: 4xx requests will not be banned, and in those environments you won't receive external requests anyway, so there's no point in having that whisper handling enabled there.

Specifically to the question of local IP addresses, that's nowadays very hard to determine. From the regex in the MR I can tell at least 2 issues: 10.x addresses are also used as public addresses by some IPs since the IPv4 shortage and Docker environments are also using 169.x address ranges. But that's only 2 examples where this would fail. We should assume that there are so many more.

But it's not only hard to determine private address ranges, it's also not necessary if you turn off whispering where it's not required.

aron novak → closed merge request !5

I agree that `$config['crowdsec.settings']['whisper']['enable'] = 0;` should be fine in these cases.
There was one robustness improvement in the MR that's still valuable, I'll propose that separately.
Going to set back the status where it was originally.

I had the chance to think about it more.
For the sake of as realistic integration test as possible, we'd still prefer to have all parts of Crowdsec enabled, like on LIVE.

(Any non-trivial software can and will cause surprises. An example: https://github.com/sirbrillig/phpcs-variable-analysis/issues/340 - a widely used and trusted package suddenly broke our CI.)

What if we introduce a "dry mode"? It's like doing really everything, except that it does not use Ban module to block the IPs, but for instance the logger to say it would ban that IP for X amount of time in non-dry mode. How does this sound?

@aron novak you're right that pipelines should be identical to the live system, that's our philosophy as well. And yet, we're looking to behave differently. With the dry-mode, the question remains where you draw the line. Doing everything except the ban is almost exactly the same as disabling the whisper handling. You can see that in \Drupal\crowdsec\Buffer::addWhisperSignal where the actual ban happens 10 lines later than the decision to return because of the disabled whisper. All the lines in-between are pure variable collection. And it should be the responsibility of this module to make sure that those work correctly. The live site tests should not rely on them, do they?