Has anyone managed to get ModSecurity working successfully with Nextcloud (and Apache)?
I’m running Nextcloud 18.0.5 on Raspbian Buster with Apache/2.4.38 (Raspbian), all works great, and I have ModSecurity working no problem (OWASP ModSecurity Core Rule Set ver.3.2.0). I have installed the NextCloud .conf files (REQUEST-903.9003-NEXTCLOUD-EXCLUSION-RULES.conf & REQUEST-903.9012-NEXTCLOUD-EXCLUSION-RULES.conf) from OWASP ModSecurity Core Rule Set ver.3.1.0.
I regularly up/download 5GB+ files, and I just can’t get it to allow me to do this, regardless of what I set SecRequestBodyLimit or SecRequestBodyNoFilesLimit to. (I also noticed that I can’t dismiss notifications from within the web page view, e.g. Calendar app).
Happy to share my configuration details, but just wanted to see if anyone else had had any luck with this?
I just spent most of the weekend trying to setup NC 21 on Debian Buster with the ModSecurity rules from the Buster repos. They’re broken, flat out broken. No, pulling the latest exclusion rules from Github doesn’t fix it.
Eventually, I took the blue pill and added SecRuleEngine off to that VirtualHost.
I don’t have time to run down all the broken rules and fix them. And I sure don’t want to own NC+MS. There’s no mention of ModSecurity in the Nextcloud documentation, and the NC distribution doesn’t include an EXCLUSION-RULES.conf updated for the current version of the server. This post is the #2 result when searching for “nextcloud modsecurity.” (#1 is an outdated version of the EXCLUSION-RULES.) Support seems to be non-existent, and as each major update seems to need a new set of rules, trying to run ModSecurity with Nextcloud is a exercise in frustration.
Until there is solid support for ModSecurity from the Nextcloud project itself, I can’t recommend using it. Just saying that makes me feel dirty.
I had the same issue and disabled the following security rules:
Then it worked fine. You can check your modsecurity.log file, check the last access requests from your IP which have been blocked and identify the rule ID which is the issue. On my server, Plesk is running - I can simply disabled a set of rules in the web interface. Not where to do that on other servers, but it might help.
You can also simply go for a less strict rule set (the above is for OWASP).
not to necro this post but Its relevant I just got this to work with nc22.2.3 on debian 11 apache2 with modsecurity and the coreruleset.org rulesets.
I ran tail -f /var/log/apache2/error.log to monitor output and then began whitelisting until DAV sync worked and the webdav error went away in the admin warning page. Look at the warning and you will see something in the line that says [id “949110”] , this is the ID to whitelist
To whitelist you edit /etc/apache2/mods-enabled/security2.conf and between
simply add a line
SecRuleRemoveById (insert the error ids you found in the log file separated by a space)
So I ended up with:
SecRuleRemoveById 980120 980130 920350 911100 949110
which is similar to what @bigcookie got so either there are still errors that are going to happen for me or something is different between versions or our respective setups.
Overall it doesn’t seem to hard to setup so far, also this doesnt seem to mess with zoneminder at all if you have that too.
lol - Disabling Rule id 949110 is a funny concept!
If you run the modsecurity Core Rule Set in the default Anomaly Scoring Mode this does basically cripple all the checks by CRS’ REQUEST rules. It is like you had disabled all inbound rules together. OK, you still get the logging but it will never block on anything checked by the inbound rules.
A very good and detailed explanation how the CRS works can be found here: