Coexistence avec d'autres outils de sécurité
Comment InfraFence fonctionne à côté de CSF et lfd, Imunify360, ImunifyAV, cPHulk, fail2ban, CrowdSec, BitNinja, Monarx, firewalld, ufw, Plesk Firewall et ModSecurity, outil par outil.
Dernière mise à jour:
La plupart des serveurs font déjà tourner quelque chose. InfraFence est conçu pour cohabiter avec : toutes ses règles se trouvent dans ses propres chaînes et ensembles (INFRAFENCE, INFRAFENCE-RULES, INFRAFENCE-PORTS, INFRAFENCE-EGRESS), et il ne modifie, ne vide ni ne réordonne jamais les règles d'un autre outil. Si le rechargement d'un autre outil (ufw reload, firewall-cmd --reload, csf -r, netfilter-persistent, iptables-restore) supprime son saut, l'agent le remet en place en moins d'une minute.
L'agent détecte ces outils en lecture seule, et l'écran Coexistence des plugins de panneaux les affiche. Quand un autre outil actif gère le pare-feu, InfraFence fonctionne en mode coexist ; sinon il est primary.
| Outil | Ce que fait InfraFence à côté |
|---|---|
| CSF (ConfigServer Firewall) | Garde sa propre chaîne et ne modifie jamais csf.conf, csf.allow ni csf.deny. Après csf -r, il ne restaure que son propre saut. Les ports CSF ne changent que si vous le demandez depuis le tableau de bord. |
| lfd (Login Failure Daemon) | Les deux lisent les mêmes journaux et bloquent chacun de leur côté : les blocages de lfd restent dans CSF, les bannissements d'InfraFence dans son propre ensemble. |
| Imunify360 | Ne touche ni au pare-feu, ni aux ipsets, ni au WAF d'Imunify360 et s'en tient à sa propre chaîne ; les deux bloquent indépendamment. |
| ImunifyAV | Les deux analysent les fichiers. InfraFence ne supprime ni ne déplace jamais un fichier de lui-même : quarantaine uniquement sur demande. |
| cPHulk | cPHulk bloque les connexions au panneau et aux services ; InfraFence lit les mêmes journaux et bannit au niveau du pare-feu. cPHulk n'est pas modifié. |
| fail2ban | Compatible : les deux ne font que rejeter du trafic. InfraFence ne touche pas aux chaînes de fail2ban. |
| CrowdSec | Compatible : les deux ne font que rejeter du trafic. InfraFence ne touche pas aux règles de CrowdSec. |
| Plesk Firewall | Plesk réécrit ses règles quand vous appliquez des modifications ; InfraFence ne les modifie jamais et ne restaure que sa propre chaîne, en moins d'une minute. |
| BitNinja | Ne touche ni au pare-feu ni au WAF de BitNinja et s'en tient à sa propre chaîne ; les deux bloquent indépendamment. |
| Monarx | Les deux analysent les fichiers. InfraFence ne supprime ni ne déplace jamais un fichier de lui-même : quarantaine uniquement sur demande. |
| firewalld | Garde ses propres règles ; la chaîne d'InfraFence est indépendante et restaurée en moins d'une minute après un rechargement. |
| ufw | InfraFence saute vers sa chaîne avant les règles d'ufw ; un rechargement d'ufw est réparé en moins d'une minute. |
| ModSecurity | InfraFence lit le journal d'audit de ModSecurity pour ses détections. Sous un panneau d'hébergement, il n'ajoute aucune règle ModSecurity : c'est le panneau qui gère la configuration du serveur web. Les jeux de règles trouvés (OWASP CRS, Comodo WAF, Imunify360 WAF, Atomicorp) sont listés. |
Quand un outil réécrit sans cesse le pare-feu
Si l'agent doit réparer ses chaînes plusieurs fois d'affilée, ou trois fois ou plus en une heure, il signale un événement firewall_conflict : un autre outil réécrit sans cesse le pare-feu (ufw, firewalld, CSF, netfilter-persistent ou une exécution de gestion de configuration). Les bannissements continuent de fonctionner ; l'événement vous indique où chercher.
Listes blanches
Une adresse en liste blanche est seulement exemptée des blocages d'InfraFence : InfraFence n'ajoute jamais d'ACCEPT, il n'ouvre donc jamais ce qu'un autre outil a fermé.