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

Introduction

Before we begin talking about how to install ModSecurity 2, OWASP with Apache on Debian 12, let's briefly understand – What is ModSecurity 2 and OWASP?

ModSecurity 2 is an open-source web application firewall (WAF) that helps protect websites from online threats. It acts as a shield, monitoring and filtering web traffic to identify and block malicious activities. ModSecurity 2 ensures website security by defending against common attacks like SQL injection and cross-site scripting (XSS).

OWASP stands for the Open Web Application Security Project. It is a non-profit organization that focuses on improving the security of software and web applications. OWASP provides resources, tools, and guidelines to help developers, security professionals, and organizations build secure applications and protect against common web application vulnerabilities.

In this tutorial, you will install ModSecurity 2, OWASP with Apache on Debian 12. We will also address a few FAQs on how to install ModSecurity 2, OWASP with Apache on Debian 12.

Advantages of ModSecurity 2

1. Enhanced Website Security: ModSecurity 2 protects websites against various attacks, including SQL injection and XSS, boosting overall security.
2. Open-Source and Free: Being an open-source solution, ModSecurity 2 empowers all website owners to use advanced security features without incurring additional costs.
3. Customizable Rules: It allows users to create and modify rules according to their specific security requirements, providing flexibility in protection measures.
4. Real-Time Monitoring: ModSecurity 2 continuously monitors web traffic in real-time, enabling immediate detection and prevention of malicious activities.
5. Active Community Support: The strong community behind ModSecurity 2 ensures regular updates, bug fixes, and a wealth of resources, offering reliable assistance.

Section 1: Install Apache and ModSecurity 2 on Debian 12

Step 1: Update Debian System Packages for ModSecurity 2 Installation

Making sure our Debian system is up-to-date is our first step. By doing this, security risks are reduced, optimal performance is guaranteed, and all current packages are kept up to date. To do this, execute the following command:

sudo apt update && sudo apt upgrade

Once your system has been updated, make sure Apache is installed. If not, install it with the following command:

sudo apt install apache2

Section 2: Import ModSecurity Module PPA with Apache on Debian 12

Step 1: Setting up the Required Repository on Debian

We need to install the ModSecurity Apache Module as our next task. Utilizing the version that isn't the most recent from Debian's default repositories may result in instant problems. Rather, we will install the most recent ModSecurity Module for Apache by importing it from a third-party repository. Digitalwave is the one who maintains this third-party repository, which is well-known for its stable binaries.

Installing the following packages is a good place to start:

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

Next, we import the GPG key from the ModSecurity 2 Module PPA repository:

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

Once the GPG key has been obtained, add the repository to your computer:

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

Now that the repository is operational, the APT policy needs to be modified to give this repository priority over other repositories for particular ModSecurity packages. That's what the following command does:

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

Run an APT update after that to make the newly imported source visible:

sudo apt update

Additionally, you can use the following to validate this policy change and confirm the preferences:

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

Step 3: Install ModSecurity 2 Module on Debian 12

Once the repository is prepared, install the libapache2-mod-security2 module as follows:

sudo apt install libapache2-mod-security2

It is necessary to enable the module after installation. To do this, use the following command:

sudo a2enmod security2

Step 4: Restarting Apache Service

In order to ensure that all modifications take effect and the recently added ModSecurity module is properly integrated, we lastly restart the Apache service:

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

Section 3: Enable ModSecurity 2 Module on Debian 12

Accessing the ModSecurity Configuration File

The /etc/apache2/mods-enabled/security2.conf file is the Apache ModSecurity configuration file. Use the following command to open this file in the text editor of your choice, such as nano:

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

Find the line that says:

IncludeOptional /etc/modsecurity/*.conf

Make sure that other required configuration files from the /etc/modsecurity directory are included in this line, which should not be commented out. By default, it needs to be left uncommented.

Modifying the ModSecurity 2 Configuration for Apache on Debian

To make the configuration file active, we must rename it from modsecurity.conf-recommended to modsecurity.conf. To accomplish this, use the following command:

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

Let's now open the configuration file with this new name:

sudo nano /etc/modsecurity/modsecurity.conf

The default ModSecurity rule engine in this file is set to DetectionOnly. This implies that it won't stop potentially harmful activity; instead, it will recognize and record it. Change this by finding the SecRuleEngine line (around line 7) and replacing DetectionOnly with On to activate ModSecurity's blocking capabilities.

From:

SecRuleEngine DetectionOnly

To:

SecRuleEngine On

Adjusting Log Settings for Apache on Debian

The SecAuditLogParts line is located further down the configuration file, approximately line 224. It is necessary to modify the default setting for this line in order to accurately log all transaction information.

Change:

SecAuditLogParts ABDEFHIJZ

To:

SecAuditLogParts ABCEFHJKZ

After making these adjustments, save your work and close the editor.

Restarting Apache to Apply Changes

Restarting the Apache service is the last step in this process that ensures our ModSecurity configuration changes take effect. The command used to do this is as follows:

sudo systemctl restart apache2

Section 4: Implementing the OWASP Core Rule Set for ModSecurity2 on Debian 12

Your webserver is not secure with just ModSecurity. In order to recognize possible dangers and stop malicious activity, a set of rules is needed. Many webservers and Web Application Firewalls (WAFs) use the well-respected OWASP (Open Web Application Security Project) Core Rule Set (CRS). By implementing this rule set, you can provide your server with strong defense against various online threats.

Make sure you have the most recent version of OWASP CRS by going to the OWASP Release tag page before continuing. By following this step, you can be sure that the security updates for your server are downloaded and installed.

Creating the Parent Directory for OWASP CRS on Debian

Let's first use the mkdir command to create the main parent directory for OWASP:

sudo mkdir /etc/apache2/modsec/

Download OWASP CRS Archive on Debian

The OWASP CRS 3.3.4 archive, which is the most recent stable version, will then be retrieved using the wget command. Recall that you need to confirm the version using the previously mentioned link.

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

Because of its early development state, the nightly build might provide more modern security features, but it might also present problems. It is recommended that novice users stick with the stable version to minimize any potential issues.

Extracting the Archive

We may extract the archive into the directory we previously made after it has been downloaded:

unzip v3.3.4.tar.gz
sudo mv coreruleset-3.3.4/ /etc/apache2/modsec/

Configuring the Rule Set

You should rename the sample configuration file provided by the OWASP CRS, keeping the original as a backup. The cp command can be used to accomplish this:

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

Enabling the Rules

Open the file at /etc/apache2/mods-enabled/security2.conf to activate the rules:

sudo apt install unzip -y

After that, add the next two lines:

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

Moreover, remove comment out the following line:

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

When finished, save the file and close it:

Restarting Apache to Apply Changes

Restarting your Apache service is the final step to make sure the modifications take effect:

sudo systemctl restart apache2

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

The OWASP Core Rule Set (CRS) is an extensive tool with a wide range of adjustable parameters. For the majority of servers, its default configuration instantly improves security while having no effect on real users or Search Engine Optimization (SEO) bots. In this section, we will cover some of the key features of the CRS, but it is always helpful to look through the configuration files to get a full understanding of all the options.

Adjusting the CRS Configuration on Debian with ModSecurity 2

To begin, we open the crs-setup.conf file, which contains the majority of the CRS configuration options:

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

Grasping the CRS Scoring System on Debian with ModSecurity 2

ModSecurity functions in two different ways:

• Anomaly Scoring Mode: This mode, which is advised for most users, gives each time a rule matches a "anomaly score." Following the processing of both incoming and outgoing rules, the anomaly score is examined, and if required, a disruptive action is initiated. Frequently, a 403 error is the result of this action. This mode gives you more freedom to set blocking policies and accurate log information.
• Self-Contained Mode: When a rule matches in this mode, an action is applied immediately. It can use less resources, but it is less flexible and produces audit logs that aren't as educational. When the first rule is satisfied and the designated action is carried out, the rule-matching process comes to an end.

Understanding Paranoia Levels on Debian with ModSecurity 2

Four levels of paranoia are defined by the OWASP CRS:

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

Elevated levels of paranoia make it possible to implement more regulations, boost security, and increase the possibility of false positives blocking legitimate traffic. It's critical to match your degree of paranoia with your level of experience and security requirements.

Testing OWASP CRS on Your Server on Debian with ModSecurity 2

Use your web browser to go to the following URL to make sure your server is running the OWASP CRS correctly. Don't forget to substitute your real domain name for "yourdomain.com":

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

In the event that you encounter a 403 Forbidden error, OWASP CRS is operating as planned. If not, there may have been an error made during setup that needs to be fixed; the most frequent problem is often forgetting to set DetectionOnly to On or a similar value.

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

Handling false positives when utilizing OWASP CRS and ModSecurity is frequently an ongoing endeavor. Nonetheless, the effort is valuable because these systems defend against a variety of threats. We advise starting the process with a low degree of paranoia in order to lower the quantity of possible false positives.

An overpowering surge of false positives can be avoided by running the rule set with few false positives for a few weeks or even months before increasing the paranoia level. By using this technique, you can become accustomed to the system's alerts and learn how to react correctly.

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

A built-in feature of ModSecurity is the ability to whitelist common actions that might unintentionally result in false positives. Take a look at this instance:

#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"

For programs like WordPress, phpBB, and phpMyAdmin, uncomment the corresponding lines and leave the (1) value in place to implement whitelisting. Set the value to (0) for any services that are not in use to stop them from being whitelisted.

The modified setup might resemble this:

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"

Here, unnecessary options have been eliminated, leaving only the proper syntax for the configurations you need.

Creating Rule Exclusions Before CRS Implementation on Debian with ModSecurity 2

Using the cp command, rename the REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf file to begin creating custom exclusions:

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

Recall that in order to prevent errors during Apache2 service testing, every exclusion rule must have a distinct id:<rule number>.

For instance, some REQUEST_URIs might result in false positives. Two such scenarios involving the Google PageSpeed beacon and the WordPress WPMU DEV plugin are shown in the example below:

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"

Permissions will be automatically granted by these rules for any URL that starts with the given path.

Additionally, there are several ways to whitelist IP addresses:

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"

A single IP address is whitelisted in the first rule, and broader subnet matching is achieved with the @ipMatch directive in the second rule. Subnets and IP addresses can be blocked by substituting deny for allow. This degree of flexibility allows you to design complex whitelists and blacklists, and even combine them with Fail2Ban for an even more complete security approach.

Disabling Specific Rules on Debian with OWASP, ModSecurity 2

A different approach is to disable specific rules that consistently result in false positives, rather than whitelisting the entire path. Long-term, this approach may prove to be very advantageous, even though it calls for more time and thorough testing.

Let's say that your team consistently receives unjustified bans and blocks as a result of rules 941000 and 942999 in your /admin/ area. Using the RemoveByID command, you would find the rule ID in your ModSecurity logs and disable only that particular ID:

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

Handling false positives with Apache, ModSecurity, and OWASP requires constant log monitoring. By doing this, you can find patterns that indicate false positives. After these patterns are found, you can develop unique rules to counteract them.

For example, you can create an exclusion rule for those unique cases if you find that certain rules are routinely causing false positives. With this method, possible false positives can be managed more precisely and successfully.

Your apps will run in a more secure and effective environment if you keep a close eye on your logs and adjust your system to fix problems as they appear.

Section 7: Implementing Log Rotation for ModSecurity 2 on Apache and Debian 12

Because web transactions are dynamic, ModSecurity logs can build up quickly, which makes an effective log management plan necessary. One useful feature for efficiently handling these logs in ModSecurity is log rotation, which is not enabled by default. You will find instructions on how to configure log rotation for your ModSecurity in this section.

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

First, a new file made especially for ModSecurity rotation needs to be created. To accomplish this, make a new file called modsec and open it using the nano command:

sudo nano /etc/logrotate.d/modsec

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

Enter the configuration shown below in the newly created modsec file:

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

The system is told to retain the logs for a period of 31 days by this configuration. That being said, you have a great deal of flexibility in modifying the storage duration to suit your needs. For instance, you can change the 31 to any desired number of days to keep logs for a shorter amount of time—for instance, 7 days to keep logs for a week.

The daily setting in this configuration makes sure that the ModSecurity logs are rotated every day. While delaycompress pushes back the compression until the second rotation cycle, the compress directive kicks in the old log files' compression to conserve storage space. If the log file is missing, the missingok option keeps things from going wrong, and if the log file is empty, notifempty makes sure there is no rotation.

Importance of Log Rotation

You can keep your ModSecurity's logging environment organized and manageable by setting up log rotation. It makes sure that older logs are gradually reduced in size and eventually removed, which makes log analysis and potential problem-solving easier. Log rotation is therefore a crucial component of effective log management in ModSecurity.

FAQs to Install ModSecurity 2, OWASP with Apache on Debian 12

Conclusion

We hope this tutorial helped you understand how to install ModSecurity 2, OWASP with Apache on Debian 12.

If you have any queries, please leave a comment below, and we’ll be happy to respond to them for sure.