CrowdSec is a security open-source software. See the overview.
CrowdSec is written in Golang.
Crowdsec agent itself is rather light, and in a small to medium setup should use less than 100Mb of memory.
During intensive logs processing, CPU is going to be the most used resource, and memory usage shouldn't really grow.
CrowdSec is under MIT license.
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 signal 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 pulling block-lists from the platform, the following information is shared as well :
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.
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 Discourse, we love challenges ;)
CrowdSec versions (after v1) supports SQLite (default), MySQL and PostgreSQL databases. See databases configuration for relevant configuration. Thanks to the Local API, distributed architectures are resolved even with sqlite database.
SQLite by default as it's suitable for standalone/single-machine setups.
- Whitelists allows you to "discard" events or overflows
- Simulation allows you to simply cancel the decision that is going to be taken, but keep track of it
Profiles allows you to control which decision will be applied to which alert.
Yes, crowdsec parsers only parse the logs that are relevant for scenarios.
Take a look at
cscli metrics and understand what do they mean to know if your setup is correct.
You can follow this guide
Setting up a proxy works out of the box, the net/http golang library can handle those environment variables:
On Systemd devices you have to set the proxy variable in the environment section for the CrowdSec service. To avoid overwriting the service file during an update, a folder is created in
/etc/systemd/system/crowdsec.service.d and a file in it named
http-proxy.conf. The content for this file should look something like this:
After this change you need to reload the systemd daemon using:
Then you can restart CrowdSec like this:
systemctl restart crowdsec
If you use
sudo cscli, just add this line in
visudo after setting up the previous environment variables:
Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY"
To report a bug, please open an issue on the repository.
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
- Or add your own whitelists
Please keep in mind that raspberry pi OS is designed to work on all raspberry pi versions. Even if the port target is known as armhf, it's not exactly the same target as the debian named armhf port.
The best way to have a crowdsec version for such an architecture is to do:
- install golang (all versions from 1.13 will do)
- Update the GOARCH variable in the Makefile to
- install the arm gcc cross compiler (On debian the package is gcc-arm-linux-gnueabihf)
- Compile crowdsec using the usual
See the tutorial
With tor installed, setting
HTTPS_PROXY environment variables to your socks5 proxy will do the trick.
$ sudo HTTPS_PROXY=socks5://127.0.0.1:9050 HTTP_PROXY=socks5://127.0.0.1:9050 ./wizard.sh --bininstall
Do not use the wizard in interactive (
-i) mode if you're concerned, as it will start the service at the end of the setup, leaking your IP address.
$ sudo HTTP_PROXY=socks5://127.0.0.1:9050 HTTPS_PROXY=socks5://127.0.0.1:9050 cscli capi register
When setting up High Availability for Local API, do not forget to share the same
CS_LAPI_SECRET between your Local API instances : it is the secret used to signed JWT tokens. (By default it's generated from PRNG at startup)
To disable the central API, simply comment out the
online_client section of the configuration file.