ninja at @prismacsi- human rights activist

ModSecurity WebApp Firewall

Mod Security WAF

It is an open source web application firewall. It generally listens and analyzes HTTP traffic. It acts as intrusion detection (IDS) and blocking (IPS) for web applications.



$ sudo apt-get install libapache2-mod-security
$ sudo a2enmod mod-security
$ sudo /etc/init.d/apache2 force-reload


$ sudo yum install mod_security
$ sudo /etc/init.d/httpd restart

After installing the packages, we will need to configure several configurations for the firewall to function properly. I’ll use Apache as a web service that will explain the Debian operating system today.

After the installation is complete we will start apache2

$ service apache2 restart

Then let’s check our required module with apachectl (a checking tool for HTTP Service).

$ apachectl -M |grep security 

security2_module(shared) Next we’ll make a few changes to our pre-defined configuration file

$ mv /etc/modsecurity/modsecurity.conf{-recommended,}

We make the name of our configuration file modsecurity.conf then open it with our nano editor.

We will make arrangements in 2 rule engines


It is one of the rule engines of the firewall and takes 3 different parameters.

  • On – ( work)
  • Off – (not work)
  • DetectionOnly – (work but no block)

A quality resource written in 2007 is written off by default. I don’t know how long it’s been, but now it’s open by default and it’s used to buffer the answers, analyze them or not. It takes 2 different parameters.

  • On – ( work)
  • Off – (not work)

We find the line that is SecRuleEngine and switch from DetectionOnly to On Download now SecResponseBodyAccess opening On mode Off taking.

Adjusting the size of the data to be retrieved by POST method.

We are restarting our Apache service.

$ service apache2 restart

Immediately thereafter, the log file called modsec_audit.log should be created under /var/log/apache2/ where modsecurity records the traffic that is listening.

Now I’m going to create a php file with security vulnerabilities and then send a payload to the web service to see if it works.

Vulnerability PHP File
$xss = $_GET['a'] 
echo $xss; 

We understand from the code is a very simple Cross Site Scripting (XSS) vulnerability. HTTP GET will retrieve the data from the “a” input that comes with the request and print it to the screen.

Now let’s send a simple XSS payload


The log file on the back, where modsecurity records the traffic, understands that the incoming request has the code under /usr/share/modsecurity/ rules, which detects harmful javascript code to exploit XSS vulnerability, and prevents it by returning 403 responses to the request.

Before moving on to the rule writing phase, I go around the directory where there are some rules and try to understand the event.

I see that there are two different file types: .conf and .data under /usr/share/modsecurity-crs/rules.

There are payload lists in the .data files so that the rule files do not take up much space due to their vulnerability. For example, in the configuration file related to Response and SQL Injection, the anomaly of sqli weakness should be corrupted if the error is based on the screen, while the payload file, ie, file, if something catches the response is blocking.

Example: You have an error in sql syntax - mysql error vs

In a way, it does the job of including payloads in the conf file in another file.


Detailed coming soon

Follow me with twitter @berkdusunur