Options for securely pulling data from LAN?

Toolforger

Member

Reaction score: 6
Messages: 20

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:
  • 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!
 

aragats

Daemon

Reaction score: 480
Messages: 1,158

An attacker with a keylogger could open SSH connections and do on FreeBSD whatever they want.
Really? You should disable password login and exchange the keys! The password SSH access is most secure and reliable.
 

roccobaroccoSC

Well-Known Member

Reaction score: 93
Messages: 413

Really? You should disable password login and exchange the keys! The password SSH access is most secure and reliable.
Well, if the attacker has installed a keylogger, what would prevent them from uploading the SSH key to attacker's computer? It does not make any difference if you use a password or a key - both are in the attacker's control because even if the key is encrypted, the attacker can use the keylogger and get the password to it, then upload the file and just use it.

The only way to prevent such an attack I can think of, is to put some 2-way authentication. For example, with an RSA card registered on the server, SMS-PIN, mobile app or some other means. This way the attacker could not login without the second channel.
 
  • Thanks
Reactions: OJ

roccobaroccoSC

Well-Known Member

Reaction score: 93
Messages: 413

Hi Toolforger,

From my perspective if you want to be secure against ransomware or other attacks, you should not be using Windows with your documents. Here are some suggestions, but it depends on your paranoia level:
Devices:
  • Do not use any router or other modem/router combos. These are real machines with CPUs, file systems and firewalls, in many cases incorrectly configured, not up to date Firmware, etc. One has very little control over such devices.
  • Instead, use real computers, like Intel NUC, where you have full control over the OS installed. Of course, install FreeBSD on them.
  • For your network, just use switches. Do not use routers for the reasons above. The switch must have a special management port, it should not be manageable remotely.
  • For external links, use plain DSL or cable modems - no routers in them! Again, for the above reasons.
  • For your servers, NAS and desktop workstations - always use FreeBSD. My own workstation works very well with FreeBSD and KDE.
  • For your notebooks - first check if the hardware has good driver support. If yes, use FreeBSD (I have one notebook with it, it works). If not, GNU/Linux should cover you in any case.
  • Windows is in my opinion a good OS, but it has the disadvantage of being used massively by inexperienced users, which makes it a very attractive target for ransomware entrepreneurs.
  • Always patch your OS-es regularly.
Connections:
  • Always use encrypted traffic, even in your local network. SSH tunneling with key authentication (some random extremely strong password) is the way to go, especially if you log in from a remote location over the Internet.
  • If you need VPN (e.g. OpenVPN), first make an SSH-tunnel, then open the VPN connection over the tunnel. I have heard that SSH is in general stronger than SSL, unless used incorrectly. There's no harm in using both layers for sure.
  • Allow all needed connections in machine's firewalls explicitly! For example, if your workstation is A and your server is B, then B should have one open SSH port, and it's firewall should allow only host A's MAC and IP address.
  • Do not use WLAN! In case you do, ALWAYS encrypt the traffic over an SSH tunnel (switch -D opens a SOCKS5 proxy for you to use in an encrypted way).
  • Always close your ports you're not using at the moment. Open them when needed.
  • If you use IPv4, disable IPv6 everywhere. If you use IPv6, disable IPv4 everywhere (firewalls mostly). It's easy to overlook missing firewall rules for the other protocol, then you have a widely opened attack surface to be exploited. Well secured IPv4 and widely opened IPv6 is like locking your front door and leaving the back door open.
  • When using SSH for tunnelling, ALWAYS use a very limited user without login shell. Opening a port is everything you need.
  • Whenever possible, put the SSH services inside a jail and bridge or route its interface to the network. Do not expose the main host!
  • Use highest security algorithms! Do not use obsolete algorithms. Use big keys!
  • Regarding your question: how to expoze ZFS snapshots: Always over SSHFS and read-only (anyway).
  • NEVER USE NFS SHARING! NFS is insecure by design and allows for privilege escalation. I take that back. You should use the "root_squash" option, which is enabled by default: https://www.tldp.org/HOWTO/NFS-HOWTO/security.html
  • SMB is in general more secure than NFS, although make sure NOT to use SMBv1, which is vulnerable. Just use the highest possible level, if SMB cannot be avoided. And enforce the level.
  • With a quick search I found a project, offering sshfs for Windows. I don't know anything about it though, so research it first: https://github.com/billziss-gh/sshfs-win
Gateway:
  • Exchange the DSL modem/router with a simple modem that does not have a router. It simple modulates your signal and connects your RJ-45 hole with the provider, no CPU, no storage, no attack surface.
  • Put a FreeBSD box directly connected to the Internet line as a gateway.
  • Treat everything outside gateway's external interface as malicious.
  • Set your gateway IPFW to paranoia level. This link is a good starter: https://alexnettm.com/freebsd/freebsd-nastrojka-ipfw-kernel-nat.html (note, the link's SSL certificate is expired, but the info is still OK).
  • Expose at most 1 single SSH port to the Internet. Use port knocking to open it on demand! Everyone else would not be able to access anything.
  • Put your SSH daemon and the OpenVPN server inside a jail. Even if it gets hacked, your gateway would still be safe. From outside, allow only access to the jail. Access to the host should be only locally possible - from the LAN. The jail traffic can be then routed inside the network to your other machines.
Server/NAS:
  • Again, open a single SSH port. Port knocking might be used, but for the LAN is probably an overkill, unless you have WLAN.
  • Always mount your NAS directory via SSH (sshfs) and read-only! You do not need write access when watching a movie or listening to a song.
  • Have a special transfer directory, mounted via sshfs read-write. Dump stuff there, then move it on the machine itself from a secure shell.
  • Use ZFS and at least daily snapshots. They are cheap. Use disk redundancy and backup via zfs send your data.
Workstation/Notebook:
  • Do not open any services on your workstations. Allow only outgoing connections.
  • You can connect your two workstations (e.g. via synergy) without opening anything in their firewalls. Create two SSH tunnels to a jail on another box. One reverse tunnel to localhost, and one forward tunnel.
Shells:
  • Always use sudo and execute only the necessary commands as root. Not all of them! Be sure to check out scripts before executing them.
WLAN/Android/IoT/Gaming:
  • If you need to use WLAN, smartphones, smart TVs or whatever (washing machine with WLAN) - add a second level to your LAN. Have two segments: one secure for your work and documents, one insecure for the virus infested smart devices and gaming PCs.
  • Put a FreeBSD gateway between the two segments.
  • Never allow write access to the secure network.
  • If you need, allow read-only access to certain files, like your kid's videos or pictures. Inside a jail, of course. And also limit the access to read-only for the jail itself.
This is, of course, a lot of work. But it can keep you covered for even more than 10 years.
Even applying some of the suggestions would help securitywise.

Regarding your original thought about the ransomware, you could use 2-factor authentication with your SSH connections. And also - instead of keys, you can use certificates that expire every few days or weeks. But most people probably don't need this extreme level of security, even for business.
 

roccobaroccoSC

Well-Known Member

Reaction score: 93
Messages: 413

One more thing: Why do you want to open the Windows boxes and pull data from them? Isn't it much more secure to open an SSH port on your FreeBSD server and rsync from the windows machines whatever you need? I think you can use minGW or cygwin's rsync inside a BATCH file.
So your Windows users would simply have to click on the file to do the backup, or even better - the backup can be done via scheduled task behind the curtains.

If you're worried that the windows machines would wreak havoc on your FreeBSD directory, just give them permission to a limited directory only (or better, a simple jail for each user).
The ransomware can damage the files on the Windows machines themselves, so it does not matter if the windows uploads to BSD or BSD pulls from windows - files are broken in both cases. If you ZFS snapshot every upload immediately after it's uploaded the ransomware would be powerless against you.

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!
 

tommiie

Active Member

Reaction score: 40
Messages: 154

Well, if the attacker has installed a keylogger, what would prevent them from uploading the SSH key to attacker's computer? It does not make any difference if you use a password or a key - both are in the attacker's control because even if the key is encrypted, the attacker can use the keylogger and get the password to it, then upload the file and just use it.
If the attacker has access to your keys and passwords, why would you even want to fetch your data from that server? Who's to say the attacker didn't compromise your data, altered it, deleted it, installed backdoors in it...

If you don't want to use SSH, don't even consider Samba or any other tool.
 

Sevendogsbsd

Well-Known Member

Reaction score: 210
Messages: 446

Good security on a home LAN is a great idea but the majority of attacks are not against home users but against businesses. Granted home users most certainly have lesser security than most businesses (credit card companies, banks, etc), but businesses hosting large amounts of customer data are prime targets. Focused attackers could care less about home users because the ROI is little. Script kiddies maybe, because they are too stupid to know better and just want to reek havoc.

I do like the idea of segregating wireless devices and need to implement this on my network. I have a high quality firewall running FreeBSD and just need to figure out how to vlan all of the wireless devices off.
 
OP
OP
Toolforger

Toolforger

Member

Reaction score: 6
Messages: 20

Sorry for responding so late, for some reasons I didn't get the notifications that I normally do.

Thanks for all the responses.

Answers:

* The maximum catastrophe scenario I'm dealing with is that the NAS is secure but some machines in the LAN are infested. Infested machines can be scrubbed and have their OS reinstalled from secure media, the NAS serves as the place to restore the data from. (There's the risk to get infested data back. All the NAS can do for that is to provide older versions, in the hope a clean copy is available.)
Advice for securing the LAN via no-appliances, VPN, no-Wifi, internal-firewalls etc. policies is valuable in general, but in this thread, I want to concentrate on securing the NAS itself, while facing a LAN with potentially-compromised workstations.
When safeguarding against potentially-compromised workstation, the chances for an infested Windows aren't that much different than those for an infested FreeBSD: Both may have been attacked through Javascript or an image decoding exploit, in the browser or in the mail client.
So for purposes of this thread, I am not interested in what I can do to secure the LAN, I am only interested in what I can do to secure the NAS itself.

* My plan is to make the NAS agnostic about the content of the data it is taking in. It is going to just shove it into a ZFS directory and never interpret anything in it.
That way, I don't need to care whether the data is infested, ransomware-encrypted, or whatnot.

* The data filesystem will have to be mounted read-write to allow adding more data.
For added security, the rsync pull will run inside a jail that has write access just to the ZFS directory where the data is being stored.
For even more added security, the data is exposed to the LAN in the form of read-only snapshots on a Samba server. If a user wants to play Russian Roulette with his data, he could even use SMB1, it's not the server that gets compromised with SMB1, it's the data.

* Pull vs. push: Pull puts the control over the schedule in a single place. That makes it easier to administer it. Or to shut down stuff in case of an emergency. Or to find out what the schedule is - no need to hunt down the machine and see how it's configured.
It's a bit awkward for users because changing the schedule requires going to the NAS and changing the configuration. OTOH it's rare enough that this isn't a big issue.
Also, I suspect that if the NAS makes it pull, ransomware will less likely spot that the data is being read for backup purposes, and not encrypt it. (This was a bigger issue when I still was thinking "let the Windows machine do the pushing through SMB", which ransomware would most likely spot.) Also, pull avoids giving the workstation and any ransomware on it a chance at overwriting stuff - it's the NAS that controls what writes happen, not the workstation.
Finally, the backup status (log, what snapshots exist, which of them are to be culled when) is easier to do if the control is fully on the NAS side.

* I put in "10 years" because "for the rest of my life" would be megalomaniac :)
Though I do hope to achieve "for the rest of my life". I just don't expect anything to hold up longer than a decade.
 

roccobaroccoSC

Well-Known Member

Reaction score: 93
Messages: 413

your assumptions make sense in my opinion. In this case just activate a well configured firewall on the NAS and take regular snapshots, you should be just fine. Open only one SSH port, deactivate password login and login with a key. For mounting, use SSHFS and mount read-only. Update the files via rsync.

Alternatively you could share your other machines' directories via SMB and the NAS can mount them and rsync automatically. This should also be reasonably secure, but use a good password and create a separate SMB account for the NAS, for example nas@YOURWINDOWSPC with a strong password.
 

Trihexagonal

Daemon

Reaction score: 847
Messages: 1,465

I put in "10 years" because "for the rest of my life" would be megalomaniac :)
Though I do hope to achieve "for the rest of my life". I just don't expect anything to hold up longer than a decade.
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.
And you expect to be using DSL10 years from now?
 
OP
OP
Toolforger

Toolforger

Member

Reaction score: 6
Messages: 20

Actually, yes, DSL for the next 10 years - the installation guy didn't find a free duct to put the fibre in, but there was a functioning copper wire so I settled for DSL.
Turns out our 30MBit DSL is good enough for a two-person household with limited upload requirements.
It's unlikely that I'll change that before I move out, which will be in ~15 years if personal and professional plans work out :)
But, sure, things might change. I'm in Switzerland, they might decide that DSL

No sshfs for me - it failed me once by silently storing data locally instead of over the wire when the connection went down, which is inacceptable design, and I don't trust software that contains inacceptable design choices.

One thing I wasn't sure about was how to connect to the Windows machines.
SMB would have worked, but too many strings attached. Plus FreeBSD's smbfs can't do SMB2/3 (one of the grand WTFs I have seen in my life - a security-minded project like FreeBSD doesn't even mention that smbfs requires SMB1, which is a security risk for the server... I almost cancelled using FreeBSD at all for that, I'm aware that not everything can be made shiny, but at least the docs about security issues need to be on-spot else you can't use it )
NFS doesn't have a security flag on it, but it has similar issues with user ids as SMB.
So I decided to stick with SSH&rsync. Permissions are easy to keep under control via publickey auth. I plan to restrict the publickey file so that the FreeBSD box cannot do anything but the specific rsync command it needs; that doesn't help with the "safeguard the FreeBSD box" mission but it keeps the individual client machines safer (not that I think that's ever going to happen, but "I think" are the first two words of a whole lot of Famous Last Words so I'll be just cautious anyway ;-) )
 

roccobaroccoSC

Well-Known Member

Reaction score: 93
Messages: 413

SMB would have worked, but too many strings attached. Plus FreeBSD's smbfs can't do SMB2/3 (one of the grand WTFs I have seen in my life - a security-minded project like FreeBSD doesn't even mention that smbfs requires SMB1, which is a security risk for the server... I almost cancelled using FreeBSD at all for that, I'm aware that not everything can be made shiny, but at least the docs about security issues need to be on-spot else you can't use it )
You could use the samba client from the samba package instead of smbfs. It should support higher protocol levels.

Also, you could install a FTP server on the windows machines and use FTP via SSL from your FreeBSD box. There are a number of FTP servers available for Windows and FreeBSD supports FTP out of the box, of course.
 
OP
OP
Toolforger

Toolforger

Member

Reaction score: 6
Messages: 20

I'm still shying away from Samba :)
Network discovery and getting the permissions right keep to be troublesome points.
Cygwin has its own set of hassles, but since I've been using it for years at least I know how to deal with those.

FTP would have to be secured; the solutions that I know are sftp (ftp over ssh) and ftps (ssl-encoded ftp).
sftp is back to using Cygwin ssh :)
ftps would work... I have used it on various occasions, and it usually required an extra tweak to work. I suspect ftps doesn't get the developer love that sftp is getting, because everybody already has ssh and sftp so there's almost zero incentive to improve ftps.

rsync-over-ssh still has two massive points in favor over FTP:
  • Repeatedly pulling the same data is MUCH faster than FTP.
  • It's going to be used with the Linux clients anyway, so sticking with rsync uniformly is going to be much simpler.

Thanks for mentioning FTP though; I hadn't evaluated it properly, so I wouldn't be aware what kinds of roadblock should make me consider FTP even if I don't want to use it.
 

roccobaroccoSC

Well-Known Member

Reaction score: 93
Messages: 413

FTP can be easily secured, you don't need Cygwin. There are a lot of FTP servers for Windows, just search on the web.
I personally have used FileZilla long time ago and it worked.

About the performance: rsync copies differences, indeed. FTP does not need to be dumb though, take a look here: https://serverfault.com/questions/24622/how-to-use-rsync-over-ftp
They cite a program called csync that could allegedly do something similar.
So this counters your objection #1.

Point #2: FTP is just as standard on every Unix, MacOS and Windows, so you don't need to worry about avaiability of a client software. Not only that, FTP is actually installed by default on FreeBSD AND Windows, while rsync not. So FTP actually beats rsync in this aspect by a small margin.
Regarding your server software - whether you install Cygwin for sshd or FileZilla or whatever other FTP server software, it does not matter - you still need to install something. Cygwin is a kind of hack, it's not natively developed for Windows. On the other hand FTP servers specially for Windows have probably integrated monitoring, control and autostart.

If you prefer sshd, then install it, but FTP could be just as good. I would not rule it out without first taking a look and making sure the objections still hold.

By the way, FTP over SSL could be really nice if you configured the server to require a specific client Certificate for authentication. In this way you could use it like HTTPS and login with certificate. SSH also supports certificates though. So I would put them next to each other, they do the same job after all.
 
OP
OP
Toolforger

Toolforger

Member

Reaction score: 6
Messages: 20

csync isn't ready yet. Quote from the user manual: "The contents of a path could be a file, a directory or a symbolic link (symbolic links are not supported yet)."
(I need something that does a full system backup for Linux anyway, so I have block devices/pipes/whatever, considerations for file system boundaries, and such. The option list for the rsync command is pretty long and well-curated. csync would be an option if I hadn't already decided to leverage the Linux-specific features of rsync.)

#2: An FTP client is standard, an FTP server is not. The FreeBSD box needs to be the client to be able to control the process.

#3. Setting up a PKI is MUCH more work than distributing an SSH key to all machines that need it.

#4. FTP still cannot do partial file transfers. rsync transfers just the blocks that changed (each side checksums a block and they negotiate whether a specific block really needs to go over the wire). I do not think FTP or SMB can do that.

There's also the fact that rsync has more than a decade of flawless proven operation behind it, while csync is unproven.

I wasn't aware of csync, so thanks for mentioning it. It might fit other jobs that I have in the future.
 

roccobaroccoSC

Well-Known Member

Reaction score: 93
Messages: 413

I personally prefer using SSH for all transfers. I do not use Windows or Mac, so I have the advantage for simply using the same tools - rsync and SSHD.
 

roccobaroccoSC

Well-Known Member

Reaction score: 93
Messages: 413

#4. FTP still cannot do partial file transfers. rsync transfers just the blocks that changed (each side checksums a block and they negotiate whether a specific block really needs to go over the wire). I do not think FTP or SMB can do that.
FTP can do partial transfer:
ftp()
restart marker
Restart the immediately following get or put at the indicated
marker. On UNIX systems, marker is usually a byte offset
into the file.

I don't know if the FTP client program supports transferring only the modified parts of a file: csync. I am surprised that rsync can do this, it's quite tricky to determine which parts are the same and wich are not - for this a file needs to be compared somehow by parts. If it can indeed do it, respect - use rsync.
 
OP
OP
Toolforger

Toolforger

Member

Reaction score: 6
Messages: 20

rsync works by SSH-ing into the remote server, and telling it to start its version of rsync. Each rsync process then does the checksumming on its own side.

FTP can do partial transfers, but last time I looked at the FTP protocol (to be fair: a decade ago), it didn't have commands to transfer checksums. And even if the FTP protocol has the command, both server and client will have to implement it, in a compatible fashion (which isn't always the case for FTP, for historical reasons).
FTP comes with so many strings attached that I haven't considered using it for more than a decade. Essentially, since rsync came along, which can do everything that FTP does but in a sane and controllable fashion :)
 
Top