How to Install ModSecurity 2, OWASP with Apache on Debian 12, 11 or 10

Securing your Apache web server is critical, and ModSecurity offers a robust solution for this challenge. This open-source web application firewall (WAF) is designed to protect your web applications from various threats. This guide will focus on installing ModSecurity 2 with Apache on Debian 12, 11, or 10.

Why Choose ModSecurity 2?

• Apache Compatibility: ModSecurity 2 is fully compatible with Apache, making the installation and configuration process seamless.
• Reliability: This version has undergone extensive testing, making it a stable and reliable choice for securing your web applications.
• Older Debian Version Support: ModSecurity 2 works smoothly with older versions of Debian, such as Debian 11 and 10, thanks to specialized PPA repositories that provide the latest Apache packages.

What’s Next?

This guide will provide detailed instructions on how to install ModSecurity 2 on Apache for Debian versions 12, 11, and 10. We’ll use a trusted PPA repository specializing in the latest Apache packages, ensuring a smooth installation process. Stay tuned for a step-by-step walkthrough to bolster your web application’s security.

Section 1: Install Apache and ModSecurity 2 on Debian 12, 11 or 10

Step 1: Update Debian System Packages for ModSecurity 2 Installation

Our first step is to ensure our Debian system is updated. Doing so keeps all existing packages up to date, ensures optimal performance, and minimizes security risks. Achieve this by running the following command:

sudo apt update && sudo apt upgrade

After updating your system, check whether Apache is installed. If not, use the following command to install it:

sudo apt install apache2

Section 2: Import ModSecurity Module PPA with Apache on Debian 12, 11 or 10

Step 1: Setting up the Required Repository on Debian

The next task on our list is to install the ModSecurity Apache Module. The version available in Debian’s default repositories might not be the latest, and using it can lead to immediate errors. Instead, we’ll import a third-party repository to install the latest ModSecurity Module for Apache. This third-party repository, maintained by Digitalwave, is renowned for its stable binaries.

Begin by installing a set of necessary packages:

sudo apt install apt-transport-https lsb-release ca-certificates curl -y

We then proceed to import the ModSecurity 2 Module PPA repository GPG key:

curl -fsSL https://modsecurity.digitalwave.hu/archive.key | sudo gpg --dearmor | sudo tee /usr/share/keyrings/digitalwave-modsecurity.gpg > /dev/null

After acquiring the GPG key, add the repository to your system:

echo "deb [signed-by=/usr/share/keyrings/digitalwave-modsecurity.gpg] http://modsecurity.digitalwave.hu/debian/ $(lsb_release -sc) main" | sudo tee -a /etc/apt/sources.list.d/digitalwave-modsecurity.list
echo "deb [signed-by=/usr/share/keyrings/digitalwave-modsecurity.gpg] http://modsecurity.digitalwave.hu/debian/ $(lsb_release -sc)-backports main" | sudo tee -a /etc/apt/sources.list.d/digitalwave-modsecurity.list

Step 2: Prioritizing the New Apache Module PPA Repository on Debian

With the repository in place, it’s now necessary to adjust the APT policy to prioritize this repository for specific packages related to ModSecurity. The following command accomplishes this:

cat << EOF | sudo tee -a /etc/apt/preferences.d/99modsecurity
Package: *nginx*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *libapache2-mod-security2*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *modsecurity-crs*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *libmodsecurity*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900
EOF

Next, run an APT update to reflect the newly imported source:

sudo apt update

Additionally, to confirm the preferences, you can confirm this policy change with the following:

sudo apt-cache policy libapache2-mod-security2 modsecurity-crs libmodsecurity3

Step 3: Install ModSecurity 2 Module on Debian 12, 11 or 10

Now that the repository is ready proceed with the installation of the libapache2-mod-security2 module:

sudo apt install libapache2-mod-security2

After installation, it’s necessary to enable the module. Use the following command to achieve this:

sudo a2enmod security2

Step 4: Restarting Apache Service

Lastly, we restart the Apache service to make sure all changes take effect, and the newly added ModSecurity module is correctly integrated:

sudo nano /etc/apache2/mods-enabled/security2.conf

Section 3: Enable ModSecurity 2 Module on Debian 12, 11 or 10

Accessing the ModSecurity Configuration File

The configuration file for Apache ModSecurity can be found at /etc/apache2/mods-enabled/security2.conf. Access this file using the nano text editor (or your preferred text editor) with the following command:

sudo nano /etc/apache2/mods-enabled/security2.conf

Look for the line that reads:

IncludeOptional /etc/modsecurity/*.conf

Ensure this line is uncommented, as it includes other necessary configuration files from the /etc/modsecurity directory. It should be uncommented by default.

Modifying the ModSecurity 2 Configuration for Apache on Debian

We need to rename the modsecurity.conf-recommended configuration file to modsecurity.conf to make it active. This can be done with the following command:

sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Now, let’s open this newly named configuration file:

sudo nano /etc/modsecurity/modsecurity.conf

Within this file, the ModSecurity rule engine is set to DetectionOnly by default. This means it will identify and log potentially malicious behavior without blocking it. To change this and enable ModSecurity’s blocking capabilities, locate the SecRuleEngine line (around line 7) and replace DetectionOnly with On.

From:

SecRuleEngine DetectionOnly

To:

SecRuleEngine On

Adjusting Log Settings for Apache on Debian

Further down the configuration file, you will find the SecAuditLogParts line (around line 224). The default setting for this line isn’t quite correct; it needs to be adjusted to log all transaction information accurately.

Change:

SecAuditLogParts ABDEFHIJZ

To:

SecAuditLogParts ABCEFHJKZ

With these modifications in place, save your changes and exit the editor.

Restarting Apache to Apply Changes

Our final step in this process is to restart the Apache service so that our changes to the ModSecurity configuration take effect. This is accomplished using the following command:

sudo systemctl restart apache2

Section 4: Implementing the OWASP Core Rule Set for ModSecurity2 on Debian 12, 11 or 10

ModSecurity alone does not safeguard your webserver. It requires a rule set to identify potential threats and block malicious activity. The OWASP (Open Web Application Security Project) Core Rule Set (CRS) is a highly regarded rule set used by various webservers and Web Application Firewalls (WAFs). Deploying this rule set furnishes your server with robust protection against a range of threats emerging on the internet.

Before we proceed, it’s essential to verify that you have the latest version of OWASP CRS by visiting the OWASP Release tag page. This step ensures that you download and install the most up-to-date security measures for your server.

Creating the Parent Directory for OWASP CRS on Debian

First, let’s create the main parent directory for OWASP using the mkdir command:

sudo mkdir /etc/apache2/modsec/

Download OWASP CRS Archive on Debian

Next, we’ll use the wget command to fetch the OWASP CRS 3.3.4 archive, which is the stable version at the time of writing. Remember that you should verify the version from the link mentioned earlier.

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.4.zip

The nightly build may offer more up-to-date security measures but could cause issues due to its development status. For new users, it is advisable to use the stable version to avoid potential complications.

Extracting the Archive

With the archive downloaded, we can extract it into the directory we created earlier:

sudo tar xvf v3.3.4.tar.gz -C /etc/apache2/modsec

Remember to change the commands based on the OWASP CRS version you downloaded.

Configuring the Rule Set

The OWASP CRS has a sample configuration file you should rename while retaining the original as a backup. You can do this using the cp command:

sudo cp /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf.example /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf

Remember to replace /coreruleset-3.3.4/ with the exact version of the OWASP CRS that you have chosen.

Enabling the Rules

To activate the rules, open the /etc/apache2/mods-enabled/security2.conf file:

sudo apt install unzip -y

Then, insert the following two lines:

Include /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf
Include /etc/apache2/modsec/coreruleset-3.3.4/rules/*.conf

Again, ensure you replace /coreruleset-3.3.4/ with the exact version of OWASP CRS you’ve selected.

Additionally, comment out or remove the following line:

IncludeOptional /usr/share/modsecurity-crs/*.load

Once done, save and exit the file:

Restarting Apache to Apply Changes

The last step is to restart your Apache service to ensure the changes take effect:

sudo systemctl restart apache2

Section 5: Getting Started with OWASP Core Rule Set and ModSecurity 2 on Debian 12, 11, or 10

The OWASP Core Rule Set (CRS) is a comprehensive tool with numerous customizable options. Its default configuration provides immediate security enhancements for most servers without impacting genuine visitors or Search Engine Optimization (SEO) bots. We will discuss a few significant aspects of the CRS in this section, but exploring the configuration files for a complete understanding of all available options is always beneficial.

Adjusting the CRS Configuration on Debian with ModSecurity 2

We initiate by opening the crs-setup.conf file where most of the CRS settings can be altered:

sudo nano /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf

Grasping the CRS Scoring System on Debian with ModSecurity 2

ModSecurity operates in two distinct modes:

• Anomaly Scoring Mode: Recommended for most users, this mode assigns an ‘anomaly score’ each time a rule matches. After processing both inbound and outbound rules, the anomaly score is checked, and a disruptive action is triggered if necessary. This action often takes the form of a 403 error. This mode provides accurate log information and offers greater flexibility in setting blocking policies.
• Self-Contained Mode: In this mode, an action is applied instantly whenever a rule is matched. While it can reduce resource usage, it offers less flexibility and yields less informative audit logs. The rule-matching process stops when the first rule is met, and the specified action is executed.

Understanding Paranoia Levels on Debian with ModSecurity 2

The OWASP CRS defines four paranoia levels:

• Paranoia Level 1: The default level is suitable for most users.
• Paranoia Level 2: For advanced users.
• Paranoia Level 3: For expert users.
• Paranoia Level 4: Only advisable under extraordinary circumstances.

Higher paranoia levels enable additional rules, provide increased security, and augment the likelihood of blocking legitimate traffic due to false positives. Choosing a paranoia level that aligns with your expertise and security needs is essential.

Testing OWASP CRS on Your Server on Debian with ModSecurity 2

To ensure the OWASP CRS is operating correctly on your server, use your internet browser to access the following URL. Remember to replace “yourdomain.com” with your actual domain:

https://www.yourdomain.com/index.html?exec=/bin/bash

If you receive a 403 Forbidden error, OWASP CRS is functioning as expected. If not, there might be a misstep in the setup process that requires your attention; the most common issue can be forgetting to change DetectionOnly to On or something similar.

Section 6: Address False Positives and Custom Exclusion Rules with OWASP with ModSecurity 2 on Debian 12, 11, or 10

Dealing with false positives while leveraging ModSecurity and OWASP CRS is often a perpetual task. However, these systems’ defense against diverse threats makes the effort worthwhile. To begin the process, we recommend maintaining a low paranoia level to reduce the number of potential false positives.

Running the rule set with minimal false positives for a few weeks, or even months, before augmenting the paranoia level can prevent an overwhelming surge of false positives. This method enables you to acclimate to the system’s alerts and understand how to respond appropriately.

Managing False Positives in Known Applications on Debian with OWASP, ModSecurity 2

ModSecurity incorporates an innate capability to whitelist common actions that may inadvertently trigger false positives. Consider the following example:

#SecAction \
# "id:900130,\
#  phase:1,\
#  nolog,\
#  pass,\
#  t:none,\
#  setvar:tx.crs_exclusions_cpanel=1,\
#  setvar:tx.crs_exclusions_dokuwiki=1,\
#  setvar:tx.crs_exclusions_drupal=1,\
#  setvar:tx.crs_exclusions_nextcloud=1,\
#  setvar:tx.crs_exclusions_phpbb=1,\
#  setvar:tx.crs_exclusions_phpmyadmin=1,\
#  setvar:tx.crs_exclusions_wordpress=1,\
#  setvar:tx.crs_exclusions_xenforo=1"

To enact whitelisting for applications such as WordPress, phpBB, and phpMyAdmin, uncomment the respective lines and maintain the (1) value. For services not in use, adjust the value to (0) to prevent their whitelisting.

The updated configuration could look as follows:

SecAction \
 "id:900130,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.crs_exclusions_phpbb=1,\
  setvar:tx.crs_exclusions_phpmyadmin=1,\
  setvar:tx.crs_exclusions_wordpress=1"

In this instance, extraneous options have been removed, leaving the correct syntax for the configurations you require.

Creating Rule Exclusions Before CRS Implementation on Debian with ModSecurity 2

To craft custom exclusions, start by altering the name of the REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf file using the cp command:

sudo cp /etc/apache2/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/apache2/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

Remember, each exclusion rule needs to have a unique id:<rule number> to avoid errors during Apache2 service testing.

For example, certain REQUEST_URIs may trigger false positives. The following example illustrates two such scenarios involving Google PageSpeed beacon and the WPMU DEV plugin for WordPress:

SecRule REQUEST_URI "@beginsWith /wp-load.php?wpmudev" "id:1544,phase:1,log,allow,ctl:ruleEngine=off"

SecRule REQUEST_URI "@beginsWith /ngx_pagespeed_beacon" "id:1554,phase:1,log,allow,ctl:ruleEngine=off"

These rules will grant automatic permissions for any URL beginning with the specified path.

IP addresses can also be whitelisted in various ways:

SecRule REMOTE_ADDR "^195\.151\.128\.96" "id:1004,phase:1,nolog,allow,ctl:ruleEngine=off"

SecRule REMOTE_ADDR "@ipMatch 127.0.0.1/8, 195.151.0.0/24, 196.159.11.13" "phase:1,id:1313413,allow,ctl:ruleEngine=off"

In the first rule, a single IP address is whitelisted, while the second rule uses the @ipMatch directive for broader subnet matching. To block a subnet or IP address, replace allow with deny. With this level of flexibility, you can create intricate blacklists and whitelists and even incorporate them with Fail2Ban for a more comprehensive security strategy.

Disabling Specific Rules on Debian with OWASP, ModSecurity 2

Instead of whitelisting an entire path, another approach involves disabling specific rules that consistently cause false positives. While this method requires more time and rigorous testing, it can prove highly beneficial in the long run.

Let’s say rules 941000 and 942999 in your /admin/ area continually trigger unwarranted bans and blocks for your team. You would locate the rule ID in your ModSecurity logs and disable only that specific ID using the RemoveByID command:

SecRule REQUEST_FILENAME "@beginsWith /admin" "id:1004,phase:1,pass,nolog,ctl:ruleRemoveById=941000-942999"

Monitoring Logs and Identifying Patterns on Debian with OWASP, ModSecurity 2

Continuous monitoring of logs is vital when handling false positives with Apache, ModSecurity, and OWASP. Doing so can help you detect patterns that signal false positives. Once such patterns are identified, you can create custom rules to mitigate them.

For instance, if you discover specific rules consistently triggering false positives, you can create an exclusion rule for those distinct cases. This approach allows for more precise and effective management of potential false positives.

By maintaining a constant, watchful eye on your logs and fine-tuning your system to address issues as they arise, you can create a more secure, efficient environment for your applications.

Section 7: Implementing Log Rotation for ModSecurity 2 on Apache and Debian 12, 11 or 10

Due to the dynamic nature of web transactions, ModSecurity logs can accumulate rapidly, necessitating an efficient log management strategy. Log rotation, which is not configured by default in ModSecurity, is a powerful tool for managing these logs effectively. This section will guide you through setting up log rotation for your ModSecurity.

Step 1: Creating a ModSecurity Rotation File on Debian for ModSecurity 2

Firstly, we need to create a new file specifically for ModSecurity rotation. To do this, use the nano command to create and open a new file named modsec:

sudo nano /etc/logrotate.d/modsec

Step 2: Configuring the Rotation File on Debian for ModSecurity 2

In the newly created modsec file, input the following configuration:

/var/log/modsec_audit.log
{
        rotate 31
        daily
        missingok
        compress
        delaycompress
        notifempty
}

This configuration instructs the system to keep the logs for a duration of 31 days. However, the storage duration is highly flexible and can be modified based on your needs. For example, if you wish to retain logs for a shorter period, you can replace the 31 with your desired number of days, such as 7 for retaining a week’s worth of logs.

In this setup, daily ensures that the ModSecurity logs are rotated on a daily basis. The compress directive activates the compression of the old log files to save storage space, while delaycompress delays the compression until the second rotation cycle. The missingok option prevents an error if the log file is missing, and notifempty ensures no rotation if the logfile is empty.

Rotating the logs daily is usually recommended since combing through a large log file encompassing a whole week can be daunting.

Importance of Log Rotation

Setting up log rotation helps you maintain a clean and manageable logging environment for your ModSecurity. It ensures that older logs are systematically compressed and ultimately eliminated, simplifying log analysis and troubleshooting any potential issues. Hence, log rotation is an indispensable part of efficient log management in ModSecurity.

Final Thoughts on the Installation of ModSecurity 2 with Apache and OWASP Core Rule Set on Debian

In conclusion, the installation and configuration of ModSecurity 2 with Apache and OWASP Core Rule Set on Debian 10 (Buster), Debian 11 (Bullseye), or Debian 12 (Bookworm) is a process that requires precision, but the enhanced security it provides makes the effort worthwhile. From the installation and initial configuration of ModSecurity to the integration with the OWASP Core Rule Set, each step bolsters the resilience of your server against malicious web traffic. We delved into the strategies for minimizing false positives, which can be a persistent issue in such a dynamic system, and we addressed the importance of effective log management through log rotation. This knowledge allows you to maintain high security while ensuring a smooth user experience.