Scenarios fireup order and skipping

crowdsec
1

Hi

I’m trying to figure out how to order scenarios queue and skip unnecessary ones.

For example: I’m running crowdsec on OPNsense router and there is scenario which looks into packet filter logs (firewallservices/pf-scan-multi_ports)

It has this filter:

filter: "evt.Meta.log_type == 'pf_drop' && evt.Meta.service == 'tcp'"

I want to leave this filter (and scenario) alone and make a copy this scenario file into new file (and new name) → “aaa/a-pf-scan-multi_ports_mod”, and mod for my needs, by modifying:

filter: "evt.Meta.log_type == 'pf_drop' && evt.Parsed.dst_ip == "x.x.x.x" &&( evt.Meta.service == 'tcp' || evt.Meta.service == 'udp')" blackhole: 60m reprocess: false

The purpose of modified (a-pf-scan-multi_ports_mod) scenario is to make blackhole time longer for specific destination IP (I have plan different scenarios for different servers in regards to pf-scan)

The problem is, that both scenarios are summoned (the modified one and the original one), but I want to summon the modified one first (because it is more specific and more conditions has to be fulfilled ) and if the “filter” conditions wouldn’t be met, then leave and summon next one, the default original one)

The cscli explain shows that both will be summoned.

├ Scenarios ├ 🟢 aaaa/pf-scan-multi_ports └ 🟢 firewallservices/pf-scan-multi_ports

And both were summoned indeed.

obraz
obraz1432×445 47.5 KB

How to make this possible?

2

Scenario skipping is not possible, all scenario are always evaluated for every event. If you want a more custom setup then you should remove the ofifical one that you dont want to be evaluated and replace it with a negative filter to the one that you created.

3

Arrghh… This is what I suspected. I wanted to keep the original scenarios because they work well (and are updated from the crowdsec repository), but add more customised ones that were meant to fulfil additional actions/needs.

So what is purpose of reprocess: parameter?

4

Reprocess means once the bucket has overflown the event is passed back through the scenarios so you can filter on it to create a chain of buckets. Typically though this is used for custom scenarios and not including Hub ones as you would have a starting bucket which has remediation: false then on the chain buckets this will change to remediation: true depending on your use cases.

5

Ah, I thought that, when set to false, it stop to run other scenarios at all.

Ok. So I have to create my own version of pf-scan-multi_ports and disable the default one.