Skip to content

Imunify360 ​

Where to find it in the panel: Imunify360 is at /admin/settings/imunify360, under Settings > Tools > Imunify360 once it is installed, and its module page is at /admin/modules/imunify360. Health > Security compares it with ImunifyAV and cPGuard.

Imunify360 is a comprehensive security platform for Linux web-hosting servers: web application firewall (WAF), malware detection and cleanup, brute-force protection, and reputation management. AdminBolt installs it and surfaces it to both administrators and end users. Only one of Imunify360, ImunifyAV, and CPGuard can be active on a server.

Installation ​

  1. Open Health > Security and click Install on the Imunify360 card, or open Modules in the sidebar (/admin/modules) and select Imunify360. Both start the installer (/admin/imunify360-installer), which has no sidebar entry of its own.
  2. Enter your Imunify360 activation key and proceed. The installer downloads and sets up the Imunify360 packages and reports progress.

Without a key, Imunify360 installs unlicensed unless CloudLinux Network (CLN) already licenses this server by its IP address, and the result says that it protects nothing until it is registered. On a server with ImunifyAV, use Upgrade to Imunify360 instead; see ImunifyAV.

What the installer sets up ​

Since panel 1.9.3, an Imunify360 installed from the panel works with the rest of the server:

  • Accounts. Imunify360 sees the hosting accounts, their domains, and the administrator. It counts these accounts against the licence's user limit.
  • ModSecurity. The installer switches on the web server's ModSecurity engine and loads the Imunify360 rules, so its WAF enforces straight away. ModSecurity Config shows whether the rules are in effect. OpenLiteSpeed does not load ModSecurity through AdminBolt, so there the installer finishes with a warning.
  • WebShield. The installer switches WebShield on and hands it each site's own certificate; see WebShield certificates.
  • Fail2Ban. Fail2Ban keeps running with all its jails; see Login protection.

When one of these parts could not be set up, the result says that Imunify360 is installed and names what is missing, with the next step.

When the installation fails ​

Since panel 1.9.3, a failed installation names its cause when the panel recognises it:

  • Imunify360 did not accept the licence for this server. The activation key may be right and still be refused for this server by its server or user limit. Check the key, and its limits, in your CloudLinux Network account, then install again.
  • The Imunify360 package repository refused the download, or the server could not reach it.

Otherwise the message quotes the last lines of the installer's own log, without the activation key.

A failed first installation is rolled back, so the server is not left with a half-installed Imunify360. An Imunify360 that was on the server before the run is never removed.

Running the installer again on a server that already has Imunify360 is how a new key is applied. Imunify360 removes the current key first, so when the new key is refused the server is left without a licence. The installer then says so and gives the command that registers the server again.

Servers upgraded from an earlier version ​

Updating the panel to 1.9.3 repairs an Imunify360 installed from an earlier version: licence counting, the ModSecurity rules (unless you switched ModSecurity off), WebShield, and Fail2Ban, which earlier installers stopped. The step also checks the licence and reports a refused licence with how to register it; registering needs the activation key, which the panel does not keep. If the step cannot finish, for example because bolt-agent does not answer right after the update, it changes nothing and runs again with:

bash
bolt-cli run-upgrade-steps --retry-failed

Login protection ​

Imunify360 protects SSH logins and blocks the addresses of FTP brute force attacks. Mail (IMAP, POP3, SMTP), webmail, and panel logins are not covered by it, so since panel 1.9.3 Fail2Ban keeps running next to Imunify360 with its jails and keeps protecting them. The Imunify360 pages and Fail2Ban Settings say so.

Keep Fail2Ban running. When it is installed but stopped on an Imunify360 server, Health warns that these logins have no brute force protection.

WebShield certificates ​

WebShield serves each site with that site's own certificate, for the domain and every name the site is served under, such as www., parked domains, and the mail and webmail names. The panel keeps WebShield in step: a certificate that is issued, renewed, replaced, or removed reaches WebShield shortly after, and so does a domain that is added, removed, or renamed, or a new hostname. Every night the whole set is refreshed.

A certificate that also names a domain of another account, or of the server itself, is left out of WebShield. The nightly and the manual refresh report it as a warning that names the site and the names at fault, and a single certificate change records it in the panel log. That site is served WebShield's default certificate until its certificate is replaced.

To refresh WebShield by hand, for example after replacing certificate files outside the panel, run bolt-cli imunify360-webshield-sync or call POST /api/admin/imunify360/webshield/sync with an administrator API key. Both answer with what was added and skipped.

What it provides ​

  • WAF, malware scanning and cleanup, brute-force protection, and reputation management (the Imunify360 engine).
  • An admin view in the panel, at /admin/settings/imunify360, with Imunify360's own interface. When Imunify360 is not installed, the page says so and points to the Modules list.
  • A client view under Security > Imunify360 in the client panel, with Imunify360's own client interface for the signed-in account only: scanning, the account's ignore list, and clean-up.
  • Threat notifications: when Imunify360 flags files in an account, the client is told in the client panel's bell, and by email when the account has a contact email. See Threat notifications to clients.

Known limitations ​

  • Imunify360 runs as its own service; AdminBolt installs it, checks its health, and surfaces its views.
  • OpenLiteSpeed does not load ModSecurity through AdminBolt, so the Imunify360 WAF rules do not apply there.