Fallstudie: nginx Reverse Proxy + Suricata + CrowdSec

Nachdem wir einen ueber eine Web-Shell kompromittierten Server bereinigt hatten, war der naechste Schritt sicherzustellen, dass es nicht wieder passiert. Wir setzten einen nginx Reverse Proxy mit TLS und Hardening vor die Apps, ein Suricata, das den gesamten Verkehr sieht, und ein CrowdSec, das die Logs liest und feindliche Quellen automatisch blockiert. Drei Schichten, die sich gegenseitig abdecken.

Die Anforderung: Verteidigung in der Tiefe, nicht eine einzige Mauer

Eine einzige Verteidigungsschicht faellt beim ersten Fehler. Wir wollten drei: einen Proxy, der die App verbirgt und filtert, ein IDS, das Angriffe auf Netzwerkebene sieht, und eine Engine, die aus Logs lernt und automatisch blockiert. Wenn eine etwas verpasst, faengt es die andere.

Kurz gesagt: derselbe Angreifer wird vom Proxy, vom IDS und von der Reputations-Engine gesehen; wir blockieren ihn einmal, automatisch, bevor er Schaden anrichtet.

Architektur

Das Internet kommt ueber nginx (Reverse Proxy + TLS) herein, der an die PHP-Apps dahinter weiterleitet. Suricata inspiziert den gesamten Verkehr (IDS), und CrowdSec liest die nginx-Logs, wendet Szenarien an und legt boese IPs in einen Firewall-Bouncer.

nginx: Reverse Proxy, TLS und Hardening

nginx verbirgt die App, terminiert TLS und setzt die Basis-Limits (Rate-Limit, Security-Header). Die PHP-App ist nicht mehr direkt exponiert.

# /etc/nginx/sites-available/app
limit_req_zone $binary_remote_addr zone=app:10m rate=10r/s;
server {
  listen 443 ssl http2;
  server_name app.example.com;
  ssl_certificate     /etc/letsencrypt/live/app.example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
  add_header X-Content-Type-Options nosniff;
  add_header X-Frame-Options SAMEORIGIN;
  location / {
    limit_req zone=app burst=20 nodelay;
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header X-Real-IP $remote_addr;
  }
}

nginx -t && systemctl reload nginx

Suricata: IDS auf dem gesamten Verkehr

Suricata sieht die Pakete und loest Alarme bei Signaturen aus (Scans, Exploits, Web-Shells). Sie setzen es auf die Schnittstelle und laden die Emerging-Threats-Regeln.

apt -y install suricata
suricata-update            # ET-open-Regeln herunterladen
# Listen-Interface (af-packet) in /etc/suricata/suricata.yaml setzen
systemctl enable --now suricata
# Alarme beobachten:
tail -f /var/log/suricata/fast.log

Kurz gesagt: Suricata blockiert hier nicht selbst (es ist ein IDS), aber es gibt Augen auf dem Netz: Sie sehen den Scan oder Exploit, wenn er passiert.

CrowdSec: liest die Logs und blockiert

CrowdSec liest die nginx-Logs (und optional Suricatas eve.json), erkennt Angriffsmuster und legt die boese IP in einen Firewall-Bouncer. Plus Community-Reputation.

curl -s https://install.crowdsec.net | sudo sh
apt -y install crowdsec
cscli collections install crowdsecurity/nginx crowdsecurity/base-http-scenarios
# Firewall-Bouncer (nftables) -> dropt die IPs
apt -y install crowdsec-firewall-bouncer-nftables

# was es sammelt + was es blockiert
cscli metrics
cscli decisions list
cscli alerts list --since 24h
cscli console enroll <KEY>   # Dashboard + CTI-Blocklists

Ergebnis

Die PHP-App ist nicht mehr direkt exponiert: nginx filtert und limitiert, Suricata gibt Sichtbarkeit auf Angriffe, und CrowdSec blockiert feindliche Quellen automatisch, bevor sie insistieren. Ein Scanner, der Web-Shells sucht, wird in Sekunden an der Firewall erkannt und blockiert, und Community-Reputation stoppt viele Angriffe, bevor sie beginnen. Alles geht ins 24/7-Monitoring.