coreruleset: Proposal to include monitoring agents exceptions in a new data file
_Issue originally created by user fzipi on date 2019-10-08 20:31:17. Link to original issue: https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1589._
Type of Issue
New feature.
Description
While working on creating one exception for FP (#1583), the discussion there turned into getting a more holistic approach for monitoring agents.
We can take into account Monit, Nagios, Elasticsearch Metricbeat: anything that does the monitoring exclusively from 127.0.0.1.
For example:
SecRule REMOTE_ADDR "@ipMatch 127.0.01,::1" ...
SecRule REQUEST_HEADERS:User-Agent "@rx %{tx.monitoring_user_agent_rx}" ...
The list of monitoring agent could be read from a data file.
It should not be enabled by default (which was a common concern), and also we may want to add something related to awareness about SSRF by adding these exceptions.
But this is normally a must for anyone that has production server: they will need monitoring.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 29 (18 by maintainers)
Yes, that problem with the tags persists.
If #1886 is adopted, then it’s perfectly OK to use it here of course.
901470 should have the default-UAs empty, should not it? And 901480 should then check for the existence / size of that variable. So unless you define UAs in crs-setup.conf, there is nothing that is disabled.
I like the proposal laid out and I realize, I have been overly defensive above. Sorry. If it’s limited to individual IPs, we should be on the safe ground.
Bonus points for only disabling rules that are commonly triggered by monitoring agents.
Is there sense in limiting this to the HEAD and GET methods?
So all in all, I see this as a useful workaround for a persisting problem.
I like the approach. We should sort the IDs in the
ruleRemoveById. The only thing I see is that we might want to use more tags instead of specific numbers. But in that case, we should have to add additional tags to those rules 🤔User fzipi commented on date 2020-01-31 14:17:29:
Will push soon some of the data I’ve got for this one.
User fzipi commented on date 2019-10-08 22:28:19:
We are going to use only 127.0.0.1.
Forget about anything else.
I’m changing the text above.
User dune73 commented on date 2019-10-08 21:33:19:
Let me iterate this: The examples in 905 disable the rule engine completely. I think this is very dangerous, but it is limited to requests from 127.0.0.1 and you can’t spoof that IP address.
The description above implies this will be used in connection with internet IPs. So imagine a cheap monitoring service being used to ping an online banking system. If you combine this with the disabling of the rule engine, then the security of the monitoring service is the only protection of a backdoor around the WAF that is accessible from that monitoring service. An attacker would thus be able to hijack the monitoring service and then attack the bank via the disabled WAF. The attack would be to hijack the monitoring service and then probe all the configured services if they block standard attacks that CRS blocks. If the behaviour is different depending on the IP, they attackers have discovered an IP backdoor.
User dune73 commented on date 2019-10-08 21:02:43:
That’s why I was reluctant yesterday and what I am reading here makes me nervous.
I do not want attackers to come up with a Burp pluginthat probes user-agents automatically and then based on the right UA disable the rule engine. You probably want to build an additional constraint via the IP address, but I think this is very dangerous and an invitation for configuration errors.
I mean if everybody agrees we need this prepared, when I will let myself be overruled, but I think it has to come with VERY BIG WARNING SIGNS.
User fgsch commented on date 2019-10-08 20:42:29:
I think the idea is checking the ip address, user-agent and some urls. Similar to what we do in 905110, which also falls into this category.