DEV Community

Cover image for Harden Apache2 Server
Tikam Singh Alma
Tikam Singh Alma

Posted on • Edited on

Harden Apache2 Server

#apache2 #aws #django #security

1. Install Mod_Security2 

sudo apt install libapache2-mod-security2 -y
Enter fullscreen mode Exit fullscreen mode

Alternatively install from Github official repository

[https://github.com/SpiderLabs/ModSecurity(https://github.com/SpiderLabs/ModSecurity)

After installing ModSecurity, enable the Apache 2 headers module :

sudo a2enmod headers
Enter fullscreen mode Exit fullscreen mode

After installing ModSecurity and enabling the header module,restart the apache2 service :

    sudo systemctl restart apache2
Enter fullscreen mode Exit fullscreen mode

2. Get OWASP CRS and Configure it

ModSecurity is a firewall and therefore requires rules to function.

So we add the OWASP's CRS - Core Rule Set to harden our server

  1. Remove the default .recommended extension from the ModSecurity configuration file name 
sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.con
Enter fullscreen mode Exit fullscreen mode
  1. With a text editor such as vim, open /etc/modsecurity/modsecurity.conf and change the value for SecRuleEngine to On: 
sudo nano /etc/modsecurity/modsecurity.conf
Enter fullscreen mode Exit fullscreen mode

Add this

SecRuleEngine On
Enter fullscreen mode Exit fullscreen mode

Restart Server

sudo systemctl restart apache2
Enter fullscreen mode Exit fullscreen mode

The OWASP ModSecurity Core Rule Set (CRS) is a set of generic attack detection rules for use with ModSecurity or compatible web application firewalls. The CRS aims to protect web applications from a wide range of attacks, including the OWASP Top Ten, with a minimum of false alerts. The CRS provides protection against many common attack categories, including SQL Injection, Cross Site Scripting, and Local File Inclusion.

To set up the OWASP-CRS, follow the procedures outlined below.

  1. First, delete the current rule set that comes prepackaged with ModSecurity by running the following command:

    sudo rm -rf /usr/share/modsecurity-crs

  2. Ensure that git is installed:

    sudo apt install git

  3. Clone the OWASP-CRS GitHub repository into the /usr/share/modsecurity-crs directory:

    sudo git clone https://github.com/coreruleset/coreruleset /usr/share/modsecurity-crs

  4. Rename the crs-setup.conf.example to crs-setup.conf:

    sudo mv /usr/share/modsecurity-crs/crs-setup.conf.example /usr/share/modsecurity-crs/crs-setup.conf

  5. Rename the default request exclusion rule file:

    sudo mv /usr/share/modsecurity-crs/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /usr/share/modsecurity-crs/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

You should now have the OWASP-CRS setup and ready to be used in your Apache configuration.

3. Configure your server to use Mod_security

  1. Edit the /etc/apache2/mods-available/security2.conf file to include the OWASP-CRS 
cd /etc/apache2/mods-available/security2.conf

<IfModule security2_module>
        SecDataDir /var/cache/modsecurity
        Include /usr/share/modsecurity-crs/crs-setup.conf
        Include /usr/share/modsecurity-crs/rules/*.conf
</IfModule>
Enter fullscreen mode Exit fullscreen mode
  1. Include the SecRuleEngine directive set to On. 
cd to /etc/apache2/your.website.conf

<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        SecRuleEngine On
</VirtualHost>

Or

<IfModule security2_module>
SecRuleEngine On
</IfModule>
Enter fullscreen mode Exit fullscreen mode
  1. Restart the apache2 service to apply the configuration 
sudo systemctl restart apache2
Enter fullscreen mode Exit fullscreen mode
  1. Testing ModSecurity 
curl http://<SERVER-IP/DOMAIN>/index.php?exec=/bin/bash

You'll get 404
Enter fullscreen mode Exit fullscreen mode

4. Enabling HTTP Policy and Paranoia 

cd to /usr/share/modsecurity-crs

$ cd /usr/share/modsecurity-crs
or
$ sudo nano /usr/share/modsecurity-crs/crs-setup.conf
Enter fullscreen mode Exit fullscreen mode

Change Paranoia Level on Paranoia Level Initialization section.

Find this section on

/usr/share/modsecurity-crs/crs-setup.conf

[[ Paranoia Level Initialization ]]

The Paranoia Level (PL) setting allows you to choose the desired level of rule checks that will add to your anomaly scores.With each paranoia level increase, the CRS enables additional rules giving you a higher level of security. However, higher paranoia levels also increase the possibility of blocking some legitimate traffic due to false alarms (also named false positives or FPs). If you use higher paranoia levels, it is likely that you will need to add some exclusion rules for certain requests and applications receiving complex input.

A paranoia level of 1 is default.

In this level, most core rules are enabled. PL1 is advised for beginners, installations covering many different sites and applications, and for setups with standard security requirements.At PL1 you should face FPs rarely. If you encounter FPs, please open an issue on the CRS GitHub site and don't forget to attach your complete Audit Log record for the request with the issue.

Paranoia level 2

This level Includes many extra rules, for instance enabling many regexp-based SQL and XSS injection protections, and adding extra keywords checked for code injections. PL2 is advised for moderate to experienced users desiring more complete coverage and for installations with elevated security requirements. PL2 comes with some FPs which you need to handle.

Paranoia level 3

It enables more rules and keyword lists, and tweaks limits on special characters used. PL3 is aimed at users experienced at the handling of FPs and at installations with a high security requirement.

Paranoia level 4

It further restricts special characters.The highest level is advised for experienced users protecting installations with very high security requirements. Running PL4 will likely produce a very high number of FPs which have to be treated before the site can go productive.

SecAction \
"id:900000,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:tx.paranoia_level=1"
Enter fullscreen mode Exit fullscreen mode

5. HTTP Policy Settings on HTTP Policy Settings Section 

$ sudo nano /usr/share/modsecurity-crs/crs-setup.conf
Enter fullscreen mode Exit fullscreen mode

Section on - [[ HTTP Policy Settings ]]

This section defines your policies for the HTTP protocol, such as: allowed HTTP versions, HTTP methods, allowed request Content-Types forbidden file extensions (e.g. .bak, .sql) and request headers (e.g. Proxy)

These variables are used in the following rule files:

REQUEST-911-METHOD-ENFORCEMENT.conf

REQUEST-912-DOS-PROTECTION.conf

REQUEST-920-PROTOCOL-ENFORCEMENT.conf

HTTP methods that a client is allowed to use.

Default: GET HEAD POST OPTIONS

Example: for RESTful APIs, add the following methods: PUT PATCH DELETE

Example: for WebDAV, add the following methods: CHECKOUT COPY DELETE LOCK

MERGE MKACTIVITY MKCOL MOVE PROPFIND PROPPATCH PUT UNLOCK

Uncomment this rule to change the default.

SecAction \
"id:900200,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:'tx.allowed_methods=GET HEAD POST OPTIONS PUT PATCH DELETE'"
Enter fullscreen mode Exit fullscreen mode

Top comments (0)

Read next

dpaluy profile image

Implement a Secure, Dynamic Domain Approval System for Embeddable Widgets in Ruby on Rails

David Paluy -

tymzap profile image

🍯 Honeypot field: an easy to implement React security technique

Tymek Zapała -

psantus profile image

Aurora Serverless v2 scales to zero.. but how fast?

Paul SANTUS -

franckpachot profile image

Aurora DSQL - Simple Inserts Workload from an AWS CloudShell

Franck Pachot -