Web Hosting with WHMCS: Common Mistakes • Best Practices
WHMCS Training
If you don't know WHMCS or you have a limited knowledge of this platform, first focus on reading beginners guide to WHMCS. Finding an expert of WHMCS is recommended. If your budget doesn't cover the costs of consulting, keep reading this article. We're going to teach you the basics.
When creating a WHMCS site to start a hosting business, everyone makes mistakes. Each mistake is a learning opportunity but there's a limit. You can't learn at the expense of your customers.
First thing first, WHMCS is not CMS like WordPress. What could go wrong if your blog returns errors or if you accidentally deleted a post? Pretty much nothing.
On the other hand WHMCS is connected to servers, payment gateways, domains and thousands of customers' services. As for domains, each of them follows a different life cycle made of renewals, expirations, grace/redemption period that vary from TLD to TLD. You can't mess with them as losing a domain can quickly turn into a very expensive mistake.
The first lesson to learn here is that there's little room for mistakes in WHMCS. Especially when providing services is your job. The risks of failing before even starting are real so let's dive into the stuff.
Further Security Steps
You have finished installing WHMCS. Before playing with its settings, you must perform the so called Further Security Steps. In the official documentation there's a detailed article that explains everything.
There's no need for us to repeat what the article already says. Here we focus on explaining the reasons why such steps shouldn't be underestimated. While it's true that some are optional, some others are mandatory.
You have to keep in mind that WHMCS is more than a website but the tool that runs your hosting business. As you can imagine to the eye of a cracker, breaching WHMCS is tens of times more attractive than cracking pretty much anything else.
As we said earlier, WHMCS is connected to servers, registrars, payment gateways. Most importantly it stores all your password and auth-codes that could be used to steal domains. Not to mention the possibility to inject malicious contents on all sites that you host on behalf of customers. Such things can pulverise your business in minutes!
Secure writable directories
Move the following writeable directories "above www" so that they're not accessible from browsers. In other words, when using Plesk such directories must be at the same level of httpdocs. For cPanel it's public_html.
- attachments
- downloads
- templates_c
If you don't move them, a cracker can exploit the possibility of uploading a backdoor in WHMCS. The backdoor is a file that grants access to files and database of your system. Basically it's like having FTP & phpMyAdmin access. The step from compromising your WHMCS to customers' sites is short. Let us give you an example:
- The cracker attaches the backdoor in a support ticket
- WHMCS renames the file adding a prefix (eg. 107046_hello.txt)
- The file is stored in attachments directory
With that in mind, the cracker knows that:
- The file is somehow is accessible from example.com/attachments/
- File name has been prefixed with 6 random digits
- An underscore separates the prefix original file name
With a directory scanner and a bit of brute force, anyone can guess the prefix. Once done, the backdoor can be easily accessed via web browser. The disaster is served. This is just one of the many ways a cracker can benefit from writable directories. Securing them is fundamental.
Secure configuration file
Still in WHMCS root there's a file named configuration.php. It contains sensitive data that you can't recover without a backup. If you accidentally edit or delete this file, you won't be able to recover passwords stored in WHMCS.
To avoid accidentally overwriting the file, you could make it read-only with CHMOD 400. Other than that, there's no particular reason to do that. This step doesn't increase security but protects you from human errors.
Move crons directory
Another key directory of WHMCS, is crons. It contains scripts that runs automatically via cron job. As we previously said for writeable directories, it is recommended to move it "above www". If you don't do that, anyone can triggr automated tasks by simply visiting example.com/crons/cron.php.
Restrict access by IP
I'm not a big fan of restricting access to a specific set of IPs for access to WHMCS administration. What if you need to login from mobile phone, dynamic IPs, from abroad or from the computer of your friend?
In such cases seeing "Forbidden" page is annoying. Blocking yourself from your own CRM doesn't look right to me. For me protection can't be at the expense of ease of use. That being said, your WHMCS, your rules.
Change admin folder name
For WordPress it's wp-admin, for Joomla administrator, for PrestaShop admin. WHMCS is no different and uses admin. Everyone knows default admin directories to conduct brute force attacks. We can make life difficult for crackers by simply renaming this folder.
Think about it. Leaving default names is like saying «Hello world! Feel free to brute force my login form located in example.com/admin». Not to mention zero-day vulnerabilities still unknown to or unaddressed by publishers.
Renaming this folder can notably improve the security level of your WHMCS. Before you rush to rename it, do not use a stupid replacement. Let us name some:
- CRM
- AdminPanel
- Backend
- Staff
- Manage
- Access
- Manage
- Manager
- Area
- Platform
- Billing
- Login
- cP
- Control
Also don't play with your bran name with things like:
- AdminKata
- AdminKatamaze
- MazeAdmin
- KataAdmin
Do you think that crackers are this stupid? There are dictionaries of commonly used replacements. Some malicious spiders browse the internet looking exactly for this. If you decide to go for one of these easy-to-guess options, you're not increasing protection.
Over the years we have accessed to thousands of WHMCS and 9 out of 10 we find such easy-to-guess names. It's unbelievable considering that this step alone can offer a high level of protection with almost no efforts.
What about something more random like 0D86Y4NG4? You don't even need to remember it. Just add WHMCS administration to favorites. Enjoy protection and move on to the next step.
Restrict database privileges
WHMCS suggests to disable specific database privileges but I'd rather ignore this step. As I previously said, I'm not a fan of security at the expense of usability. If someone manages to compromise your WHMCS, who cares about database privileges? You are already in serious troubles.
Many third-party modules and WHMCS itself expressly need some of these database privileges. The need to manually turn on and off them on demand is a complete waste of time. We think you can skip this step as long as you regularly take backups of your database.
Clicking on links
Few paragraphs earlier, we told you the importance of renaming admin directory. Using an unique and unguessable name can make a significant difference. However this tactic alone is useless if you don't keep this name a secret. Let us show how easily you can reveal your admin directory to anyone without even realizing it.
Every time you click a link, your browser includes the referer field which indicates the last page you where when you clicked the link. Simply put, when you click a link from ticket view, you're revealing admin directory.
For example many of our customers click on links included in our WHMCS modules to read documentation, changelogs etc. Our Google Analytics detects referrers onsite allowing us to discover admin login pages.
Let's get to the point. We're not saying that you shoud not click any link but be careful with the ones included in support tickets. Get used to copy/paste them in address bar. Keep in mind that opening links in new tab or window still sends referrers.
Overcomplicating
Beginners have the strange habit to make things complicated for no actual reason. WHMCS is already difficult to learn. Don't make things worse. The table below can help you avoid making bad decisions.
Don't do this  |
Do this  |
|---|---|
| Creating customer-based products | Use billable items |
| Adding unnecessary configurable options | Keep the purchasing process quick and simple |
| Replicating hosting plans for every CMS | An hosting package can suffice to any CMS |
| Having hundreds of products that never sell | Stick to products that actually sell |
| Using product addons, upgrades and downgrades | Leave them there. Most of the times they are not needed |
| Creating too many support departments | Unless you employ tens of people, all you need is pre-sales and technical support |
| Translating language files | Learn language overrides |
| Faking invoice numbers | There's nothing wrong in starting with invoice #1 |
| Hosting fake reviews | Stay away from scandals and fines |
| Branding anything and everything | Don't waste time putting your label everywhere. There's no need to hide that you use Plesk or cPanel |
| Thinking of WHMCS as a multi-tenant software | That's how you manage reseller in WHMCS |
| Offering too many choices |
You lose sales. 3 options are fine, 5 are too many:
|
| Allowing the registration of any TLD |
The day you manage to sell that exotic TLD, you'll waste hours trying to understand why it doesn't work. Stick to popular TLDs |
| Wasting client groups |
Customers can't be assigned to more than one group. Don't waste this opportunity with pointless groupings |
| Disabling automation to avoid fraudulent orders |
Learn how fraud protection works in WHMCS |
| Clicking without reading |
Read docs and ask for help. There's no undo in WHMCS |
| Pretending to use Bulk Pricing Updater for one client |
It's not supported. Use this pricing updater |
| Using default passwords for provisioning | |
| Watch out Client Custom Fields | |
| Doing SEO |
SEO and WHMCS are incompatible |
| Customizing six template |
Create and work on a copy of six template otherwise all changes will be lost during upgrades |
| WHMCS and customers on the same server |
Some hosting control panels can't setup hosting accounts on the same server where WHMCS is hosted (create function times-out). Use a separate servers |
| Login as Client? There's a glitch | |
| Using default integration with Chatstack |
Look at our enhanced integration with Chatstack |
Using a CMS
WHMCS lacks tools for content creators and is bad at search engine optimization. Many try to overcome the issue by installing a CMS like WordPress, Joomla or Drupal. This is a terrible idea. You can directly use WHMCS as CMS with all SEO enhancements included.
If you still want to rely on a third-party CMS, please read the following very carefully. WHMCS and your chosen CMS must be installed on separated hosting plans. To avoid misunderstanding of any sort, look at the the image below.
This is what we mean by saying "separated hosting plans". We are not talking about alias, subdomains, addon domains, domain or parking. That's not even about separating FTP accounts. You have to treat them as two distinct websites.
It doesn't matter how your CMS will be accessible from the web. It can be example.com/blog, blog.example.com or example.com. Just keep them on separate hosting plans.
If you don't follow this rule, a cracker can breach into your WHMCS by exploiting a vulnerability of your CMS. Don't put all your eggs in one basket. There's no point in securing WHMCS if you allow potential attacks to come from the CMS or any other web-based system.
Automatic Invoices
When you spot a mistake in an invoice that was automatically issued by WHMCS, do not delete it. Automatically generated invoices have in fact the peculiarity of storing a "reference ID". A value that is not visible from interface and that cannot be edited.
If you delete an invoice that contains one of these IDs, WHMCS won't be able to perform automatic tasks (eg. create, renew, unsuspend products and domains) when necessary. This problem also extends to invoice items.
That beings said, you should always try to fix billing mistakes on the same invoice by editing (not deleting) existing items. If you don't do that, you will be forced to perform tasks like renewals manually.
Emails
WHMCS is great at notifying things to customers and administrators. Customizing email templates that are being sent to customers requires a deep knowledge of WHMCS. Same goes for email settings.
The problem here is that beginners tend to overestimate their ability. They proceed with confidence making changes causing more harm than good.
Over the years, we have witnessed plenty of issues originating from customer confusion due to nonsensical changes made to emails. Please, respect the complexity of WHMCS for a couple of months before making changes.
Email Templates
You start editing email templates with the best of intentions. Probably you want to translate email in other languages but end up adding complexity.
Let's face it. You are still not mastering WHMCS thus how can you think that changing templates is a good idea? Take your time and learn this software.
Email Piping
With Email Piping, emails sent from customers automatically become support tickets. As a result clients can open and reply to tickets via email without the need to login to the client area first.
You're probably best to stay away from email piping. This is particularly true if you're starting a hosting business from scratch. The misconfiguration of email piping could result into never-ending loops and lost emails.
Let's see it from a different perspective. You started your website with WHMCS. What you need the most are visitors that help you increase rankings on search engines. Having customers submitting tickets from clientarea surely help.
There's nothing wrong in being a little opportunistic. We put lot of efforts to drive traffic to our site with marketing campaigns. Customers that visit the site to open, read and reply to support tickets are free traffic. We suggest using email piping at a later stage.
Marketing Emails
GDPR establish that email marketing is not allowed without consent. Starting from version 7.5, WHMCS introduced opt-in/opt-out functionality for marketing emails. The problem is that many forget that the rights of customers must be respected.
Every time you use Mass Mail Tool, ask yourself if you're sending a marketing email. If so, tick the relative checkbox and include the unsubscribe URL somewhere in the body of your message.
Billing
WHMCS holds your business together connecting domains, services, payments and customers with automation. The best approach is to embrace this structure as a whole tuning it to match your needs.
The problem is that many want to use third-party solutions to issue invoices. Generally the reason behind this decision is a bit silly. Some says they already have a billing software and want to use it for the sake of it.
Stop complicating things and enjoy the fully integrated experience of WHMCS and Billing Extension that introduces hundreds of features including:
- Monthly invoicing
- Electronic invoicing
- Credit notes
- Invoice to FTP
- Conversion tracking with Facebook Pixel and LinkedIn
If you still want to use an external software, you could be interested in the built-in electronic invoice web service for WHMCS.
Credentials
It's common for WHMCS owners to rely on external developers and companies. It could be for dedicated WHMCS support, modules or templates. In this scenario sharing your FTP and admin credentials is crucial.
We understand that beginners don't like the idea of granting access to their systems. That's how they end up creating accounts with limited privileges. They also hide customers, invoices and revenues. It's time to debunk the myth that this constitutes some sort of protection.
FTP access is enough to browse all files, database and WHMCS administration. We're not telling you this to scare you. We're just stating the truth. WHMCS permissions offer no protection against FTP.
That said, there's no need to be paranoid. Simply focus on trusting the right people. That's all you need.
Comments (0)