Ransomware - Best Practices - Restrict share permissions (NFS Shares)

  • 8 October 2021
  • 4 replies
  • 1429 views

Userlevel 2
Badge +9

What are The Best Practices for restricting NFS share permissions?

Our storage supports NFSv3, NFSv4, NFSv4.1, LDAP Domain Settings and NIS Domain Settings.

 

NFS Shares supports “Network group” (network group name configured in the LDAP or NIS domain)

 

What are the Recommended options on... 

Permission Constraint: 

  • all_squash: The user ID (UID) and group ID (GID) of a shared directory are mapped to user nobody
  • no_all_squash: The UID and GID of a shared directory are reserved

root Permission Constraint:

  • root_squash: The client cannot access the storage system as user root. If a client accesses the storage system as user root, the client will be mapped as user nobody.
  • no_root_squash: allows a client to access the file system as user root that has full control and access permissions for shared directories. If a share is used to create a VM, no_root_squash is recommended.

Source Port Verification:

  • secure: If secure is selected, clients can use ports 1 to 1023 to access NFS shares.
  • insecure: If insecure is selected, clients can use any port to access NFS shares.

Anonymous User ID (Set the UID and GID of the user accessing the shared directory who is mapped as an anonymous user)

 

CommServe runs Windows 2016.

Media Agent Servers runs Linux OS. 

CommVault FR 11.24.12

 

 


4 replies

Userlevel 7
Badge +23

Hi @Eduardo Braga !

I’m speaking to some of our Ransomware experts and will circle back when I get more, though in the meantime I converted this topic to a Conversation to encourage others to share their thoughts.

Userlevel 2
Badge +9

Hi @Eduardo Braga !

I’m speaking to some of our Ransomware experts and will circle back when I get more, though in the meantime I converted this topic to a Conversation to encourage others to share their thoughts.

Mike, Sorry to bother you. Any news about that? 

 

CommServe runs Windows 2016 (FR 11.26.3)

Media Agent Servers runs Linux OS (updated). FR 11.26.3

Userlevel 7
Badge +23

No bother!

I’ll reach out to some folks again.

Userlevel 3
Badge +6

NFSv3 performs better over low-latency connections but has only basic IP address-based security. As Commvault runs as root, using any sort of squash is likely to create issues with access to the share unless you make everything on the share world R/W which is likely to be higher risk than the alternative.


NFSv4 performs better over high-latency connections but these are uncommon for this use case; your library is generally going to be physically close to your MA. NFSv4 does have more granular security options, however because Commvault will always be running as root, they are unlikely to give you much if any additional flexibility.


My personal suggestions -- these do not come from Commvault at large -- would be to use NFSv3 and restrict R/W access to the IP of the MA(s). 


Implement the ransomware protection feature to prevent non-Commvault processes from modifying that data: https://documentation.commvault.com/11.24/expert/126096_configuring_ransomware_protection_for_disk_library_on_nfs_share.html

 

I would also recommend using the noexec and nodev mount options for a little extra security, as there's no reason for anything to be executed from that share or for device files to exist on it. I usually include noatime as well, though the performance benefit is likely to be undetectable.
 

Example fstab line for NFSv3:

host:/export  /srv/commvault/lib2  nfs  default,local_lock=none,noatime,nofail,noexec,nodev,nfsvers=3,context="system_u:object_r:cvstorage_t:s0"  0 0

Or for NFSv4:

host:/export  /srv/commvault/lib2  nfs4  default,local_lock=none,noatime,nofail,noexec,nodev,nfsvers=4,context="system_u:object_r:cvstorage_t:s0"  0 0

 

Reply