ModSecurity / Apache / Nextcloud

ℹ️ Support
,
1

A quick query…

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?

Thanks very much

3

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.

4

Hello @jlfranklin , @castletonroad ,

I had the same issue and disabled the following security rules:
920350
920300
949110
980130
911100
920230
920420

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).

Hope this helps, regards

5

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
and
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.

6

Hmm
I just setting up the nginx in front of php-fpm with owasp/modsecurity-crs:nginx.

Im currently working with excluding 200002, 200003, 911100, 920420, 921110, 941100, 941130. Disabling 949110 also deactivtes the rule for blocking on dected issue.
Tested with:

curl -H "User-Agent: Nikto" http://localhost/

But I would appreciate an official list of rules to exclude.

7

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:

https://www.netnea.com/cms/apache-tutorial-7_including-modsecurity-core-rules/

1 Like
8

giving this thread new life…

Didn’t see any follow-up and as with all things nextcloud… trial and error… this is where I ended up.

Mod Security v2
libapache2-mod-security2

OWASP CRS v4.6 <---- latest on git
https://github.com/coreruleset/coreruleset

Nextcloud rule exclusions plugin

The directions for CRS installing the plugins was a little vague… here’s what my setup looks like

Reverse Proxy Apache2 but it could probably work for bare metal too

- Install ModSecurity with Apache on Debian/Ubuntu and enable it

install

sudo apt install libapache2-mod-security2

enable modsecurity

sudo a2enmod security2

restart apache

sudo systemctl restart apache2

- Configure the standard setup

rename recommended config file to start using it

sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

default modsecurity setup is detection only, turn it on in the config file

sudo nano /etc/modsecurity/modsecurity.conf

change the line

SecRuleEngine DetectionOnly

to

SecRuleEngine On

that turns on the recommended basic config

restart apache

sudo systemctl restart apache2

! ! ! nextcloud will stop working after you do this because the rule engine is on. for me this resulted in the data directory not loading after login

- Install the latest OWASP Core Rule Set

there are others but this is a free and community maintained one - updated just last month

download - replace v?.?.? with the latest

wget https://github.com/coreruleset/coreruleset/archive/v?.?.?.tar.gz

extract

tar xvf v?.?.?.tar.gz

create a directory to store the CRS files and move the extracted files

sudo mkdir /etc/apache2/modsecurity-crs/

sudo mv coreruleset-?.?.?/ /etc/apache2/modsecurity-crs/

rename the example config

sudo mv /etc/apache2/modsecurity-crs/coreruleset-?.?.?/crs-setup.conf.example /etc/apache2/modsecurity-crs/coreruleset-?.?.?/crs-setup.conf``

- Install Nextcloud plugin (rules exceptions) for ModSecurity

download - replace v?.?.? with latest

wget https://github.com/coreruleset/nextcloud-rule-exclusions-plugin/archive/refs/tags/v?.?.?.tar.gz

extract

tar xvf v?.?.?.tar.gz

there are only two files needed for this, move them to mod security plugin directory

sudo mv nextcloud-rule-exclusions-plugin-?.?.?/plugins/nextcloud-rule-exclusions-before.conf  /etc/modsecurity/plugins/

sudo mv nextcloud-rule-exclusions-plugin-?.?.?/plugins/nextcloud-rule-exclusions-config.conf  /etc/modsecurity/plugins/

- Configure ModSecurity to use the latest CRS and Nextcloud plugin

edit the mod config

sudo nano /etc/apache2/mods-enabled/security2.conf

change the section # Include OWASP ModSecurity CRS rules if installed
from

IncludeOptional /usr/share/modsecurity-crs/*.load

to (the order is important)

IncludeOptional /etc/apache2/modsecurity-crs/coreruleset-?.?.?/crs-setup.conf

IncludeOptional /etc/modsecurity/plugins/nextcloud-rule-exclusions-config.conf

IncludeOptional /etc/modsecurity/plugins/nextcloud-rule-exclusions-before.conf

IncludeOptional /etc/apache2/modsecurity-crs/coreruleset-?.?.?/rules/*.conf

check the apache config before restarting

sudo apache2ctl -t

restart apache after all that is setup

sudo systemctl restart apache2

make sure it’s running

sudo systemctl status apache2

At this point Nextcloud should mostly function as normal. There are a few other notes in the documentation for the modsecurity nextcloud plugin about the nextcloud add-ons/apps that work and don’t.

- Optimizing the setup

I’m not going to do a step by step here yet… There are so many different things to approve from here. I will need to do some testing first. The things I will be looking into are.

  • auto notifications or updates of CRS when a new version is released
  • virtual host/site specific exclusions - eg. using the nextcloud exclusions on just nextcloud
  • adjusting logging parameters for high traffic servers
  • IP whitelisting
  • Known malicious IP blocking with auto updates using something like Honeypot API
1 Like
9

Ok, got host-specific plugin/exclusion working right after posting

in the nextcloud modsecurity plugin config, comment out this section and change to match your server and plugin version

sudo nano /etc/modsecurity/plugins/nextcloud-rule-exclusions-config.conf

edit this section

SecRule &TX:nextcloud-rule-exclusions-plugin_enabled "@eq 0" \
     "id:9508010,\
     phase:1,\
     pass,\
     nolog,\
     ver:'nextcloud-rule-exclusions-plugin/1.2.0',\
     chain"
     SecRule REQUEST_HEADERS:Host "!@your.nextcloud.com" \
        "t:none,\
        setvar:'tx.nextcloud-rule-exclusions-plugin_enabled=0'"

to test you can put in the wrong domain and nextcloud will stop working properly

There are some limitations here. Modsecurity only supports 1GB file uploads as far as I can tell. This might be a problem for some. Would like to find a workaround for this.

1 Like
10

I’m still doing some testing with this and there seem to be some real limitations with large file uploads and other small features. I haven’t circled back around to it yet but plan to at some point.

2 Likes
11

Nice job ! Let me know pls if you have any updates!