0

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.

enter image description here

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.

1 Answer 1

0

It turns out that exec is a repeat option, but append/prepend for example are not. The rest are sort of what you'd expect.
Made a little table from v2/re_actions.c:

action category argc cardinality
id METADATA 1, 1 ONE
marker METADATA 1, 1 ONE
rev METADATA 1, 1 ONE
msg METADATA 1, 1 ONE
logdata METADATA 1, 1 ONE
accuracy METADATA 1, 1 ONE
maturity METADATA 1, 1 ONE
ver METADATA 1, 1 ONE
severity METADATA 1, 1 ONE
chain FLOW 0, 0 ONE
log NON_DISRUPTIVE 0, 0 ONE
nolog NON_DISRUPTIVE 0, 0 ONE
auditlog NON_DISRUPTIVE 0, 0 ONE
noauditlog NON_DISRUPTIVE 0, 0 ONE
block DISRUPTIVE 0, 0 ONE
deny DISRUPTIVE 0, 0 ONE
status DISRUPTIVE 1, 1 ONE
drop DISRUPTIVE 0, 0 ONE
pause DISRUPTIVE 1, 1 ONE
redirect DISRUPTIVE 1, 1 ONE
proxy DISRUPTIVE 1, 1 ONE
pass DISRUPTIVE 0, 0 ONE
skip DISRUPTIVE 1, 1 ONE
skipAfter DISRUPTIVE 1, 1 ONE
allow DISRUPTIVE 0, 1 ONE
phase DISRUPTIVE 1, 1 ONE
t NON_DISRUPTIVE 1, 1 MANY
ctl NON_DISRUPTIVE 1, 1 MANY
xmlns NON_DISRUPTIVE 1, 1 MANY
capture NON_DISRUPTIVE 0, 0 ONE
sanitiseArg NON_DISRUPTIVE 1, 1 MANY
sanitiseMatchedBytes NON_DISRUPTIVE 0, 1 MANY
sanitizeMatchedBytes NON_DISRUPTIVE 0, 1 MANY
sanitizeArg NON_DISRUPTIVE 1, 1 MANY
sanitiseMatched NON_DISRUPTIVE 0, 0 MANY
sanitizeMatched NON_DISRUPTIVE 0, 0 MANY
sanitiseRequestHeader NON_DISRUPTIVE 1, 1 MANY
sanitizeRequestHeader NON_DISRUPTIVE 1, 1 MANY
sanitiseResponseHeader NON_DISRUPTIVE 1, 1 MANY
sanitizeResponseHeader NON_DISRUPTIVE 1, 1 MANY
setenv NON_DISRUPTIVE 1, 1 MANY
setvar NON_DISRUPTIVE 1, 1 MANY
expirevar NON_DISRUPTIVE 1, 1 MANY
deprecatevar NON_DISRUPTIVE 1, 1 MANY
initcol NON_DISRUPTIVE 1, 1 MANY
setsid NON_DISRUPTIVE 1, 1 ONE
setrsc NON_DISRUPTIVE 1, 1 ONE
setuid NON_DISRUPTIVE 1, 1 ONE
exec NON_DISRUPTIVE 1, 1 MANY
multiMatch NON_DISRUPTIVE 0, 0 ONE
tag METADATA 1, 1 MANY
prepend NON_DISRUPTIVE 1, 1 ONE
append NON_DISRUPTIVE 1, 1 ONE

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.