Sécurisez votre VPS : une checklist pour les 10 premières minutes

Écrit par l'équipe ApexVPS • Dernière mise à jour : juillet 2026 • Lecture de 9 min

Un nouveau VPS Linux est sondé par des bots automatisés quelques minutes après sa mise en ligne, donc le premier geste le plus judicieux est de suivre une courte checklist réutilisable sécuriser un VPS checklist avant d'installer quoi que ce soit d'autre. Ce guide est cette checklist : une routine pratique pour les dix premières minutes, à suivre sur tout nouveau serveur Ubuntu ou Debian pour créer un utilisateur non-root, verrouiller SSH, activer un pare-feu et fermer la porte aux connexions par force brute. Chaque commande ci-dessous est standard et sûre à copier, et aucune ne nécessite d'outillage particulier — juste votre terminal et quelques minutes.

Suivez les étapes dans l'ordre. Chacune s'appuie sur la précédente, et à la fin, vous aurez un serveur nettement plus difficile à pirater que l'image par défaut de départ.

Pourquoi cette urgence ? L'espace IPv4 public est scanné en continu. Les moteurs de recherche pour appareils connectés à Internet, ainsi que d'innombrables botnets, répertorient de nouveaux hôtes et essaient des identifiants par défaut 24h/24. L'écart entre « le serveur est en ligne » et « le serveur est attaqué » se mesure en minutes, pas en jours. Passer dix minutes concentrées sur ces bases vous retire de la liste des cibles faciles dont les outils automatisés se régalent, et cela ne coûte que votre attention.

Avant de commencer

Vous aurez besoin de l'accès SSH à votre nouveau serveur et de l'adresse IP que votre fournisseur vous a envoyée par e-mail. Chez ApexVPS, chaque plan inclut un accès root complet, vous pouvez donc effectuer cette procédure de durcissement vous-même. Ouvrez un terminal et connectez-vous en tant que root (ou l'utilisateur par défaut créé par votre image) :

ssh root@your_server_ip

Une règle prime sur toutes les autres : ne désactivez jamais une méthode de connexion tant que vous n'avez pas confirmé que le remplacement fonctionne. Gardez votre première session SSH ouverte pendant que vous en testez une seconde. Si quelque chose tourne mal, cette session ouverte est votre filet de sécurité.

Étape 1 — Mettez à jour le système

Des logiciels corrigés sont le fondement de toute liste de contrôle de sécurité VPS. Commencez par actualiser l'index des paquets et installer les dernières corrections de sécurité :

sudo apt update && sudo apt upgrade -y

Sur une nouvelle image, cela tire souvent des dizaines de mises à jour, y compris des correctifs noyau et OpenSSH. Si le noyau est mis à niveau, prévoyez un redémarrage avec sudo reboot une fois le reste de la liste de contrôle terminé.

Étape 2 — Créez un utilisateur non-root avec sudo

Se connecter directement en tant que root est risqué : une seule commande erronée s'exécute avec des privilèges illimités, et root est le premier compte que tout attaquant tente. Créez un utilisateur dédié et accordez-lui des droits administratifs via sudo à la place :

adduser deploy
usermod -aG sudo deploy

La première commande crée le compte et demande un mot de passe ; la seconde l'ajoute au groupe sudo. Remplacez deploy par le nom de votre choix. Désormais, vous vous connecterez sous cet utilisateur et n'élèverez les privilèges à root que lorsqu'une commande spécifique l'exige.

Étape 3 — Configurez l'authentification par clé SSH

Les mots de passe peuvent être devinés ; les clés SSH pratiquement pas. Générez une paire de clés Ed25519 moderne sur votre machine locale (pas sur le serveur) :

ssh-keygen -t ed25519 -C "[email protected]"

Acceptez l'emplacement par défaut et, idéalement, définissez une phrase de passe. Copiez ensuite la clé publique vers votre nouvel utilisateur sur le serveur :

ssh-copy-id deploy@your_server_ip

Si ssh-copy-id n'est pas disponible, créez le répertoire et le fichier à la main sur le serveur, collez votre clé publique dans ~/.ssh/authorized_keys, et corrigez les permissions :

mkdir -p ~/.ssh
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Ouvrez maintenant un nouveau terminal et confirmez que vous pouvez vous connecter sans mot de passe : ssh deploy@your_server_ip. Ne passez pas à la suite tant que cela ne fonctionne pas — l'étape suivante en dépend.

Étape 4 — Verrouillez SSH : désactivez la connexion root et les mots de passe

Une fois la connexion par clé prouvée, désactivez les options plus faibles. Modifiez la configuration du démon SSH :

sudo nano /etc/ssh/sshd_config

Définissez (ou décommentez et modifiez) ces trois directives :

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Validez le fichier avant de l'appliquer, puis redémarrez le service :

sudo sshd -t
sudo systemctl restart ssh

La vérification sshd -t détecte les fautes de frappe qui pourraient sinon vous enfermer dehors. Après le redémarrage, testez une nouvelle connexion dans un terminal séparé. La connexion root via SSH et la devinette de mots de passe sont maintenant toutes deux hors jeu.

Changez le port SSH (optionnel)

Déplacer SSH hors du port 22 n'arrêtera pas un attaquant déterminé, mais cela vous cache du bruit de fond constant des bots qui ne scannent que le port par défaut. Si vous le voulez, ajoutez une ligne telle que Port 2222 à /etc/ssh/sshd_config. Crucialement, ouvrez le nouveau port dans votre pare-feu (étape suivante) avant de redémarrer SSH, sinon vous serez verrouillé dehors.

Étape 5 — Activez un pare-feu avec UFW

Un pare-feu garantit que seuls les ports que vous avez l'intention d'exposer sont accessibles. Ubuntu et Debian sont livrés avec UFW (Uncomplicated Firewall), qui est exactement ce que son nom promet. Définissez une valeur par défaut sensée et autorisez SSH avant de l'activer :

sudo apt install ufw -y
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

Le profil OpenSSH ouvre le port 22. Si vous avez déplacé SSH à l'étape précédente, autorisez le nouveau port avec sudo ufw allow 2222/tcp à la place. Vous hébergez un site web ? Ajoutez HTTP et HTTPS :

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Tout le reste reste fermé par défaut, ce qui est exactement ce que vous voulez sur un serveur public.

Étape 6 — Installez fail2ban pour stopper la force brute

Même avec des clés imposées, les attaquants continueront de marteler votre port SSH. fail2ban surveille vos journaux et bannit temporairement toute IP qui échoue trop de fois. Installez-le et activez-le :

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban

Pour personnaliser les règles, copiez la configuration par défaut dans un fichier de remplacement local afin que les mises à jour n'écrasent jamais vos modifications, puis modifiez-le :

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Dans la section [sshd], vous pouvez ajuster des valeurs comme maxretry et bantime. Rechargez avec sudo systemctl restart fail2ban et vérifiez qui est actuellement incarcéré avec sudo fail2ban-client status sshd.

Étape 7 — Activez les mises à jour de sécurité automatiques

Les failles de sécurité sont découvertes constamment, et celles qui font mal sont les correctifs que vous n'avez jamais appliqués. Le paquet unattended-upgrades installe les mises à jour importantes pour vous selon un calendrier :

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure -plow unattended-upgrades

Choisissez "Oui" lorsque vous y êtes invité, et Ubuntu ou Debian appliquera silencieusement les mises à jour de sécurité en arrière-plan. Cette seule étape comble l'écart entre la divulgation d'une vulnérabilité et la protection de votre serveur.

Étape 8 — Désactivez les services inutilisés et renforcez la sécurité de base

Chaque service qui écoute sur le réseau est une porte d'entrée potentielle, alors supprimez tout ce dont vous n'avez pas besoin. Listez ce qui est réellement en cours d'exécution et ce qui est lié à un port :

sudo systemctl list-units --type=service --state=running
sudo ss -tulpn

Si vous repérez un service que vous n'utilisez pas, désactivez-le et arrêtez-le :

sudo systemctl disable --now <service-name>

Quelques autres victoires rapides complètent la liste :

Pour une vue plus approfondie au niveau du framework de la configuration sécurisée, la Fondation OWASP publie des recommandations de durcissement et de sécurité largement respectées, à mettre en favoris lorsque votre installation évolue.

Votre liste de contrôle de 10 minutes en un coup d'œil

Gardez ce résumé à portée de main — c'est toute la routine pour sécuriser un VPS sous forme de liste de contrôle, afin que vous puissiez la répéter en quelques minutes sur chaque nouveau serveur que vous déployez :

  1. Mettez à jour tous les paquets et redémarrez si le noyau a changé.
  2. Créez un utilisateur non-root et ajoutez-le au groupe sudo.
  3. Générez une clé SSH Ed25519 et copiez la clé publique sur le serveur.
  4. Confirmez que la connexion par clé fonctionne dans un second terminal.
  5. Désactivez la connexion root et l'authentification par mot de passe dans sshd_config.
  6. Déplacez éventuellement SSH vers un port non standard.
  7. Activez UFW, refusez les connexions entrantes par défaut et autorisez uniquement les ports que vous utilisez.
  8. Installez fail2ban pour bannir automatiquement les tentatives de force brute.
  9. Activez les mises à niveau de sécurité non supervisées.
  10. Désactivez les services inutilisés et examinez ce qui écoute.

Aucune de ces étapes n'est difficile en soi, mais en sauter une laisse un vide évident. Ensemble, elles forment une base solide qui arrête la grande majorité des attaques opportunistes. À partir de là, vous pouvez ajouter des extras à mesure que vos besoins évoluent — un proxy inverse avec TLS, un outil de détection d'intrusion, une isolation par service avec des conteneurs ou une sauvegarde hors serveur en plus des instantanés du fournisseur.

Comment ApexVPS complète votre durcissement

La liste de contrôle ci-dessus durcit le système d'exploitation, mais certaines menaces se situent en dessous. Les attaques volumétriques et les pannes matérielles sont gérées au niveau de l'infrastructure, et c'est là que votre fournisseur compte. Chaque plan ApexVPS comprend une protection DDoS toujours active, de sorte qu'un flot de trafic est absorbé avant d'atteindre votre pare-feu, ainsi que des sauvegardes automatisées — quotidiennes sur Starter Pro et horaires sur Business et Enterprise — afin qu'une erreur ou une compromission ne signifie jamais repartir de zéro. Une surveillance 24h/24 et 7j/7 et un CPU et une RAM véritablement dédiés signifient qu'un voisin bruyant ne peut ni vous ralentir ni devenir votre problème.

Vous pouvez voir l'ensemble des protections sur la présentation des fonctionnalités d'ApexVPS et comparer ce que chaque offre inclut sur la page des plans et tarifs VPS. Si vous durcissez un serveur spécifiquement pour exécuter vos propres applications, notre guide d'hébergement autonome VPS se marie bien avec cette liste de contrôle. L'inscription se fait uniquement par e-mail et le paiement se fait uniquement en crypto via OxaPay — Bitcoin, Ethereum, USDT et plus de 30 crypto-monnaies, sans carte de crédit, sans compte bancaire et sans KYC.

Questions fréquemment posées

Quelle est la première chose à faire pour sécuriser un nouveau VPS ?

Mettez à jour tous les paquets avec sudo apt update && sudo apt upgrade -y, puis créez un utilisateur non-root avec les droits sudo afin d'arrêter de vous connecter en tant que root. Ces deux étapes ferment les voies d'attaque les plus courantes et les plus dommageables avant que vous configuriez quoi que ce soit d'autre.

Dois-je changer le port SSH par défaut ?

C'est facultatif. Déplacer SSH du port 22 réduit le volume de scans automatisés dans vos journaux, mais ce n'est pas une sécurité réelle en soi — l'authentification par clé, un pare-feu et fail2ban font le gros du travail. Si vous changez le port, ouvrez le nouveau dans UFW avant de redémarrer SSH pour ne pas vous retrouver verrouillé.

Ai-je besoin d'un pare-feu si j'utilise des clés SSH ?

Oui. Les clés SSH ne protègent que le service SSH ; un pare-feu comme UFW contrôle tous les autres ports de la machine. Refuser tout le trafic entrant par défaut et n'autoriser que les ports que vous utilisez réellement est un élément essentiel de toute liste de contrôle pour sécuriser un VPS, avec ou sans clés.

fail2ban est-il nécessaire sur un VPS ?

Il est fortement recommandé. Même avec les connexions par mot de passe désactivées, les bots continueront de sonder votre port SSH et d'encombrer vos journaux. fail2ban bannit automatiquement les contrevenants récidivistes, réduisant le bruit et bloquant la faible possibilité d'une tentative de force brute réussie contre n'importe quel service.

ApexVPS inclut-il une protection DDoS et des sauvegardes ?

Oui. Chaque plan comprend une protection DDoS toujours active et des sauvegardes automatisées — quotidiennes sur Starter Pro et des instantanés horaires sur Business et Enterprise — ainsi qu'une surveillance 24h/24 et 7j/7. Elles complètent votre propre durcissement du système en couvrant la couche d'infrastructure que vous ne pouvez pas sécuriser depuis l'intérieur du serveur.

Envie de faciliter le durcissement ? Découvrez la protection DDoS, les sauvegardes et les ressources dédiées de chaque plan ApexVPS →