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.

Step #1: Create a Liquid Web Private Cloud Product

To create your first Private Cloud product you will first need to open the Product Setup Wizard page within the WHMCS interface:

  1. Click on the ‘Addons’ tab at the top of the page.
  2. Select the ‘Liquid Web Storm Servers Billing’ option.
  3. From the sidebar on the left, click ‘Product Setup Wizard’.
  4. Once loaded, select only ‘Liquid Web Private Cloud’ then click ‘Next’.
  5. At this point the process will vary depending on if you already have a Private Cloud server connected to your Liquid Web account.
  6. If you already have a Private Cloud server continue to F, otherwise you will need to create a new Private Cloud server:
    Add Private Cloud

    1. You will see a ‘Add New Server’ dialog box come up, once the page loads.
    2. Select the Zone you’d like the server to be in.
    3. Review the available Private Cloud servers and select the one you’d like.
    4. Provide a hostname for the server in the ‘Host Name’ text input.
    5. Click ‘Add Server’.
  7. You may now create the Private Cloud based product.
  8. Create Private Cloud Product

    You may want to adjust most, if not all, of the fields on this configuration page to customize the product based on your current needs.
  9. After adjusting the options as needed, click the ‘Save & Continue’ button.

Step #2: Advanced Product Configuration Settings

While the initial settings in the Product Setup Wizard are generally enough to accommodate most product creations, there are more advanced settings which might be useful when creating more complex product configurations.

There will be small differences between the advanced settings found within the Private Cloud settings and the VPS based settings, though generally they both have most of the same options.

To access the advanced product configuration settings you can either: click ‘Save & go to Advanced mode’ button when creating a new product, or by opening a current product and selecting the ‘Module Settings’ tab.

Vps Advanced
Private Cloud Advanced

Above you see the VPS advanced configuration page (left) and the Private Cloud advanced configuration page (right).

As seen above the advanced configuration pages are fairly similar in nature, this should make using these pretty simple once you’ve worked with either one. To further simplify understanding the options available, you will only find the following options on the VPS page:

  • Default Configurable Options
    • Used to generate a handful of customer customizable server options, such as: VPS type, Backup settings, IP address quantity, and bandwidth quotas
  • Zone
    • Determines the ‘data center zone’ that the server can be created in
  • Config
    • Defines the specific server that will be used to create the product; e.g. 1G SSD vs 2G non-SSD

The following options are only on the Private Cloud page:

  • Configurable Options
    • Similar to ‘Default Configurable Options’ above, this generates a number of Private Cloud specific options that can be exposed to customers upon checkout.
  • Custom Field
    • Similar to the above point, this generates custom fields to collect data on customer checkout.
  • Parent Server
    • Defines the parent server that this product will use when creating new instances.
  • Available Parents
    • A list of available Private Cloud servers that are usable as a Parent server.
  • Select Parent Automatically
    • When enabled the product should automatically select the parent server based on available resources.

On both Private Cloud & VPS pages you will find:

  • Username & Password
    • These are the credentials used when connected to the Storm API – should be prepopulated with the credentials that were initially created.
  • Template
    • This is the image used to bootstrap the server — this determines the Servers OS, Management Panel type, and Server Management Level.
  • Image
    • Allows the new server to be bootstrapped with a Storm Server Image if the account contains some images.
  • Backup Plan & Backup Quota
    • These options determine if backups are enabled, what type of backup plan is used, and the quota applied to the backups.
  • IPs Number & Maximum Number of IPs
    • Defines the default number of IP addresses to start the server with and the maximum number of IPs a single server can allocate.
  • Bandwidth Quota
    • Allows customization of the Bandwidth quota applied to the server.
  • Monitoring
    • Enables customers to control Monitoring services on the server.
  • Firewall
    • Enables customers to control Firewall services on the server.
  • IPs Management
    • Enables customers to control IP address allocations on the server.

With a multitude of product configuration options available, you can choose exactly how you offer products and services to your customers. By fully utilizing these more advanced settings you can allow customers to select from a very specifically tuned array of products, or to adjust product details as they wish during the checkout process.

Step #3: Working with Configurable Options

To expand further upon the ability for your customers to tweak and adjust services they are ordering you can take advantage of the ‘Configurable Options Groups’ within WHMCS. These ‘Configurable Options’ are additional options that can be presented to a user upon ordering a service.

By utilizing these configurable options with the advanced features discussed above you are able to provide customers a build your own server experience, a variety of products to fit specific needs, or a mixture of both.

To begin working with ‘Configurable Options’ you will need to open WHMCS and go to the ‘Setup -> Products/Services -> Configurable Options’ page. Once there you can see a list of the groups similar to the following screenshot.

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

Working with WHMCS & the Liquid Web Reseller Plugin
I. What is WHMCS and installing the Liquid Web 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.

Step #1: Connect the plugin to Storm API

To make the initial connection to the Storm API you will first need to open the Product Setup Wizard page:

  1. Click on the ‘Addons’ tab at the top of the page.
  2. Select the ‘Liquid Web Storm Servers Billing’ option.
  3. From the sidebar on the left, click ‘Product Setup Wizard’.
  4. Once loaded, we will make our connection by starting to set up our first product:
    1. Adjust the checkboxes to your liking, for this example we will only select: ‘Liquid Web SSD VPS’
    2. Click Next.
    3. If this is the first product setup you will be redirected to the Account Authentication page.
  5. On the ‘Liquid Web account authentication’ page you will be prompted for your Liquid Web API authentication; you may either enter Liquid Web API credentials or your Liquid Web Manage credentials, and the wizard will create a new API user.
    1. For using a current API user:
    2. Api User login

      1. Click the ‘I have Liquid Web API credentials’ heading.
      2. Enter your Liquid Web Storm API user credentials.
      3. Click ‘Continue’.
    3. For creating a new API user:
    4. Manage Login

      1. Click the ‘Create a NEW Liquid Web API username and password for me’ heading.
      2. Enter your Liquid Web Manage credentials.
      3. Click ‘Create new API account’.
      4. You will now see the new Storm API user that has been created. Write these credentials down for safe keeping.
      5. Click ‘Continue’.

With that completed you have now authorized the plugin to access your Liquid Web account via the Storm APIs. You can now begin to create and setup products to offer your new clients.

Step #2: Create your first VPS product

Having completed all the prior steps we are now ready to create the first product via the Product Setup Wizard. In this tutorial our example product will be based on the Liquid Web SSD VPS, so we are now on the related configuration page, as seen below.

Product Wizard - Add VPS Product

You may want to adjust most, if not all, of the fields on this configuration page to customize the product based on your current needs.

Product Details

  • You need to provide the product name, description, and select a product group.

Module Settings

  • Default values from the database are loaded when you open this page.
  • You need to select the OS template and VPS type when changing the Zone.

Pricing (Monthly)

  • You can set the subscription pricing (monthly) either in percentage or fixed values.
  • When using percentage-based pricing, the module will automatically calculate the pricing of the selected configuration and update the pricing table in WHMCS.

Once you have adjusted the options on this page to your liking you can then proceed with creating the product by clicking ‘Save & Continue’ found on the bottom right of the page.

If you would like to you can verify the product was created by pulling up the ‘Products/Services’ page of WHMCS; found under: Setup > Products/Services > Products/Services, you should find your new product listed there. With this step you will have completed the creation of your first product!

Step #3: Storm Server Billing configuration

Now that we’ve created our first product clients can immediately begin putting in orders via the WHMCS client area. They will be charged based on the price values you configured when working through the Product Setup Wizard.

However with certain products or services you may require that clients pay for various resource usages, such as: bandwidth, disk usage, overall disk space, backups, memory, and/or CPU usage.

In order to control these aspects of a product you can use the ‘Liquid Web Storm Servers Billing’ page:

  1. Click on the ‘Addons’ tab at the top of the page.
  2. Select the ‘Liquid Web Storm Servers Billing’ option.
  3. Once loaded you will see a page similar to:
  4. Enable Billing Page

    Note: the paths on your page will be updated to reflect the location of the files needing to be run on cron.
  5. Configure and Enable the cron jobs:
    1. Using your preferred method [cPanel, or Command line], enable each cron job found on this page.
  6. You will see a dropdown under ‘Enable Billing’, open the dropdown and select your new product from the list.
  7. Once the page loads, you will see various resource usage-related categories where you can set extra charges for various metrics. [Bandwidth, Disk, Memory, etc]
  8. Billing Limits page

  9. Adjust these values to your liking and then click ‘Save Changes’ near the bottom of the page

With these new options and limits in place any servers of this type will now be billed based on resource limits defined on the Billing configuration page.

At this point the plugin should be fully configured with WHMCS and you can now continue to use the ‘Product Setup Wizard’ to create even more products and services to offer your clients.

What is WHMCS and installing the Liquid Web plugin

Working with WHMCS & the Liquid Web Reseller Plugin

What is WHMCS?

The WHMCS software suite provides the necessary tools to automate billing and provisioning of web hosting services on WHM based servers. It provides an easy-to-access management interface allowing resellers full control over the products and services you choose to offer. WHMCS is perfect for the reseller looking to streamline or expand their cPanel-based business.

WHMCS provides automated systems for managing invoices, billing, customer management, and service provisioning – all allowing you to focus more on your clients. Enhanced by the addition of our rebuilt plugin for WHMCS, the process truly is fully automated.

New products can now be created in a few clicks with the new ‘Product Setup Wizard’; once an order has been placed and paid for, the plugin will access the LiquidWeb Manage APIs to spin up and provision the necessary services for you.

Step #1: Installing the LiquidWeb WHMCS plugin

Installation of our WHMCS plugin is a rather simple process and can be done by a few methods: using graphical-based tools and programs, or the command line interface. This section will detail the steps required to install and setup the plugin.

Our WHMCS plugin can now be found on a publicly available GitHub-based repository. Or a direct download link to the installation Zip: Liquid Web for WHMCS.

Download the plugin zip file in your root WHMCS directory. The directory might not be the same for everyone, but an example of how to do this would be:

Via SSH (command line) on the server…
cd /home/$WHMCSUSER/public_html/WHMCS/
wget https://github.com/liquidweb/LiquidWeb-WHMCS-Plugin/archive/master.zip
unzip master.zip
cd LiquidWeb-WHMCS-Plugin-master/
rsync -avH includes/ ../includes/
rsync -avH modules/ ../modules/

You can also use FTP to upload the file, or use the cPanel File Manager if you wish. Regardless of the upload method you will need to unzip the files and put them in place using the commands from above.

Step #2: Activate the LiquidWeb WHMCS plugin

  1. Click on the “Setup” tab near the top of the page
  2. Select the “Addon Modules” option
  3. Open the Addon Page

  4. Once loaded, find ‘Liquid Web Storm Servers Billing’ and click “Activate”
  5. To give this module the correct permissions, click on the “Configure” (i) button and then select “Full Administrator” (ii) in the “Access Control” section and then click ”Save Changes” (iii)
  6. Enable Main Addon

  7. While here you may want to activate the Widget plugin
    1. Find ‘Storm On Demand Widget For WHMCS’ and click “Activate”
    2. To configure this module’s settings, click on the “Configure” button (a), adjust the ‘Low Inventory Threshold’ and ‘Cron Mail’ settings to your liking (b) and then click “Save Changes” (c).
    3. Enable Widget Addon

    4. To give the Widget proper permissions, click “Setup > Staff Management > Administrator Roles”. On the Administrator Roles page you will edit the Role which you’d authorize for the widget.
    5. Open User Role permissions

    6. On the Role editing page find the “Widgets” section, and within that find and enable “Liquid Web Storm Servers”, click “Save Changes”

At this point the Liquid Web WHMCS plugin should now be active and you should be able to start setting up packages and products within WHMCS.

If you’d like to report issues, or provide feedback of any kind, regarding this plugin you can feel free to do so by utilizing the project’s GitHub Issues page.

Working with Composer & Examples

Tutorial: How to use Composer
I. Composer 101
II. Installing Composer on cPanel servers
III. 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.

Example #1: Getting GuzzleHTTP using Composer

One of the most popular PHP HTTP clients, Guzzle is a library that can make sending HTTP requests simple and easy. As a widely used and well-documented library, Guzzle is an easy package for any developer or designer to take advantage of.

To try out Guzzle run the following commands:

$ mkdir guzzleTest
$ cd ./guzzleTest/
$ composer require guzzlehttp/guzzle

Then create an index.php file in the same folder with the following content:

<?php
require_once 'vendor/autoload.php';
$client = new GuzzleHttp\Client();

// Make a request
$res = $client->request('GET', 'http://www.timeapi.org/utc/now.json');

// Output the status code of the response
echo 'Page response code: '.$res->getStatusCode();
echo "<hr/>";
// "200"

// Output headers of the response
echo 'Response Content-Type header: ';
print_r( $res->getHeader('content-type') );
echo "<hr/>";
// 'application/json; charset=utf8'

// Output the actual content (body) of the response
echo 'Response Body content: ';
echo $res->getBody();
echo "<hr/>";
?>
In the above PHP code, lines starting with ‘//’ are considered comments and are just there to help detail each step of script.

Opening the new index.php file in your browser should yield a page that shows: the HTTP response code, the ‘Content-Type’ header of the response provided, and the actual content of the response.

Example #2: Getting a framework

While composer is mainly used to get specific libraries and packages needed for a site to run, it’s also possible for a whole framework or CMS to be provided using composer. Laravel is one of many popular PHP frameworks that use composer to distribute their core files. An example of using composer to get Laravel can be done with the following commands:

$ composer create-project --prefer-dist laravel/laravel ./laraTest

Once this command has been executed composer will do a number of things for you; it will create the “laraTest” folder, initialize the composer.json file, get any necessary dependencies and then setup the Laravel-specific files.

To verify this example you will need some familiarity with the Laravel framework, however you can verify that composer did its job by checking the file structure. To check the file structure run the following command:

$ ls -lah

You should see a structure similar to:

total 200K
drwxr-xr-x 11 user users 4.0K Aug 8 13:17 .
drwxr-xr-x 10 user nginx 4.0K Aug 8 13:16 ..
drwxr-xr-x 10 user users 4.0K Apr 27 09:01 app
-rwxr-xr-x 1 user users 1.7K Apr 27 09:01 artisan
drwxr-xr-x 3 user users 4.0K Apr 27 09:01 bootstrap
-rw-r–r– 1 user users 1.3K Apr 27 09:01 composer.json
-rw-r–r– 1 user users 111K Aug 8 13:17 composer.lock
drwxr-xr-x 2 user users 4.0K Apr 27 09:01 config
drwxr-xr-x 5 user users 4.0K Apr 27 09:01 database
-rw-r–r– 1 user users 458 Aug 8 13:17 .env
-rw-r–r– 1 user users 423 Apr 27 09:01 .env.example
-rw-r–r– 1 user users 61 Apr 27 09:01 .gitattributes
-rw-r–r– 1 user users 73 Apr 27 09:01 .gitignore
-rw-r–r– 1 user users 503 Apr 27 09:01 gulpfile.js
-rw-r–r– 1 user users 212 Apr 27 09:01 package.json
-rw-r–r– 1 user users 1.1K Apr 27 09:01 phpunit.xml
drwxr-xr-x 2 user users 4.0K Apr 27 09:01 public
-rw-r–r– 1 user users 1.9K Apr 27 09:01 readme.md
drwxr-xr-x 5 user users 4.0K Apr 27 09:01 resources
-rw-r–r– 1 user users 567 Apr 27 09:01 server.php
drwxr-xr-x 5 user users 4.0K Apr 27 09:01 storage
drwxr-xr-x 2 user users 4.0K Apr 27 09:01 tests
drwxr-xr-x 29 user users 4.0K Aug 8 13:17 vendor

Installing Composer on cPanel servers

Tutorial: How to use Composer
I. Composer 101
II. Installing Composer on cPanel servers
III. Working with Composer & Examples

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.

Pre-Flight Check

  • These instructions are intended specifically for installing Composer on a cPanel based server running WHM prior to version 58.
  • We’ll be logging in as root to a Liquid Web Fully Managed cPanel server.
As of WHM version 58 cPanel is now including a version of Composer by default, this can be accessed by simply calling composer from command line.
For more details see: What’s New in WHM 58 & What to Look For

Step #1: Get the installer

Acquire the Composer installer script with the following commands:

$ EXPECTED_SIGNATURE=$(wget https://composer.github.io/installer.sig -O - -q)
$ php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
$ php -r "if (hash_file('SHA384', 'composer-setup.php') === '$EXPECTED_SIGNATURE') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"

The above commands will: get the installer’s signature, get the installer file, verify the download by checking the signature and finally confirm if the installer is valid, or corrupt. You should see output similar to:

Installer verified

Step #2: Run the installer

To run the installer in a manner that will install composer globally run the following command:
php ./composer-setup.php --install-dir=/usr/local/bin --filename=composer

With this command run as root composer should now be globally installed on the server.

Step #3: Verify the install

In order to verify the composer installation was successfully you will want to do the following to test. First, as root, run the following command:
# composer -V

You should see something similar to:

Composer version 1.2.0 2016-07-19 01:28:52

If that checks out, you will then want to verify Composer works for the users as well. To confirm composer is working for the cPanel accounts SSH into your server as a cPanel user and do the same:

$ composer -V

You should see something similar to:

Composer version 1.2.0 2016-07-19 01:28:52

Composer 101

Tutorial: How to use Composer

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.

Examples being: Silex MicroFramework, the infamous PHPMailer class, Laravel Framework, and many more – all of which can be found on Composer’s main repository Packagist.

To find a more documented list of classes, libraries, or frameworks that are available you can review the Packagist site.

So How Do I Use This Tool?

To use Composer you will want to be logged in via SSH, or TTY, and you will run the following command:

$ composer require {somepackage}

This will issue a command for Composer that essentially states you are requiring the provided package name in the current folder. What this does is requests the package given; if found, it then creates the following:

  • composer.json
  • /vendor
  • composer.lock

Ok, so that downloaded the necessary PHP files to use the library, or package, you are requesting. It created a “/vendor” folder where it downloaded all the ‘library’ files. Great, you’ve got the necessary files, but now what?

How Do I Use the Composer-provided Libraries?

To use Composer-provided libraries you may need to understand Composer a little bit better first; specifically you’ll need to understand how Composer’s autoloader works. Think of this as your ‘crash course’ to the autoloader.

To make more sense of this concept let’s go back to our ‘What is Composer’ section; as we know Composer is a “Dependency Manager for PHP”. This means it’s getting you a library, or some code, needed for your site or project. It will also grab any libraries, or other requirements, needed by that library to function – hence the name “dependency management tool”, it’s doing that part in the background for you. In order to make use of this tool, you need to make sure you’re properly including everything that is required.

That’s where Composer’s Autoloader comes in, the autoloader is a script which includes and loads any needed dependencies. Long story short, Composer will create for you a file called: “autoload.php” that is located in the “/vendor” folder it creates. This file is all you need to use/re-use the libraries, classes, or etc, that you are getting from Composer.

Using the Autoloader

In order to use a Composer-provided library you will simply need to add the following to your script:
require 'vendor/autoload.php';

Keep in mind that the part within single quotes should be the relative path to this file; this may need adjusting depending on how you are doing things.

Final Tips When Using Composer

Ultimately, including the `require autoloader.php` line allows you to utilize the packages, classes, libraries, etc, that you are asking composer to get for you. These dependencies are downloaded locally to where the ‘require’ command was run.

When working on cPanel servers you should only run and use composer as the cPanel user requiring those dependencies. Doing this will ensure the files are downloaded in a manner that keeps proper user ownership and permissions. However, if you accidentally run Composer as the root user you will simply need to adjust the file permissions and ownership accordingly.

While the usage of Composer is mainly done by developers, if you are experiencing any issues with file ownership, permissions, or if you have any questions feel free to contact our Heroic Support®.

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

Advanced Firewall Configuration in WHM/cPanel

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

How to Allow Traffic by Country in the CSF Firewall

One of the most-requested features on cPanel servers is the ability to manage and filter traffic at a country level. With the ConfigServer Firewall (CSF) plugin in WebHost Manager, you can do exactly that.

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.

Blocking traffic by country code carries significant overhead, due to the fact that the country-level CIDR ranges can be quite large and the IP address behind each incoming request must be checked against the block list.
One alternative is to instead specifically allow traffic by country code. This approach can minimize the performance hit by country-level filtering whenever traffic from several countries needs to be blocked, or traffic from only one geographic area should be allowed.
If you have not already done so, back up the current firewall configuration (Part One: How to Back up and Restore the Firewall Configuration) before making any changes.

Step #1: Open Firewall Configuration in WHM

  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: Allow traffic by country code

  1. On the Firewall Configuration page, scroll down to the Country Code Lists and Settings section.

    Use CC_Allow_Filter to restrict access to a specific country or list of countries.

  2. CC_ALLOW_FILTER accepts two-letter country codes, such as “US” for the United States of America, “GB” for Great Britain, and “DE” for Germany.
  • Multiple countries can be comma separated with no spaces in between, such as “US,GB,DE” to deny access to the US, Great Britain, and Germany.
  • You can find a list of ISO 3166-1 alpha-2 codes at https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2.

Note that CSF has two separate “Allow” sections:

  • CC_ALLOW actually opens the firewall to all traffic on all ports from the listed countries, bypassing any port and protocol rules in place. It should not be used.
  • CC_ALLOW_FILTER allows only traffic from the specified country or countries, but respects the port and packet rules elsewhere in the firewall configuration. This is the preferred method for allowing traffic by country code.

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

See Part Four: How to Block or Allow Specific Ports by Country in the CSF Firewall
 

How to Block Traffic by Country in the CSF Firewall

One of the most-requested features on cPanel servers is the ability to manage and filter traffic at a country level. With the ConfigServer Firewall (CSF) plugin in WebHost Manager, you can do exactly that.

Country-level filtering in CSF uses the Maxmind GeoLite Country database to obtain CIDR (Classless Inter-Domain Routing) ranges for specific countries. Each CIDR range covers all the IP addresses assigned to that country.

There are a number of reasons why a server administrator may wish to block traffic from a specific country, with reducing bandwidth, minimizing exposure to security risks, and ensuring that a site’s content is viewable only in geographic locations where it is permitted among the most common. However, there are several important factors to consider before choosing to filter traffic at the country level:

  • A small percentage of unwanted traffic still may get through, and a small percentage of desired traffic could be blocked, because:
    • the CIDR range lists used for country-level blocks are not 100 percent accurate.
    • some Internet Service Providers and web services use non-geographic IP addresses for their clients.
    • proxy services and virtual private networks can be used to mask a visitor’s true geographic location.
  • Country-level filtering applies only to incoming connections. Outbound traffic is not affected.
  • Using country-level filtering will negatively impact performance and you will notice slower response times on your websites. This is due to the sheer size of the CIDR range lists (the list for the U.S. is 621K in plain text and contains more than 37,000 entries) and the fact that the firewall must check each incoming IP address against the chosen list(s).

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 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.

Step #1: Open the Firewall Plugin in WHM

  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.
    Edit the CSF configuration file

Step #2: Deny Access by Country Code

CSF does not recommend the use of country-level blocks on any VPS or small server unless the CIDR range for the chosen country is very small. The use of a large-range country block on a small server or VPS could slow the server to the point that it becomes inaccessible.

If you’re using a VPS or have any question as to whether your server has the resources to effectively implement a country-level block, you may find it more practical to allow or deny traffic by country code to specific ports, which we cover in Parts Three and Four.

  1. On the Firewall Configuration page, scroll down to the Country Code Lists and Settings section.
    ccallowdeny1
  2. Use the CC_DENY field to block by country code:
    • The CC_DENY field accepts two-letter country codes, such as “US” for the United States of America, “GB” for Great Britain, and “DE” for Germany.
    • Multiple countries can be comma separated with no spaces in between, such as “US,GB,DE” to deny access to the US, Great Britain, and Germany.
    • You may find a list of ISO 3166-1 alpha-2 codes at https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2
    • Do NOT use the CC_ALLOW field to allow traffic by country code. CC_ALLOW opens the firewall to all traffic on all ports from the listed countries, bypassing any port and protocol rules in place.
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.

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.
    Restart csf and lfd for new settings to take effect

Next Steps

See Part Three: How to Allow Traffic by Country in the CSF Firewall