How to create a custom ModSecurity rule to protect the website against brute-force attacks?

Issue

• Imunify360 is installed, ModSecurity and WebShield are enabled.
• The custom web application is used.
• The visitor is allowed to make any number of authentication attempts.

How to write a custom rule to prevent bruteforce attacks?

Environment

• Imunify360
• ModSecurity
• WebShield
• graylist

Solution

1. Start tailing web server log to understand, what values are available when failed access attempt occurs:

   # tail -fn0 /var/log/apache2/example.com-access.log | grep 11.22.33.44

   Where:

   • /var/log/apache2/example.com-access.log is the path to the domain access log;
   • 11.22.33.44 - IP address from which the domain is accessed for the test. The public IP address can be quickly checked at 'https://ifconfig.co/'.

2. Reproduce the issue by accessing the website in the browser and performing unwanted actions (attempt to log in using invalid credentials).

3. Check the output of the 'tail' in the terminal. It should be something like that:

   11.22.33.44 - - [11/Jan/2022:19:02:05 +0700] "POST /index.php?goto=Login&action=cheekLoginID HTTP/1.1" 401 482 "https://example.com/index.php?goto=Login" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36"

   Notice highlighted parts:

   • Type of the request: POST
   • URL (the part after the domain name): index.php?goto=Login
   • Response code: 401

4. Use these details as conditions for the new rule. Here is what we got:

   SecRule RESPONSE_STATUS "@streq 401" "id:88999901,phase:5,chain,pass,log,severity:2,msg:'Custom WAF: Captcha on Login Attempt Failure simtl.kimiafarma.co.id',t:none,tag:'service_i360custom'"
   SecRule REQUEST_METHOD "^POST$" "chain,t:none" 
   SecRule REQUEST_URI "@contains /index.php?goto=Login" "t:none"

   And here how it works:

   • id:88999901 - rule id. For graylisting, Imunify360 only uses rules with ids 779999** and 889999**. Other ids are either ignored or reserved for the Imunify360 ruleset. Warning: make sure that a unique rule id is set. Having the same rule id twice will result in a web server error;
   • pass - means that request will be tracked, but not blocked immediately;
   • severity:2 - the severity level, that allows graylisting after the rule was triggered twice in quick succession;
   • msg:'any test here' - custom message for the log;
   • RESPONSE_STATUS "@streq 401" - first condition. It tracks requests to web servers with response 401 (standard response for failed authentication);
   • REQUEST_METHOD "^POST$" - second condition. It is to make sure that the rule is triggered only for POST requests;
   • REQUEST_URI "@contains /index.php?goto=Login" - the final condition. The rule only triggers for the specific string in the address bar.

5. Locate the configuration file for custom ModSecurity rules:

   # find /etc -type f -name waf-custom.conf
   /etc/sysconfig/imunify360/generic/modsec.conf.d/waf-custom.conf

   Add the created rule to the file, and make sure that the webserver configuration test is passed:

   # apachectl -t

   If there are configuration errors, revert the change and fix the syntax issues (the path for the problem config file and the line number will be provided).

6. Reload webserver to apply config changes:

   # systemctl reload apache2

7. Check if the rule works by reproducing unwanted behavior and tailing both access log and Imunify360 console log:

   # tail -fn0 /var/log/apache2/example.com-access.log /var/log/imunify360/console.log | grep 11.22.33.44

Cause

A rule is absent for the custom application or the common but strongly customized application.

Useful links

How to add Custom ModSec rules on different Panels and IM360 Stand Alone