decisions list strange result
I recently noticed my firewall bouncer stopped adding ip flagged for ssh attack to the iptable.
I had set it up that way :
I was wondering what changed.
I also have a lot of decisions with negative expiration for the
CAPI
source (-16h32 for example).4 Replies
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 ❤️
From what I just understood, the config above would only block IP reported for ssh behaviour in the community blocklist and not in subscribed list
Issue is : it stopped getting ssh IP to block
I also don't see any ssh related ban in my current CAPI decsision list
only http related ones
as Blotus pointed out, we slighly altered the scenario naming scheme that comes from CAPI beforehand it used to say
crowdsecurity/ssh-bf
as the scenario itself instead now we use the behaviour name which is ssh:bruteforce
so your filter should still match.
However, is your engine reporting http based scenarios? as the system is designed to tailor the blocklist to your actively reported scenarios so if you are reporting them more than ssh the list will want to download more http stuff so you are more protected on your actively attacked application.
this is what the behaviour looks like in cscli metrics
I haven't had any ssh attack detected by my engine latetly which could be the reason why I don't have any ssh:* CAPI decsion currently if the list downloaded depend on what is attacked. However I do not have any ssh:* decision currently
but it still doesn't explain the decisions with negative expiration
btw the --limit option did not work
cscli decision list --limit 15 --origin CAPI