Un VPS tout juste déployé est exposé à des attaques automatisées dans les minutes qui suivent sa mise en ligne — cette checklist vous guide à travers la première heure de durcissement qui vous permet d'en garder le contrôle.
Chaque nouveau serveur démarre avec les mêmes faiblesses : une connexion root par défaut, un accès SSH protégé uniquement par mot de passe, un pare-feu grand ouvert et aucune application automatique des correctifs. Des bots scannent en permanence l'ensemble de l'espace IPv4, donc « personne ne connaît encore mon IP » n'est jamais vrai.
Ce guide est une checklist de durcissement ordonnée, prête à copier-coller. Suivez-la de haut en bas sur une machine Debian ou Ubuntu fraîchement installée, et vous fermerez les brèches réellement exploitées par les attaquants, pas celles dont s'inquiète la sécurité de façade.
Avant de toucher au serveur
Deux décisions prises avant votre toute première connexion vous feront gagner des heures par la suite. Préparez votre clé SSH et choisissez un nom d'utilisateur non-root.
- 1
Générer une clé SSH moderne
Sur votre propre machine, exécutez ssh-keygen -t ed25519 -C "you@device". Les clés Ed25519 sont courtes, rapides et plus robustes que l'ancien standard RSA-2048.
- 2
Ne jamais laisser la clé privée sur le serveur
La moitié privée ne quitte jamais votre ordinateur portable. Vous ne copiez jamais que le fichier .pub sur les hôtes. Ignorer cette règle est la principale façon de se retrouver bloqué et de devoir tout reprovisionner.
- 3
Notez vos identifiants de provisionnement
La plupart des fournisseurs envoient par e-mail un mot de passe root temporaire ou injectent votre clé au moment du déploiement. Si une clé a été injectée, vous pouvez passer directement à la création d'un utilisateur.
Si votre hébergeur injecte votre clé SSH au moment du déploiement, vous n'avez jamais de fenêtre d'accès par mot de passe — la plus grande surface d'attaque disparaît avant même le premier démarrage.
Étape 1 — Corrigez tout, puis maintenez les correctifs à jour
Un noyau ou un OpenSSL non corrigé est la seule faille qu'aucune règle de pare-feu ne peut réparer. Mettez à jour le système avant de configurer quoi que ce soit d'autre.
- Debian/Ubuntu : apt update && apt full-upgrade -y puis redémarrez si le noyau a changé.
- Activez unattended-upgrades pour que les correctifs de sécurité s'appliquent automatiquement : apt install unattended-upgrades && dpkg-reconfigure unattended-upgrades.
- Redémarrez selon un calendrier que vous maîtrisez — configurez Unattended-Upgrade::Automatic-Reboot sur une heure creuse plutôt que de laisser les mises à jour du noyau à moitié appliquées.
Étape 2 — Créez un véritable utilisateur et mettez root à la retraite
Se connecter en tant que root signifie qu'une seule session compromise donne le contrôle total de la machine, sans aucune piste d'audit. Créez-vous plutôt un compte sudo nominatif.
- 1
Ajoutez l'utilisateur
adduser deploy puis usermod -aG sudo deploy (utilisez wheel sur les systèmes de la famille RHEL).
- 2
Installez votre clé pour cet utilisateur
Depuis votre ordinateur portable : ssh-copy-id deploy@your-server-ip. Cela écrit votre clé publique dans ~/.ssh/authorized_keys avec les permissions correctes.
- 3
Testez avant de fermer la porte
Ouvrez un second terminal et vérifiez que vous pouvez faire ssh deploy@server et exécuter sudo -v. Ne désactivez jamais root ou les mots de passe tant qu'une nouvelle session ne fonctionne pas.
Règle d'or du durcissement SSH : gardez votre session actuelle ouverte et prouvez que la nouvelle connexion fonctionne dans une seconde fenêtre avant de modifier le moindre paramètre d'authentification. Cette seule habitude évite presque tous les blocages.
Étape 3 — Le durcissement SSH, la partie la plus importante
SSH est la porte d'entrée de tout VPS, et c'est là que se concentre la majorité des tentatives de connexion automatisées. Modifiez /etc/ssh/sshd_config (ou un fichier de configuration dans /etc/ssh/sshd_config.d/) et définissez les clés suivantes.
Validez la syntaxe avec sshd -t, puis exécutez systemctl restart ssh. Si sshd -t signale une erreur, corrigez-la avant de redémarrer, sous peine de faire planter le démon.
Changer le port SSH par défaut (22) est optionnel et ne fait que réduire le bruit dans les logs — c'est de l'obscurité, pas de la sécurité. Une fois PasswordAuthentication désactivé, les bots qui scannent les ports n'ont plus rien à deviner : concentrez vos efforts sur les clés plutôt que sur des jeux de ports.
Étape 4 — Activez un pare-feu par défaut restrictif
Un démon SSH durci partage toujours la machine avec tous les autres services en écoute. Un pare-feu impose par défaut la règle « fermé sauf si je l'ai ouvert ».
- 1
Définissez la base
Avec ufw : ufw default deny incoming et ufw default allow outgoing.
- 2
N'autorisez que ce que vous servez
ufw allow OpenSSH, puis ufw allow 80,443/tcp uniquement si cette machine héberge réellement du trafic web.
- 3
Activez et vérifiez
ufw enable then ufw status verbose. Tout ce qui n'est pas listé est désormais inaccessible depuis internet.
Ajoutez la règle SSH au pare-feu avant d'activer ufw. Activer un pare-feu par défaut restrictif sans règle d'autorisation pour votre propre port coupera votre session.
Étape 5 — Ralentissez le brute-force avec Fail2ban
Même mots de passe désactivés, les bots continuent de frapper à la porte et gonflent vos logs. Fail2ban bannit les récidivistes au niveau du pare-feu.
- apt install fail2ban — la jail sshd fournie par défaut fonctionne dès l'installation.
- Copiez jail.conf vers jail.local, puis ajustez bantime à la hausse (ex. 1h) et maxretry à la baisse (ex. 3) selon vos préférences.
- Vérifiez que ça fonctionne avec fail2ban-client status sshd pour voir le nombre d'IP bannies.
Étape 6 — Réduisez la surface d'attaque
Le service le plus sûr est celui qui ne tourne pas. Auditez ce qui est en écoute et supprimez ce dont vous n'avez pas besoin.
Auditez les ports ouverts
ss -tulpn liste tous les sockets en écoute et le processus derrière chacun. Examinez tout ce que vous n'avez pas démarré délibérément.
Supprimez les paquets inutiles
Désactivez ou désinstallez les services que vous n'utilisez pas — une base de données ou un agent de messagerie laissé actif est un risque pur et simple.
Isolez les services
Liez les démons internes comme les bases de données à 127.0.0.1 afin qu'ils ne soient jamais exposés, même en cas de faille du pare-feu.
Verrouillez les permissions
Assurez-vous que ~/.ssh est en 700 et authorized_keys en 600. Des permissions incorrectes font que sshd ignore silencieusement votre clé.
Étape 7 — Journalisez, surveillez et connaissez votre état de référence
Le durcissement n'est pas une opération ponctuelle. Vous devez être en mesure de remarquer tout changement.
- Passez en revue l'activité d'authentification avec journalctl -u ssh ou lastb pour les tentatives de connexion échouées.
- Envisagez auditd pour conserver un historique inviolable des actions privilégiées.
- Conservez une sauvegarde hors serveur de /etc et de vos données, afin qu'une machine compromise puisse être reconstruite proprement plutôt que d'être considérée comme fiable après coup.
Là où l'hébergeur lui-même fait la différence
Le durcissement logiciel protège l'OS, mais c'est le fournisseur qui décide de ce qui se trouve en dessous — le filtrage réseau, la traçabilité des paiements, et si une identité est un jour associée au serveur. Chez ChainVPS, chaque offre inclut un filtrage DDoS et une bande passante illimitée, et les serveurs sont réglés via un solde crypto prépayé disponible en 21 cryptomonnaies, dont Monero, sans KYC. Si votre modèle de menace inclut le fait de ne jamais lier un serveur à votre identité, nos VPS offshore sont conçus exactement pour ça.
L'emplacement fait aussi partie du durcissement : six de nos quinze régions sont des juridictions à haut niveau de confidentialité (NL, CH, RO, IS, MD, LU). Associer un OS durci à un serveur dédié offshore permet de resserrer à la fois la surface logicielle et la surface juridique.
La checklist en une heure, condensée
- Mise à jour complète du système + correctifs de sécurité automatiques activés
- Utilisateur sudo nominatif créé, clé installée, connexion testée
- Connexion SSH root et authentification par mot de passe toutes deux désactivées
- Configuration SSH validée avec sshd -t et rechargée
- Pare-feu par défaut restrictif actif, seuls les ports nécessaires ouverts
- Fail2ban actif sur la jail sshd
- Ports ouverts audités, services inutilisés supprimés
- Sauvegarde hors serveur et revue des logs en place
Dois-je changer le port SSH pour un autre que le 22 ?
C'est optionnel et cela ne réduit que le bruit dans les logs, pas le risque réel. Une fois l'authentification par mot de passe désactivée et les clés obligatoires, changer de port ajoute de l'obscurité plutôt que de la sécurité — priorisez d'abord la désactivation des mots de passe.
Est-il sûr de désactiver l'authentification par mot de passe si je n'ai qu'une seule clé ?
Oui, à condition d'avoir testé la connexion par clé dans une session séparée et de conserver une sauvegarde de la clé privée. De nombreux fournisseurs proposent également une console web ou un mode de récupération, si bien que vous n'êtes jamais vraiment bloqué hors du matériel.
Ai-je encore besoin d'un pare-feu si SSH est le seul service actif ?
Oui. Un pare-feu par défaut restrictif vous protège des services que vous avez oublié avoir installés, ainsi que de tout ce qu'un futur paquet pourrait discrètement se mettre à écouter. Cela ne coûte rien et élimine les mauvaises surprises.
À quelle fréquence dois-je revoir le durcissement ?
Les mises à jour de sécurité automatiques prennent en charge le travail quotidien, mais vérifiez les ports en écoute et les logs d'authentification après toute installation logicielle majeure, et au moins une fois par mois. Considérez une base durcie comme quelque chose à vérifier régulièrement, pas comme un réglage définitif qu'on oublie ensuite.
