Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SecRuleScript in chain rules #213

Open
void-in opened this issue Jun 8, 2020 · 4 comments
Open

SecRuleScript in chain rules #213

void-in opened this issue Jun 8, 2020 · 4 comments
Assignees
Labels
nostale The label to apply when an issue is exempt from being marked stale

Comments

@void-in
Copy link

void-in commented Jun 8, 2020

Hi, so I want to execute SecRuleScript as part of a chain rule but the script executes independent of the other rules.

Inside vhost of domain mydomain.com, I have the following:

    modsecurity on;
    modsecurity_rules '
    SecDebugLogLevel 9
    SecDebugLog /var/log/nginx/modsec_debug
    SecRule SERVER_NAME "@streq myotherdomain.com" "id:34443223,phase:1,deny,chain"
      SecRuleScript /tmp/test.lua "deny"
    ';

As you can see, I am deliberately comparing mydomain.com to myotherdomain.com through the @Streq operation and it is failing as can be seen in the corresponding audit logs:

[1635b64bbf696aefbee6836ccd3b6f2c]  [4] (Rule: 34443223) Executing operator "StrEq" with param "myotherdomain.com" against SERVER_NAME.
[1635b64bbf696aefbee6836ccd3b6f2c]  [9] Target value: "mydomain.com" (Variable: SERVER_NAME)
[1635b64bbf696aefbee6836ccd3b6f2c]  [4] Rule returned 0.
[1635b64bbf696aefbee6836ccd3b6f2c]  [9] Matched vars cleaned.
[1635b64bbf696aefbee6836ccd3b6f2c]  [4]  Executing script: /tmp/test.lua.
[1635b64bbf696aefbee6836ccd3b6f2c]  [1]
[1635b64bbf696aefbee6836ccd3b6f2c]  [9] Returning from lua script: The IP Address 1.1.1.1 found in file
[1635b64bbf696aefbee6836ccd3b6f2c]  [9] Running action: log
[1635b64bbf696aefbee6836ccd3b6f2c]  [9] Saving transaction to logs
[1635b64bbf696aefbee6836ccd3b6f2c]  [9] Running action: auditlog
[1635b64bbf696aefbee6836ccd3b6f2c]  [9] Saving transaction to logs
[1635b64bbf696aefbee6836ccd3b6f2c]  [4] Running (disruptive)     action: deny.
[1635b64bbf696aefbee6836ccd3b6f2c]  [8] Running action deny
[1635b64bbf696aefbee6836ccd3b6f2c]  [8] Skipping this phase as this request was already intercepted.

But still the lua script at /tmp/test.lua is executing. Also, since the SecRuleScript is part of a chain rule, we shouldn't be giving any action to the SecRuleScript but if no action is specified, it generates a syntax error.

Just wanted to confirm are we not able to execute SecRuleScript as part of chain rules? The slides at https://www.slideshare.net/RobertRowley/teaching-your-waf-new-tricks although quite dated but it suggests that SecRuleScript can be run as part of a chain rule.

It would be great if we can run SecRuleScript in chain rules since implementing ipMatchFromFile with CIDR format IPs is a pain to implement in plain lua.

Version Info
libmodsecurity and modsecurity-nginx both have been checked out from the repo two days earlier so I believe both are latest master branches.

Thank you very much.

@void-in
Copy link
Author

void-in commented Jun 8, 2020

So after some more research, there is this answer by @spartantri at https://security.stackexchange.com/questions/191164/cookie-operations-using-modsecurity-rules where it is mentioned that perhaps SecRuleScript cannot be part of chain rules? If that is the case, then this issue can be closed. Thanks

@martinhsv
Copy link
Contributor

Hi @void-in ,

At least in v2.9.x, that functionality worked as per your expectation in your original posting.

What you are reporting in v3 may be the result of a bug having crept in. I'll follow up.

In the meantime you could consider the option suggested in that link that you found. Another option could be to use the first rule in your chain as you have it and then use the exec action to execute your lua script.

@github-actions
Copy link

github-actions bot commented Jul 9, 2020

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

@github-actions github-actions bot added the stale label Jul 9, 2020
@zimmerle zimmerle added nostale The label to apply when an issue is exempt from being marked stale and removed stale labels Jul 9, 2020
@github-actions
Copy link

github-actions bot commented Aug 9, 2020

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
nostale The label to apply when an issue is exempt from being marked stale
Projects
None yet
Development

No branches or pull requests

3 participants