Saturday, November 10, 2012

Setting up a ModSecurity powered Reverse Proxy


Following the series of my ModSecurity related posts, in this one, I explain how we can set up a reverse proxy that will process all the requests received by any browser and then forward them to the web applications we want to protect. This reverse proxy will be an autonomous VM that is very flexible to deploy in front of numerous web applications. For example, we can write generic ModSecurity rules and then we can copy and apply the VM to multiple places in order to process the requests. Afterwards, we can parameterize each VM according to the application that resides behind it.


I used the following VMs for this demo:
  • Debian 6 64-bit (2 processors, 1024MB RAM), acting as reverse proxy with ModSecurity 2.5.12. Installed Apache version: 2.2.16.
  • OWASP Broken Web Applications VM. Just the guarenteed solution! Download it here.
  • Windows XP Pro with Hacme bank vulnerable web application installed. Installation instructions can be found here.
My aim is to create a reverse proxy that handles more than one web application's requests.
Below, there is a schematic of the VM infrastructure that I have described earlier.



  • Unified Rules. With this architecture we have a VM that is charged with filtering every HTTP request to our web applications and therefore, we can edit the rules and parameterize it in order to filter possibly malicious requests. Core rule sets can be used in order to have a generic protection and, on the meanwhile, we can paramiterize the rules for specific fields and functions of our web applications.
  • Network Security. The security of our network becomes more robust and solid. The web applications are isolated, they receive only HTTP request from the reverse proxy.
  • Cost Free! I have used only freeware software, no money are needed for this architecture and infrastracture.


  • Time Consuming. ModSecurity needs dedicated professionals in order to write rules and parameterize the product.
  • Single point of Failure. ModSecurity VM is a single point of failure, meaning that if VM is down, the web applications will be unavailable and unaccessible.


First of all, we need to install ModSecurity at our Debian VM which will be acting as a reverse proxy. Then we enable it and then we download the OWASP Core Rule Set which can be found here.
More specifically, we follow these steps:
€ > apt-get install libapache-mod-security
€ > a2enmod mod-security
Now, we need to set up the reverse proxy. We create a file at the location /etc/apache2/sites-available and we enable it by creating a soft link to it a the location /etc/apache2/sites-enabled. Below you can see a sample site. This is only a sample, you can parameterize it and customize it as you wish.
LoadModule proxy_module /usr/lib/apache2/modules/
LoadModule proxy_http_module /usr/lib/apache2/modules/
<IfModule security2_module>
        Include /etc/apache2/crs/activated_rules/*.conf
<VirtualHost *:80>
        ServerName modsecurity
        ProxyRequests Off
        ProxyPass               /HacmeBank_v2_Website/
        ProxyPassReverse        /HacmeBank_v2_Website/
        ProxyPass               /owaspbwa/
        ProxyPassReverse        /owaspbwa/

Now, every request to the web applications is examined by ModSecurity and then, proxied to the appropriate IP inside our LAN.


I am going to omit a demo attack to the OWASP BWA VM because I have already examined it on a previous post in my blog. Therefore, the scenario I am going to follow, is to send a simple SQL injection payload to the Hacme Bank web application.

The logs generated by ModSecurity:

[09/Nov/2012:15:19:50 +0200] UJ0C9X8AAQEAAB0xAVcAAAAC 6177 80
POST /HacmeBank_v2_Website/aspx/login.aspx HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Proxy-Connection: keep-alive
Cookie: PHPSESSID=saafok2s1qn7tkf1ln7800isg3; ASP.NET_SessionId=tgsda3mibmrqgluhkzms4u55; CookieLoginAttempts=5
Content-Type: application/x-www-form-urlencoded
Content-Length: 120
And the log that activated the ModSecurity rule:

Message: Warning. Pattern match "(?i:([\s'"`Β΄ββ\(\)]*)?([\d\w]+)([\s'"`Β΄ββ\(\)]*)?(?:=|<=>|r?like|sounds\s+like|regexp)([\s'"`Β΄ββ\(\)]*)?\2|([\s'"`Β΄ββ\(\)]*)?([\d\w]+)([\s'"`Β΄ββ\(\)]*)?(?:!=|<=|>=|<>|<|>|\^|is\s+not|not\s+like|not\s+regexp)([\s'"`Β΄ββ\(\)] ..." at ARGS:txtUserName. [file "/etc/apache2/crs/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "77"] [id "950901"] [rev "2.2.5"] [msg "SQL Injection Attack"] [data " 1=1"] [severity "CRITICAL"] [tag "WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"]
Message: Warning. Pattern match "(?i:\bor\b ?(?:\d{1,10}|[\'"][^=]{1,10}[\'"]) ?[=<>]+|(?i:'\s+x?or\s+.{1,20}[+\-!<>=])|\b(?i:x?or)\b\s+(\d{1,10}|'[^=]{1,10}')|\b(?i:x?or)\b\s+(\d{1,10}|'[^=]{1,10}')\s*[=<>])" at ARGS:txtUserName. [file "/etc/apache2/crs/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "134"] [id "959071"] [rev "2.2.5"] [msg "SQL Injection Attack"] [data "' or 1=1--"] [severity "CRITICAL"] [tag "WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"]
Message: Warning. Pattern match "([\~\!\@\#\$\%\^\&\*\(\)\-\+\=\{\}\[\]\|\:\;"\'\Β΄\β\β\`\<\>].*){4,}" at ARGS:txtUserName. [file "/etc/apache2/crs/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "171"] [id "981173"] [rev "2.2.5"] [msg "Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded"] [data "-"]
Message: Warning. Pattern match "(?i:(?i:\d["'`Β΄ββ]\s+["'`Β΄ββ]\s+\d)|(?:^admin\s*?["'`Β΄ββ]|(\/\*)+["'`Β΄ββ]+\s?(?:--|#|\/\*|{)?)|(?:["'`Β΄ββ]\s*?(x?or|div|like|between|and)[\w\s-]+\s*?[+<>=(),-]\s*?[\d"'`Β΄ββ])|(?:["'`Β΄ββ]\s*?[^\w\s]?=\s*?["'`Β΄ββ]) ..." at ARGS:txtUserName. [file "/etc/apache2/crs/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "217"] [id "981244"] [msg "Detects basic SQL authentication bypass attempts 1/3"] [data "' or 1=1"] [severity "CRITICAL"] [tag "WEB_ATTACK/SQLI"]
Message: Warning. Pattern match "(?i:(?:["'`Β΄ββ]\s*?(x?or|div|like|between|and)\s*?["'`Β΄ββ]?\d)|(?:\\x(?:23|27|3d))|(?:^.?["'`Β΄ββ]$)|(?:(?:^["'`Β΄ββ\\]*?(?:[\d"'`Β΄ββ]+|[^"'`Β΄ββ]+["'`Β΄ββ]))+\s*?(?:n?and|x?x?or|div|like|between|and|not|\|\||\&\&)\s*?[\w ..." at ARGS:txtUserName. [file "/etc/apache2/crs/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "249"] [id "981242"] [msg "Detects classic SQL injection probings 1/2"] [data "' or 1"] [severity "CRITICAL"] [tag "WEB_ATTACK/SQLI"]
Apache-Handler: proxy-server
Stopwatch: 1352467189580612 738276 (1537* 9311 -)
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.5.12 (; core ruleset/2.1.2.
Server: Apache/2.2.16 (Debian)


A reverse proxy running ModSecurity can be used to protect server farms that host critical web applications. This architecture is a low cost that could offer significant security protection if ModSecurity is parameterized correctly.

References - Further reading

1 comment: