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 KVM-VPS (virtueller privater 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 diesen vier Bereichen fern. Die Person, die den Server neben Ihrem auf derselben physischen Maschine mietet, kann Ihre Dateien nicht lesen, Ihre Prozesse nicht auflisten, sich nicht an Ihrem Server anmelden und Ihren Netzwerkverkehr nicht sehen. Containerbasierte Tarife bieten eine schwächere Trennung, wie weiter unten beschrieben.

Die vollständige Antwort besteht aus zwei Teilen. Der Anbieter besitzt die Hardware und den Hypervisor. Sie sind für alles innerhalb Ihrer virtuellen Maschine verantwortlich. Dort beginnt fast jeder tatsächliche Sicherheitsvorfall. Server werden durch einen offenen Port, ein schwaches SSH-Passwort, ein Paket, das niemand aktualisiert hat, oder ein Geheimnis in einer veröffentlichten Datei kompromittiert. Eine Kompromittierung über den Hypervisor kommt dagegen sehr selten vor.

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 Admin-Oberflächen binden standardmäßig häufig an 0.0.0.0. Das bedeutet: an jede Netzwerkschnittstelle, einschließlich der öffentlichen. Das Scannen des IPv4-Adressraums aus dem Internet läuft ständig und automatisiert. Eine neue IPv4-Adresse erhält daher innerhalb weniger Minuten nach ihrer Aktivierung die erste unaufgeforderte Anfrage. Der IPv6-Adressraum ist zu groß, um ihn Adresse für Adresse zu durchsuchen. Eine IPv6-Adresse kann jedoch über DNS-Einträge und andere Datenlecks gefunden werden. Betrachten Sie sie daher nicht als verborgen. Ein Redis ohne Passwort, ein nicht authentifizierter Elasticsearch-Knoten, eine offene Docker API auf Port 2375 und eine Admin-Oberfläche mit den Standardanmeldedaten werden auf diese Weise gefunden. Der Scanner weiß dabei nicht, wer Sie sind. Binden Sie einen Dienst an 127.0.0.1, wenn ihn nur der lokale Rechner benötigt, und blockieren Sie den restlichen Zugriff mit der Firewall.

Docker umgeht Ihre Firewall. Durch das Veröffentlichen eines Container-Ports werden Network Address Translation (NAT)-Regeln geschrieben. Diese werden vor den Regeln von ufw (uncomplicated firewall) ausgewertet. Dadurch kann ein Container aus dem Internet erreichbar sein, obwohl ufw status angibt, dass dieser Port abgewiesen wird. Das überrascht auch Personen, die alle anderen Maßnahmen korrekt umgesetzt haben. Warum ein Docker-Port ufw ignoriert sollten Sie lesen, bevor Sie einen Container-Port veröffentlichen.

SSH mit aktivierter Passwortanmeldung. Lesen Sie auf jedem Server mit einer öffentlichen IPv4-Adresse das SSH-Log (/var/log/auth.log unter Ubuntu, /var/log/secure unter Rocky Linux und anderen Systemen der RHEL-Familie oder journalctl -u ssh und journalctl -u sshd, wenn keine Logdatei geführt wird). Dort finden Sie Zeilen wie Failed password for root from 203.0.113.10 port 54312 ssh2, und zwar Tausende davon, Tag und Nacht. Bots probieren gängige Benutzernamen und Passwörter durch. Eine aktivierte Passwortanmeldung zusammen mit einem root-Konto, das Anmeldungen akzeptiert, reicht einem Angreifer aus. Wenn nur Schlüssel zulässig sind und die root-Anmeldung deaktiviert ist, wird dieser Datenverkehr zu Rauschen, das Sie ignorieren können.

Ein privater Schlüssel, der überall verwendet wird. Ein einzelner Schlüssel, der auf jedes Notebook und jeden Server kopiert wurde, bedeutet: Ein gestohlenes Notebook öffnet den Zugang zu allem. SSH-Schlüssel laufen außerdem nicht ab. Ein Schlüssel, den Sie vor zwei Jahren an einen Auftragnehmer übergeben haben, funktioniert daher noch heute. Ein Schlüssel pro Person und Gerät kostet nichts und begrenzt, auf welche Systeme mit einem einzelnen gestohlenen Schlüssel zugegriffen werden kann.

Pakete, die niemand aktualisiert. Ein veröffentlichtes CVE für Ihren Webserver oder Ihr Anwendungsframework ist eine öffentlich verfügbare Anleitung. Scanner beginnen innerhalb weniger Tage, gezielt danach zu suchen. Sicherheitsupdates sind die günstigste verfügbare Schutzmaßnahme und können automatisch ausgeführt werden: siehe automatische Sicherheitsupdates unter Ubuntu.

Ein durchgesickertes Geheimnis. Datenbankpasswörter und API-Schlüssel befinden sich in .env-Dateien. Diese 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-Coding-Agenten 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 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 auf einem KVM VPS. Ihr Server ist eine virtuelle Maschine mit einem eigenen Kernel und einer eigenen virtuellen Festplatte sowie einem Bereich des physischen Speichers, den der Host ihm zuweist. Der Prozessor verhindert jeden Zugriff außerhalb dieses Bereichs. Zwischen den Gastsystemen gibt es kein gemeinsam genutztes Dateisystem. Daher haben Dateiberechtigungen auf dem Server eines Nachbarn innerhalb Ihres Servers keine Bedeutung. Containerbasierte Tarife wie OpenVZ und LXC verwenden gemeinsam den Kernel des Hosts und bieten eine schwächere Isolierung. Prüfen Sie daher, welchen Typ Sie buchen.

Ist ein VPS sicherer als Shared Hosting?

Für die Isolierung: ja. Beim Shared Hosting laufen viele Websites innerhalb eines Betriebssystems. Die einzige Grenze bilden Dateiberechtigungen. Ein Fehler in einem anderen Konto kann daher unter Umständen Dateien offenlegen. Bei einem VPS bildet die virtuelle Maschine die Grenze. Der Nachteil ist, dass der Host beim Shared Hosting die Updates einspielt, während Sie sie bei einem nicht verwalteten VPS selbst einspielen müssen. Ein VPS ist nur dann sicherer, wenn Sie die Updates tatsächlich installieren und die Ports schließen.

Kann mein Hosting-Anbieter meine Daten lesen?

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

Wie wird ein VPS am häufigsten kompromittiert?

Mit großem Abstand durch einen exponierten Dienst oder eine schwache SSH-Anmeldung. Automatisierte Scanner prüfen kontinuierlich jede öffentliche IPv4-Adresse. Eine Datenbank, die ohne Passwort an 0.0.0.0 gebunden ist, oder ein Administrationsbereich mit den Standardzugangsdaten wird daher innerhalb von Minuten statt Monaten gefunden. Das SSH-Log auf jedem Server mit einer öffentlichen IPv4-Adresse (/var/log/auth.log auf Ubuntu, /var/log/secure auf Rocky Linux) zeigt den SSH-Anteil: Wiederholte Failed password for root-Zeilen von Adressen aus aller Welt. Hypervisor-Escapes gibt es, aber sie gehören zur Sicherheitsforschung und richten sich gegen hochwertige Ziele. Sie sind nicht die Ursache gewöhnlicher Einbrüche.