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 xxx.xxx.xxx.xxx 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.
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 nextcloud.enable-https
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.