IBM Security Verify

 View Only

How IBM Security Verify Access makes use of Web Application Firewall  (ModSecurity CRS) configuration to enforce DDOS protection

By YUTAKA KANEMOTO posted Wed January 24, 2024 02:27 AM


Co Authored By Tushar Prasad , Nilesh Amrutkar

 IBM Security Verify Access introduced open Source based Web application Firewall Engine called ModSecurity.This capability is available in Verify Access Version 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!")
                Control.trace(5, "WAF01: you are NOT admin. Triggered!")

  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:
    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 "$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 "
    (then you will see the response again)

    Lua Script:


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.