Securing NFS?

[dcrdev 255]

Are any Linux users out there securing nfs in any way?

 

I'm contemplating moving over to nfs from sftp, but am a little uneasy about security which with the base configuration seems to rely on ip addresses, group/user id's - which can all be spoofed with little to no effort. From my own research - it seems that the only viable options are:

 

• Setting up kerberos authentication, but this seems more like a system-wide authentication system.
• Restricting nfs to loopback and tunnelling it over ssh.

Are either of the above two ideas, good ones? Or does anyone else have any suggestions?

 

My motivation for wanting to move to nfs is having better support for acl style permissions on the client side.

[mastrmind11 722]

Are any Linux users out there securing nfs in any way?

 

I'm contemplating moving over to nfs from sftp, but am a little uneasy about security which with the base configuration seems to rely on ip addresses, group/user id's - which can all be spoofed with little to no effort. From my own research - it seems that the only viable options are:

 

• Setting up kerberos authentication, but this seems more like a system-wide authentication system.
• Restricting nfs to loopback and tunnelling it over ssh.

Are either of the above two ideas, good ones? Or does anyone else have any suggestions?

 

My motivation for wanting to move to nfs is having better support for acl style permissions on the client side.

You mean internally?  I can't speak to much of this since I assume anyone internal special enough to gain access to my internal network is trusted, but linux's user/group security has worked since the dawn of time.  If you need higher security than linux u/g permissions, I either have to question whether you're setting up an emby server in a minimum security white-collar prison, or are paranoid to the point of a faraday cage house.  Mostly kidding, but really want to hear why...

[dcrdev 255]

Yeah internally -

 

I'm not doubting Linux's user/group security, but say for instance if someone had access to my physical machine...

 

• I could set up an nfs export, restricted to the user John (uid 1000), the group Files (gid 1001) and the ip 192.168.1.101.
• Now anyone connected to my network wouldn't be able to access that export unless using the ip 192.168.1.101.
• The machine assigned to 192.168.1.101 wouldn't be able to access that export unless the user was a member of a group with the id 1001, or was the user with id 1000. That's fine I control who uses the machines on my network, it's protected with disk encryption, selinux etc...
• However someone with physical access to the running machine could plug it into another network, assign the ip 192.168.1.101 to another machine and create a user and group with the id's 1000/1001. If I left this gap open, then there wouldn't be much point in the multiple layers of disk encryption, disablement of Intel ME and many many other measures I've taken to lock down the machine.

That all might sound insanely paranoid and over the top and... well it is - I'm not trying to hide anything and well I really have no good explanation lol

Edited December 22, 2017 by dcrdev

[dcrdev 255]

Spent far too much time on this:

[root@hell01-ws01 bin]# cat secure_nfs
#!/bin/bash
REMOTE_SERVER="hostname.domain.com"
LOCAL_PORT=2049
REMOTE_PORT=2049
REMOTE_PATH="/storage"
USER="$1"

function help(){

	echo "Usage example:";
	echo "`basename $0` [(-m|--mount) string] (-u|--unmount)";
	echo "Options:";
	echo "-m or --mount string: Tunnels the NFS Export.";
	echo "-u or --unmount: Unmounts the NFS Export.";
	exit 1;

}

tunnel () {

	local user="$1"
	mkdir -p "/mnt$REMOTE_PATH/"

	mount -t nfs "localhost:$REMOTE_PATH" "/mnt$REMOTE_PATH/" | \
	ssh -i "/home/$user/.ssh/id_rsa" -NT \
	  -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes \
	  -L "$LOCAL_PORT:localhost:$REMOTE_PORT" \
		 "$user@$REMOTE_SERVER"
	exit 0

}

safeUnmount () {

	umount -lf "/mnt$REMOTE_PATH/"
        sleep 3
	exit 0

}

unmount=0;
ARGS=$(getopt -o "m:u" -l "mount:,unmount" -n "tr" -- "$@");

if [ $? -ne 0 ];
then
    help;
fi

eval set -- "$ARGS";

while true; do
	case "$1" in
		-m|--mount)
			shift;
			if [ -n "$1" ]; then
				tunnel "$1";
				shift;
			fi
		;;
		-u|--unmount)
			shift;
			safeUnmount;
		;;

		--)
			shift;
			help;
		;;
	esac
done

[root@hell01-ws01 system]$ cat secure_nfs@.service
[Unit]
Description=Secure NFS Mounting Daemon
Wants=network-online.target
After=network.target network-online.target

[Service]
ExecStart=/usr/local/bin/secure_nfs -m %i
ExecStop=/usr/local/bin/secure_nfs -u
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

[dominic@hell01-serv01 ~]$ cat /etc/exports
#
# /etc/exports
# Created on Sat Dec 22 16:24:00 2017
#
#
/storage                                   localhost(rw,sync,wdelay,nohide,crossmnt,no_subtree_check,mountpoint,sec=sys,insecure,no_root_squash,no_all_squash)

Lol

Edited December 22, 2017 by dcrdev

[mastrmind11 722]

damn bro, why so paranoid? 

[dcrdev 255]

Had to redo it slightly -

 

Systemd was sending SIGHUP which was killing the tunnel before the catch kicked in, causing the unmount to stall and ultimately stall the service from exiting. I've redone it with arguments -m for mount -u for unmount, the systemd unit calls -u in the ExecStop directive.

 

Well gotta say I'm pretty happy with that - encrypted/key protected NFS has never been so easy.

[mastrmind11 722]

I have to direct you to my previous post

[thefirstofthe300 292]

At some point, you have to look at *who* you are trying to protect yourself from and decide if NFS will open up an attack avenue for that party. If it won't, go ahead with the NFS implementation. Otherwise, avoid it.

 

Doing something fancy with the implementation, i.e. export to loopback and tunnel out over SSH will almost certainly be more hassle/wasteful than it's worth IMHO.

 

Security, imho, is more about making it sufficiently difficult to prevent attackers from accessing the server while not making the server impractical to use due to all of the security measures in place.

 

In this case, it sounds like you are concerned about people with physical access to the box. If that is the case, the most productive security measures you could take to protect the NFS shares would be to secure the network (no unauthorized/untrusted devices can be added) and take steps to protect the physical hardware (server cage???). It seems like such steps should mitigate your concerns about the NFS shares.

 

If either of those steps are impractical, the move to NFS is likely not worth it.

 

I hope I'm not coming across as dismissive. I just want to help you see that you need to break down what your expected attack vectors are and decide if NFS is capable of properly securing the expected attack vectors natively. If it's not, you should probably be looking at another solution or stay with what you have.

 

Sent from my Pixel 2 XL using Tapatalk

[dcrdev 255]

No I get why you are being dismissive - sounds ridiculous I know, it's just something I want to do.

 

At the end of the day I need NFS for what I'm intending to do - it's the only file transfer protocol with proper posix acl integration.

 

The ssh tunnel is working out quite nicely - it runs as a systemd service, is available shortly after boot and is portable outside the network - should I need it to be; there doesn't appear to be any degradation in speed either. I've even taken it as far as packaging it as an rpm, that I can deploy to all my machines via my repo.