Six couches de défense, un seul produit
Imunify360 ne se résume pas à un antivirus. Il empile six niveaux de protection complémentaires qui se renforcent mutuellement : pare-feu réseau, WebShield (protection des bots), WAF applicatif, scanner antivirus avec nettoyage, Proactive Defense (runtime PHP), et détection d'intrusion (IDS/IPS). La force de cette architecture est qu'une menace qui contourne le WAF peut encore être arrêtée par la Proactive Defense, et une menace qui passe le runtime PHP sera détectée lors du prochain scan antivirus. Chaque couche est indépendante mais alimente les suivantes.
Les six couches en détail
- Pare-feu réseau avec threat intelligence : bloque les IP malveillantes connues à partir d'une base alimentée par le réseau global Imunify, qui couvre plusieurs dizaines de millions de domaines selon l'éditeur. Quand une IP attaque un serveur du réseau, elle est bloquée sur tous les autres en quelques minutes.
- WebShield et protection bots : filtre le trafic HTTP entrant avant qu'il n'atteigne l'application — CAPTCHA adaptatif, listes grises (Graylist), protection DDoS de couche 7.
- WAF applicatif (ModSecurity + règles Imunify) : inspecte chaque requête HTTP et bloque les exploits connus (injections, inclusions de fichiers, XSS). Les règles sont mises à jour automatiquement depuis les serveurs CloudLinux.
- Antivirus et scan malware : scan en temps réel des fichiers nouvellement écrits, scan de fond planifiable, nettoyage automatique — Imunify tente d'éliminer le code malveillant en conservant le reste du fichier.
- Proactive Defense : module PHP qui analyse le comportement des scripts à l'exécution (et non seulement leur contenu statique). Bloque webshells obfusqués, reverse shells et exfiltration de données même si le fichier passe le scan antivirus.
- IDS/IPS et patch management : détection des comportements anormaux côté système, couplée à KernelCare pour appliquer des patches noyau Linux sans redémarrage.
La Proactive Defense : arrêter les malwares obfusqués
La Proactive Defense est la couche la plus difficile à contourner. Elle ne scanne pas les fichiers sur disque — elle intercepte l'exécution PHP en temps réel et examine les patterns de comportement : tentative d'écriture de fichiers hors du webroot, appels à exec(), shell_exec(), system(), eval() sur des données non sanitisées, injections SQL depuis un script qui devrait se contenter de lire la base. Le module est disponible pour Apache et LiteSpeed. Son intérêt principal est contre le malware obfusqué : un webshell qui passe à travers les outils de scan statiques parce que son code est encodé en base64 et décodé à l'exécution sera arrêté par la Proactive Defense dès qu'il tente une action dangereuse. Il requiert le PHP durci de CloudLinux (alt-php, « Hardened PHP ») pour fonctionner.
KernelCare et le patch management sans redémarrage
Le patch management d'Imunify360 repose sur KernelCare (aussi développé par CloudLinux). KernelCare applique les patches de sécurité du noyau Linux en mémoire vive, sans arrêter le serveur ni les sites hébergés. Sur un serveur partagé cPanel qui héberge 200 clients, un redémarrage imposé pour un patch noyau crée une fenêtre de maintenance inconfortable. KernelCare élimine cette contrainte : le noyau tourne en version sécurisée en quelques secondes, sans downtime. L'intégration documentée par Imunify360 porte sur le noyau ; les bibliothèques système (glibc, openssl) suivent les mises à jour habituelles du système. Les mises à jour automatiques comptent aussi pour Imunify360 lui-même : la faille du composant AI-Bolit (partagé par Imunify360, ImunifyAV et ImunifyAV+), qui permettait l'exécution de code arbitraire, jusqu'aux droits root, lors de l'analyse d'un fichier piégé, a été corrigée en octobre 2025 par la version 32.7.4-1. Le correctif a été poussé automatiquement sur la grande majorité des serveurs avant l'avis de sécurité publié en novembre 2025 — illustration directe de l'avantage des mises à jour automatiques.
RapidScan et CloudAV : performance des scans à grande échelle
Sur un serveur qui héberge des centaines de gigaoctets de fichiers clients, un scan antivirus complet et quotidien est coûteux en CPU. Imunify360 répond avec deux mécanismes. RapidScan accélère les scans répétés jusqu'à 20 fois par rapport au premier scan complet : il maintient des métadonnées locales et des hash cloud pour ne re-scanner que les fichiers créés ou modifiés depuis le dernier passage. CloudAV déporte l'analyse approfondie vers l'infrastructure cloud d'Imunify Security, sans consommer le CPU local pour les fichiers suspects qui méritent un examen plus poussé. Le troisième levier, Low Resource Usage, réduit la consommation CPU et RAM (WebShield désactivé, jeu de règles WAF minimal) — utile sur des VPS aux ressources limitées où Imunify360 partage le serveur avec MySQL, PHP-FPM et le reste de la stack cPanel.
Déploiement : installer Imunify360 sur cPanel/WHM
L'installation officielle se fait depuis la ligne de commande SSH, en tant que root. Il n'y a pas de paquet yum à ajouter manuellement : un script de déploiement télécharge et configure tout automatiquement.
Installation pas à pas
Télécharger le script d'installation
Depuis une session root :
wget https://repo.imunify360.cloudlinux.com/defence360/i360deploy.sh -O i360deploy.shLancer le déploiement avec la clé de licence
Exécutez
bash i360deploy.sh --key VOTRE_CLE_LICENCE. La clé s'obtient depuis votre espace CloudLinux Network (CLN) après achat. En essai 14 jours, la clé d'essai reçue par e-mail s'utilise de la même façon ; avec une licence liée à l'IP, lancez le script sans argument :bash i360deploy.sh.Vérifier l'enregistrement WHM
Connectez-vous à WHM en tant que root, puis naviguez vers Plugins → Imunify360. Acceptez le contrat de licence lors du premier accès. L'interface affiche immédiatement le statut du pare-feu, des scans actifs et des incidents récents.
Activer la Proactive Defense
Dans WHM Imunify360, ouvrez l'onglet Proactive Defense et activez le mode
Kill Mode(bloque et stoppe le script malveillant) plutôt queLog Only(journalisation seule, mode par défaut). EnKill Mode, une exécution PHP suspectée est arrêtée instantanément. Restez enLog Onlyquelques jours si vous avez des applications métier complexes pour identifier les faux positifs avant de basculer.Configurer le scan planifié
Dans Settings → Malware Scanner, définissez la fréquence (quotidien recommandé) et les exclusions de répertoires (caches, backups volumineux). Le premier scan complet peut durer plusieurs heures selon la taille des données hébergées.
Enregistrer la licence dans CLN
La licence Imunify360, par clé ou par IP, se gère dans le CloudLinux Network (CLN) — exactement comme une licence CloudLinux OS. En cas de migration, retirez l'ancien serveur (ou l'ancienne IP) de la licence dans CLN, enregistrez le nouveau (
imunify360-agent register VOTRE_CLE, ouimunify360-agent register IPLpour une licence par IP), puis contrôlez avecimunify360-agent rstatus.
Imunify360 supporte AlmaLinux, Rocky Linux, RHEL, CloudLinux OS, Ubuntu 22/24 et Debian, et s'intègre à cPanel, Plesk, DirectAdmin ou en standalone. Depuis novembre 2024, Ubuntu 24 est officiellement supporté. Sur un serveur avec SELinux activé, le script i360deploy.sh applique lui-même le module de politique SELinux d'Imunify360 ; ce n'est qu'en cas d'installation directe des paquets RPM qu'il faut le compiler et le charger à la main (checkmodule, semodule_package, semodule -i), puis redémarrer imunify360 et imunify360-webshield.
Gestion des règles WAF et conflits OWASP
Le WAF d'Imunify360 repose sur ModSecurity avec un jeu de règles propre maintenu par CloudLinux. Si votre serveur utilisait auparavant le jeu de règles OWASP (fréquent sur des configurations cPanel manuelles), désactivez OWASP avant d'installer Imunify360 : les deux jeux de règles créent des conflits, des blocages légitimes en cascade et des faux positifs massifs. Imunify360 gère ses propres règles de façon autonome — il n'est pas prévu pour cohabiter avec OWASP. En cas de conflit après installation, la documentation officielle recommande de passer sur Off, dans la section ModSecurity Vendors de WHM, tous les vendors tiers sauf le ruleset Imunify360, puis, si ce dernier manque, de le réinstaller avec imunify360-agent install-vendors.
Dépannage : messages d'erreur fréquents
Les problèmes les plus courants après installation ou mise à jour d'Imunify360 ont des causes précises et des solutions documentées.
Résolution des erreurs courantes
« Imunify agent is not running »
Cause la plus fréquente : le service
imunify360n'a pas démarré après un reboot ou une mise à jour. Vérifiez avecsystemctl status imunify360puisjournalctl -u imunify360 -n 50. Si le service est actif mais que le tableau de bord affiche toujours ce message juste après l'installation, laissez du temps : la base SQLite de l'agent se synchronise avec l'interface, et la documentation officielle conseille d'attendre jusqu'à 60 minutes. Si le problème persiste, redémarrez manuellement :systemctl restart imunify360.« Connection refused » sur un socket interne de l'agent
Ce type d'erreur (
Errno 111) indique qu'aucun processus n'écoute sur le socket de communication interne entre les composants Imunify360. La cause habituelle est un agent arrêté, ou un démon (commeimunify360-wafd) qui n'a pas redémarré après une mise à jour. Vérifiezsystemctl status imunify360et le journal (journalctl -u imunify360 -n 50), puis relancez le service :systemctl restart imunify360. Si le problème revient, forcez la mise à jour vers la dernière version stable avec le script officielimunify-force-update.sh(wget -O imunify-force-update.sh https://repo.imunify360.cloudlinux.com/defence360/imunify-force-update.sh && bash imunify-force-update.sh).« You must install the following extensions before you can edit their values: imunify360 » (WHM)
Ce message WHM apparaît lors de l'édition d'un package cPanel sur un serveur où Imunify360 est installé mais où le feature management n'est pas activé. Commande de résolution :
imunify360-agent feature-management native enable. L'opération est immédiate et ne nécessite pas de redémarrage.Notifications « Malware detected » non reçues
Imunify360 peut détecter des malwares sans envoyer les alertes e-mail configurées. Vérifiez d'abord que le service de notification est actif dans Settings → Notifications et que l'adresse e-mail configurée est joignable depuis le serveur (tester avec
sendmailoumail). Si la configuration est correcte, vérifiez que le serveur joint en sortie le serveur centralimunify360.cloudlinux.comsur le port 443, contrôle indiqué par la documentation officielle. Les ports 52223 et 52224 sont, eux, des ports locaux de WebShield, pas des ports sortants.Connectivité perdue vers `files.imunify360.com` ou `imunify360.cloudlinux.com`
Les mises à jour automatiques des règles WAF et de la base de signatures antivirus passent par ces deux domaines. Si le serveur ne peut pas les joindre (pare-feu sortant restrictif, proxy, DNS interne), les règles et les signatures ne se mettent plus à jour. Vérifiez avec
curl -v https://files.imunify360.comet ajoutez une exception sortante si nécessaire.Plugin Imunify360 absent de l'interface WHM
Si l'entrée de menu Imunify360 n'apparaît pas dans WHM/cPanel malgré une installation en apparence réussie, vérifiez d'abord que la licence est bien enregistrée :
imunify360-agent rstatusdoit rendreOK, sinon enregistrez l'agent (imunify360-agent register VOTRE_CLE) et rafraîchissez WHM. Vérifiez aussi que le serviceimunify360est bien enactive (running)avant de diagnostiquer l'interface.
Licences : comment ça marche
La licence Imunify360 s'active par clé ou par l'IP du serveur et se facture au nombre d'utilisateurs (comptes cPanel, Plesk, etc. sur le serveur). Les paliers se choisissent selon le nombre total de comptes hébergés ; les tarifs à jour figurent sur la page tarifs de l'éditeur. Une offre standalone (sans panneau de contrôle) est aussi disponible pour les serveurs Nginx ou Apache purs. L'enregistrement se fait dans le CloudLinux Network (CLN), le même portail que pour les licences CloudLinux OS. En cas de migration vers une nouvelle IP, le transfert de licence se gère directement depuis le portail CLN — il n'y a pas besoin de racheter. Les licences revendeur (5 serveurs+) bénéficient de prix dégressifs. Pour ServOrbit, les licences Imunify360 sont disponibles directement depuis l'espace client, liées à l'IP de votre serveur dédié ou VPS cloud.
Imunify360 vs. outils séparés : ce que vous évitez
Faites défiler le tableau
| Besoin | Sans Imunify360 | Avec Imunify360 |
|---|---|---|
| Pare-feu réseau + threat intelligence | CSF + LFD (config manuelle, pas de réseau global) | Intégré, mis à jour auto depuis le réseau global Imunify |
| WAF applicatif | ModSecurity + OWASP (règles à maintenir manuellement) | Ruleset Imunify maintenu et poussé automatiquement |
| Antivirus malware | ClamAV (scan seul, pas de nettoyage automatique) | Scan + nettoyage automatique + CloudAV |
| Protection runtime PHP | Pas d'équivalent intégré, à assembler soi-même | Proactive Defense intégrée |
| Patch noyau sans redémarrage | Mise à jour manuelle + fenêtre de maintenance | KernelCare intégré |
| Gestion centralisée WHM | Outils disparates, pas d'interface unifiée | Plugin WHM natif, vue unifiée des incidents |
Si votre serveur tourne sous CloudLinux OS (fréquent sur les serveurs cPanel partagés), Imunify360 bénéficie d'une intégration renforcée avec les cages PHP par utilisateur (CageFS). Chaque compte cPanel voit un environnement PHP isolé : un malware qui s'exécute dans le contexte d'un site client ne peut pas lire les fichiers des autres clients. Cet environnement cumule isolation PHP (CloudLinux), protection runtime (Imunify360 Proactive Defense) et scan antivirus en un seul déploiement cohérent.
