⚠️ Dans les 60 secondes suivant la mise en ligne d'un VPS, des bots automatisés tentent déjà de s'y introduire sans exception.

Ce constat, nos équipes l'observent quotidiennement lors d'audits d'infrastructure. Pour illustrer l'ampleur du phénomène : un serveur Ubuntu vierge, sans DNS, sans annonce publique, exposé uniquement via son adresse IP brute, reçoit en moyenne plus de 200 tentatives de connexion SSH dans sa première heure de vie. Des robots automatisés parcourent en continu l'intégralité d'internet à la recherche de configurations vulnérables.

Peu importe la taille de votre organisation, startup, pme ou grand compte, les patterns d'attaque sont identiques. Et pourtant, lors de nos missions d'audit, nous retrouvons systématiquement les mêmes failles non corrigées. Ce guide détaille les sept erreurs les plus fréquentes et, surtout, comment les éliminer efficacement.

 

Erreur n°1 — mises à jour de sécurité non automatisées

Tout logiciel contient des vulnérabilités. C'est une réalité fondamentale du développement informatique. La différence entre un serveur compromis et un serveur sécurisé tient souvent à une seule chose : l'application régulière des correctifs de sécurité. Un système non patché, c'est une faille connue avec un exploit documenté et les attaquants le savent.

Un serveur qui tourne depuis 400 jours sans redémarrage ni mise à jour n'est pas une performance technique. C'est un signal d'alarme.

Mise en œuvre : activer les mises à jour automatiques

Sur Ubuntu et Debian, le paquet unattended-upgrades prend en charge l'application automatique des correctifs de sécurité :

Activation du paquet unattended-upgrades

Activation et vérification du service

Une fois configuré, vérifiez que le service est actif. Sur CentOs/RHEL, l'équivalent est dnf-automatic. L'objectif est simple : aucun patch de sécurité critique ne doit attendre une intervention manuelle.

 

Erreur n°2 — administrer le serveur directement en root

Le compte root dispose de droits absolus sur le système. Une seule erreur de manipulation, une session compromise, un script malveillant exécuté par inadvertance et c'est l'intégralité du serveur qui est exposée. Travailler en root au quotidien est une pratique à haut risque que nous déconseillons formellement.

La bonne pratique consiste à créer un compte utilisateur dédié avec des privilèges élevés uniquement lorsque nécessaire (via sudo), et de désactiver complètement la connexion root distante.

Mise en œuvre : créer un compte d'administration sécurisé

Voici la séquence recommandée pour sécuriser l'accès administrateur :

Création d'un utilisateur non-root avec droits sudo

⚠️ Impératif : testez impérativement la connexion avec le nouveau compte dans un terminal séparé AVANT de fermer votre session root.

Une fois le nouveau compte validé, désactivez la connexion root dans le fichier de configuration SSH (PermitRootLogin no) et redémarrez le service SSH.

 

Erreur n°3 — authentification SSH par mot de passe

Les mots de passe sont soumis aux attaques par force brute, aux fuites de bases de données et à l'ingénierie sociale. Une clé SSH correctement générée, en revanche, est mathématiquement impossible à craquer dans un délai raisonnable. Pourtant, une majorité de serveurs VPS restent configurés avec l'authentification par mot de passe activée.

Mise en œuvre : déployer l'authentification par clé SSH

Étape 1 — générer une paire de clés sur votre poste local (algorithme ed25519, le plus sécurisé actuellement) :

Génération d'une paire de clés ed25519

Étape 2 — transférer la clé publique sur le serveur :

Copie de la clé publique vers le serveur

Étape 3 — mettre à jour la configuration SSH (/etc/ssh/sshd_config) :

Configuration de sshd_config

Étape 4 — redémarrer le service SSH :

Redémarrage du service ssh

🔑  Règle absolue : gardez votre session courante ouverte et testez la connexion par clé dans un nouveau terminal avant toute modification irréversible.

 

Erreur n°4 — absence de pare-feu

Sans pare-feu, chaque port ouvert sur votre serveur est potentiellement accessible depuis n'importe quelle adresse IP dans le monde. Chaque service expose une surface d'attaque. La règle de base : n'autoriser que le trafic strictement nécessaire, tout le reste doit être bloqué par défaut.

Mise en œuvre : configurer UFW (Uncomplicated firewall)

UFW est l'outil de référence pour la gestion du pare-feu sur les distributions Debian/Ubuntu. Voici la configuration minimale recommandée :

Configuration UFW — politique par défaut et ouverture des ports nécessaires

Politique par défaut : tout trafic entrant est refusé, tout trafic sortant est autorisé. N'ouvrez que les ports correspondant aux services réellement actifs (SSH, HTTP, HTTPS, etc.). Chaque port inutilement ouvert est une opportunité offerte aux attaquants.

💡  si vous modifiez le port SSH par défaut (22), autorisez le nouveau port AVANT d'activer UFW sous peine de vous bloquer vous-même hors du serveur.

 

Erreur n°5 — absence de protection anti force brute

Même avec des clés SSH déployées et les mots de passe désactivés, les tentatives de connexion automatisées ne cesseront pas. Des milliers de bots scrutent en permanence le port SSH et génèrent des logs volumineux, consomment des ressources et peuvent masquer une véritable tentative d'intrusion dans le bruit ambiant.

Fail2Ban analyse les journaux système en temps réel et bannit automatiquement les adresses ip qui dépassent un seuil configurable de tentatives d'authentification échouées.

Mise en œuvre : installer et configurer Fail2Ban

Installation et configuration de base :

Installation de Fail2Ban et création du fichier de configuration local

Paramétrage recommandé pour la prison SSH :

Configuration du jail SSH — 3 tentatives max en 10 minutes, ban d'1 heure

Résultat : 3 tentatives d'authentification échouées en 10 minutes entraînent un bannissement automatique d'une heure. Ce paramétrage élimine la quasi-totalité du bruit généré par les bots de scan.

Vérification des bans actifs via Fail2Ban-client

 

Erreur n°6 — services inutiles en écoute

Une installation linux fraîche inclut souvent des services démarrés par défaut dont vous n'avez aucun besoin : serveur FTP, telnet, bases de données exposées sur des ports non filtrés, serveurs d'impression... Chacun de ces services en écoute représente une surface d'attaque supplémentaire.

La règle est simple : si un service ne remplit pas une fonction active et nécessaire, il doit être arrêté et désactivé.

Mise en œuvre : auditer et réduire la surface d'exposition

Commencez par lister tous les ports en écoute sur votre serveur :

Audit des ports en écoute avec ss -tulpn

Pour chaque port identifié, posez-vous la question : ce service est-il indispensable ? Si la réponse est non, désactivez-le :

Désactivation des services inutiles avec systemctl

Réduire la surface d'exposition est l'une des mesures de sécurité les plus efficaces et les plus souvent négligées. Moins de services actifs = moins de vecteurs d'attaque potentiels.

 

Erreur n°7 — absence de stratégie de sauvegarde

La sécurité ne se résume pas à la prévention des intrusions. Elle englobe également la capacité de récupération après incident. Un serveur compromis, un ransomware, une défaillance matérielle : si vous n'avez pas de sauvegardes récentes et testées, vous repartez de zéro.

Une bonne stratégie de sauvegarde repose sur trois principes : automatisation, externalisation (les sauvegardes ne doivent jamais résider sur le même serveur que les données) et vérification régulière de la restauration.

Mise en œuvre : automatiser les sauvegardes chiffrées

Voici un script de sauvegarde simple et efficace, à planifier via cron :

Script de sauvegarde automatisé avec chiffrement

Planification via cron pour une exécution quotidienne à 2h du matin :

Planification cron de la sauvegarde automatique

 

Checklist opérationnelle et sécurisation d'un VPS en production

Appliquez cette checklist sur chaque nouveau serveur mis en production. Aucune étape ne doit être ignorée.

 

Action de sécurité	Priorité
Mettre à jour tous les paquets système	🔴 critique
Activer les mises à jour de sécurité automatiques	🔴 critique
Créer un utilisateur non-root avec sudo	🔴 critique
Désactiver la connexion ssh directe en root	🔴 critique
Configurer l'authentification par clé ssh (ed25519)	🔴 critique
Désactiver l'authentification par mot de passe ssh	🔴 critique
Mettre en place un pare-feu ufw	🔴 critique
N'ouvrir que les ports strictement nécessaires	🔴 critique
Installer et configurer fail2ban	🟠 haute
Auditer et désactiver les services inutiles	🟠 haute
Changer le port ssh par défaut (22)	🟠 haute
Configurer des sauvegardes automatiques hors serveur	🟠 haute
Mettre en place un monitoring des logs (journalctl/siem)	🟡 recommandé
Activer l'authentification à deux facteurs (2fa) ssh	🟡 recommandé

 

Durcissement d'urgence — 10 minutes pour l'essentiel

Vous avez un serveur existant à sécuriser rapidement ? Voici la séquence minimale à appliquer immédiatement, avant même d'aborder les étapes plus avancées :

Script de durcissement rapide — les commandes essentielles à exécuter en priorité

Cette séquence couvre les vecteurs d'attaque les plus exploités. Elle ne remplace pas une sécurisation complète, mais elle réduit drastiquement votre exposition dans les premières minutes.

 

Conclusion

La réalité des cyberattaques est implacable : la majorité des compromissions de serveurs ne résultent pas de techniques sophistiquées, mais de l'exploitation de négligences basiques. Mot de passe SSH sans restriction, root accessible depuis internet, système non patché depuis des mois autant de portes ouvertes que les attaquants franchissent automatiquement.

Appliquer les sept mesures décrites dans ce guide représente une demi-journée de travail. En retour, vous éliminez la grande majorité des vecteurs d'attaque courants et vous établissez une base solide pour toute infrastructure sérieuse. La sécurité n'est pas un projet ponctuel : c'est un processus continu qui commence par ces fondamentaux.

 

ST DIGITAL accompagne les entreprises dans la sécurisation de leurs infrastructures cloud et on-premise.

Besoin d'un audit de sécurité vps ou d'une mission de hardening ?

Contactez-nous