How to avoid getting alerts for IPs on subscribed blocklists?

Here is my setup:

I receive e-mail alerts for IPs getting banned by crowdsec, for various scenarios. But, when I use CTI with these IPs, most of them are part of the “CrowdSec Community Blocklist”.

I understand that my bouncer returns an HTTP 403 to requests coming from banned IPs (and I can see them in its logs). And that these log lines are parsed by crowdsec agents, and can trigger a scenario.

I probably would not have this issue if I used a bouncer that would block the IPs at a firewall level. Is there a way to do that inside a kube cluster?

If not, would there be a way to avoid alerts for IPs that are already part of a subscribed blocklist?

Yes you can avoid a duplicate notification, the question is would you like another decision to be made if they already have one?

In fact, I would like that IPs from a subscribed blocklist (like the community blocklist) do not trigger any notification.
Because they don’t need much attention: they are already blocked all the time, and for a good reason.
Ideally, they would not even trigger an alert.

I’d like to be notified only for IPs that are not part of a blocklist. Because I might need to check if it’s a false-positive, if it’s a targeted attack that would require more attention etc.

Yes, but I need an answer to the question do you want them to re trigger a new decision? because the answer will alter how you would implement it.

Edit: alerts and decisions are separate things

Thanks for your patience.
I would probably like to have no new decision.

So you need to modify your engine profiles to check if there already a decision

name: default_ip_remediation
 - Alert.Remediation == true && Alert.GetScope() == "Ip" && GetDecisionsSinceCount(Alert.GetValue(), "2h") < 1
 - type: ban
   duration: 4h
#duration_expr: "Sprintf('%dh', (GetDecisionsCount(Alert.GetValue()) + 1) * 4)"
on_success: break

The key thing to point out in the above yaml is the GetDecisionsSinceCount(Alert.GetValue(), "2h") < 1 at the end of the filter. This means that within 2 hours if the IP address has already got a decision then a new one wont be generated as well as the notification will be nulled.

The reason for 2 hours is the community blocklist pulls every 2 hours on free plan so there no need to check anything above this time.

However, this applied for ALL scenarios. We cant get the origin of the decision, if you want this then you can use the CTI helpers but you get 50 queries per day for free.

Many thanks for your detailed answer.

So I suppose there is an implicit decision for all IPs in a subscribed blocklist, that does not appear in CrowdSec Console ?

And, if such IP triggers for example crowdsec/http-probing, it will generate an alert, but no (new) decision. And no notification either.

Did I understand it well?

Exactly, they get applied on your Security Engine level only.

And, if such IP triggers for example crowdsec/http-probing, it will generate an alert, but no (new) decision. And no notification either.

Not with the current setup, this will not generate an alert or decision or notification. You can do it but have to be split across multiple profiles.

Thanks for your help.
I’ve implemented the setup you suggested.

However, I also now understand that not all the community blocklist is downloaded and used by crowdsec lapi and agents (found that in Troubleshooting Guide | CrowdSec).

How can I check (manually) if an IP belongs to a subscribed blocklist? Using cscli, I suppose?
For example, IP was recently blocked locally (I received a notification for it). According to, it’s in the community blocklist. How can I check if it belongs to the part of the community blocklist in use locally?

More generally, I don’t find much detail on how the part of the community blocklist is “based on (my) installed scenarios”. Where can I find more detail?