With or without a CrowdSec bouncer: a tale of two servers

As CrowdSec is approaching its second anniversary, our community is stronger than ever and increasing at an exponential rate. We reached a point where each day more than 1 million signals – data on nefarious IP activity –  is shared with CrowdSec, contributing to the biggest Cyber Threat Intelligence in the world. With 1.8 million IPs in our database and a curated blocklist of that size, we wanted to measure how this translates to the security of our users.

At the end of 2021, we set up two sibling VPS at OVH: same region, same services (SSH + NGINX). Nothing fancy, there are literally millions of similar boxes on the Internet.

Those two machines, which we very creatively called machine A and machine B, had the following differences:

  • Machine A is running CrowdSec, with no IPS component 
  • Machine B is running CrowdSec and has a firewall-bouncer (IPS)

3 months later, let’s take a look at these machines and check whether CrowdSec made a difference.

The objective of running CrowdSec, and especially the community-blocklist (available by default to all CrowdSec users) is to drastically reduce the number of spotted alerts. Not only the ability to block incoming attacks but also to prevent them, because the bad guys behind them are already listed in the community blocklist.

The difference in numbers

First of all, machine A (no bouncer) went through what you would expect from a machine exposed on the Internet: 1937 attacks over 12 weeks.

Attacks received by Machine A

On the other hand, machine B (with the bouncer) was attacked only 167 times over 12 weeks.

Scenario of attacks on Machine A and Machine B

It is important to note that machine B was not only able to see fewer attacks thanks to the installed firewall bouncer that would stop attacks as they happened. It actually prevented 91% of attacks because bad guys were preemptively blocked by the community blocklist.

In terms of distinct IPs seen by each machine, machine A spotted 146 distinct IPs, while machine B only 90. The difference is the number of IPs that were in the community blocklist before they even attacked machine B.

That’s a diminution of 91% of attacks and 38% in terms of the distinct number of attackers.

Further analysis

Two things are in play here:

  • The machine without the bouncer has the ability to detect attacks thanks to the CrowdSec agent. It is plugged into the logs of SSH and NGINX and thus will detect the usual background noise created by scanning activity. Due to CrowdSec’s low-alert output design, one IP is not too likely to generate several alerts, unless the attack lasts for a long time.
  • The machine with the bouncer on the other hand, while detecting the same attacks, has the ability to stop them as soon as they happen. But, more importantly, it preemptively blocks a lot of bad IPs thanks to the community blocklist

What about IPs that were detected and blocked afterward on machine B? Could the CrowdSec community spot and block this upfront?

To answer that question, we checked those IP addresses against our CTI, as one can do in the CrowdSec console, and the results are quite insightful.

The vast majority of those IP addresses (92%) are so notoriously known by the CrowdSec community that they are part of the community blocklist. When it comes to the remaining IPs, only 5% have a moderate or low confidence level.

What’s next

The CrowdSec community starts to really pull its own weight: the overall majority of attacks are preemptively stopped by the community blocklist, and the remaining malevolent IPs are very well known by the community. We’re working on leveraging this data to make sysadmins and SecOps life easier on a daily basis!

This quick study gives a strong indication of how a crowd-powered IP blocklist – combined with a curation mechanism, can strengthen the security level of CrowdSec users. In addition, it allows users to focus on the most significant and impactful attack signals, instead of losing time and resources exploring  IP activity that is already well known by the community.


The data collected by CrowdSec on these 2 machines and the charts generated are made available publicly in this Github repository.

You may also like

scalecommerce plummets operational costs and skyrockets efficiency with crowdsec
Use Case

ScaleCommerce Uses CrowdSec to Plummet Operational Costs and Skyrocket Efficiency

ScaleCommerce, a leading provider of high-performance and secure online shop solutions, uses CrowdSec to reduce operational costs and supercharge efficiency.

CrowdSec Protects the IUT de Bordeaux against Breach Attempts Using the Power of the Crowd
Use Case

CrowdSec Protects the IUT de Bordeaux against Breach Attempts Using the Power of the Crowd

By leveraging CrowdSec’s open source and collaborative approach, Bordeaux IUT mitigates security risks and fosters a culture of transparency and resilience.

Scalable and Low-Friction Authentication for MSSPs with the CrowdSec IDPS
Use Case

Scalable and Low-Friction Authentication for MSSPs with the CrowdSec IDPS

Scaling can be an issue for smaller teams. See how we helped an MSSP user achieve scalable & low-friction authentication in 30 minutes with the CrowdSec IDPS.