FIREWALL · SECURITY & OPS
Firewall and CrowdSec: layered protection for SME servers in 2026
Network firewall (ufw/nftables) plus application protection with CrowdSec, the open-source successor to Fail2ban with crowd-sourced threat intel.
Researched & fact-checked by: DuneDive LLC · As of: 2026-05
What is a layered server firewall?
A server firewall is not a single tool but a chain of filters at different network layers. The lowest layer is the network firewall: iptables, nftables, or uncomplicated firewall (ufw) decide which TCP/UDP ports are open outwards. The next layer is the application firewall: tools like CrowdSec, Fail2ban, or ModSecurity analyse application logs (nginx, sshd, postfix), detect attack patterns, and block attacking IPs.
As of May 2026 CrowdSec is the open-source market leader for SMEs. The French company developed a more modern concept than Fail2ban in 2020: not only local log analysis but crowd-sourced threat intelligence. Every CrowdSec node reports observed attacks to the central platform (anonymised, only an IP hash plus the attack pattern), and all nodes share the resulting blocklist with more than 100,000 servers worldwide. An IP that attacks a fiduciary server in Paris is blocked on a server in Zurich 90 seconds later.
The architecture is cleanly separated: a local agent reads logs and decides bans. Bouncers (plugins) enforce the bans - there are bouncers for nginx, iptables, Cloudflare, Traefik, AWS WAF, and custom web apps. The free tier is the Community Edition, fully usable for SMEs. In May 2026 CrowdSec introduced a new AI Bouncer: a light ML model detects behavioural anomalies (request speed, path patterns, user-agent drift) that rule-based detection misses.
Why the layers matter
An SME server without a firewall becomes a target within minutes of going live - SSH brute force, credential stuffing on known paths (/wp-admin, /api/v1/login), vulnerability scans (Shodan, Censys). The server cannot fend off attacks with its own auth logic - it exhausts itself on the sheer volume of attempts.
Take a Swiss law firm running a Nextcloud server for client files: without protection the server sees 200 to 5000 failed login attempts per day. Even with strong passwords and MFA that is a performance problem (logs fill up, CPU rises) and a DoS risk (brute-force waves overload the auth endpoint). With CrowdSec, attackers are banned for 4 hours after 3 to 5 failed logins - and the bouncer drops packets in iptables before they reach the application.
For compliance, documented defence is state of the art. FADP Art. 8 demands appropriate security. The FDPIC guideline lists firewall and brute-force protection among the minimum technical-organisational measures. Without firewall plus application-layer protection, FADP compliance for a client portal is untenable.
Third driver: speed of the threat landscape. Botnets in 2026 target servers at a scale that pure local detection cannot keep up with. A crowd-sourced blocklist makes the 100,000x multiplier usable.
How the layered protection works
Layer 1 - network firewall. ufw is the beginner-friendly option on Ubuntu/Debian, a wrapper around iptables/nftables. Default config: all incoming ports closed by default, exceptions for 22 (SSH), 80 (HTTP), 443 (HTTPS). SSH ideally not on 22 but on a non-standard port (e.g. 2847) - this massively cuts background noise. Advanced setups use nftables directly for finer rules (geolocation blocking, connection limits).
Layer 2 - SSH hardening. Before any application firewall: PasswordAuthentication no in sshd_config, public-key auth only, root login disabled, AllowUsers whitelist, Fail2ban or CrowdSec with the ssh acquis. As of May 2026 the recommendation is to additionally hide SSH behind a Tailscale or WireGuard VPN, then there is no public SSH port at all.
Layer 3 - CrowdSec agent. The daemon runs as a container or systemd service. The acquis config tells it which logs to read (nginx access.log, sshd.log, postfix.log, custom app logs). Parsers decompose log lines into structured events. Scenarios are YAML rules that match patterns (e.g. http-bruteforce: 5 failed /login in 60 seconds). On match a decision fires (typically IP ban for 4 hours).
Layer 4 - bouncer. The decision is sent to all registered bouncers. The iptables bouncer sets a DROP rule. The nginx bouncer returns HTTP 403. The Cloudflare bouncer creates a block entry in the Cloudflare account. At Fairlane we combine the nginx bouncer plus the iptables bouncer (defense in depth - even if one bouncer fails, the other blocks).
Layer 5 - crowd blocklist. The CrowdSec Console (free for Community Edition) delivers the shared blocklist set: 4 to 6 million active bad IPs at typical levels. Update every 15 minutes. The AI Bouncer (new in May 2026) extends rule-based detection with behavioural classification - catching attackers that stay under the scenario thresholds.
Layer 6 - web application firewall. ModSecurity with the OWASP Core Rule Set is the open-source choice. ModSecurity sits in nginx or Apache and checks every HTTP request against 200+ rules (SQL injection, XSS, RFI, path traversal). Cloudflare WAF (see ddos-schutz-cloudflare) is the cloud variant. Both complement CrowdSec - layer-7 pattern matching instead of log analysis.
Layer 7 - logging and audit. All bouncer actions log to a record with decision ID, IP, pattern, and bouncer. Loki or Elasticsearch ingests them (see logging-und-audit-trail). Important for FADP: IP addresses are personal data, retention should not exceed 6 months unless there is an active forensic investigation.
CrowdSec setup in 6 steps
- 01Harden the network firewall: ufw default deny incoming, ufw allow 22/2847/80/443, enable SSH public-key auth.
- 02Install CrowdSec: curl -s https://install.crowdsec.net | sudo sh, then sudo systemctl status crowdsec.
- 03Configure acquis: cscli parsers install crowdsecurity/nginx-logs sshd-logs, plus postfix-logs and custom-app-logs as needed.
- 04Install bouncers: cs-firewall-bouncer (iptables) and/or cs-nginx-bouncer, optionally cs-cloudflare-bouncer.
- 05Enrol with the CrowdSec Console (cscli console enroll) for crowd blocklist and dashboard access.
- 06Configure whitelists: office IP, monitoring IPs, health-check endpoints under scenarios/whitelists.yaml.
When to deploy CrowdSec
CrowdSec belongs on every publicly reachable Linux server. Setup effort for a typical SME: 2 to 4 hours. Maintenance: 1 to 2 hours/month. Effect: 90 to 99 percent of attack noise disappears, real incidents become visible.
Typical use cases: a Hetzner server with custom apps (fiduciary portal, lawyer case system, e-commerce backend). Nextcloud, Bitwarden, MinIO servers. Custom LLM API endpoints (CrowdSec detects token-burn attacks via request-rate pattern matching). Mail servers (postfix acquis recognises spam attempts and auth brute force). Docker hosts running n8n, Loki, Qdrant, Grafana.
Special fit: SMEs with several servers. The CrowdSec Console aggregates decisions across all nodes - an attack on the n8n server automatically yields a ban on the web server. Also across cloud providers.
When CrowdSec is overkill
Three cases where CrowdSec is not the right choice.
First: a pure single-page marketing site behind Cloudflare without login and without API. Cloudflare WAF already covers the attacks; an additional CrowdSec layer adds little. ufw plus Cloudflare WAF is sufficient.
Second: servers below the minimum hardware requirement. CrowdSec needs roughly 200 MB of RAM and half a CPU core. On a 512 MB VPS that is noticeable.
Third: strict compliance with a prohibition on cloud API calls outside the Swiss data area. CrowdSec Community Edition sends anonymised telemetry to the central platform (IP hash, attack patterns). Anyone forbidden to allow this connection can run CrowdSec in offline mode - but loses the key crowd advantage and effectively drops to Fail2ban-level functionality.
General pitfalls: building scenarios so aggressive that they produce false positives (your own health check trips a brute-force rule and the load balancer gets banned). Activating a bouncer without protecting your admin access (you lock yourself out). Failing to whitelist your office VPN (a Tor-exit-node match on your IP results in a ban).
Trade-offs
STRENGTHS
- Crowd-sourced blocklist with 100,000+ nodes and 4 to 6 million active bad IPs
- Clean separation of agent and bouncer, multiple bouncers can run in parallel
- YAML scenarios more readable than Fail2ban regex
- AI Bouncer adds behavioural ML to rule-based detection
WEAKNESSES
- About 200 MB of RAM required, noticeable on minimal VPS
- Community Edition sends telemetry - offline mode loses the main advantage
- False positives with over-aggressive scenario configuration
- Self-lockout possible without careful whitelist hygiene
FAQ
How is this different from Fail2ban?
Fail2ban is the classic since 2004, still actively maintained, but conceptually dated. CrowdSec has three structural advantages: (1) crowd-sourced threat intel via the Console, (2) cleaner separation of agent and bouncer (Fail2ban does both in one process), (3) YAML-based scenarios instead of regex in INI files. For a single SME system without compliance pressure, Fail2ban suffices; for several servers and modern requirements, CrowdSec is the better choice.
What about FADP compliance with the threat intel?
CrowdSec Community Edition sends only IP hashes plus scenario names. No client data, no plain-text logs. Retention in the Console account is 7 days. CrowdSec is a French SAS headquartered in Paris and is subject to GDPR. Acceptable for Swiss SMEs; for strictly FINMA-regulated operations the offline mode should be considered.
How long are IPs banned?
Default for SSH brute force: 4 hours. Default for HTTP brute force: 4 hours. Crowd blocklist: 24 hours to 7 days depending on reputation. Values are configurable in YAML. Persistent bans for severe incidents (e.g. a successful exploit attempt) can be set in a custom scenario to 30 days or permanent. Whitelisting and manual unblock via cscli decisions delete are possible at any time.
What is the CrowdSec AI Bouncer?
Released in May 2026. A complementary ML model that does not match patterns but behaviour: request rate, path sequences, user-agent drift, header anomalies. Catches attackers that stay under classic scenario thresholds (e.g. 1 login attempt per minute instead of 5/min). Free in the Community Edition, based on a light model that runs locally (no outbound API call for inference). In pilot phase at Fairlane: experience so far positive.