Menu
For securing NFS (Network File System), the mount option krb5p can be used to encrypt all traffic between the file server and the NFS client. Authentication and key exchange is based on Kerberos.
Here is an example on how to configure that for Debian: https://wiki.debian.org/NFS/Kerberos
Unfortunately, there seems to be no way to configure the cipher used for this transport enryption. What cipher is used and how can this be configured, selected, or enforced?
486
NFS uses DES to encrypt a time stamp in the remote procedure call (RPC) messages sent between NFS servers and clients. This encrypted time stamp authenticates machines just as the token authenticates the sender.
Secure NFS uses DES encryption to authenticate hosts involved in RPC transactions. RPC is a protocol used by NFS to communicate requests between hosts. Secure NFS will mitigates attempts by an attacker to spoof RPC requests by encrypting the time stamp in the RPC requests.
That's why NFSv3 is considered to be as secure as the weakest NFS client in the environment. NFSv3 also does not provide any transit encryption. GIAC Gold Jakub Dlugolecki 12 if an NFSv4 client host is compromised, an attacker has to provide active Kerberos ticket in order to get NFS data.
NFS itself is not generally considered secure - using the kerberos option as @matt suggests is one option, but your best bet if you have to use NFS is to use a secure VPN and run NFS over that - this way you at least protect the insecure filesystem from the Internet - ofcourse if someone breaches your VPN you're ...
Without having used NFSv4 with Kerberos but used it in many other places, you are referring to confidentiality provided by the GSS-API through Kerberos which is implemented with gss_wrap(3)/gss_unwrap(3). It provides a quality of protection parameter but I am quite certain that NFSv4 will leave it null => at discretion of the mechanism.
Anyway, given that GSS-API completely abstracts from the mechanism, you probably have no choice but you still can do something about it. Enable in your KDC at least RC4, at best AES128 and AES256. Implementations will use best available cipher. You can scan traffic between the client and TGS (TGS-REQ and TGS-REP), client and server (NFS) to see which encryption type has been negotiated and this will highly be used for wrapping/unwrapping. You can always read the RFCs as I did but this will take a lot of time to understand.
Hope this helps. Of course, I could be completely wrong about NFSv4 internals.
Just made some digging and I am quite certain now that my analysis is correct. RFC 7530, chapter 3.2.1 talks about Kerberos 5 mandatory privacy for krb5p as well as AES along with HMAC-SHA1. Further reading leads to the RFC 2203 (RPCSEC_GSS spec) which talks about gss_wrap/gss_unwrap.
76
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
