Zentralisierte Absicherung mit CrowdSec, HAProxy und einem tinc-Mesh

Erkennen, entscheiden, durchsetzen

Ich betreibe Server in mehreren Rechenzentren bei unterschiedlichen europäischen Anbietern. Ein tinc-Mesh verbindet die beteiligten Systeme. Darauf baut eine zentral verwaltete CrowdSec-Infrastruktur auf: Erkennung findet auf den zuständigen Agenten statt, die Entscheidungen werden zentral verwaltet und an den jeweiligen Zugangspunkten umgesetzt.

Die Rollen sind bewusst getrennt. Ein Log Processor beziehungsweise Agent wertet Logs aus, erkennt Muster anhand seiner Parser und Szenarien und meldet Alerts. Die Local API (LAPI) sammelt diese Meldungen; ihre Profile legen fest, ob daraus eine Entscheidung entsteht. Bouncer beziehen die Entscheidungen und setzen sie lokal durch.

So muss ich Sicherheitsregeln nicht auf jedem Server unabhängig verwalten. Die Ausführung bleibt dennoch nahe am Dienst: im Reverse Proxy, in der Host-Firewall oder direkt in WordPress.

Drei Bausteine, eine zentrale LAPI

Meine Infrastruktur gliedert sich in einen zentralen Baustein und zwei Arten von Satelliten. Der zentrale Baustein betreibt die LAPI, die Verwaltungsoberfläche, die CAPI-Anbindung und den HAProxy-Bouncer. Core-Satelliten sind für weitere Hosts der eigenen Infrastruktur vorgesehen. Externe Satelliten laufen als Host-Pakete auf den angebundenen Drittsystemen.

Aktuell sind drei Enhance-Hosts als externe Satelliten angebunden. Weitere Core-Hosts ohne öffentliches Webangebot werden nicht pauschal mit demselben Schutzumfang ausgestattet: Dort bleibt beispielsweise zu prüfen, welcher Schutz für DNS-Dienste sinnvoll ist.

Die Trennung der Rollen folgt dem Multi-Server-Modell von CrowdSec.

Was auf dem zentralen Server läuft

Auf dem zentralen Server kommen mehrere Dienste zusammen: HAProxy nimmt Anfragen für die dort veröffentlichten Dienste entgegen. Eine CrowdSec Security Engine wertet seine Logs aus. Die LAPI verwaltet Alerts, Entscheidungen und die zentrale IP-Allowlist. Der HAProxy-Bouncer läuft als separater SPOA-Dienst; die Management UI macht den Betriebszustand sichtbar.

Die Verwaltungsoberfläche ist ausschließlich über den VPN-Zugang erreichbar. Die LAPI steht den freigegebenen Satelliten über das tinc-Mesh beziehungsweise das interne Management-Netz zur Verfügung. Sie wird für diese Kommunikation nicht öffentlich ins Internet gestellt.

Die Verbindung zur CrowdSec Community API (CAPI) läuft ausgehend über einen Egress Proxy. Darüber bezieht die zentrale Instanz Community-Informationen und tauscht die dafür vorgesehenen Sicherheitsmeldungen aus. Für diese Verbindung muss kein Zugriff aus dem Internet auf das interne Mesh geöffnet werden.

HAProxy: SPOE zur Prüfung, HTTP 403 zur Abwehr

Für den Reverse Proxy verwende ich den CrowdSec HAProxy SPOA Bouncer als separaten Dienst. HAProxy spricht ihn über SPOE an. Der Bouncer synchronisiert die Entscheidungen im Stream-Modus regelmäßig von der LAPI und hält sie für lokale Prüfungen vor. Es ist daher keine synchrone LAPI-Abfrage für jede einzelne HTTP-Anfrage nötig.

1. Anfrage an HAProxyDer Reverse Proxy nimmt die HTTP-Anfrage entgegen.
2. Prüfung über SPOEDer SPOA-Dienst bewertet die Client-IP anhand seiner synchronisierten Entscheidungen.
3. Durchsetzen am ProxyBei ban antwortet HAProxy mit 403 Forbidden. Andernfalls geht die Anfrage zum vorgesehenen Backend weiter.

In meiner aktiven Konfiguration werden IP-basierte Entscheidungen ohne Request-Body geprüft. Für Browser kann HAProxy eine HTML-Sperrseite ausliefern; andere Clients erhalten ebenfalls HTTP 403. Eine gesperrte Anfrage erreicht das dahinterliegende Backend nicht.

Die Integration kann auch CAPTCHA und AppSec-Funktionen unterstützen. Diese Möglichkeiten sind im hier beschriebenen Aufbau nicht aktiviert. Das ist also keine Beschreibung einer bereits eingeschalteten WAF.

Wenn die LAPI vorübergehend nicht erreichbar ist, können bereits synchronisierte, weiterhin gültige Entscheidungen lokal zur Verfügung stehen. Neue Entscheidungen kommen während der Unterbrechung nicht an. Ein Cache ist damit keine Zusage eines unbegrenzt unveränderten Schutzes.

Technische Grundlage: HAProxy-SPOA-Integration von CrowdSec.

Enhance-Hosts im tinc-Mesh

Auf jedem der drei beteiligten Enhance-Hosts laufen ein CrowdSec-Agent und ein Firewall-Bouncer. Der Agent verarbeitet lokale Logs mit den dort benötigten Parsern und Szenarien und meldet erkannte Angriffe an die zentrale LAPI. Der Firewall-Bouncer bezieht die Entscheidungen und setzt IP-Sperren auf seinem Host durch.

Das tinc-Mesh stellt den Kommunikationsweg zur Zentrale bereit. Die CrowdSec-Verwaltung muss dadurch nicht an jedem Standort öffentlich erreichbar sein. Unterschiedliche Rechenzentren und Anbieter ändern nichts an der gemeinsamen Entscheidungsbasis.

HAProxy und Host-Firewalls schützen dabei unterschiedliche Zugangspunkte. Nicht jede Enhance-Anfrage läuft zuerst durch den zentralen HAProxy. Bei vorgeschalteten Proxys muss außerdem geklärt sein, welche Client-Adresse auf der jeweiligen Ebene tatsächlich sichtbar ist. Die Schutzschichten ergänzen sich; sie bilden nicht automatisch für jeden Request eine identische Kette.

Ausnahmen zentral und gezielt pflegen

Vertrauenswürdige IP-Adressen und Netze verwalte ich in der zentralen LAPI-Allowlist. Dazu können eigene Monitoring-Systeme, administrative Zugänge, Partner-Systeme oder wichtige API-Clients gehören. Jede Ausnahme braucht einen konkreten Zweck und einen möglichst kleinen Geltungsbereich.

Damit steht eine gemeinsame IP-/Netz-Ausnahmepolitik zur Verfügung. Ich muss dieselbe CrowdSec-Ausnahme nicht unabhängig auf jedem Satelliten pflegen. Das ersetzt allerdings keine Kontrolle bereits bestehender Sperren oder anderer, separat konfigurierter Firewallregeln.

Eine IP-Allowlist ist auch keine allgemeine Freigabe beliebiger URLs oder Benutzerkonten. Für solche Regeln sind andere Mechanismen zuständig. Die genaue Wirkung beschreibt die CrowdSec-Dokumentation zu zentralen Allowlists.

WordPress: eigener Bouncer pro Website

Einzelne WordPress-Websites können zusätzlich das CrowdSec-Plugin als anwendungsnahen Bouncer verwenden. Jede angebundene Website erhält einen eigenen Bouncer-API-Key und verbindet sich mit der zentralen LAPI.

• Entscheidungen lassen sich direkt in der Anwendung durchsetzen.
• Jeder Zugang lässt sich einzeln widerrufen oder rotieren.
• Die Identität der angebundenen Website bleibt bei der Verwaltung nachvollziehbar.

Der Plugin-Bouncer ergänzt den Schutz durch Reverse Proxy und Host-Firewall. Er ersetzt weder die CrowdSec-Agenten zur Logauswertung noch die Pflege und Absicherung der WordPress-Installation selbst.

Ein Blick auf den Betrieb

Die zentrale Verwaltung zeigt, ob die einzelnen Komponenten Entscheidungen abrufen und wie sich Alerts und Sperren entwickeln. Im Dashboard vom 29. Oktober 2026 waren 130 aktive Entscheidungen, 4.959 Alerts für sieben Tage und 14 aktive Bouncer zu sehen.

Das ist eine datierte Momentaufnahme aus dem Betrieb, keine Live-Anzeige. Die Zahl der Bouncer ist nicht mit der Zahl der Server gleichzusetzen: Neben Host-Bouncern können auch der HAProxy-Bouncer und einzelne WordPress-Plugins registriert sein.

Die Betriebsregeln dahinter

Für mich sind einige Grenzen wichtiger als eine möglichst lange Liste aktivierter Funktionen:

• Die LAPI bleibt eingeschränkt erreichbar. Nur berechtigte Teilnehmer dürfen Alerts melden oder Entscheidungen beziehen.
• Jeder Bouncer hat seinen eigenen API-Key. Zugänge lassen sich einzeln kontrollieren und austauschen.
• Die Management UI bleibt im VPN. Verwaltung und öffentliche Dienste sind getrennt.
• Externe Verbindungen laufen bewusst ausgehend. Die CAPI-Anbindung verwendet den Egress Proxy.
• Ausnahmen werden dokumentiert. Eine zentrale Allowlist braucht ebenso Pflege wie eine Sperrliste.
• Erreichbarkeit und Synchronisierung werden geprüft. Ein registrierter Bouncer allein beweist noch keine wirksame Blockierung.

Gerade Agentenzugänge verdienen Aufmerksamkeit: Wer Alerts einspeisen darf, kann mittelbar auch Entscheidungen auslösen. Zugangskontrolle und die Absicherung des Mesh sind deshalb Teil des Sicherheitskonzepts.

Zentrale Sicht, lokale Durchsetzung

Die zentrale LAPI liefert eine gemeinsame Entscheidungsbasis über mehrere Standorte hinweg. HAProxy, Firewall-Bouncer und WordPress-Plugins setzen diese Entscheidungen jeweils dort um, wo sie Zugriff auf die betreffende Anfrage haben.

Für meinen Betrieb bedeutet das: eine Stelle für die gemeinsame Verwaltung, passende Erkennung auf den beteiligten Systemen und mehrere klar zugeordnete Durchsetzungspunkte. Der Ausbau erfolgt nach Bedarf. Zusätzliche Funktionen wie AppSec oder CAPTCHA sind eigene Schritte und werden nicht allein durch die vorhandene SPOA-Anbindung aktiv.