FREQUENTLY ASKED QUESTIONS¶
What is Crowdsec ?¶
Crowdsec is a security open-source software. See the overview
What language is it written in ?¶
Crowdsec is written in Golang
What licence is Crowdsec released under ?¶
Crowdsec is under MIT license
Which information is sent to the APIs ?¶
Our aim is to build a strong community that can share malevolent attackers IPs, for that we need to collect the bans triggered locally by each user.
The alert sent by your Crowdsec to the central API only contains only meta-data about the attack :
- Attacker IP
- Scenario name
- Time of start/end of attack
Your logs are not sent to our central API, only meta-data about blocked attacks will be.
When your crowdsec is authenticating to the central API, it as well sends the list of the scenarios you have enabled from the hub. This is used by us to provide you the most accurate consensus list, so that we can provide you IPs that have triggered scenario(s) that you are interested into as well.
What is the performance impact ?¶
As Crowdsec only works on logs, it shouldn't impact your production. When it comes to bouncers, it should perform one request to the database when a new IP is discovered thus have minimal performance impact.
How fast is it ?¶
Crowdsec can easily handle several thousands of events per second on a rich pipeline (multiple parsers, geoip enrichment, scenarios and so on). Logs are a good fit for sharding by default, so it is definitely the way to go if you need to handle higher throughput.
If you need help for large scale deployment, please get in touch with us on the CrowdSecurity discourse, we love challenges ;)
What backend database does Crowdsec supports and how to switch ?¶
Currently (0.3.0), Crowdsec supports SQLite (default) and MySQL databases. See backend configuration for relevant configuration.
SQLite is the default backend as it's suitable for standalone/single-machine setups. On the other hand, MySQL is more suitable for distributed architectures where bouncers across the applicative stack need to access a centralized ban database.
How to control granularity of actions ? (whitelists, learning etc.)¶
Crowdsec support both [whitelists]((/write_configurations/whitelist/) and learning :
- Whitelists allows you to "discard" events or overflows
- Learning allows you to simply cancel the decision that is going to be taken, but keep track of it
How to add whitelists ?¶
You can follow this guide
How to set up proxy ?¶
Setting up a proxy works out of the box, the net/http golang library can handle those environment variables:
Since cscli uses
sudo, you just this line in
visudo after setting up the previous environment variables:
Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY"
How to report a bug ?¶
To report a bug, please open an issue on the repository
What about false positives ?¶
Several initiatives have been taken to tackle the false positives approach as early as possible :
- The scenarios published on the hub are tailored to favor low false positive rates
- You can find generic whitelists that should allow to cover most common cases (SEO whitelists, CDN whitelists etc.)
- The simulation configuration allows you to keep a tight control over scenario and their false positives
I need some help¶
Feel free to ask for some help to the community.
I don't see anything in the dashboard !¶
Whenever in doubt with what is being processed or not, check cscli metrics. It should allow you to check : - if the logs are properly read - if the logs are properly parsed - if the scenarios are being triggered
If logs are being read, parsed and overflows are being triggered, but still nothing appears in the dashboard, ask for some help on discourse or gitter !
I have installed crowdsec and it detect attacks, but nothing is blocked !¶
Keep in mind that is only in charge of the detection. The decision/remediation is applied by Bouncers. If you don't install any bouncer, you will detect attack, but not block them. Explore the bouncers in the hub to find the relevant ones !