Dernière mise à jour : septembre 2026
Chaque serveur connecté à Internet est scanné en permanence par des bots automatisés. Ils testent les ports ouverts, tentent des connexions SSH avec des identifiants courants, cherchent des services non patchés à exploiter. Un serveur mal sécurisé peut être compromis en quelques heures — parfois en quelques minutes.
Sécuriser un serveur n’est pas une action ponctuelle : c’est un ensemble de bonnes pratiques à mettre en place dès l’installation et à maintenir dans le temps. Voici les mesures essentielles, classées par ordre de priorité.
1. Sécuriser l’accès SSH
SSH est la porte d’entrée principale de votre serveur. C’est aussi la première cible des attaques automatisées. Plusieurs mesures complémentaires réduisent drastiquement la surface d’attaque :
Utiliser l’authentification par clé
L’authentification par clé SSH est bien plus sûre qu’un mot de passe : les clés ont généralement 2048 ou 4096 bits, ce qui les rend pratiquement impossibles à brute-forcer. Chaque utilisateur génère une paire clé publique / clé privée. La clé publique est placée sur le serveur, la clé privée reste sur la machine de l’administrateur — elle ne transite jamais sur le réseau.
Une fois les clés en place, désactivez l’authentification par mot de passe dans la configuration SSH :
PasswordAuthentication no
PubkeyAuthentication yesDésactiver la connexion root
Ne jamais se connecter directement en root. Créez un utilisateur avec des droits sudo et désactivez la connexion root dans /etc/ssh/sshd_config :
PermitRootLogin no
AllowUsers votre-utilisateurLa directive AllowUsers restreint SSH aux seuls utilisateurs listés — tout le reste est refusé, même avec un mot de passe valide.
Changer le port SSH
Le port 22 est le port par défaut de SSH. Les bots le ciblent en priorité. Changer vers un port non standard (par exemple 2222 ou un autre de votre choix entre 1024 et 65535) élimine la majorité des scans automatisés. Ce n’est pas une mesure de sécurité en soi — un attaquant déterminé trouvera le port — mais ça réduit considérablement le bruit dans les logs et les tentatives de brute-force.
Port 2222Après chaque modification, redémarrez le service SSH (systemctl restart sshd) et testez la connexion dans un second terminal avant de fermer la session active — une erreur de configuration peut vous verrouiller hors du serveur.
2. Configurer le pare-feu
Un pare-feu contrôle quel trafic réseau est autorisé à entrer et sortir du serveur. La règle de base : tout fermer par défaut, puis ouvrir uniquement les ports nécessaires.
UFW (Uncomplicated Firewall) est l’outil standard sur Ubuntu et Debian. Sa syntaxe est simple et lisible :
# Politique par défaut : tout bloquer en entrée
sudo ufw default deny incoming
sudo ufw default allow outgoing
# Ouvrir les ports nécessaires
sudo ufw allow 2222/tcp # SSH (votre port personnalisé)
sudo ufw allow 80/tcp # HTTP
sudo ufw allow 443/tcp # HTTPS
# Activer le pare-feu
sudo ufw enablePour les serveurs qui hébergent uniquement des sites web, ces trois ports suffisent. Chaque port supplémentaire ouvert est un point d’entrée potentiel — n’ouvrez un port que si un service en production l’exige, et fermez-le dès que le service n’est plus utilisé.
Si votre serveur gère aussi le mail, la base de données à distance ou d’autres services, ouvrez les ports correspondants au cas par cas. Vérifiez les ports actuellement en écoute avec ss -tlnp pour identifier ce qui tourne et ce qui peut être fermé.
3. Protéger contre les attaques brute-force
Même avec des clés SSH et un port non standard, les tentatives de brute-force sur SSH, les formulaires de connexion WordPress (wp-login.php, xmlrpc.php) et d’autres services exposés restent fréquentes. Deux outils complémentaires permettent de les bloquer automatiquement.
Fail2ban
Fail2ban surveille les fichiers de logs et bloque automatiquement les adresses IP qui accumulent des échecs d’authentification. Il crée des règles de pare-feu temporaires (ou permanentes) pour bannir les IP suspectes.
Fail2ban fonctionne par « jails » — chaque jail surveille un service spécifique (SSH, Apache/Nginx/OLS, WordPress). La configuration par défaut protège SSH, mais vous pouvez ajouter des jails pour d’autres services selon votre stack.
CrowdSec
CrowdSec est l’alternative moderne à Fail2ban, avec un avantage majeur : une base de données communautaire d’adresses IP malveillantes. Quand un serveur détecte une attaque et bloque une IP, cette information est partagée avec toute la communauté CrowdSec. Votre serveur bénéficie ainsi de la détection collective — une IP qui attaque un serveur en Allemagne est bloquée sur le vôtre avant même qu’elle ne vous cible.
CrowdSec propose aussi une console web pour visualiser les alertes et gérer les décisions de blocage. Son architecture modulaire (agents de détection + bouncers d’application) le rend plus flexible que Fail2ban, notamment pour protéger des services web derrière un reverse proxy.
Les deux outils peuvent coexister sur un même serveur si besoin, mais CrowdSec seul couvre la plupart des cas d’usage et apporte la dimension communautaire en plus.
4. Maintenir le serveur à jour
Les failles de sécurité sont découvertes et publiées en permanence. Entre la publication d’une CVE et son exploitation active par des bots, il se passe parfois seulement quelques heures. Maintenir le serveur à jour est la mesure la plus simple et la plus efficace pour limiter les risques.
Mises à jour du système
Sur Debian/Ubuntu, la commande de base :
sudo apt update && sudo apt upgrade -yPour ne jamais oublier les correctifs de sécurité critiques, activez les mises à jour automatiques avec unattended-upgrades :
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgradesPar défaut, unattended-upgrades n’applique que les correctifs de sécurité — pas les mises à jour majeures qui pourraient casser quelque chose. C’est le bon compromis entre sécurité et stabilité.
Mises à jour applicatives
Le système d’exploitation n’est qu’une partie de la stack. PHP, MySQL/MariaDB, le serveur web (OpenLiteSpeed, Nginx), et bien sûr WordPress, ses thèmes et ses plugins doivent aussi être maintenus à jour. Les plugins WordPress obsolètes sont l’un des vecteurs d’attaque les plus exploités — les vulnérabilités connues sont testées systématiquement par les bots.
5. Réduire la surface d’attaque
Moins il y a de logiciels et de services qui tournent sur un serveur, moins il y a de failles potentielles à exploiter. Le principe est simple : n’installer que ce qui est nécessaire.
- Installation minimale : partez d’une image serveur minimale (Ubuntu Server, Debian netinstall) plutôt que d’une image complète avec des dizaines de paquets préinstallés. N’installez que les services dont vous avez besoin
- Désactiver les services inutiles : vérifiez ce qui tourne avec
systemctl list-units --type=service --state=running. Un serveur FTP actif alors que vous n’utilisez que SFTP ? Un serveur mail alors que vos emails passent par un service externe ? Désactivez-les - Côté WordPress : chaque plugin actif est un point d’entrée potentiel. Supprimez (ne désactivez pas seulement) les plugins et thèmes inutilisés. Les thèmes par défaut de WordPress (Twenty Twenty-*) que vous n’utilisez pas doivent aussi être supprimés
6. HTTPS et certificats SSL
En 2026, un site sans HTTPS n’a plus sa place en ligne — les navigateurs le signalent comme non sécurisé et Google le pénalise au référencement. HTTPS chiffre les échanges entre le navigateur et le serveur, protégeant les données en transit (identifiants, formulaires, données de paiement).
Let’s Encrypt fournit des certificats SSL gratuits, reconnus par tous les navigateurs. Le renouvellement est automatique via Certbot ou le gestionnaire intégré à votre panneau serveur (ServerAvatar, cPanel). Il n’y a plus aucune raison d’acheter un certificat SSL pour un site standard.
Points de vigilance :
- Vérifiez que le renouvellement automatique fonctionne (
certbot renew --dry-run) — un certificat expiré affiche un avertissement de sécurité qui fait fuir les visiteurs - Forcez la redirection HTTP → HTTPS pour que toutes les connexions soient chiffrées, sans exception
- Désactivez les protocoles obsolètes (TLS 1.0, TLS 1.1) — seuls TLS 1.2 et TLS 1.3 doivent être actifs
7. Protection applicative (WAF)
Un pare-feu réseau (UFW) filtre le trafic par port et protocole. Un WAF (Web Application Firewall) va plus loin : il analyse le contenu des requêtes HTTP et bloque celles qui contiennent des tentatives d’injection SQL, de cross-site scripting (XSS), de traversal de répertoire ou d’autres attaques applicatives.
- Cloudflare WAF : si votre site est derrière Cloudflare (même en plan gratuit), vous bénéficiez d’une couche de protection contre les attaques les plus courantes, d’une protection DDoS et de règles personnalisables. Le plan Pro ajoute des règles WAF managées plus avancées
- ModSecurity : WAF open source qui s’intègre à Apache et Nginx. Avec le jeu de règles OWASP CRS (Core Rule Set), il détecte et bloque les attaques web les plus répandues. Plus complexe à configurer et à maintenir, mais puissant
- OpenLiteSpeed : intègre un module de protection contre les attaques par requête (anti-DDoS, rate limiting par IP) directement dans sa configuration, sans module externe
Un WAF ne remplace pas les bonnes pratiques de développement et de configuration — il ajoute une couche de défense supplémentaire qui bloque les attaques connues avant qu’elles n’atteignent votre application.
8. Surveillance et détection
La sécurité ne s’arrête pas à la configuration initiale. Un serveur doit être surveillé en permanence pour détecter les anomalies et les tentatives d’intrusion.
Surveiller les logs
Les fichiers de logs (/var/log/auth.log, /var/log/syslog, logs du serveur web) contiennent les traces de toute activité sur le serveur. Un outil comme Logwatch envoie un résumé quotidien par email avec les événements notables : tentatives de connexion échouées, erreurs système, activité inhabituelle.
Détecter les modifications suspectes
rkhunter (Rootkit Hunter) analyse le système à la recherche de rootkits, backdoors et exploits locaux. Il vérifie l’intégrité des fichiers système et signale toute modification suspecte. Planifiez un scan régulier via cron et examinez les rapports.
Pour WordPress spécifiquement, des outils comme WPScan (en ligne de commande) permettent de scanner les vulnérabilités connues des plugins, thèmes et de la version WordPress installée.
Monitoring des ressources
Une consommation CPU ou mémoire anormale peut être le signe d’un crypto-miner installé par un attaquant, d’un script malveillant en cours d’exécution ou d’une attaque DDoS en cours. Un monitoring basique avec des alertes sur les seuils critiques (CPU > 90%, disque > 85%) permet de réagir rapidement.
9. Mots de passe et authentification
Les clés SSH protègent l’accès au serveur, mais d’autres services nécessitent des mots de passe : base de données, panneaux d’administration, comptes WordPress. Les règles de base restent essentielles :
- Mots de passe uniques et complexes : minimum 16 caractères, générés par un gestionnaire de mots de passe (Bitwarden, KeePass, 1Password). Jamais de mots du dictionnaire, de dates de naissance ou de noms propres
- Un mot de passe par service : si un mot de passe est compromis, les autres services restent protégés
- Authentification à deux facteurs (2FA) : activez-la sur tout ce qui le permet — panneau d’administration serveur, WordPress (via un plugin comme WP 2FA), comptes email de gestion
- Gestionnaire de mots de passe : obligatoire dès que vous gérez plus de quelques accès. Il génère, stocke et remplit les mots de passe de façon sécurisée
10. Sauvegardes
La sauvegarde n’est pas une mesure de sécurité au sens strict — elle ne prévient pas les attaques. Mais elle est votre dernier recours quand tout le reste a échoué. Un serveur compromis avec des sauvegardes récentes et testées peut être restauré en moins d’une heure. Sans sauvegarde, la récupération peut prendre des jours — ou être impossible.
Ce sujet mérite un article complet : consultez notre guide détaillé sur la mise en place d’une sauvegarde efficace pour WordPress.
Conclusion
La sécurité d’un serveur repose sur des couches de protection complémentaires : accès SSH verrouillé, pare-feu restrictif, protection brute-force, mises à jour automatiques, surface d’attaque réduite, WAF, surveillance active et sauvegardes. Aucune mesure isolée ne suffit — c’est leur combinaison qui rend un serveur résilient.
La plupart de ces mesures se mettent en place en quelques heures lors de l’installation initiale. Le vrai travail est ensuite de les maintenir dans le temps : surveiller les alertes, appliquer les correctifs, tester les sauvegardes, auditer régulièrement la configuration.
Si vous souhaitez un audit de sécurité de votre serveur ou la mise en place d’une configuration sécurisée pour votre infrastructure WordPress, nous pouvons en discuter.