Wir haben unseren Web-Server auf ein komplett neues Fundament gestellt: den Umstieg von CloudPanel (einer grafischen Verwaltungsoberfläche) hin zu einem zentralen Reverse-Proxy-Server (proxymanager), der vollständig per Infrastructure-as-Code (IaC) mit Ansible verwaltet wird.

Warum dieser Schritt? CloudPanel ist praktisch, solange alles klein ist – aber bei wachsender, verteilter Infrastruktur wird eine GUI zur Fessel: Konfiguration liegt verstreut in der Oberfläche, ist schwer nachvollziehbar und lässt sich nicht sauber versionieren. Mit IaC ist unser kompletter Web-Traffic dagegen als Code dokumentiert, reproduzierbar und versioniert: Der Server ist der gemeinsame Eingangspunkt für alle Dienste – er nimmt die Anfragen entgegen, sichert sie ab und verteilt sie an die jeweiligen Backend-Server im internen Netz. Jeder Vhost, jedes Zertifikat und jede Sicherheitsregel steht in einer YAML-Datei und wird per Playbook-Lauf konsistent deployt.

Warum ein zentraler Proxy?

Früher lief für jeden Dienst mehr oder weniger ein eigenes, individuelles Setup – oft über die CloudPanel-GUI. Das bedeutete viel parallele Konfiguration, unterschiedliche Eigenheiten – und vor allem sehr viel doppelte Pflege. Mit einem einzigen zentralen Reverse-Proxy bündeln wir das:

  • Ein einheitlicher Eingangspunkt für den gesamten öffentlich erreichbaren Web-Traffic.
  • Zentrale Sicherheitseinstellungen, die wir einmal definieren und gezielt pro Dienst anpassen können.
  • Einfachere Erweiterung: Ein neuer Dienst bekommt einen Vhost – konfiguriert in einer YAML-Datei, deployed per Playbook.
  • Weniger Angriffsfläche im internen Netz, weil nur der Proxy nach außen exponiert ist, während die eigentlichen Dienste intern laufen.

So pflegen wir eine konsistente, gut nachvollziehbare Infrastruktur, statt vieler Einzelfälle.

Was auf dem Server läuft

Komponente Aufgabe
nginx Reverse-Proxy und TLS-Terminierung mit zentraler, pro Vhost konfigurierbarer Verwaltung aller Dienste.
acme.sh Automatische Let’s-Encrypt-Zertifikate (Wildcard- und Einzelzertifikate) inkl. Renewal – mit Fullchain-Handling für eine lückenlose Auslieferung.
Anubis Proof-of-Humanity-Filter vor besonders bot-belasteten Diensten, um Missbrauch einzudämmen, ohne echte Nutzer unnötig zu stören.
CrowdSec Intrusion-Detection mit nginx-Bouncer (Inline-Blocking) und Firewall-Bouncer, plus Whitelisting für legitime Clients, damit keine False-Positives entstehen.

Sicherheit & Betrieb

  • TLS: Moderne Verschlüsselung (TLS 1.2/1.3), HSTS und eine durchgängige, pro Dienst anpassbare Security-Header-Policy (CSP, Referrer-Policy, Permissions-Policy, CORP/COOP/COEP u. a.).
  • CrowdSec + AbuseIPDB: Erkennung von Crawling, Brute-Force, CVEs und anderen Angriffen. Ban-Entscheidungen landen direkt in der Firewall und werden zusätzlich als Report an AbuseIPDB gemeldet.
  • Anubis vor sensiblen Diensten: Automatisierte Zugriffe ohne Challenge-Fähigkeit (z. B. reine CLI-Clients) werden gezielt am Filter vorbeigeführt, während normale Nutzer geschützt bleiben.
  • Wartungsfreundlich durch Code: Ein Deployment ist ein einzelner Playbook-Lauf. Zertifikate, Vhosts, Bouncer und Filter werden dabei konsistent installiert, konfiguriert und – nach einem Test – neu geladen.

Ein Einstiegspunkt für alles

Statt für jeden Dienst ein eigenes Setup zu pflegen, läuft unsere gesamte (Federated-)Web-Präsenz – vom Chat über Forum und Fediverse bis hin zu Cloud, Wiki und Git – über diesen einen, sauber orchestrierten Proxy. Das macht die Infrastruktur einfacher zu warten, sicherer und deutlich leichter skalierbar.