Is VPS-hosting veilig? Alles wat u moet weten

Is VPS-hosting veilig? Het korte antwoord

Ja. VPS-hosting is veilig voor de doeleinden waarvoor de meeste mensen het aanschaffen, en het is een duidelijke verbetering ten opzichte van shared hosting. Een VPS (virtual private server) is een virtuele machine met een eigen kernel, eigen geheugen, eigen schijfruimte en eigen gebruikersaccounts. De hypervisor die de machine draait, schermt deze vier onderdelen af van andere klanten. De persoon die de server naast de uwe op dezelfde fysieke machine huurt, kan uw bestanden niet lezen, uw processen niet inzien, niet inloggen op uw server en uw netwerkverkeer niet bekijken.

Het eerlijke antwoord bestaat uit twee delen. De provider is eigenaar van de hardware en de hypervisor. U bent eigenaar van alles binnen uw virtuele machine, en daar begint bijna elk daadwerkelijk incident. Servers worden gecompromitteerd via een open poort, een zwak SSH-wachtwoord, een pakket dat niet is bijgewerkt of een geheim in een bestand dat per ongeluk is gepubliceerd. Het komt zeer zelden voor dat er wordt ingebroken via de hypervisor.

Wat de hypervisor daadwerkelijk scheidt

Een hypervisor is de software die virtuele machines op één fysieke host uitvoert. Op een KVM VPS (KVM staat voor kernel based virtual machine, de standaard op Linux-hosts) is uw server een volledige virtuele machine. Deze start zijn eigen kernel op. De host wijst een vast gebied van het fysieke geheugen toe, en de memory management unit van de processor weigert elke toegang buiten dat gebied; code die in een andere guest draait, kan uw RAM dus op geen enkele wijze adresseren. Er is geen gedeeld bestandssysteem en geen gedeelde gebruikerstabel, waardoor bestandsrechten op de server van een buurman geen enkele invloed hebben op die van u.

Shared hosting werkt anders. Veel websites bevinden zich binnen één besturingssysteem, onder één webserver en één PHP-installatie, als gewone gebruikersaccounts. De enige grens wordt gevormd door bestandsrechten. Een fout in de rechten, of een kwetsbare plugin die draait als een gebruiker die te veel kan lezen, kan daarom de bestanden van een ander account bereiken. Dat is het gat dat de overstap van shared hosting naar een VPS dicht.

Controleer wat u koopt, want niet elk abonnement dat als VPS wordt verkocht, is een virtuele machine. Container-gebaseerde abonnementen (OpenVZ, LXC, Virtuozzo) delen de kernel van de host en scheiden klanten met namespaces en cgroups in plaats van hardware-virtualisatie. Dat is een zwakkere grens, omdat een kernel-bug op de host ook een kernel-bug in uw server is. U kunt op die abonnementen ook geen kernel-modules laden, wat bepaalde software uitsluit. KVM is de veiligere standaard. Vraag welke variant u krijgt voordat u betaalt.

Wat een 'noisy neighbour' voor u kan betekenen

Het delen van een fysieke host kost u snelheid, en dat is het enige dat het kost. De gasten op één machine delen de fysieke CPU en de schijven. Wanneer de CPU bezig is met een andere gebruiker, wacht uw virtuele CPU, en Linux rapporteert dit wachten als steal time: het %st-veld in top en vmstat. Steal time die urenlang boven een paar procent uitkomt, betekent dat de host overbezet is. Dit betekent niet dat iemand uw gegevens leest. De oplossing is een ander abonnement of een andere provider, en u kunt de CPU en schijf die u daadwerkelijk heeft gekregen meten voordat u een besluit neemt.

Er is één effect tussen klanten dat het vermelden waard is, en dat is geen beveiligingslek. Als u e-mail verstuurt vanaf uw VPS, bevindt uw IP-adres zich in een reeks die ook door andere klanten wordt gebruikt. Een buurman die spam verstuurt, kan ervoor zorgen dat een deel van die reeks op een blocklist terechtkomt, waardoor uw e-mail in spamfilters belandt om een reden waar u zelf geen schuld aan heeft. Providers die actief toezien op misbruik houden hun reeksen schoner. Vraag hiernaar als e-mail belangrijk voor u is.

Wat een kwaadwillende buurman niet kan, en het zeldzame geval waarin dit wel mogelijk is

Een klant op dezelfde host heeft geen toegang tot uw bestanden. Zij kunnen uw processen niet inzien, uw schijf niet koppelen en geen shell openen op uw server, omdat geen van deze zaken binnen hun virtuele machine bestaat. Eén uitzondering is het vermelden waard: beschouw elk privénetwerk van een provider als een netwerk dat u deelt met vreemden, en versleutel wat eroverheen gaat in plaats van aan te nemen dat het onzichtbaar is.

Hypervisor-escapes zijn reëel. Een bug in de virtualisatielaag kan code binnen één guest toegang geven tot de host, en vanaf de host tot elke guest die daarop draait. Deze bugs worden gevonden, gepubliceerd met een CVE (common vulnerabilities and exposures)-identificatie en gepatcht. Hostingproviders patchen deze snel omdat hun gehele bedrijfsmodel op die laag rust. Het gebruik hiervan vereist een werkende exploit voor een specifieke hypervisor-versie, wat een kostbare investering is voor een klein hostingaccount.

Side-channel-aanvallen tussen guests zijn eveneens reëel. Dit is de Spectre- en Meltdown-familie, die gedeelde processorcaches misbruiken om kleine hoeveelheden data over een grens heen te achterhalen. Microcode- en kernel-updates beperken deze risico's, en de uitleksnelheden in gepubliceerd onderzoek zijn minuscuul. Gepubliceerde gevallen zijn onderzoekdemonstraties in plaats van massa-aanvallen. Het risico is niet nul. Het staat echter nergens bovenaan de lijst met zaken die u schade zullen berokkenen.

Waar de verantwoordelijkheid van de provider eindigt en die van u begint

De provider is verantwoordelijk voor het gebouw, de host-hardware, de hypervisor en de host-kernel, het fysieke netwerk en het configuratiescherm waarmee u uw server kunt starten, stoppen, opnieuw kunt installeren en snapshots kunt maken. Als een van deze onderdelen faalt, is het aan hen om dit te herstellen.

U bent verantwoordelijk voor alles vanaf het besturingssysteem en hoger. Dit betekent de pakketten die u installeert, de poorten die u open laat staan, de accounts en keys die kunnen inloggen, de updates die u uitvoert, uw back-ups en uw eigen applicatiecode. De meeste VPS-abonnementen zijn 'unmanaged', wat betekent dat niemand uw server voor u bijwerkt en dat geen enkel supportticket dit voor u zal doen. Het onderscheid tussen managed en unmanaged is het lezen waard voordat u tot aankoop overgaat, omdat dit bepaalt in hoeverre u verantwoordelijk bent voor deze lijst.

Eén onderdeel van uw verantwoordelijkheid wordt vaak vergeten: het configuratiescherm van de hostingprovider zelf. Iedereen die toegang heeft tot dat account, kan uw server opnieuw installeren of uw schijf koppelen aan een rescuesysteem, zonder ooit een wachtwoord van binnenuit de server te hoeven weten. Schakel tweefactorauthenticatie (2FA) in op het hostingaccount en gebruik dat wachtwoord nergens anders opnieuw.

Kan uw hostingprovider uw gegevens inzien?

Ja, in principe wel, en dit is de eerlijke grens van wat een VPS u biedt. Uw schijfimage bevindt zich op de opslag van de provider. Hun console geeft toegang op schermniveau tot uw virtuele machine. Met de rescue-modus kan een ander systeem worden opgestart waarbij uw schijf is aangekoppeld. Een VPS beschermt u tegen andere klanten, maar de provider valt buiten die belofte.

Indien u gegevens beheert die onleesbaar moeten blijven voor de host, versleutel deze dan in uw applicatie voordat ze worden weggeschreven. Volledige schijfversleuteling binnen de guest helpt tegen een gekopieerde image in ruste, maar de sleutel moet in het geheugen aanwezig zijn terwijl de server draait, waardoor de provider nog steeds toegang heeft. Hetzelfde vertrouwensmodel geldt voor een dedicated server die u alleen huurt, met één gedeelde laag minder.

Wat een VPS daadwerkelijk kwetsbaar maakt

Een service die op elke interface luistert. Databases, caches, message queues en beheerpanelen binden standaard vaak aan 0.0.0.0. Dit betekent dat ze op elke netwerkinterface luisteren, inclusief de publieke interface. Het internet wordt constant en geautomatiseerd gescand; een nieuw IP-adres ontvangt binnen enkele minuten na activering de eerste ongevraagde verzoeken. Redis zonder wachtwoord, een Elasticsearch-node zonder authenticatie, een open Docker API op poort 2375 en een beheerpaneel met standaardinloggegevens worden op deze manier gevonden door scanners die niet weten wie u bent. Bind een service aan 127.0.0.1 wanneer alleen de lokale machine deze nodig heeft en blokkeer de rest via de firewall.

Docker dat uw firewall omzeilt. Het publiceren van een containerpoort schrijft network address translation (NAT)-regels die worden geëvalueerd vóór de regels van ufw (uncomplicated firewall). Hierdoor kan een container bereikbaar zijn vanaf het internet, terwijl ufw status aangeeft dat de poort is geblokkeerd. Dit overkomt vaak gebruikers die verder alles correct hebben ingesteld. De reden waarom een Docker-poort ufw negeert is het lezen waard voordat u een containerpoort publiceert.

SSH met wachtwoorden ingeschakeld. Lees /var/log/auth.log op elke publieke server en u zult regels als Failed password for root from 203.0.113.10 port 54312 ssh2 vinden, duizenden per dag en nacht. Bots proberen continu veelvoorkomende gebruikersnamen en wachtwoorden. Inloggen met een wachtwoord in combinatie met een root-account dat inlogpogingen accepteert, is alles wat een aanvaller nodig heeft. Gebruik uitsluitend keys en schakel root-login uit; dit verandert het inlogverkeer in ruis die u kunt negeren.

Eén private key die overal wordt gebruikt. Eén key die op elke laptop en server is gekopieerd, betekent dat één gestolen laptop toegang geeft tot alles. SSH-keys verlopen niet, dus een key die twee jaar geleden aan een externe medewerker is gegeven, werkt vandaag nog steeds. Eén key per persoon en per machine kost niets en beperkt de schade bij een gestolen key.

Pakketten die niet zijn bijgewerkt. Een gepubliceerde CVE voor uw webserver of applicatieframework is een openbare set instructies; scanners beginnen binnen enkele dagen met het testen daarop. Beveiligingsupdates zijn de goedkoopste verdediging die beschikbaar is en kunnen automatisch worden uitgevoerd: zie automatische beveiligingsupdates op Ubuntu.

Een gelekt geheim. Database-wachtwoorden en API-keys staan in .env-bestanden. Deze bestanden worden soms per ongeluk naar een publieke repository geüpload of geserveerd door een webserver die naar de verkeerde map wijst. Alles wat in de context van een AI-codeerassistent wordt geplakt, kan ook in een logbestand belanden, wat een apart onderwerp is: geheimen buiten het bereik van een agent houden.

Alles draaien als root. Wanneer uw applicatie als root draait, geeft één bug in de code de aanvaller de volledige controle over de machine, omdat er binnen de server geen barrière meer is die verdere verspreiding stopt.

Uw deel van het werk

Niets van het onderstaande valt onder het beheer van de hypervisor. Alles bevindt zich aan uw kant van de grens, en dit is de kant die bepaalt of uw VPS veilig is.

• Voer het eerste uur correct uit: de eerste tien minuten op een nieuwe VPS behandelt een non-root gebruiker en een firewall.
• Beveilig externe toegang: SSH verharden op een VPS.
• Sluit de poorten die u niet gebruikt: basisprincipes van ufw firewall.
• Geef elke service alleen de toegang die nodig is: gebruikers met minimale rechten op een VPS.
• Vertraag brute-force inlogpogingen: fail2ban op Ubuntu 24.04.
• Houd een back-up bij die u ten minste één keer heeft hersteld: restic back-ups voor een VPS.

Het deel van de provider is al voltooid op het moment dat uw server opstart. Uw deel kost ongeveer een uur op de eerste dag en daarna enkele minuten per maand. Als u nog opties aan het vergelijken bent, behandelt wat een VPS daadwerkelijk is de basis van dit alles.

FAQ

Kan een andere klant op dezelfde fysieke server mijn bestanden lezen?

Nee, niet op een KVM VPS. Uw server is een virtuele machine met een eigen kernel en een eigen virtuele schijf, plus een regio van het fysieke geheugen die door de host aan u is toegewezen. De processor blokkeert elke toegang buiten die regio. Er is geen gedeeld bestandssysteem tussen gasten, dus bestandsrechten in de server van een buurman hebben geen betekenis binnen die van u. Op containers gebaseerde abonnementen zoals OpenVZ en LXC delen de host-kernel en bieden een zwakkere grens; controleer dus welk type u aanschaft.

Is een VPS veiliger dan shared hosting?

Wat betreft isolatie: ja. Bij shared hosting draaien veel sites binnen één besturingssysteem en is de enige grens de bestandsrechten, waardoor een fout in een ander account soms bestanden kan blootstellen. Op een VPS is de grens een virtuele machine. Het compromis is dat shared hosting door de host wordt gepatcht, terwijl een unmanaged VPS door u wordt gepatcht. Een VPS is alleen veiliger als u daadwerkelijk de updates uitvoert en de poorten sluit.

Kan mijn hostingprovider mijn gegevens lezen?

In principe wel, en geen enkel VPS-product verandert dat. De schijf-image wordt opgeslagen op de hardware van de provider, de console geeft toegang op schermniveau tot de draaiende machine, en de rescue-modus kan een ander systeem opstarten met uw schijf aangekoppeld. Als bepaalde gegevens onleesbaar moeten blijven voor de host, versleutel deze dan in uw applicatie voordat u ze wegschrijft. Schijfversleuteling binnen de gastmachine houdt de sleutel nog steeds in het geheugen terwijl de server draait, dus dit verwijdert de provider niet uit het vertrouwensmodel.

Wat is de meest voorkomende manier waarop een VPS wordt gecompromitteerd?

Een blootgestelde service of een zwakke SSH-login, met grote voorsprong. Geautomatiseerde scanners scannen continu elk openbaar IP-adres. Een database die is gebonden aan 0.0.0.0 zonder wachtwoord, of een beheerderspaneel dat op de standaardinloggegevens is gelaten, wordt binnen minuten in plaats van maanden gevonden. /var/log/auth.log op elke openbare server toont de SSH-helft hiervan: herhaalde Failed password for root-regels van adressen over de hele wereld. Hypervisor-escapes bestaan, maar dit is onderzoekswerk gericht op hoogwaardige doelwitten, niet de oorzaak van alledaagse inbreuken.