NFS and SSH

[Crystal_1]

Hi,

I was told SSH can mitigate risk of using NFS. Can anyone tell me about this more specifically?

Thanks,
Crystal

[Stefan Farrelly]

Yes, by tunnelling nfs through ssh - so that all nfs traffic is encrypted, and thus safe. Check out the details here;

http://www.math.ualberta.ca/imaging/snfs/

[Steven E. Protter]

SSH mitigates lots of risks.

Since passwords are encrypted, it prevents interception of root passwords.

As far as NFS goes, what risks specifically are you talking about?

If NFS is installed verison 3 or above and properly patched it is quite secure. It may not be as robust or easy to configure as CIFS/9000/Samba, but its pretty reliable.

Here is a search requiring three words, ssh nfs and risk.

If you specify the risk, I can address your question.

SEP

[Bill Hassell]

NFS by itself is not secure. The data is sent between the server and client exactly as it is stored on the disk...and sending this across a LAN is not a good idea as the LAN traffic can be recorded by rogue computers. By using ssh, all logins can be truly authenticated and individual keystrokes encrytped before they appear on the LAN. And by using sftp (Secure FTP), both the login and data transfers will also be encrytped. HP provide SSH free of charge from: http://sofware.hp.com

[Shannon Petry]

Im sorry, but I have to dis-agree with Steven Potter and his assessment of NFS V3. NFS version anything is insecure, as packets are not encrypted.

Anyone able to sniff a network can re-assemble the packets and reproduce data. Yes, it takes some expertise or tools to do, but once re-assembled the data is ready for use.

NFS does not encrypt, and even using secure mount options does not change the fact that the data is transmitted in a plain un-encrypted state.

SSH creates an encrypted channel for all methods of data exchange. So even if packets could be re-assembled in a proper order, the data would have to be decrypted in order to use.

When you look at the time and work involved in trying to decrypt the standard encryption type used in SSH (cypher or blowfish), it becomes virtually impossible.

Sincerely,
Shannon

[Crystal_1]

Thanks for all your input...

One application requires to use NFS on the background and therefore there will not be any manual login.

How does the SSH tunnelling work when the application daemon accesses information from other servers?

Since SSH can encrypt the packets through the network traffic. Does this mean using NFS via SSH is no longer insecure? What are the remaining risks?

Crystal

[Andrew Cowan]

If you want to use a variety of services such as NFS it is far easier to setup an IPSEC tunnel. The advantage here is that the individual programs will not even know this is hapenning.

[Todd Whitcher]

Hi,

HP does not provide a secure NFS product as mentioned above and NFS is insecure by nature as mentioned.

IPSEC can't be used to Secure an Application like NFS:

http://www.docs.hp.com/hpux/internet/index.html#IPSec/9000

From the HP IPsec Manual:

IPSec Limitations and Constraints

IPSec general limitations and constraints are described below:

Security for multiple destination addresses (i.e. broadcast, subnet broadcast, multicast, and anycast addresses) is not supported.


You cannot selectively encrypt or authenticate services that use dynamic ports, such as NFS (Network File System) mountd, NFS lockd, and NIS (Network Information Service).

http://www.docs.hp.com/hpux/onlinedocs/J4256-90001/J4256-90001.html

Secure Shell wont help w/ NFS you can use it for secure telnet rlogin remsh rcp ftp.
http://www.docs.hp.com/hpux/internet/index.html#HP-UX%20Secure%20Shell

The best thing to do is secure the networks where you have NFS Clients and Servers set up.

[Steven Sim Kok Leong]

Hi,

Mitigating risks should be a combination of security implementations. It really depends on what you are trying to secure. Are you trying to secure authenticity, confidentiality, integrity or availability?

In this case, I gather you will be most concerned with authenticity of the NFS server and clients and the confidentiality of traffic transmitted among them.

Some mitigating methods:

1) Install a network-based firewall upfront of all your NFS servers and clients so that the NFS services on your NFS servers cannot be accessed from the Internet and be exploited.

2) Running a switched network also mitigates the risk of traffic being sniffed on the network, assuming that your switches are physically secured.

3) Running host-based firewalls to limit accesses between your servers and clients for NFS services.

4) To prevent DNS compromises, use either split DNS with an internal DNS or rely on /etc/hosts by putting trusted entries into them. Remember to get /etc/nsswitch.conf to prioritise name search with /etc/hosts first.

Hope this helps. Regards.

Steven Sim Kok Leong

[Steven E. Protter]

Summary:

NFS 3 deals with he performance problems and security issues of NFS 2. The data goes across the network unencrypted and can be picked up by any computer on the LAN.

Installing Secure Shell 3.5 at both ends solves that problem? Without any additional configuration? I've been using Secure Shell for years and NFS, because thats how Ignite works.

I think the way to wrap up this thread with a solution(regardless of whether a rabbit is handed out), would be to post the documentation necssary to use ssh to secure NFS.

SEP

[Sridhar Bhaskarla]

Hi,

Just having ssh on both ends will not be sufficient to tunnel the NFS data through ssh. It's not simple port forwarding. You will need to get secure RPC code which is available at

http://www.math.ualberta.ca/imaging/snfs/

There is a bit of configuration involved. You may need to do some research on your own as there may not be many that are extensively using Secure NFS.

If you find it tough to configure Secure NFS, then you can go with Steven Simkok Leong's recommendations of minimizing the risks by enhancing the security.

-Sri

[Andrew Cowan]

I read Todd's reply to my earlier post about using IPSEC to tunnel NFS traffic and was wondering if had read it correctly? Todd quoted from the HP IPSEC Implementation manual, which states:

"You cannot selectively encrypt or authenticate services that use dynamic ports, such as NFS (Network File System) mountd, NFS lockd, and NIS (Network Information Service)."

Isn't the word "selectively" the key here. I wasn't suggesting that you encrypt some of the traffic between your hosts, but all of it. At my company we setup all our AIX systems to talk IPSEC to one another, but not to our client-pc's. In this way (IBM calls it transport mode) packets are encrypted at layer-2/3 and systems can be setup to deny access to hosts not using IP-Sec. Surely this would include NFS, or am I missing something here?

I'll hapilly admit if I'm wrong, but this point is key to our security policy, as the next stage is to get our HP systems to join the party, so any suggestions/comments are welcome.

[Andrew Cowan]

Further to my previous comment. If you look at:

http://www.docs.hp.com/hpux/pdf/J4256-90001.pdf Page 42. The policy configuration screen shows the option "Protocol=ALL" and I would have expected that selecting this would protect NFS?

I also looked at the other links in the earlier reply, and they are basically the same text.

Suggestions welcome.

[Todd Whitcher]

Regarding Andrews IPSEC Suggestion. He is correct that the manual is speaking to "Selectively" encrypting / authenticating the dynamically assigned ports w/ HPUX NFS ( rpc.mountd rpc.lockd rpc.statd ) Setting up a tunnel is a good suggestion if thats a route you want to take. Sorry for any confusion on that point.

Cheers,

Todd

[Andrew Cowan]

Hi Todd,

Thanks for clearing that up. I nearly had a heart-attack when I first saw your earlier post! :)

This is what I really like about forums, you can see a reply that makes you really question what you assumed you already knew.

Thanks,
Andrew

Hey, and Crystal, how about some points?