Nextcloud and the Modsecurity Core Rule Set

I’m wondering if Nextcloud is not seeing any value in Modsecurity and the Core Rule Set?

There is for example a pull request open at CRS development to mitigate the “Nextcloud 20 false-positives” for over a year now. The main reason why it’s not moving is stated clearly in the conversation on github as:

Checked during meeting if there is suddenly somebody who uses NextCloud/Owncloud and could see him-/herself reviewing this PR properly. This is a contributing PR but we are not able to merge since no team member has any experience or time for this.
→ No volunteers for 1975, so let’s keep this open.

I’ve recently started myself to dig a little into Modsecurity rules and which exceptions to the CRS are required to minimize the number of false positives. What became clear very quick is that the collaborative nature, extensibility and flexibility of Nextcloud impose quite a challenge for a Web Application Firewall (WAF) if you don’t want to boldly disable most of the checks to enable a smooth operation.

There is a limited number of threads that deal with this issue but none of them is giving an educated guideline how to tune the rules for Nextcloud without crippling the WAF too much. Of course it is easy to get rid of the false positives by generally disabling the offending rules but a more fine granular approach would be desirable that would limit this to the particular requests we have to expect from Nextcloud.

As an example the HTTP methods allowed by the default CRS configuration are just GET HEAD POST OPTIONS. This set is expanded in the Nextcloud specific rules file REQUEST-903.9003-NEXTCLOUD-EXCLUSION-RULES.conf for various REQUEST_FILENAME, i.e. request paths. With the right knowledge or even some guidelines from Nextcloud developers it would be possible to limit the extension of allowed HTTP methods to the absolute minimum for the paths that require it. However, the reality is that this information is acquired by experience, i.e. trial and error in the field and over time so many REQUEST_FILENAME patterns have accumulated that all of the following HTTP methods will be allowed in general: PUT PATCH CHECKOUT COPY DELETE LOCK MERGE MKACTIVITY MKCOL MOVE PROPFIND PROPPATCH SEARCH UNLOCK REPORT TRACE JSONOP.

This is not so far from completely disabling the rules that check for the allowed HTTP methods at all.
And I’m afraid that the situation could look quite similar for other checks of the CRS.

I think every customer who is using Nextcloud in production would benefit from a small investment of Nextcloud into the further development of the CRS REQUEST-903.9003-NEXTCLOUD-EXCLUSION-RULES.conf file.

Or is the common sense that Nextcloud does in general require opening up a WAF too much to keep it useful?

1 Like