Sécuriser un serveur VPS Linux en 30 minutes : la liste de contrôle après la livraison

Pourquoi sécuriser un VPS dès la première heure

Sécuriser un VPS commence au moment où l’hébergeur vous envoie l’adresse IP et le mot de passe root. Dès qu’une machine répond sur Internet, des robots testent son port SSH avec des listes d’identifiants courants, souvent dans les minutes qui suivent. Un serveur livré « nu » n’a ni pare-feu, ni limitation des tentatives, ni mises à jour automatiques. Les étapes ci-dessous ferment ces portes dans l’ordre, avec les commandes exactes pour Debian et Ubuntu et l’équivalent AlmaLinux quand il tient en une ligne.

La procédure s’applique à un serveur VPS Linux avec accès root, livré sous Debian 12, Ubuntu 22.04 ou 24.04, ou AlmaLinux 9, et fonctionne aussi sur un serveur dédié fraîchement installé. Avant de commencer, réunissez :

• l’adresse IP du serveur et le mot de passe root de livraison ;
• un client SSH (terminal sous Linux et macOS, Windows Terminal ou PuTTY sous Windows) ;
• si possible, l’adresse IP fixe de votre bureau ou de votre VPN, pour la mettre en liste blanche ;
• une adresse e-mail pour les rapports de mises à jour.

Les durées sont des ordres de grandeur pour un administrateur qui connaît déjà les commandes ; comptez le double la première fois. Ce guide traite le système ; les bonnes pratiques côté application (CMS, extensions, comptes) sont détaillées dans le guide renforcer durablement la sécurité de son hébergement.

Minutes 0 à 5 : mettre à jour le système et faire l’inventaire

Connectez-vous en root et mettez à jour tous les paquets : une image de VPS a souvent plusieurs semaines de retard sur les correctifs de sécurité.

ssh root@ADRESSE_IP
apt update && apt full-upgrade -y
apt autoremove -y

Sur AlmaLinux, la même opération s’écrit dnf upgrade -y. Si le noyau a été mis à jour, redémarrez tout de suite avec reboot : sur Ubuntu, la présence du fichier /var/run/reboot-required le signale ; sur AlmaLinux, dnf needs-restarting -r donne la réponse.

Repérer ce qui écoute déjà sur le réseau

Listez les services qui attendent des connexions : tout ce qui apparaît ici est joignable depuis Internet tant qu’aucune règle ne l’interdit.

ss -tulpn

Sur une image minimale, seul sshd devrait apparaître, avec parfois un résolveur DNS local sur 127.0.0.53. Une base de données qui écoute sur 0.0.0.0 doit être fermée par le pare-feu ou reconfigurée sur 127.0.0.1. Désinstallez ce que vous n’utiliserez pas : un service absent n’a pas besoin d’être patché.

Minutes 5 à 10 : créer un utilisateur non root avec sudo

Travailler en root aggrave chaque erreur de frappe et chaque vol d’identifiant. Créez un compte nominatif avec droit d’élévation et réservez root au secours.

adduser prenom
usermod -aG sudo prenom

Sur AlmaLinux, le groupe d’administration s’appelle wheel et la création se fait en deux commandes : useradd -m prenom && passwd prenom, puis usermod -aG wheel prenom. Choisissez un mot de passe long et unique : sudo le demande même quand SSH ne l’accepte plus.

Vérifiez depuis un second terminal que le compte fonctionne et peut passer root :

ssh prenom@ADRESSE_IP
sudo -i

À plusieurs administrateurs, créez un compte par personne : un compte partagé rend les journaux inexploitables et empêche de révoquer un seul accès.

Minutes 10 à 15 : clés SSH et désactivation du mot de passe

Les attaques par dictionnaire visent les mots de passe ; une clé SSH les rend inopérantes. Générez-la sur votre poste, jamais sur le serveur, et protégez-la par une phrase de passe.

ssh-keygen -t ed25519 -C "prenom@poste-de-travail"
ssh-copy-id prenom@ADRESSE_IP

Avec PuTTY, générez la clé dans PuTTYgen et collez la clé publique dans ~/.ssh/authorized_keys du compte nominatif. Une nouvelle connexion ne doit plus demander que la phrase de passe de la clé.

Sécuriser le VPS Debian ou Ubuntu : le fichier sshd_config

Debian 12, Ubuntu 22.04 et suivants et AlmaLinux 9 lisent /etc/ssh/sshd_config.d/ avant le fichier principal, et la première valeur rencontrée l’emporte. Créez donc un fichier dédié :

# /etc/ssh/sshd_config.d/10-durcissement.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
X11Forwarding no

Sur Ubuntu, un fichier 50-cloud-init.conf remet parfois PasswordAuthentication yes ; le préfixe 10- garantit que le vôtre est lu en premier. Contrôlez la syntaxe puis redémarrez le service, nommé ssh sur Debian et Ubuntu, sshd sur AlmaLinux :

sshd -t
systemctl restart ssh

Changer le port SSH : utile contre le bruit, pas une protection

Déplacer SSH vers un port haut réduit le volume de tentatives dans les journaux, rien de plus : un scan trouve le nouveau port en quelques secondes. Si vous le faites, ajoutez Port 2222 dans le même fichier, ouvrez ce port dans le pare-feu avant de redémarrer SSH, puis vérifiez avec ss -tlnp que sshd écoute dessus. Sur AlmaLinux, prévenez SELinux : semanage port -a -t ssh_port_t -p tcp 2222. La vraie protection reste la clé et le refus du mot de passe.

Minutes 15 à 20 : un pare-feu avec des règles minimales

Le principe : tout bloquer en entrée, n’ouvrir que les ports utiles, laisser sortir. Sur Debian et Ubuntu, ufw est le plus rapide ; il pilote nftables ou iptables en dessous.

apt install -y ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80,443/tcp
ufw enable
ufw status verbose

Si vous avez changé le port SSH, remplacez 22/tcp avant ufw enable. Avec une IP fixe au bureau, restreignez SSH : ufw allow from 203.0.113.10 to any port 22 proto tcp, puis supprimez la règle générale. Sur AlmaLinux, firewalld est déjà actif : firewall-cmd --permanent --add-service=http --add-service=https, firewall-cmd --permanent --remove-service=cockpit, puis firewall-cmd --reload.

L’équivalent en nftables pur

Sans ufw, un fichier /etc/nftables.conf minimal suffit, testé par nft -f /etc/nftables.conf puis activé par systemctl enable --now nftables :

#!/usr/sbin/nft -f
flush ruleset
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif lo accept
    ct state established,related accept
    ct state invalid drop
    ip protocol icmp accept
    ip6 nexthdr icmpv6 accept
    tcp dport { 22, 80, 443 } accept
  }
  chain forward { type filter hook forward priority 0; policy drop; }
  chain output { type filter hook output priority 0; policy accept; }
}

Quels ports ouvrir selon l’usage du VPS

Minutes 20 à 25 : fail2ban contre les tentatives SSH

Même sans mot de passe accepté, les tentatives répétées encombrent les journaux et consomment du processeur. fail2ban lit les échecs et bannit l’adresse source dans le pare-feu pour une durée définie.

apt install -y fail2ban

Sur AlmaLinux, le paquet vient du dépôt EPEL : dnf install -y epel-release puis dnf install -y fail2ban fail2ban-firewalld. Ne modifiez jamais jail.conf, qui est écrasé à chaque mise à jour ; créez /etc/fail2ban/jail.local :

fail2ban ssh : les réglages minimaux

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
ignoreip = 127.0.0.1/8 ::1 203.0.113.10

[sshd]
enabled = true
backend = systemd
port    = ssh

La ligne backend = systemd compte sur Debian 12 et les images Ubuntu récentes, qui n’installent plus rsyslog : sans elle, fail2ban cherche un /var/log/auth.log absent et refuse de démarrer la prison. Remplacez 203.0.113.10 par votre IP fixe pour ne jamais vous bannir vous-même, et adaptez port si nécessaire. Activez puis contrôlez :

systemctl enable --now fail2ban
fail2ban-client status sshd

Le compteur Currently banned monte en général dans l’heure. Pour lever un bannissement : fail2ban-client set sshd unbanip ADRESSE. Un bantime d’une heure suffit : les robots changent d’adresse, et un bannissement de plusieurs jours augmente surtout le risque de vous bloquer depuis un réseau mobile.

Minutes 25 à 30 : mises à jour automatiques, fuseau horaire et NTP

Un serveur à jour à la livraison redevient vulnérable à la première faille publiée. Sur Debian et Ubuntu, unattended-upgrades n’applique par défaut que les dépôts de sécurité, ce qui limite le risque de régression.

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

Répondez « Oui » : le fichier /etc/apt/apt.conf.d/20auto-upgrades est créé. Dans /etc/apt/apt.conf.d/50unattended-upgrades, renseignez ensuite deux lignes : Unattended-Upgrade::Mail "vous@exemple.fr"; pour recevoir le compte rendu, et Unattended-Upgrade::Automatic-Reboot "false"; pour décider vous-même des redémarrages. Vérifiez avec unattended-upgrade --dry-run --debug. Sur AlmaLinux : dnf install -y dnf-automatic, puis dans /etc/dnf/automatic.conf mettez upgrade_type = security et apply_updates = yes, et lancez systemctl enable --now dnf-automatic.timer.

Une horloge juste pour des journaux lisibles

Une horloge décalée fausse les horodatages, perturbe la validation des certificats TLS et dérègle la fenêtre findtime de fail2ban. Réglez le fuseau horaire et activez la synchronisation :

timedatectl set-timezone Europe/Paris
timedatectl set-ntp true
timedatectl status

La ligne System clock synchronized: yes doit apparaître. Debian et Ubuntu utilisent systemd-timesyncd, AlmaLinux utilise chrony ; chronyc tracking y affiche l’écart courant. Les 30 minutes sont écoulées : le serveur est à jour, n’accepte que des clés SSH sur un compte nominatif, filtre ses ports, bannit les robots et se corrigera seul.

Après les 30 minutes : sauvegardes hors serveur et surveillance

Rien de ce qui précède ne protège contre une suppression accidentelle, un disque défaillant ou un rançongiciel. Seule une copie stockée ailleurs que sur le VPS le fait. Pour les sites hébergés chez NovaHoster, la sauvegarde automatique applique ce principe : copie quotidienne hors de l’hébergement, restauration en un clic. Sur un VPS administré par vos soins, montez l’équivalent :

1. Choisissez une destination externe : stockage objet compatible S3, serveur de sauvegarde distinct ou NAS joignable par SFTP.
2. Installez un outil qui chiffre et déduplique, restic ou borgbackup, présents dans les dépôts Debian, Ubuntu et EPEL.
3. Sauvegardez au minimum /etc, /home, /var/www et les dumps produits par mysqldump ou pg_dump.
4. Planifiez une exécution quotidienne par cron ou minuteur systemd, avec 7 jours de rétention et un point mensuel.
5. Testez une restauration complète sur un autre serveur dans le mois, puis chaque trimestre. Une sauvegarde jamais restaurée n’est qu’une hypothèse.

Surveiller sans outil lourd

Pour une revue hebdomadaire : uptime pour la charge, df -h pour le disque, free -m pour la mémoire, last -a | head pour les dernières connexions, et le journal système pour les erreurs :

journalctl -p err -b
journalctl -u ssh --since today

Pour être prévenu sans regarder, installez logwatch, qui envoie un résumé quotidien par e-mail, et abonnez le serveur à une supervision externe qui teste le port 443 toutes les minutes. La lecture des journaux applicatifs, dès qu’un site renvoie une erreur 500, est expliquée dans le guide lire les logs et diagnostiquer une application en production.

Si Plesk est installé sur le VPS

Plesk Obsidian regroupe plusieurs de ces fonctions dans son interface, mais ne dispense pas du durcissement système ci-dessus : SSH, pare-feu et mises à jour du système restent de votre ressort. Dans Plesk, passez en revue quatre points.

• Mises à jour Plesk : dans « Outils & Paramètres », rubrique « Mises à jour », activez l’installation automatique des mises à jour de Plesk. Vérifiez aussi que les versions de PHP servies aux sites sont supportées ; le guide sur la faille PHP2Shell montre comment changer de version PHP sans casser un site.
• Imunify360 : si l’extension est installée, activez le pare-feu applicatif et le scanner de fichiers, et lisez la liste des incidents chaque semaine. Sur un VPS, sa licence est séparée de celle de Plesk ; vérifiez qu’elle est active.
• Pare-feu et force brute : l’extension « Pare-feu Plesk » et la rubrique « Protection contre les attaques par force brute (Fail2Ban) » pilotent les mêmes mécanismes que ceux configurés plus haut. Choisissez l’un ou l’autre pour éviter des règles contradictoires.
• Accès à l’interface : limitez le port 8443 à vos adresses IP dans « Restriction de l’accès administratif » et activez l’authentification à deux facteurs.

Le gestionnaire de sauvegarde de Plesk peut envoyer les archives vers un stockage FTP ou S3 distant ; il remplit le rôle décrit plus haut à condition que la destination soit externe au serveur.

Liste de contrôle pour sécuriser un VPS après la livraison

Cochez chaque point avant la mise en production. La liste sert aussi lors d’un audit ou d’un changement d’administrateur.

• Système entièrement mis à jour et redémarré si le noyau a changé.
• Inventaire des services en écoute fait avec ss -tulpn ; services inutiles désinstallés.
• Compte nominatif créé, membre de sudo ou wheel, testé.
• Clé SSH ed25519 déployée ; connexion root et connexion par mot de passe refusées ; sshd -t sans erreur.
• Pare-feu actif avec politique « tout refuser en entrée » et seulement les ports du tableau.
• fail2ban démarré, prison sshd active, votre IP fixe dans ignoreip.
• Mises à jour de sécurité automatiques configurées, rapport envoyé par e-mail.
• Fuseau horaire Europe/Paris et synchronisation NTP confirmée.
• Sauvegarde quotidienne vers une destination externe, restauration testée.
• Résumé quotidien des journaux et supervision externe du port 443 en place.
• Si Plesk : mises à jour automatiques, Imunify360 actif, accès admin restreint, 2FA.
• Mot de passe root initial changé et conservé dans un gestionnaire de mots de passe.

Sécuriser un VPS sans le faire soi-même : l’infogérance

Ces trente minutes ne sont que le début. Un serveur demande ensuite une veille sur les failles publiées, des redémarrages planifiés, une lecture régulière des journaux et une réponse rapide quand une alerte tombe un dimanche soir. Pour une PME ou une agence sans administrateur système, c’est souvent cette routine, plus que l’installation, qui pose problème.

L’infogérance serveur de NovaHoster prend en charge ce suivi à partir de 49 € HT par mois : monitoring, mises à jour système et sécurité, durcissement du serveur, intervention sur incident et support 7j/7 assuré par des développeurs. Elle s’applique à un VPS comme à un serveur dédié hébergé en France, où elle est incluse chaque année. Les étapes de ce guide sont alors réalisées et documentées à la livraison, et la liste de contrôle devient un compte rendu que vous recevez plutôt qu’une tâche à exécuter.

Si vous gardez la main, ouvrez une demande depuis l’Espace client dès qu’un doute apparaît sur une alerte ou une connexion inconnue dans last. Indiquez le système, l’heure exacte et le message concerné, jamais de clé privée ni de mot de passe.

Guides liés

Pour aller plus loin sur le même sujet, et sur ce qui l’entoure :

• Détecter et traiter un malware avec Imunify360 — Apprenez à interpréter une alerte Imunify360, vérifier un fichier infecté, utiliser la quarantaine et sécuriser votre site sans supprimer…
• Comprendre CloudLinux, LVE et CageFS — Découvrez comment CloudLinux limite les ressources et isole les comptes d’hébergement avec LVE et CageFS, ainsi que les symptômes d’une…
• Faille PHP2Shell : mettre PHP à jour sur WordPress et PrestaShop — Versions de PHP corrigées, vérification et changement de version dans Plesk, signes de piratage et marche à suivre selon votre offre…
• Administrer un abonnement Plesk sans interrompre son site — Découvrez une méthode fiable pour administrer un abonnement Plesk, modifier les réglages d’un domaine et limiter les risques avant chaque…
• Changer d’hébergeur WordPress sans perdre son référencement : la méthode complète, phase par phase — Changer d’hébergeur WordPress sans perdre son référencement : préparation, copie, test, bascule DNS avec TTL abaissé, vérifications SEO et…

Sources techniques

[1] ANSSI — Recommandations de sécurité relatives à un système GNU/Linux [2] Debian Wiki — UnattendedUpgrades [3] Debian — Securing Debian Manual [4] Ubuntu Documentation — UFW (Uncomplicated Firewall) [5] OpenSSH — Manuel sshd_config [6] fail2ban — Dépôt officiel et documentation