Working with WHMCS & the Liquid Web Reseller Plugin

Working with WHMCS & the Liquid Web Reseller Plugin

What is WHMCS & how it can optimize your business

The WHMCS software suite is an all-in-one client management, billing & support interface for web hosting businesses. WHMCS can be used to automate the billing and provision of Web Hosting Services. Most often utilized by resellers, WHMCS can simplify and streamline the process of providing hosting service. To learn more, read our “What is WHMCS” article here.

What does Liquid Web’s WHMCS Plugin do?

WHMCS has a lot of useful features right out of the box, however most of these features are based on control panels such as cPanel or Plesk. This is perfectly fine if you just want to sell shared hosting but if you’re looking to resell cloud based VPS / VMs you will need to install additional plugins / addon modules that contain this additional functionality. Continue reading “Working with WHMCS & the Liquid Web Reseller Plugin”

Migrating to Liquid Web with Managed WordPress Portal

Note: The instructions in this tutorial are for the Managed WordPress portal client, these instructions do not apply if you have a Liquid Web WordPress Server Optimized Template account.

Migrations to Liquid Web’s Managed WordPress portal are made easy using a custom plugin created specifically for Liquid Web by BlogVault. With this plugin, you can migrate any WordPress site into your portal in just a few easy steps.

Step #1: Create a Site

You will need to create a new site in your portal to act as a destination site for your migration to Liquid Web.

  1. Log into your portal and click Create New Site
  2. Once the Create a Site page opens, enter the site nickname. 
    Note:
    The site nickname (short name)  is only a nickname for easy organization of your sites within the Managed WordPress portal. It is not the domain you will be using for your public-facing site. It can be changed at any time.
  3. Enter your email address. This is the email address you will use for all notifications for your site. 
  4. If you want to create your site from a stencil you saved, choose the stencil from the drop-down. 
  5. Click Create Site to have the site begin to create. Once it is finished, it will show up in your site list on the main page of your portal. 
  6. You will need the SFTP credentials for the site to copy/paste into the migration plugin. Click the Manage Site button for the site you created to access the information you will need. 

You will now prepare the site you want to migrate over. This is called the source site.

Step #2: Source Site Preparation

Warning: If you are using a platform service like Rainmaker, you will need to open a Support Ticket to complete your migration.

To prepare your source site, log into your WordPress admin page for the site you want to migrate.

  1. From the admin portal of the source site, click the Plugins link. 
  2. Click Add New to be navigated to the WordPress plugins page. 
  3. Begin typing Liquid Web in the search bar. The migration plugin for Liquid Web should appear in the list of plugins. 
  4. Select Install Now to download the plugin to your site. 
  5. After the plugin installs, click Activate. This will direct you to the BlogVault plugin page.
  6. Your source site is now ready for migration.

Step #3: Begin Migration

You are now ready to begin the migration process.

  1. When you activate the migration plugin, it will automatically direct you to the migrations page. 
    Note:
    Once you activate the plugin, a link to the plugin will show up in the menu on the right hand side of your WordPress admin portal. If you are not immediately directed to the page, use the link to get to the BlogVault migration plugin home.
  2. You will need to enter the following information from your Liquid Web Managed WordPress site management page into the plugin form to begin your migration:
    • Email address, this is the email you will use to receive all site notifications.
    • Site URL, make sure you use https:// with the domain name. This is the domain name that is found at the top of your site management home page in your portal.
    • SFTP Hostname which is the IP address in the SFTP information section of your site portal. Use the convenient Copy link to copy the information from your portal and paste it into the plugin.
    • SFTP username and password also found in the SFTP information section of the site portal. To create a password, click the Generate Password link in your portal.
  3. Once you enter the required information, click the Migrate button to begin. 
  4. You can watch the progress of your migration with BlogVault’s migration progress site. Here you can watch the progress of your migration. 
    Note:
    Depending on the size of the files and tables in your site, your migration can take a few moments or a few hours. Please be patient during the migration process.
  5. Once the migration is complete, a success message will show on the migration page and you will receive an email notifying you of the migration as well. 

Step #4: Test Your Site

Your site is now successfully migrated! There is just one more step to complete before you make your site go live by changing the DNS. If you are hosted with Liquid Web, you will need to create a DNS Zone, see our article How to Add or Modify DNS Records in Manage for more information.

Before you go live with your site, it is important that you test your site and make sure everything works the same way as it did before the migration.

  1. Using the link at the top of the page in your site manager, open your new site.
  2. Test all pages, links, redirects and post a comment.
  3. Log into the WordPress admin page and create a new page and post to make sure they create properly. Import an image or two and make sure they display correctly.

Step #5: Go Live with Your Site

Once you’ve verified that all parts of your site are working as they should, you are now ready to go live with your site.

WHMCS with Private Cloud Servers and Advanced Product Setup

Working with WHMCS & the Liquid Web Reseller Plugin

With the steps of the previous articles complete, we now have the WHMCS Liquid Web plugin setup and enabled. If you followed the previous directions, you’ve successfully created the first product based on VPS offerings. We will now cover some more advanced product creation options. Continue reading “WHMCS with Private Cloud Servers and Advanced Product Setup”

WHMCS account setup, the Product Setup Wizard and Storm Servers Billing

Working with WHMCS & the Liquid Web Reseller Plugin
II. WHMCS account setup, the Product Setup Wizard and Storm Servers Billing
III. WHMCS with Private Cloud Servers and Advanced Product Setup

In the previous article we covered the basics of WHMCS, the benefits of using our plugin, and how to enable the plugin and widgets we provide in our plugin package. This article will cover the configuration of the Storm API access and your first product.

With the rebuilt Liquid Web reseller plugin for WHMCS, the initial account and API connection setup has been integrated into the new Product Setup Wizard. So, to configure the plugin to access your Liquid Web account via Storm API, we simply will start the process of creating your first product. Continue reading “WHMCS account setup, the Product Setup Wizard and Storm Servers Billing”

Working with Composer & Examples

In the previous articles we worked through what composer is, who uses it, and how to install it. Here we will cover some basic use case examples of how to acquire packages using the composer tool we previously setup.

The example documented in this article can be done either locally, or on your Liquid Web Fully Managed cPanel server, in either case these directions should be run as the user owning the website files. On a cPanel server this would mean you’re running these via SSH logged in as the cPanel user and you would be starting from within public_html. Continue reading “Working with Composer & Examples”

Installing Composer on cPanel servers

With a tool like Composer it is generally best to have the ability to run it as any user on the server and from any directory. This is generally referred to as being ‘globally installed’ as any user can access the tool from any location. In this guide we will detail how to install Composer globally on a cPanel based server. Continue reading “Installing Composer on cPanel servers”

Composer 101

Composer is a dependency manager for PHP, written in PHP. Specifically, it’s used to simplify the process of using PHP libraries in your projects. The use can range from getting a framework, including a library class, or open source projects; generally these packages are downloaded by Composer and then implemented by a developer in a website’s code. Continue reading “Composer 101”

Basic DoS/DDoS Mitigation with the CSF Firewall

Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks are common threats that every publicly accessible web server faces. The purpose of such attacks, in simplest terms, is to flood a server with connections, overloading it and preventing from accepting legitimate traffic.

Attacks increasingly have become automated instead of directly targeted and botnets (networks of infected computers that can be remotely controlled) continue to grow at a rapid pace, making DoS and DDoS attacks much more common.

Fortunately, CSF can be used to help mitigate small attacks.

Before proceeding, it is important to understand the following points:

  1. There is no way to prevent a DoS/DDoS attack against any server connected to the Internet; once in progress, the only thing that can be done is to try to mitigate its effects.
  2. There is no way to make a server respond normally when it is under attack; the most that can be done is to try to keep it online during the attack by reducing the impact of the incoming traffic.
  3. In some cases, the best way to deal with a large-volume attack is to null-route the server’s IP address. Effectively, that means temporarily taking it offline until the incoming traffic subsides.
  4. Any measures employed within CSF will be effective only against small attacks, and measures should be implemented in CSF only while the server is under attack. The firewall settings always should be restored afterward to minimize disruption of legitimate traffic, as the measures outlined below will slow incoming packets.
  5. CSF is not the only way to mitigate small-scale attacks. Services such as those offered by CloudFlare’s network also may help because they are external, buffering traffic to the server. And for maximum protection against large attacks (millions of incoming packets per second), a specialized DoS mitigation service may be necessary. You can read more about such protection at https://www.liquidweb.com/services/network/ddos.html.

Pre-Flight Check

  • This series assumes you have the ConfigServer Firewall (CSF) installed on your cPanel server, and you have access to WebHost Manager (WHM).
  • If your managed cPanel server currently uses APF but you’d prefer CSF, contact Heroic Support® and request a switch. There is no charge, it typically takes only a few minutes, and the only service that needs to be restarted as a result is the firewall itself. Our support technicians also can port your existing APF rules to CSF. If requesting an upgrade, please be sure to indicate whether your server uses the Guardian backup service so that its rules also can be configured.

If you have not already done so, be sure to first back up the current firewall configuration (Part One: How to Back up and Restore the Firewall Configuration) before making any changes. After the attack has subsided, you will want to restore the current firewall configuration using the instructions in that article.

Step #1: Open the Firewall Configuration

  1. In WebHost Manager, locate and select ConfigServer Security & Firewall under the Plugins section in the left menu. You also can begin typing “fire” into the search field at the top left to narrow down the options.
  2. Click on the Firewall Configuration button to open the configuration file.

Step #2: Rate Limit Incoming Traffic

The first thing that can be done to mitigate the effects of an incoming attack is to limit the number of connections per IP address.

When properly configured, CSF will track the number of connections from IP address hitting the server and block IP addresses at the firewall level should they exceed a defined limit.

It’s important not to set the limit too low, as protocols such as FTP, IMAP, and even HTTP all legitimately make multiple connections. Also, remember that most companies as well as homes and public hotspots may have many different computers on their internal network which all share a single public IP address.

  1. To set the limit on connections per IP address, scroll down to the Connection Tracking section of the Firewall Configuration page and set CT_LIMIT to the desired value.
    Connection tracking limit
    For the purposes of this tutorial, we’ll be using 150 connections per IP address as an upper limit. You may find that you need to lower or raise that number but, generally, you should never attempt to set it below about 100.
  2. Assuming the server is under attack, you also will want to disable email alerts by setting CT_EMAIL_ALERT to “0”. Otherwise, the server will send an email every time it blocks an IP address, which will only add to load on the server.
    Disable email alerts when enabling connection tracking
  3. You also may wish to restrict rate limiting to specific ports, which can be done using the CT_PORTS setting. Multiple ports can be added in comma-separated format (with no space in between). In this example, we’re applying rate limiting only to HTTP ports:
    Limit connection tracking to specific ports

With these settings, any IP address that makes more than 150 connections to the web site on the standard and/or secure ports will be blocked in the firewall. By default, that will be a temporary block for 30 minutes. The CT_BLOCK_TIME setting can extend the block period, and by toggling the CT_PERMANENT setting you can arrange for the IP addresses to be blocked permanently.

Step #3: SYNflood Protection

A SYNflood attack is a DoS attack exploiting the TCP (Transmission Control Protocol) connection process itself.

In basic terms, a TCP connection is established using a three-way handshake:

  • The client (incoming connection) sends a synchronization packet (SYN) to the server.
  • The server responds with a synchronization acknowledgement (SYN/ACK) to the client.
  • The client then responds with an acknowledgement (ACK) back to the server.

A SYNflood attack manipulates that three-way handshake by initiating multiple synchronization requests and then refusing to respond with any final acknowledgements. That causes the server, which is keeping a spot open waiting on the client’s final reply to complete their incoming connection, to eventually run out of available connections for the targeted service and appear to be offline.

On a Linux server, you can quickly check for SYN packets by running this command over SSH:
netstat -nap | grep SYN -c
It’s important to note that the presence of SYN packets does not necessarily mean that a server actually is under SYNflood attack. For instance, if load on the server already is high or there is a great deal of incoming traffic, an elevated level is to be expected. Only the presence of a large number (in the hundreds) is likely to be indicative of a possible SYNflood attack.

If you know that the server is under attack, you can configure CSF to help mitigate this type of attack. Otherwise, skip to Step Three and restart the firewall to apply the rate limits you enabled in Step One.

  1. To enable SYNflood protection, locate the Port Flood Settings section of the Firewall Configuration page.
    Port Flood settings
  2. You can enable SYNflood protection by setting SYNFLOOD to “1” and setting the maximum rate and burst:
    • SYNFLOOD_RATE is the number of SYN packets to accept per IP, per second. For the purposes of this tutorial, we’ll be using a value of “75/s” on the assumption that a DoS attack is in progress.
    • SYNFLOOD_BURST is the number of times the IP can hit the rate limit before being blocked in the firewall. A setting of 25 works for our purposes.

You likely will need to raise or lower these settings based on your circumstances. However, a setting above about 100/s for the rate (or 150 for the burst) could be too generous to be effective; Likewise, lowering the rate below about 50/s (or the burst below about 50) could prevent legitimate access to services.

Step #3: Save Your Changes and Restart the Firewall

  1. Scroll to the bottom of the Firewall Configuration page and click on the Change button.
  2. On the next screen, click the Restart csf+lfd button to restart the firewall with the new settings.

Next Steps

  1. Once the attack has subsided, you will need to restore the firewall’s previous configuration to avoid disruption of legitimate incoming traffic. If these “under attack” rules are left in place, the added packet scrutiny at the firewall level will slow traffic considerably and can lead to noticeably diminished web server performance.
  2. If you followed the instructions in Part One: How to Back up and Restore the Firewall Configuration to back up the previous configuration, you can easily use the same process to restore those saved settings. You also may wish to save these DoS/DDoS protection settings before restoring the original configuration so that they can be quickly employed in the future if necessary.

 

How to Block or Allow Specific Ports by Country in the CSF Firewall

In addition to being able to manage traffic from a specific country or a list of countries, CSF allows you to manage access by country to specific ports. This can be useful if you need to ensure that a particular service is available globally (such as your web server on port 80) but want to restrict international access to services such as WHM/cPanel, SSH, or FTP.

You should note that all of the limitations on country-level filtering outlined in Part Two: How to Block Traffic by County in the CSF Firewall apply here as well. Specifically, some ISPs use non-geographic IP addresses, some web services and cloud-based tools may use servers outside the country the companies are based in, and proxy services and virtual private networks easily can mask a visitor’s actual geographic location.

Taken together, that means that some unwanted traffic could get through, and some desired traffic could be blocked under certain circumstances.

Note: At least one of ConfigServer’s servers is in Germany; blocking that country could prevent CSF from being able to update and display an error on the ConfigServer Security&Firewall page in WHM.

Pre-Flight Check

  • This series assumes you have the ConfigServer Firewall (CSF) installed on your cPanel server, and you have access to WebHost Manager (WHM).
  • If your managed cPanel server currently uses APF but you’d prefer CSF, contact Heroic Support® and request a switch. There is no charge, it typically takes only a few minutes, and the only service that needs to be restarted as a result is the firewall itself. Our support technicians also can port your existing APF rules to CSF. If requesting an upgrade, please be sure to indicate whether your server uses the Guardian backup service so that its rules also can be configured.

If you have not already done so, back up the current firewall configuration before making any changes.

In WebHost Manager, locate and select ConfigServer Security & Firewall under the Plugins section in the left menu. You also can begin typing “fire” into the search field at the top left to narrow down the options, then click on the Firewall Configuration button to open the configuration file.

Blocking Access to Specific Ports by Country

Restricting access by port to IP addresses originating in a specific country or countries can be an effective way to help minimize the negative performance impact that country-level blocking can bring.

That’s because the smaller the CIDR (Classless Inter-Domain Routing) range against which each IP making an incoming request is checked, and the fewer requests on that port (SSH on port 22 and FTP on port 21 are likely to see far less traffic than the website itself on port 80), the fewer the resources the firewall checks should require.

In this case, only incoming traffic on the specified port or ports will checked against the CIDR range(s) for the blocked country code(s).

If you wish to deny access to several countries or wish to allow access to a port for only a single country, a better option may be to instead allow access only to that country. Feel free to skip ahead to Allow access to specific ports by country below to learn how to do that.

In this example, we’re blocking access to the standard FTP port, 21, to IP addresses originating in Belgium.

Step #1: Specify the Country or Countries to be Denied

  1. Scroll down to the Country Code Lists and Settings section and add the country code to CC_DENY_PORTS. Multiple countries can be comma separated with no spaces in between, and you can find a list of ISO 3166-1 alpha-2 codes at https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2.
  2. List the port that will be blocked in the specified country in the CC_DENY_PORTS_TCP and CC_DENY_PORTS_UDP fields.

Here we’ve specified that traffic originating from Belgium is not allowed to connect on the standard FTP port, 21:Blocking port access by country

Step #2: Save Your Changes and Restart the Firewall

  1. Scroll to the bottom of the Firewall Configuration page and click on the Change button.
  2. On the next screen, click the Restart csf+lfd button to restart the firewall with the new settings.

By defining a country in CC_DENY_PORTS and a port in the CC_DENY_PORTS_TCP and CC_DENY_PORTS_UDP fields, we’ve ensured that the port will remain open to any visitor with valid credentials so long as their IP address does not originate from the specified country.

Allowing Access to Specific Ports by Country

Just as you can deny incoming traffic by port to a specific country or countries, you also can choose to allowing incoming traffic by port to only a specific country or countries. Generally, this should be a better option than attempting to deny port access to a long list of countries because the firewall be working with a smaller CIDR range against which each incoming request must be checked.

To limit the ability to connect on a specific port or ports to visitors with IP addresses originating in a specific country or countries, you must:

  • close the ports in the firewall
  • define the country code allowed to connect on those blocked ports
  • specify the blocked ports to be opened for the specified country

In this example, we’re restricting access to the standard FTP port, 21, to IP addresses based in Germany.

Step #1: Close the Ports in the Firewall

On the Firewall Configuration page, scroll down to the IPv4 Port Settings section, and remove the desired port number from the TCP_IN and UDP_IN (if present) fields.
Here, we’ve removed port 21 from the allowed incoming IPV4 ports, effectively blocking external access to the port:

Remove the port from TCP_IN

Step #2: Specify the Country or Countries to be Allowed

Scroll down to the Country Code Lists and Settings section and add the country code to CC_ALLOW_PORTS.

Here we’ve specified that traffic originating from Germany is allowed to connect on ports which have been otherwise closed in the firewall (we’ll define the specific ports for this allow in the next step):

Allowing a country access to specified ports
Multiple countries can be comma separated with no spaces in between, and you can find a list of ISO 3166-1 alpha-2 codes at https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2.

Step #3: Specify the Closed Ports to be Allowed to the Designated Country

Just below the CC_ALLOW_PORTS field, you’ll see CC_ALLOW_PORTS_TCP and CC_ALLOW_PORTS_UDP.

We’ll add the port to open to the country (or countries) specified in CC_ALLOW_PORTS here, in this case, port 21:

SPecify which ports to open to designated countries

Step #4: Save Your Changes and Restart the Firewall

  1. Scroll to the bottom of the Firewall Configuration page and click on the Change button.
  2. On the next screen, click the Restart csf+lfd button to restart the firewall with the new settings.

Now that we’ve closed the standard FTP port in the firewall’s IPV4 Port Settings, no visitor will be able connect to port 21 unless their IP address originates from Germany. At the same time, the setting applies only to port 21 and any visitor, regardless of geographic location, still can view the website or connect to any port open in the firewall.

Next Steps

See Part Five: Basic DDoS Mitigation with CSF