Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Encryption Cloud Networking Linux

Encrypt NFSv4 with TLS Encryption Using Stunnel (linuxjournal.com) 83

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."
This discussion has been archived. No new comments can be posted.

Encrypt NFSv4 with TLS Encryption Using Stunnel

Comments Filter:
  • by El Cubano ( 631386 ) on Saturday August 18, 2018 @11:43AM (#57149888)

    sec=krb5p

    • by Anonymous Coward

      They said standalone. Keberos isn't lightweight. There is quite a bit of administrative overhead that isn't woth the squeeze for small groups.

      • by cruff ( 171569 )
        It is true that the Kerberos infrastructure is a bit of a pain, but it does work well when you have it in place.
      • Administrative overhead? You aren't running Active Directory in your environment?

        True the tools used to onboard *NIX (except solaris) are pretty shit (I'm looking at you SSSD).

        For AD when generating your keytabs you need to salt the keys with the internal UPN (ie: samaccountname@ad.domain, minus the dollarsign for computer accounts) for every principal assigned to the account, but once you know that is is trivial to script the onboarding.

        Then you just need to ensure your service accounts that use NFS
    • IPsec (Score:4, Insightful)

      by pD-brane ( 302604 ) on Saturday August 18, 2018 @01:49PM (#57150466) Homepage

      You could also do NFS over IPsec.

      NFSv3 could be fine as well.

      Often no need for complicated designs like NFSv4 and Kerberos.

      • by emil ( 695 )
        Wireguard has biting criticism of ipsec and openvpn. If you can stand the UDP and you're on a supported platform, it's likely far preferable. See the addendum.
  • by guruevi ( 827432 ) on Saturday August 18, 2018 @11:43AM (#57149892)

    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.

    • Re: (Score:3, Insightful)

      by iggymanz ( 596061 )

      actually, NFS has encryption option, and the article tries to justify this extraneous stunnel solution by stating "waaah, it's too hard to do the built in..." which is bullshit

      You can do NFS securely and without stunnel. end of story.

      • ...unless the story takes you to clients and servers of an external vendor/customer, to your cloud provider, or to internal sites in other divisions that will not participate in a realm.
    • You will see in the conclusion the FBI advisory to reboot Soho routers. Generally, end users cannot maintain firmware or patch broadband devices. Encrypting everything it can touch, and keeping internal devices patched, is hardly unreasonable.
  • by rsilvergun ( 571051 ) on Saturday August 18, 2018 @11:49AM (#57149924)
    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.
    • 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.

      Now, now, we’re only a few comments in and already someone’s complaining about systemd...

  • by Anonymous Coward

    I'm in shock!

    • by Desler ( 1608317 )

      Slashdot has had political articles for nearly 2 decades. From example, [url=https://slashdot.org/story/98/12/16/1930206/us-and-uk-unilaterally-attack-iraq]here[/url] is one from 1998 that was heavily political. Cry more, snowflake.

    • by Desler ( 1608317 )

      Slashdot has had political articles for nearly 2 decades. From example, here [slashdot.org] is one from 1998 that was heavily political. Cry more, snowflake.

  • by sydsavage ( 453743 ) on Saturday August 18, 2018 @12:12PM (#57150016)

    NFSv4 _does_ have native encryption, but it requires the use of GSSAPI (kerberos).

    • Re: (Score:3, Informative)

      by Desler ( 1608317 )

      Yes and the article addresses that:

      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.

      • Re: (Score:2, Informative)

        by iggymanz ( 596061 )

        "addressing" the issue by saying "wahhh it's way too hard", man up you pansies, kerberos isn't that hard

        • NFS was never meant to be used across WAN links.

          • WAN links and networking have evolved much over the lifespan of NFS. It can be done over WAN now with no problem.

  • Why noto plain SSH TCP forwarding?

    • Easy answer... Stunnel runs out of inetd, and it supports client=yes in that configuration. A wrapper will also coerce it to observe restricted ports. This is much friendlier than ssh.
  • 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

  • nfs over openvpn locks up [kernel.org] = CLOSED WILL_NOT_FIX

    "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'

The Tao is like a glob pattern: used but never used up. It is like the extern void: filled with infinite possibilities.

Working...