Security hardening for ImpulseVPS

ImpulseVPS manages servers only through each provider's API. Your customers hold root, so the module stays out of the server itself. Your part of hardening covers the provider tokens, admin access, and keeping WHMCS, PHP and ionCube current.

Scope each provider token

Give each provider account a token with only the access ImpulseVPS needs:

• Vultr: a Personal Access Token from Account → API. It has full access, so under Account → API → Access Control, allow your WHMCS server's IP. Vultr rejects calls from any address not on that list.
• Hetzner Cloud: a Read & Write token from your project → Security → API Tokens. A token reaches only its own project, so connect one account per project.
• DigitalOcean: a Full Access (read and write) token from API → Tokens, with no expiry or a long one.
• Linode (Akamai): a Personal Access Token from Profile → API Tokens. Set Linodes, Volumes, StackScripts, IPs and Firewalls to Read/Write. Account Read Only is optional. Linode can't add scopes to an existing token, so a missing scope means a new token.

Test connection only reads, so a token missing write access still passes it. After you create or narrow a token, run the Synthetic end-to-end test under Diagnostics → Health Checks. It creates one billable server and then destroys it, even after a timeout or an error. If the destroy fails, or the provider's answer to the create is lost, you get a critical alert, because the server may still be billing. Then try firewall, snapshot and backup changes on a test order.

Where the tokens live

ImpulseCore stores the tokens under ImpulseCore → Operations → VPS Providers, encrypted at rest. After you save a token, the form shows only a mask. Other Impulse modules you run share these accounts.

Rotate a token in place: create a new one with the same access in the same provider account (on Hetzner Cloud, the same project), paste it over the masked value in ImpulseCore → Operations → VPS Providers and save it (Save for the default account, Save profile for a named one), click Test connection on the account in Addons → ImpulseVPS → Settings → Providers & Regions, then revoke the old token at the provider. Each server stays on the account it was created on, so rotating a token doesn't disturb running servers. For the full steps, see Adding a provider account to ImpulseVPS.

If a provider refuses an account's API key, the 15-minute provider check raises a critical alert on the Dashboard.

Nothing runs on the customer's server

• No way in from WHMCS. ImpulseVPS installs no agent or admin proxy on the server and never connects to it over SSH, not even in an emergency. Recovery uses the provider's API: power, the console where offered, a firewall reset, a reinstall or a snapshot.
• Nothing secret at first boot. First-boot user-data carries only the hostname, the customer's SSH keys, SSH hardening and the customer's optional startup script. It never carries a password. A payload containing private-key material is refused, and only cloud-init images can be offered.
• SSH hardening. When the server is created or reinstalled with an SSH key, its first-boot setup turns password login off. The key can be the customer's own or one the module generated. A key the customer adds to the server later doesn't turn password login off. When an order has no key and the server gets a one-time root password, password login stays as the image sets it, so that password still works.

One-time credentials

Without an SSH key, the customer gets a one-time credential. On Vultr, Hetzner Cloud and Linode, it's the server's one-time root password, set when the server is created. On DigitalOcean, it's a key pair the module generates. ImpulseCore stores the credential encrypted. The client area's Access tab shows it once, and then it's deleted. It is never emailed.

• Revealing it. The customer confirms the reveal and re-enters their account password, unless they did so in the last few minutes. Nothing is shown while the service is suspended or scheduled for deletion.
• Admins are refused. An administrator signed in to the client area as the customer can't reveal the credential, because revealing it would use it up. The refusal is audited.
• If it's lost or leaked. There is no root password reset. The customer can reinstall with a new SSH key, which erases the disk. On DigitalOcean a reinstall keeps the server's original keys, so that customer needs your help.
• On purge. The purge deletes the credential along with the server.

Firewall defaults and the reset

A new server starts with every port open. Customers restrict it on the Firewall tab, where Apply replaces the whole rule set. If a rule set would cut off SSH from the customer's own address, they're warned and must type their hostname to apply it.

Reset firewall to open replaces a customer's rules with every TCP and UDP port, plus ping, over IPv4 and IPv6. Other IP protocols stay blocked. Use it to recover a locked-out customer, not for enforcement. To stop an abusive server, suspend its service.

Destructive actions ask first

• Plain confirmation: Power off, Reboot VPS, Reset firewall to open and Resolve unknown create.
• Server's name typed in: Reinstall OS and Force purge. The name is checked again before anything runs.
• Instance ID typed in: Destroy instance in the orphan report on the Instances tab.

To control which admin roles can use the addon at all, open System Settings → Addon Modules, click Configure on ImpulseVPS and set Access Control.

Audit entries and request IDs

• Server actions carry a request ID, whether the customer, you or the scheduler ran them. Each one is checked against the service's own server and recorded under Diagnostics → Activity, where you can filter by service number, event or level.
• Admin actions in the addon are logged under ImpulseCore → Operations → Audit with your admin ID and a request ID.
• Customer references in a customer's Recent activity are the first eight characters of the request ID.
• No secrets in logs. Credential events record the key's name, never its value, and the support snapshot under Diagnostics → Help masks secrets.

Keep WHMCS, PHP and ionCube current

ImpulseVPS 1.0.0 needs WHMCS 9.0 or later, PHP 8.2, 8.3 or 8.4, ionCube Loader 13 or later for that PHP version, and ImpulseCore 1.61.19 or later. Apply security updates within those versions, and enable ionCube for a new PHP version before WHMCS switches to it.

When a release needs a newer ImpulseCore, upgrade ImpulseCore first and open Addons → ImpulseCore once. Then upload the new ImpulseVPS release over the existing folders. Upgrades never touch existing servers.

If you add web server hardening rules, keep serving the console files under modules/servers/impulsevps/console/novnc/. A rule that blocks paths containing /vendor/ stops the browser console from loading on Hetzner Cloud servers, which use these files.

Related

• Installing ImpulseVPS — step-by-step
• Adding a provider account to ImpulseVPS
• How to monitor your ImpulseVPS fleet