Un VPS fraîchement livré reçoit souvent ses premières tentatives de connexion SSH dans l’heure qui suit sa mise en ligne. Il suffit d’ouvrir le journal d’authentification le lendemain pour s’en rendre compte. Les robots qui balayent les plages d’adresses IP des hébergeurs ne dorment jamais, et une machine neuve, avec un mot de passe root envoyé en clair, est exactement ce qu’ils cherchent.
La plupart des incidents sur un premier serveur virtuel ne viennent pas d’une faille sophistiquée, mais d’une poignée d’oublis qui se répètent d’un débutant à l’autre. Les voici, avec la manière de les éviter.
Laisser SSH tel que l’hébergeur l’a livré
L’erreur la plus répandue consiste à garder la connexion par mot de passe et l’accès direct au compte root. C’est pratique le premier jour, et c’est la porte d’entrée de la majorité des compromissions. Le bon réflexe tient en trois gestes : créer un utilisateur ordinaire avec les droits sudo, installer une clé SSH sur ce compte, puis désactiver dans la configuration du démon l’authentification par mot de passe et la connexion root.
Changer le port SSH est souvent présenté comme une protection. Cela réduit le bruit dans les journaux, rien de plus. Un outil comme fail2ban, qui bannit temporairement les adresses multipliant les échecs, rend un service plus concret. Avant de fermer quoi que ce soit, gardez une seconde session ouverte : beaucoup de premières erreurs se terminent par un administrateur enfermé dehors, obligé de passer par la console de secours de l’hébergeur.
Croire que le pare-feu est déjà en place
Selon les hébergeurs, un VPS arrive avec un pare-feu réseau activé, désactivé, ou pas de pare-feu du tout. Il ne faut rien supposer. Sur la machine elle-même, nftables ou une surcouche comme ufw permet d’adopter une politique simple : tout refuser en entrée, puis n’ouvrir que ce qui doit l’être, typiquement SSH, HTTP et HTTPS.
Un piège classique attend ceux qui installent Docker : par défaut, les ports publiés par les conteneurs sont ouverts en manipulant directement les règles du noyau, ce qui peut contourner les règles posées avec ufw. Une base de données lancée « pour tester » se retrouve alors joignable depuis internet. La parade consiste à lier les ports internes à 127.0.0.1 dans la configuration du conteneur et à vérifier de l’extérieur, avec un scan depuis une autre machine, ce qui répond réellement.
Oublier qu’il existe une seconde adresse : l’IPv6
De nombreux VPS reçoivent à la fois une adresse IPv4 et une adresse ou un bloc IPv6. Les règles de pare-feu écrites uniquement pour l’IPv4 laissent alors un service parfaitement accessible par l’autre protocole. Avec ufw, l’option IPv6 doit être active ; avec nftables, une table de la famille inet couvre les deux d’un coup. Le test de contrôle est le même : scanner la machine sur ses deux adresses.
Choisir l’offre sur le seul nombre de cœurs
Les fiches commerciales mettent en avant les vCPU et la mémoire. Pour un usage réseau, d’autres lignes comptent autant : bande passante garantie ou partagée, éventuel plafond de trafic mensuel, nombre d’adresses IPv4 incluses, présence d’une protection anti-DDoS, localisation du datacenter et possibilité d’un réseau privé entre plusieurs machines. Deux offres affichant la même configuration peuvent se comporter très différemment sur ces points.
Pour ne pas comparer des choux et des carottes, on peut partir des offres de VPS comparées sur https://meilleur-serveur-dedie.fr/, où les fiches précisent la date du relevé, les frais d’installation et la source officielle, et signalent comme « À vérifier » ce qui n’est pas confirmé. C’est une base de tri ; la lecture des conditions générales de l’hébergeur retenu reste indispensable, en particulier sur le prix au renouvellement.
Sauvegarder sur la machine qu’on veut protéger
Un script qui copie chaque nuit la base de données dans un dossier du même VPS n’est pas une sauvegarde. Si le disque virtuel est corrompu, si la machine est compromise ou si le compte chez l’hébergeur est suspendu, tout disparaît ensemble. Les instantanés proposés en option par certains hébergeurs aident, mais restent chez le même prestataire.
Une organisation raisonnable pour un petit projet combine :
- un instantané avant chaque mise à jour importante ;
- une sauvegarde chiffrée et quotidienne vers un stockage externe, chez un autre prestataire, avec un outil comme restic ou BorgBackup ;
- une restauration complète testée au moins une fois, sur une machine vierge.
Le dernier point est celui qu’on saute toujours. Une sauvegarde jamais restaurée est une hypothèse, pas une garantie.
Négliger les mises à jour automatiques et la supervision
Un VPS installé puis oublié dérive vite. Sur Debian et Ubuntu, le paquet unattended-upgrades applique automatiquement les correctifs de sécurité ; il faut juste vérifier qu’il est actif et que les redémarrages nécessaires finissent par être faits. Côté supervision, une sonde externe gratuite qui vérifie toutes les cinq minutes que le site répond suffit à éviter d’apprendre une panne par un utilisateur.
Dernier conseil, le plus simple : tenez un fichier texte où vous notez chaque modification faite sur le serveur, avec la date et la commande. Le jour où il faudra reconstruire la machine, ou comprendre pourquoi un service ne répond plus, ce journal vaudra plus que n’importe quel outil.
