„Managed Hosting“ steht auf vielen Angeboten und bedeutet auf jedem etwas anderes. Bei dem einen sind es Updates des Betriebssystems, bei dem anderen ein Bereitschaftstelefon, bei einem dritten nur ein Server mit mehr Arbeitsspeicher. Der Begriff ist nicht geschützt, deshalb hilft nur eine Aufzählung.
Zu einem betreuten Server gehören sechs Bausteine: ein vorgelagerter Reverse Proxy mit automatischen Zertifikaten, Angriffserkennung, Erreichbarkeitsüberwachung mit Benachrichtigung, tägliche verschlüsselte Sicherungen mit Wiederherstellungstest, getrennte Netze zwischen den Diensten und ein Verwaltungszugang, der nicht öffentlich erreichbar ist. Fehlt einer davon, ist es kein Betrieb, sondern Bereitstellung.
1. Reverse Proxy und Zertifikate
Vor allen Anwendungen steht ein Reverse Proxy, in unserem Fall nginx. Er nimmt jede Anfrage entgegen und leitet sie an die zuständige Anwendung weiter. Damit liegt die Verschlüsselung an einer Stelle statt in jedem Dienst einzeln, ebenso Sicherheits-Header, Zwischenspeicherung und Weiterleitungen.
Die Zertifikate erneuern sich selbst über Let’s Encrypt. Bei uns läuft das über die Prüfung per DNS-Eintrag statt über eine Datei auf dem Webserver. Der Umweg hat einen praktischen Grund: So lassen sich auch Zertifikate für Dienste ausstellen, die gar nicht öffentlich erreichbar sind, und Platzhalter-Zertifikate für ganze Unterdomänen.
2. Angriffserkennung
Jede öffentlich erreichbare Website bekommt automatisierte Anmeldeversuche, unabhängig davon, ob sie jemand kennt. Das sind keine gezielten Angriffe, sondern Programme, die das gesamte Netz durchgehen.
Dagegen laufen zwei Ebenen. fail2ban wertet die Protokolle des Servers aus und sperrt auffällige Adressen zeitweise. CrowdSec erkennt zusätzlich Verhaltensmuster im Webverkehr und arbeitet mit einer gemeinsamen Liste bekannter Angreifer. Eine Adresse, die bei anderen Teilnehmern auffällig geworden ist, wird hier abgewiesen, bevor sie den ersten Versuch machen kann.
Wichtig dabei ist die Nebenwirkung: Eine zu scharfe Regel sperrt auch Berechtigte aus. Deshalb gehört zu diesem Baustein die Frage, wie man sich selbst wieder Zugang verschafft, wenn man versehentlich gesperrt wurde.
3. Überwachung, die den Ausfall vor dem Kunden bemerkt
Für die Erreichbarkeit läuft Uptime Kuma, für Systemwerte wie Auslastung und Plattenplatz Beszel, dazu eine tägliche Systemprüfung, die als Bericht per Mail kommt.
Ein Punkt daran ist wichtiger als die Werkzeugnamen: Eine Überwachung, die nur die Startseite abfragt, erkennt einen Datenbankausfall nicht. Statisches HTML wird weiter mit Erfolg ausgeliefert, während im Hintergrund nichts mehr funktioniert. Deshalb prüft die Überwachung bei uns eine eigens dafür gebaute Adresse, die serverseitig einen echten Zugriff auf Datenbank und Zwischenspeicher auslöst. Erst wenn dieser Zugriff gelingt, meldet die Anwendung sich als gesund.
4. Sicherungen, verschlüsselt und geprüft
Nachts laufen Datenbankauszüge und Archive aller Datenverzeichnisse, anschließend werden sie verschlüsselt und an einen zweiten Standort gespiegelt. Der Zugang für diese Spiegelung ist einseitig: die Gegenstelle darf lesen, sonst nichts.
Dazu gehört der Wiederherstellungstest, der die Sicherung regelmäßig in leere Container zurückspielt und nachzählt. Warum das nicht optional ist, steht ausführlich im Beitrag darüber, warum eine Sicherung erst nach dem Test zählt.
5. Getrennte Netze und begrenzte Ressourcen
Jede Anwendung läuft in eigenen Containern, und die Container sprechen nur über die Netze miteinander, die sie brauchen. Eine öffentlich erreichbare Website hat keinen Weg zur Datenbank eines anderen Kunden, weil dieser Weg gar nicht existiert.
Besondere Vorsicht gilt beim Zugriff auf die Container-Verwaltung selbst. Wer diesen Zugang hat, hat faktisch Verwaltungsrechte auf dem gesamten Server. Deshalb läuft er über einen vorgeschalteten Filter, der nur bestimmte Abfragen durchlässt, und jeder Dienst bekommt nur die Rechte, die er tatsächlich braucht.
Dazu kommen Obergrenzen für Arbeitsspeicher und Prozesse je Anwendung. Ohne sie zieht ein einzelner fehlerhafter Dienst den ganzen Server mit sich.
6. Verwaltungszugang nicht im offenen Netz
Alles, was der Verwaltung dient, ist von außen nicht erreichbar. Der Zugang läuft über ein WireGuard-VPN. Was doch öffentlich erreichbar sein muss, liegt hinter einer vorgeschalteten Anmeldung mit zweitem Faktor über Authelia.
Der Effekt ist unspektakulär und wirksam: Oberflächen, die es im Netz nicht gibt, können auch nicht durchprobiert werden.
Die Blindstelle, die man kennen sollte
Sämtliche Überwachung läuft auf demselben Server, den sie überwacht. Fällt die Maschine vollständig aus, meldet sich niemand, weil auch der Meldeweg weg ist. Das ist eine bekannte Schwäche dieses Aufbaus, und die Lösung ist eine zusätzliche Prüfung von außen, etwa von einem Gerät im eigenen Büro oder über einen fremden Dienst.
Wir schreiben das hin, weil es zur ehrlichen Aufzählung gehört. Wer einen Aufbau beschreibt und keine einzige Schwäche nennt, hat entweder nicht genau hingesehen oder verschweigt etwas.
Brauchst du das alles?
Ehrliche Antwort: nein. Für eine Website, die informiert, keine Anmeldung hat und deren Ausfall über ein Wochenende verkraftbar wäre, ist gutes Webhosting mit automatischen Sicherungen völlig ausreichend, und alles andere ist zu teuer.
Der Aufwand lohnt sich, sobald Anwendungen mit Anmeldung dazukommen, sobald Daten von Kunden verarbeitet werden, oder sobald ein Ausfall den Betrieb spürbar trifft. Dann ist die Frage nicht mehr, ob der Server läuft, sondern wie schnell jemand merkt, dass er es nicht tut.
Wie wir das machen
Wir betreiben diese Bausteine für unsere eigenen Anwendungen und für Kundenprojekte auf derselben Grundlage. Der Vorteil daran ist banal und wirkt trotzdem: Wir merken einen Fehler zuerst an unserem eigenen System. Was im Betrieb enthalten ist, steht unter Managed Hosting und laufender Betrieb.
Was ist der Unterschied zwischen Webhosting und Managed Hosting?
Webhosting stellt Speicherplatz und eine Laufzeitumgebung bereit. Managed Hosting umfasst zusätzlich Betrieb und Verantwortung: Updates, Überwachung, Sicherungen mit Prüfung, Absicherung und eine benannte Reaktionszeit im Störungsfall.
Reicht ein Uptime-Monitor auf der Startseite?
Nein. Eine Startseite kann weiterhin fehlerfrei ausgeliefert werden, während Datenbank oder Zwischenspeicher ausgefallen sind. Nötig ist eine Prüfadresse, die serverseitig einen echten Zugriff auf diese Dienste auslöst.
Warum sollten Verwaltungsoberflächen nicht öffentlich sein?
Weil jede öffentlich erreichbare Anmeldemaske automatisiert durchprobiert wird. Liegt der Zugang hinter einem VPN oder einer vorgeschalteten Anmeldung mit zweitem Faktor, entfällt diese Angriffsfläche vollständig.
Wie viele Anmeldeversuche bekommt eine kleine Website?
Auch eine unbekannte Seite sieht täglich automatisierte Versuche, oft im dreistelligen Bereich. Das sind keine gezielten Angriffe, sondern Programme, die systematisch das gesamte Netz durchgehen.
