Page 1 of 1

Secure operation of NextCloud (and Plex) on CentOS server from home with external accessibility

Posted: 2020/05/08 14:28:56
by rogerwilco
Goal:
Hosting of NextCloud and Plex @home with a reasonably high level of security and the smallest possible attack surface, as well as limited/restricted external access for 1 user.

LAN-internal use (fixed IPs are used in the LAN)
- Nextcloud for known devices from the LAN (no Snap/Flatpak/AppImage)
- Plex media server for known devices from the LAN
- CalDAV/CardDAV/WebDAV
- Remote access to servers via SSH with self-signed keys, only via CLI

External/WAN accesses
- Use of CalDAV/CardDAV/WebDAV
- possibly some file sync from an Android device, probably for WebDAV and SSH. This is currently planned via VPN tunnel; accessible via DynDNS service.

Information about the environment:
- CentOS 8 server with 2 NICs, theoretically 3 possible, since there is still a USB WLAN dongle.
- Arris Group Inc "TG1682G" router with 4 LAN ports, one of which could be used for a DMZ of this router.
- Currently there are no other switches/routers.
- No fixed WAN-IP through ISP, so a DynDNS service will be used here. On the server runs "ddclient" for updating the WAN-IP.
- 2 Linux clients (+1 Windows10 client), 2 or 3 Android devices
- probably Webmin will be added.

Server security:
- firewalld
- fail2ban
- SSH with self-signed keys
- root account locked for remote access
- no GUI login for remote access, only SSH.
- current Lynis score = 76
- IPv6 has been disabled
-- intended: OSSEC


Unclear aspects, questions, request for tips:
- How would one use the 2 NICs (with regard to the potentially used DMZ) in the most sensible way, whereby the goal should be minimal, i.e. only really necessary, exposure of the server? Aim is to keep the attack surface small.

- How sensible is it, with regard to the level of protection, to handle external access via a VPN tunnel alone (PPTP, L2TP, IPsec) and then to allow SSH with self-signed key and CalDAV/CardDAV/WebDAV in connection with SSL?
As mentioned before, as far as I know, GUI remote administration is not intended.
Yes, such a VPN tunnel would then run into the (supposed) DMZ of the consumer router, but further access to the LAN from WAN is (at first (what might follow later is still unclear)) not intended.

- Does it make sense to put the server into the DMZ of the consumer router connected to NIC#1 for example, and to run a very strict configuration for NIC#1 via firewalld (obviously only opening necessary ports, drop requests from unwanted sources, where connections should only be allowed via the aforementioned VPN tunnel) anyway and to handle requests from the internal LAN via NIC#2 with a different firewalld zone profile?

- What about gateways, data flow directions, routing, (port) forwarding etc.?

- Is it true that usually the DMZ of a consumer router reduces the level of protection that a router can offer, since it is in fact only an internal switch, which is not really separated from the rest of the LAN and for the DMZ various "protective functions" of the router, for the operation of a server out of the DMZ for requests from outside, things are virtually deactivated?
Wouldn't port forwarding be safer then compared to placing the server into a consumer router's DMZ.
Is a second NIC still an advantage then?


...I'm running out of questions here, since some things are still unclear to me, as you have surely noticed.

Of course am I willing to to read up and put work into it. There is also a CentOS-VM as a playground, but I lack a little bit the direction and working my way in should ideally already have one or two, more or less clear, directions.

It needn't become a hyperparanoid installation, it should simply reflect many best practices and offer an adequate security/protection level with a reasonable effort, so that the intended use cases still work.

Where's my thinking wrong?
What have I not considered?
Which of the approaches is possibly even feeble-minded?


Many, many thanks for your input.