Web Application Firewall
Liferay Cloud 5.x.x
Liferay Cloud includes a web application firewall called ModSecurity. It inspects requests sent to the web server against a predefined set of custom rules. This step prevents typical web application real time L7 attacks, like XSS, SQL Injection, and other forms of hijacking attempts that might lead to loss of sensitive information.
When you import third-party rule sets such as the OWASP ModSecurity Core Rule Set (CRS), you must tune those rules for your application. Enabling a full rule set in blocking mode without tuning can block legitimate Liferay DXP requests (for example, the /combo resource loader, login, or Control Panel pages).
Liferay Cloud includes additional network security features, including a private network, public load balancer (Layer 7), and CDN.
Custom firewall rules are not available with shared cluster subscriptions.
Enabling ModSecurity
ModSecurity is disabled by default. To enable it, add the LCP_WEBSERVER_MODSECURITY environment variable to your project repository’s webserver/LCP.json file.
Attack detection rules are only processed if ModSecurity is enabled. You must add your own rules and tune your specific configuration.
To avoid disruptions for legitimate traffic, set LCP_WEBSERVER_MODSECURITY to DetectionOnly and deploy the change first. After testing, checking the logs, and tuning your ModSecurity configuration, when you’ve determined that no functionality will be impacted, you can change the value to On and redeploy it.
These values are allowed for LCP_WEBSERVER_MODSECURITY:
-
On: enables ModSecurity. Attack detection rules are processed.
-
Off: disables ModSecurity. Rules are not processed.
-
DetectionOnly: enables ModSecurity. Rules are processed, but disruptive actions are not executed (block, deny, drop, allow, proxy, or redirect).
The LCP_WEBSERVER_MODSECURITY environment variable is equivalent to ModSecurity’s own SecRuleEngine directive.
Changing ModSecurity’s Configuration
The default ModSecurity settings are recommended. To override the default configuration, 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.
Long, parameter-rich URLs and large form submissions can trigger PCRE or request body size limits in ModSecurity. You can increase these limits by increasing the SecRequestBodyLimit and SecRequestBodyNoFilesLimit values in modsecurity.conf, and updating the SecRuleEngine directive to SecRuleEngine ${LCP_WEBSERVER_MODSECURITY}.
Note that the default size limits are industry-standard limits for firewalls, intended to prevent some kinds of attacks. Increasing these limits also increases your vulnerability to those attacks, so tune this value cautiously.
Copy this example of recommended settings as a starting point for your own modsecurity.conf file. If you use this file, replace the line SecRuleEngine DetectionOnly with this line:
SecRuleEngine ${LCP_WEBSERVER_MODSECURITY}
See the ModSecurity Reference Manual for more information on the allowed settings.
Adding and Tuning Attack Detection Rules
Attack detection rules are not provided by default. You must provide rules according to your specific needs.
Tuning your rule set (including exclusions and anomaly thresholds) is required to prevent major disruptions to your application. Some rule configurations might require Liferay DXP to be recompiled with your rule set. Contact the Liferay Support team for help hardening your rule set.
When you import a generic rule sets such as the OWASP ModSecurity Core Rule Set (CRS), you must tune them to your application first.
This workflow avoids service interruptions when you add a rule set:
-
Test key paths in your Liferay DXP instance with detection-only mode enabled. Sign in and navigate to your site’s pages, any custom applications or forms, and commonly used configuration pages (e.g., in the Control Panel).
For each path you test, check the ModSecurity audit log (
/var/log/modsec_audit.log) for rules that matched and raised anomaly scores. -
Work with your security team to analyze each rule matched in the logs.
Carefully examine each instance to determine if it may indicate a real attack or a false positive for legitimate Liferay requests.
-
Tune the rules in your ModSecurity configuration to remove false positives while blocking real threats.
-
When you finish tuning your rule set, enable ModSecurity in blocking mode.
See the official Core Rule Set documentation for guidance on tuning your rule set. Common tuning options include
-
Adjusting anomaly thresholds using rule
900110(for example, increasing the inbound or outbound anomaly threshold). -
Adding targeted rule exclusions for specific URLs or parameters you can guarantee are safe in your deployment.
For example, this configuration disables a specific rule for the /combo endpoint:
SecRule REQUEST_URI "@beginsWith /combo" \
"id:1000001,phase:1,pass,nolog,ctl:ruleRemoveById=920100"
Work with your security team to assess the risks and comply with your own security policies whenever you change the configuration. Continue to monitor and audit the logs as your application evolves, in case more exclusions or changes are needed.
Using ModSecurity Audit Logs
When enabled, ModSecurity automatically generates audit logs, recording detailed information for all transactions. To view the logged information, open the modsec_audit.log file in your web server’s /var/log directory.
If you configure ModSecurity by providing your own modsecurity.conf file, you can log the information in the web server’s console (where you can download it) instead of modsec_audit.log. Change this line in your modsecurity.conf file:
SecAuditLog /var/log/modsec_audit.log
Replace /var/log/modsec_audit.log with /dev/stdout to print audit logs for each transaction in the console. The audit logs appear once you deploy the change.
If desired, change the audit log format to JSON by adding one line to the modsecurity.conf file:
SecAuditLogFormat JSON