Sécuriser un VPS : le guide pratique

Certains liens de cette page sont des liens d'affiliation : si vous souscrivez après avoir cliqué, nous percevons une commission, sans surcoût pour vous. Cela ne change ni notre classement ni nos réserves, qui reposent sur les caractéristiques réelles des offres. En savoir plus

Prendre un VPS, c'est devenir administrateur système, que l'on s'en rende compte ou non. L'hébergeur garantit le matériel, le réseau et l'hyperviseur ; tout ce qui tourne à l'intérieur de la machine relève de vous, y compris quand elle est compromise.

Ce guide couvre les mesures qui comptent réellement, leur ordre de priorité, et ce qu'elles ne protègent pas.

Ce qui arrive à un serveur laissé nu

Un serveur exposé sur Internet reçoit des tentatives de connexion automatisées dans les minutes qui suivent sa mise en service. Ce ne sont pas des attaques ciblées : des robots balaient en permanence les plages d'adresses et testent les identifiants les plus courants.

Un serveur compromis sert ensuite à envoyer du spam, héberger des contenus frauduleux ou participer à des attaques. L'hébergeur le détecte généralement avant vous, et suspend le service pour protéger son réseau. La plupart des contrats ne prévoient aucune obligation d'assistance pour la remise en état.

Un serveur compromis ne se nettoie pas : il se réinstalle. Une fois qu'un attaquant a obtenu les privilèges d'administration, aucune vérification ne permet d'affirmer qu'il ne subsiste pas un accès dissimulé. La seule réponse fiable est la réinstallation complète depuis une sauvegarde antérieure à la compromission.

Les six mesures qui écartent l’essentiel du risque

Elles se mettent en place en une heure et suffisent à écarter la quasi-totalité des attaques automatisées, qui constituent l'immense majorité de la menace réelle.

1. Authentification SSH par clés uniquement

C'est la mesure la plus efficace du lot. Générez une paire de clés, déposez la clé publique sur le serveur, vérifiez que la connexion fonctionne, puis désactivez l'authentification par mot de passe. Les attaques par force brute deviennent alors sans objet.

2. Pas de connexion directe en root

Créez un compte dédié disposant de l'élévation de privilèges, et interdisez la connexion directe du compte administrateur. Un attaquant doit alors deviner un nom d'utilisateur en plus du reste.

3. Un pare-feu restrictif

N'ouvrez que les ports réellement nécessaires : le web, le chiffrement et l'accès distant. Tout le reste doit être fermé par défaut. Une base de données ne doit jamais être accessible depuis l'extérieur.

4. Mises à jour de sécurité automatiques

Activez l'application automatique des correctifs de sécurité du système. C'est le seul moyen réaliste de rester à jour dans la durée, parce que personne ne se connecte chaque semaine pour vérifier.

5. Blocage des tentatives répétées

Un outil qui bannit temporairement les adresses effectuant des tentatives de connexion répétées réduit considérablement le bruit et la charge, en complément de l'authentification par clés.

6. Sauvegardes hors du serveur

Une sauvegarde stockée sur le serveur qu'elle protège disparaît avec lui. Envoyez-la ailleurs, chez un autre prestataire si possible, et testez une restauration au moins une fois.

Ce que ces mesures ne couvrent pas

Durcir l'accès au serveur ne protège pas ce qui tourne dessus. La majorité des compromissions de sites web ne passent pas par SSH mais par l'application elle-même.

Une extension de CMS obsolète comportant une faille publiquement documentée.
Un mot de passe d'administration faible sur le site lui-même.
Un formulaire mal filtré permettant l'injection de code ou le dépôt de fichiers.
Des identifiants laissés dans un dépôt de code public, que des robots recherchent activement.
Un service annexe installé pour un test puis oublié, et jamais mis à jour.

La sécurité applicative relève donc du même effort que la sécurité système : mises à jour régulières, suppression de ce qui ne sert plus, et principe du moindre privilège pour chaque composant.

Surveiller sans y passer ses journées

Une compromission passe souvent inaperçue plusieurs semaines. Quelques dispositifs légers permettent de la détecter tôt, sans surveillance permanente.

Une surveillance externe de disponibilité, qui alerte quand le service ne répond plus.
Un contrôle de la charge du serveur : une consommation processeur anormale sans trafic correspondant est un signal classique.
La surveillance de la réputation de l'adresse IP, pour être averti si votre serveur se met à envoyer du spam.
Une lecture périodique des journaux d'authentification, ne serait-ce que pour repérer une connexion réussie inattendue.
Une alerte sur l'espace disque, dont la saturation soudaine accompagne souvent un usage détourné du serveur.

Si vous n'avez pas le temps de mettre en place ces dispositifs ni de réagir aux alertes, c'est un signal clair : l'offre adaptée à votre situation n'est pas un VPS nu, mais un hébergement infogéré ou mutualisé où l'hébergeur assume cette responsabilité.

En cas de compromission

La réaction dans les premières heures détermine l'ampleur des dégâts. Voici l'ordre à suivre.

Isoler le serveur en coupant l'accès public, pour arrêter l'envoi de spam ou la diffusion de contenus frauduleux.
Ne pas nettoyer dans l'urgence. Conservez l'état du serveur : il documente ce qui s'est passé et par où.
Identifier la date probable de compromission, pour savoir jusqu'à quelle sauvegarde remonter.
Réinstaller entièrement et restaurer les données depuis une sauvegarde antérieure à cette date.
Changer tous les identifiants : accès serveur, base de données, administration du site, comptes de messagerie, clés d'API.
Corriger la faille d'origine avant de remettre en ligne, faute de quoi la compromission se reproduira à l'identique.

Si des données personnelles ont pu être consultées ou exfiltrées, une violation de données doit être notifiée à l'autorité de protection compétente dans un délai contraint, et parfois aux personnes concernées. Ce point relève du RGPD et ne se règle pas uniquement techniquement.

Questions fréquentes

Un serveur compromis peut-il être nettoyé ?

Ce n'est pas fiable. Une fois les privilèges d'administration obtenus, un attaquant peut dissimuler des accès qu'aucune vérification ne garantit d'avoir tous trouvés. La seule réponse sûre est la réinstallation complète et la restauration d'une sauvegarde antérieure à la compromission.

Ces mesures suffisent-elles ?

Elles écartent l'essentiel des attaques automatisées, qui constituent la majorité de la menace. Elles ne protègent pas ce qui tourne sur le serveur : une extension obsolète ou un mot de passe faible sur le site reste une porte d'entrée.

Sécuriser un VPS : les mesures indispensables