Security & Maintenance

The security posture, the malware dashboard, backups and why the panel doesn’t list them, and the day-2 maintenance surfaces — all through the Plesk API and the file-service daemon, never SSH.

1. The management-plane posture

The Plesk API is the management plane: REST v2, the CLI-gateway and XML-RPC, all with the per-server API key. ImpulsePlesk never connects to a Plesk 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 operation.

The one inbound component on the box is the file-service daemon: a small TLS, bearer-auth service that operates as the subscription’s own system user (setuid privsep in a root helper) for file operations, and runs the root-only backup list, restore and export tooling. It exists only because file access and the Plesk backup list tool sit outside the REST CLI gateway.

Audit everywhere

Every provisioning and client-area action is written to the module’s audit log and Core’s audit trail with secrets redacted. Customer-facing errors are always brand-neutral; the raw Plesk error is kept operator-side.

2. Malware protection (Imunify360)

Under Operations → Malware, the Malware Protection panel is a per-server Imunify360 dashboard: protection status plus Malware, Firewall, Proactive, Reputation and KernelCare tiles, recent incidents, and write-actions (firewall add/remove, scan now, scan path) routed through an audited command queue.

Installing the engine is operator-driven

Install Imunify from Plesk → Extensions on the box — there is no “install engine” button in the module. The panel surfaces and drives an engine that’s already present.

Imunify telemetry is not reachable over the Plesk API, so a small read-only, outbound-only reporter runs on the box (root cron, every 5 min) and POSTs telemetry authenticated with an X-Impulse-Token header. Turn it on with Enable reporter on the server’s Malware panel, which shows a one-line installer to run on the box as root. It has no inbound port, and its only changes are the ones you queue from the panel — scans and firewall-list changes, picked up on its next run.

3. Plesk itself in the CVE surface

Plesk is tracked as a managed-externally upstream in ImpulseCore’s security / CVE surface. The module’s security collector reports the running Plesk version to Core; the operator applies Plesk updates. This keeps the running version visible in Core’s posture without the module trying to patch a panel it doesn’t own.

4. Backups & Backup Manager visibility

Backups are created through the CLI-gateway; listing, restore and download run through the file-service daemon, because Plesk’s backup list tool is not gateway-reachable. The module lists, restores and downloads them itself:

• Create — Back up now queues the job, and the backup_runner cron (every 2 min) runs pleskbackup --domains-name <domain> through the CLI-gateway with mapped option flags (exclude mail/files/databases/logs, incremental, description).
• List — pmm-ras --get-dump-list, filtered to the subscription domain, exposing tenant-safe fields only. (Note: pleskbackup --list does not exist.)
• Restore — pleskrestore --restore <dump> -level domains -filter list:<domain> -async; the blast radius is the one domain, and status is polled.
• Download — pmm-ras --export-dump-as-file, single-domain dumps only (export has no per-domain filter, so a server-wide dump would package every co-tenant’s data).

Why the panel looks empty

Admin/CLI-created dumps are owner-type="server", so Plesk’s customer Backup Manager does not list them. The dumps are real — just invisible in the panel. That’s exactly why the module surfaces them itself.

Passwords survive a restore

A restore re-applies the account’s stored credentials, so Plesk resets the system/FTP password. The module re-asserts the Core-stored password afterward, so the customer’s login keeps working.

5. Monitoring & health crons

These scheduled tasks, all dispatched by ImpulseCore’s cron runner, keep servers and services healthy:

• health_version_poll — every 15 min: server liveness (GET /server) and the Plesk version.
• file_service_poll — every 2 min: the file-service version on servers with an update running or a daemon not yet reporting.
• usage_sync — hourly: disk and bandwidth usage into WHMCS (for its usage billing) and usage history.
• alert_detection — hourly: raises alerts on threshold conditions.
• dns_pointing_check — hourly: checks whether each customer’s domain is delegated to the operator’s nameservers.

Set the expected nameservers globally under Settings → General & Access → DNS pointing, or override per-server. Customers whose domain isn’t delegated see a “your domain isn’t pointing to us yet” notice with the values and a re-check button. Leave the nameservers blank to turn the check off.

6. Maintenance & lifecycle

Day-2 maintenance lives under Dashboard → Maintenance. Repair account relations adopts any active service that’s missing its Plesk subscription (link-by-domain) and reports orphaned subscription rows.

Terminate is a non-destructive fence: the subscription is disabled and marked for purge, and only deleted at the day-7 hard purge run by Core’s lifecycle cron, which also clears the stored secrets. Suspend sets the Plesk subscription to disabled; unsuspend enables it again.

Update ImpulseCore before a release that needs it

ImpulsePlesk needs ImpulseCore 1.61.19 or later, and a later release may need a newer one. Update ImpulseCore first, then upload the module. If you upload a release that needs a newer ImpulseCore, ImpulseCore holds it back: its Modules and Overview tabs show an Update ImpulseCore notice naming the version needed, and the release’s new cron tasks and hooks aren’t installed. Updating ImpulseCore then finishes the upgrade — you don’t need to reactivate ImpulsePlesk.