Server security is layered: what Imunify360, CPGuard and cxs each actually cover

The question people ask when they start buying server security is almost always the wrong one: "Imunify360 or CPGuard?" The useful question is different — which layer on my server is currently uncovered?

An attack does not come through one door. It arrives as packets, becomes an HTTP request, executes as PHP, and finally lands on disk as a file that sits there quietly for months. A different technology stops each of those stages, and none of these three products covers the whole chain. Anything claiming otherwise is a product page talking, not an engineer.

The layers an attack moves through

• Network. Packet filtering, closed ports, brute-force lockouts, country or ASN blocks. nftables/iptables, CSF with lfd, or a suite's own firewall module.
• Request (WAF). Inspecting the request before PHP ever sees it: injection payloads, upload attempts, known exploit signatures. The engine is usually ModSecurity — the real difference between products is the ruleset and the reputation feed behind it, not the engine.
• Runtime. What happens once code that got past the filters actually executes: a base64 blob handed to eval, a system() call, an account trying to read outside its own home.
• Filesystem. The shell already written to disk, the injected first line of wp-config.php, the redirect buried in .htaccess. Scanning, quarantine, integrity checks.
• Patching. Kernel and library CVEs. Four flawless layers sitting on a kernel that has not been patched in months are decoration.
• Recovery. Backups. Not a security product, but unquestionably a security layer — it is what you reach for when cleanup does not work.

Now place the three products on that list.

What Imunify360 covers

This is the broadest single-product option. It ships its own firewall fed by a central IP reputation database (greylisted visitors get a captcha instead of a hard block), its own WAF ruleset running on ModSecurity, and a malware scanner. The piece the other two have no direct equivalent for is Proactive Defense: a PHP extension that judges code by what it does at execution time rather than by a signature on disk. That is the layer that stops a shell written yesterday, one that appears in no signature database anywhere.

So on its own Imunify360 touches network, request, runtime and filesystem. What it does not touch: patching and backups.

The honest downsides:

• It costs resources. A full /home scan is felt on a RAM-constrained box. You can throttle scan intensity, but then scans take longer — you do not get both.
• It produces false positives. Obfuscated but legitimate plugins and commercial themes with license checks are the usual suspects. Turn automatic cleanup on from day one and you will break a working site yourself.
• Watching the license is on you. After a move to a new IP, or once the term ends, the agent stops pulling signature updates. Check the license state after any migration.

Where CPGuard sits

CPGuard aims at the same core layers: firewall management, ModSecurity rule management, brute-force protection, malware scanning and CMS vulnerability scanning. Besides cPanel it is used on panels such as DirectAdmin and CyberPanel — confirm support for your own panel and version before you install.

In practice it diverges in two places. First, footprint: it aims at a lighter agent. Treat that as something to measure, not a claim to accept — run top and iotop for a week on your own box and let your workload answer. Second, scope: there is no layer that hooks into PHP at execution time. A brand-new, signature-less shell gets caught on the next scan, not at the moment it runs.

On RAM-constrained VPS boxes and moderately loaded servers that is a reasonable trade. On a shared server hosting several hundred WordPress installs, the missing runtime layer is felt more often.

cxs: one layer, done properly

cxs is a different tool entirely. It is not a firewall, it is not a WAF, and its interface is barely worth mentioning. It does exactly one job — the filesystem layer — and it does that job very well.

Two scan modes plus a web-server hook. First, on demand, the thing you put in cron:

cxs --user customer --quarantine /home/quarantine

Which tests run is decided by the --options letters. Those letters vary by version — rather than copying an example line off the internet, read cxs --help on your own server.

Second, real-time watching: cxswatch uses inotify on /home, /tmp and upload directories and scans files the moment they are written. This is the layer that catches a shell delivered over FTP or SFTP — when malware on a customer's own laptop steals their FTP password and drops a file, no WAF sees it, but the watcher does.

Third, and in practice the most valuable, the ModSecurity integration: it scans files uploaded over the web before they are moved into place, so the shell arriving through a vulnerable plugin's upload endpoint stops right there. On shared hosting, most real incidents start on one of those two paths.

Its blind spots:

• It never touches the network layer, and at the request layer it only inspects the uploaded file — it is not a WAF ruleset. Someone who installs cxs and calls the server secure has swept the room and left the door open.
• Before enabling watch mode, check sysctl fs.inotify.max_user_watches. On a server with hundreds of accounts the default may not be enough; once the limit is hit some directories go unwatched, and you only find out by reading the log.
• Reports need a human. Unattended quarantine will happily carry off a legitimate file.

Layer by layer, who covers what

• Network: Imunify360 yes · CPGuard yes · cxs no
• Request (WAF): Imunify360 yes · CPGuard yes · cxs only scans the uploaded file
• Runtime: Imunify360 yes · CPGuard no · cxs no
• Filesystem: all three — with cxs adding real-time and upload-time coverage
• Patching: none of them
• Recovery: none of them

Do you need all three? No

The clear answer first: do not run Imunify360 and CPGuard on the same server. They cover most of the same layers and collide in exactly the same places. Two agents both loading ModSecurity rulesets means the same rule ID is defined twice, ModSecurity throws a configuration error and Apache will not come up; two agents both managing firewall chains means that within a month you cannot tell which rule belongs to whom.

The combinations that make sense:

• One suite + backups + patching. Right for most servers. Pick a suite, then add restore and kernel patching under it.
• Suite + cxs on demand. If the suite already does real-time scanning, use cxs as an hourly cron scan and for the ModSecurity upload hook. Enable cxswatch on top and the same file gets scanned twice by two agents, burning disk I/O for nothing.
• cxs + CSF only. On a server that hosts your own projects with no customer uploads, more than this may be unnecessary.

Install order — and why it is not arbitrary

• 1. Fix the base first. SSH key auth, no password login for root, packages current. Nothing installed above matters on a box whose root password has leaked.
• 2. Backups before scanners. Security agents quarantine and clean files; when the first false positive lands you need somewhere to roll back to. Do not install and forget — actually perform one restore.
• 3. Patching. A reboot-free kernel patching layer removes the "we'll do it in the next maintenance window" excuse. A deferred patch is just an open hole with a date on it.
• 4. Isolation. Account isolation such as CageFS on shared servers. Do this before the scanner: isolation is what keeps one compromised account from becoming a compromised server.
• 5. The suite. Installation is a single command on the server — a deploy script like bash i360deploy.sh finds the license from the server's IP, with no key to paste. The moment it is up, do two things: whitelist your own admin IP (csf -a 1.2.3.4 if you run CSF, otherwise the agent's own whitelist screen), and if CSF is in use, make sure /etc/csf/csf.conf no longer says TESTING = 1 — in testing mode a cron job flushes the rules on a schedule and lfd never starts, so you believe you are protected when you are not.
• 6. Report-only for the first week. Leave the malware action on report rather than clean, and let the WAF log. Collect a week of false positives, add the real exceptions, then tighten. Do it the other way round and day one is spent answering tickets.
• 7. cxs last. On demand first, read the report, build the ignore list, then switch on watching.

When the WAF blocks a real customer

It will happen — usually as "I can't save my post". The rule ID that produced the 403 is in the ModSecurity audit log, by default /var/log/apache2/modsec_audit.log on cPanel with EasyApache 4, and in the hits list of WHM's ModSecurity tools. Disable that specific ID for that specific domain. The instinct to switch the whole ruleset off for the account, because it is faster, is how servers end up nominally protected and actually naked.

What none of them fix

• A weak WordPress admin password. Brute-force attempts may hit the firewall, but if the password has leaked the attacker logs in once, as a valid user. No layer flags it, because technically it is not an attack.
• An unpatched plugin. The vulnerability lives in the customer's site. You catch the shell afterwards, not the entry.
• A nulled theme. The customer installed the malicious code themselves, deliberately.
• Volumetric DDoS. A host-based firewall only sees traffic that has already arrived. That layer is solved upstream, on the network side.
• Data exfiltration. If a table is leaving through a query that looks legitimate, no signature engine will notice.

Layered security does not mean stopping everything. It means knowing which risk is handled where, and being able to say honestly which one is still open.

One practical licensing note

All three are licensed in the panel to the server's IP address rather than to a key file. In day-to-day terms: move the server to a new IP and the agent goes unlicensed, usually without any noise — it simply stops pulling signature updates. Updating the IP should be the first task after a migration. You change it yourself in the panel, the old address stops immediately, and the new one is typically live within a minute.

Imunify360, CPGuard and cxs are managed from the same place and sit side by side on the server security licenses page. If you want to close the patching layer too, KernelCare is added from the same panel.