This article is about how to securely configure the machine where your Nextcloud/ Owncloud instance will be running.
Even if you set-up your connection with Owncloud in a secure way, your data still can be compromised by exploiting security flaws in the underlying architecture.
In the following we specifically will cover the underlying software stack and brute-force password hacking attempts.
Automatically install security updates
No software package is perfect – there might be security holes in the the whole stack – starting with the linux kernel up to the used SSL library.
However most security holes that are being exploited are publicly known and security updates have been provided for them.
The only reason why they still can be exploited is that people do not install the security updates in time. Especially if there is no server-admin dedicated to maintaining the Owncloud machine one might easily miss on such updates.
Fortunately it is very easy to enable automatic security updates on debian based distributions with
sudo dpkg-reconfigure -plow unattended-upgradesStarting with owncloud 8.2, there are per release package sources, so it is safe to also include owncloud itself in the unattended-upgrades. To do so add the following line to
/etc/apt/apt.conf.d/50unattended-upgrades
"*owncloud.com/ce*9.0/Ubuntu*:";This line follows the format "<origin>:<suite>" and is matched against the contents of /var/lib/apt/lists/.
To verify whether the origin is included as desired run:
sudo unattended-upgrades --dry-run --debugPrevent brute-force password hacks
Unfortunately Owncloud 9.1 is still vulnerable to brute-force password attacks in its default configuration as it does not enforce timeouts after failed login-attempts.
Therefore one might just try all possible passwords gain access to your machine in about 3 days for a typical password length:
To prevent this we can use fail2ban to enforce a timeout after a certain number of failed login attempts.
First install fail2ban
sudo apt-get install fail2banFail2ban works by parsing the log files of a service and then reconfiguring the firewall in order to ban the offending ip-address.
So we need to tell owncloud to log the failed login attempts. To do so edit
owncloud/config/config.php
'logtimezone' => '<TIMEZONE>', // e.g. 'Europe/Berlin'
'logfile' => '/var/log/owncloud.log',
'loglevel' => '2'
Note that logtimezone must match the clock of your server. Furthermore the webserver user (e.g. www-data) must have write access to the logfile. To verify that logging works, do some failed logins and check /var/log/owncloud.log.
Next create the following filter definition for fail2ban
/etc/fail2ban/filter.d/owncloud.conf
[Definition]
failregex={"reqId":".*","remoteAddr":"<HOST>","app":"core","message":"Login failed: .*","level":2,"time":".*"}
Together with the following service definition
/etc/fail2ban/jail.local
[owncloud]
enabled = true
filter = owncloud
port = https
logpath = /var/log/owncloud.logNow restart fail2ban and try to log in 4 times with a wrong password. The 4th attempt should give you a timeout. (for 15min)
If you do not get the timeout you should verify that fail2ban correctly reads the log by
fail2ban-regex /var/log/owncloud.log /etc/fail2ban/filter.d/owncloud.conf
good stuff, I’m going to implement this right now on my owncloud, thx
Guys, I found the issue why it’s not working, for me it was the timezone, because, of course, fail2ban needs to know the times when someone accessed the owncloud instance:)
‘logtimezone’ => ‘Europe/Vienna’,
Instead of
‘logtimezone’ => ‘UTC’,
Thank you, just what i needed. But there’s still another hole i would like fix. If you share a file you can secure it with a password. The invalid ones are not track in this way.
I could not get this to work. Restarting fail2ban seemed to pass the settings without a problem but when I make the login attempts it doens’t ever give me the message or stop be from continuing to log in.
it should not give you any error message – it should simply block you from the server for 15min.
Take a look on /var/log/fail2ban.log and on /var/log/owncloud.log to find out whats going wrong.
/var/log/fail2ban.log shows the service starting the the owncloud jail running. /var/log/owncloud.log does not seem to exist. I’m not sure why it’s never created, I’ve tried logging in with a wrong password 5+ times and I don’t see any lines in the fail2ban.log other than that the owncloud jail is starting and running.
fail2ban works by parsing owncloud.log – so if it is not there fail2ban cant possibly work.
Did you edit owncloud/config/config.php as suggested?
Also check the log on the owncloud administration page.
A wild guess would be that the php user has no write permissions to /var/log/.
Should
‘logfile’ => ‘/path/to/owncloud/data-directory/owncloud.log’,
or are we explicitly creating a new logfile for this process?
Then this is the file that should be referenced in /etc/fail2ban/jail.local.
also take a look whether it contains any info about failed log-in attempts.
Hmm. I have changed the path in /etc/fail2ban/jail.local to read ‘logfile’ => ‘/var/www/owncloud/data/owncloud.log’
Viewing that file shows the login attempts being written to the log file, however entering wrong passwords still doesn’t seem to lock me out for any amount of time.
Brother, its the post updated with all this info? I installed 7.0.1 and having some issues as well..trying all the solutions from the comments..still no blocking! 🙁
Fail2ban doesn’t like the ISO8601 format that ownCloud uses, so in order to make it work right you need to follow the last post over here: http://forum.owncloud.org/viewtopic.php?f=26&t=18520&start=10
Basically it switches to a different format that works with fail2ban. Just tested it myself, and it locked me out right away! Make sure you change the locations of the log files in ALL the configs.
for me fail2ban 0.8.11 works fine with ISO8601
Owncloud 7.0.2 the Fail2ban doesn’t work with this . Whats the Problem with the Code. On 7.0.1 it works without Problems 🙁
check your owncloud.log for the “wrong password” warnings. also compare the logged time with the server time
the changed the log format in 7.0.2. I updated the filter definition to match both.
My owncloud did not have access to /var/log. Had to drop the log in /var/www/owncloud but it works great.
You shouldn’t put logs into a folder that is accessible by the webserver (someone might inject an url containing code and try to use it with an attack). Instead use chgrp and chmod g+w to grant access to a subfolder of /var/log to owncloud.
Thanks. There are always things to learn.
Who exactly should be owner of my new /var/log/owncloud folder?
i used the same user/group as my apache2 folder has set, seems to work here.
Thanks for the article. I had to change the log file to owncloud/data/owncloud.log.
So, I’m trying to configure fail2ban for OC 7.04. I’m not having any luck with OC writing to the owncloud.log file mentioned in this write up. It appears that the log_authfailip function has been removed and failed log in attempts are now logged through checkPassword.
https://github.com/owncloud/core/pull/10442
I’m still researching how to adjust fail2ban for this change.
have you found a solution?
the second row in /etc/fail2ban/filter.d/owncloud.conf should still match with OC 7.0.4. As far as I can see this is the change I already noticed with 7.0.2.
hmm i keep getting this message when i am trying to restart
root@techknight:/home/daniel# nano /etc/fail2ban/filter.d/owncloud.conf
root@techknight:/home/daniel# service fail2ban restart
* Restarting authentication failure monitor fail2ban ERROR Failed during configuration: File contains no section headers.
file: /etc/fail2ban/filter.d/owncloud.conf, line: 1
‘{“app”:”core”,”message”:”Login failed: ‘.*’ \(Remote IP: ”, X-Forwarded-For: ‘.*’\)”,”level”:2,”time”:”.*”}n’
[fail]
seems you forgot to place [Definition] above the regex in /etc/fail2ban/filter.d/owncloud.conf. compare your config with the post.
my config gile looks like this as it is the newest owncloud
[Definition]
failregex={“app”:”core”,”message”:”Login failed: ‘.*’ (Remote IP: ”, X-Forwarded-For: ‘.*’)”,”level”:2,”time”:”.*”}
it still says it needs an definition ?
Thanks for the writeup, just implemented this right now on my OC instance and it’s working as intended. (OC 7.04)
I followed exactly everything you have mentioned. It does not seem to work. I don’t get timed out 🙁
does logging work? i.e. do you see log messages in /var/log/owncloud.log after failed login attempts?
Yep. I can see the failed attempts. Moreover if I run fail2ban-regex /var/log/owncloud.log /etc/fail2ban/filter.d/owncloud.conf
I get the following result:
Lines: 72 lines, 0 ignored, 54 matched, 18 missed
assuming you made indeed 54 login attempts, is the logged time correct? compare with the output of “date” on your server.
Date: Sat Feb 14 11:32:52 EST 2015
owncloud.log output (a single line):
{“reqId”:”b6326a5346a1ceca00a26e58297c6f01″,”remoteAddr”:
“108.162.242.243”,”app”:”core”,”message”:”Login failed: ‘a’ (Remote IP:’108.162.242.243′, X-Forwarded-For:
‘67.204.34.129’)”,”level”:2,”time”:”2015-02-14T11:31:37-05:00″,”method”:”POST”,”url”:”/owncloud/”}
honestly, I am out of ideas. The only thing left is that fail2ban fails to ban. take a look at /var/log/fail2ban.log
it does ban it on logs, but it deos not seem to work
I finally figured it out. I modified the regex a little bit.
This might help with Owncloud 8.0.2 🙂 Thanks a lot for this tutorial. I learnt a lot.
{“reqId”:”.*”,”remoteAddr”:””,”app”:”core”,”message”:”Login failed: .*”,”level”:2,”time”:”.*”}
I had the same problem. The solution for me:
in jail.local the default-backend is set to systemd. But when using a separate logfile for owncloud you have to set the backend in the [owncloud]-section to polling.
Now it works for me.
Worked perfectly for OC 7.0.5. Thanks!
Thank you for this fine tutorial.
I’m running OwnCloud v7.05 and Fail2ban v0.9.1 on a Fedora 21 server so I had to make the following changes to make i work:
1. In “/etc/owncloud/config.php” I changed ‘log_type’ => ‘syslog’ (default) to ‘log_type’ => ‘owncloud’. Before I made this change, nothing would be written to “/var/log/owncloud.log”. Source: http://kortlink.dk/gsqt
2. On Fedora 21 the webserver user and group is “apache” (not “www-data”) so I changed the ownership of “/var/log/owncloud.log” to “apache”: “chmod apache:apache /var/log/owncloud.log”.
3. I placed “jail.local” in the folder “/etc/fail2ban/jail.d/” since it’s recommended by Fedora.
thanks a lot for this how2!
Seems to work on my system OC 8.1.1 on debian wheezy
(I also did chown www-data:www-data /var/log/owncloud.log)
Thanks a lot!!
Thanks for this, great guide!
I am trying to setup fail2ban but everything seems ok but fail2ban is not working. I can do many fail attempts to login.
I have verify that fail2ban correctly read the logs.
And i have edit owncloud.conf like with the instructions.
When i restart service i have this warnings
* Restarting authentication failure monitor fail2ban WARNING ‘ignoreregex’ not defined in ‘Definition’. Using default one: ”
check this one here: https://forum.owncloud.org/viewtopic.php?t=28678
you can safely ignore this warning.
ok thx. I have seutp failban and is working 🙂
Thank you. This is a fantastic help.
Although this article is relatively old (+3yrs), I’m wondering if these still apply today with OCX. Also I’m merely interested in OC for personal use on a shared hosting server. Since this environment is limited in access, are there specific measures to secure the installation?
Thanks