#How to list banned IPs
cscli decisions list
#How to unban an IP
cscli decisions delete -i x.x.x.x
#I want to prevent Crowdsec from banning a given IP
Inspired from the existing default whitelist for private IP addresses, you can craft your own (and drop it in
name: crowdsecurity/mywhitelistsdescription: "Whitelist events from private ipv4 addresses"whitelist: reason: "private ipv4/ipv6 ip/ranges" ip: - "127.0.0.1" - "::1" cidr: - "192.168.0.0/16" - "10.0.0.0/8" - "172.16.0.0/12"
#Where is the configuration related to the CrowdSec local API?
While you don't need to modify these file with a simple installation, you need to edit them when you want to use CrowdSec in a multi machine setup.
- For the CrowdSec Local API Server listen URL:
This information is stored in
/etc/crowdsec/config.yaml in the
More information here.
- For the CrowdSec Agent client API:
The URL of the local API that the CrowdSec agent should communicate with is stored in
You can edit the
url option according to your local API URL.
- For the bouncers:
Each bouncer has its own configuration file, which is located in the
They all have an
api_url option to set the local API URL.
#My bouncer doesn't start/work (common causes)
- Bouncer cannot connect to the local API
- error message might look like:
level=error msg="auth-api: auth with api key failed return nil response, error: dial tcp 127.0.0.1:8080: connect: connection refused"
- solution verify that the local API runs on the configured IP
- Bouncer cannot authenticate to the local API
- error message might look like:
time="19-04-2022 15:43:07" level=error msg="API error: access forbidden"
- solution regenerate an API key via cscli bouncers
#My scenario is triggered with less logs than the scenario capacity
During the installation, the CrowdSec Wizard is ran, which detects the basic logs files to add in the acquisition configuration.
If you re-run the
wizard.sh script after the installation and you have common log files, they might be set up multiple times in your acquisition configuration. This means that CrowdSec will read each logs line as many time as you have the logs file configured in your acquisition configuration.
#Scenario XXX keeps triggering, it's a false positive
To avoid a specific scenario that is bothering you, you have several options:
- set it in simulation mode: you will see the alerts, but no decisions will be applied
- purely remove the scenario: it will be completely disabled
#I need to whitelist a specific event pattern
For example, I don't want to disable the simulation mode for a scenario nor remove it, but it triggers false positives when i access the admin panel of my website.
I can then whitelist the admin panel URLs and so keep the scenario:
name: crowdsecurity/my_whitelistdescription: "Whitelist URL starting with '/admin' "whitelist: reason: "False positive on admin panel" expression: - "evt.Parsed.request startsWith '/admin'"
#I receive few IPs in the community-blocklist
The community-blocklist that you receive is based on your installed scenarios, if they are neither tainted nor custom.
For example, if your
crowdsecurity/ssh-bf scenario is tainted, you will not receive IPs concerning this scenario in the
#I want to set a custom/tainted scenario in simulation mode
If you want to set a custom/tainted scenario in simulation mode, you need to provide the scenario's filename instead of its name.
For example, i have a scenario called
crowdsecurity/my-custom-scenario located in
To enable the simulation mode for this scenario, i need to run:
sudo cscli simulation enable my_custom_scenario.yaml
Why are XXX logs not parsed in
cscli metrics ?#
If you are facing logs that doesn't seem to be parsed correctly, please use
cscli explain :
# cscli explain --log "May 16 07:50:30 sd-126005 sshd: Invalid user git from 184.108.40.206 port 47738" --type syslogline: May 16 07:50:30 sd-126005 sshd: Invalid user git from 220.127.116.11 port 47738 ├ s00-raw | └ 🟢 crowdsecurity/syslog-logs (first_parser) ├ s01-parse | ├ 🔴 crowdsecurity/iptables-logs | ├ 🔴 crowdsecurity/mysql-logs | ├ 🔴 crowdsecurity/nginx-logs | └ 🟢 crowdsecurity/sshd-logs (+6 ~1) ├ s02-enrich | ├ 🟢 crowdsecurity/dateparse-enrich (+2 ~1) | ├ 🟢 crowdsecurity/geoip-enrich (+13) | ├ 🔴 crowdsecurity/http-logs | └ 🟢 crowdsecurity/whitelists (unchanged) ├-------- parser success 🟢 ├ Scenarios ├ 🟢 crowdsecurity/ssh-bf ├ 🟢 crowdsecurity/ssh-bf_user-enum ├ 🟢 crowdsecurity/ssh-slow-bf └ 🟢 crowdsecurity/ssh-slow-bf_user-enum
This command will allow you to see each parser behaviour.
Do not use
cscli explain on big log files, as this command will buffer a lot of information in memory to achieve this.
If you want to check crowdsec's behaviour on big log files, please see replay mode.
#Is scenario XXX working on my logs ?
You can replay old logs with replay mode, which will allow you to see which scenarios would have been triggered. If no scenario seem to trigger, you can have a closer look at potential parsing errors with
#I want to add collection XXX : how to add log files, and how to test if it works ?
When adding a collection to your setup, the hub will usually specify log files to add.
Those lines need to be added in your acquisition file (
cscli metrics will allow you to see if lines are read and/or parsed.