#Crowdsec Plugin not showing all decisions listed.

1 messages · Page 1 of 1 (latest)

livid salmon
#

Hello : Wondering if anybody can help me. I am running crowdsec and suricata on OPNsense 25.1.1. I have crowsec parsing the suricata logs. When I get two hits on crowdsec they are both listed in the alerts on opnsense but only one is listed in the decisions until i delete the first one and then the second one shows up. When I log into crowdsec console online both show in the alerts and the decisions. I have tried this many times and the same results each time . If i go to console and clcsi list decisions only the first is shown. But when I delete the first one and cscli list decisions then the second is shown. I never had this problem before on OPNsense 24.7 My OPNsense insatallation is fresh installation, not an upgrade from 24.7
I am showing this from my health audit. opnsense-25.1.1: checksum mismatch for /usr/local/opnsense/service/templates/OPNsense/IDS/suricata.yaml

balmy patrolBOT
#
Important Information

Thank you for getting in touch with your support request. To expedite a swift resolution, could you kindly provide the following information? Rest assured, we will respond promptly, and we greatly appreciate your patience. While you wait, please check the links below to see if this issue has been previously addressed. If you have managed to resolve it, please use run the command /resolve or press the green resolve button below.

Log Files

If you possess any log files that you believe could be beneficial, please include them at this time. By default, CrowdSec logs to /var/log/, where you will discover a corresponding log file for each component.

Guide Followed (CrowdSec Official)

If you have diligently followed one of our guides and hit a roadblock, please share the guide with us. This will help us assess if any adjustments are necessary to assist you further.

Screenshots

Please forward any screenshots depicting errors you encounter. Your visuals will provide us with a clear view of the issues you are facing.

© Created By WhyAydan for CrowdSec ❤️ ·
ember root
livid salmon
#

I have also noted a behavior I have not seen before. I am running suricata in ids mode and have crowdsec set up to parse suricata logs and ban. I have been noticing that not all the suricata alerts are being sent to or collected by crowdsec. When I checked the suricata fast logs, I have found that only suricata alerts with Classification: Potentially Bad Traffic are being picked up by crowdsec. Others such as Classification: Attempted Information Leak seem to be ignored by crowdsec. Have you seen this before and is this normal behavior.

queen badge
#

https://app.crowdsec.net/hub/author/crowdsecurity/scenarios/suricata-alerts
We filter on the severity of the rule, that's probably why:

  • if it's severity 1, we instantly ban the IP
  • if it's severity 2, we need at least 3 matches
  • Severity 3 is ignored, they often are informational rules
CrowdSec Console
Hub configuration

Use CrowdSec Console to visualize security data, manage dynamic blocklists, and gain real-time intelligence on IPs. Enhance your threat response capabilities.

livid salmon
#

So for severity 2 it needs >3 matches from the same ip address to trigger a ban? Can I trigger a ban on severity 2 with one match if I wanted to by editing the yaml

ember root
#

Yes you can edit the yaml instead and remove capacity and change the type to trigger instead of leaky

#

but we take no responsibility for bans it may take as in our own testing some rules can trigger easily

livid salmon
#

But the defaut ban is only 4 hours right? If I had a problem I could fine tune the rules or revert the yaml .

ember root
#

Yes exactly

livid salmon
#

Where is the location of the yaml for this?

ember root
#

in freebsd or opnsense its /usr/local/etc/crowdsec/scenarios

livid salmon
#

Ok. thank you.

livid salmon
#

I edited the suricata-alerts.yaml as you described but alerts are still not triggering on severity . Im not sure if I have done it correctly. Here is what I did

#

for lower (2) priority : wait for >=3 different signatures being triggered

we intentionally avoid scenarios on priority 3 and such that are too sensitive to false positives

type: trigger
leakspeed: 20s

queen badge
#

put the content in between triple ` for discord to not interpret it

#

have you restarted crowdsec after making the changes ?

livid salmon
#

yes I did.

queen badge
#

paste the entire content of the scenario file
and a log line that should have triggered a ban

livid salmon
#

Yes I will, but what do you mean by put content between tripple.

queen badge
#

to make a code block
by typing 3 backquotes (`)

to make it look like this
livid salmon
#

'''# for lower (2) priority : wait for >=3 different signatures being triggered

we intentionally avoid scenarios on priority 3 and such that are too sensitive to false positives

type: trigger
leakspeed: 20s

queen badge
#

backquotes not single quotes 🙂

#

or just upload the file itself

livid salmon
#

Ok . Not used to using discord.

#

02/27/2025-10:22:29.512573 [] [1:2011716:3] ET SCAN Sipvicious User-Agent Detected (friendly-scanner) [] [Classification: Attempted Information Leak] [Priority: 2] {UDP} 104.168.4.138:5065 -> x.x.x.x:5060

📎 suricata-alerts.yaml
queen badge
#

For the log line, put it between 2 single `, it's not readable otherwise

#

if i managed to read the log correctly, the severity is 1
so it should have been banned by default

can you show me the content of /usr/local/etc/crowdsec/acquis.yaml
and the output of cscli metrics?

livid salmon
queen badge
#

ok i know
In the suricata log, you pasted, it mentions UDP ({UDP} just before the IP): we explicitly ignore UDP logs, as it's trivial to spoof the source IP in an UDP packet (so, it would be trivial to block any IPs by just sending a few crafted packets to your system).
It's especially true in the case of suricata, as it's looking at the raw packets

livid salmon
#

Ok. So if I leave my config the way it is and there is a level 2 on tcp it should block.

queen badge
#

yes