0

I am hosting a nextcloud application on my apache2 production server on which I use modsecurity for hardening.

As modsecurity will detect many requests generated by Nextcloud as false positives, I want to enable the special modsecurity nextcloud exclusions via "tx.crs_exclusions_nextcloud=1". Since I am hosting multiple vHosts/Subdomains on this server and nextcloud has its own one (as well as that its not an option to do such exclusions globally for every subdomain) I want to enable this exclusions via the Apache VirtualHost Config Directory:

<VirtualHost _default_:443>
    ServerName nextcloud.mydomain.tld
    ...
    SecAction "id:x,pass,log,setvar:tx.crs_exclusions_nextcloud=1" #also tried ALL possible combinations of variables (id, log, nolog, pass, ...) etc, please don't assume the issue being here as long as you don't are 100% sure.
    ...
</VirtualHost>

This does not work. And I have completely no clue why. The documentation says this command is usable in the VirtualHost section and I checked the order of the config files being included.
Order:

  • Mod itself being loaded
  • /etc/apache2/mods-enabled/security2.conf
  • /etc/modsecurity/000_modsecurity.conf
  • /etc/modsecurity/001_crs-setup.conf
  • /etc/modsecurity/rules/*.conf | OWASP ModSecurity CRS v3.3.0 <--- Rule definition
  • /etc/modsecurity/002_crs-exclusions.conf <--- Current Hotfix, see below
  • Site-Configs <--- <VirtualHost>

Since the SecAction in VirtualHost does not work and modsecurity is still detecting many nextcloud requests as false positives, I currently use the last file, 002_crs-exclusions.conf, to active the nextcloud exclusions:

SecRule REQUEST_HEADERS:Host ^nextcloud.mydomain.tld$ "id:900130,phase:1,nolog,pass,t:none,setvar:tx.crs_exclusions_nextcloud=1"

which works. Bit I am not satisfied with this solution - I want to use this via the VirtualHost directive, since this should work.

Second issue

Modsecurity blocks the request URI /remote.php/dav/calendars/<user>/personal/<uuid>.ics if a user is trying to update a calendar entry. This is due to the fact that this request has the Header Content-Type: application/xml but no real xml content, which leads modsecurity to a libxml2 parse error. So I want to exclude rule# 200000 (this rule defines that Header Content-Type: application/xml-requests should go through modsecurity's xml-parser) for the URI /remote.php/dav/calendars/.* with SecRuleRemoveById via an <Location> directive:

<Location ~ "/remote.php/dav/calendars/.*">
    Header set LocDebug "works"  #to check if <Location> is applied correctly
    SecRuleRemoveById 200000
</Location>

Result:
Every request going to one of these URIs (loading of the calendar, etc.) have the header LocDebug in them, showing that the rules in <Location ...> are applied successfully - but if the user tries to update the calendar entry (request with malformed xml), the request still fails with HTTP 500 and modsecurity reporting an parsing error - This request has NO LocDebug header, leading me to assume that there is some issue with the order of those actions and commands applied in relation to when the request is actually parsed.
I also tried setting SecRuleRemoveById globally, but this one does completely not work AT ALL.

I tried everything, literally everything and as documented above the order should be no problem.
Does anybody have any idea what I may be doing wrong or where the issue could be? I am clueless.


Technical information:

  • OS: Debian 10 Buster - all packages newest ver.
  • Apache: apache2.4.38-3+deb10u4
  • ModSecurity: libapache2-mod-security2 v2.9.3-1
Jason Aller
  • 3,541
  • 28
  • 38
  • 38
PXLDEV
  • 53
  • 1
  • 8

1 Answers1

3

For the first issue

Your SecAction does not have phase action. In this case the mod_security2 puts the rule/action into the 2nd phase, which is too late imho.

For the second issue

I don't see the reason, why SecRuleRemoveId does not work, it shoudl work. But you can put a SecAction here too, with a ctl:ruleRemoveById=200000.

Dharman
  • 30,962
  • 25
  • 85
  • 135
airween
  • 6,203
  • 1
  • 14
  • 20
  • (Sorry for my late response, I had some personal stuff going on and were busy) First of, thanks for the help. I checked the phase-thing you addressed and (while it may have been a flaw too) it has not fixed the issue. Still not working. I've also exactly copied the example exclusion SecAction from the "crs-setup.conf.example" file of the official github rep. but that works neither. Regarding the second issue i've tried using SecAction as you suggested but that isn't working, too. I am pretty clueless at this point. Do you have any other ideas were the problem could be? – PXLDEV Aug 20 '21 at 14:02