As soon as a web app goes online, automated attack bots bombard it with malicious requests. Attackers eventually target every website and eCommerce store in the hopes of discovering a vulnerability that they can exploit to inject code, misuse resources, or steal data. In 2019, bad bots accounted for one-quarter of all web traffic. Many features in cPanel and WHM assist web hosts and site administrators in repelling bad bots, including the ModSecurity web application firewall (WAF).
For many years, cPanel and WHM have supported ModSecurity 2, and in cPanel 92, developers brought additional for ModSecurity 3. It should be noted that ModSecurity 3 support is experimental, but it provides a few significant benefits:
- ModSecurity 3 runs faster than previous versions.
- It is not dependent on Apache and can be used alongside other web servers such as NGINX.
This article will explain what ModSecurity is and how to install and configure ModSecurity 3 on cPanel and WHM.
Table of Contents
What Is Apache ModSecurity and How Does It Work?
ModSecurity is a firewall for web applications. It continuously monitors incoming web traffic for threats, blocking malicious connections before they reach applications. ModSecurity is a rule-based firewall that compares requests to a set of rules to look for patterns that match attacks like SQL injection, session hijacking, cross-site scripting, and others.
Users can add their own rules to rule sets that are typically provided by a third party. The most popular is the Open Web Application Security Project (OWASP) Core Rule Set. It includes rules that protect web apps from a wide range of threats, including the OWASP Top Ten, a list of the most common attacks that is regularly updated.
You may be wondering how web-application firewalls differ from the network firewall that already exists on your server. Do you require both? As discussed in How To Survive a DDoS Attack, network firewalls protect servers from malicious traffic at the network layer.
Because they appear to be legitimate web requests, network firewalls such as CSF cannot filter attacks against web applications. WAFs, on the other hand, are designed to work at the application layer, identifying potentially harmful HTTP requests. If you host web apps on your cPanel server, you should use both a network firewall such as CSF and a WAF such as ModSecurity.
How to Install ModSecurity in cPanel
You will need root access to your server to install ModSecurity 3, both on the command line with SSH and in WHM. You must first install the EasyApache4 experimental repository because ModSecurity 3 support is experimental.
Log in to your server with SSH and run the following command:
yum install ea4-experimental
The connector that allows ModSecurity to communicate with a web server will then be installed. We offer two connectors, one for Apache and the other for NGINX. They can be added to the shell or the WHM.
You must first uninstall ModSecurity 2:
yum remove ea-apache24-mod_security2
Install the relevant connector in the shell using one of the following:
yum install ea-modsec30-connector-apache24
yum install ea-modsec30-connector-nginx
In WHM:
- Navigate to the EasyApache4 page, which you will find in the Software section of the sidebar menu.
- Click Customize under Currently Installed Packages.
- Select the Additional Packages tab.
- Click the switch next to modsec30-connector-apache24 or modsec30-connector-nginx
- Select the Review tab, and click the Provision button at the bottom of the page.
cPanel will now install the connector and its dependencies.
Finally, we’ll install the OWASP Core Rule Set, which you can do in WHM by repeating the installation process described above for the modsec30-rules-owasp-crs package. You can also use the shell to install the RPM:
yum install ea-modsec30-rules-owasp-crs
Configuring ModSecurity
We chose sensible defaults that should work for most web hosting environments, but we also provide tools in WHM’s Security Center for configuring ModSecurity and its rules.
ModSecurity Configuration
ModSecurity Configuration includes options for controlling the behavior of ModSecurity components such as the audit engine, rules engine, and connection engine. You can also configure the relevant paths and binaries in this interface if you want to use an external geolocation database or logging tool.
ModSecurity Tools
The primary interface for monitoring and configuring the firewall’s rules is ModSecurity Tools. The Hits List displays requests that triggered a rule and allows users to deactivate rules so that similar connections can be enabled in the future.
ModSecurity Tools also includes an interface for viewing and editing rules, as well as adding new rules using ModSecurity’s SecRules language.
ModSecurity Vendors
Tools for adding and managing rule sets are included in ModSecurity Vendors. If you followed the instructions in the previous section, you should see the OWASP CRS rule set provided by cPanel, which you can activate or deactivate here, as well as control automatic updating. You can also enable and disable rule sets, such as IP reputation, WordPress exclusion, and scanner detection rules.
Hosting providers may prefer to develop their own rule set or buy one from a third-party vendor. ModSecurity Vendors also has functionality for adding and managing third-party rulesets.
Managing ModSecurity with ModSecurity SDBM utility
ModSecurity saves information about IP addresses and requests in the /var/cpanel/secdatadir/ip.pag file. Because ModSecurity does not purge stale data, this file may consume an excessive amount of disk space over time. Install the ModSecurity SDBM utility if you want the system to automatically clean this cache.
yum install ea-modsec-sdbm-util
If the utility is installed, cPanel’s maintenance scripts will run it automatically, but you can also run it manually with the following command:
/scripts/shrink_modsec_ip_database -x
As a general rule, system administrators should delegate cache cleanup to maintenance scripts. If you choose to run the SDBM tool utility manually, restart Apache with:
/scripts/restartsrv_httpd