NethServer Version: 8
Module: crowdsec
At the cli both dovecot bf are listed and show enabled but they’re not showing up in the control panel even with a new private browsing session 12 odd hours after install. I have not rebooted the server but I have restart crowdsec both at the cli and the control panel button.
IIRC we list collections and you have enabled a scenarios so it might be the clue why it is not listed
please show us the command line you have used
scenarios list
“… cscli collections list” does not list melite or ltsich’s wootwoot, which are listed in scenarios
collections !== scenarios
a collection is a bundle of parsers (how to grep) and scenarios (what to do once grep)
in short the collections page cannot list scenarios nor parsers
Seems like if we’re showing anything enabled in the gui we should be showing everything that’s enabled,
well we should need to create two pages more like the collections
collections
--------------
parsers
--------------
scenarios
or maybe one web page with three tabs
collections | parsers | scenarios
What do you think @giacomo
cc @fasttech
We try not to expose everything in the UI. In fact, the more options we expose, the more chances we give users to configure something incorrectly.
What should happen when you disable the parsers for a collection? The collection remains enabled, but without parsers it does nothing. Likewise, if the collection and its parsers are enabled but the parsers themselves are disabled, nothing happens.
From my point of view, when we present collections in the UI, the collection should be the responsibility boundary: you enable or disable a collection, and that’s it.
We should avoid a situation where a collection looks enabled while its parsers are disabled, because it gives the user the feeling that they are protected when they actually aren’t.
Ok. Let me come at it this way.
I checked a few detections, they were scenarios. It looks like almost everything in Blocklists and Detections are scenarios. You cannot find a single one of them in Collections, so … down the rabbit hole you go to figure out where your detection falls in the scheme of things. Let’s say you have a detection of a scenario that you don’t want triggered, you delete the scenario at the shell because you don’t want to disable the collection of scenarios?
Also, why is the nextcloud scenario tainted, what did you folks change about the scenario?
I agree with Steph: let’s keep the UI simple.
you delete the scenario at the shell because you don’t want to disable the collection of scenarios?
You can just disable the collection.
Otherwise from command line you can do all the tweaks but then you should not configure it from the UI anymore.
If fine tuning of CrowSec is common request, we can also think to expose something more in the UI. But for now I’d leave it simple.
We need to ban based on the logs we found and also adjust the service name IIRC. I also often have to add whitelists for bad plugins that trigger bans against legitimate users, so Nextcloud is not really a great tool here , you have to trick it a bit.
I just wanted to add something, @fasttech. I think Melite scenario is probably the only corner case we should add to CrowdSec by default. I already use it personally and asked @davidep to add it to CrowdSec, but we are concerned about banning innocent users.
I suggest you monitor the custom scenario for a while and then come back with your feedback.
Appreciate the heads up @stephdl I am in CS daily, I’ve been building my own Cloudflare ish db of subnets of aggressive probers and blocking at the fw to cut traffic to my stuff, so far I haven’t seen triggers for melite’s scenarios and that may be a case more that I’ve blocked most of the infra used for aggressive probing without losing legit traffic. I got tired of seeing 300 hits in 4 secs from google assigned blocks with 8 CS triggers before it’s stopped, MS is almost as bad but my db is pretty large now so the load’s off my servers finally.
So there’ll be a collection update that will include the dovecot bf scenarios?
I still think admins should be able to see anything enabled in the gui though, it just doesn’t seem to make sense to only have a partial view.
I secretly hope we’ll see this enabled in CrowdSec one day.
melite/dovecot-slow-bf ✔️ enabled 0.1 /etc/crowdsec/scenarios/dovecot-slow-bf.yaml
melite/dovecot-time-based-bf ✔️ enabled 0.1 /etc/crowdsec/scenarios/dovecot-time-based-bf.yaml
It’s simply about doing more with the official parser: kicking people who deliberately slow down authentication against your server.