Home / server / Questions / 363236
In Process
anonymous-one
Asked: 2012-02-24 16:21:49 +0800 CST

NFS server + client : Recommended hardening / final touches

  • 772

We have just setup a lovely little nfs share / client for the first time.

a) The UID for files on the client side, is showing up as 4294967294 when listed via ls, but the client is able to create and remove files / dirs in the share. Files and folders created on the client end, show up with the correct username (and uid) on the server side. We made sure that the users writing to the share have the same UID on the server end.

The following shows up for all files / folders on the client side:

drwxr-xr-x 6 4294967294 4294967294 4096 Feb 23 16:04 foldername

Is this ok?

b) Does anything need to be done with portmap / the nfs daemons to completely disable any nfs (or rpc*, as it was not installed prior to this) services from running on our external interface? Ideally we would like to bind the services just to our lan and vpn subnets.

c) What is the ideal way to make the nfs client side as aggressive as possible on reconnection attempts? Ideally, if the network connection is lost at any time, the nfs client side would keep trying often, and indefinitely. Is it possible to accomplish this via fstab? Or does nfs client by default already do this? The LAN side, where the nfs shares are shared, is a 1GBit connection.

d) Anything else?

Over and out.

nfs hardening rpc

2 Answers

  1. I'm only answering the security question here, since that's what I have the most experience with.

    NFS is tricky to secure. The most important thing I could recommend is to use NFS4 with GSS authentication mechanisms, but I'll continue to answer as though you are using NFS3 (or even NFS2).

    • Specify IPs, hostnames, or netgroups in your exports file. Never export to *, since this allows anyone anywhere to access your share.
    • Never use the insecure or no_root_squash export options. secure keeps the server's trust limited to root on the client, not just any user, and root_squash remaps requests by root to nobody, preventing access to sensitive system files through the share.
    • As you are already trying to do, do not allow access to the portmapper, rpc.nfsd, or rpc.mountd from the Internet. A good network setup (firewalls, router ACLs, etc.) will ensure this, but the -i option to portmap and using the hosts.allow file to limit access to local IPs are also good ideas.

    If you want to test your setup for security issues, I've written a Python program for bypassing basic NFS security mechanisms, NfSpy. Feel free to try it out and see if you can access your export in ways you didn't expect.

    P.S. Regarding client reconnection attempts, see the MOUNT OPTIONS section of the nfs(5) manpage. In general, the retrans and hard/soft options control what you want, but on a per-request basis. The mount itself will stay up even if the server goes down for extended periods. These settings determine how specific requests (read, write, etc) are handled.

    • 5

  2. This is a very wide topic really, and nothing that can be answered quickly with a single post. I think you should start by reading some of the many guides on hardening and best practices for NFS servers and clients.

    I ran a quick search in google and found two links that might interest you:

    Securing NFS

    Linux NFS-HOWTO

    (Contains best practices and many other good info about security and tweaking)

    • 1