I decided to replace my good old fail2ban by CrowdSec. A nice crowd-sourced alternative where the ban don’t just come from your machine, but from the rest of the user of the application.

It has so many advantages when you come from fail2ban, like a direct integration with CloudFlare or even Nginx to block any detected attacks.


I had a nice detection of spam of the 2 most used vectors on a wordpress: wp-login.php and xmlrpc.php.

The jail was pretty simple, detect spam on those page, and block. But in CrowdSec, we don’t use jail, we use scenario. I had to learn and make a new scenario to teach the program to detect the possible intrusion.


Use the Scenario & Collection

I’ve contributed to the official HUB of CrowdSec to add the missing scenario about XMLRPC.

So if you want to have the scenario install through the hub, the safest and easiest way to keep it up-to-date, here is the procedure:

sudo cscli collections install crowdsecurity/wordpress
sudo cscli scenarios install crowdsecurity/http-bf-wordpress_bf_xmlrpc
sudo systemctl reload crowdsec

It will install the new collection with WordPress login protection and then you can install the XMLRPC scenario then reload crowdsec

Use the gist

A quick explanation, CrowdSec use a system of bucket with a capacity, grouping, and a couple of timers.

  • Capacity: Number of item in the bucket, when it overflows (capacity + 1) the scenario is triggered.
  • Leakspeed: Item are removed from the bucket following this timer. Explaining why it’s a leaky bucket.
  • Blachole: When the bucket overflow, how long do we wait before trying to fill a new one.
  • Groupby: What define the bucket, by which variable should we group the data to make an item.


Just copy the content of the gist at: /etc/crowdsec/scenarios/http-wordpress-login-xmlrpc.yaml

Then reload CrowdSec

sudo systemctl reload crowdsec