Security & Maintenance

The security posture, the Imunify360 malware dashboard, cPanel in ImpulseCore’s CVE surface, backups, the scheduled health tasks and the day-2 maintenance surfaces — all over the WHM API, never SSH.

1. The management-plane posture

The WHM API is the management plane: WHM API 1 and cPanel UAPI over TLS, with one WHM API token per server, stored encrypted and never shared between servers. ImpulseCpanel never connects to a server over SSH — there is no SSH code path and no break-glass toggle — and there is no free-form shell over the API; every change is a typed API call.

Audit everywhere

Every admin action in Addons → ImpulseCpanel is checked against WHMCS’s security token and written to ImpulseCore’s audit log as admin.<action>, with the admin, a request ID, the server, plan or service it touched, and the result. Only non-secret form fields are recorded, and API tokens and passwords are masked from the result text. Customer sign-ins to the control panel and refused client-area actions are audited too. Diagnostics → Activity shows the module’s latest 100 entries; with the Imunify reporter on, its reports fill that quickly (one entry per report, every 5 minutes per server), so look older entries up in ImpulseCore’s audit log for the module, linked from Diagnostics → Help.

Destructive admin actions ask before they run: Forget server needs the server’s hostname typed, and a one-time WHM sign-in or a forget can’t be repeated by re-sending the form.

2. Malware protection (Imunify360)

Operations → Malware is a per-server Imunify360 dashboard: one card per active server, with an Open in WHM link to Imunify360 on that server.

Installing Imunify360 is up to you

Imunify360 is a paid cPanel plugin you install from WHM → cPanel → Manage Plugins; there is no “install engine” button in the module. The WHM API has no reliable way to tell whether Imunify360 is installed (Re-check presence can’t confirm it), so the status reporter below is what confirms the agent on a server.

Imunify360’s data is only available on the server itself, so a small status reporter ships it to WHMCS. It’s outbound-only: it reads imunify360-agent (and KernelCare’s status), POSTs a report to your WHMCS System URL every 5 minutes with its own per-server token, and has no listening port and no remote shell. The only changes it makes are the scans and firewall-list changes you queue from the panel.

The reporter needs an https System URL

The install command and every report carry the server’s tokens, so they travel over https only. While System Settings → General Settings → WHMCS System URL isn’t https://, a server’s card offers no Enable reporter (or New install command) button, and a callout says why; the install endpoint refuses (HTTP 409) before spending the one-time token, and the reporter never posts over plain http. This release can’t install a reporter over http; a reporter installed by an earlier build while the System URL was http keeps reporting over http until it’s reinstalled — once the URL is https, use New install command on the server’s card to reinstall it. The certificate must be valid too — the reporter checks it, so a self-signed or expired one stops the reports.

To set it up:

1. Click Enable reporter on the server’s card. The page shows a one-line install command, once; its one-time token expires after 24 hours.

2. Run the command on the server as root:

   curl -fsSL --proto '=https' --proto-redir '=https' \
     "https://<your-whmcs>/modules/servers/impulsecpanel/imunify-bootstrap.php?id=<token-id>" \
     -H "X-Impulse-Token: <one-time-token>" | sudo bash

   It writes the reporter to /usr/local/bin/impulse-imunify-reporter, its configuration (readable by root only) to /etc/impulse/imunify-reporter.conf, and a root cron entry to /etc/cron.d/impulse-imunify-reporter, then sends the first report. WHMCS keeps only hashes of the tokens. The --proto options keep curl on https, redirects included, so the one-time token is never sent in the clear.

3. Within about 5 minutes the card shows the protection status and six tiles — Malware scanner, Firewall, Proactive defense, Reputation, KernelCare and Incidents (7d) — each opening its details.

From the card you can Scan all accounts, scan one path, and add or remove addresses on the firewall’s allow, deny and grey lists. These are queued, not run live: the reporter picks them up on its next run, within about 5 minutes, and every one is audited. A card whose last report is more than 15 minutes old shows the reporter as stale.

• If the command expires before you run it, click Enable reporter again. Once a reporter has been installed, the button reads New install command while the reporter isn’t reporting, and mints a fresh one-time command to reinstall it.

• Disable reporter rejects the server’s reports from then on (each rejected report is still audited until the reporter is gone). Show details under the result gives the command that removes the reporter from the server; the installer also created the /etc/impulse and /var/lib/impulse directories (the second holds the reporter’s queued-command results), which can go too:

  rm -f /etc/cron.d/impulse-imunify-reporter /usr/local/bin/impulse-imunify-reporter /etc/impulse/imunify-reporter.conf

3. cPanel itself in the CVE surface

cPanel is tracked as a managed externally upstream in ImpulseCore’s security and CVE surface. The module reports each server’s running cPanel & WHM version — the one Test connection and the 15-minute health task record — so Operations → Security (ImpulseCore’s tab) keeps the running version visible in Core’s security posture. You apply cPanel and operating-system updates yourself, in WHM; the module doesn’t patch a panel it doesn’t own.

4. Backups

The module doesn’t run or schedule server backups — cPanel’s own backup system does, as you configure it in WHM.

• For you: Diagnostics → Health Checks → Server backups shows each active server’s backup settings, read-only: backups on or off, the daily/weekly/monthly schedule, retention, destinations (“Local only” when there are none) and running restores. To change backups, add a destination or restore an account, use Log in to WHM in the server’s menu.
• For customers: the client area’s Backups tab generates a full backup of the account into its home directory and lists recent backups; downloading and restoring happen in the control panel, through the backup sign-in.

The Server backups panel loads live

It asks every active server for its backup settings each time Health Checks opens (three WHM calls per server, each allowed 15 seconds). With many servers, or one that doesn’t answer, the page is slow; a server that doesn’t answer shows as Unreachable.

5. Scheduled tasks

These run on ImpulseCore’s cron runner:

Task	Runs	What it does
provision	every 2 min	Retries account creation for services left pending by a failed Create, up to 25 per run, the longest-waiting first, with each service’s own plan, Region and client email. A service whose plan or Region can’t be resolved isn’t retried: it stays pending with not retried: … as its last error, audited once per reason (see Plans & WHMCS products).
usage_sync	hourly	Reads disk usage (WHM accountsummary) and bandwidth (WHM showbw) for active accounts and writes them to the WHMCS service, for WHMCS’s usage billing, and to the module’s usage history. It pages through every active account, 200 at a time, for up to about 100 seconds a run; a run that runs out of time saves its place (the usage_sync_cursor setting) and the next run carries on from there, so on a large fleet every account is still reached in turn. An account whose server doesn’t answer is skipped that run, and waiting on that server slows the run.
health_version_poll	every 15 min	Calls WHM’s version on every active server, records the cPanel & WHM version, and marks the server online and healthy or offline and down — a server takes new accounts only while its last check passed. It also applies the module’s database updates.
alert_detection	hourly	Opens an alert when a server is down (critical) or at its capacity (warning), and clears it when that’s no longer true. There’s no alert list in the admin: each change is an ImpulseCore audit entry (alert.server_down and alert.server_full, then alert.server_down.cleared or alert.server_full.cleared), which ImpulseCore’s monitoring forwards like any other audit entry to the alert destinations whose level and event filters match (alert.server_down is critical, alert.server_full a warning, the .cleared entries info).

Only the module checks its servers’ health: ImpulseCore’s general health probe leaves ImpulseCpanel’s servers alone, so the Health column is the module’s own check.

6. Maintenance & lifecycle

Dashboard → Maintenance → Repair account relations links every Active or Pending service that’s missing its cPanel account to an account with the service’s domain on any active server, and reports account records whose WHMCS service no longer exists. Like Link Existing Account, it needs a valid license, stops at a developer key’s 3 accounts, and records each service’s product Hosting Plan. A service whose product has no plan, or names one that doesn’t exist, is linked without a plan and flagged: the result says how many to review, and each one’s Last error says why — select the product’s Hosting Plan and run Change Package on it. Operations → Maintenance is ImpulseCore’s maintenance tab.

• Suspend suspends the cPanel account in WHM (its sites show cPanel’s suspended page); unsuspend reactivates it. cPanel has no read-only mode, so the account stays fully suspended during its 7-day suspension grace, with its files, databases and mail kept. If it’s still suspended when the grace ends, it’s removed the same way as a terminated account; ImpulseCore’s daily lifecycle task emails the customer a final warning once 2 days or fewer remain.
• Terminate deletes nothing: the account is suspended, marked for removal and detached from the client’s ImpulseCore project. Seven days later ImpulseCore’s purge task removes the account with WHM removeacct — its domains, files, databases and mail — frees its place on the server and records the purge. A purge never runs on a service that both WHMCS and the module still show as active.
• Restoring a service within its grace window (Cancel grace or Restore service in ImpulseCore’s Lifecycle tab) unsuspends the account and, after a terminate, attaches it to the client’s project again.

Grace windows, warning emails and the purge are ImpulseCore’s; see Lifecycle & suspension.

What a service contributes to its project

A provisioned service publishes HOSTING_URL, HOSTING_PRIMARY_DOMAIN, HOSTING_FTP_HOST, HOSTING_FTP_USER, HOSTING_DEPLOY_PATH, MYSQL_HOST and MYSQL_PORT to its ImpulseCore project’s environment. HOSTING_FTP_PASSWORD is kept as an encrypted secret — for accounts the module created, and refreshed when WHMCS changes the service’s password.