Securing NFS beyond /etc/exports

[Olivier Masse]

Almost everything that relates to NFS Security goes in much detail explaining how to add flags in /etc/exports. However, following a security audit I've had, I've been asked the following questions.

1. How can I prevent someone from easily guessing the NFS file handles? ... as fsirand doesn't work on vxfs filesystems.

2. How can I prevent someone from remotely disabling an rpc service?

3. How can I prevent the NFS server from accepting requests coming from an unpriviledged port?

Solaris seems to have tweaks to cover this, but I spend lots of time searching the ITRC and HP does not have many suggestions except putting rpc.mountd in inetd.sec which does not cover the cases above.

Any suggestions?

Thanks

[Todd McDaniel_1]

3) I am pretty sure NFS has to allow for listening to open ports. What are you calling unpriveleged ports?



You can add some other security to your box via /etc/hosts.allow; /etc/hosts.deny.

Use these files to deny and then grant access for certain daemons which use tcp protocols...

This will help you tighten your security.

Here is a sample of my actual /etc/hosts.allow and deny files. You may want to remove and add items to the hosts.allow if you dont have some of these items like SSH.

BTW, SSH might not be a bad idea either...

----------------------------------------------
# cat /etc/hosts.deny
# Deny all hosts
ALL : ALL

----------------------------------------------
# cat /etc/hosts.allow
#all : all : banners=/usr/localcw/opt/sysguard/banners : allow
ftpd : all : banners=/usr/localcw/opt/sysguard/banners : allow
telnetd : all : banners=/usr/localcw/opt/sysguard/banners : allow
tftpd : all : banners=/usr/localcw/opt/sysguard/banners : allow
logind : all : banners=/usr/localcw/opt/sysguard/banners : allow
rlogind : all : banners=/usr/localcw/opt/sysguard/banners : allow
remshd: all : banners=/usr/localcw/opt/sysguard/banners : allow
sidftpd : all : banners=/usr/localcw/opt/sysguard/banners : allow
rexecd : all : banners=/usr/localcw/opt/sysguard/banners : allow
sshd : all : banners=/usr/localcw/opt/sysguard/banners : allow

[Todd McDaniel_1]

Okay, on #2 I need a bit of background...

a) is rpc in jeopardy by other user's with root access killing the rpc daemons or is this a malicious attack?

b) When you say remotely... are you saying they disable the rpcd on the remote box or login remotely to YOUR master and kill rpcdaemons?



NFS by its nature is meant to be used by trusted systems, just my opinion.

IF you have serious security problems, I would suggest not using NFS and only use SSH logins on those boxes and secureFTP to transfer data back and forth.

[Andrew Cowan]

Firstly ensure that you never export any filesystem to "everyone", limit the hosts that have access, and where possible, export as read-only, and with nosuid.

If you really want to secure NFS and a lot of other protocols, install IP-SEC, and run tunelled communications between all your most vital hosts.

Another simpler to limit exposure is to setup a switched-network and to install multiple firewalls.

BTW. I think that you'll only have /etc/hosts.allow|deny when you install TCP-Wrappers. The default security file in HP-UX is /etc/inetd.sec, and neither of these will protect the portmapper.

[Olivier Masse]

I'm mostly challenged by people who recently secured Solaris systems, and it seems that Sun did some tweaks to increase the security of their NFS services somewhat over the years, especially the portmapper. There is not any documentation of Sun vs. HP's NFS security features.

rpc.mountd can be protected with inetd.sec, but rpcbind is still vulnerable.

NFS is required, I can't just remove (reason #1: 2 terabytes of data).

[Andrew Cowan]

As far as I am aware Sun produced what it calls a secure RPC, which means that Portmapper does not behave in the same way as the standard version used by the rest of the world.

Portmappers main weakness is that it does not validate connections and will therefore respond to any request.

Here are some docs regarding the Secure version
http://csrc.nist.gov/publications/nistpubs/800-7/node184.html