SecRuleUpdate*ById not working inside VirtualHost scope

[derhansen]

The documentation shows, that SecRuleUpdateTargetById can be used in any scope.

The config for my vhost looks like this:

<VirtualHost *:80>
  SecRuleUpdateTargetById 973020 !REQUEST_COOKIES
  ... 
</VirtualHost>

As soon as I restart the Apache with the SecRuleUpdateTargetById inside the virtualhost config, Apache refuses to start and claims the following error message

Updating target by ID with no ruleset in this context

I'm using the latest version of ModSecurity and the OWASP CRS.

Is this a bug, is the documentation wrong or am I missing something?

[brenosilva]

SecRuleUpdateTargetById runs before the merge of contexts. So it works under VirtualHost but the rule should be present in the same context:

<VirtualHost :80>
#include "rules/.conf"
SecRuleUpdateTargetById 973020 !REQUEST_COOKIES
...

We need to improve it by making this directive run after the merge.

Consider use ctl:removeTargetById

Thanks

[marcstern]

Any news on this?
This is a major ennoyance

[derhansen]

The same applies to "SecRuleUpdateTargetByTag", which also does not work inside a VirtualHost scope

[marcstern]

Any plan to fix this?
Using ctl:removeTargetById is not always possible, especially in a shared environment where you can only add rules after the default ones.
The behavior should be, for any location:

• remove the rule with specified id
• create a new version of that rule (same id) with the exception

[odesk2dot2by]

Main problem:
ctl:removeTargetById doesn't know how to work with regex . For instance:

ctl:ruleRemoveTargetByID=981248;ARGS:widget-text[4][text] - OK
ctl:ruleRemoveTargetByID=981248;ARGS:/^widget/ - BAD

[odesk2dot2by]

This situation not problem, need trick with chains. However so as ctl action doesn't uses macros, you can make so:

  # For -> ARGS_NAMES:columns[numbers][text][text]
  SecRule REQUEST_URI "@rx ^/admin/path.*" \
                       "id:'1013',phase:1,t:none,log,chain,\
                        msg:'MATCHED_VAR_NAME - %{MATCHED_VAR_NAME}'"
  SecRule ARGS_NAMES  "@rx columns\[[0-9]+\]\[[a-z]+\]\[[a-z]+\]" "ctl:ruleRemoveByID=981173"

If add some small patch and make recompilation of module, then results may be more restrictive. In this case we could make exception for each MACHED_VAR_NAME exactly.

 SecRule ARGS_NAMES  "@rx columns\[[0-9]+\]\[[a-z]+\]\[[a-z]+\]" \
                                        "ctl:ruleRemoveTargetByID=981173;%{MATCHED_VAR_NAME}"

best regards, Andrei
upwork.link

[syragon]

This situation not problem, need trick with chains. However so as ctl action doesn't uses macros, you can make so:

  # For -> ARGS_NAMES:columns[numbers][text][text]
  SecRule REQUEST_URI "@rx ^/admin/path.*" \
                       "id:'1013',phase:1,t:none,log,chain,\
                        msg:'MATCHED_VAR_NAME - %{MATCHED_VAR_NAME}'"
  SecRule ARGS_NAMES  "@rx columns\[[0-9]+\]\[[a-z]+\]\[[a-z]+\]" "ctl:ruleRemoveByID=981173"

If add some small patch and make recompilation of module, then results may be more restrictive. In this case we could make exception for each MACHED_VAR_NAME exactly.

 SecRule ARGS_NAMES  "@rx columns\[[0-9]+\]\[[a-z]+\]\[[a-z]+\]" \
                                        "ctl:ruleRemoveTargetByID=981173;%{MATCHED_VAR_NAME}"

best regards, Andrei
upwork.link

This does not work in ModSecurity 2.9 and Apache. Am able to log a %{MATCHED_VAR} and %{MATCHED_VAR_NAME}, so it detects the array fine, but ctl does not appear to be taking %{MATCHED_VAR_NAME} or %{MATCHED_VAR} when it's passed to it. The only solution was moving rules to the global config outside the VirtualHost. Really bad. Not impressed with Modsecurity team, so many open issues and bugs like this for years. It blows my mind that ctl:ruleRemoveTargetById does not simply accept regex in the target name - most websites make use of arrays and other dynamically named REQUEST variables.

[zimmerle]

SecRuleUpdate*ById is no longer an issue with version 3.0.

[henkworks]

It is great to read that this bug is fixed. At least in theory. Considering that this fix only exists in modsec3 which is a completely different product (quote from the mainpage: »Libmodsecurity is a complete rewrite of the ModSecurity platform« »It is no longer just a module.«) and especially that there is no connector for apache (https://github.com/SpiderLabs/ModSecurity-apache »This project should be considered under development and not production ready. The functionality is not complete and so should not be used. With Apache HTTP Server, the recommended version of ModSecurity is v2.9.x.«), in practice I consider it misleading to mark this bug fixed for most users of modsec.

Please reopen this bug and fix it in modsec2.

(For the future: please consider finding a new name, not just increasing the version number, if you create a new product.)