Ist VPS-Hosting sicher? Das kontrollieren Sie

Ist VPS-Hosting sicher? Die kurze Antwort

Ja. VPS-Hosting ist für die Aufgaben, für die es die meisten Menschen mieten, sicher und stellt eine deutliche Verbesserung gegenüber Shared Hosting dar. Ein VPS (Virtual Private Server) ist eine virtuelle Maschine mit eigenem Kernel, eigenem Arbeitsspeicher, eigener Festplatte und eigenen Benutzerkonten. Der Hypervisor, auf dem sie ausgeführt wird, hält andere Kunden von allen vier Bereichen fern. Die Person, die auf derselben physischen Maschine den Server neben Ihrem mietet, kann Ihre Dateien nicht lesen, Ihre Prozesse nicht auflisten, sich nicht an Ihrem Server anmelden und Ihren Netzwerkverkehr nicht sehen.

Die ehrliche Antwort besteht aus zwei Teilen. Der Anbieter besitzt die Hardware und den Hypervisor. Sie sind für alles innerhalb Ihrer virtuellen Maschine verantwortlich. Dort beginnen fast alle tatsächlichen Sicherheitsvorfälle. Server werden über einen offenen Port, ein schwaches SSH-Passwort, ein Paket, das niemand aktualisiert hat, oder ein Secret in einer veröffentlichten Datei kompromittiert. Über den Hypervisor werden sie dagegen nur sehr selten kompromittiert.

Was der Hypervisor tatsächlich trennt

Ein Hypervisor ist die Software, die virtuelle Maschinen auf einem physischen Host ausführt. Bei einem KVM-VPS (KVM steht für kernel based virtual machine und ist der Standard auf Linux-Hosts) ist Ihr Server eine vollständige virtuelle Maschine. Er bootet einen eigenen Kernel. Der Host weist ihm einen festen Bereich des physischen Arbeitsspeichers zu. Die Memory Management Unit des Prozessors verweigert jeden Zugriff außerhalb dieses Bereichs. Daher kann Code, der in einem anderen Gast läuft, Ihren Arbeitsspeicher überhaupt nicht adressieren. Es gibt kein gemeinsames Dateisystem und keine gemeinsame Benutzertabelle. Dateiberechtigungen auf dem Server eines Nachbarn haben auf Ihrem Server daher keine Bedeutung.

Shared Hosting funktioniert anders. Viele Websites laufen in einem Betriebssystem, unter einem Webserver und einer PHP-Installation als normale Benutzerkonten. Die einzige Abgrenzung bilden die Dateiberechtigungen. Ein Berechtigungsfehler oder ein verwundbares Plugin, das unter einem Benutzer mit zu weitreichenden Leserechten läuft, kann daher auf die Dateien eines anderen Kontos zugreifen. Diese Lücke schließt der Wechsel von Shared Hosting zu einem VPS.

Prüfen Sie, was Sie kaufen, denn nicht jeder als VPS angebotene Tarif ist eine virtuelle Maschine. Containerbasierte Tarife (OpenVZ, LXC, Virtuozzo) verwenden gemeinsam den Kernel des Hosts und trennen Kunden durch Namespaces und cgroups statt durch Hardwarevirtualisierung. Das ist eine schwächere Grenze, weil eine Kernel-Schwachstelle auf dem Host auch eine Kernel-Schwachstelle in Ihrem Server ist. Außerdem können Sie bei diesen Tarifen keine Kernel-Module laden, wodurch manche Software nicht eingesetzt werden kann. KVM ist die sicherere Standardwahl. Fragen Sie vor dem Kauf, welche Variante Sie erhalten.

Was ein lauter Nachbar bei Ihnen bewirken kann

Das Teilen eines physischen Hosts kostet Sie Geschwindigkeit, und Geschwindigkeit ist der einzige Nachteil. Die Gäste auf einem Rechner teilen sich die physischen CPUs und Datenträger. Wenn die CPU mit einem anderen Gast beschäftigt ist, wartet Ihre virtuelle CPU. Linux weist diese Wartezeit als Steal Time aus: im Feld %st von top und vmstat. Steal Time von mehr als wenigen Prozent über mehrere Stunden bedeutet, dass der Host überbucht ist. Das bedeutet nicht, dass jemand Ihre Daten liest. Die Lösung ist ein anderer Tarif oder ein anderer Anbieter. Bevor Sie sich entscheiden, können Sie die tatsächlich verfügbare CPU- und Datenträgerleistung messen.

Ein Effekt zwischen Kunden ist dennoch wichtig. Er ist keine Sicherheitslücke. Wenn Sie E-Mails von Ihrem VPS versenden, gehört Ihre IP-Adresse zu einem Bereich, den auch andere Kunden verwenden. Ein Nachbar, der Spam versendet, kann dazu führen, dass ein Teil dieses Bereichs auf einer Blocklist landet. Ihre E-Mails werden dann aus einem Grund als Spam eingestuft, den Sie nicht verursacht haben. Anbieter, die Missbrauch konsequent unterbinden, verfügen über sauberere IP-Bereiche. Fragen Sie danach, wenn E-Mail für Sie wichtig ist.

Was ein böswilliger Nachbar nicht tun kann und wann es selten doch möglich ist

Ein Kunde auf demselben Host hat keinen Zugriffspfad zu Ihren Dateien. Er kann Ihre Prozesse nicht sehen, Ihre Festplatte nicht mounten und keine Shell auf Ihrem Server öffnen, weil diese Dinge innerhalb seiner virtuellen Maschine nicht vorhanden sind. Eine Ausnahme sollte ausdrücklich genannt werden: Betrachten Sie jedes private Netzwerk des Providers als ein Netzwerk, das Sie mit Fremden teilen. Verschlüsseln Sie Daten, die darüber übertragen werden, statt anzunehmen, dass sie unsichtbar sind.

Hypervisor-Escapes sind real. Ein Fehler in der Virtualisierungsschicht kann Code innerhalb eines Gasts den Zugriff auf den Host ermöglichen. Vom Host aus kann der Code anschließend jeden darauf ausgeführten Gast erreichen. Solche Fehler werden gefunden, mit einem CVE- (Common Vulnerabilities and Exposures-)Identifier veröffentlicht und behoben. Hosting-Provider patchen sie schnell, weil ihr gesamtes Geschäft auf dieser Schicht basiert. Die Ausnutzung erfordert einen funktionierenden Exploit für eine bestimmte Hypervisor-Version. Für ein kleines Hosting-Konto ist das ein unverhältnismäßig teurer Exploit.

Side-Channel-Angriffe zwischen Gästen sind ebenfalls real. Dazu gehören die Spectre- und Meltdown-Familie. Sie missbrauchen gemeinsam genutzte Prozessor-Caches, um geringe Datenmengen über eine Grenze hinweg abzuleiten. Microcode- und Kernel-Updates mindern das Risiko. Die in veröffentlichten Arbeiten beschriebenen Leckraten sind sehr gering. Die veröffentlichten Fälle sind Forschungsdemonstrationen und keine Massenangriffe. Das Risiko ist nicht null. Es steht jedoch bei Weitem nicht an der Spitze der Risiken, die Ihnen schaden werden.

Wo die Aufgabe des Providers endet und Ihre beginnt

Der Provider ist für das Gebäude, die Host-Hardware, den Hypervisor und den Host-Kernel, das physische Netzwerk sowie das Control Panel verantwortlich, mit dem Ihr Server gestartet, gestoppt, neu erstellt und als Snapshot gesichert werden kann. Wenn eine dieser Komponenten ausfällt, muss der Provider den Fehler beheben.

Sie sind für alles ab Ihrem Betriebssystem aufwärts verantwortlich. Dazu gehören die installierten Pakete, die offenen Ports, die Konten und kryptografischen Schlüssel, mit denen eine Anmeldung möglich ist, die von Ihnen eingespielten Updates, Ihre Backups und Ihr eigener Anwendungscode. Die meisten VPS-Tarife sind unmanaged. Das bedeutet, dass niemand Ihren Server für Sie patcht und auch kein Support-Ticket diese Aufgabe übernimmt. Die Aufteilung in managed und unmanaged sollten Sie vor dem Kauf lesen, weil sie festlegt, welcher Teil dieser Aufgaben bei Ihnen liegt.

Ein Teil Ihrer Verantwortung wird leicht übersehen: das Hosting-Control-Panel selbst. Wer über die Zugangsdaten verfügt, kann Ihren Server neu erstellen oder Ihre Festplatte an ein Rescue-System anhängen, ohne ein Passwort aus dem Server zu kennen. Aktivieren Sie die Zwei-Faktor-Authentifizierung (2FA) für das Hosting-Konto und verwenden Sie dieses Passwort nirgendwo sonst.

Kann Ihr Hosting-Provider Ihre Daten sehen?

Ja, grundsätzlich ist das möglich. Das ist die ehrliche Einschränkung eines VPS. Ihr Disk-Image liegt auf dem Speicher des Providers. Über dessen Konsole kann er auf Bildschirmebene auf Ihre virtuelle Maschine zugreifen. Im Rescue-Modus kann ein anderes System mit Ihrem eingebundenen Datenträger gestartet werden. Ein VPS schützt Sie vor anderen Kunden. Der Provider ist von diesem Schutz ausgenommen.

Wenn Daten für den Host unlesbar bleiben müssen, verschlüsseln Sie sie in Ihrer Anwendung, bevor sie geschrieben werden. Eine vollständige Datenträgerverschlüsselung innerhalb des Gasts schützt vor einem kopierten Image im Ruhezustand. Der Schlüssel muss jedoch im laufenden Server im Arbeitsspeicher liegen. Dadurch bleibt der Provider weiterhin im Vertrauensbereich. Dasselbe Vertrauen gilt für einen dedizierten Server, den Sie allein mieten, allerdings mit einer gemeinsam genutzten Ebene weniger.

Was tatsächlich in einen VPS einbricht

Ein Dienst, der auf allen Schnittstellen lauscht. Datenbanken, Caches, Message Queues und Administrationsoberflächen binden standardmäßig häufig an 0.0.0.0. Dadurch sind sie über jede Netzwerkschnittstelle erreichbar, einschließlich der öffentlichen Schnittstelle. Scans des gesamten Internets laufen dauerhaft automatisiert. Eine neue IP-Adresse erhält daher meist innerhalb weniger Minuten nach ihrer Aktivierung die erste unerwartete Anfrage. Ein Redis ohne Passwort, ein nicht authentifizierter Elasticsearch-Knoten, eine offene Docker API auf Port 2375 und eine Administrationsoberfläche mit den Standardanmeldedaten werden auf diese Weise gefunden. Der Scanner weiß nicht, wer Sie sind. Binden Sie einen Dienst an 127.0.0.1, wenn ihn nur der lokale Rechner benötigt. Blockieren Sie den Zugriff auf den Dienst zusätzlich mit der Firewall.

Docker umgeht Ihre Firewall. Durch die Veröffentlichung eines Container-Ports werden Regeln für Network Address Translation (NAT) angelegt. Diese werden vor den Regeln von ufw (uncomplicated firewall) ausgewertet. Ein Container kann daher aus dem Internet erreichbar sein, obwohl ufw status angibt, dass der Port abgelehnt wird. Das betrifft auch Benutzer, die alle anderen Einstellungen korrekt vorgenommen haben. Warum ein Docker-Port ufw ignoriert sollten Sie lesen, bevor Sie einen Container-Port veröffentlichen.

SSH mit aktivierten Passwörtern. Wenn Sie /var/log/auth.log auf einem öffentlichen Server lesen, finden Sie dort Einträge wie Failed password for root from 203.0.113.10 port 54312 ssh2, und zwar Tag und Nacht zu Tausenden. Bots probieren gängige Benutzernamen und Passwörter durch. Eine Anmeldung per Passwort zusammen mit einem root-Konto, das Anmeldungen akzeptiert, reicht einem Angreifer aus. Verwenden Sie ausschließlich Schlüssel und deaktivieren Sie die root-Anmeldung. Dann können Sie diesen Netzwerkverkehr ignorieren.

Ein privater Schlüssel für alle Systeme. Wenn ein einzelner Schlüssel auf jeden Laptop und jeden Server kopiert wurde, kann ein gestohlener Laptop auf alles zugreifen. SSH-Schlüssel laufen außerdem nicht ab. Ein Schlüssel, den Sie einem Auftragnehmer vor zwei Jahren gegeben haben, funktioniert daher heute noch. Ein Schlüssel pro Person und pro Rechner kostet nichts und begrenzt, auf welche Systeme ein einzelner gestohlener Schlüssel zugreifen kann.

Pakete, die niemand aktualisiert. Ein veröffentlichter CVE für Ihren Webserver oder Ihr Anwendungsframework enthält öffentlich verfügbare Anweisungen zur Ausnutzung der Schwachstelle. Scanner beginnen innerhalb weniger Tage mit entsprechenden Tests. Sicherheitsupdates sind die kostengünstigste verfügbare Schutzmaßnahme. Sie können automatisch installiert werden: siehe automatische Sicherheitsupdates unter Ubuntu.

Ein offengelegtes Geheimnis. Datenbankpasswörter und API-Schlüssel befinden sich in Dateien wie .env. Solche Dateien werden in ein öffentliches Repository übertragen oder von einem Webserver ausgeliefert, der auf das falsche Verzeichnis zeigt. Alles, was Sie in den Kontext eines KI-Programmierassistenten einfügen, kann ebenfalls in einem Log landen. Das ist ein eigenes Thema: Geheimnisse außerhalb der Reichweite eines Agenten halten.

Alles läuft als root. Wenn Ihre Anwendung als root läuft, kontrolliert ein einziger Fehler darin den gesamten Rechner. Innerhalb des Servers gibt es dann keine Grenze mehr, die eine weitere Ausbreitung verhindert.

Ihre Aufgaben

Nichts davon gehört zur Arbeit am Hypervisor. Alles liegt in Ihrem Zuständigkeitsbereich. Dieser Bereich entscheidet, ob Ihr VPS sicher ist.

• Erledigen Sie die erste Stunde sorgfältig: die ersten zehn Minuten auf einem neuen VPS behandeln einen Benutzer ohne root-Rechte und eine Firewall.
• Sichern Sie den Fernzugriff ab: SSH auf einem VPS härten.
• Schließen Sie nicht verwendete Ports: Grundlagen der ufw-Firewall.
• Geben Sie jedem Dienst nur die benötigten Zugriffsrechte: Benutzer mit geringsten Rechten auf einem VPS.
• Bremsen Sie Brute-Force-Anmeldungen: fail2ban auf Ubuntu 24.04.
• Halten Sie ein Backup vor, das Sie mindestens einmal wiederhergestellt haben: restic-Backups für einen VPS.

Die Aufgaben des Anbieters sind bereits erledigt, wenn Ihr Server startet. Ihre Aufgaben dauern am ersten Tag etwa eine Stunde und danach wenige Minuten pro Monat. Wenn Sie noch Optionen vergleichen, erklärt was ein VPS tatsächlich ist die Grundlagen für alles Weitere.

FAQ

Kann ein anderer Kunde auf demselben physischen Server meine Dateien lesen?

Nein, nicht bei einem KVM-VPS. Ihr Server ist eine virtuelle Maschine mit eigenem Kernel und eigener virtueller Festplatte sowie einem Bereich des physischen Arbeitsspeichers, den der Host ihm zuweist. Der Prozessor verhindert Zugriffe außerhalb dieses Bereichs. Zwischen den Gästen gibt es kein gemeinsames Dateisystem. Daher haben Dateiberechtigungen auf dem Server eines Nachbarn innerhalb Ihres Servers keine Bedeutung. Containerbasierte Angebote wie OpenVZ und LXC verwenden den Kernel des Hosts gemeinsam und bieten daher eine schwächere Isolation. Prüfen Sie deshalb, welchen Typ Sie buchen.

Ist ein VPS sicherer als Shared Hosting?

Für die Isolation: ja. Beim Shared Hosting laufen viele Websites in einem Betriebssystem, und die einzige Grenze bilden Dateiberechtigungen. Daher kann ein Fehler in einem anderen Konto manchmal Dateien offenlegen. Bei einem VPS bildet die virtuelle Maschine die Grenze. Der Nachteil ist, dass der Hoster beim Shared Hosting die Updates einspielt, während Sie ein nicht verwaltetes VPS selbst aktualisieren müssen. Ein VPS ist nur dann sicherer, wenn Sie die Updates tatsächlich installieren und die Ports schließen.

Kann mein Hostinganbieter meine Daten lesen?

Grundsätzlich ja. Kein VPS-Produkt ändert daran etwas. Das Festplatten-Image wird auf der Hardware des Anbieters gespeichert. Die Konsole ermöglicht den Zugriff auf die Bildschirmausgabe der laufenden Maschine. Im Rescue-Modus kann ein anderes System mit Ihrer eingebundenen Festplatte gestartet werden. Wenn bestimmte Daten für den Host unlesbar bleiben müssen, verschlüsseln Sie sie in Ihrer Anwendung, bevor Sie sie schreiben. Eine Festplattenverschlüsselung innerhalb des Gasts hält den Schlüssel während des Betriebs weiterhin im Arbeitsspeicher. Sie entfernt den Anbieter daher nicht aus dem Vertrauensmodell.

Wie wird ein VPS am häufigsten kompromittiert?

Mit großem Abstand durch einen erreichbaren Dienst oder einen schwachen SSH-Login. Automatisierte Scanner prüfen kontinuierlich jede öffentliche IP-Adresse. Eine Datenbank, die ohne Passwort an 0.0.0.0 gebunden ist, oder ein Administrationspanel mit den Standard-Zugangsdaten wird daher innerhalb von Minuten statt Monaten gefunden. /var/log/auth.log auf einem öffentlichen Server zeigt die SSH-Seite dieses Problems: wiederholte Failed password for root-Zeilen von Adressen aus aller Welt. Hypervisor-Escapes gibt es, aber dabei handelt es sich um Forschung auf hohem Niveau, die sich gegen besonders wertvolle Ziele richtet. Sie sind nicht die Ursache gewöhnlicher Sicherheitsverletzungen.