Security measures for external access

I have recently setup my NextCloud 11 (snap version) with Ubuntu Core on a Raspberry Pi3, and have just now made it accessible on the world wide web.

I have some question regarding security. I have asked about this before when I was preparing for my setup, but since I am using the snap version I think that most important steps are already completed in the automated installation. I have followed the instructions here:

So I have done this:

  1. Registered for a domain
  2. Opened port 80 and 443 and forwarded those to the Pi3 (both UDP and TCP, do I only need one of protocols?)
  3. Added my domain in the “trusted domains list”
  4. Enabled HTTPS with Let’s encrypt.
  5. Enabled 2-factor authentication with FreeOTP

I addition I can inform that my nextcloud data is stored on a USB drive, while everything else is on the Pi’s SD card.

So, my questions is:
Do I need to do something else in addition to make my setup Secure?
Bare in mind that I am using the Snap version.

I think HTTP can be both its mainly TCP.
Did you choose the redirection with letsencrypt as http is missing the s of secure.

Guess you could install fail2ban to stop brute force logins and various logged attacks.
Its fairly easy to install.

You could enable the firewall on the pi also and just have 80 & 443 open.

Maybe whitelist your connections.
Allow from in the apache.conf or firewall.

Security is often a double edged sword and you can make systems very hard to work with, prob a lot you could do.

The above is a good guide but I pointed to mod-security as I have tried it and found it to cause more problems than it may protect for.
I guess you just need to get used to you system, but whitelisting those you trust and saying no to all else is definitely the easiest and most secure, if inflexible.

Did you choose the redirection with letsencrypt as http is missing the s of secure.

Not quite sure what you mean by this. I simply used Let’s Encrypt by using
sudo nextcloud.enable-https

I looked at fail2ban, which is quite interesting. But I wonder how the built-in brute force counter measures in NC11 are compared to fail2ban.

I tried researching the pi firewall, but for the most part I only found threads where people where discussing whether or not it existed.

Didn’t even know that existed, but also slightly bemused at the rationale for creating script wrappers around existing scripts that are well documented.

I dunno if its snap that causes such object references but the valuable services letsencrypt provide and the update and reissue through cron shouldn’t really be obfuscated and repackaged as nextcloud provisions.

For a beginner like myself I like the simplicity of the snap version, but I don’t like the lack of documentation on the wiki. For instance, I don’t know if the command enables Strict-Transport-Security.

Maybe someone else can tell me what is done when launching

By using the test on I have found that HSTS is enabled when using

Actually nextcloud itself informs about the most critical security issues on the admin panel. HTTPS forwarding, HSTS and file access are checked at least. So if nothing appears there: So far so good.

Fail2ban is only relevant if you connect to your system via SSH or something. At least SSH protection (on port 22) is set up by default. For nextcloud web access there is nothing like that necessary because it has integrated brute force protection.

The standard firewall on Debian systems is iptables. I don’t know if this is also true for snappy Ubuntu. Check that and if so you will find plenty guides online on how to set up the firewall.

Some people have fail2ban doing nextcloud log checks.

I only have SSH and webmin open on the local subnet and openvpn is so very easy to setup and much more secure as a public port.
So I connect to the local subnet with openvpn and use ssh and webmin there remotely. I wouldn’t personally have those two open public fail2ban or not.

There is a fail2ban filter and jail examples in the forum as nextcloud is prone to bruteforce attempts being public, without things like 2factor.

UFW I guess I have every thing but http, https & (1197) is it anyway (openvpn) public.
Then a few services available on the local subnet.

UFW is dead easy and doesn’t need a GUI

Its relatively secure as with self hosting port forwarding is acting as a firewall and really ufw on mine is a 2nd firewall, behind the router.

Yeah I also do so and could provide the steps for that if necessary. But actually if I had known the nextcloud internal brute force attack I would not have set this up, as it more less just doubles the same thing ;).

Against brute force on ssh the best way I found is to change the standard ssh port 22 to a different one. Since nearly one year of changed this I had no single brute force attempt, which can be seen in the fail2ban log. The only problem with that is, that many official and work place web accesses block non standard ports. But I anyway prefer to manage my server from home, so no problem with that.

Thanks for all answers. I haven’t done anything active to open SSH to external access, so I don’t think that is an issue.

I guess I am all set by Let’s Encrypt and the integrated measures in Nextcloud :slight_smile:

I did a bit of a tutorial that was just supposed to be a known good. I used debian but could be any.

In that I use DNSMasq for internal DNS and DHCP and meant to get round to posting about OpenVPN, SSH, Webmin and Fail2Ban.

Would be great if you started a thread on top tips, would be great maybe to also have a community wiki.

Maybe post something.