Qu’est-ce que CSF (ConfigServer Security and Firewall) ? Un guide technique complet

CSF, ou ConfigServer Security & Firewall, est un pare-feu à inspection dynamique des paquets (SPI), un démon de détection des échecs de connexion et une suite de renforcement de la sécurité pour les serveurs Linux. Il fonctionne comme une interface riche en fonctionnalités pour iptables (et nftables sur les noyaux plus récents), abstrayant la gestion complexe des règles en une couche de configuration structurée tout en ajoutant une détection active des menaces via son démon compagnon, LFD (Login Failure Daemon).

Pour tout serveur Linux en production — qu’il exécute un hébergement mutualisé, un VPS ou un environnement dédié bare-metal — CSF fournit une défense périmétrique en couches : filtrage du trafic entrant/sortant, analyse des journaux en temps réel, atténuation des attaques par force brute, détection des scans de ports et contrôle d’accès au niveau des pays, le tout gérable via une CLI ou une interface web intégrée à cPanel, DirectAdmin ou Webmin.

Fonctionnement interne de CSF

CSF ne remplace pas iptables ou nftables — il les gère. Lorsque vous définissez des règles dans /etc/csf/csf.conf ou manipulez des listes d’IP, CSF traduit ces directives en règles netfilter au niveau du noyau et les applique de manière atomique.

L’architecture comporte deux composants principaux fonctionnant en tandem :

• csf — le moteur de règles de pare-feu qui lit les fichiers de configuration et peuple les chaînes iptables/ip6tables.
• lfd — un démon persistant qui surveille les fichiers journaux système en temps réel, évalue les événements d’authentification par rapport à des seuils configurables et demande à csf de bloquer ou débloquer dynamiquement des adresses IP.

Au démarrage, CSF vide les chaînes existantes et les reconstruit entièrement à partir de sa configuration. Cette approche « table rase » empêche l’accumulation de règles et garantit que l’état du pare-feu est toujours déterministe et auditable.

Modes de fonctionnement de CSF

CSF fonctionne selon l’une des deux postures de trafic fondamentales :

Mode Autorisation (par défaut pour la plupart des déploiements) : Tout le trafic entrant et sortant est refusé par défaut. Seuls les ports explicitement listés dans les directives TCP_IN, TCP_OUT, UDP_IN et UDP_OUT sont autorisés. Il s’agit de la posture de production recommandée.

Mode Test (TESTING = "1") : CSF charge les règles mais LFD n’applique pas les blocages. Cela vous évite de vous bloquer vous-même lors de la configuration initiale. Désactivez toujours le mode test avant la mise en production :

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

Principales fonctionnalités de CSF expliquées

Moteur de règles de pare-feu

CSF gère quatre listes de ports principales dans csf.conf :

TCP_IN / UDP_IN — ports ouverts pour les connexions entrantes
TCP_OUT / UDP_OUT — ports autorisés pour les connexions sortantes

Une configuration minimale de serveur web pourrait ressembler à :
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"
Au-delà de la gestion des ports, CSF prend en charge les règles basées sur les CIDR, vous permettant d’autoriser ou de refuser des plages réseau entières. Les règles sont stockées dans des fichiers plats pour faciliter la gestion des versions :




Fichier
Objectif




/etc/csf/csf.allow
IP ou CIDR en liste blanche permanente


/etc/csf/csf.deny
IP ou CIDR bloqués en permanence


/etc/csf/csf.ignore
IP que LFD ne bloquera jamais automatiquement


/etc/csf/csf.dyndns
Noms d’hôtes DNS dynamiques à résoudre automatiquement et autoriser




Démon de détection des échecs de connexion (LFD)
LFD est la couche d’intelligence active de CSF. Il surveille les fichiers journaux — notamment /var/log/secure, /var/log/maillog, /var/log/exim_mainlog et d’autres — et comptabilise les échecs d’authentification par IP source dans une fenêtre temporelle configurable.
Directives de configuration clés de LFD :

LF_TRIGGER — nombre d’échecs avant qu’un blocage soit émis
LF_INTERVAL — la fenêtre temporelle glissante (en secondes) pour le comptage des échecs
LF_DURATION — durée d’un blocage temporaire (0 = permanent)
LF_SSH, LF_FTPD, LF_SMTPAUTH, LF_POP3D, LF_IMAPD — seuils d’échec par service

Un exemple pratique de renforcement : définir LF_SSH = "5" avec LF_INTERVAL = "300" pour bloquer toute IP qui échoue à l’authentification SSH 5 fois en 5 minutes. Cette seule directive élimine la grande majorité des attaques automatisées de bourrage d’identifiants ciblant le port 22.
Cas limite critique : Si votre système de surveillance ou votre agent de sauvegarde s’authentifie depuis une IP dynamique, il finira par déclencher LFD. Ajoutez toujours ces IP sources dans /etc/csf/csf.ignore avant de resserrer les seuils.
Détection des intrusions et suivi des processus
Au-delà de la surveillance des connexions, LFD effectue plusieurs fonctions de détection d’intrusion au niveau de l’hôte :

PT_LOAD — surveille la charge CPU et alerte ou bloque si un processus dépasse les seuils définis, utile pour détecter le cryptominage ou les processus incontrôlés sur une infrastructure mutualisée.
PT_USERMEM et PT_USERTIME — limites de mémoire et de temps CPU par utilisateur, essentielles pour les environnements d’hébergement web mutualisé où l’isolation des ressources est indispensable.
LF_DIRWATCH — surveille les répertoires spécifiés pour détecter les modifications de fichiers, fournissant une surveillance rudimentaire de l’intégrité des fichiers.
LF_SCRIPT_ALERT — détecte les scripts envoyant des e-mails en excès, indicateur courant d’une application PHP compromise.

Détection des scans de ports
CSF utilise le suivi du module iptables recent pour identifier les hôtes sondant plusieurs ports en succession rapide. Les directives PS_INTERVAL, PS_LIMIT et PS_PORTS contrôlent la sensibilité. Lorsqu’un scan de ports est détecté, l’IP source est immédiatement ajoutée à la liste de refus et une alerte est envoyée.
Une subtilité à connaître : une détection agressive des scans de ports peut générer des faux positifs provenant de scanners réseau légitimes utilisés par des équipes de sécurité ou des services de surveillance de disponibilité. Ajoutez ces IP de scanners dans csf.ignore de manière proactive.
DDoS et limitation du débit de connexion
CSF fournit plusieurs mécanismes pour absorber ou dévier les attaques volumétriques :

CT_LIMIT — nombre maximum de connexions simultanées par IP. Le définir à 100–300 pour les serveurs web empêche un seul hôte de monopoliser les emplacements de connexion.
CT_INTERVAL — fréquence d’exécution du suivi des connexions.
SYNFLOOD et SYNFLOOD_RATE — active la protection contre les inondations SYN iptables avec une limite de débit de paquets configurable.
UDPFLOOD — limite le débit des paquets UDP par IP, atténuant les attaques par amplification UDP.

Il est important de comprendre la portée de l’atténuation DDoS de CSF : il est efficace contre les attaques au niveau applicatif et les attaques réseau de faible volume provenant d’un nombre limité de sources. Face à un DDoS volumétrique à grande échelle (dizaines de Gbps), un routage nul en amont ou un service dédié de nettoyage DDoS est nécessaire. CSF complète mais ne remplace pas la protection réseau en amont.
Contrôle d’accès au niveau des pays (CC_DENY / CC_ALLOW)
CSF s’intègre aux bases de données GeoIP MaxMind pour appliquer des politiques d’accès géographiques. La directive CC_DENY accepte les codes pays ISO 3166-1 alpha-2 :
CC_DENY = "CN,RU,KP,IR"
Alternativement, CC_ALLOW_FILTER combiné avec CC_DENY = "ALL" crée une politique géographique en liste blanche uniquement — utile pour les services qui desservent légalement ou opérationnellement uniquement des juridictions spécifiques.
Piège opérationnel : Les bases de données GeoIP ne sont pas parfaitement précises. Des utilisateurs légitimes derrière des VPN d’entreprise ou des nœuds de périphérie CDN peuvent sembler provenir d’un pays bloqué. Combinez le blocage par pays avec la mise en liste blanche des IP pour les partenaires connus.
Blocages temporaires et déblocage
CSF prend en charge les blocages à durée limitée, qui sont préférables aux interdictions permanentes pour les cas ambigus :
# Block an IP for 3600 seconds (1 hour)
csf -td 192.168.1.100 3600 "Suspicious scan activity"

# Remove a temporary block manually
csf -tr 192.168.1.100

# Check if an IP is currently blocked
csf -g 192.168.1.100
Alertes e-mail et rapports
CSF envoie des notifications par e-mail pour un large éventail d’événements. La directive LF_ALERT_TO définit l’adresse du destinataire. Les catégories d’alertes comprennent :

Dépassements du seuil d’échecs de connexion
Connexions root réussies
Détections de scans de ports
Violations des limites de ressources des processus
Modifications des règles de pare-feu
Modifications suspectes de fichiers (si LF_DIRWATCH est activé)

Pour les serveurs à fort trafic, la fatigue des alertes est un risque opérationnel réel. Utilisez les seuils LF_EMAIL_ALERT et envisagez de router les alertes CSF vers une boîte aux lettres dédiée ou une intégration SIEM plutôt qu’une boîte de réception générale. La livraison fiable des alertes dépend d’une pile de messagerie correctement configurée — si vous gérez votre propre infrastructure de messagerie, un hébergement e-mail avec un alignement SPF/DKIM approprié garantit que les alertes CSF ne sont pas silencieusement rejetées comme spam.
Installation de CSF sur un serveur Linux
CSF n’est pas disponible dans les dépôts de distributions standard. L’installation est simple :
# Download the latest release
cd /usr/src
wget https://download.configserver.com/csf.tgz

# Extract and install
tar -xzf csf.tgz
cd csf
sh install.sh
Après l’installation, vérifiez que tous les modules iptables requis sont disponibles :
perl /usr/local/csf/bin/csftest.pl
Tout résultat FATAL indique des modules noyau manquants qui doivent être résolus avant que CSF fonctionne correctement. Les résultats WARN sont consultatifs et généralement non bloquants.
La configuration initiale se trouve dans /etc/csf/csf.conf. La première étape la plus critique est de désactiver le mode test et de définir vos ports autorisés avant de redémarrer le démon.
Intégration de CSF avec les panneaux de contrôle
CSF est livré avec des plugins d’interface utilisateur natifs pour les trois principaux panneaux de contrôle d’hébergement Linux :




Panneau de contrôle
Méthode d’intégration
Emplacement dans l’interface




cPanel / WHM
Plugin CSF pour WHM
WHM > Plugins > ConfigServer Security & Firewall


DirectAdmin
Plugin CSF
Panneau d’administration > Fonctionnalités supplémentaires


Webmin
Module CSF pour Webmin
Webmin > Réseau > ConfigServer Security & Firewall




L’intégration WHM est la plus complète en termes de fonctionnalités, exposant l’éditeur de fichiers de configuration complet, la recherche d’IP, la gestion des blocages temporaires et le visualiseur de journaux dans l’interface WHM. Pour les administrateurs gérant un VPS avec cPanel, CSF est effectivement la solution de pare-feu standard — il est préinstallé ou facilement installable sur pratiquement toutes les images VPS cPanel.
Pour les environnements sans panneau de contrôle, la CLI est entièrement capable. Commandes principales :
csf -s    # Start firewall
csf -f    # Stop (flush) firewall
csf -r    # Restart firewall
csf -l    # List current iptables rules
csf -a 203.0.113.5   # Allow an IP permanently
csf -d 203.0.113.5   # Deny an IP permanently
csf -g 203.0.113.5   # Check block status of an IP
csf -u    # Check for CSF updates
CSF vs. solutions alternatives de pare-feu Linux
Comprendre où CSF s’inscrit dans l’écosystème plus large vous aide à prendre une décision architecturale éclairée.




Fonctionnalité
CSF + LFD
UFW
firewalld
Fail2ban + iptables




Couche d’abstraction principale
iptables / nftables
iptables / nftables
nftables / iptables
iptables / nftables


Atténuation active des attaques par force brute
Intégrée (LFD)
Aucune (nécessite un couplage)
Aucune (nécessite un couplage)
Fonctionnalité principale


Intégration avec les panneaux de contrôle
Native (cPanel, DA, Webmin)
Aucune
Aucune
Limitée


GeoIP / blocage par pays
Intégré
Aucun
Aucun
Via plugin


Détection des scans de ports
Intégrée
Aucune
Aucune
Via filtre


Surveillance des processus/ressources
Intégrée (PT_*)
Aucune
Aucune
Aucune


Complexité de configuration
Moyenne-Élevée
Faible
Moyenne
Moyenne


Adapté à l’hébergement mutualisé
Oui
Non
Non
Partiel


Support IPv6
Oui (ip6tables)
Oui
Oui
Oui




Quand choisir CSF : Vous gérez un serveur cPanel/DirectAdmin/Webmin, un VPS ou un serveur dédié dans un contexte multi-locataire ou d’hébergement, ou vous avez besoin d’un outil unique qui consolide la gestion du pare-feu, la détection des attaques par force brute et la surveillance au niveau de l’hôte sans assembler plusieurs outils séparés.
Quand envisager des alternatives : Vous gérez un environnement de microservices conteneurisés où la politique réseau est gérée au niveau de la couche d’orchestration (Kubernetes NetworkPolicy, Calico), ou vous avez besoin d’une gestion native nftables sur une distribution moderne sans couches de compatibilité iptables héritées.
Cas d’utilisation courants et scénarios de déploiement
Sécurisation d’un serveur d’hébergement web
Sur un serveur cPanel typique, CSF doit être configuré pour :

N’ouvrir que les ports requis par les services actifs (HTTP, HTTPS, SMTP, IMAP, POP3, FTP, SSH, DNS)
Activer LF_SCRIPT_ALERT pour détecter les mailers PHP compromis
Définir CT_LIMIT pour éviter l’épuisement des connexions depuis une seule source
Activer l’intégration MODSEC si ModSecurity est installé, en corrélant les blocages WAF avec les rejets au niveau du pare-feu

Renforcement de l’accès SSH
Combiner CSF avec l’authentification SSH par clé et un port SSH non standard crée une posture de contrôle d’accès robuste :
# Allow only your management IP on the SSH port
# In /etc/csf/csf.allow:
tcp|in|d=2222|s=203.0.113.10  # Replace with your actual management IP and SSH port
Définissez LF_SSH = "3" pour bloquer toute IP après trois tentatives échouées, et ajoutez votre IP de gestion dans csf.ignore pour éviter un auto-verrouillage accidentel.
Protection de l’infrastructure de messagerie
Les serveurs de messagerie sont des cibles de choix pour les attaques par force brute. Les seuils LFD par service de CSF (LF_SMTPAUTH, LF_POP3D, LF_IMAPD) doivent être définis de manière agressive (3 à 5 échecs) sur tout serveur gérant du SMTP authentifié. Associez cela à des certificats SSL correctement configurés sur tous les ports de messagerie pour éviter l’interception des identifiants qui rendrait la protection contre la force brute inutile.
Charges de travail GPU et haute performance
Pour les environnements d’hébergement GPU exécutant des API d’inférence ML ou des services de rendu, les protections CT_LIMIT et SYNFLOOD de CSF sont particulièrement précieuses — ces services exposent souvent des points de terminaison API à haute valeur qui attirent les sondes automatisées. Restreignez les ports API aux CIDR clients connus via csf.allow et utilisez CC_DENY pour filtrer les zones géographiques sans base d’utilisateurs légitime.
Liste de contrôle pour le renforcement de la configuration CSF
Avant de considérer un déploiement CSF prêt pour la production, vérifiez les points suivants :

TESTING = "0" est défini et CSF a été redémarré
TCP_IN et TCP_OUT ne contiennent que les ports requis par les services actifs — supprimez les valeurs par défaut qui ne s’appliquent pas
Les seuils LF_SSH, LF_FTPD, LF_SMTPAUTH sont définis à 3–5 échecs
Vos IP de gestion sont dans /etc/csf/csf.ignore et /etc/csf/csf.allow

Matrice de décision : CSF est-il le bon outil pour votre environnement ?

FAQ

Quelle est la différence entre CSF et Fail2ban ?

Les deux outils effectuent le blocage d’IP par force brute en analysant les fichiers journaux, mais CSF est une suite de sécurité complète qui gère également les règles de pare-feu sous-jacentes, l’accès aux ports, la limitation du débit de connexion, la surveillance des processus et le filtrage GeoIP. Fail2ban est un outil de prévention des intrusions ciblé qui s’appuie sur un pare-feu externe (iptables, nftables ou firewalld) pour l’application. Sur les serveurs d’hébergement avec panneaux de contrôle, CSF est la solution opérationnellement la plus complète. Sur les systèmes Linux minimaux ou les conteneurs, Fail2ban associé à firewalld peut être plus léger et plus approprié.

CSF peut-il bloquer le trafic IPv6 ?

Oui. CSF gère à la fois les ensembles de règles iptables (IPv4) et ip6tables (IPv6). Le support IPv6 est activé par défaut lorsque le noyau le prend en charge. Assurez-vous que IPV6 = "1" est défini dans csf.conf et que vos listes de ports TCP6_IN / TCP6_OUT sont configurées, car elles reflètent par défaut les paramètres IPv4 mais peuvent être personnalisées indépendamment.

Comment éviter de me bloquer accidentellement lors de la configuration de CSF ?

Ajoutez votre IP de gestion dans /etc/csf/csf.allow et /etc/csf/csf.ignore avant d’effectuer tout changement restrictif. Conservez TESTING = "1" lors de la configuration initiale — en mode test, CSF charge les règles mais LFD n’applique pas les blocages, et les règles sont automatiquement vidées après 5 minutes si elles ne sont pas confirmées. Ne définissez TESTING = "0" qu’une fois que vous avez vérifié la connectivité.

CSF fonctionne-t-il sur des serveurs sans panneau de contrôle ?

Oui, entièrement. CSF est installé et géré entièrement via la ligne de commande. L’interface web est une couche de commodité optionnelle pour les environnements avec panneau de contrôle. Toute la configuration se fait via des fichiers plats dans /etc/csf/ et le binaire CLI csf. De nombreux administrateurs préfèrent la gestion uniquement via CLI pour l’auditabilité et l’automatisation via des outils de gestion de configuration comme Ansible ou Puppet.

À quelle fréquence CSF doit-il être mis à jour, et comment procéder ?

CSF doit être mis à jour à chaque nouvelle version publiée, en particulier pour les changements liés à la sécurité. Vérifiez les mises à jour avec csf -u, qui compare la version installée avec la dernière version disponible sur le serveur de téléchargement ConfigServer. Les mises à jour peuvent être appliquées directement depuis l’interface du plugin WHM ou via la CLI. Automatisez la vérification avec une tâche cron hebdomadaire, mais appliquez les mises à jour manuellement après avoir examiné le journal des modifications — les mises à jour de CSF modifient parfois les valeurs de configuration par défaut qui nécessitent une révision avant le déploiement.