Comment configurer un pare-feu pour votre hébergement cPanel

Sécuriser un serveur cPanel sans pare-feu correctement configuré revient à laisser la porte d’entrée d’un centre de données déverrouillée. ConfigServer Security & Firewall (CSF) est la référence absolue pour renforcer les environnements cPanel et WHM — il s’intègre directement dans l’interface de WHM, s’appuie sur iptables (ou nftables sur les noyaux plus récents), et est livré avec un démon compagnon appelé Login Failure Daemon (LFD) qui gère la détection d’intrusion en temps réel. Ce guide présente un déploiement CSF complet, adapté à la production : installation, architecture des règles, atténuation avancée des menaces et flux de maintenance continu.

Que vous utilisiez un VPS avec cPanel ou un Serveur Dédié complet, les principes de configuration sont identiques. La différence est que sur une machine dédiée, vous disposez d’un accès exclusif au noyau, ce qui signifie que les fonctionnalités de suivi des connexions et de protection contre les inondations SYN de CSF peuvent être poussées plus loin sans affecter les locataires voisins.

Pourquoi un pare-feu logiciel n’est pas optionnel sur les serveurs cPanel

cPanel expose une large surface d’attaque par conception. Une installation par défaut ouvre des dizaines de ports de service — WHM (2086/2087), cPanel (2082/2083), FTP (21), soumission de courrier (587), IMAP (993), POP3 (995), et plus encore. Chaque port ouvert est un vecteur d’entrée potentiel. Sans filtre de paquets avec état devant ces services :

• Les attaques par force brute contre SSH, FTP et le webmail réussissent silencieusement
• Les robots de credential-stuffing martèlent les points de terminaison xmlapi et cpsrvd
• Le trafic DDoS par amplification sature la NIC avant que la couche applicative puisse répondre
• Les comptes d’hébergement partagé compromis peuvent pivoter latéralement sur le serveur

Un pare-feu matériel en périphérie du réseau aide, mais il ne peut pas voir le contexte de la couche applicative — il ne sait pas qu’une IP a échoué 20 connexions IMAP consécutives en 60 secondes. CSF + LFD fonctionne au niveau de l’hôte et réagit exactement à ce type de signal comportemental.

CSF vs. autres options de pare-feu pour cPanel

CSF l’emporte sur tous les axes qui comptent pour un environnement cPanel. La seule raison de choisir firewalld ou ufw est si vous utilisez une pile non-cPanel et préférez un outil plus léger.

Étape 1 : Liste de contrôle pré-installation

Avant de toucher à la moindre commande, effectuez ces vérifications. Les ignorer est la façon dont les administrateurs se bloquent accidentellement hors des serveurs de production.

Vérifiez votre accès hors bande. Confirmez que vous avez accès à la console de votre hébergeur (KVM over IP, IPMI, ou une console VNC web). Si CSF bloque votre IP pendant les tests, l’accès console est votre chemin de récupération.

Notez votre adresse IP de gestion. Exécutez la commande suivante depuis votre machine locale :

curl -4 ifconfig.me

Vous mettrez cette IP en liste blanche dans CSF avant d’activer le mode d’application.

Vérifiez l’état actuel de iptables :

iptables -L -n --line-numbers

Si un autre outil de pare-feu (APF, firewalld) est déjà actif, arrêtez-le et désactivez-le avant d’installer CSF pour éviter les conflits de règles.

Confirmez que Perl est installé (CSF est basé sur Perl) :

perl -v

Sur un système CentOS/AlmaLinux/CloudLinux fraîchement installé, Perl est présent par défaut. Sur les builds Ubuntu minimaux, installez-le avec apt install perl.

Étape 2 : Installer CSF sur votre serveur cPanel

Connectez-vous à votre serveur en tant que root via SSH :

ssh root@YOUR_SERVER_IP

Téléchargez, extrayez et exécutez le programme d’installation :

cd /usr/src
wget https://download.configserver.com/csf.tgz
tar -xzf csf.tgz
cd csf
sh install.sh

Le programme d’installation enregistre CSF en tant que service système, installe le plugin WHM et place le fichier de configuration principal dans /etc/csf/csf.conf.

Exécutez la vérification des dépendances intégrée pour confirmer que tous les modules Perl requis sont présents :

perl /usr/local/csf/bin/csftest.pl

Toute ligne marquée FATAL doit être résolue avant de continuer. Les lignes marquées WARN sont des fonctionnalités optionnelles — examinez-les, mais elles n’empêcheront pas CSF de fonctionner.

Vérifiez la version installée :

csf -v

Étape 3 : Configuration principale dans /etc/csf/csf.conf

Ouvrez le fichier de configuration principal dans votre éditeur préféré :

nano /etc/csf/csf.conf

Le fichier est abondamment commenté. Les directives suivantes ont le plus grand impact sur la sécurité et doivent être examinées à chaque nouveau déploiement.

Mode test

Lors de la première installation de CSF, TESTING = "1" est défini par défaut. Dans ce mode, LFD ne démarre pas et aucun blocage n’est appliqué — les règles sont chargées mais temporaires. Ne désactivez pas le mode test tant que vous n’avez pas mis votre IP de gestion en liste blanche et validé toutes les règles de port.

TESTING = "0"   # Set this only after full validation

Listes d’autorisation des ports entrants et sortants

TCP_IN et TCP_OUT définissent quels ports TCP sont autorisés dans chaque direction. Un serveur cPanel minimal mais fonctionnel nécessite :

TCP_IN = "20,21,22,25,53,80,110,143,443,465,587,993,995,2077,2078,2082,2083,2086,2087,2095,2096"
TCP_OUT = "20,21,22,25,53,80,110,113,443,587,993,995"
UDP_IN = "20,21,53"
UDP_OUT = "20,21,53,113,123"

Note opérationnelle critique : Le port 2087 est WHM SSL. Le port 2083 est cPanel SSL. Si vous les supprimez de TCP_IN avant de mettre votre IP en liste blanche, vous perdrez immédiatement l’accès au panneau de contrôle. Le port 123 (UDP sortant) est NTP — le supprimer casse la synchronisation de l’heure, ce qui entraîne des échecs de validation des certificats SSL et des rejets de livraison de courrier.

Fermez chaque port qui n’est pas en usage actif. Exécutez ss -tlnp pour vérifier ce qui écoute réellement avant de finaliser cette liste.

Mise en liste blanche de votre IP de gestion

Ajoutez votre IP à /etc/csf/csf.allow avant de désactiver le mode test :

echo "YOUR.MANAGEMENT.IP # My office IP" >> /etc/csf/csf.allow

Vous pouvez également utiliser la commande CSF directement :

csf -a YOUR.MANAGEMENT.IP "Management workstation"

Les IP en liste blanche contournent tous les blocages LFD et toutes les règles de limitation du débit. Gardez cette liste minimale — chaque entrée est une exception permanente à votre politique de sécurité.

Blocage des IP malveillantes connues

Les blocages permanents vont dans /etc/csf/csf.deny :

csf -d MALICIOUS.IP.ADDRESS "Confirmed scanner"

Pour les imports en masse depuis des flux de renseignement sur les menaces (Spamhaus DROP, Emerging Threats, etc.), ajoutez les CIDRs directement à /etc/csf/csf.deny et rechargez :

csf -r

Étape 4 : Configurer le Login Failure Daemon (LFD)

LFD est le composant de détection d’intrusion comportementale de CSF. Il surveille les fichiers journaux système en temps réel, compte les échecs d’authentification par IP source, et déclenche un blocage temporaire lorsqu’un seuil est dépassé. C’est votre principale défense contre les attaques par force brute sur les identifiants.

Directives LFD clés dans csf.conf :

Cas particulier à connaître : Si votre serveur est derrière une passerelle NAT ou un routeur de bureau partagé, plusieurs utilisateurs légitimes partagent une même IP externe. Définir LF_TRIGGER trop bas bloquera tout votre bureau après quelques fautes de frappe. Augmentez le seuil ou mettez l’IP du bureau en liste blanche dans csf.allow.

LFD surveille également les processus suspects, les événements de surveillance des répertoires et la détection des modifications de fichiers (les fonctionnalités LF_DIRWATCH et LF_INTEGRITY). Activez LF_INTEGRITY pour détecter les modifications non autorisées des binaires système :

LF_INTEGRITY = "3600"   # Check every hour

Étape 5 : Fonctionnalités avancées d’atténuation des menaces

Protection contre les inondations SYN

Les attaques par inondation SYN épuisent la table de connexions TCP en envoyant de grands volumes de paquets SYN sans compléter la poignée de main. Activez l’atténuation intégrée de CSF :

SYNFLOOD = "1"
SYNFLOOD_RATE = "100/s"
SYNFLOOD_BURST = "150"

Ces valeurs autorisent 100 nouveaux paquets SYN par seconde avec une tolérance de burst de 150 avant que la règle ne se déclenche. Ajustez ces valeurs en fonction de votre trafic légitime de pointe — un site e-commerce lors d’une vente flash peut nécessiter des valeurs de burst plus élevées.

Suivi des connexions

Le suivi des connexions limite le nombre total de connexions simultanées depuis une seule IP sur tous les ports. C’est efficace contre les attaques DDoS à faible débit et l’épuisement des connexions :

CT_LIMIT = "300"
CT_INTERVAL = "30"
CT_BLOCK_TIME = "1800"
CT_SKIP_LOCAL = "1"

CT_SKIP_LOCAL empêche les connexions localhost et loopback d’être comptabilisées dans la limite — essentiel sur les serveurs où les démons cPanel communiquent en interne via TCP.

Détection de scan de ports

CSF peut détecter et bloquer les hôtes qui sondent plusieurs ports dans une courte fenêtre temporelle :

PS_INTERVAL = "300"
PS_LIMIT = "10"
PS_BLOCK_TIME = "3600"
PS_PERMANENT = "0"

Une IP qui touche 10 ports fermés ou plus en 300 secondes est bloquée pendant une heure. Définissez PS_PERMANENT = "1" uniquement si vous êtes certain que vos utilisateurs légitimes ne déclencheront jamais accidentellement cette règle — certains clients de messagerie et outils de surveillance sondent plusieurs ports lors de la négociation de connexion.

Blocage par pays

Si votre application n’a pas d’utilisateurs légitimes dans certaines régions à haut risque, le blocage au niveau du pays réduit considérablement le bruit dans vos journaux et la charge de travail de LFD. Modifiez csf.conf :

CC_DENY = "CN,RU,KP,NG"
CC_ALLOW = ""

Les codes pays suivent la norme ISO 3166-1 alpha-2. CSF télécharge les données GeoIP automatiquement. Soyez précis ici — bloquer des pays entiers est un instrument grossier. Une meilleure approche pour la plupart des déploiements est CC_ALLOW (liste blanche uniquement des pays où se trouvent vos utilisateurs) combinée avec CC_ALLOW_PORTS pour restreindre l’accès basé sur les pays à des ports spécifiques uniquement.

Restrictions SMTP sortantes

Les installations WordPress compromises et les scripts vulnérables sont fréquemment utilisés comme relais de spam. CSF peut restreindre le SMTP sortant aux seuls processus de messagerie autorisés :

SMTP_BLOCK = "1"
SMTP_ALLOWUSER = "mailman"
SMTP_ALLOWGROUP = "mail"

Cela bloque toutes les connexions sortantes sur le port 25 sauf celles provenant de processus s’exécutant en tant qu’utilisateur ou groupe spécifié. La livraison de courrier légitime via votre MTA (Exim sur cPanel) n’est pas affectée car Exim s’exécute en tant que groupe mail. Cette seule directive élimine toute une classe d’abus de spam par compte compromis.

Si vous avez besoin d’une infrastructure de messagerie sortante de qualité professionnelle aux côtés de votre hébergement, envisagez d’associer votre serveur à une solution d’Hébergement Email dédiée pour les courriers transactionnels et marketing.

Étape 6 : Application et test de la configuration

Une fois que vous avez examiné toutes les directives, rechargez CSF pour appliquer les modifications sans redémarrage complet :

csf -r

Pour redémarrer complètement CSF et LFD :

csf -ra

Vérifiez l’état actuel et le nombre de règles actives :

csf -l

Vérifiez que LFD est en cours d’exécution :

systemctl status lfd

Testez depuis une IP externe (pas votre IP de gestion en liste blanche) que le blocage des ports fonctionne comme prévu. Utilisez nmap depuis une machine séparée :

nmap -sS -p 1-65535 YOUR_SERVER_IP

Seuls les ports explicitement listés dans TCP_IN doivent apparaître comme ouverts. Tous les autres doivent retourner filtered.

Désactivez le mode test uniquement après que cette validation soit réussie :

# In /etc/csf/csf.conf, set TESTING = "0", then:
csf -r

Étape 7 : Configuration via l’interface graphique WHM

Pour les administrateurs qui préfèrent une interface graphique, CSF s’intègre entièrement dans WHM. Naviguez vers WHM > Plugins > ConfigServer Security & Firewall. Depuis là, vous pouvez :

• Afficher la liste de blocage en direct et débloquer manuellement des IP
• Ajouter des entrées d’autorisation/refus temporaires et permanentes
• Déclencher une vérification de configuration qui valide la syntaxe de csf.conf
• Afficher les journaux LFD dans une interface paginée et consultable
• Exécuter l’outil de synchronisation de cluster si vous gérez plusieurs serveurs

L’interface WHM est particulièrement utile pour le personnel de support qui doit débloquer l’IP d’un client légitime sans accès SSH. Accordez aux comptes revendeurs WHM l’accès au plugin CSF de manière sélective — tous les revendeurs n’ont pas besoin de la capacité de gestion du pare-feu.

Étape 8 : Surveillance, analyse des journaux et maintenance

Surveillance des journaux en temps réel

LFD écrit les événements de blocage dans /var/log/lfd.log. Surveillez-le en temps réel lors d’un incident actif :

tail -f /var/log/lfd.log

Le journal d’activité propre à CSF se trouve dans /var/log/csf.log. Pour un résumé des IP les plus fréquemment bloquées au cours des dernières 24 heures :

grep "Blocked" /var/log/lfd.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

Alertes par email

Configurez LFD pour envoyer des alertes à votre adresse administrative :

LF_ALERT_TO = "admin@yourdomain.com"
LF_ALERT_FROM = "lfd@yourdomain.com"

Activez des types d’alertes spécifiques :

LF_EMAIL_ALERT = "1"      # Block alerts
LT_EMAIL_ALERT = "1"      # Login tracking alerts
RT_EMAIL_ALERT = "1"      # Resource usage alerts

Évitez d’activer tous les types d’alertes sur un serveur très sollicité — la fatigue des alertes amène les administrateurs à commencer à ignorer les notifications, ce qui va à l’encontre du but recherché.

Mise à jour de CSF

CSF publie fréquemment des mises à jour. Exécutez le programme de mise à jour intégré :

csf -u

Cela télécharge la dernière version, préserve vos fichiers de configuration et redémarre le service. Planifiez cela dans une tâche cron hebdomadaire :

0 3 * * 0 /usr/sbin/csf -u >> /var/log/csf_update.log 2>&1

Intégration avec cPHulk

cPanel est livré avec son propre outil de protection contre la force brute appelé cPHulk. Exécuter simultanément cPHulk et LFD crée des blocages redondants et peut prêter à confusion lors de la réponse aux incidents. L’approche recommandée : désactivez cPHulk et fiez-vous exclusivement à LFD, qui est plus configurable et s’intègre à la liste de blocage unifiée de CSF.

Désactivez cPHulk via WHM sous Security Center > cPHulk Brute Force Protection.

Architecture de pare-feu pour les environnements multi-serveurs

Si vous gérez plusieurs serveurs cPanel — un schéma courant avec des clusters d’Hébergement VPS ou un serveur web principal associé à un serveur de base de données séparé — la fonctionnalité de synchronisation de cluster de CSF vous permet de propager les listes de blocage sur tous les nœuds simultanément.

Configurez les membres du cluster dans /etc/csf/csf.conf :

CLUSTER_MASTER = "PRIMARY_SERVER_IP"
CLUSTER_SENDTO = "SECONDARY_SERVER_IP"
CLUSTER_RECVFROM = "PRIMARY_SERVER_IP"
CLUSTER_KEY = "your_shared_secret_key"

Lorsque LFD bloque une IP sur le serveur principal, le blocage est automatiquement propagé à tous les membres du cluster en quelques secondes. C’est particulièrement utile lorsqu’un scanner sondant votre serveur web tente également une attaque par force brute SSH sur votre nœud de base de données.

Pour les environnements à fort trafic ou les charges de travail intensives en GPU fonctionnant aux côtés de services web, l’infrastructure d’Hébergement GPU bénéficie de la même approche de renforcement CSF — la configuration du pare-feu est identique, mais les valeurs CT_LIMIT doivent généralement être plus élevées pour accommoder les connexions API parallèles légitimes.

Considérations sur la sécurité SSL et des ports

Un pare-feu contrôle l’accès aux ports, mais il ne valide pas l’intégrité cryptographique des connexions sur ces ports. Assurez-vous que chaque service exposé via vos règles de pare-feu est également protégé par un certificat SSL/TLS valide. Un port 443 ouvert avec un certificat expiré ou auto-signé représente un risque de phishing et d’attaque MITM.

Associez votre configuration de pare-feu à des certificats correctement émis par une CA de confiance. AlexHost fournit des Certificats SSL qui s’intègrent directement au flux de travail AutoSSL de cPanel, garantissant que vos points de terminaison HTTPS exposés sont cryptographiquement sûrs.

Pièges courants et comment les éviter

Se bloquer soi-même lors de la configuration initiale. Mettez toujours votre IP en liste blanche dans csf.allow avant de définir TESTING = "0". Confirmez toujours l’accès console avant d’effectuer des modifications d’application.

Bloquer les services internes de cPanel. Les démons cPanel communiquent via localhost et parfois via l’IP principale du serveur. CT_SKIP_LOCAL = "1" et un examen attentif de TCP_OUT préviennent les perturbations de service auto-infligées.

LF_DURATION trop agressif sur l’hébergement partagé. Si des utilisateurs légitimes partagent une IP NAT avec des attaquants, un blocage de 24 heures pénalise des clients innocents. Utilisez LF_DURATION = "3600" et LF_PERMBLOCK_COUNT = "4" pour n’escalader que les récidivistes vers des bannissements permanents.

Oublier d’ouvrir les ports des agents de surveillance. Si vous utilisez un service de surveillance externe (Zabbix, Nagios, Datadog), son agent nécessite un port entrant ouvert. Ajoutez-le à TCP_IN et mettez l’IP du serveur de surveillance en liste blanche dans csf.allow.

Ne pas tester les règles sortantes. Les administrateurs se concentrent sur TCP_IN entrant mais négligent TCP_OUT. Des règles sortantes trop restrictives cassent le système de mise à jour de cPanel, les renouvellements de certificats Let’s Encrypt (port 80 sortant vers les serveurs ACME), et les connexions MySQL distantes.

Exécuter CSF sur un serveur avec proxy Cloudflare. Lorsque le trafic passe par Cloudflare, l’IP source vue par CSF est une IP de nœud de périphérie Cloudflare, pas la vraie IP du visiteur. Bloquer une IP Cloudflare bloque tout le trafic passant par ce nœud de périphérie. Utilisez le fichier csf.allow pour mettre en liste blanche les plages IP publiées par Cloudflare et configurez votre application pour lire l’en-tête CF-Connecting-IP pour les vraies IP des visiteurs.

Matrice de décision technique : Choisir votre profil de configuration CSF

Points clés : Liste de contrôle de préparation à la production

Avant de considérer votre déploiement CSF prêt pour la production, vérifiez chaque élément ci-dessous :

• L’IP de gestion est présente dans /etc/csf/csf.allow et confirmée avec csf -g YOUR.IP

TESTING = "0" est défini et csf -r a été exécuté
TCP_IN ne contient que les ports avec des services actifs et intentionnels — vérifiés avec ss -tlnp

SMTP_BLOCK = "1" est activé sauf si le serveur est un relais de messagerie dédié
LFD est en cours d’exécution — confirmé avec systemctl status lfd

LF_PERMBLOCK_COUNT et LF_PERMBLOCK_INTERVAL sont configurés pour escalader les récidivistes
CT_LIMIT est défini et ajusté à vos connexions simultanées de pointe attendues
SYNFLOOD = "1" est activé avec des valeurs de débit appropriées à votre volume de trafic
Les alertes par email sont configurées et une alerte de test a été reçue
cPHulk est désactivé dans WHM pour éviter les conflits avec LFD
Une tâche cron csf -u hebdomadaire est planifiée
L’accès console/IPMI a été testé indépendamment de SSH
Les règles de port sortantes (TCP_OUT) ont été validées — les mises à jour cPanel, Let’s Encrypt et NTP fonctionnent tous correctement
Si vous utilisez Cloudflare, les plages IP Cloudflare sont en liste blanche dans csf.allow

FAQ

Quelle est la différence entre CSF et un pare-feu matériel, et ai-je besoin des deux ?

Un pare-feu matériel fonctionne au périmètre du réseau et filtre le trafic avant qu’il n’atteigne la NIC de votre serveur. CSF fonctionne au niveau du système d’exploitation et ajoute une détection comportementale et consciente des applications que les pare-feux matériels ne peuvent pas fournir — comme bloquer une IP après des échecs répétés de connexion cPanel. Dans un environnement de production, les deux couches sont complémentaires. Le filtrage matériel réduit la charge DDoS volumétrique ; CSF gère les tentatives d’intrusion ciblées.

Comment débloquer une IP que CSF a bannie définitivement ?

Exécutez csf -dr BLOCKED.IP.ADDRESS pour la supprimer de la liste de refus, puis csf -r pour recharger les règles. Vous pouvez également utiliser l’interface du plugin CSF dans WHM sous « Débloquer une IP ». Pour éviter un nouveau blocage, ajoutez l’IP à csf.allow avec csf -a IP.ADDRESS "reason".

CSF va-t-il interférer avec les renouvellements de certificats Let’s Encrypt / AutoSSL ?

Uniquement si le port 80 sortant est bloqué dans TCP_OUT ou si les IP du serveur de validation Let’s Encrypt se trouvent par inadvertance dans csf.deny. Assurez-vous que le port 80 est dans TCP_IN (pour les réponses au défi HTTP-01) et dans TCP_OUT (pour la communication avec le serveur ACME). Si les renouvellements échouent après l’installation de CSF, vérifiez csf.deny pour toutes les plages IP Let’s Encrypt et examinez /var/log/lfd.log pour les connexions sortantes bloquées.

Comment tester en toute sécurité une nouvelle règle CSF sans risquer un verrouillage ?

Réactivez temporairement le mode test en définissant TESTING = "1" dans csf.conf et en exécutant csf -r. En mode test, les règles sont chargées mais non appliquées, et LFD ne démarre pas. Validez vos modifications, puis définissez TESTING = "0" et rechargez. Confirmez toujours l’accès console avant de repasser en mode d’application.

CSF protège-t-il contre les attaques de la couche applicative comme l’injection SQL ou le XSS ?

Non. CSF fonctionne au niveau des couches réseau et transport (L3/L4) et n’a aucune visibilité sur les charges utiles des requêtes HTTP. Les attaques de la couche applicative nécessitent un pare-feu d’application web (WAF) tel que ModSecurity avec l’ensemble de règles de base OWASP, qui s’intègre avec Apache et Nginx sur les serveurs cPanel. CSF et ModSecurity sont complémentaires — CSF gère les menaces au niveau réseau tandis que ModSecurity gère les attaques au niveau HTTP. LFD peut être configuré pour bloquer les IP qui déclenchent répétitivement des règles ModSecurity via la directive LF_MODSEC.