Securing a WHMCS install: the checklist we actually run

Internetivo has run its client billing on WHMCS for years, and the Internetivo platform itself is built as a WHMCS add-on. That means our own business sits on the same software many hosting companies use every day. Over time we have built up a checklist that we come back to whenever we set up or review an install.

None of this is secret, and most of it is not new. WHMCS publishes its own security guidance, and the first section below follows it. The value is in doing all of it, and in checking it again later, because a secure setup slowly drifts if nobody looks.

Start with what WHMCS itself recommends

The official WHMCS documentation has a page on enhancing security. If you do nothing else, do these:

• Move the writeable directories (attachments, downloads and the template cache) outside the web root, so they cannot be reached from a browser.
• Lock down configuration.php with file permissions that stop it being overwritten or edited by accident.
• Move the crons directory above the web root.
• Rename the admin directory, so the login page is not sitting at the address every scanner tries first.
• Restrict the admin area by IP address if your staff work from fixed addresses.
• Use SSL everywhere, for the client area and the admin area alike.
• Give the database user only the privileges WHMCS needs, not full control of the server.
• Block web requests to the vendor directory. Apache's bundled .htaccess does this, but on nginx you have to add the rule yourself.
• Send a Content Security Policy frame-ancestors header so your pages cannot be framed by another site for clickjacking.
• Stop people registering with your own company's email domain, which makes it harder for someone to pose as staff.

That list is the foundation. The rest of this article is what we add on top.

The PHP and web server layer

Most real-world problems we have seen start below WHMCS, in how the server runs PHP.

• One system user per site. Each site runs as its own user, and its files belong to that user. If one site is compromised, the damage stops at its own folder.
• open_basedir per site. PHP can only read and write inside the site's own directories and a private temporary folder. This one setting quietly blocks a whole class of attacks that try to read files from elsewhere on the server.
• Sensible PHP-FPM limits. Set a request timeout and a cap on worker processes for each pool. A slow script or a flood of requests should hit a limit and fail cleanly, not take the whole server with it.
• No world-writable files. If something needs to be writeable, make it writeable by the site user only, and keep it out of the web root where you can.
• Keep PHP on a supported version. WHMCS lists which PHP versions each release supports. Running a PHP version that no longer receives security fixes undoes much of the work above.

Cron and privileges

The WHMCS cron runs often and touches everything: invoices, emails, domain syncs. It deserves care.

• Run the cron as the site user, never as root. If a script the cron loads is ever changed by an attacker, it should only be able to do what the site itself can do.
• Keep custom scheduled jobs separate. If you add your own automation, give each job its own clear owner and permissions rather than piling everything into one root crontab.
• Watch that it actually ran. A cron that silently stops is a security problem as well as a billing one: overdue suspensions, missed reminders and unrotated logs all follow. A simple alert when the last run is too old pays for itself.

Email that people can trust

Your WHMCS install sends invoices, password resets and payment reminders. Those are exactly the emails criminals like to imitate.

• Publish SPF and sign outgoing mail with DKIM for the domain WHMCS sends from.
• Add a DMARC record, start by monitoring the reports, and move to a stricter policy once you are sure every legitimate sender passes.
• Use a dedicated sending address for system mail, so replies and bounces are easy to watch.
• Protect the forms that send mail. A captcha on login, registration and password reset stops automated abuse of the pages that can trigger an email or test a stolen password.

Done properly, this means your clients' mail providers can tell your real invoice from a fake one.

Keep watching after the setup

Security is not a one-off task. These are the habits that keep a good setup good:

• Turn on two-factor sign-in for every staff account, and remove accounts for people who have left.
• Follow the WHMCS security announcements and apply security releases promptly. Check your version's end-of-life date, and plan the upgrade before it arrives, not after.
• Compare what is running with what you think is running. If you deploy from a repository, check now and then that the files on the live server match it. Servers drift: a quick fix made directly on the box, or a file copied to the wrong place, is easy to forget. We compare checksums of key files for exactly this reason, and it has caught real differences for us.
• Keep add-ons to the ones you use. Every module you install is code that runs with access to your billing data. Deactivate and remove what you no longer need.
• Back up, and test the restore. A backup you have never restored is a hope, not a plan.

If you run WHMCS for your own hosting business, we hope this saves you some time. If you would rather have someone go through your setup with you, a security check is one of the services you can post as a task on Internetivo.