Die Verwaltung von Kundenwebsites in großem Maßstab erfordert ein Sicherheitsdenken in der Infrastruktur, das über die einfache Installation von Sicherheitsplugins oder das Erzwingen von sicheren Passwörtern hinausgeht.
Wenn du Dutzende oder Hunderte von WordPress-Websites hostest, wird die Hosting-Architektur zu einem Sicherheitsaspekt, der entweder dein gesamtes Portfolio schützen oder gefährden kann.
Traditionelles Shared Hosting hält die Kosten niedrig, bedeutet aber auch, dass die Websites dasselbe Dateisystem, denselben Prozessraum und denselben Netzwerkstack nutzen. Wenn also eine Website auf einem gemeinsam genutzten Server kompromittiert wird, kann sich die Malware auf andere Websites ausbreiten.
Die versteckten Sicherheitsrisiken von Shared Hosting-Umgebungen
Jede Website auf einem Shared Hosting Server nutzt einen Teil der CPU, des RAM und des Speichers des Servers. Das ist für Hosting-Anbieter aus Kostensicht sinnvoll und hält die Preise für die Kunden erschwinglich.
Aus der Sicherheitsperspektive gibt es jedoch Schwachstellen, die mit der Anzahl der von dir verwalteten Websites wachsen. Das Hauptproblem liegt in der gemeinsamen Nutzung von Ressourcen. Dateiberechtigungen und Benutzerisolierung können einen gewissen Schutz bieten, aber das sind Kontrollen auf Softwareebene, die ausgenutzt werden können. Schließlich sind Phishing-Angriffe, Malware und Ransomware nach wie vor die größten Bedrohungen für jede Website.
Das Verständnis von „lateraler Ausbreitung“ und „Kreuzkontamination“ kann helfen, die Risiken zu verdeutlichen:
- Laterale Ausbreitung bedeutet, dass Malware von einem kompromittierten System auf andere Systeme im selben Netzwerk oder in derselben Umgebung übertragen wird.
- Eine Kreuzkontamination liegt vor, wenn sich ein Sicherheitsproblem, das eine Website betrifft, auf andere Websites ausbreitet, die dieselbe Infrastruktur nutzen.
Wenn du Kundenportfolios verwaltest, kann es attraktiv sein, mit Shared Hosting Geld zu sparen. Ein veraltetes Plugin oder ein schwaches Passwort eines einzelnen Kunden kann jedoch eine Bedrohung für dein gesamtes Hosting-System darstellen.
Wenn du die Zeit einrechnest, die du für die Überwachung von Bedrohungen und die Behebung von Sicherheitsvorfällen auf mehreren Websites benötigst, sinkt der Wert.
Wie sich Malware zwischen Websites auf gemeinsam genutzten Servern ausbreitet
Die genaue Art der seitenübergreifenden Kontamination hängt davon ab, wie der Hosting-Anbieter die Benutzertrennung und die Dateiberechtigungen implementiert. Dennoch bleibt das Grundproblem bei den meisten Shared-Hosting-Konfigurationen gleich: Diese Umgebungen schaffen Angriffsflächen, über die kompromittierte Konten durch falsch konfigurierte Berechtigungen oder anfällige Skripte auf die Dateien anderer Nutzer zugreifen können.
Zu den Übertragungswegen für eine Cross-Site-Infektion gehören:
- PHP-Skripte lesen Dateien aus anderen Benutzerverzeichnissen, wenn die Berechtigungen falsch konfiguriert sind.
- Gemeinsame temporäre Verzeichnisse ermöglichen die Verbreitung von Malware zwischen Websites.
- Schwachstellen auf Serverebene ermöglichen es, dass Prozesse von einer Website auf andere übergreifen.
- Kompromittierte Benutzerkonten erhalten über gemeinsam genutzte Ressourcenpools Zugriff auf benachbarte Verzeichnisse.
Der Kinsta-Kunde Bookswarm entdeckte dieses Problem, als er Hunderte von Kundenwebsites auf einer gemeinsamen Hosting-Plattform verwaltete. Das Unternehmen stellte fest, dass die gemischte Serverkonfiguration nicht nur Sicherheitsprobleme verursachte, sondern auch die einzelnen Websites gefährdete. Die Architektur bedeutete, dass „ein Angriff auf eine Website einem Angriff auf andere Websites gleichkam“.
Dies führt auch zu einer Belastung für den Betrieb, da eine ständige Überwachung erforderlich ist, um Angriffe zu erkennen, bevor sie sich ausbreiten. Wenn eine Website Anzeichen einer Infektion aufweist, muss man jede andere Website auf demselben Server überprüfen. Die Reaktion auf einen Vorfall wird zu einer Übung für das gesamte Portfolio und nicht zu einer isolierten Lösung.
Das Problem der Kontamination durch schwarze Listen
Gemeinsam genutzte IP-Adressen schaffen eine weitere Risikoebene im traditionellen Shared Hosting. Wenn sich mehrere Websites dieselbe IP-Adresse teilen, haben sie in den Augen von E-Mail-Anbietern, Suchmaschinen und Sicherheitsdiensten auch denselben Ruf.
Da eine einzige Kompromittierung dazu führen kann, dass die gesamte IP-Adresse auf eine schwarze Liste gesetzt wird, leidet jede Website mit dieser IP unter mehreren kaskadenartigen Problemen:
- Die Zustellbarkeit von E-Mails sinkt für dein gesamtes Portfolio, wenn eine kompromittierte Website Spamfilter wie Spamhaus auslöst.
- Suchmaschinen stufen die gemeinsam genutzte IP als verdächtig ein, was sich negativ auf die Platzierungen aller zugehörigen Websites auswirkt.
- Sicherheitsdienste und Firewalls blockieren Anfragen von der IP und unterbrechen die Funktionalität von Websites, die nichts mit der ursprünglichen Kompromittierung zu tun haben.
- Kunden-Websites verlieren Vertrauensindikatoren, wenn Sicherheitstools die gemeinsame IP mit bösartigen Aktivitäten in Verbindung bringen.
Der Wiederherstellungsprozess nach einer IP-Blacklist erfordert ein koordiniertes Vorgehen mit deinem Hosting-Provider. Du musst herausfinden, welche Website das Problem verursacht hat, sie bereinigen und dann die Löschung aus verschiedenen Blacklists beantragen. Während dieses Prozesses sind alle Websites auf der gemeinsamen IP weiterhin von den Folgen betroffen.
In der Zwischenzeit musst du deinen Kunden erklären, warum ihre E-Mails nicht mehr funktionieren oder warum ihre Website markiert wurde, obwohl sie optimale WordPress-Sicherheitspraktiken angewendet haben. Die Ursache dafür liegt in Infrastrukturentscheidungen, auf die der einzelne Websitebetreiber keinen Einfluss hat. Die ganze laufende Wartung kostet Zeit, die dann für Kundenarbeit und Entwicklungsprojekte fehlt.
Isolierung auf Containerebene für WordPress-Hosting
Die Isolierung von Websites löst viele der grundlegenden Probleme des Shared Hosting. Bei Kinsta wird zum Beispiel jede Website in einem eigenen isolierten Container mit eigenen Ressourcen betrieben. Das bedeutet, dass jede WordPress-Website ihren eigenen Container zugewiesen bekommt, der alles enthält, was zum Betrieb benötigt wird: Linux, NGINX, PHP und MySQL.
Die Isolierung erfolgt auf der Ebene des Betriebssystems durch zwei zentrale Mechanismen:
- Namespaces bieten jedem Container eine eigene Sicht auf die Systemressourcen. Ein Prozess, der in einem Container läuft, kann Prozesse in einem anderen Container weder sehen noch mit ihnen interagieren.
- Kontrollgruppen („cgroups“) sorgen für die Begrenzung der Ressourcen und stellen sicher, dass jeder Container Zugriff auf seine eigene CPU- und RAM-Zuweisung hat.
Außerdem können die PHP-Threads deiner WordPress-Website die Prozesse anderer Websites weder sehen noch mit ihnen interagieren. Diese Trennung auf Kernel-Ebene verhindert Szenarien, in denen ein kompromittierter Prozess einer Website versucht, auf Ressourcen anderer Websites zuzugreifen.
Auch die Netzwerkstacks arbeiten in jedem Container unabhängig voneinander. Jede Website hat seine eigene Netzwerkschnittstelle und IP-Verarbeitung. Diese Isolierung erstreckt sich über den gesamten Stack und beseitigt das Problem der lärmenden Nachbarn, das beim Shared Hosting auftritt.
Wenn eine Website eine Verkehrsspitze erfährt oder ressourcenintensive Operationen durchführt, wirkt sich das nur auf den Container dieser Website aus. Die dedizierte Ressourcenzuweisung bedeutet, dass andere Website weiterhin mit ihrer vollen Zuweisung arbeiten, unabhängig davon, was an anderer Stelle in der Infrastruktur passiert.
Wie Container-Isolierung die laterale Ausbreitung von Malware verhindert
Wenn eine Website in einer containerisierten Umgebung kompromittiert wird, bleibt die Malware auf diesen Container beschränkt. Diese Trennung verhindert, dass kompromittierte Prozesse durch verschiedene Mechanismen auf andere Container zugreifen können:
- Die Dateisysteme bleiben isoliert, so dass sich Malware nicht durch die Ausnutzung gemeinsam genutzter Verzeichnisse oder temporärer Dateien verbreiten kann.
- Prozess-Namensräume verhindern, dass bösartiger Code Prozesse in anderen Containern scannt oder mit ihnen interagiert.
- Die Netzwerkisolierung schränkt die Fähigkeit kompromittierter Websites ein, benachbarte Websites zu scannen oder anzugreifen.
- Die Speicherbereiche bleiben vollständig voneinander getrennt, damit Pufferüberlauf-Angriffe nicht die Containergrenzen überschreiten können.
Wenn die Website auf Kinsta gehostet wird, können unsere Überwachungssysteme den kompromittierten Container sofort erkennen und reagieren, während die anderen Websites in deinem Portfolio weiterarbeiten.
Überprüfung tatsächlicher Isolierung im Vergleich zu den Marketingaussagen
Nicht alle Hosting-Anbieter setzen die Container-Isolierung auf die gleiche Weise um. Einige verwenden den Begriff „isoliert“, um eine weiche Begrenzung der Ressourcennutzung zu beschreiben, während gleichzeitig mehrere Websites in gemeinsamen Umgebungen betrieben werden. Wenn du weißt, was eine echte Isolierung auf Containerebene ist, kannst du deine Hosting-Optionen besser einschätzen und die Sicherheitsrisiken vermeiden, die durch irreführendes Marketing entstehen.
Echte Container-Isolation bedeutet, dass jede Website in ihrem eigenen Betriebssystem-Namensraum mit eigenen Ressourcen läuft, auf die andere Websites nicht zugreifen können. Wenn du auf der Suche nach einem neuen Hosting-Anbieter bist, gibt es ein paar Punkte, auf die du achten solltest:
- Bekommt jede Website ihren eigenen Container mit dedizierten CPU- und RAM-Zuweisungen, auf die andere Websites nicht zugreifen können?
- Sind die Dateisysteme auf der Kernel-Ebene vollständig getrennt, indem Namespaces und nicht nur Berechtigungen auf Benutzerebene verwendet werden?
- Was passiert mit den anderen Websites, wenn ein Container kompromittiert wird oder eine Verkehrsspitze auftritt?
- Welche Containerisierungstechnologie verwendet der Anbieter (LXC, LXD, Docker) und wie wird die Isolierung durchgesetzt?
- Kann der Anbieter eine technische Dokumentation über seine Isolationsmechanismen und Architektur vorlegen?
Der Unterschied zwischen Soft Limits und Hard Isolation ist sowohl für die Sicherheit als auch für die Leistung wichtig. Soft Limits können die CPU-Leistung einer Website begrenzen, aber sie funktionieren in einer gemeinsamen Umgebung, in der die Prozesse einer Website weiterhin mit anderen interagieren können. Harte Isolierung mit dedizierten Ressourcen bedeutet, dass jede Website in einer völlig separaten Umgebung arbeitet, in der benachbarte Websites weder auf ihre Ressourcen zugreifen noch von ihren Aktivitäten beeinflusst werden können.
Technische Überprüfungsmethoden
Wenn du nach technischen Spezifikationen suchst, in denen die Containerisierungstechnologie detailliert beschrieben ist, kannst du herausfinden, inwieweit ein Anbieter über die zugrunde liegende Architektur informiert ist. Anbieter, die LXC, LXD, Docker oder ähnliche Technologien verwenden, sollten zum Beispiel in der Lage sein, die spezifischen Isolationsmechanismen zu beschreiben, die sie implementieren.
Konformitätszertifizierungen wie SOC 2 Typ II und ISO 27001 zeigen, dass die Sicherheitspraktiken von unabhängigen Stellen geprüft wurden. Diese Zertifizierungen erfordern dokumentierte Sicherheitskontrollen und regelmäßige Tests, die mehr Sicherheit bieten als Marketingaussagen allein. Kinsta verfügt über beide Zertifizierungen und unterzieht sich regelmäßigen Audits, um zu überprüfen, ob die Isolationsmechanismen wie angekündigt funktionieren.
Wenn du den Hoster während eines Testzeitraums nutzen kannst, kannst du auch auf verschiedene Weise überprüfen, wie die Isolierung funktioniert, z. B. indem du den Ressourcenverbrauch mehrerer Websites auf demselben Server überwachst oder dir ansiehst, was bei CPU-intensiven Operationen einer einzelnen Website passiert.
Bei Kinsta kannst du diese Art von praktischer Überprüfung im ersten Monat kostenlos durchführen.
Verstehen, was Website Isolation für deine Hosting-Strategie bedeutet
Der Wechsel von Shared Hosting zu einer isolierten Container-Architektur kann die grundlegende Sicherheitslage deines gesamten WordPress-Portfolios und sogar die Art und Weise, wie du das Infrastrukturmanagement im großen Maßstab angehst, zum Besseren wenden.
Bei mehreren Kunden-Websites auf Shared Hosting ist die Wahrscheinlichkeit, dass es auf mindestens einer Website zu einem Sicherheitsvorfall kommt, so gut wie sicher. Die eigentliche Frage ist, ob dieser Vorfall auf eine einzige Website beschränkt bleibt oder zu kaskadenartigen Problemen in deinem gesamten Portfolio führt.
Für Agenturen und Teams, die viele WordPress-Websites verwalten, ist das Hosting letztlich eine Risikoentscheidung auf Portfolioebene. Wenn du auf der Suche nach einer Infrastruktur bist, die speziell für die Verwaltung von Websites in großem Umfang entwickelt wurde, bietet dir Kinsta Lösungen, die speziell auf Agenturen und WordPress-Umgebungen mit hohem Volumen zugeschnitten sind.
Joel ist Frontend-Entwickler und arbeitet bei Kinsta als Technical Editor. Er ist ein leidenschaftlicher Lehrer mit einer Vorliebe für Open Source und hat über 200 technische Artikel geschrieben, die sich hauptsächlich um JavaScript und seine Frameworks drehen.
