Co Authored By Tushar Prasad , Nilesh Amrutkar
Introduction

 IBM Security Verify Access introduced open Source based Web application Firewall Engine called ModSecurity.This capability is available in Verify Access Version 10.0.5.0 onwards. IBM Verify Access makes use of Mod Security as web application firewall (WAF). Verify Access WAF can be configured to protect Web Application based on URL patterns, using "request-match" in [WAF] stanza. This can be useful when Customers would like to invoke WAF depends on such method and URL patterns. But if Customers would like to use some other info, like HTTP Header, cookie, etc., to invoke WAF, you can use HTTP Transformation in Lua for such purpose. In theory, HTTP Transformation is a method to modify request from client/response from backend server to adjust them to your requirement, additionally a new function was added to trigger WAF. Even though you also need to use "request-match" in [http-transformations:<resource-name>], you can add additional conditions to trigger WAF using Lua script. Please note that XSLT can be used for HTTP Transformation as well, but only Lua script can trigger WAF.

 High Level flow chart of steps

1. Modify crs-setup.conf to enable DoS Protection (or whatever you would like to use).
2. Prepare Lua script which invoke Control.triggerWAF()
   This function takes a single string parameter (like "1,2,5"), which is used to specify　the WAF phases for which rules processing should be invoked. An empty string is used to indicate that all phases should be enabled for processing.
3. Define resource name which is associated to the Lua script in webseald-<instance name>.conf
4. Configure request-match in [http-transformations:<resource-name>]
   Please note that Control.triggerWAF() may only be called in the ‘request’ processing phase of the transformation rule and should not be used in the ‘postazn’ or ‘response’ phases.
   
5. Evaluate the behavior in accordance with the logic of your Lua script.

 Actual Steps
To evaluate the behavior, let’s try [[ Anti-Automation / DoS Protection]] of Mod Security. 

1.  Enable DoS Protection
   To enable WAF, Navigate to Web -> Manage:Reverse Proxy, Select an instance
   Manage -> Configuration -> Edit WAF Configuration File
   
   Modify SecRuleEngine to On
   
   Save and Deploy
   
   To enable DoS Protection, Navigate to Web -> Global Settings: Web Application Firewall
   
   crs-setup.conf -> Edit Configuration File
   
   Comment out following part (search DoS Protection):
   
   (to recreate ddos scenario easily, I reduced dos_counter_threshold to 10. This means, if you send 10 requests within 60 seconds twice, then you will be blocked for 600 seconds. You need to send 20 requests to be blocked. Please check detailes in REQUEST-912-DOS-PROTECTION.conf.)
   
   
   
2.  Upload Lua script named WAF01. In this scenario, when you access */env.cgi, if a request was sent without iam=admin cookie, then trigger WAF.
   
   

   Control.trace(5, "WAF01: called for " .. HTTPRequest.getURL())
   local cname="iam"
   if string.match(HTTPRequest.getURL(), "/env.cgi") then
                 if HTTPRequest.containsCookie(cname) and
                   string.match(HTTPRequest.getCookie(cname), "admin") then
              Control.trace(5, "WAF01: you are admin. not triggered!")
         else
               Control.trace(5, "WAF01: you are NOT admin. Triggered!")
               Control.triggerWAF("1,2,5")
         end
   end

   
   
   
   
3. Navigate to Web -> Global Settings: HTTP Transformation
   
   Click New.
   
    Input 'WAF01.lua' and check Lua as Template, then click OK.
   
   Select the newly created script, click Edit,
   
    paste above script and click OK.
   
   
   
4.  Configure HTTP Transformation
   Navigate to Web -> Manage: Reverse Proxy
   Select an instance
   Manage -> Configuration -> Edit Configuration File
   
   Search WAF01 and define resource-name like following:
   
   WAF01 = WAF01.lua
   
   
5. Define request-match like following after [http-transformations] stanza:
   [http-transformations:WAF01]
   request-match = request:GET /jct/*
   (in this case, env.cgi is hosted by /jct junction)
   
   Save, deploy, and restart the web reverse proxy instance.
   
   
6.  Send requests without iam=admin cookie 20 times. You will see 403 Forbidden for the next request.
   
   

   # for i in `seq 1 21`; do curl -u testuser:password1 "http://www.example.com/jct/env.cgi?count=$i"; done

   
   
   
7.  (you will see 403 Forbidden in the last request.)
   After you see the 403 Forbidden, send request with iam=admin cookie. You can access the page.
   
   

   # curl -H 'Cookie: iam=admin' -u testuser:password1 "http://www.example.com/jct/env.cgi
   (then you will see the response again)

   
   Lua Script: https://github.com/IBM-Security/isam-support/blob/master/config-example/webseal/ModSecurity/waf01.lua

Summary

In this topic of discussion, you have learned how to use ModSecurity CRS and IBM Security Verify Access Reverse Proxy to protect Web Application.  As you can see above, you can manage condition when you would like to trigger WAF by using LUA script. Since you can use headers, cookies in LUA script, you can trigger WAF under more detailed condition which cannot be achieved only using [WAF] stanza and request-match entries.