Bobcares

7 proven ways to secure WHMCS from hackers, malware and vulnerabilities

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.

BOOST YOUR HOSTING BUSINESS!

Never again lose customers to poor service! Sign Up once. Enjoy Peace Of Mind For Ever!

CLICK HERE FOR WORLD-CLASS SUPPORT SERVICES

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Speed issues driving customers away?
We’ve got your back!

Privacy Preference Center

Necessary

Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

PHPSESSID - Preserves user session state across page requests.

gdpr[consent_types] - Used to store user consents.

gdpr[allowed_cookies] - Used to store user allowed cookies.

PHPSESSID, gdpr[consent_types], gdpr[allowed_cookies]
PHPSESSID
WHMCSpKDlPzh2chML

Statistics

Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.

_ga - Preserves user session state across page requests.

_gat - Used by Google Analytics to throttle request rate

_gid - Registers a unique ID that is used to generate statistical data on how you use the website.

smartlookCookie - Used to collect user device and location information of the site visitors to improve the websites User Experience.

_ga, _gat, _gid
_ga, _gat, _gid
smartlookCookie
_clck, _clsk, CLID, ANONCHK, MR, MUID, SM

Marketing

Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.

IDE - Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.

test_cookie - Used to check if the user's browser supports cookies.

1P_JAR - Google cookie. These cookies are used to collect website statistics and track conversion rates.

NID - Registers a unique ID that identifies a returning user's device. The ID is used for serving ads that are most relevant to the user.

DV - Google ad personalisation

_reb2bgeo - The visitor's geographical location

_reb2bloaded - Whether or not the script loaded for the visitor

_reb2bref - The referring URL for the visit

_reb2bsessionID - The visitor's RB2B session ID

_reb2buid - The visitor's RB2B user ID

IDE, test_cookie, 1P_JAR, NID, DV, NID
IDE, test_cookie
1P_JAR, NID, DV
NID
hblid
_reb2bgeo, _reb2bloaded, _reb2bref, _reb2bsessionID, _reb2buid

Security

These are essential site cookies, used by the google reCAPTCHA. These cookies use an unique identifier to verify if a visitor is human or a bot.

SID, APISID, HSID, NID, PREF
SID, APISID, HSID, NID, PREF