Pourquoi votre VPS est vulnérable dès la livraison
Dès qu'une adresse IP est allouée à votre serveur, des robots automatisés commencent à la scanner. Shodan, Censys et des milliers de bots malveillants référencient en permanence les ports ouverts sur Internet. Un serveur Linux vierge expose par défaut le port 22 en SSH avec l'utilisateur root accessible depuis n'importe quelle adresse IP du monde. Si votre mot de passe root est faible — ou si vous avez réutilisé un mot de passe déjà compromis dans d'autres fuites de données — votre serveur peut être compromis en quelques heures, voire en quelques minutes. Sans pare-feu, tous les ports ouverts par vos futures applications seront également accessibles sans restriction. Sans système de détection d'intrusion, aucune alerte ne vous préviendra d'une attaque par force brute en cours. Ce guide corrige ces trois problèmes fondamentaux avec des outils éprouvés, disponibles directement dans les dépôts officiels de votre distribution.
Ce que ce guide met en place
- Utilisateur non-root avec sudo — réduit la surface d'attaque en désactivant les connexions directes en tant que root
- Authentification par clé SSH — élimine les attaques par force brute sur les mots de passe, seule votre clé privée permet l'accès
- Désactivation de l'accès root SSH — même si le mot de passe root est compromis, la connexion directe reste impossible
- UFW (pare-feu) — bloque par défaut tout trafic entrant et n'autorise que les ports explicitement déclarés
- fail2ban — bannit automatiquement les adresses IP qui multiplient les tentatives de connexion échouées
- Mises à jour de sécurité automatiques — les correctifs critiques s'appliquent sans intervention manuelle quotidienne
- Synchronisation de l'horloge système — garantit des journaux cohérents et des certificats TLS valides
Prérequis avant de commencer
Avant de suivre ce guide, assurez-vous de disposer de tout ce qui est nécessaire. Une préparation correcte vous évitera d'être bloqué en cours de route, en particulier au moment de la configuration SSH où une erreur peut vous couper l'accès au serveur.
Ce dont vous avez besoin
- Accès root SSH fonctionnel — vous devez pouvoir vous connecter avec
ssh [email protected]avant de commencer - Ubuntu 22.04 LTS ou Debian 12 — ce guide est testé sur ces deux distributions, les commandes sont identiques
- Une paire de clés SSH générée localement — lancez
ssh-keygen -t ed25519sur votre machine si vous n'en avez pas encore - Un terminal avec deux onglets ouverts — gardez toujours une session root active pendant la configuration SSH pour éviter tout blocage
Les 7 étapes de durcissement
Mettre à jour le système
Commencez par synchroniser la liste des paquets et appliquer tous les correctifs disponibles : apt update && apt upgrade -y. Redémarrez si un nouveau noyau a été installé : reboot. Reconnectez-vous en root après le redémarrage avant de passer à l'étape suivante.
Créer un utilisateur non-root avec sudo
Créez un nouvel utilisateur qui sera votre compte de travail quotidien. Remplacez deploy par le nom de votre choix : adduser deploy. Suivez les invites pour définir un mot de passe fort. Ajoutez ensuite cet utilisateur au groupe sudo : usermod -aG sudo deploy. Vérifiez que l'ajout a fonctionné : groups deploy doit afficher deploy sudo.
Copier votre clé SSH vers le nouvel utilisateur
Depuis votre machine locale, copiez votre clé publique vers le compte deploy : ssh-copy-id [email protected]. Si ssh-copy-id n'est pas disponible, copiez manuellement en vous connectant en SSH en tant que deploy, puis exécutez : mkdir -p ~/.ssh && chmod 700 ~/.ssh et collez votre clé publique dans ~/.ssh/authorized_keys avec chmod 600 ~/.ssh/authorized_keys. Testez immédiatement la connexion dans un nouvel onglet : ssh [email protected] — ne fermez pas la session root tant que cette connexion n'est pas confirmée.
Durcir la configuration SSH
Éditez le fichier de configuration du démon SSH : nano /etc/ssh/sshd_config. Modifiez ou ajoutez ces directives : PermitRootLogin no pour interdire l'accès root direct, PasswordAuthentication no pour désactiver l'authentification par mot de passe, et optionnellement Port 2222 pour changer le port d'écoute (n'oubliez pas d'ouvrir ce port dans UFW avant de redémarrer). Rechargez la configuration : systemctl reload sshd. Testez immédiatement la connexion avec le nouvel utilisateur depuis un autre terminal avant de fermer votre session actuelle.
Configurer UFW (pare-feu)
Installez UFW si nécessaire : apt install ufw -y. Définissez la politique par défaut : ufw default deny incoming et ufw default allow outgoing. Autorisez les ports dont vous avez besoin — si vous avez changé le port SSH : ufw allow 2222/tcp, sinon ufw allow 22/tcp. Ajoutez les ports web : ufw allow 80/tcp et ufw allow 443/tcp. Activez le pare-feu : ufw enable. Confirmez avec Y quand demandé. Vérifiez l'état : ufw status verbose.
Installer et configurer fail2ban
Installez fail2ban : apt install fail2ban -y. Créez un fichier de configuration local pour éviter que vos réglages soient écrasés lors des mises à jour : cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local. Éditez jail.local pour activer la protection SSH : dans la section [sshd], assurez-vous que enabled = true est présent et réglez bantime = 1h, findtime = 10m, maxretry = 5. Redémarrez et activez le service : systemctl enable --now fail2ban. Vérifiez que la jail SSH est active : fail2ban-client status sshd.
Activer les mises à jour de sécurité automatiques
Installez le paquet unattended-upgrades : apt install unattended-upgrades -y. Lancez l'assistant de configuration : dpkg-reconfigure -plow unattended-upgrades et répondez Yes. Pour vérifier que les mises à jour automatiques de sécurité sont bien activées, consultez /etc/apt/apt.conf.d/20auto-upgrades : les deux lignes APT::Periodic::Update-Package-Lists "1"; et APT::Periodic::Unattended-Upgrade "1"; doivent être présentes. Assurez-vous également que systemd-timesyncd est actif pour maintenir l'horloge à jour : systemctl status systemd-timesyncd.
Conseil critique : testez TOUJOURS la connexion SSH avec votre nouvel utilisateur dans un deuxième terminal AVANT de fermer votre session root. Si vous fermez la session root sans avoir vérifié que l'authentification par clé fonctionne pour deploy, vous risquez d'être définitivement bloqué hors de votre serveur. En cas de doute, passez par la console KVM/VNC disponible dans votre panneau de contrôle ServOrbit.
Aller plus loin après le durcissement initial
Une fois les sept étapes complétées, votre serveur est considérablement plus sécurisé qu'à sa livraison. Mais la sécurité est un processus continu, pas un état figé. Plusieurs outils complémentaires peuvent renforcer encore votre posture de sécurité selon votre contexte. Pour les environnements qui doivent répondre à des exigences de conformité (RGPD, PCI-DSS, ISO 27001), installez auditd : apt install auditd -y puis systemctl enable --now auditd. Ce démon journalise tous les appels système sensibles — exécution de commandes, modifications de fichiers, connexions — et facilite les audits réglementaires. Pour une protection plus avancée contre les botnets et les scans coordonnés, CrowdSec est une excellente alternative à fail2ban : il analyse les comportements de manière collaborative, partage les réputations d'IP entre ses utilisateurs et dispose de tableaux de bord de supervision modernes. Notre article dédié détaille son installation et sa configuration sur Ubuntu et Debian.
fail2ban vs CrowdSec : lequel choisir ?
| Critère | fail2ban | CrowdSec |
|---|---|---|
| Facilité d'installation | Très simple (apt) | Simple (script officiel) |
| Intelligence collective | Non (local uniquement) | Oui (base partagée) |
| Interface de supervision | CLI uniquement | Dashboard web inclus |
| Consommation ressources | Très faible | Faible à modérée |
| Idéal pour | Serveurs simples, débutants | Infras multi-serveurs, compliance |
Dépannage : cas courants après durcissement
Même avec une procédure soigneuse, il arrive qu'on se retrouve bloqué ou confronté à des comportements inattendus. Voici les trois situations les plus fréquentes et comment les résoudre. Premier cas : vous vous êtes bloqué hors SSH. Connectez-vous via la console KVM ou VNC de votre panneau ServOrbit, qui donne un accès direct au serveur indépendamment de SSH. Une fois connecté en console, vous pouvez corriger la configuration sshd, ajouter votre clé dans authorized_keys ou réinitialiser un mot de passe. Deuxième cas : fail2ban a banni votre propre adresse IP. Débannissez-vous depuis la console ou depuis une autre IP : fail2ban-client set sshd unbanip VOTRE_IP. Pour éviter que cela se reproduise, ajoutez votre IP fixe dans la section [DEFAULT] de jail.local : ignoreip = 127.0.0.1/8 VOTRE_IP. Troisième cas : vous avez changé le port SSH mais oublié de l'ouvrir dans UFW avant de relancer sshd. Reconnectez-vous en console, ajoutez la règle manquante ufw allow 2222/tcp et relancez ufw reload.
Conclusion
En moins d'une heure, vous avez transformé un serveur vulnérable en une base solide : l'accès root SSH est désactivé, seules des clés cryptographiques permettent de se connecter, un pare-feu filtre tout trafic non autorisé, fail2ban bloque automatiquement les attaquants et les correctifs de sécurité s'appliquent sans intervention manuelle. Ces sept étapes constituent le minimum absolu pour tout serveur exposé à Internet. Elles ne remplacent pas une sécurisation applicative (HTTPS, headers de sécurité, validation des entrées) mais elles ferment les vecteurs d'attaque les plus exploités sur les VPS Linux. Pensez à les documenter dans votre runbook d'équipe et à les appliquer systématiquement à chaque nouveau serveur que vous provisionnez.
