Sécuriser un VPS : les 7 gestes de la première heure, dans le bon ordre

Votre VPS vient d'être livré. Il a une adresse IP publique, un compte administrateur et, souvent, un mot de passe envoyé par courriel.

Les robots qui balaient Internet à la recherche de serveurs ouverts n'attendent pas que vous ayez fini votre café. Dès sa mise en ligne, votre machine reçoit des tentatives de connexion. C'est la règle, pas l'exception.

Avec un VPS, la sécurité du système vous revient. L'hébergeur protège le datacenter, le réseau, le matériel. Ce qui se passe à l'intérieur de votre serveur, c'est votre affaire. Voici les 7 gestes à faire avant d'y installer quoi que ce soit, et surtout l'ordre dans lequel les faire.

Pourquoi l'ordre compte autant que les gestes

Le premier risque n'est pas le pirate. C'est vous.

Désactiver la connexion par mot de passe avant d'avoir testé votre clé SSH ? Vous êtes dehors. Activer le pare-feu avant d'avoir autorisé SSH ? Votre session se coupe, et vous êtes dehors aussi.

Une règle simple évite ces deux accidents : gardez toujours une session ouverte pendant que vous modifiez l'accès. Testez la nouvelle configuration dans une seconde fenêtre. Ne fermez la première qu'une fois la seconde connectée.

Geste 1 : mettre le système à jour

Un serveur fraîchement installé a souvent des correctifs en retard. Les failles corrigées sont publiques, donc connues des attaquants.

Sur Debian ou Ubuntu, une commande suffit : apt update && apt upgrade. Activez ensuite les mises à jour de sécurité automatiques (paquet unattended-upgrades). Les correctifs de sécurité s'installeront sans attendre que quelqu'un y pense.

Geste 2 : créer un utilisateur à vous

Le compte root a tous les droits. Il existe sur toutes les machines Linux, donc les robots le visent en premier : ils n'ont même pas à deviner le nom d'utilisateur.

Créez un compte personnel, donnez-lui le droit d'administrer via sudo, et travaillez avec lui. Chaque commande sensible demandera une confirmation. Et vous saurez qui a fait quoi si plusieurs personnes administrent le serveur.

Geste 3 : passer à la clé SSH

C'est le geste le plus efficace de la liste.

Un mot de passe se devine, se vole, se réutilise. Une clé SSH, non. Vous générez une paire de clés sur votre ordinateur : la clé privée reste chez vous, la clé publique est déposée sur le serveur. Sans la clé privée, personne n'entre. Même avec le bon mot de passe.

Testez la connexion par clé avec votre nouvel utilisateur. Elle fonctionne ? Alors seulement, passez au geste suivant.

Geste 4 : fermer les portes inutiles de SSH

Dans le fichier de configuration SSH (/etc/ssh/sshd_config), deux lignes changent tout :

- PermitRootLogin no : plus personne ne se connecte directement en root.

- PasswordAuthentication no : plus de connexion par mot de passe, la clé devient obligatoire.

Redémarrez le service SSH, puis ouvrez une seconde session pour vérifier que vous entrez toujours.

Changer le port SSH (22 par défaut) réduit le bruit dans les journaux. Ce n'est pas une protection. Un serveur bien configuré sur le port 22 est plus sûr qu'un serveur mal configuré sur un port exotique.

Geste 5 : activer un pare-feu qui refuse tout par défaut

Le principe : on bloque tout le trafic entrant, puis on ouvre uniquement ce qui sert.

Sur Ubuntu, l'outil UFW rend la chose lisible. On autorise SSH en premier, puis le web (ports 80 et 443) si le serveur héberge un site, puis on active. Une base de données n'a presque jamais besoin d'être joignable depuis Internet. Si votre application et sa base tournent sur le même serveur, ce port reste fermé.

Chaque port ouvert est une porte à surveiller. Moins il y en a, mieux vous dormez.

Geste 6 : bloquer les tentatives répétées

Fail2ban lit les journaux de connexion et bannit temporairement les adresses qui échouent trop souvent.

Soyons honnêtes : avec la clé SSH obligatoire, deviner un mot de passe ne mène nulle part. Fail2ban ne vous sauve pas. Il allège les journaux, et il protège les autres services exposés, comme la page de connexion d'un site ou un serveur de messagerie. Utile, pas suffisant.

Geste 7 : sauvegarder ailleurs que sur le serveur

Une sauvegarde stockée sur le serveur qu'elle protège disparaît avec lui. Panne, erreur de manipulation, logiciel de rançon : le résultat est le même.

Programmez des sauvegardes automatiques vers un autre emplacement. Puis faites le test que presque personne ne fait : restaurez une sauvegarde, au moins une fois. Une sauvegarde jamais restaurée est une hypothèse, pas une garantie.

Sécuriser un VPS chez CloudStore : ce qu'il faut savoir avant de commencer

Ces 7 gestes s'appliquent sur n'importe quel VPS Linux. Deux questions méritent pourtant d'être posées à votre hébergeur avant la livraison.

Où est physiquement le serveur ? Sécuriser l'accès ne sert pas à grand-chose si les données de vos clients sont stockées sur un continent dont la loi vous échappe. Les VPS CloudStore sont hébergés en Afrique.

Que faire si vous vous enfermez dehors ? Une erreur de pare-feu arrive aux meilleurs. Il faut alors un accès de secours au serveur, sans passer par SSH.

Pour les sauvegardes, renseignez-vous sur les options proposées avec votre offre . Et si vous préférez ne pas faire cette configuration seul, notre équipe peut vous accompagner.

Une heure maintenant, ou une semaine plus tard

Ces gestes prennent moins d'une heure à un administrateur qui les connaît. Rattraper un serveur compromis prend beaucoup plus longtemps : comprendre comment l'attaquant est entré, réinstaller, restaurer, prévenir les clients.

Un VPS est un serveur à vous. Sa sécurité aussi.

Vous préparez un nouveau projet ? Choisissez votre VPS CloudStore — voir nos tarifs sur cloudstore.africa — et appliquez ces 7 gestes dès la livraison.