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 plus de 57 millions de domaines dans le réseau global Imunify (données 2025). 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. Depuis décembre 2024, Imunify360 intègre aussi des améliorations mémoire et performance significatives qui réduisent l'empreinte de ce module sur les serveurs à forte charge.
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. Même logique pour les librairies système (glibc, openssl) via KernelCare.library. Cette approche est particulièrement pertinente pour les vulnérabilités critiques — dont la faille découverte en octobre 2025 dans le composant AI-Bolit d'ImunifyAV, qui permettait une exécution de code arbitraire sur les serveurs analysant des fichiers malveillants. CloudLinux a déployé le patch (v32.7.4.0) automatiquement sur les serveurs Imunify360 actifs avant la divulgation publique de 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 Mode, plafonne l'empreinte RAM à environ 100 Mo — 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.sh
Lancer 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. Si vous êtes en essai 14 jours, utilisez bash i360deploy.sh --key IPL (IP License — pas d'enregistrement CLN requis pour l'essai).
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, allez dans Settings → Proactive Defense et activez le mode KILL (bloque et stoppe le script malveillant) plutôt que LOG (log uniquement). En mode KILL, une exécution PHP suspectée est arrêtée instantanément. Commencez par LOG quelques jours si vous avez des applications métier complexes pour identifier les faux positifs avant de basculer.
Configurer le scan planifié
Dans Malware Scanner → Settings, 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 est liée à l'IP du serveur et s'enregistre via le CloudLinux Network (CLN) — exactement comme une licence CloudLinux OS. En cas de migration vers une nouvelle IP, il faut transférer la licence depuis le portail CLN avant de réinstaller, sinon le service passe en mode dégradé.
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é. Si vous tournez sur un serveur avec SELinux activé, installez le module de politique SELinux Imunify360 manuellement après installation (imunify360-selinux via yum) — sinon certains composants du pare-feu ne démarrent pas.
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 procédure de résolution officielle est : supprimer le vendor ruleset Imunify360, sauvegarder le datastore ModSecurity, réinstaller le vendor Imunify360, vérifier la configuration Apache, redémarrer le serveur web, puis re-tester le ruleset.
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 imunify360 n'a pas démarré après un reboot ou une mise à jour. Vérifiez avec systemctl status imunify360 puis journalctl -u imunify360 -n 50. Si vous voyez Tried to start while migrations are not applied, attendez 2 à 5 minutes — les migrations de base SQLite s'exécutent au démarrage et bloquent temporairement le service. Si le problème persiste, redémarrez manuellement : systemctl restart imunify360.
« Failed to connect to rpc socket [Errno 111] Connection refused »
Ce message (apparu notamment en v8.4.3) indique un échec du socket de communication interne entre les composants Imunify360. La cause est souvent un crash du processus principal pendant une migration. Solution : systemctl stop imunify360 && systemctl stop imunify360-pam && systemctl start imunify360. Si le problème revient, vérifiez les permissions du répertoire /var/run/imunify360/.
« 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 sendmail ou mail). Si la configuration est correcte, vérifiez que les ports 52223 et 52224 sont ouverts en sortie — Imunify360 les utilise pour communiquer avec les serveurs cloud CloudLinux. Un pare-feu amont bloquant ces ports coupe silencieusement les notifications.
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 ne se mettent plus à jour et le service repasse en mode dégradé. Vérifiez avec curl -v https://files.imunify360.com et 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, le plugin UI n'est pas enregistré. Exécutez /usr/share/imunify360/scripts/register-plugin.sh (ou l'équivalent selon la version) et rafraîchissez WHM. Vérifiez aussi que le service imunify360 est bien en active (running) avant de diagnostiquer l'interface.
Licences : comment ça marche
La licence Imunify360 est liée à l'IP du serveur et facturée au nombre d'utilisateurs (comptes cPanel, Plesk, etc. sur le serveur). Les plans débutent autour de 14 $/mois pour un serveur avec jusqu'à 30 utilisateurs. 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
| 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 57M+ domaines |
| 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 | Aucun équivalent disponible séparément | 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 (ce qui est le cas de la majorité des 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. C'est le seul environnement qui cumule isolation PHP (CloudLinux), protection runtime (Imunify360 Proactive Defense) et scan antivirus en un seul déploiement cohérent.
