Hi all,
I'm hoping for strategic advice, so feel free to give.
Here goes:
Task: Pull data from the Linux and Windows machines in the home network, while secure against ransomware attacks.
Situation:
The Windows and Linux machines are desktops.
The network setup is as usual: Internet <-> DSL modem <-> local net. No DMZ, but the DSL modem is actually pretty good security-wise (an AVM FritzBox model).
The DSL modem does DNS caching, DHCP, and Zeroconf.
Threat model:
The routine scenario is that at least one desktop machine is under attacker control.
The DSL modem will be under attacker control, though that's a much more difficult target.
I want to be safe for the next 10 years or so.
My current approach is to configure FreeBSD for minimal attack surface:
Open for debate but I currently believe I'm already good:
Here I know I need advice:
Any insights welcome!
I'm hoping for strategic advice, so feel free to give.
Here goes:
Task: Pull data from the Linux and Windows machines in the home network, while secure against ransomware attacks.
Situation:
The Windows and Linux machines are desktops.
The network setup is as usual: Internet <-> DSL modem <-> local net. No DMZ, but the DSL modem is actually pretty good security-wise (an AVM FritzBox model).
The DSL modem does DNS caching, DHCP, and Zeroconf.
Threat model:
The routine scenario is that at least one desktop machine is under attacker control.
The DSL modem will be under attacker control, though that's a much more difficult target.
I want to be safe for the next 10 years or so.
My current approach is to configure FreeBSD for minimal attack surface:
- No write-enabled or instruction-submitting services exposed anywhere.
- The FreeBSD box operates autonomously otherwise.
- The ZFS snapshots will be published back to the LAN using a Samba server, which has read-only access to the ZFS snapshots.
Open for debate but I currently believe I'm already good:
- Pull schedule (what machines, what directories, when, how often) and deprecation schedule (what snapshots to cull at what age) are entirely configured in the FreeBSD machine.
- No sshd: An attacker with a keylogger could open SSH connections and do on FreeBSD whatever they want. Command access is solely via physically attached keyboard/monitor. (No copy&paste from forum advice, unfortunately.)
- Samba is an awfully large attack surface from protocol alone. I think I'll want to jail the Samba server.
- ZFS snapshots are read-only by default, so I don't need anything when exposing them in the Samba jail, right?
- Pulling from Linux machines is easy via rsync-over-ssh.
- To secure the Linux machines, I mount-rebind-ro the directories to be pulled, create a special user that cannot execute anything but the rsync command needed to read those directories. public-key authentication. I want to pull pretty much everything including fifos, permissions etc., so rsync is going to run in numeric uid/gid mode - that's another reason why the FreeBSD box isn't going to do anything with the data it pulls. (This is pretty much a tangent, as this applies to the Linux clients, not the FreeBSD machine.)
Here I know I need advice:
- How do I expose the ZFS snapshots back to the Linux machines? I need to be able to browse them, with uids/gids intact if possible.
- The Windows machines won't expose their pull directories via SMB1 because it's too insecure. This means I cannot use mount_smbfs, right?
- If the Windows machines expose pull directories via SMB2/3, is there any way that FreeBSD can read these?
- The Windows machines could use Cygwin to expose the pull directories for rsync-over-ssh. Sort-of-unfortunately, Cygwin's ssh may conflict with Microsoft's native "developer mode" SSH. Plus I'd have to tell the Windows users to install Cygwin and configure sshd, which is going to give me MEGO reactions... On the plus side, the FreeBSD side of things would become simpler, reducing the attack surface a bit. So at least I have a strategy of last resort.
- What can be done with the ACLs on the Windows side? Ideally, these should be recoverable from the pulled data. OTOH the Windows users aren't too interested in that functionality, so if that's complicated I'll simply drop it.
- I briefly considered using Samba with Kerberos. I ditched the idea for two reasons: (a) Kerberos is COMPLICATED. (b) It requires a reliable DNS, which means I'd have to move the DHCP and Zeroconf functions from the DSL modem to the FreeBSD machine, and I fear that's both beyond my abilities and my time budget. Kerberos would give us the option to move data between machines and keeping ACLs and similar semantics intact, which would be nifty, but I suspect it won't work for me in the end (and maybe it's not really doable - I doubt that I can use MIT Kerberos as a Windows domain controller).
- Newer Windows versions can to NFS. Which would make shares instantly usable from FreeBSD. However, it's just Windows Server that has it, and the local machines are Home and Pro licenses... so no, not an option. Besides, NFS requires that either uids/gids are numerically identical across machines, which is pretty absurd in modern ages, or (again) Kerberos.
Any insights welcome!