Blocking Bad Traffic by Behaviour, Not by IP List

Every internet-facing server gets the same traffic: credential stuffing on the login route, scanners walking a wordlist of admin paths, bots probing for known CMS vulnerabilities. It is constant, it is automated, and it is noise until one of them finds something.

Static IP blocklists are a poor answer. Addresses rotate, the list ages, and legitimate users end up behind a blocked residential IP.

The model: detect and remediate, separately

CrowdSec splits the job. The agent reads your existing logs — nginx, SSH, the application — and matches them against scenarios describing behaviour. When a scenario fires, it records a decision. A separate component, the bouncer, enforces it at the firewall, the reverse proxy or the application.

That split matters. Detection can run on a log-shipping host; enforcement happens where the traffic is. And swapping enforcement layers does not mean redoing detection.

# acquis.yaml
filenames:
  - /var/log/nginx/access.log
labels:
  type: nginx

Scenarios are declarative: N failed authentications from one source within M seconds, this many 404s across distinct paths, requests matching known probe signatures. They describe patterns rather than addresses, which is why they keep working when the address changes.

Start in observation mode

Turn detection on and enforcement off. Watch the decisions for a week.

You will find things you did not expect: a monitoring probe that looks like a scanner, a mobile client retrying aggressively on a flaky connection, an office NAT where forty people share one address and one of them keeps mistyping their password.

Enable blocking after you have allowlisted those. Skipping this step is how a security tool becomes an outage, and it is the most common way these deployments go wrong.

The community signal, with a caveat

Participating instances share attacker IPs and you can consume the aggregated blocklist. It is genuinely useful — an address hammering someone else's login page an hour ago is not a customer.

The caveat is that you are now enforcing decisions made by data you did not verify. Treat it as one input with its own confidence level, not as ground truth. Keep your own scenarios as the primary signal, and make sure a false positive from a shared list is something you can diagnose quickly.

What it does not replace

This is a traffic-layer control. It does not fix an authentication bug, an injection flaw, or a missing authorisation check. It reduces the volume of automated attempts against those, which buys time and cleans up your logs — but the underlying vulnerability is still there.

Rate limiting and behavioural blocking are the outer wall. They are not a reason to skip the work inside it.

Resources

• Repo: crowdsecurity/crowdsec
• Docs: docs.crowdsec.net
• Video walkthroughs: YouTube: crowdsec setup tutorial
• Related: Wazuh: an SOC you can actually run