Install and Configure ModSecurity on Ubuntu 16.04 Server

Posted on by Jason Potter | Updated:
Reading Time: 5 minutes

Mod_security, also commonly called Modsec for short, is a powerful WAF (Web Application Firewall) that integrates directly into Apache’s module system. This direct integration allows the security module to intercept traffic at the earliest stages of a request. Early detection is crucial for blocking malicious requests before they are passed along to web applications hosted by Apache websites. This provides and extra layer of protection against common threats a server faces. This article will explore the installation of mod_security along with the CRS (Core Rule Set) in an Ubuntu 16.04 LTS Server running Apache 2.4.


The target system environment must meet the following requirements:

  • Ubuntu 16.04 LTS Server
  • Baseline Apache 2.4 pre-installed
  • Pre-configured Network & Internet Connection
  • Root user shell access (console or SSH)

Additionally, familiarity with the following system administration concepts are necessary:

  • Basic navigation of the Linux command line shell
  • Modifying files in your chosen system editor (vim, nano, emacs, etc.)


Pre-Flight Checks

Mod_security is a standard module in many Apache-based OS images and may already be installed on the target system. Before we continue, lets first make sure we are running Apache 2.4 and mod_security is not already installed. This is done simply with the following two commands.

Sudo is a prefix to all commands in this documentation. It allows execution of root-level permissions on a command by command basis. If you are not familiar with sudo, you may be prompted for your password to authorize execution one or more of the commands in this outline.

Check Apache Version

sudo apache2ctl -v

Example Output:
Server version: Apache/2.4.18 (Ubuntu)
Server built:   2018-06-07T19:43:03

Check if the Security Module is Active

apache2ctl -M | grep security

— If this command returns nothing, mod_security is not installed so proceed to the Installation Section.

— If the command returns security2_module, mod_security is installed so proceed to the Configuration Section.


Installation Section

The apt package manager in all Debian-based system (like Ubuntu) makes installation quick and painless. Supply the correct package name, libapache-modsecurity in this case, to the apt command and confirm the installation.

Use Apt to Install the libpache2-modseurity Plugin

sudo apt install libapache2-modsecurity -y

Example Output:

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
libapache2-mod-security2 libyajl2 modsecurity-crs
Suggested packages:
lua geoip-database-contrib ruby
The following NEW packages will be installed:
libapache2-mod-security2 libapache2-modsecurity libyajl2 modsecurity-crs
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 545 kB of archives.
After this operation, 3,960 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 xenial/main amd64 libyajl2 amd64 2.1.0-2 [19.6 kB]
Get:2 xenial/universe amd64 libapache2-mod-security2 amd64 2.9.0-1 [314 kB]
Get:3 xenial/universe amd64 libapache2-modsecurity all 2.9.0-1 [2,006 B]
Get:4 xenial/universe amd64 modsecurity-crs all 2.2.9-1 [210 kB]
Fetched 545 kB in 0s (1,659 kB/s)
Selecting previously unselected package libyajl2:amd64.
(Reading database ... 92965 files and directories currently installed.)
Preparing to unpack .../libyajl2_2.1.0-2_amd64.deb ...
Unpacking libyajl2:amd64 (2.1.0-2) ...
Selecting previously unselected package libapache2-mod-security2.
Preparing to unpack .../libapache2-mod-security2_2.9.0-1_amd64.deb ...
Unpacking libapache2-mod-security2 (2.9.0-1) ...
Selecting previously unselected package libapache2-modsecurity.
Preparing to unpack .../libapache2-modsecurity_2.9.0-1_all.deb ...
Unpacking libapache2-modsecurity (2.9.0-1) ...
Selecting previously unselected package modsecurity-crs.
Preparing to unpack .../modsecurity-crs_2.2.9-1_all.deb ...
Unpacking modsecurity-crs (2.2.9-1) ...
Setting up libyajl2:amd64 (2.1.0-2) ...
Setting up libapache2-mod-security2 (2.9.0-1) ...
apache2_invoke: Enable module security2
Setting up libapache2-modsecurity (2.9.0-1) ...
Setting up modsecurity-crs (2.2.9-1) ...
Processing triggers for libc-bin (2.23-0ubuntu11) ...

Once installed, it’s a simple matter to confirm the security module is being loaded by Apache:

Check if the Security Module is Active

apache2ctl -M | grep security

Example Output:

security2_module (shared)


Configuration Section

Now that the base module is installed, we need to configure and enable it. This requires a few steps:

Step 1) Copy the recommended config over as the live config

sudo cp /etc/modsecurity/modsecurity.conf{-recommended,}

Step 2) Modify the live config and change “SecRuleEngine DetectionOnly” to “SecRuleEngine On”

sudo sed -i -e 's/DetectionOnly$/On/i' /etc/modsecurity/modsecurity.conf

Step 3) Check Apache’s config syntax & restart Apache if OK

sudo apache2ctl -t && sudo apache2ctl restart

Example output:

Syntax OK

Apache is now actively running with mod_security in place. However, there are no rules in place for it. The next section goes over configuring these rules.


Enable Core Rule Set & Base Rules

The security module is only as good as the rules governing it. To help get started, the libapache2-modsecurity package comes with a companion package (modsecurity-crs). This package contains the Core Rule Set or CRS, which is a basic set of rules that handle some of the most common malicious activity on the Internet today.  The CRS protects against many dangerous types of traffic include, but not limited to:

  • SQL Injections (SQLi)
  • Remote Code Execution (RCE)
  • Cross Site Scripting (XSS)
  • And many other common malicious behavior


The CRS gets installed along with the security module. Follow these next steps to enable CRS & it’s Base Rules.

Step 1) Add the following lines to modsecurity.conf with your preferred editor

# ModSecurity Core Rule Set (CRS)
IncludeOptional /usr/share/modsecurity-crs/*.conf
IncludeOptional /usr/share/modsecurity-crs/activated_rules/*.conf

Step 2) Create a symlink in the activated_rules directory for all *.conf files in the base_rules directory

CSRD=/usr/share/modsecurity-crs; for e in $CSRD/base_rules/*.conf; do sudo ln -s $e $CSRD/activated_rules/; done

Step 3) [Optional] Confirm symlinks are in the activated_rules directory

sudo ls /usr/share/modsecurity-crs/activated_rules/*.conf


Step 4) Check Apache’s config syntax & restart Apache if OK

sudo apache2ctl -t && sudo apache2ctl restart

Example output:

Syntax OK

The server is now configured and actively using the base_rules from the CRS. There are additional rules provided by the CRS package. These additional rules are discussed in greater detail in the next section.

Rule of Thumb:
It is necessary to verify syntax and restart Apache, anytime changes are made to one or more mod_security rules.


Enable Additional Rules [Optional]

The Core Rule Set includes many additional rules. These rules are separated into three distinct categories: experimental_rules, optional_rules, and slr_rules. Each category’s rules are contained within their directory of the same name. Activating these rules is the same process as enabling the base_rules. Create a symlink to the desired rule from the activated_rules directory.  The following commands can be used to quickly enable these rules if needed.

Discernment is warranted when enabling additional rules beyond those in the base_rules set. The additional rules, especially experimental_rules, are more likely to encounter false positives, blocking legitimate traffic. The commands below are provided for convenience and is not an endorsement of enabling all rules indiscriminately.


CSRD=/usr/share/modsecurity-crs; for e in $CSRD/experimental_rules/*.conf; do sudo ln -s $e $CSRD/activated_rules/; done


CSRD=/usr/share/modsecurity-crs; for e in $CSRD/optional_rules/*.conf; do sudo ln -s $e $CSRD/activated_rules/; done


CSRD=/usr/share/modsecurity-crs; for e in $CSRD/slr_rules/*.conf; do sudo ln -s $e $CSRD/activated_rules/; done


Disable Rules

To disable rules, delete the symlink within the activated_rules directory that pertains to the rule in question. Once deleted, a quick restart of Apache services is necessary to make the change active.

Example: Delete the application_defects rule then restart Apache.

sudo rm -rf /usr/share/modsecurity-crs/activated_rules/modsecurity_crs_55_application_defects.conf

sudo apache2ctl restart


The Most Helpful Humans In Hosting

There is more than one-way Liquid Web can help. Whether it’s contacting our support or providing you the managed services you need to succeed, you can rely on us to be there with you. If you find yourself having trouble with these instructions, our support teams are here to help. We pride ourselves on being  The Most Helpful Humans In Hosting™.  Our support teams work diligently with Apache and Mod_security daily. With availability 24 hours a day, 7 days a week, and 365 days a year, we are always available to assist when your tasks become too arduous to tackle on your own. We encourage you to share the burden with our support teams by phone, chat or email. We can help!


Fully Managed Servers & Applications

All the Liquid Web Fully Managed Servers & Applications come with mod_security installed, configured, and managed by our support teams. In addition to the Core Rule Set packaged with mod_security, all of our fully managed server kicks include our very own Liquid Web internal rules. These additional rules protect against further threats that our security engineers have identified attacking servers in the wild. These additional rules are a direct countermeasure against known attack vectors and update when new attacks have been identified. We take care of it all, so you don’t have to worry.



Server Protection Packages

When standard security is not enough, you don’t have to wage war alone. The Liquid Web Server Protection Packages provides additional server hardening beyond just mod_security rules. These packages offer hardened configurations to maintain the best level of protection against intrusion and other malicious activity. This is merely one of our many security-related Hosting Add-on Services.

Avatar for Jason Potter

About the Author: Jason Potter

A veteran of the IT Support field, I have more than a decade of experience in systems administration, web hosting, and cPanel servers. I enjoy writing and providing complicated technical concepts in layman terms. On my free time, I enjoy playing several types video games, automation scripting and just living life with my wife and two kids.

Latest Articles

Controlling PHP settings with a custom php.ini file

Read Article

How to install Puppet Server on Linux (AlmaLinux)

Read Article

Email security best practices for using SPF, DKIM, and DMARC

Read Article

Linux dos2unix command syntax — removing hidden Windows characters from files

Read Article

Change cPanel password from WebHost Manager (WHM)

Read Article