Errors involving Nextcloud and Failure to Change Request Size Limit

[UM-Li]

OS: Debian 11 (bullseye)
ModSecurity version: 3.3.0 (libapache2-mod-security2 package)
Apache version: 2.4.54
Rule sets:

• OWASP CRS that comes with the Debian package
• Nextcloud Rule Exclusions Plugin for OWASP CRS (Repository)

---

Hi, I'm new to ModSecurity so please bear with me. I have a Nextcloud instance on my site at /nextcloud, and am trying to upload a 150 MiB .zip file via the Nextcloud client. For now small files can be uploaded, but this archive fails due to request body size limit. I made two attemps to let the file pass through:

(Apache2 was restarted between every change of the .conf files below.)

1. Adding LocationMatch rules in virtual host definition

In 000-default-le-ssl.conf:

<VirtualHost *:443>
  ...
  <LocationMatch "^/nextcloud">
    SecRuleRemoveById ...
    SecRequestBodyLimit 1073741824
    SecRequestBodyNoFilesLimit 1073741824
  </LocationMatch>
</VirtualHost>

This location-matching regex should be correct since SecRuleRemoveById rules in the same block had taken effect. But apparently the size limit was not changed by this, as I kept getting such errors in modsec_audit.log:

--df911a3d-H--                                                                   
   Message: Request body (Content-Length) is larger than the configured limit (13107200).
   Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client 127.0.0.1] ModSecurity: Request body (Content-Length) is larger than the configured limit (13107200). [hostname "www.um-li.xyz"] [uri "/nextcloud/remote.php/dav/uploads/UM-Li/4195104407/0000000000000001"] [unique_id ...]

The "configured limit" was still 13107200 as defined in /etc/modsecurity/modsecurity.conf.

2. Directly changing modsecurity.conf

I also tried directly changing the size limits in modsecurity.conf:

SecRequestBodyLimit 1073741824
SecRequestBodyNoFilesLimit 1073741824

But the upload failed again, and the log file got flooded by garbled text. It seems the .zip file was piped raw into the log.

---

I'm not sure how to continue. I would like ModSecurity allow large file upload in this particular directory (/nextcloud). Preferrably by setting a direcory-specific exception, since other parts of the site are OK with the more restrictive default limit. What is the best practice to achieve this?

[UM-Li]

Changing size limits in /etc/modsecurity/modsecurity.conf worked after rebooting the server. Now the archive can be uploaded, but I'm still not sure why this doesn't work in virtual host definition.

[martinhsv]

Hello @UM-Li ,

Re: "ModSecurity version: 3.3.0 (libapache2-mod-security2 package)"

Your version of ModSecurity is probably v2.9.x. Given that you mention you are using OWASP CRS, I suspect you are confusing the version of that ruleset (i.e. that the ruleset is version 3.3.0) with the version of the ModSecurity engine.

As to your issue:

I just checked in my own test deployment and, a lower SecRequestBodyLimit in modsecurity.conf was successfully overridden by a higher value that was directly within a <VirtualHost...> element.

However, if the override was within a <LocationMatch...> element within that <VirtualHost...> element, then the override did not occur.

If I recall correctly (and I'm going by memory, since I cannot find a reference to it), there is a slightly obscure conflict between when LocationMatch directives are executed by Apache and when ModSecurity needs the configuration value to have been filled in.

For your use case, one way to handle this could be to use a phase:1 rule with the ctl:requestBodyLimit action to modify the value for the desired REQUEST_FILENAME conditions. Note: you would probably have to include this with your 'regular' ModSecurity rules -- i.e. not within a LocationMatch element since that (I believe) will result in a comparable problem issue in terms execution order (between Apache's execution of the LocationMatch and execution of your new rule).

[UM-Li]

Thanks for looking into this @martinhsv.

Yes I was confused about the versions. ModSecurity is v2.9.3, and the CRS is v3.3.0.

Following your advice I wrote this exception rule:

SecRule REQUEST_FILENAME "@beginsWith /nextcloud" \
    "id:[?],\
     phase:1,\
     pass,\
     nolog,\
     ctl:requestBodyLimit=1073741824"

I see in the wiki there must be an id clause, and a few ranges are available for reservation, but am unsure if there are used ones in these ranges already. How can I check which IDs are available (or used) so that this rule won't conflict with others?

[martinhsv]

Hi @UM-Li ,

When writing custom rules for your own deployment, you can use any integer that you like -- as long as it is not a duplicate of any other rules loaded by that same ModSecurity instance. Startup will fail if there is a duplicate.

However, it can be advantageous to take the published ranges into account. For example avoiding custom rules using ids in the range 200000-299999 will turn out to have been useful if you decide in the future to start using rules published by Comodo.

For my own custom rules I usually select an id that is 5 digits or less, per the first bullet point in the id description in the documentation.

[UM-Li]

Thanks @martinhsv, the rule has taken effect with an ID assigned. The request body still seems large with the file supposedly excluded, and I have to set a large SecRequestBodyNoFilesLimit to let it through.

--bfef111f-H--
Message: Request body no files data length is larger than the configured limit (67108864).. Deny with code (413)
Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client 127.0.0.1] ModSecurity: Request body no files data length is larger than the configured limit (67108864).. Deny  with code (413) [hostname "www.um-li.xyz"] [uri "/nextcloud/remote.php/dav/uploads/UM-Li/435887783/0000000000000002"] [unique_id ...]
Apache-Handler: application/x-httpd-php
Stopwatch: 1676487020140298 10524684 (- - -)
Stopwatch2: 1676487020140298 10524684; combined=4275, p1=2936, p2=0, p3=363, p4=637, p5=339, sr=321, sw=0, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.9.3 (http://www.modsecurity.org/); OWASP_CRS/3.3.0.
Server: Apache
Engine-Mode: "ENABLED"

I wonder:

• Is there an equivalent of ctl:requestBodyLimit for SecRequestBodyNoFilesLimit?
  I tried ctl:requestBodyNoFilesLimit, which got rejected.
• The archive was dumped raw into the audit log before. Is this intended behavior? Could it be ModSecurity cannot separate the file from the request in this case? Please see log entries I posted for a related issue, where the archive was dumped at positions marked with [** RAW DATA **].

[martinhsv]

The entire list of ctl: actions is listed in the manual: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#ctl

The distinction provided by SecRequestBodyNoFilesLimit only works for a POST request where the Content-Type is 'multipart/form-data'.

[UM-Li]

Thanks again for the explanation!