Install Imunify360 on a cPanel and CloudLinux server

Imunify360 is the CloudLinux security stack — a layered WAF, malware scanner, brute-force protection, and Proactive Defense PHP runtime sandbox bundled together. On a shared cPanel node it replaces a sprawl of ad-hoc tools (ModSecurity rules, ClamAV cron jobs, fail2ban, custom suspend scripts) with a single agent and a single WHM plugin.

This guide covers the install on a cPanel server running CloudLinux OS — the supported and recommended combination. Imunify360 also runs on AlmaLinux 8/9 and Rocky 8/9 without CloudLinux, but several features (CageFS hardening, MySQL access rules) require CloudLinux to work. Budget 20 minutes end-to-end plus a Tweak Settings restart.

Before you start

• A working cPanel & WHM instance with root SSH.
• CloudLinux OS already installed — or AlmaLinux/Rocky if you accept the reduced feature set.
• 1 GB of free RAM beyond the existing cPanel and CloudLinux footprint. Imunify360's agent and scanner together resident around 400-700 MB at steady state.
• An Imunify360 activation key. If you don't have one, grab it from the Imunify360 product page — single-server keys activate immediately.
• Port 443 outbound open to the Imunify360 cloud (*.imunify360.com). The agent calls home for reputation feeds and signature updates every five minutes.

Step 1 — Activate the licence

Imunify360 keys bind to an IP, not a hostname. Run the activation in the same shell session as the installer so they share an IP view:

curl https://repo.imunify360.cloudlinux.com/defence360/i360deploy.sh -o i360deploy.sh
bash i360deploy.sh --key YOUR-ACTIVATION-KEY

The deploy script:

1. Adds the Imunify360 yum repository.
2. Installs the imunify360-firewall package and dependencies.
3. Registers the licence against the server's primary IP.
4. Drops a new WHM plugin under Plugins → Imunify360.

The installer is idempotent — if it fails mid-run, fix the cause (usually outbound 443 or a yum conflict) and re-run it. Total runtime on a fresh node is 5-8 minutes.

Step 2 — Verify the install

After the installer completes, three things should be true:

# 1. The service is running
systemctl status imunify360

# 2. The agent reports as registered
imunify360-agent version

# 3. The WAF is loaded
imunify-policy whitelist list

A healthy version output ends with License: VALID. If it says EXPIRED or NOT_FOUND, the activation didn't bind — see the Imunify360 licence is invalid recovery section below.

The WHM plugin under Plugins → Imunify360 should show the dashboard within 60 seconds of the install completing. If the page is blank, hard-refresh — the cPanel asset cache sometimes holds the old (empty) plugin manifest for a minute.

Step 3 — Enable Proactive Defense

Proactive Defense is the runtime PHP sandbox — it intercepts PHP function calls inside running customer scripts and blocks malicious patterns (eval-decoded shells, file_put_contents into web roots, assert() payloads) before they execute. It catches uploaded webshells that slip past static scanning. It's off by default.

In WHM → Plugins → Imunify360 → Proactive Defense set the mode to Kill mode:

• Log only — observes and reports but doesn't block. Use for the first 48 hours on a busy shared box if you're nervous about false positives.
• Kill mode — terminates the PHP process when a malicious pattern fires. This is the recommended production setting.
• Disabled — off. Don't run Imunify360 without Proactive Defense, you're paying for the feature.

Proactive Defense requires CloudLinux's mod_lsapi PHP handler. If you're on Apache with mod_php or suPHP, switch to mod_lsapi first — the CloudLinux PHP Selector setup walks through it.

Step 4 — Tune the three defaults that cause support tickets

Out of the box, three Imunify360 defaults trigger more customer complaints than they prevent attacks. Change them before exposing the panel to users:

1. WebShield CAPTCHA threshold. Default is 3 failed connection attempts before challenging. On mobile networks behind shared NAT, legitimate users trip this. Bump it to 8 under WAF → Settings → Captcha.

2. MyImunify customer self-service. Default is enabled — customers see a MyImunify panel in cPanel that lets them whitelist their own IPs. Disable it unless you've trained support, because users will whitelist attackers thinking they're whitelisting themselves. WHM → Plugins → Imunify360 → MyImunify → Disable.

3. Malware Scanner action. Default is Clean up which modifies the customer's files. For a managed service this is fine. For unmanaged hosting where customers expect files not to be touched, switch to Quarantine instead and notify the customer.

Step 5 — Confirm the WAF is taking traffic

Generate a test 4xx to confirm the WAF is in the request path:

curl -A "() { :; }; echo VULNERABLE" https://your-server.example.com/

A correctly-installed Imunify360 returns HTTP 403 with the body Access Denied by ImunifyAV+. If you get 200 OK or the site's normal homepage, the WAF isn't intercepting — re-check that LiteSpeed or Apache is configured to use Imunify360's ModSecurity ruleset under WAF → ModSecurity.

Imunify360 licence shows as invalid

The most common cause is that the activation IP doesn't match the server's outbound IP. On a NATed VPS or a host behind a load balancer, the IP the licence sees is the gateway, not the server. Check:

# What the server thinks its IP is
imunify360-agent server-info | grep ip

# What the licence server thinks it is
curl -s https://imunify360.cloudlinux.com/api/me | jq .ip

If these don't match, the licence is bound to the wrong address. Open a support ticket with us with both IPs — we rebind from the partner side without you having to buy a new key.

How Imunify360 interacts with cPanel features

A few integrations that surprise people:

• AutoSSL still works. Imunify360's WAF allows ACME challenge paths by default.
• WHM brute-force protection (cPHulk) and Imunify360 brute-force both run. Disable cPHulk to avoid double-counting — Imunify360 is the more thorough of the two.
• Backup tools (JetBackup, R1soft) are detected automatically and excluded from the malware scanner. Custom backup scripts are not — add them to the scanner exclude list under Files → Ignore List.

For licensing questions across the CloudLinux stack — Imunify360 versus the cheaper ImunifyAV+ scanner-only SKU, or whether Imunify360 is bundled with your CloudLinux licence — see the CloudLinux licensing breakdown.

Next steps

• Pair Imunify360 with CloudLinux LVE tuning — runtime sandbox plus per-user resource limits is the standard shared-hosting security baseline.
• New to CloudLinux? Start with installing CloudLinux OS on a cPanel server and then come back to Imunify360.
• For LiteSpeed users, the LSWS install guide covers the ModSecurity handover that Imunify360 expects on its first run.