DEV Community

Daniel Black
Daniel Black

Posted on

SafeLine + CrowdSec: Building a Two-Layer Defense for Your Server

#waf #security #devops #crowdsec

People often frame SafeLine and CrowdSec as an either/or choice. They aren't. One guards your application layer, the other guards your server's perimeter — and a real defense is usually both. Here's how the two fit together in practice, without doubling your workload.

The idea in one paragraph

CrowdSec watches your whole server and bans IPs that misbehave. SafeLine sits in front of your web app and filters malicious HTTP requests before they reach your code. Stack them and you get IP reputation at the edge plus payload inspection at the app — two layers, one quiet server.

A concrete topology 

Internet
   │
   ▼
CrowdSec  (agent + firewall bouncer: bans known-bad / scanning IPs)
   │
   ▼
SafeLine  (reverse proxy: inspects every HTTP request)
   │
   ▼
Your app
Enter fullscreen mode Exit fullscreen mode

CrowdSec acts first, at the network level. Anything that survives gets handed to SafeLine, which inspects what's actually being requested.

Where each one actually acts

  • CrowdSec sees the IP, the request volume, and behavior patterns (scanning, credential guessing, weird paths). It bans at the firewall, so bad actors never waste your resources.
  • SafeLine sees the request body. It catches SQL injection, XSS, and malicious bots using a semantic engine that understands what a request is trying to do — even from an IP with a spotless reputation.

A realistic scenario

Case A — the noisy scanner. An IP floods your site with probes. CrowdSec recognizes the scan behavior (and may already know the IP from its global threat feed), bans it at the firewall. The traffic never reaches SafeLine.

Case B — the patient attacker. A fresh IP, clean reputation, sends a seemingly normal POST with a hidden SQLi payload. CrowdSec sees nothing wrong with the IP, so it passes. The request hits SafeLine, whose semantic engine flags the injection and drops it.

Neither tool alone covers both cases. Together, they do.

Getting both running

SafeLine installs in one command and runs as a reverse proxy in front of your app:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en
Enter fullscreen mode Exit fullscreen mode

Point it at your app via the console at https://<your-server-ip>:9443, and your HTTP traffic is filtered.

CrowdSec installs as an agent plus a "bouncer" that enforces bans in your firewall (iptables/nftables). Add the collections for the services you actually run, and it starts learning behavior immediately.

FAQ

Will they conflict?

No. CrowdSec manages firewall rules on the host; SafeLine manages a reverse proxy in front of the app. Different layers, no overlap.

Do I need CrowdSec if I already have SafeLine?

SafeLine alone leaves host-level threats (SSH brute force, port scanning) unaddressed. CrowdSec covers that gap.

Is CrowdSec open source?

Yes — it's open-source and community-driven, sharing threat signals across its network. SafeLine is a self-hosted WAF you run yourself, with a free Community Edition covering up to 10 apps at 800 QPS.

Which should I install first?

Start with SafeLine if your priority is the web app; add CrowdSec when you want host-level IP banning too. Order doesn't matter much.

Stop choosing between layers. Run them both and let each do what it's best at.

Top comments (0)