networking, nextcloud, nextcloudpi, raspberrypi, security

ModSecurity Web Application Firewall for NextCloud

There is little point in going through all the trouble of setting up and hosting your own private cloud if it is not properly protected.

Running your own service means that you are the sole responsible for its management and security.

Having a vulnerable setup poses the risk of your most private data being exposed which beats the whole purpose of using NextCloud to have control of your sensitive data.

NextCloudPi already offers a number of security features:

On top of that, we are going to install and set up Apache ModSecurity.

ModSecurity is a Web Application Firewall (WAF) that it monitors all requests the web server receives. At the most basic level, it monitors for attack patterns or known possible vulnerabilities and blocks anything suspicious at the web server level.

We are talking serious protection here. It is really restrictive and ruthlessly blocks anything that potentially smells bad to the point that it is 90% going to break your website.

It is a complicated beast that takes patience to set up, as you have to audit each one of the potential vulnerabilities and allow them in the WAF, or ideally, have them fixed in the application.

I will refer you to the links for the gory details. I will just explain what changes I had to go make for NextCloud to work with ModSecurity.

Enable HTTP2 and disable old versions of HTTP

Enable HTTP operations used by WebDav (PROPFIND)

Enable anomaly scoring mode

This mode of operation is more flexible, as it allows all rules in the CRS to participate in the decision of denying a request. This is opposed to the traditional mode where the first rule that matches the request results in denial. In this mode rules can affect each other and the result is a more powerful decision engine. See the links below for more information.

Whitelist rules

I tested NextCloud under normal usage and whitelisted those false positives that I know are not result of a hacking attempt. I just used the most basic setup for this first release, the whitelisting process can be done in a more sophisticated way but this is fine for now.

Hide Server Signature

This is not strictly necessary for NextCloud to work with ModSecurity, but it is nice to hide your server version and operating system to potential attackers. Security through obscurity won’t take us far by itself but at least we won’t make it THAT easy to fingerprint us.

Usage

This is highly experimental at this point. Most likely as people install different NextCloud Apps things will break, so I recommend to disable it whenever we are changing things, then enable it again withΒ  sudo nextcloudpi-configΒ  to see that everything is fine.

If anyone finds things that are broken, the place to look is

If people find more rules that need whitelisting, please send a PR or report them on the github issues page of the project. Log captures are normally all we need.

It is disabled by default.

Installation

Get it already made

I have included this in the latest release of my NextCloudPi, a ready to use Raspbian 8 image featuring NextCloud 11, HTTP2, PHP7 and more.

Follow the instructions provided. Once up and running, from your Raspberry Pi write

Do it yourself

First, clone the repo

Online installation through SSH

Use the generic software installer with the script modsecurity.sh

Adjust to the IP address of your server.

This process is optimized for the Raspberry Pi, but should work in any system that certbot supports. If you are not using the default username and password for the Raspberry Pi, you can specify username and/or password in the command line.

Offline installation (Raspbian)

You can do this process offline using QEMU.
Extract the SD card and copy the image to your computer (adjust sdx).

Then,

Once done, you can copy it back (adjust sdx ).

Code

github

References

http://blog.modsecurity.org/2010/11/advanced-topic-of-the-week-traditional-vs-anomaly-scoring-detection-modes.html

https://samhobbs.co.uk/2016/03/getting-started-apache-modsecurity-debian-and-ubuntu

https://samhobbs.co.uk/2015/09/example-whitelisting-rules-apache-modsecurity-and-owasp-core-rule-set

https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual

Author: nachoparker

Humbly sharing things that I find useful
[ github dockerhub ]

15 Comments on “ModSecurity Web Application Firewall for NextCloud

  1. Don’t forget to Modify /etc/modsecurity/modsecurity.conf

    Increase SecRequestBodyInMemoryLimit 131072 to 531072
    Increase SecRequestBodyLimit 13107200 to 8589934592 (8GB)

    To prevent large upload errors. The default is too low for nextcloud

    1. Thanks for the tip!

      Actually I used SecRequestBodyNoFilesLimit for that, but the code in this post was not updated with that. I just did.

      I will re-test this soon, because I am working in bigger uploads.

      Anyhow, tips, testing, feedback, contributions and PRs are very welcome.

      Thanks

  2. I tested your config with Nextcloud 12 on Ubuntu server 16.04 and unfortunately there are many false positives. I had to add PUT, DELETE and REPORT to tx.allowed_methods or the calendar doesn’t work at all. I checked the log and there’s still many things getting blocked.
    Do you have a working config for Nextcloud 12 by any chance?
    Furthermore Ubuntu uses /usr/share/modsecurity-crs/ for the rules, while the config is still in /etc/modsecurity/.

    1. That’s interesting… the info in the page is updated for NextCloud 12

      I didn’t test it in Ubuntu though, but in Raspbian. What is the version of apache and modsecurity that you are using?

      Also, keep in mind that the configuration that I share doesn’t block requests on each false positive, but when the anomality score is too big, which means that there can be some matches in the log but the request still goes through.

      Calendar works fine for me in NextCloudPi

      1. “dpkg -l | grep apache2” reports: apache2 2.4.18-2ubuntu3.4 and libapache2-mod-security2 2.9.0-1.

        I didn’t find the setting to “Enable anomaly scoring mode”. Is that “SecDefaultAction” in the script?

        I’m currently running DetectionOnly and just checked the logs again.

        I’m not even using Nextcloud at the moment and I’m getting a lot of those errors. The second one is new and doesn’t sound too good.
        Are you supposed to keep adding stuff to the whitelist until you get no more errors? But unless I test everything , something minor might fail silently one day and break something.

        ModSecurity seems awfully complicated. I would have expected that there are whitelists for all common applications, but it seems like your guide is the only one for Nextcloud. I found some mentions of ModSecurity and Nextcloud, but almost all say you should just turn it off.

        1. I have updated the github link.

          Yes, it is a complicated beast, but once configured you can be pretty confident that you will be safe.

          Please, read the references to this post to understand the concepts. I am afraid you won’t be able to change things otherwise.

          It is normal that some warnings appear, only when an “anormal” number of them show up for a particular request, it will be denied.

          In any case… I use it everyday and it works for me with NC 12 and half a dozen common apps. You shouldn’t have to modify it.

          If anything is different, might be related to our different versions.

          Apache: 2.4.25
          modsecurity: 2.8.0

          It is complicated, that is why I wanted to start supporting modsecurity for Nextcloud … if there is more people using it we can together come up with a working ruleset. I only use it on Raspbian, so that is my contribution.

          Anyway, let us know if you can make it work.

  3. Some rules are now removed in modsecurity_crs_99_whitelist.conf which treats the installation as one that is in /var/www/nextcloud, but what if a user has the data folder on a separate partition? For example if someone has this in the config.php file: ‘datadirectory’ => ‘/srv/nextcloud’

    Would that mean that the white list could be different and split up the removal of rules between /srv/nextcloud and /var/www/nextcloud? Or is all the action relevant to modsecurity in /var/www/nextcloud exclusively? Thank you!

    1. It does not matter where the datadir is when it comes to modsecurity rules. What matters is where the webapp code is ( that is the www folder )

      — COPYPASTE —
      Hi, please ask technical questions or report issues on github. That way other people with the same issue can benefit from the answer.

      Check first that it has not been asked before
      — COPYPASTE END —

Leave a Reply

Your email address will not be published. Required fields are marked *