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 the global Imunify network, which covers several tens of millions of domains according to the vendor. 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. It requires CloudLinux's Hardened PHP (alt-php) to operate.
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 integration documented by Imunify360 covers the kernel; system libraries (glibc, openssl) follow the usual system updates. Automatic updates matter for Imunify360 itself too: the flaw in the AI-Bolit component (shared by Imunify360, ImunifyAV and ImunifyAV+), which allowed arbitrary code execution, up to root privileges, when scanning a crafted file, was fixed in October 2025 by version 32.7.4-1. The fix was pushed automatically to the vast majority of servers before the security advisory published 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 Usage, reduces CPU and RAM consumption (WebShield disabled, minimized WAF ruleset) — 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.shRun 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, the trial key received by email is used the same way; with an IP-based license, run the script without arguments:bash i360deploy.sh.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, open the Proactive Defense tab and switch to
Kill Mode(blocks and stops the malicious script) rather thanLog Only(logging only, the default mode). InKill Mode, a suspected PHP execution is stopped instantly. Stay inLog Onlyfor a few days if you have complex business applications, to identify false positives before switching.Configure the scheduled scan
In Settings → Malware Scanner, 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, key-based or IP-based, is managed in the CloudLinux Network (CLN) — exactly like a CloudLinux OS license. When migrating, remove the old server (or old IP) from the license in CLN, register the new one (
imunify360-agent register YOUR_KEY, orimunify360-agent register IPLfor an IP-based license), then check withimunify360-agent rstatus.
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. On a server with SELinux enabled, the i360deploy.sh script applies the Imunify360 SELinux policy module itself; only if you install the RPM packages directly do you need to compile and load it by hand (checkmodule, semodule_package, semodule -i), then restart imunify360 and imunify360-webshield.
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 documentation recommends switching to Off, in the WHM ModSecurity Vendors section, every third-party vendor except the Imunify360 ruleset, then, if that ruleset is missing, reinstalling it with imunify360-agent install-vendors.
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
imunify360service did not start after a reboot or update. Check withsystemctl status imunify360thenjournalctl -u imunify360 -n 50. If the service is active but the dashboard still shows this message right after installation, give it time: the agent's SQLite database is syncing with the interface, and the official documentation advises waiting up to 60 minutes. If the problem persists, restart manually:systemctl restart imunify360."Connection refused" on an internal agent socket
This type of error (
Errno 111) means that no process is listening on the internal communication socket between Imunify360 components. The usual cause is a stopped agent, or a daemon (such asimunify360-wafd) that did not restart after an update. Checksystemctl status imunify360and the log (journalctl -u imunify360 -n 50), then restart the service:systemctl restart imunify360. If the problem recurs, force the update to the latest stable version with the officialimunify-force-update.shscript (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)
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
sendmailormail). If the configuration is correct, check that the server can reach the central serverimunify360.cloudlinux.comoutbound on port 443, a check given by the official documentation. Ports 52223 and 52224, for their part, are local WebShield ports, not outbound ports.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 and signatures stop updating. Check with
curl -v https://files.imunify360.comand 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, first check that the license is registered:
imunify360-agent rstatusmust returnOK; otherwise register the agent (imunify360-agent register YOUR_KEY) and refresh WHM. Also verify that theimunify360service isactive (running)before diagnosing the interface.
Licenses: how it works
The Imunify360 license is activated by key or by the server's IP and billed by the number of users (cPanel, Plesk accounts, etc. on the server). Tiers are chosen by the total number of hosted accounts; current prices are published on the vendor's pricing page. 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
Scroll the table
| Need | Without Imunify360 | With Imunify360 |
|---|---|---|
| Network firewall + threat intelligence | CSF + LFD (manual config, no global network) | Integrated, auto-updated from the global Imunify network |
| 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 integrated equivalent, to be assembled yourself | 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 (common on 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 environment combines PHP isolation (CloudLinux), runtime protection (Imunify360 Proactive Defense) and antivirus scanning in a single coherent deployment.
