Introduction to ModSecurity

To begin I will address the installation of mod_security, which is a web application firewall, also known as WAF.
The mod_security is now supported by the SpiderLabs (http://blog.spiderlabs.com/), sustained by Truswave blog, one of the giants of the security team.
The mod_security is an opencsource WAF in my opinion loses nothing to the owners. He has paid some rules, developed by the staff of SiperLabs and has rules available for free on the OWASP site, but our intention is not to take anything but ready to understand how the tool works, to create our own rules.

In this first article, we discuss the design, operation and installation of mod_security, already in the next we will see the integration of it with the two leading opencsource web servers.

Let's start by listing where mod_security can help us:

- Real time accesses and attempts to circumvent our application.
- Virtual patching protecting our application until the team of developers can fix a possible failure.
- Log all HTTP traffic
- Continuous evaluation of safety through safety testing and analysis of logs, we can know if our application this vulnerable before a third party.
- Hardening web application.

Installation Options

The mod_security can be installed directly on the web server or can be used with the reverse proxy.

- On the web server, it would be the best choice for those who already have their network architecture and not want to change. The weakness of this choice would be the administration of resources, since mod_security would share these resources with the system.
- As a reverse proxy, in my opinion the best choice, because you are so full isolating your network and does not compromise the web server resources.

Main features
- Parsing
- Buffering
In the default installation, mod_security the request and response, which can change both before completing the action causes buffer.
- Logging
All transactions are logged, so you can make an analysis, if needed
- Rule Engine
The rules, we can say that are the heart of mod_security therefore are responsible for the executions of the locks.
A code example of rule: SecRule ARGS "<script>" log, deny, status: 404

the Rules

By default rules follow the following sequence:
SecRule VARIABLE OPERATOR ACTION

Variables, mod_security will tell where to look. In our example was used to ARGS variable, which tells mod_security to look at all the parameters of request
Operator will tell mod_security, what to look for. In our example we have the string JS <script>, used in XSS attacks.
Shares, will tell mod_security action you should take, if the previous condition is true. In our example mod_security log in will register, will deny access and give the answer as 404 status.
Flow

We can divide the rules into 5 phases, where each phase specifies the mod_security runs the rule set to the same.
1 Request headers
2 Request body
3 Response headers
4 Response body
Logging 5-
- In phases of request mod_security makes analysis of requests and applies the rules according to what was configured, it is for header or body and then passes to a request to webserver
- In response phases of mod_security is the analysis of the webserver response, the request sent both to header as to body and then passes the response to the client.
- At the time of logging, mod_security to say how we want the requests and responses are recorded in the log.


Installation (The installation is based on RedHat )

First we will install all dependencies
- Yum install gcc make curl-devel libxml2 libxml2-devel httpd-devel pcre-devel

For installing mod_security, we use git (yum install git), and download the latest version of the project.
- git clone git: //github.com/SpiderLabs/ModSecurity.git
- cd ModSecurity
- ./autogen.sh
- ./configure
- make
- make install


Ready, we completed our installation. Next week we will see how to integrate mod_security the webserver.
@l0c4lh05t