Slashdot Mirror
Encrypt NFSv4 with TLS Encryption Using Stunnel (linuxjournal.com)
The systems and database administrator for a Fortune 500 company notes that while NFS is "decades old and predating Linux...the most obvious feature missing from NFSv4 is native, standalone encryption." emil (Slashdot reader #695) summarizes this article from Linux Journal:
NFS is the most popular remote file system in the Linux, UNIX, and greater POSIX community. The NFS protocol pushes file traffic over cleartext connections in the default configuration, which is poison to sensitive information.
TLS can wrap this traffic, finally bringing wire security to files vulnerable to compromise in transit. Before using a cloud provider's toolset, review NFS usage and encrypt where necessary.
The article's author complains that Google Cloud "makes no mention of data security in its documented procedures," though "the performance penalty for tunneling NFS over stunnel is surprisingly small...."
"While the crusade against telnet may have been largely won, Linux and the greater UNIX community still have areas of willful blindness. NFS should have been secured long ago, and it is objectionable that a workaround with stunnel is even necessary."
TLS can wrap this traffic, finally bringing wire security to files vulnerable to compromise in transit. Before using a cloud provider's toolset, review NFS usage and encrypt where necessary.
The article's author complains that Google Cloud "makes no mention of data security in its documented procedures," though "the performance penalty for tunneling NFS over stunnel is surprisingly small...."
"While the crusade against telnet may have been largely won, Linux and the greater UNIX community still have areas of willful blindness. NFS should have been secured long ago, and it is objectionable that a workaround with stunnel is even necessary."
NFS is unencrypted exactly because of the overhead it brings and the fact that within a small network the risk is relatively small to non-existent.
NFS has a number of assumptions that WAN links don't provide (eg stability). Use a different protocol if you want security and stability over WAN.
Custom electronics and digital signage for your business: www.evcircuits.com
it's a Unix philosophy: lots of smaller tools working well together instead of one big tool that tries to do everything and just turns into a mess.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
I'm in shock!
Speak any English?
it is objectionable that a workaround with stunnel is even necessary.
What's really objectionable is that people don't read the documentation and know about the features that are in NFS
Namely sec=krb5p
Perhaps retrofitting an old protocol isn't worth it when newer options exist.
NFSv4 _does_ have native encryption, but it requires the use of GSSAPI (kerberos).
From the article:
The sec=krb5p option will encrypt NFSv4 traffic in a Kerberos realm, but requiring this infrastructure is inappropriate in hosted environments and is generally far from helpful. Basic access to symmetric cryptography does not and should not mandate such enormous baggage.
What you quoted was commentary added by the submitter and was not from the article.
NFS is no good outside of locally-controlled networks anyway. If you need encryption, you already need something different from NFS.
And I can't stand NFSv4; it's not flexible enough. I use v3 so as to able to export exactly the directories I want to.
"If I use stunnel (or a VPN or ...), the problem is solved"
What a fucking dolt.
Quite contrary to popular myth telnet is able to do encryption if enabled.
Brilliant observation Captain Obvious.
Are you the author of the Linux Journal article or something? You've posted two or three times now (already) this bit from the article. You seem to be quite defensive about it.
And I don't agree that KRB5 is "enormous baggage."
Nothing at all wrong with using a layered approach, Running NFS over stunnel or other layer is exactly what you should do. There is therefore no reason why encryption has to be in NFS. People also have run Telnet over SSL. Isnt this the Unix way?
I use sshfs. Problem solved!
With the increasing numbers of built-in exploits in Intel CPUs, why does NFS encryption even add anything in the shared hosting environment that this article refers to?
I found the LJ article by Charles Fisher to be clear, balanced, well-written, and as a freely available contribution to the rest of us, helpful. Thanks Charles and LJ!
If you're that worried about your LAN, you can always throw in openvpn to fix pretty much any other protocol that doesn't do things for itself.
You could also do NFS over IPsec.
NFSv3 could be fine as well.
Often no need for complicated designs like NFSv4 and Kerberos.
I love sshfs. It is incredibly easy and convenient and works in places where nfs would be really hard to implement. It allows me to mount any file system on the ssh server, including file systems that are NFS network mounted themselves.
However, I have found that sshfs is not very fast or stable. The sshfs mounted file systems will sometimes hang, even when my ssh terminal sessions remain up.
Maybe I should contribute to development.
End-to-end encryption.
SMB Multichannel (multiple connections per SMB session)
SMB Direct Protocol (SMB over remote direct memory access (RDMA))
I'd be willing to bet that Let's Encrypt is responsible for freely decrypting TLS traffic at the behest of various state actors.
You get what you pay for!
> It also makes maintainence easier. Each application protocol having its own encryption leads to a lot of wheel reinventing and unnecessary man hours maintaining software.
I do vulnerability scanning and weak encryption issues are very common. Weak protocols, weak certs, etc. Often these are on devices or services that people don't think about very often. Using an ipsec or similar VPN tunnel between sites means EVERYTHING going over the wire is encrypted properly, by maintaining just one configuration. You may also want some things encrypted on the local network.
moot with spectre meltdown like exploits....
Why noto plain SSH TCP forwarding?
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
Linux has documentation? I've found most of it horribly outdated.
Only the State obtains its revenue by coercion. - Murray Rothbard
The author is a fucking idiot.
If you arenâ(TM)t using Kerberos and ldap you are doing it wrong.
He goes on about nfs in fstab, while admitting he ignores autofs. Again wrong.
This is a bit on the goofy side for /. Who didn't know NFS is insecure? Neither is CIFS/Samba, they're both insecure and from my perspective these are the two most used network file system protocols used in Linux.
And since NFS is been insecure since...forever. I've never used this thing not-over-a-VPN or only on LANs. Traditionally, NFS was not really used across WANs due to poor linkspeed across such WANs, and I seem to recall NFS being horribly bad on slow links. So no one really cared about securing it because no one really ran NFS over the public internet. I certainly never did. I still don't. My network file system protocol of choice is CIFS/Samba over VPN, because it's just what I've always used. Windows didn't always support NFS, though I believe it does now.
Of course this mentality came from an age before WiFi and broadband internet. I'd have to guess most of use don't fool with goofy stunnel setups when a VPN does the trick nicely, and provides security to a lot more than just NFS. Personally, I consider stunnel to be what people used when they can't figure out how to create point-to-point VPN between two locations. Sticking only one protocol into an encrypted stream kinda gives a leg up to a would be interested third-party.
Better to have lots of different stuff passing through encrypted pipes. I've been there, I've used it, but I don't anymore.
"there is no reasonable solution for this kind of bug. There will always be a danger of deadlocks when using openvpn."
openvpn should behave the same as stunnel - a userspace program handling the data
I use NFS all over the place on my home network, purely because it's my home network and my good old residential router doesn't forward any ports from outside for NFS or open them on the firewall. My NFS server exports all my media so that my media clients around the house can mount the movies directory or whatever as if it were local. I also use it to mount my MAME ROMS directory for my RetroPie setup in the living room. Very handy. Since the NFS server won't talk to anything other than 192.168.1.* via it's own firewall it works very well. I'm not familiar with the history of NFS but did NFS used to be used from remote sites over the Internet or something? I suppose I can see a use for encrypted NFS over business networks if the LAN is huge and paranoid but wouldn't Samba or something be better in that situation? Honest questions.
*I* am the author of the Linux Journal article, and your insistence on the Kerberos baggage means that ad-hoc connections that are not part of a realm must go unencrypted. This is bad enough when I'm at work trying to mount a server behind my cable modem, but it becomes truly objectionable when cloud providers push the same unencrypted protocols. And before you tell me that ipsec or openvpn will solve all of my problems, read the wireguard commentary.