Bobcares.com provides outsourced hosting support to web hosts. Part of our services involve hardening critical web hosting apps such as WHMCS to prevent hacking, malware infection and vulnerability exploits.

Over the past 10 years we’ve seen several WHMCS exploits that steal sensitive customer data, redirect payment accounts, and more. Today, we’ll go through the top 7 security practices that helped us secure WHMCS against all these attacks in our customer servers.

1. Prevent exploits by lightning fast security patching

Security researchers constantly find vulnerabilities in every popular software. WHMCS is no exception. So, we monitor security channels round the clock, so that we immediately become aware of a new WHMCS vulnerability or exploit.

When a new vulnerability is found, we patch WHMCS within a few minutes by:

• Applying the official patch (if available), or
• Using a web server work-around (eg. mod_sec rule) that blocks the execution of the vulnerability.

The key here is speed. Most mass exploits happen via automated means. It’ll take botnet masters a few hours to build a deploy a mass exploit solution. So, we make it a point to update our customer’s severs within that time, so that exploits will fail.

2. Block attacks by using a web application firewall (WAF)

WHMCS exploits usually employ common attack methods such as SQL injection, Remote File Inclusion, etc.

It is possible to detect and block an attack by checking if a site visit matches any of the common attack behaviors. For this, we use Web Application Firewalls (or WAFs) such as mod_security, NAXSI, etc. We use it to:

• Block common attack methods like directory traversal, remote file inclusion, and more.
• Write custom rules that block HTTP requests that try to exploit a vulnerable function.

To be effective, the WAF database should be constantly updated with the latest attack signatures from Comodo, OWASP, etc.. However, some of these signatures could block legitimate users. So, we periodically review new rules from these channels, test them for proper functioning, and update the rules database.

See how we help web hosting companies

3. Defuse exploits by changing default WHMCS settings

Almost all WHMCS attacks are automated, where hackers use a central attack server to send exploits to thousands of WHMCS sites simultaneously.

These attacks assume the default WHMCS settings to run their exploits.

So, an easy solution we use is to change all critical default settings in WHMCS. Some of these are:

• Change the name of the admin directory from “admin” to something else.
• Limit the database user’s pemissions to DELETE, INSERT, SELECT, UPDATE and LOCK TABLES.
• Limit the IPs that can access admin area to only staff IPs.
• Write protect the configuration file, and move it a location outside public_html.
• Move attachment, downloads and templates directories to outside public_html.
• Auto-scan new file uploads for malware using anti-virus such as ClamScan, LMD, etc.

4. Limit bugs by periodically removing un-used add-ons

A common source of vulnerabilities are 3rd party addons and payment gateway modules.

It is common for business owners to try out new features, and leave the addons without updates. This is an easy access point for hackers.

We prevent this issue by periodically scanning the whole WHMCS installation, and removing any and all files, directories and add-ons that are not essential for WHMCS to function.

We also recommend to use a non-public development server to test new functionalities so that un-used add-ons never reach the live server.

[ You don’t have to lose your sleep to keep your customers happy. Our friendly Hosting Support Specialists are online 24/7/365 to help your customers. ]

5. Reduce hack risk by web server hardening

Many exploits rely on non-standard PHP functions and availability of common server commands.

So, we lock down the web server so tight that most exploits will just refuse to execute. Some of these steps are:

• Disabling dangerous PHP functions.
• Block non-standard ports.
• Force HTTPS with strong ciphers and 2048 bit certificates.
• Disable lax permissions (eg. 777) in web-accessible directories.
• Prevent common PHP hacks using security patches such as Suhosin.
• Hide PHP and server versions, and disable PHPInfo function so that hackers cant run tests.
• Block connections from infected computers using blocklists such as SpamHaus XBL.
• Disable script execution in uploads directory.

We review these settings periodically to make sure they are performing as expected, and to make sure it’s up-to-date with the latest hardening techniques.

6. Intercept hack attempts through 24/7 security monitoring

Even despite all these precautions, it is possible that someone might get through the defenses. Which is why we monitor the WHMCS installation round the clock for anomalous events.

We monitor several server parameters to detect a possible intrusion. Some of these are:

• Network traffic,
• File system changes (eg. file uploads)
• Non-standard execution (eg. if a process is created by an unknown script)
• Privileged file access (eg. if someone tries to access /etc/passwd)

At the slightest hint of a trouble, we quickly get into the server, investigate the event, and if it’s indeed an attack, we mount additional defenses quickly so that WHMCS remains secure.

7. Backup verification and securing

At this point, we’ve covered several layers of redundant security practices. If one fails, another layer would block an attack.

Now, what if everything fails, and an attack happens? *knock wood*

We take precautions for that eventuality too. That is why we take backups of database and WHMCS web root at least once every day.

Then we periodically conduct back-up restore drills to make sure:

• The backups are indeed working (that is the database, etc. is not corrupted).
• That we can restore the backups within a few minutes.

We store the backups in a secure off-site location that’s removed from the WHMCS network, so that the infected server cannot access it automatically.

This ensures that the backups are always reliable, and even if we’re struck down, we can be back online in no time.