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

Rules for Dokuwiki. #983

Merged
merged 16 commits into from Feb 5, 2018

Conversation

Projects
None yet
3 participants
@bagley
Contributor

bagley commented Dec 8, 2017

Here are rules to allow Dokuwiki to work with modsecurity. They were in #899 but it was decided to make them their own PR.

Rules for Dokuwiki.
Signed-off-by: Matt Bagley <firstlife22@gmail.com>

bagley added some commits Jan 5, 2018

Better rules for editing pages.
Signed-off-by: Matt Bagley <firstlife22@gmail.com>
Allow the config to be saved.
Signed-off-by: Matt Bagley <firstlife22@gmail.com>
Show the index, even if things like "postgresql" or other things show up
Signed-off-by: Matt Bagley <firstlife22@gmail.com>
Only check login vars if do=login.
Signed-off-by: Matt Bagley <firstlife22@gmail.com>
For performance, only do admin rules if do=admin.
Signed-off-by: Matt Bagley <firstlife22@gmail.com>
Clean up some comments.
Signed-off-by: Matt Bagley <firstlife22@gmail.com>
Remove white spaces
Signed-off-by: Matt Bagley <firstlife22@gmail.com>
@dune73

This comment has been minimized.

Collaborator

dune73 commented Jan 24, 2018

Again, a very decent PR.

The same general remarks I made about #982 apply here as well.

An additional question:

  • 9011200: disabling CRS completely for the username parameter on the login screen looks a bit extreme. Is that really necessary?

And then addresses to everybody: There are deeply chained rules in this PR. Do we want to additional indentation for every level, or stick to a 2nd level in that case?

If you do not have the time, to look into this again @bagley, then I will follow the procedure outlined in #982.

bagley added some commits Jan 24, 2018

Add crs_exclusions_dokuwik=1 to crs-setup.conf.example
Signed-off-by: Matt Bagley <firstlife22@gmail.com>
Condense description at the top of the file.
Signed-off-by: Matt Bagley <firstlife22@gmail.com>
Use tag for attack-injection-php (930000-933999).
Signed-off-by: Matt Bagley <firstlife22@gmail.com>
Don't allow anything on the login username.
Signed-off-by: Matt Bagley <firstlife22@gmail.com>
ruleRemoveTargetByTag=CRS for wikitext/suffix/prefix ARGS on page edits.
Signed-off-by: Matt Bagley <firstlife22@gmail.com>
On page edits, remove 'wikitext' check, and allow 930100 for REQUEST_…
…BODY.

- Also left note about 'summary' arg, but decided not to include it.

Signed-off-by: Matt Bagley <firstlife22@gmail.com>
@bagley

This comment has been minimized.

Contributor

bagley commented Jan 24, 2018

I put a check for dokuwiki's cookies in a lot of the rules. That's probably not needed, and may be slowing it down. Taking those out will shorten the rules/chains. Let me know if those should be taken out.

@bagley

This comment has been minimized.

Contributor

bagley commented Jan 24, 2018

On one rule, I turn off requestBodyAccess if it's a large upload (only on the php file that does the uploading). Is that a good thing to do? Or should that be left to the user's decision?

SecRule REQUEST_FILENAME "@endsWith /lib/exe/ajax.php"\
    "id:9011120,\
...
    SecRule REQUEST_HEADERS:Content-Length "@gt 31486341" \
        "t:none,\
        ctl:requestBodyAccess=Off"
nolog,\
noauditlog,\
chain"
SecRule REQUEST_HEADERS:Content-Length "@gt 31486341" \

This comment has been minimized.

@christiantreutler-avi

christiantreutler-avi Jan 24, 2018

Are you choosing this @gt number for any particular reason?

This comment has been minimized.

@bagley

bagley Jan 24, 2018

Contributor

No. Not anything definite beyond just seeming like a good balance for performance. But starting to think I should just comment it out at the top, for the config, if at all.

This comment has been minimized.

@christiantreutler-avi

christiantreutler-avi Jan 25, 2018

I was actually not referring to removing that rule, but from my experience even running CRS on anything below 32MB seems rather problematic and can cause FPs and long latency/high CPU. But having the default which the user should set anyway should work fine.

This comment has been minimized.

@bagley

bagley Jan 25, 2018

Contributor

Well, that's what I tried before, setting the 'crs_exclusions_dokuwiki_scan_upload=31486341' variable that would respond to a rule setting the upload scan limit, but I couldn't get it to work. It was as if it was being ignored. Is that what you are referring to? I don't think it would be good to hard code it in, as if someone needed to modify it, they'd have to do so each time it was updated.

Or just set crs_exclusions_dokuwiki_scan_upload=0|1 for if uploaded files are scanned or not. And then a simple rule to turn off scanning for uploads.

This comment has been minimized.

@bagley

bagley Jan 25, 2018

Contributor

Option C: Put a note at the top that the user can add to crs-setup.conf or website config.

# If you want to relax the upload restrictions of file types,
# see rule 900240. For Dokuwiki you can limit the exception
# to the ajax.php file:
#
# SecRule REQUEST_FILENAME "@endsWith /lib/exe/ajax.php"\
#    "id:9011120,\
#    phase:1,\
#    t:none,\
#    nolog,\
#    pass,\
#    chain"
#    SecRule REQUEST_COOKIES:/S?DW[a-f0-9]+/ '@rx ^[%a-zA-Z0-9_-]+' \
#      "t:none,\
#      tx.restricted_extensions='.bak/ .config/ .conf/ .db/ .ini/ .log/ .old/ .pass/ .pdb/ .sql/'"
#
# If you have have performance/latency issues on large uploads, 
# you can try disabling scanning of uploaded files (may open security
# holes). Here's an example for crs-setup.conf or your website's config 
# that will only make the exception for uploads (ajax.php)
#
# SecRule REQUEST_FILENAME "@endsWith /lib/exe/ajax.php"\
#    "id:9011121,\
#    phase:1,\
#    t:none,\
#    pass,\
#    nolog,\
#    noauditlog,\
#    chain"
#    SecRule REQUEST_HEADERS:Content-Length "@gt 31486341" \
#        "t:none,\
#        ctl:requestBodyAccess=Off"
#
# And to increase the upload size for only uploaded files (512MB):
#
# SecRule REQUEST_FILENAME "@endsWith /lib/exe/ajax.php"\
#    "id:9011122,\
#    phase:1,\
#    t:none,\
#    pass,\
#    nolog,\
#    noauditlog,\
#    ctl:requestBodyLimit=536870912"
Remove the upload limit for scanned files. Let the user decide on this.
Signed-off-by: Matt Bagley <firstlife22@gmail.com>
@dune73

This comment has been minimized.

Collaborator

dune73 commented Feb 5, 2018

Merging this and moving to fixup afterwards. Will also settle open questions from above.

@dune73 dune73 merged commit b0feead into SpiderLabs:v3.1/dev Feb 5, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@bagley

This comment has been minimized.

Contributor

bagley commented Feb 5, 2018

Thanks for merging this. I also took a look at #1011, tested it, and it worked great.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment