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!
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.
Newer =/= better. Sshfs is painfully slow compared to NFS.
Man take a chill pill. He was just discussing that telnet has the ability to do encryption that's it. The article was poking fun at telnet. Besides telnet has some great terminal support still.
Written by a millennial that doesn't know about IPSec
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.
> 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.
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
For a while when sshd was having numerous buffer overflows telnet made more sense :)
Only the State obtains its revenue by coercion. - Murray Rothbard
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.
Yes, because it is so very easy to get cloud servers, external vendor clients and servers, and internal sites in different domains into the same realm. You must do this every day.
...and when it runs on Windows 7, it will be an option.
Please see the Wireguard addendum.
You don't send your private key to a CA for their signature. You send a public key embedded in your cert, which they encrypt with their private key. Their signature attests for you, but they can't decrypt without your key, which you (hopefully) never sent.