Hardening a Server in Two Steps: Fail2ban for the Host, SafeLine for the App

Daniel Black — Fri, 09 Oct 2026 11:23:38 +0000

People treat server hardening and web-app protection as two separate projects. They aren't. Fail2ban and SafeLine cover different layers, and together they take about ten minutes to stand up. Here's the two-step version.

Step 1 — Fail2ban: lock down the host

Fail2ban watches your server's logs and bans IPs that show hostile behavior — SSH brute force, repeated 404s, port scans. Install it:

sudo apt install fail2ban
sudo systemctl enable --now fail2ban

By default it protects SSH. Enable a few more jails (nginx, wordpress) and bad actors get dropped at the firewall before they ever reach your app.

Step 2 — SafeLine: protect the app

SafeLine sits in front of your web app as a reverse proxy and inspects every HTTP request. Install it in one command:

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

Point it at your app via the console at https://<your-server-ip>:9443. SQL injection, XSS, and malicious bots get blocked at the application layer — even from an IP with a clean reputation.

Why both

Fail2ban stops host-level noise: SSH brute force, scanning, repeated probes.
SafeLine stops app-level attacks: injection, XSS, malicious bots reaching your code.

One guards the door; the other guards what's inside. Neither replaces the other.

FAQ

Does Fail2ban need SafeLine?

If your only risk is SSH brute force, Fail2ban alone is a fine start. But it can't see into HTTP request bodies — that's SafeLine's job.

Does SafeLine need Fail2ban?

SafeLine protects the app, not the host. Without Fail2ban, your SSH port and other services stay exposed to brute force.

Is SafeLine open source?

SafeLine is a self-hosted WAF with a free Community Edition (up to 10 apps, 800 QPS). It's not open source — you run it yourself rather than building from source.

How long does setup take?

About ten minutes for both, most of it waiting on package installs.

Two steps, two layers, one quieter server.

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

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

Daniel Black — Fri, 09 Oct 2026 11:06:14 +0000

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

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

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.

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

DEV Community: Daniel Black