How to enable ModSecurity and Check if it's Working (Liferay PaaS)

Note: please note that Liferay has renamed its Liferay Experience Could offerings to Liferay SaaS (formerly LXC) and Liferay PaaS (formerly LXC-SM).

Issue

• How to enable ModSecurity in Liferay PaaS and test whether it is working or not.

Environment  

• Liferay DXP 7.4

Resolution

• Follow the below steps to Enable ModSecurity with OWASP Rules: (Please note that Attack detection rules are not provided by default. You must provide rules according to your specific needs)
  1. Enable the ModSecurity in your environment by adding the LCP_WEBSERVER_MODSECURITY environment variable to the project repository’s webserver/LCP.json file. (Configure value as 'On' for LCP_WEBSERVER_MODSECURITY variable)
  2. Add the OWASP Foundation’s ModSecurity Core Rule Set (CRS) with the help of the below steps:
  
  • Download the rules collection from here.
  • Unzip the files to a temporary folder.
  • Move the rules folder to the project repository /webserver/configs/[ENV]/modsec/
  • Move the crs-setup.conf.example file to the project repository /webserver/configs/[ENV]/modsec/ and rename the file to crs-setup.conf
  • Edit the crs-setup.conf file and add code "include /etc/nginx/modsec/rules/*.conf" to the last line of the file without "".
  3. Finally, commit the changes to the repository and deploy the same.
• To test the OWASP Foundation’s ModSecurity Core Rule Set (CRS) (or check if ModSecurity is Working), you may use a third-party scanning tool - Nikto Web Scanner (GitHub - sullo/nikto: Nikto web server scanner) with the help of the command -  docker run --rm alpine/nikto -h https://webserver-myapp-prd.liferay.cloud/ (Replace https://webserver-myapp-prd.liferay.cloud with your URL) on a Linux-based local machine.
• During the execution of the above command, the Webserver will log messages in the console as below:

ModSecurity: Access denied with code 403 (phase 2). Matched "Operator `Ge' with 
parameter `5' against variable `TX:ANOMALY_SCORE' (Value: `5' ) 
[file "/etc/nginx/modsec/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "80"]
 [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"]
 [data ""] [severity "2"] [ver "OWASP_CRS/3.3.2"] [maturity "0"] [accuracy "0"]
 [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] 
[tag "attack-generic"] [hostname "10.192.2.190"] [uri "/KKPeaADb.axd"]
 [unique_id "1653418308"] [ref ""], client: 200.138.53.22, server: , request: 
"GET /KKPeaADb.axd HTTP/1.1", host: "webserver-myapp-prd.liferay.cloud"

The message above suggests to us that the CRS is working (Hence, ModSecurity is Working). 

Additional Information

• The default ModSecurity settings are recommended. If you want to override these settings, create a modsecurity.conf file in your project repository’s webserver/configs/[ENV]/modsec/ directory.

You must provide all necessary configurations, because it completely overrides Liferay Cloud’s default modsecurity.conf    

• To check the functionality of the ModSecurity, you may use the audit logs as well. It shows which rules are being triggered. To check the content of the log from the web server shell, follow this path: /var/log/modsec_audit.log.
• Enabling ModSecurity
• Adding Attack Detection Rules
• Test whether mod_security is actually working (Please choose to follow this unofficial article at your discretion as it is not the official documentation of Liferay)