Skip to main content
ImpulseMinio

Security hardening for ImpulseObjects

What the module hardens for you out of the box, and what you still own as the operator — firewall, TLS, admin proxy auth, key rotation, and how the Security & Maintenance pipeline fits in.

Last updated 20 days ago

Security hardening for ImpulseObjects

The module handles a lot of the baseline hardening for you on a provisioned RustFS storage host. Some pieces — credential rotation, network policy at your perimeter, opt-in patching for connect-existing hosts — stay your call. This article maps the boundary.

What the module does by default

On a server provisioned via Servers → Provision New Storage Server:

  • UFW with explicit IPv4 + IPv6 rules. Cloud-init writes UFW rules for both stacks. Open ports: 443 (S3 + Console via Nginx), 9099 (admin proxy, restricted to WHMCS source IPs), 22 (SSH, restricted to your configured admin source IPs).
  • TLS on the S3 endpoint. Let's Encrypt certificate issued via DNS-01 challenge on first boot. Renewed by certbot on the server's own cron.
  • Per-region admin proxy auth. The Bearer token the admin proxy listens with is generated per server, not shared globally. Compromise of one server's token does not give access to other regions. The token is stored encrypted in Core's mod_impulsecore_secrets.
  • Engine root credentials never exposed to customers. All customer-facing operations create per-tenant users via RustFS's admin API. Customers never see the root key.
  • Audit trail. Every admin action that hits a storage host writes to Core's audit log with timestamp, actor, target server, and outcome.
  • Pre-patch snapshots. The Security & Maintenance pipeline takes a Vultr / Hetzner / DigitalOcean / Linode snapshot before applying OS updates. If the patch fails, the snapshot is held for you to restore or delete; it is never restored automatically.

What you still own

These are operator decisions; the module won't make them for you.

Source-IP allowlists

The admin-proxy port (9099) is allowlisted to your WHMCS server's IPs at install time. If you change WHMCS IPs (move VPS, add a second WHMCS server) you must update the source-IP list in the addon's Settings → WHMCS Server IPs, then re-run the firewall sync on each server.

SSH access

Cloud-init disables password SSH and installs the public key you configured. Restricting source IPs for SSH is your call — the default opens 22 to the world. For production, narrow this on the cloud-provider firewall (Vultr Firewall Groups, Hetzner Firewalls, DO Cloud Firewalls, Linode Cloud Firewalls) so even before UFW you only see SSH from your jump host.

Key rotation

  • VPS provider API tokens. Rotate on the same cadence you rotate any other infrastructure secret (90 days is reasonable). Update under Settings → Providers.
  • DNS provider tokens. Same cadence as your VPS tokens.
  • Storage engine root credentials per server. Rotate by updating the RustFS root credentials on the host, restarting the storage service, then updating the credentials on the server row in the Servers tab.
  • Admin proxy Bearer tokens. Regenerated by running the admin-proxy install script with the --rotate-token flag on the box, then pasting the new token into the server row.

TLS for connect-existing servers

If you brought a RustFS host under management via Connect Existing, you own its TLS. The module doesn't issue or renew the cert on a host it didn't provision. Make sure your cert is valid, auto-renewing, and covers the hostname WHMCS knows about.

OS patching on connect-existing servers

Connect-existing servers are not in the Security & Maintenance pipeline by default. To opt in, check Manage OS patching for this server on the Connect form. Otherwise patch the host yourself — apt, kernel reboots, and storage-engine version upgrades are your responsibility.

How the Security & Maintenance pipeline helps

Once a server is in the pipeline (any provisioned server, plus opted-in connect-existing servers):

  • A daily snapshot reads apt list --upgradable and the running storage-engine version.
  • Hourly CVE correlation against Ubuntu USN, CISA KEV, and NVD by CPE for RustFS (cpe:2.3:a:rustfs:rustfs).
  • Critical (CVSS 9.0+) or KEV-listed matches auto-schedule a maintenance window at now + 24h and send a branded customer email.
  • A maintenance window opens, takes a snapshot, runs apt-get install, reboots if required, and holds the snapshot for you if anything fails.

The pipeline flags risks and auto-schedules critical patches. For non-critical work it surfaces what's pending and waits for you (or the customer's maintenance window) to authorise. It does not auto-patch outside a scheduled window unless a Critical or KEV match forces it.

ImpulseCore's security pipeline article explains the cross-module mechanics — how Collectors and Actuators register, what tables back what, and how Core orchestrates across every Impulse module.

A short operator checklist

  • WHMCS source IPs current in Settings → WHMCS Server IPs.
  • SSH narrowed at the cloud-provider firewall.
  • VPS / DNS API tokens rotated on a fixed schedule.
  • Storage engine root credentials rotated annually at minimum, on every server.
  • All servers either in the Security & Maintenance pipeline or under your manual patching regime.
  • License key valid (renewal in calendar).
  • WHMCS itself patched current — the module is only as safe as the WHMCS host it runs on.

Was this helpful?

Still need help? Ask the team