Un VPS est-il sûr ? Ce que vous contrôlez

Un hébergement VPS est-il sûr ? Réponse courte

Oui. Un hébergement VPS est sûr pour la plupart des usages, et constitue une réelle amélioration par rapport à l’hébergement mutualisé. Un VPS (serveur privé virtuel) est une machine virtuelle avec son propre noyau, sa propre mémoire, son propre disque et ses propres comptes utilisateur. L’hyperviseur qui l’exécute empêche les autres clients d’accéder à ces quatre éléments. La personne qui loue le serveur voisin du vôtre sur la même machine physique ne peut pas lire vos fichiers, lister vos processus, se connecter à votre serveur ni voir votre trafic réseau.

La réponse complète comporte deux aspects. Le fournisseur possède le matériel et l’hyperviseur. Vous êtes responsable de tout ce qui se trouve dans votre machine virtuelle, et c’est là que commencent presque tous les incidents réels. Les serveurs sont compromis à cause d’un port ouvert, d’un mot de passe SSH faible, d’un paquet que personne n’a mis à jour ou d’un secret présent dans un fichier qui a été publié. Ils sont très rarement compromis à cause de l’hyperviseur.

Ce que l’hyperviseur isole réellement

Un hyperviseur est le logiciel qui exécute des machines virtuelles sur un même hôte physique. Avec un VPS KVM (KVM signifie kernel-based virtual machine, le standard sur les hôtes Linux), votre serveur est une machine virtuelle complète. Il démarre avec son propre kernel. L’hôte lui attribue une région fixe de mémoire physique, et la memory management unit du processeur refuse tout accès en dehors de cette région. Le code exécuté dans un autre guest ne peut donc pas adresser votre mémoire vive. Il n’y a ni système de fichiers partagé ni table des utilisateurs partagée. Les permissions sur les fichiers du serveur d’un voisin n’ont donc aucun effet sur le vôtre.

L’hébergement mutualisé fonctionne différemment. De nombreux sites résident dans un même système d’exploitation, derrière un même serveur web et une même installation de PHP, sous la forme de comptes utilisateur ordinaires. La seule limite repose sur les permissions des fichiers. Une erreur de permission ou un plugin vulnérable exécuté avec un compte pouvant lire trop de fichiers peut donc accéder aux fichiers d’un autre compte. C’est cette limite que l’passage de l’hébergement mutualisé à un VPS supprime.

Vérifiez ce que vous achetez, car toutes les offres vendues comme des VPS ne sont pas des machines virtuelles. Les offres basées sur des conteneurs (OpenVZ, LXC, Virtuozzo) partagent le kernel de l’hôte et isolent les clients avec des namespaces et des cgroups, au lieu d’utiliser la virtualisation matérielle. Cette limite est moins robuste, car une faille du kernel de l’hôte affecte également le kernel de votre serveur. Vous ne pouvez pas non plus charger de kernel modules sur ces offres, ce qui exclut certains logiciels. KVM constitue le choix par défaut le plus sûr. Demandez quelle technologie vous sera fournie avant de payer.

Ce qu’un voisin bruyant peut vous faire subir

Partager un hôte physique vous coûte en performances, et c’est le seul coût. Les machines invitées d’un même hôte partagent le processeur physique et les disques. Lorsque le processeur traite la charge d’un autre client, votre vCPU attend. Linux comptabilise cette attente comme du steal time : le champ %st dans top et vmstat. Un steal time supérieur à quelques pour cent pendant plusieurs heures signifie que l’hôte est surbooké. Cela ne signifie pas que quelqu’un lit vos données. La solution consiste à choisir une autre offre ou un autre fournisseur. Vous pouvez mesurer les performances CPU et disque réellement obtenues avant de décider.

Un effet entre clients mérite d’être connu, mais ce n’est pas une faille de sécurité. Si vous envoyez des e-mails depuis votre VPS, votre adresse IP se trouve dans une plage également utilisée par d’autres clients. Un voisin qui envoie du spam peut faire inscrire une partie de cette plage sur une blocklist. Vos e-mails arrivent alors dans les dossiers de spam pour une raison dont vous n’êtes pas responsable. Les fournisseurs qui surveillent les abus disposent de plages d’adresses plus propres. Renseignez-vous à ce sujet si l’e-mail est important pour vous.

Ce qu’un voisin malveillant ne peut pas faire, et le cas rare où il le peut

Un client hébergé sur le même serveur n’a aucun accès à vos fichiers. Il ne peut pas voir vos processus, monter votre disque ni ouvrir un shell sur votre serveur, car aucun de ces éléments n’existe dans sa machine virtuelle. Une exception mérite d’être précisée : considérez tout réseau privé du fournisseur comme un réseau partagé avec des inconnus. Chiffrez les données qui y transitent au lieu de supposer qu’elles sont invisibles.

Les escapes de l’hyperviseur existent. Un bug dans la couche de virtualisation peut permettre à du code exécuté dans un guest d’atteindre l’hôte, puis, depuis l’hôte, tous les guests qui y sont exécutés. Ces bugs sont identifiés, publiés avec un identifiant CVE (common vulnerabilities and exposures), puis corrigés. Les hébergeurs les corrigent rapidement, car toute leur activité repose sur cette couche. Exploiter une telle faille nécessite un exploit fonctionnel pour une version précise de l’hyperviseur. C’est une ressource coûteuse à consacrer à un petit compte d’hébergement.

Les attaques par canaux auxiliaires entre guests existent également. Elles appartiennent à la famille Spectre et Meltdown. Elles exploitent les caches de processeur partagés pour déduire de petites quantités de données de l’autre côté d’une frontière. Les mises à jour du microcode et du kernel réduisent ces risques, et les débits d’exfiltration publiés sont très faibles. Les cas publiés sont des démonstrations de recherche, pas des attaques massives. Le risque n’est pas nul. Il est simplement loin d’être prioritaire parmi les problèmes susceptibles de vous nuire.

Ce qui relève du fournisseur et ce qui vous incombe

Le fournisseur est responsable du bâtiment, du matériel de l’hôte, de l’hyperviseur et du kernel de l’hôte, du réseau physique, ainsi que du control panel qui peut démarrer, arrêter, reconstruire et prendre des snapshots de votre serveur. Si l’un de ces éléments tombe en panne, c’est à lui de résoudre le problème.

Vous êtes responsable de tout ce qui se trouve à partir de votre système d’exploitation. Cela inclut les packages que vous installez, les ports que vous laissez ouverts, les comptes et les clés qui peuvent se connecter, les mises à jour que vous appliquez, vos sauvegardes et votre propre code applicatif. La plupart des offres VPS sont unmanaged : personne ne corrige votre serveur à votre place et aucun ticket de support ne le fera. La distinction entre managed et unmanaged mérite d’être lue avant l’achat, car elle détermine quelle part de cette liste vous incombe.

Un élément de votre responsabilité est facile à oublier : le hosting control panel lui-même. Toute personne qui détient ces identifiants peut reconstruire votre serveur ou attacher son disque à un système de secours, sans connaître le moindre mot de passe utilisé dans le serveur. Activez l’authentification à deux facteurs (2FA) sur le compte d’hébergement et ne réutilisez pas ce mot de passe ailleurs.

Votre hébergeur peut-il voir vos données ?

Oui, en principe. C’est la limite à connaître avec un VPS. L’image disque se trouve sur le stockage de l’hébergeur. Sa console permet d’accéder à l’écran de votre machine virtuelle. Le mode rescue peut démarrer un autre système avec votre disque attaché. Un VPS vous isole des autres clients. L’hébergeur n’est pas couvert par cette protection.

Si certaines données doivent rester illisibles pour l’hébergeur, chiffrez-les dans votre application avant leur écriture. Le chiffrement intégral du disque dans le système invité protège contre la copie d’une image inactive. Mais la clé doit rester en mémoire pendant le fonctionnement du serveur. Cela n’exclut donc pas l’hébergeur. Le même niveau de confiance s’applique à un serveur dédié que vous louez seul, avec une couche partagée en moins.

Ce qui compromet réellement un VPS

Un service à l’écoute sur toutes les interfaces. Les bases de données, les caches, les files de messages et les panneaux d’administration écoutent souvent sur 0.0.0.0 par défaut. Cela signifie qu’ils utilisent toutes les interfaces réseau, y compris l’interface publique. Le scan d’Internet est constant et automatisé. Une nouvelle adresse IP reçoit donc sa première requête non sollicitée quelques minutes après sa mise en ligne. Un Redis sans mot de passe, un nœud Elasticsearch sans authentification, une API Docker ouverte sur le port 2375 et un panneau d’administration qui utilise encore ses identifiants par défaut sont tous découverts de cette façon, par un scanner qui ne sait rien de vous. Faites écouter un service sur 127.0.0.1 lorsque seule la machine locale doit y accéder, et bloquez le reste avec le firewall.

Docker qui contourne votre firewall. La publication d’un port de conteneur crée des règles de translation d’adresses réseau (NAT) évaluées avant les règles d’ufw (uncomplicated firewall). Un conteneur peut donc être accessible depuis Internet alors que ufw status indique que ce port est refusé. Ce problème concerne aussi les personnes qui ont correctement configuré tout le reste. La raison pour laquelle un port Docker ignore ufw mérite d’être lue avant de publier un port de conteneur.

SSH avec les mots de passe activés. Consultez /var/log/auth.log sur n’importe quel serveur public et vous trouverez des lignes comme Failed password for root from 203.0.113.10 port 54312 ssh2, par milliers, de jour comme de nuit. Les bots essaient les noms d’utilisateur et les mots de passe courants. L’authentification par mot de passe, associée à un compte root qui accepte les connexions, suffit à un attaquant. Avec les clés uniquement et la connexion de root désactivée, ce trafic devient du bruit que vous pouvez ignorer.

Une seule clé privée utilisée partout. Une clé copiée sur chaque ordinateur portable et chaque serveur signifie qu’un seul ordinateur portable volé donne accès à tout. De plus, les clés SSH n’expirent pas. Une clé remise à un prestataire il y a deux ans fonctionne donc encore aujourd’hui. Une clé par personne et par machine ne coûte rien et limite les ressources accessibles avec une seule clé volée.

Des paquets jamais mis à jour. Un CVE publié contre votre serveur web ou votre framework applicatif constitue un mode opératoire public. Les scanners commencent à le tester dans les jours qui suivent. Les mises à jour de sécurité sont la défense la moins coûteuse disponible et peuvent s’exécuter automatiquement : consultez les mises à jour de sécurité automatiques sur Ubuntu.

Un secret divulgué. Les mots de passe de bases de données et les clés d’API se trouvent dans des fichiers .env. Ces fichiers peuvent être envoyés dans un dépôt public ou servis par un serveur web configuré sur le mauvais répertoire. Tout contenu collé dans le contexte d’un agent de programmation utilisant l’IA peut également finir dans un journal. C’est un sujet distinct : garder les secrets hors de portée d’un agent.

Tout exécuter avec root. Lorsque votre application s’exécute avec root, une seule vulnérabilité lui donne le contrôle de toute la machine. Il ne reste en effet aucune séparation interne au serveur pour empêcher la propagation.

Votre partie du travail

Aucune des tâches suivantes ne relève de l’hyperviseur. Elles sont toutes de votre côté, et c’est ce côté qui détermine si votre VPS est sécurisé.

• Faites correctement la première heure : les dix premières minutes sur un nouveau VPS couvrent la création d’un utilisateur non-root et la configuration d’un pare-feu.
• Sécurisez l’accès distant : sécuriser SSH sur un VPS.
• Fermez les ports que vous n’utilisez pas : les bases du pare-feu ufw.
• Accordez à chaque service uniquement les accès dont il a besoin : utilisateurs avec le principe du moindre privilège sur un VPS.
• Ralentissez les tentatives de connexion par force brute : fail2ban sur Ubuntu 24.04.
• Conservez une sauvegarde que vous avez restaurée au moins une fois : sauvegardes restic pour un VPS.

La partie du fournisseur est déjà terminée lorsque votre serveur démarre. Votre partie prend environ une heure le premier jour, puis quelques minutes par mois. Si vous comparez encore les options, ce qu’est réellement un VPS présente les bases nécessaires pour comprendre tout cela.

FAQ

Un autre client sur le même serveur physique peut-il lire mes fichiers ?

Non, pas sur un VPS KVM. Votre serveur est une machine virtuelle avec son propre kernel et son propre disque virtuel, ainsi qu’une région de mémoire physique que l’hôte lui attribue. Le processeur bloque tout accès en dehors de cette région. Aucun système de fichiers n’est partagé entre les guests. Les permissions de fichiers sur le serveur d’un autre client n’ont donc aucune portée sur le vôtre. Les offres basées sur des conteneurs, comme OpenVZ et LXC, partagent le kernel de l’hôte et fournissent une isolation plus faible. Vérifiez donc le type de virtualisation proposé.

Un VPS est-il plus sûr qu’un hébergement mutualisé ?

Pour l’isolation, oui. En hébergement mutualisé, de nombreux sites fonctionnent dans un même système d’exploitation et la seule séparation repose sur les permissions de fichiers. Une erreur dans un autre compte peut donc parfois exposer des fichiers. Sur un VPS, la séparation repose sur une machine virtuelle. En contrepartie, l’hébergeur applique les correctifs sur un hébergement mutualisé, tandis que vous devez les appliquer vous-même sur un VPS non managé. Un VPS est plus sûr uniquement si vous installez réellement les mises à jour et fermez les ports.

Mon hébergeur peut-il lire mes données ?

En principe, oui. Aucun produit VPS ne change ce point. L’image disque est stockée sur le matériel de l’hébergeur, la console permet d’accéder à l’écran de la machine en fonctionnement et le rescue mode peut démarrer un autre système avec votre disque attaché. Si certaines données doivent rester illisibles pour l’hébergeur, chiffrez-les dans votre application avant leur écriture. Le chiffrement du disque à l’intérieur du guest conserve tout de même la clé en mémoire pendant le fonctionnement du serveur. Il ne retire donc pas l’hébergeur du périmètre de confiance.

Quel est le moyen le plus courant par lequel un VPS est compromis ?

De très loin, il s’agit d’un service exposé ou d’une authentification SSH faible. Des scanners automatisés testent en continu chaque adresse IP publique. Une base de données liée à 0.0.0.0 sans mot de passe, ou un panneau d’administration conservant ses identifiants par défaut, est donc découverte en quelques minutes plutôt qu’en quelques mois. /var/log/auth.log sur n’importe quel serveur public montre la partie SSH : des lignes Failed password for root répétées provenant d’adresses du monde entier. Les failles d’évasion de l’hyperviseur existent, mais elles relèvent de la recherche avancée et ciblent des systèmes à forte valeur. Elles ne sont pas à l’origine des compromissions ordinaires.