A VirtFusion control server holds the keys to every VPS you host, so VirtFusion security hardening is not optional. This checklist covers the control server, the hypervisors, admin accounts and the API.
Before you start
- Root access to the control server and every hypervisor, plus console or IPMI access.
- A list of IPs your staff and WHMCS connect from.
- A maintenance window for changes that may restart services.
Secure SSH everywhere
- Use SSH keys and disable password login in
/etc/ssh/sshd_config:PasswordAuthentication no. - Allow root login only with keys (
PermitRootLogin prohibit-password) or use a sudo user. - Restrict SSH to staff IPs or a VPN with the firewall.
- Install fail2ban to block brute-force attempts.
More detail: SSH lockdown checklist.
Firewall the control server
- Allow HTTPS (443) for customers and admins, and HTTP (80) only if needed for certificate renewal.
- Allow SSH only from trusted IPs.
- Allow only the ports VirtFusion documents for control server ↔ hypervisor traffic, and only between those hosts.
- Deny everything else inbound.
Firewall the hypervisors
- Hypervisor management ports should accept connections only from the control server and staff IPs.
- Be careful: rules on the host must not filter customer VPS traffic on the bridge unless you intend it.
- Keep IPMI on a private network or VPN, never open to the internet.
Warning: Test firewall changes from the console. A wrong rule on a hypervisor can cut both your SSH and every customer's network.
Protect accounts and the API
- Enforce two-factor authentication for all admins (manage users and 2FA).
- Use one API token per integration and revoke unused ones (API tokens).
- Serve the panel only over HTTPS with a valid certificate.
Patch and monitor
- Apply OS security updates weekly and VirtFusion updates soon after release.
- Enable unattended security updates on the control server if your change policy allows.
- Watch auth logs (
journalctl -u ssh) and VirtFusion admin activity for unexpected logins. - Keep offsite backups of the control server database.
Troubleshooting
- Locked out after disabling passwords: log in through the console and add your public key to
~/.ssh/authorized_keys. - Hypervisor shows offline after firewall change: allow the control server IP on the required ports.
Frequently asked questions
Should the panel be on a separate network from hypervisors?
A private network between them is ideal; at minimum, firewall management ports to each other's IPs.
Is changing the SSH port enough?
No. It reduces noise but keys, IP restrictions and fail2ban do the real work.
How do I spot a leaked API token?
Watch for API actions you did not make and rotate tokens on any suspicion.