As many of us are aware, fail2ban is a highly effective method for blocking brute-force attempts by temporarily (or permanently, if desired!) blocking IP addresses. Is there a similar functionality, and/or a native definition for the fail2ban jail.local file? There are a few unofficial ones out there (for ownCloud presently) but it would be nice to have an official one.
Another solution is ossec. It would be a good idea to include an encoder and some rules in the nextcloud documentation, to allow for an easy set up of owncloud and ossec. And also to refrain from changes in the log format between versions.
Since I haven’t heard back from the community or admins on this I’ve decided to write my own fail2ban jail rule and will post updates to the documentation upon completion.
In doing so, does anyone know where failed login attempts for Nextcloud are logged? The main log for Nextcloud appears to be /var/log/syslog but I couldn’t find any entries located there after purposefully entering bogus usernames, nor could I locate the bogus credential string anywhere in the /var/log/ directory. The command I used for find it was grep -rnw /var/log/ -e "bogususer"
You can add the following options to your config.php (in the /path/to/nextcloud/config/ folder) and Nextcloud will log failed logins to the nextcloud.log file in the /path/to/nextcloud/ folder.
There is a tutorial for setting up fail2ban for owncloud at the owncloud.org forum, section owncloud community > tutorials. It works very well on oc and I think it will work on Nextcloud too.
Thank you @AlfredSK - though I wish I had seen your message earlier! In the meantime I developed my own tutorial on GitHub (still a WIP as of this writing). I will be maintaining it as the logtype for Nextcloud is agreed upon:
Hi, in the last section of my blog nextcloud: nginx, ssl, fail2ban
you can find a very simple fail2ban solution for nextcloud based on ubuntu 16.04.
Unfortunately it is written in german but the linux commands are easy to understand even when written in german.
cheers, carsten
There are no NC docs.
edit: I was mistaken; I remembered correctly that there are no pdfs available, but full documentation seems to be provided as a set of html files.
The guide I created was made during a time with brute-force protection was not available in Nextcloud. I will update my guide to mention that it’s now an available option.
I have not experimented with the difference between the two (or other) solutions, though for forward-compatibility it’s probably more wise to go with Nextcloud’s implementation.
As far as I know, the nextcloud brute force protection leads to a growing delay between failing login attempts. Fail2ban on the other hand completely blocks a certain ip, if it fails given times for a given duration. But fail2ban is configurable in allowed attempts and block duration. So theoretically both together lead to a little stricter blocking/delaying rules and work fine together (in my case). I don’t know about performance/memory usage etc. but I guess watching one log file (fail2ban) more should be not noticeable and it is anyway highly recommended for SSH.
Fail2ban blocks the untrusted IP at the interface level using a smart firewall. Once blocked via fail2ban, the untrusted IP never accesses your HTTP server, whereas the throttling built-in to NC is done at the PHP level, and thus, allows the untrusted user to access server resources, such as Apache, mysql, PHP, etc. I use both forms of brute force protection. It’s always better to have redundancy especially for brute force.