So, SecruleUpdateActionById requires relisting action flags. At least that's my reading of "actions that can appear only once are overwritten". Which is fairly obvious for most of them, but less so for ctl: or specialty parameters.
I'm currently building this editor GUI, and so I'm wondering which flags from the original SecRule are worth repeating in a SecRuleUpdate.
Other than "can appear only once" the manual gives relatively few hints on flag types. The "Action Group" for instance (Meta-data, Non-/disruptive, Flow, Data) doesn't fully convey which options are repeat/list parameters. So for now I just classify all possible actions like this:
FIXED PARAMS (cannot be changed):
- id
- phase
- chain (sort of, since it shouldn't be changed)
META DATA (no need to retain IMO):
- accuracy, maturity
- rev, ver
- severity, tag
REAL ACTIONS (boolean flags)
- allow, block, pass, pause, deny, drop, status
- auditlog, noauditlog, nolog, log, capture
- skip, skipAfter, multiMatch, xmlns
- msg
LIST ACTIONS (→not to be added twice per SecRuleUpdateAction):
t:***
(only required copying if t:none present)- deprecatevar, expirevar, initcol, setenv, setvar,
UNCLEAR:
- logdata
- setuid:, setrsc:, setsid: → look like variable setting options, thus might appear multiple times
sanitise***
- append:, prepend:, exec:, proxy:, redirect: → though I'm presuming these are single-action flags
ctl:***
So logdata
is really just a variant of the msg
option. But I'm not sure if it can't
appear multiple times (and hence would require omitting from the SecRuleUpdate…). Perhaps
I'm just mislead by log entries collecting multiple "Matched Data:…" entries, and there
aren't any rules with multiple logdata:… options.
exec:
and append:
and thelike I haven't really seen used in the CRS rules
(egrep 'setuid|setsid|prepend|exec:|proxy|redirect' /usr/share/modsecurity-crs/rules/*.conf
).
And I would think they're not iterative, but singular. OTOH the manual says "Non-disruptive", so strictly
speaking "exec", "append" and "prepend" aren't exclusive actions like block/deny/etc.
Much unlike "redirect" and "proxy" seemingly.
But sanitiseArgs/Matched/… or setuid:/setsid:/setrsc: seem similar in scope to setvar:. Yet again it's a little unclear if they would be inherited, or overwritten by a SecRuleUpdateActionById.
The ctl:*
flags seem less crucial, since they're largely boolean flags they're surely
unaffected by SecRuleUpdates.