Welcome to the ModSecurity-Webserver-Protection repository! This repository provides a step-by-step guide on how to use ModSecurity with Apache2 or Nginx web servers to enhance server security. ModSecurity is a popular open-source Web Application Firewall (WAF) that provides protection against various attacks on web applications.

In this guide, I will explore how to use ModSecurity to protect your web server against SQL injection attacks, cross-site scripting (XSS) attacks, and other common web application attacks. I will also cover how to integrate additional security tools like ClamAV, Chkrootkit, Rkhunter, and Fail2ban to further enhance the security of your web server.

This guide is intended for users who have a basic understanding of Linux server administration and are familiar with Apache2 or Nginx web servers. The guide will provide detailed instructions on how to install and configure ModSecurity and other security tools on your web server, as well as how to integrate them with your web server configuration.

I have created this guide in English and German to make it accessible to a wide audience. The guide is organized into sections that cover the installation and configuration of each security tool and their integration with ModSecurity. We will provide detailed explanations, examples, and screenshots to help you follow along with each step.

I hope that this guide will help you enhance the security of your web server and protect your valuable data. If you have any questions or feedback, please feel free to contact us.

To install ModSecurity on different Linux distributions while using Apache as your web server, follow the steps below.

Note: The instructions provided here assume that you have already installed the Apache web server on your system. Install prerequisite packages:

• Ubuntu/Debian:

sudo apt-get update
sudo apt-get install -y build-essential libtool autoconf automake pkg-config libxml2-dev libcurl4-openssl-dev libpcre3-dev libyajl-dev zlib1g-dev liblmdb-dev

• Fedora:

sudo dnf update
sudo dnf install -y @development-tools libtool autoconf automake pkgconfig libxml2-devel libcurl-devel pcre-devel yajl-devel zlib-devel lmdb-devel

• BSD:

sudo pkg update
sudo pkg install -y autoconf automake libtool pkgconf libxml2 libcurl pcre yajl zlib lmdb

• Arch Linux:

sudo pacman -Syu
sudo pacman -S --needed base-devel libxml2 libcurl pcre yajl zlib lmdb

• Download and build ModSecurity from source:

git clone --depth 1 -b v3/master --single-branch https://github.com/SpiderLabs/ModSecurity
cd ModSecurity
git submodule init
git submodule update
./build.sh
./configure
make
sudo make install

• Download and build the ModSecurity Apache Connector:

cd ..
git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-apache.git
cd ModSecurity-apache
./autogen.sh
./configure --with-libmodsecurity=/usr/local/modsecurity
make
sudo make install

Create a new configuration file for ModSecurity:

sudo nano /etc/apache2/mods-available/modsecurity.conf

Add the following content to the file:
LoadModule security2_module /usr/lib/apache2/modules/mod_security2.so
<IfModule mod_security2.c>
  SecRuleEngine On
  SecRequestBodyAccess On
  SecResponseBodyAccess On
  SecDataDir /var/cache/modsecurity
  IncludeOptional /etc/apache2/modsecurity.d/*.conf
</IfModule>

Create a directory for additional ModSecurity rules:

sudo mkdir /etc/apache2/modsecurity.d

Ubuntu/Debian:

sudo a2enmod modsecurity
sudo service apache2 restart

Fedora:
```bash
sudo ln -s /etc/apache2/mods-available/modsecurity.conf /etc/httpd/conf.modules.d/10-modsecurity.conf
sudo systemctl restart httpd

BSD:

echo 'LoadModule security2_module /usr/local/libexec/apache24/mod_security2.so' | sudo tee -a /usr/local/etc/apache24/httpd.conf
sudo service apache24 restart

Arch Linux:

echo 'LoadModule security2_module /usr/lib/httpd/modules/mod_security2.so' | sudo tee -a /etc/httpd/conf/httpd.conf
sudo systemctl restart httpd

Configure and download the Core Rule Set (CRS):

Install the Core Rule Set:

cd /etc/apache2
sudo git clone https://github.com/coreruleset/coreruleset.git modsecurity-crs

Create a symbolic link to the CRS configuration file:

    sudo ln -s /etc/apache2/modsecurity-crs/crs-setup.conf /etc/apache2/modsecurity.d/crs-setup.conf
    sudo ln -s /etc/apache2/modsecurity-crs/rules/ /etc/apache2/modsecurity.d/rules

Run the following command to test if the configuration is correct:

sudo apachectl configtest

If the output shows "Syntax OK," you can proceed to restart the Apache server:

sudo systemctl restart apache2

Now, ModSecurity should be installed and enabled on your Apache web server. To add custom rules or modify existing ones, you can edit the configuration files located in the /etc/apache2/modsecurity.d/ directory.

Install prerequisite packages:

• Ubuntu/Debian:

sudo apt-get update
sudo apt-get install -y build-essential libtool autoconf automake pkg-config libxml2-dev libcurl4-openssl-dev libpcre3-dev libyajl-dev zlib1g-dev liblmdb-dev git

• Fedora:

sudo dnf update
sudo dnf install -y @development-tools libtool autoconf automake pkgconfig libxml2-devel libcurl-devel pcre-devel yajl-devel zlib-devel lmdb-devel git

• BSD:

sudo pkg update
sudo pkg install -y autoconf automake libtool pkgconf libxml2 libcurl pcre yajl zlib lmdb git

• Arch Linux:

sudo pacman -Syu
sudo pacman -S --needed base-devel libxml2 libcurl pcre yajl zlib lmdb git

• Download and build ModSecurity from source:

git clone --depth 1 -b v3/master --single-branch https://github.com/SpiderLabs/ModSecurity
cd ModSecurity
git submodule init
git submodule update
./build.sh
./configure
make
sudo make install

• Download and build the ModSecurity Nginx Connector:

cd ..
git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git

• Download and compile Nginx with ModSecurity module:

• Download the Nginx source code (replace 1.21.4 with the desired version number):

wget https://nginx.org/download/nginx-1.21.4.tar.gz
tar -xvzf nginx-1.21.4.tar.gz
cd nginx-1.21.4

./configure --add-dynamic-module=../ModSecurity-nginx
make
sudo make install

Create a ModSecurity configuration file (e.g., /etc/nginx/modsecurity.conf) and add the basic ModSecurity configuration:

SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess On
SecResponseBodyMimeType text/plain text/html text/xml application/octet-stream
SecDataDir /var/cache/modsecurity
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus ^(?:5|4\d[^4])$
SecAuditLogParts ABIJDEFHZ
SecAuditLogType Serial
SecAuditLog /var/log/modsecurity_audit.log

Edit your Nginx configuration file (usually located at /usr/local/nginx/conf/nginx.conf or /etc/nginx/nginx.conf) and add the following inside the http block:

modsecurity on;
modsecurity_rules_file /etc/nginx/modsecurity.conf;

Additionally, add the following line inside the location block where you want to enable ModSecurity:

modsecurity_rules_file /etc/nginx/modsecurity_rules.conf;

Install the Core Rule Set:

cd /etc/nginx
sudo git clone https://github.com/coreruleset/coreruleset.git modsecurity-crs

Create a new Nginx configuration file (e.g., /etc/nginx/modsecurity_rules.conf) and include the CRS rules:

    include /etc/nginx/modsecurity-crs/crs-setup.conf;
    include /etc/nginx/modsecurity-crs/rules/*.conf;

Test the Nginx configuration:

Run the following command to test if the configuration is correct:

sudo nginx -t

If the output shows "configuration file test is successful," you can proceed to restart the Nginx server:

        sudo nginx -s reload

Now, ModSecurity should be installed and enabled on your Nginx web server. To add custom rules or modify existing ones, you can edit the configuration files located in the /etc/nginx/modsecurity.d/ directory.

These rules scan submitted files for malware by using the "clamscan" command from ClamAV. If a virus is found, the file is blocked and a warning message is issued.

The rules in lines 10-13 scan the uploaded file using ClamAV and block the file if a virus is found. The rules in lines 14-19 allow the upload of files that do not need to be scanned, such as PDF, DOC, and XLS files. The rule in line 20 allows the upload of files that have the "multipart/form-data" content type, which is commonly used for file upload forms.

To configure ModSecurity to use ClamAV as the anti-virus engine, follow these steps:

SecRule FILES_TMPNAMES "@inspectFile /usr/bin/clamscan" \
    "id:12345,\
    phase:2,\
    t:none,\
    block,\
    msg:'Virus found in file',\
    severity:'CRITICAL',\
    chain"

SecRule FILES_TMPNAMES "!@clamav_scan" \
    "id:12346,\
    phase:2,\
    t:none,\
    pass,\
    chain"

SecRule FILES_TMPNAMES "!@rx \.pdf$" \
    "id:12347,\
    phase:2,\
    t:none,\
    pass,\
    chain"

SecRule FILES_TMPNAMES "!@rx \.doc$" \
    "id:12348,\
    phase:2,\
    t:none,\
    pass,\
    chain"

SecRule FILES_TMPNAMES "!@rx \.xls$" \
    "id:12349,\
    phase:2,\
    t:none,\
    pass"

SecRule REQUEST_HEADERS:Content-Type "!@rx ^multipart/form-data" \
    "id:12350,\
    phase:1,\
    t:none,\
    pass"

The comments in the code explain what each rule does. You can customize these rules based on your specific needs. Save the file and restart Apache:

sudo systemctl restart apache2

With these steps, you have configured ModSecurity to use ClamAV as the anti-virus engine. You can now upload files to your server and ensure that they are automatically checked for malware. If you want every file uploaded to your server to be automatically checked for malware, you can make the following changes to the rules in the ModSecurity configuration file:

Change the rule in line 14 from:

SecRule FILES_TMPNAMES "!@clamav_scan" \

to:

SecRule FILES_TMPNAMES "!@inspectFile /usr/bin/clamscan" \

This will cause every uploaded file to be scanned with ClamAV, regardless of its file type. Remove the rules in lines 15-19 that allow the upload of specific file types. This will ensure that all uploaded files are scanned.

Save the file and restart Apache:

sudo systemctl restart apache2

With these changes, ModSecurity will be configured to scan every uploaded file with ClamAV, regardless of its file type. This will ensure that all files are checked for malware before being stored on your server.

Configure ModSecurity to use ClamAV. Here is an example configuration that you can use:

SecRule REQUEST_BODY \
  "@clamav_scan" \
  "id:12345,\
  phase:2,\
  t:none,\
  block,\
  msg:'Virus found in file',\
  severity:'CRITICAL'"

This rule scans the request body with ClamAV and blocks the request if a virus is found. You can customize this rule based on your specific needs.

Configure Nginx to use ModSecurity. Here is an example configuration that you can use:

http {
  ...
  modsecurity on;
  modsecurity_rules_file /path/to/modsecurity.conf;
  ...
}

This configuration enables ModSecurity and specifies the location of the ModSecurity configuration file. You can customize the file path based on where you saved the configuration file.

Save the configuration file and restart Nginx:

sudo systemctl restart nginx

With these steps, you have configured ModSecurity to use ClamAV to scan files for malware in Nginx. You can now upload files to your server and ensure that they are automatically checked for malware.

Here are the general steps you can follow:

• Install Fail2ban on your system. The installation process will vary depending on your operating system.

• Configure Fail2ban to read the ModSecurity audit log. You can do this by creating a new Fail2ban jail configuration file that specifies the location of the audit log file. Here is an example configuration file for

• Apache:

[modsec]
enabled  = true
filter   = modsec
logpath  = /var/log/apache2/modsec_audit.log
maxretry = 1

And here is an example configuration file for Nginx:
```bash
[modsec]
enabled  = true
filter   = modsec
logpath  = /var/log/nginx/modsec_audit.log
maxretry = 1

These configurations enable the modsec jail and specify the location of the ModSecurity audit log file.

• Create a Fail2ban filter to parse the ModSecurity audit log. You can create a new filter file in the Fail2ban filter.d directory that contains regular expressions to match the relevant log entries. Here is an example filter file:

[Definition]
failregex = .*ModSecurity:.*\[id "(?P<id>\d+)".*\] .*\
            Message: Access denied.*\
            Action:.*\
            .*\
            Data: .*\
            Status: (?P<status>\d+)

This filter matches ModSecurity log entries that indicate a request was denied due to a ModSecurity rule. You can customize this filter based on your specific needs.

• Configure Fail2ban to use the new filter. You can do this by adding the new filter to the jail.local file. Here is an example configuration for Apache:

[modsec]
enabled  = true
filter   = modsec
logpath  = /var/log/apache2/modsec_audit.log
maxretry = 1

And here is an example configuration for Nginx:

[modsec]
enabled  = true
filter   = modsec
logpath  = /var/log/nginx/modsec_audit.log
maxretry = 1

These configurations enable the modsec jail and specify the location of the ModSecurity audit log file. You can customize the logpath based on where your ModSecurity audit log file is stored.

• Restart Fail2ban to apply the new configuration:

sudo systemctl restart fail2ban

With these steps, you have configured Fail2ban to work with ModSecurity on both Apache and Nginx. When a request is blocked by ModSecurity, Fail2ban will read the audit log and ban the IP address that made the request.

Chkrootkit is a tool for checking if a system has been compromised by rootkits. While it is not directly related to ModSecurity, you can use it alongside ModSecurity to enhance the security of your web server.

Here are the general steps you can follow to use Chkrootkit with ModSecurity on both Apache and Nginx:

• Install Chkrootkit on your system. The installation process will vary depending on your operating system.

• Create a new ModSecurity rule to check for Chkrootkit warnings. You can create a new rule that checks for the presence of specific strings in the output of the Chkrootkit command. Here is an example rule:

SecRule ARGS "@rx /usr/bin/chkrootkit" \
  "id:12346,\
  phase:2,\
  t:none,\
  pass,\
  chain"
SecRule RESPONSE_BODY "@rx Warning: Possible \(hacker|trojan|worm\) rootkit activity detected" \
  "id:12347,\
  phase:4,\
  t:none,\
  block,\
  msg:'Possible rootkit activity detected',\
  severity:'CRITICAL'"

This rule checks for the presence of the Chkrootkit command in the request arguments, and then checks for the presence of specific warning strings in the response body. If a warning is detected, the rule blocks the request and generates a critical severity message.

• Configure ModSecurity to use the new rule. You can add the new rule to the ModSecurity configuration file, and then reload the configuration to apply the changes.

• Run Chkrootkit regularly to scan for rootkits on your system. You can set up a cron job to run Chkrootkit on a regular basis and send the output to a log file.

• Configure ModSecurity to read the Chkrootkit log file. You can create a new Fail2ban filter that parses the Chkrootkit log file and triggers a ban if specific warning strings are detected.

• Restart your web server to apply the ModSecurity configuration changes.

With these steps, you have configured ModSecurity to work with Chkrootkit on both Apache and Nginx. When a warning is detected by Chkrootkit, ModSecurity will block the request and log a critical severity message. Additionally, you can configure ModSecurity to work with a Fail2ban filter that reads the Chkrootkit log file and triggers a ban if specific warning strings are detected.

RKHunter (Rootkit Hunter) is a tool for checking if a system has been compromised by rootkits. Similar to Chkrootkit, you can use RKHunter alongside ModSecurity to enhance the security of your web server.

Here are the general steps you can follow to use RKHunter with ModSecurity on both Apache and Nginx:

• Install RKHunter on your system. The installation process will vary depending on your operating system.

• Create a new ModSecurity rule to check for RKHunter warnings. You can create a new rule that checks for the presence of specific strings in the output of the RKHunter command. Here is an example rule:

SecRule ARGS "@rx /usr/bin/rkhunter" \
  "id:12348,\
  phase:2,\
  t:none,\
  pass,\
  chain"
SecRule RESPONSE_BODY "@rx Warning: (System\(s\) may have been compromised|Warning: Application\(s\) using \/tmp|Warning: Hidden file found)" \
  "id:12349,\
  phase:4,\
  t:none,\
  block,\
  msg:'Possible rootkit activity detected',\
  severity:'CRITICAL'"

This rule checks for the presence of the RKHunter command in the request arguments, and then checks for the presence of specific warning strings in the response body. If a warning is detected, the rule blocks the request and generates a critical severity message.

• Configure ModSecurity to use the new rule. You can add the new rule to the ModSecurity configuration file, and then reload the configuration to apply the changes.

• Run RKHunter regularly to scan for rootkits on your system. You can set up a cron job to run RKHunter on a regular basis and send the output to a log file.

• Configure ModSecurity to read the RKHunter log file. You can create a new Fail2ban filter that parses the RKHunter log file and triggers a ban if specific warning strings are detected.

• Restart your web server to apply the ModSecurity configuration changes.

With these steps, you have configured ModSecurity to work with RKHunter on both Apache and Nginx. When a warning is detected by RKHunter, ModSecurity will block the request and log a critical severity message. Additionally, you can configure ModSecurity to work with a Fail2ban filter that reads the RKHunter log file and triggers a ban if specific warning strings are detected.

There are many community-driven projects and resources available online that provide advanced and secure ModSecurity rule files that you can use as a starting point. Here are a few examples:

• OWASP ModSecurity Core Rule Set (CRS): This is a set of rules that are designed to provide basic security protections for web applications. The CRS is continuously updated and maintained by the OWASP ModSecurity Core Rule Set Project, and is available on GitHub.

• Comodo ModSecurity Rules: Comodo is a security company that provides a set of ModSecurity rules that are designed to provide advanced security protections for web applications. These rules are available for free on their website.

• Atomicorp ModSecurity Rules: Atomicorp is a security company that provides a set of ModSecurity rules that are designed to provide advanced security protections for web applications. These rules are available for free on their website.

When using any ModSecurity rule file, it is important to understand the rules and customize them to fit your specific use case.

Copyright Volkan (Sah) Kücükbudak