Proposal to include monitoring agents exceptions in a new data file

[fzipi]

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.

[dune73]

Thank you for starting to write things up. I'm starting to understand. Yet it's far from complete.

So what do you want to do with these IP ranges and UAs. Are you going to exclude rules based on the User-Agent?

[fgsch]

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.

[dune73]

I do not like the example in 905110 very much, but at least it's limited to 127.0.0.1. I do not see us disabling rules by default based on data that the client controls.

A complete example would help. Need not be complete rules. Only what will the sysadmin put into the variable, what are we going to do with it.

[fgsch]

@dune73 what do you mean? This is exactly what 905110 is doing. I'd assume the rules into this category will follow the same format, but have a different User-Agent and uri.

[fzipi]

I do not think we will have lots of rules getting data from remote monitoring.

If we have remote monitoring, they will be GETting correct URLs with a reasonable User-Agent. That's what I have in nagios/icinga/centreon and sensu right now. I don't know how much of these ones are we blocking now, but I guess not much (basically it works flawlessly).

Sometimes there are some that execute extended check, by connecting to apache mod_status. That's what Monit, Beats and some others do, normally locally (using the IP many times). These are the ones that could have problems, like the reported one.

I think we are talking about the second group for exceptions now, with the idea of getting all siblings in a data file somehow.

[dune73]

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.

[dune73]

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.

[fzipi]

We are going to use only 127.0.0.1.

Forget about anything else.

I'm changing the text above.

[fzipi]

Done. Also, I'm not comfortable with using

        ctl:ruleEngine=Off,\
        ctl:auditEngine=Off"

for these cases.

I think we need to see the common rules that will match, likely 920350, and add the proper ctl. And I would like to see a nice tag for the auditlog.

[dune73]

Thank you. Much better now.

[fzipi]

Will push soon some of the data I've got for this one.