Fallstudie: OPNsense + Caddy + CrowdSec, korrelierte Entscheidungen

Ein Kunde stellte Web-Apps ueber OPNsense bereit und erhielt pausenlos Scans und Brute-Force-Versuche. Wir integrierten Caddy als Reverse Proxy und CrowdSec, um Logs aus ZWEI Quellen zu lesen — Caddy und die pf-Firewall — sie zu korrelieren und feindliche Quellen automatisch zu blockieren. Hier ist die reale Konfiguration.

Die Anforderung: korrelierte Firewall- + App-Verteidigung

Die Angriffe kamen auf zwei Ebenen: auf Netzwerk-Ebene (Port-Scans, Fluten abgelehnter Verbindungen) und auf Web-App-Ebene (Pfad-Scans, Login-Brute-Force, CVE-Sonden). Eine Firewall allein sieht nur das Netz; eine WAF allein nur HTTP. Wir wollten ein einziges Gehirn, das BEIDES sieht und entscheidet.

Kurz gesagt: derselbe Angreifer wird sowohl von der Firewall als auch von der Web-App gesehen; wir blockieren ihn einmal, fuer alles — automatisch.

Architektur

Das Internet kommt ueber OPNsense (pf-Firewall) herein, die Web-Verkehr an Caddy (Reverse Proxy mit automatischem HTTPS) und von dort an die Apps sendet. CrowdSec liest die Caddy-Logs und die pf-Logs parallel, wendet Szenarien an, trifft Entscheidungen, und ein Bouncer setzt sie durch.

Caddy: Reverse Proxy mit automatischem HTTPS + Logs

Caddy macht HTTPS automatisch (Let's Encrypt) und loggt in JSON — ein Format, das CrowdSec leicht parst.

# Caddyfile
{
    order crowdsec first
    crowdsec {
        api_url http://127.0.0.1:8080
        api_key {env.CROWDSEC_BOUNCER_KEY}
    }
}

app.example.com {
    crowdsec                       # App-Ebenen-Bouncer (403 fuer boese IPs)
    reverse_proxy 10.0.0.20:8080
    log {
        output file /var/log/caddy/access.log
        format json
    }
}

CrowdSec: liest ZWEI Quellen (Caddy + pf)

Das ist der Schluessel: in acquis.yaml geben Sie CrowdSec beide Log-Quellen. So sieht es sowohl HTTP (von Caddy) als auch das Netz (von der OPNsense-Firewall).

# /etc/crowdsec/acquis.yaml
---
filenames:
  - /var/log/caddy/access.log
labels:
  type: caddy
---
filenames:
  - /var/log/filter/latest.log     # OPNsense-Firewall-Logs (filterlog)
labels:
  type: opnsense
---
source: journalctl
journalctl_filter:
  - "_SYSTEMD_UNIT=sshd.service"
labels:
  type: syslog

Szenarien: HTTP + Firewall

Sie installieren die Collections, die Angriffe aus jeder Quelle erkennen — Pfad-Scans, Brute-Force, CVE-Sonden (von Caddy) und Scans/Fluten (von der Firewall).

cscli collections install crowdsecurity/caddy crowdsecurity/base-http-scenarios crowdsecurity/http-cve
cscli parsers install crowdsecurity/opnsense-logs   # parst filterlog
cscli collections list
cscli hub update && cscli hub upgrade

Bouncer: Block an der Firewall + 403 an Caddy

Zwei Durchsetzungsebenen: der Firewall-Bouncer legt die boese IP in ein pf/nftables-Set (stoppt sie, bevor sie Caddy erreicht), und der Caddy-Bouncer antwortet mit 403 auf App-Ebene. Zusammen decken sie alles ab.

# 1. Firewall-Bouncer (auf OPNsense / Linux) -> Block in pf/nftables
apt -y install crowdsec-firewall-bouncer-nftables
cscli bouncers add opnsense-fw
# 2. Caddy-Bouncer (403 auf HTTP-Ebene) -> der Key aus dem Caddyfile
cscli bouncers add caddy-bouncer
cscli bouncers list

Entscheidungen und Betrieb

Es korreliert alles in einem Satz von Entscheidungen, plus Community-Reputation (IPs, die im gesamten CrowdSec-Netz gemeldet werden).

cscli metrics                    # was es aus jeder Quelle liest
cscli decisions list             # jetzt blockierte IPs (von Caddy ODER pf)
cscli alerts list --since 24h
cscli console enroll <KEY>       # Dashboard + CTI-Blocklists

Ergebnis

Ein Angreifer, der Ports scannt und dann Login-Brute-Force versucht, wird von beiden Quellen erkannt und einmal an der Firewall blockiert, bevor er die App erneut beruehrt. Fehlalarme werden durch Tuning reduziert, alles ist in der CrowdSec-Konsole sichtbar, und Community-Reputation stoppt viele Angriffe, bevor sie beginnen. Wir entwerfen, tunen es und nehmen es in das 24/7-Monitoring auf.