Imunify360 agent CLI: the commands every host actually uses

The Imunify360 control panel UI exposes maybe 60% of what the product can do. The other 40% — bulk operations, scriptable actions, the diagnostics that support will ask for before anything else — lives in the imunify360-agent CLI. This is the reference an on-call admin should keep open in a second terminal.

Everything below is run as root on the cPanel, Plesk, or DirectAdmin node where Imunify360 is installed. The binary is /usr/bin/imunify360-agent and is always in $PATH after a healthy install. If imunify360-agent is not found, the agent package itself failed to install — start with installing Imunify360 on cPanel before reading further.

Health and version

The first three commands to run on any unfamiliar server, in this order:

imunify360-agent version
imunify360-agent rstatus
imunify360-agent doctor

version prints the agent version, the database version, and the protected-resources count. A drift between agent and database version (common after a partial update) is the cause of half of all "the UI is blank" tickets.

rstatus (short for report-status) is the real health check — it hits the licence server, the malware DB, the WAF rules feed, and the cloud IP-reputation service, and reports which are reachable. Look for OK on every line. A timeout to imunify-lic.cloudlinux.com means an outbound firewall is blocking the licence callback; see fixing Imunify360 licence errors for the firewall ports.

doctor runs a self-test across config files, kernel modules, the database, and the file system layout. Add --fix to let it repair what it safely can — broken symlinks, missing config defaults, orphaned RPM scripts:

imunify360-agent doctor --fix

doctor --fix is safe to run on production; it will not touch IP lists, settings, or quarantine state.

Licence and registration

imunify360-agent register IM-XXXX-XXXX-XXXX-XXXX     # attach a key
imunify360-agent unregister                          # detach the licence
imunify360-agent rstatus                             # confirm the licence is live

After a panel migration where the IP changed, the licence almost always needs unregister + register against the new IP. The IP must already be on file with the licence — see moving an Imunify360 licence to a new IP for the activation flow on our side.

Malware scans

The on-demand scanner is the workhorse. Three patterns cover almost every ticket:

# Scan one account's docroot
imunify360-agent malware on-demand start --path /home/jdoe/public_html

# Scan everything under /home, recursively
imunify360-agent malware on-demand start --path /home

# Check what is currently running
imunify360-agent malware on-demand list

The output of list shows scan IDs. To stop a runaway scan that is hammering disk IO:

imunify360-agent malware on-demand stop --id <scan-id>

Reviewing detections:

# All malicious files currently detected, JSON
imunify360-agent malware malicious list --json

# All cleaned files in the last 7 days
imunify360-agent malware cleanup history --days 7

Acting on detections:

# Clean a single file (auto-quarantine the original)
imunify360-agent malware cleanup --id <file-id>

# Restore a file from quarantine after a false positive
imunify360-agent malware restore --id <file-id>

IP lists — block, allow, graylist

The three lists are independent. Add the same IP to white and black and the white list wins.

# Block an IP forever
imunify360-agent ip-list local add --ip 203.0.113.45 --purpose black --comment "SSH brute force"

# Allow an IP forever (overrides every block, every WAF rule, every cloud feed)
imunify360-agent ip-list local add --ip 198.51.100.10 --purpose white --comment "office VPN"

# List the current local entries
imunify360-agent ip-list local list --purpose black
imunify360-agent ip-list local list --purpose white

# Remove an entry
imunify360-agent ip-list local delete --ip 203.0.113.45 --purpose black

CIDR ranges work the same way — pass --ip 203.0.113.0/24.

To see whether an IP is being blocked and why (cloud feed, local rule, brute-force trigger, WAF), use:

imunify360-agent ip-list status --ip 203.0.113.45

This returns the full decision tree, including which list matched and which rule ID was responsible. It is the single most useful command when a customer says "you blocked my office" — the answer is almost never what the customer expects.

For the captcha graylist (WebShield), see how WebShield captcha and graylist work — it has its own subcommand tree under imunify360-agent webshield.

False-positive submission

Submitting a sample to the CloudLinux signature team is how you get a global signature fixed for everyone, instead of carrying a local whitelist forever:

# WAF false positive — submit the rule ID and request URL
imunify360-agent submit-false-positive --rule-id 77316801 --url "https://example.com/wp-admin/admin-ajax.php"

# Malware false positive — submit the quarantined file
imunify360-agent submit-false-positive --file /var/imunify360/files/HEX-<hash>

Full walkthrough with response timelines in submit Imunify360 false positives. The CLI route is faster than the UI form because it attaches the full request body and the original file hash automatically.

ProactiveDefense

The PHP runtime sandbox has its own subcommand tree. The two you will use:

# Show current mode (DISABLED, LOG, KILL)
imunify360-agent features status

# List killed/logged events
imunify360-agent pdef list --days 1

# Whitelist a script that is fingerprinting as malware
imunify360-agent pdef rule add --type allow --path /home/user/public_html/wp-content/plugins/somecache/loader.php

The mode itself is set in the main config or via the UI, not via the CLI — see configuring ProactiveDefense for the audit-then-promote workflow.

Settings — show, update, restore

The full live config:

imunify360-agent config show

Update a single key:

imunify360-agent config update '{"MOD_SEC_BLOCK_BY_CUSTOM_RULE": {"enable": true}}'

Config keys are namespaced under their feature — MALWARE_SCANNING, WAF, PROACTIVE_DEFENSE, WEBSHIELD. The JSON syntax is fussy; one mistake and the whole call no-ops without an error. Verify with config show after every update.

To reset every setting to the install default:

imunify360-agent config reset

This wipes custom rules too. Back up /etc/sysconfig/imunify360/imunify360.config first.

Diagnostics for support tickets

When CloudLinux support asks for a diagnostic bundle:

imunify360-agent doctor --bundle

This drops a tarball in /var/log/imunify360/bundle-<timestamp>.tar.gz containing every relevant log, the config, the database schema version, and the last 200 events. Upload this with the ticket instead of pasting log snippets — support will ask for it anyway.

Live tailing the four logs that actually matter:

tail -f /var/log/imunify360/console.log         # agent activity
tail -f /var/log/imunify360/error.log           # errors and stack traces
tail -f /var/log/imunify360/proactive_defense.log
tail -f /var/log/imunify360-webshield/error.log

The malware scanner has its own log under /var/log/imunify360/malware-scan.log — only useful when a scheduled scan is hanging.

Next steps

• Configure ProactiveDefense kill-mode promotion once you can read the pdef logs.
• Set up WebShield captcha graylisting for bot mitigation without the false-positive rate of pure blocking.
• If you need to coexist with another firewall, see Imunify360 alongside CSF and ModSecurity.