Mit der zunehmenden Virtualisierung verändert sich auch die Art der Serverabsicherung. Statt eines einzelnen Linux-Servers laufen heute häufig zahlreiche Dienste verteilt auf Containern oder virtuellen Maschinen.
Dadurch stellt sich schnell eine wichtige Frage:
Wo sollte CrowdSec installiert werden?
Die Antwort lautet: Es kommt auf den jeweiligen Einsatzzweck an.
Während manche Angriffe bereits auf dem Host erkannt werden können, benötigen andere Dienste einen eigenen CrowdSec-Agenten innerhalb des Containers oder der virtuellen Maschine.
In diesem Artikel betrachten wir die verschiedenen Möglichkeiten.
Typische Virtualisierungsumgebungen
CrowdSec lässt sich problemlos in modernen Virtualisierungsplattformen einsetzen.
Dazu gehören unter anderem:
- Proxmox VE
- Incus
- LXC
- KVM
- Docker
- Podman
Die grundsätzliche Funktionsweise bleibt identisch:
- Logdateien werden ausgewertet.
- Parser analysieren die Daten.
- Szenarien erkennen Angriffe.
- Decisions werden erzeugt.
- Ein Bouncer blockiert den Angreifer.
Mögliche Installationsorte
Grundsätzlich existieren drei Varianten.
Host
┌───────────────┐
│ CrowdSec │
└──────┬────────┘
│
┌─────────┴─────────┐
│ │ │
Container Container VM
oder
Host
├── Container A
│ CrowdSec
│
├── Container B
│ CrowdSec
│
└── VM
CrowdSec
oder eine Kombination aus beiden.
Variante 1 – CrowdSec ausschließlich auf dem Host
Dies ist die einfachste Lösung.
Vorteile:
- nur eine Installation
- zentrale Updates
- geringe Ressourcen
- einfache Wartung
- Firewall-Bouncer direkt auf dem Host
Nachteile:
- Host sieht nicht automatisch alle Logdateien
- Container-Logs müssen bereitgestellt werden
- Anwendungen benötigen gemeinsame Logverzeichnisse
Diese Variante eignet sich hervorragend für:
- kleine Server
- wenige Container
- zentrale Reverse-Proxys
Variante 2 – CrowdSec in jedem Container
Hier besitzt jeder Dienst seinen eigenen CrowdSec-Agenten.
Beispiel:
Container Apache CrowdSec LAPI
Vorteile:
- direkter Zugriff auf alle Logs
- keine Logweitergabe erforderlich
- vollständige Trennung
- individuelle Konfiguration
Nachteile:
- höherer Ressourcenverbrauch
- mehr Updates
- mehrere Agenten
- aufwendigere Verwaltung
Diese Variante empfiehlt sich vor allem bei Mandantenumgebungen.
Variante 3 – Hybride Architektur
Die in der Praxis häufig beste Lösung.
Beispiel:
Host
Firewall-Bouncer
│
LAPI
│
Agenten
├── Webserver
├── Mailserver
├── Datenbank
Dabei:
- analysieren Agenten ihre eigenen Logs
- melden Entscheidungen an die LAPI
- blockiert der Host zentral
Diese Architektur ist besonders skalierbar.
CrowdSec unter Proxmox VE
Proxmox basiert auf Debian.
Dadurch lässt sich CrowdSec wie auf jedem Debian-Server installieren.
Der Host schützt dabei beispielsweise:
- SSH
- Weboberfläche
- API
- Proxmox-Dienste
Zusätzlich können virtuelle Maschinen eigene CrowdSec-Installationen erhalten.
Was sollte auf dem Proxmox-Host überwacht werden?
Typische Logquellen:
- SSH
- syslog
- auth.log
- pveproxy
- pvedaemon
- Firewall
- Clusterdienste
Dadurch werden Angriffe auf den Hypervisor frühzeitig erkannt.
Virtuelle Maschinen absichern
Jede VM arbeitet unabhängig.
Deshalb sollte innerhalb wichtiger VMs ebenfalls CrowdSec installiert werden.
Beispiele:
- Webserver
- Mailserver
- Nextcloud
- Datenbankserver
- Reverse Proxy
Die VM erkennt Angriffe auf ihre eigenen Anwendungen deutlich besser als der Host.
CrowdSec unter Incus
Incus verwendet Systemcontainer.
Diese besitzen:
- eigenes Dateisystem
- eigene Prozesse
- eigene Logs
Dadurch eignet sich CrowdSec hervorragend für den Betrieb innerhalb eines Incus-Containers.
Der Agent arbeitet dort nahezu wie auf einem normalen Debian-System.
Vorteile innerhalb von Incus
- vollständiger Logzugriff
- keine komplizierten Bind-Mounts
- saubere Trennung
- einfache Wartung
- geringe Zusatzlast
Gerade bei produktiven Servercontainern empfiehlt sich diese Lösung.
CrowdSec unter LXC
Auch klassische LXC-Container unterstützen CrowdSec problemlos.
Zu beachten sind jedoch:
- Berechtigungen
- AppArmor
- Netzwerk
- Mounts
Je nach Distribution unterscheiden sich einzelne Pfade.
Privilegierte und unprivilegierte Container
Besonders wichtig:
Unprivilegierte Container bieten deutlich mehr Sicherheit.
CrowdSec funktioniert dort problemlos, sofern:
- Logdateien lesbar sind
- ausreichende Rechte bestehen
- Netzwerkzugriff funktioniert
Privilegierte Container sollten nur verwendet werden, wenn sie wirklich erforderlich sind.
Netzwerküberwachung
CrowdSec analysiert in erster Linie Logdateien.
Es handelt sich nicht um ein klassisches IDS wie Suricata.
Die eigentliche Netzwerküberwachung erfolgt indirekt über:
- Apache-Logs
- SSH-Logs
- Mailserver
- Reverse Proxy
- Firewall
- Datenbanklogs
Je mehr Dienste Logs erzeugen, desto genauer arbeitet CrowdSec.
Wo sollte der Firewall-Bouncer laufen?
Der Firewall-Bouncer sollte möglichst dort arbeiten, wo der Netzwerkverkehr tatsächlich eintrifft.
Meist also:
- Proxmox-Host
- Debian-Host
- Gateway
- Reverse Proxy
Dadurch werden Angriffe bereits vor den Containern blockiert.
Reverse Proxy als zentrale Schutzschicht
Viele Administratoren betreiben:
- Apache
- Nginx
- Traefik
vor sämtlichen Containern.
Dann genügt oft:
Internet ↓ Reverse Proxy ↓ CrowdSec Bouncer ↓ Container
Der Großteil automatisierter Angriffe wird bereits hier gestoppt.
Mehrere Agenten verwalten
In größeren Umgebungen können mehrere CrowdSec-Agenten mit einer gemeinsamen Local API arbeiten.
Beispielsweise:
Server 1 Agent ↓ LAPI ↑ Server 2 Agent ↑ Server 3 Agent
Dadurch entsteht eine zentrale Verwaltung.
Ressourcenverbrauch
CrowdSec benötigt vergleichsweise wenig Ressourcen.
Typischerweise:
- geringer CPU-Verbrauch
- moderater RAM-Bedarf
- kleine SQLite-Datenbank
- geringe Netzwerklast
Selbst mehrere Agenten stellen moderne Server kaum vor Probleme.
Updates
Bei mehreren Installationen empfiehlt sich:
- regelmäßige Paketupdates
- Hub aktualisieren
- Collections prüfen
- Parser aktualisieren
- Szenarien aktualisieren
Nach Updates sollte die Funktion getestet werden.
Sicherheitsüberlegungen
Besonders wichtig sind:
- keine unnötigen Host-Mounts
- nur notwendige Rechte vergeben
- AppArmor aktiv lassen
- Firewall verwenden
- Reverse Proxy absichern
- API nicht öffentlich erreichbar machen
Dadurch bleibt die Angriffsfläche klein.
Typische Architekturen
Kleine Umgebung
Internet ↓ Apache ↓ CrowdSec ↓ Firewall
Homelab
Proxmox ├── Reverse Proxy ├── Nextcloud ├── Immich ├── Beszel └── CrowdSec
Unternehmen
Internet ↓ Firewall ↓ Reverse Proxy ↓ CrowdSec ↓ Webserver ↓ Datenbank
Empfehlungen
Für die meisten Administratoren haben sich folgende Konzepte bewährt:
Einzelserver
CrowdSec direkt auf dem Host installieren.
Wenige Container
CrowdSec auf dem Host.
Logs der Container zentral bereitstellen.
Viele Webserver
CrowdSec am Reverse Proxy.
Viele unterschiedliche Dienste
CrowdSec innerhalb der jeweiligen Container.
Große Umgebungen
Mehrere Agenten mit gemeinsamer LAPI.
Best Practices
- Reverse Proxy zentral absichern
- Host zusätzlich schützen
- wichtige Server mit eigenem Agent ausstatten
- Firewall-Bouncer auf dem Host einsetzen
- keine privilegierten Container ohne Grund verwenden
- regelmäßige Updates durchführen
- Logs regelmäßig kontrollieren
- Entscheidungen überwachen
- API ausschließlich intern erreichbar machen
CrowdSec lässt sich flexibel in Virtualisierungsumgebungen wie Proxmox VE, Incus und LXC einsetzen. Ob die Installation direkt auf dem Host, innerhalb einzelner Container oder als hybride Architektur sinnvoll ist, hängt von der jeweiligen Infrastruktur ab. Für kleinere Umgebungen reicht häufig eine zentrale Installation auf dem Host in Verbindung mit einem Reverse Proxy und einem Firewall-Bouncer. In größeren oder mandantenfähigen Installationen bieten separate CrowdSec-Agenten innerhalb der Container eine bessere Trennung und eine präzisere Angriffserkennung. Mit einer durchdachten Architektur lassen sich sowohl Hosts als auch Container zuverlässig schützen, ohne den Verwaltungsaufwand unnötig zu erhöhen.
