Six defense layers, one product
Imunify360 is not just an antivirus. It stacks six complementary protection levels that reinforce each other: network firewall, WebShield (bot protection), application WAF, antivirus scanner with cleanup, Proactive Defense (PHP runtime), and intrusion detection (IDS/IPS). The strength of this architecture is that a threat that bypasses the WAF can still be stopped by Proactive Defense, and a threat that gets past the PHP runtime will be detected during the next antivirus scan. Each layer is independent but feeds into the next.
The six layers in detail
- Network firewall with threat intelligence: blocks known malicious IPs from a database fed by more than 57 million domains in the global Imunify network (2025 data). When an IP attacks one server in the network, it is blocked across all others within minutes.
- WebShield and bot protection: filters incoming HTTP traffic before it reaches the application — adaptive CAPTCHA, Graylist, layer 7 DDoS protection.
- Application WAF (ModSecurity + Imunify rules): inspects every HTTP request and blocks known exploits (injections, file inclusions, XSS). Rules are updated automatically from CloudLinux servers.
- Antivirus and malware scanner: real-time scanning of newly written files, schedulable background scan, automatic cleanup — Imunify attempts to eliminate malicious code while preserving the rest of the file.
- Proactive Defense: a PHP module that analyzes script behavior at runtime (not just static content). Blocks obfuscated webshells, reverse shells and data exfiltration even if the file passes the antivirus scan.
- IDS/IPS and patch management: detection of abnormal system-level behavior, coupled with KernelCare to apply Linux kernel patches without a reboot.
Proactive Defense: stopping obfuscated malware
Proactive Defense is the hardest layer to bypass. It does not scan files on disk — it intercepts PHP execution in real time and examines behavior patterns: attempts to write files outside the webroot, calls to exec(), shell_exec(), system(), eval() on unsanitized data, SQL injections from a script that should only be reading from the database. The module is available for Apache and LiteSpeed. Its main value is against obfuscated malware: a webshell that gets through static scanning tools because its code is base64-encoded and decoded at runtime will be stopped by Proactive Defense the moment it tries a dangerous action. Since December 2024, Imunify360 also integrates significant memory and performance improvements that reduce the footprint of this module on high-load servers.
KernelCare and reboot-free patch management
Imunify360's patch management relies on KernelCare (also developed by CloudLinux). KernelCare applies Linux kernel security patches in live memory, without stopping the server or the hosted sites. On a shared cPanel server hosting 200 clients, a reboot imposed for a kernel patch creates an uncomfortable maintenance window. KernelCare eliminates this constraint: the kernel runs on the patched version within seconds, with no downtime. The same logic applies to system libraries (glibc, openssl) via KernelCare.library. This approach was particularly relevant for the critical vulnerability discovered in October 2025 in ImunifyAV's AI-Bolit component, which allowed arbitrary code execution on servers analyzing malicious files. CloudLinux deployed the patch (v32.7.4.0) automatically on active Imunify360 servers before the public disclosure in November 2025.
RapidScan and CloudAV: scan performance at scale
On a server hosting hundreds of gigabytes of client files, a full daily antivirus scan is CPU-intensive. Imunify360 addresses this with two mechanisms. RapidScan speeds up repeated scans by up to 20 times compared to the first full scan: it maintains local metadata and cloud hashes to re-scan only files that have been created or modified since the last pass. CloudAV offloads deep analysis to Imunify Security's cloud infrastructure, without consuming local CPU for suspicious files that warrant a closer look. A third lever, Low Resource Mode, caps RAM footprint at around 100 MB — useful on VPS instances with limited resources where Imunify360 shares the server with MySQL, PHP-FPM and the rest of the cPanel stack.
Deployment: installing Imunify360 on cPanel/WHM
The official installation is done from the SSH command line as root. There is no yum repository to add manually: a deployment script downloads and configures everything automatically.
Step-by-step installation
Download the installation script
From a root session: wget https://repo.imunify360.cloudlinux.com/defence360/i360deploy.sh -O i360deploy.sh
Run the deployment with your license key
Execute bash i360deploy.sh --key YOUR_LICENSE_KEY. The key is obtained from your CloudLinux Network (CLN) account after purchase. For a 14-day trial, use bash i360deploy.sh --key IPL (IP License — no CLN registration required for the trial).
Verify WHM registration
Log in to WHM as root, then navigate to Plugins → Imunify360. Accept the license agreement on first access. The interface immediately displays the firewall status, active scans, and recent incidents.
Enable Proactive Defense
In WHM Imunify360, go to Settings → Proactive Defense and switch to KILL mode (blocks and stops the malicious script) rather than LOG mode (log only). In KILL mode, a suspected PHP execution is stopped instantly. Start with LOG for a few days if you have complex business applications, to identify false positives before switching.
Configure the scheduled scan
In Malware Scanner → Settings, set the frequency (daily recommended) and directory exclusions (caches, large backups). The first full scan can take several hours depending on the size of hosted data.
Register the license in CLN
The Imunify360 license is bound to the server's IP and registered via the CloudLinux Network (CLN) — exactly like a CloudLinux OS license. In case of migration to a new IP, you must transfer the license from the CLN portal before reinstalling, otherwise the service enters degraded mode.
Imunify360 supports AlmaLinux, Rocky Linux, RHEL, CloudLinux OS, Ubuntu 22/24 and Debian, and integrates with cPanel, Plesk, DirectAdmin or standalone. Since November 2024, Ubuntu 24 is officially supported. If you are running on a server with SELinux enabled, install the Imunify360 SELinux policy module manually after installation (imunify360-selinux via yum) — otherwise some firewall components will not start.
WAF rules management and OWASP conflicts
Imunify360's WAF relies on ModSecurity with a ruleset maintained by CloudLinux. If your server previously used the OWASP ruleset (common on manually configured cPanel setups), disable OWASP before installing Imunify360: the two rulesets create conflicts, cascading legitimate blocks and massive false positives. Imunify360 manages its own rules autonomously — it is not designed to coexist with OWASP. In case of conflict after installation, the official resolution procedure is: remove the Imunify360 vendor ruleset, back up the ModSecurity datastore, reinstall the Imunify360 vendor, check the Apache configuration, restart the web server, then re-test the ruleset.
Troubleshooting: common error messages
The most common problems after installing or updating Imunify360 have precise causes and documented solutions.
Resolving common errors
"Imunify agent is not running"
Most common cause: the imunify360 service did not start after a reboot or update. Check with systemctl status imunify360 then journalctl -u imunify360 -n 50. If you see Tried to start while migrations are not applied, wait 2 to 5 minutes — SQLite migrations run on startup and temporarily block the service. If the problem persists, restart manually: systemctl restart imunify360.
"Failed to connect to rpc socket [Errno 111] Connection refused"
This message (notably appearing in v8.4.3) indicates a failure of the internal communication socket between Imunify360 components. The cause is often a crash of the main process during a migration. Solution: systemctl stop imunify360 && systemctl stop imunify360-pam && systemctl start imunify360. If the problem recurs, check the permissions of /var/run/imunify360/.
"You must install the following extensions before you can edit their values: imunify360" (WHM)
This WHM message appears when editing a cPanel package on a server where Imunify360 is installed but feature management is not enabled. Resolution command: imunify360-agent feature-management native enable. The operation is immediate and does not require a restart.
"Malware detected" notifications not received
Imunify360 can detect malware without sending the configured e-mail alerts. First check that the notification service is active in Settings → Notifications and that the configured email address is reachable from the server (test with sendmail or mail). If the configuration is correct, verify that ports 52223 and 52224 are open outbound — Imunify360 uses them to communicate with CloudLinux cloud servers. An upstream firewall blocking these ports silently cuts notifications.
Lost connectivity to `files.imunify360.com` or `imunify360.cloudlinux.com`
Automatic updates of WAF rules and antivirus signature databases go through these two domains. If the server cannot reach them (restrictive outbound firewall, proxy, internal DNS), rules stop updating and the service enters degraded mode. Check with curl -v https://files.imunify360.com and add an outbound exception if necessary.
Imunify360 plugin missing from WHM interface
If the Imunify360 menu entry does not appear in WHM/cPanel despite an apparently successful installation, the UI plugin is not registered. Run /usr/share/imunify360/scripts/register-plugin.sh (or the equivalent for your version) and refresh WHM. Also verify that the imunify360 service is active (running) before diagnosing the interface.
Licenses: how it works
The Imunify360 license is bound to the server's IP and billed by the number of users (cPanel, Plesk accounts, etc. on the server). Plans start at around $14/month for a server with up to 30 users. A standalone offer (without a control panel) is also available for pure Nginx or Apache servers. Registration is done in the CloudLinux Network (CLN), the same portal as for CloudLinux OS licenses. In case of migration to a new IP, the license transfer is handled directly from the CLN portal — no need to repurchase. Reseller licenses (5+ servers) benefit from volume pricing. With ServOrbit, Imunify360 licenses are available directly from the client area, bound to the IP of your dedicated server or cloud VPS.
Imunify360 vs. separate tools: what you avoid
| Need | Without Imunify360 | With Imunify360 |
|---|---|---|
| Network firewall + threat intelligence | CSF + LFD (manual config, no global network) | Integrated, auto-updated from 57M+ domains |
| Application WAF | ModSecurity + OWASP (rules to maintain manually) | Imunify ruleset maintained and pushed automatically |
| Malware antivirus | ClamAV (scan only, no automatic cleanup) | Scan + automatic cleanup + CloudAV |
| PHP runtime protection | No equivalent available separately | Integrated Proactive Defense |
| Kernel patching without reboot | Manual update + maintenance window | Integrated KernelCare |
| Centralized WHM management | Disparate tools, no unified interface | Native WHM plugin, unified incident view |
If your server runs CloudLinux OS (which is the case for most shared cPanel servers), Imunify360 benefits from enhanced integration with per-user PHP cages (CageFS). Each cPanel account sees an isolated PHP environment: malware executing in one client's site context cannot read other clients' files. This is the only environment that combines PHP isolation (CloudLinux), runtime protection (Imunify360 Proactive Defense) and antivirus scanning in a single coherent deployment.
