ModSecurity Not Working When Using Openlitespeed As Reverse Proxy
- Thread starter gcms7892
- Start date
Hi,
I remember it should work, but I couldn't find the post. If you can reproduce it, please provide the reproduce method to bug@litespeedtech.com so we can take a deeper look.
I remember it should work, but I couldn't find the post. If you can reproduce it, please provide the reproduce method to bug@litespeedtech.com so we can take a deeper look.
I ran into the same issue. OLS 1.6.19 is set up with mod_security globally enabled using the Comodo WAF ruleset.
When a local file is requested during tests, mod_security reports the match and triggers an intervention status code. OLS responses with the new status code. So far, so good.
If the same test is applied to a vhost which has a reverse proxy configured, mod_security does the check and also correctly reports the match and intervention in the server error log, but OLS does not response with the new status code. Instead the reverse proxy request is executed and returned in full, and it seems the mod_security intervention gets completely ignored.
When a local file is requested during tests, mod_security reports the match and triggers an intervention status code. OLS responses with the new status code. So far, so good.
If the same test is applied to a vhost which has a reverse proxy configured, mod_security does the check and also correctly reports the match and intervention in the server error log, but OLS does not response with the new status code. Instead the reverse proxy request is executed and returned in full, and it seems the mod_security intervention gets completely ignored.
Hi @takerukoushirou and @gcms7892
Could you please OLS v1.7.6 or the above version a try?
Upgrade method please follow https://openlitespeed.org/kb/how-to-upgrade-openlitespeed/
Best,
Eric
Could you please OLS v1.7.6 or the above version a try?
Upgrade method please follow https://openlitespeed.org/kb/how-to-upgrade-openlitespeed/
Best,
Eric
@Cold-Egg thank you for the quick reply.
I switched to the edge repository and upgraded to version 1.7.8.
The behaviour is exactly the same, for local files the mod_security intervention works as it should, for requests with a proxy configured mod_security logs an intervention but OLS processes the request unaffected (thus does the proxy request and returns the payload).
I also tried (with version 1.6.19) different hook priorities in case it's a pipeline priority issue, but neither forcing it early with -6000 or late with 6000 changes the behaviour. This also matches the order in the server error log: mod_security intervention is always logged first, followed by the proxy debug headers (cf. bug https://github.com/litespeedtech/openlitespeed/issues/166), thus regardless of the mod_security intervention the request is afterwards processed normally.
It seems to me that mod_security correctly sets the return status code for the request (looking at the source code there is no path for it not to do so after logging the intervention), but the proxy is invoked without checking that condition and then overwrites the response with the data received from the proxy endpoint (I am not familiar enough with the internal architecture to check that or even know where to look for it though).
I switched to the edge repository and upgraded to version 1.7.8.
The behaviour is exactly the same, for local files the mod_security intervention works as it should, for requests with a proxy configured mod_security logs an intervention but OLS processes the request unaffected (thus does the proxy request and returns the payload).
I also tried (with version 1.6.19) different hook priorities in case it's a pipeline priority issue, but neither forcing it early with -6000 or late with 6000 changes the behaviour. This also matches the order in the server error log: mod_security intervention is always logged first, followed by the proxy debug headers (cf. bug https://github.com/litespeedtech/openlitespeed/issues/166), thus regardless of the mod_security intervention the request is afterwards processed normally.
It seems to me that mod_security correctly sets the return status code for the request (looking at the source code there is no path for it not to do so after logging the intervention), but the proxy is invoked without checking that condition and then overwrites the response with the data received from the proxy endpoint (I am not familiar enough with the internal architecture to check that or even know where to look for it though).
Maybe my scenario is different, just tested OLS as a proxy + Apache, and the Mod Security works on v1.7.7.
You might want to raise a ticket to support@litespeedtech.com so we can check further.
Code:
[Module:mod_security] ModSecurity: Warning. detected SQLi using libinjection. [file "/usr/local/lsws/conf/owasp/owasp-modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "45"] [id "942100"] [rev ""] [msg "SQL Injection Attack Detected via libinjection"] [data "Matched Data: n&1 found within ARGS:a: b AND 1=1"] [severity "2"] [ver "OWASP_CRS/3.2.0"] [maturity "0"] [accuracy "0"] [hostname "161.35.190.236"] [uri "/"] [unique_id "161162740382.321211"] [ref "v8,9"]
2021-01-26 02:16:43.269155 [INFO] [58.115.204.46:6355#Example] [Module:mod_security]Intervention status code triggered: 403