Escolar Documentos
Profissional Documentos
Cultura Documentos
Abstract
This paper provides guidelines on secure configuration of NetApp systems (including NetApp storage systems) running Data ONTAP. It is intended for storage and security administrators who wish to improve the overall security posture of their storage networks. For each configuration area, only the most secure settings are provided. Just as with any other information technology, an improvement in the overall level of security may result in a reduction in functionality or usability; put another way, most security problems can be viewed as excess functionality, and administrators should be cautious when applying these configurations to avoid interruption of required services. The second part of this paper provides a high-level discussion of Data ONTAP security concepts within the context of a documentation map that should allow security administrators to develop a good working knowledge of Data ONTAP security, even if they have no prior storage management experience.
Table of Contents
1. Best Practice Security Configuration ................................................................................................................... 3 1.1 Administrative Access .................................................................................................................................... 3 1.1.1 Role-Based Access Control ........................................................................................................................ 4 1.2 NFS Settings .................................................................................................................................................. 5 1.2.1 The /etc/exports File.................................................................................................................................... 6 1.3 CIFS Settings ................................................................................................................................................. 7 1.4 Multi-Protocol Settings ................................................................................................................................... 8 1.5 Network Configuration.................................................................................................................................... 9 1.6 System Services........................................................................................................................................... 10 1.6.1 Protocol Access Filter................................................................................................................................ 11 1.7 iSCSI Settings .............................................................................................................................................. 12 2. Security documentation map ............................................................................................................................. 12 2.1 Administrative Guidance .............................................................................................................................. 13 2.2 User Guidance.............................................................................................................................................. 17
TRUSTED HOSTS ACCESS Enables/disables the ability for certain hosts to access NetApp storage systems without authentication. Disable the trusted host option. filer# options trusted.hosts -
Procedure
Procedure
Access Rules It is important to make sure that the appropriate security options are used in the NFS export to prevent unsolicited clients from mounting or gaining elevated access rights to the desired volumes on the NetApp storage system. In the following example, suppose that you want to grant read-write permission on volume /vol/volx to host1, read-only permission to host2, and no other hosts can mount the volume. In versions of Data ONTAP earlier than 6.5, enter: /vol/volx -access=host1:host2,rw=host1
Security-Related Export Options The following NFS export options are related to security. It is important to note that these options should be used appropriately in order to secure the data in an NFS environment. anon This option specifies the effective user ID (or name) of all anonymous or root NFS client users that access the file system path. An anonymous NFS client user is an NFS client user that does not provide valid NFS credentials; a root NFS client user is an NFS client user with a user ID of 0. Data ONTAP determines a user's file access permissions by checking the user's effective user ID against the NFS server's /etc/passwd file. By default, the effective user ID of all anonymous and root NFS client users is 65534. To disable root access by anonymous and root NFS client users, set the anon option to 65535. To grant root user access to all anonymous and root NFS client users, set the anon option to 0 this is equivalent to the no_root_squash option in some other NFS servers. nosuid This option disables setuid and setgid executables and mknod commands on the file system path. Unless the file system is a root partition of a diskless NFS client, you should set the nosuid option to prevent NFS client users from creating setuid executables and device nodes that careless or cooperating NFS server users could use to gain root access. sec Starting with version 6.5, Data ONTAP supports the ability to specify multiple security (sec) options for each exported resource. The administrator can determine how secure NFS access is to the NetApp storage system. Basically, the following two security service types are supported. UNIX (AUTH_SYS) authentication (sys): Does not use strong cryptography and is the least secure of the security services. This is the default security service used by Data ONTAP. It is important to note that AUTH_SYS credentials are basically a user ID and up to 17 group IDs. Once logged in as a superuser on a UNIX system, one could use the su command to become a user who is allowed full access to a volume. One way to prevent this scenario from happening is to implement strong authentication mechanisms such as Kerberos.
Kerberos version 5: Provides the following three security methods: o Authentication (krb5): Uses strong cryptography to prove a users identity to a filer and to prove a filers identity to a user. o Integrity (krb5i): Provides a cryptographic checksum of the data portion of each request and the response message to each request. This defends against man in the middle tampering with filer NFS traffic. o Privacy (krb5p): Encrypts the contents of packets bidirectionally, including procedure arguments and user data, using a shared session key established by the client from the filer.
The following two examples show how the above security services are used: To specify one security type, you could enter: /vol/volx sec=sys,rw=host1 To specify multiple security types, you could enter: /vol/volx sec=krb5:krb5i:krb5p,rw=host1 For more information on setting up NFS using Kerberos authentication, refer to technical report http://www.netapp.com/library/tr/3481.pdf when a UNIX-based KDC is used, http://www.netapp.com/library/tr/3457.pdf when an AD-based KDC is used.
On the NetApp storage system: filer# options cifs.disable_server_smbsign off On the Windows client: Enable EnableSecuritySignature and RequreSecuritySignature parameters in the registry
ANONYMOUS CONNECTIONS (RESRICT ANONYMOUS) Enables/disables anonymous users from listing CIFS shares on the NetApp storage system Disable access to CIFS shares and sharenames from unauthenticated users. filer# options cifs.restrict_anonymous.enable on
CIFS BYPASS TRAVERSE CHECKING When on (the default), directories in the path to a file are not required to have the `X' (traverse) permission. This option does not apply in UNIX qtrees. Enable traverse checking by turning this option off. filer# options cifs.bypass_traverse_checking off
Specifies the UNIX user account to use when an NT user attempts to log in and that NT user would not otherwise be mapped. Set the option to a null string, denying access. NOTE: Perform this step ONLY on multi-protocol systems that have NFS/CIFS usermapping configured correctly; disabling this access on a CIFS-only NetApp storage system will result in access problems for legitimate users. filer# options walf.default_unix_user
Procedure Description Recommended Setting Procedure CHANGE PERMISSIONS Description Recommended Setting Procedure CACHE CREDENTIALS Description Recommended Setting Procedure
ROOT TO ADMIN MAPPINGS When on (the default), an NT administrator is mapped to UNIX root Disable root to admin mappings by default. filer# options walf.nt_admin_priv_map_to_root off
When enabled, only the root user can change the owner of a file. Allow only root access to change permissions to files filer# options walf.root_only_chown on
Specifies the number of minutes a WAFL credential cache entry is valid. The value can range from 1 through 20160 Set the minutes for 10 for cache credentials filer# options walf.wcc_minutes_valid 10
SNAP MIRROR SOURCE ACCESS Enables IP address based verification of snapmirror destination NetApp storage systems by source NetApp storage systems Enable source address verification. filer# options snapmirror.checkip.enable on
10
options ndmpd.access legacy Allow an NDMP server to accept a control connection request from any client. options rsh.access "host = gnesha.zo" Allow remote shell access for only one host, named gnesha.zo. options telnet.access host=10.42.69.1/24 Allow access for Telnet subnet 10.42.69. options ssh.access "host=abc,xyz AND if=e0" Allow ssh access for hosts abc and xyz when on network interface e0.
Command Description
options snmp.access if=e0,e1,e2 Allow access to SNMP for network interfaces e0, e1, and e2.
11
Command Description Command Description Command Description Command Description Command Description
options httpd.access "if != e3" Do not allow access to HTTPD for network interface e3. options httpd.admin.access host=champagne,tequila Allow access to administrative HTTPD for two hosts. options telnet.access "host=-" Disallow all access to Telnet. options snapmirror.access legacy Check access to sources from other NetApp storage systems. options snapvault.access all Allow a SnapVault server to accept any client requests.
12
interfaces and functions available to the users, describes the use of the user-accessible security functions, and includes warnings about user-accessible functions and privileges that should be controlled. Throughout both sections, frequent references are made to the Data ONTAP 7.0 documentation. This documentation is available on Network Appliance, Inc.'s web site at the following address: http://now.netapp.com/NOW/knowledge/docs/ontap/rel71
13
SecureAdmin product is installed and configured on the NetApp storage system. SecureAdmin provides many security advantages over administrative access via telnet, rsh, and http, and should be strongly considered by any customer who wants to maximize security. More information on Secure admin can be found in Chapter 9 (Using SecureAdmin) of the System Administration Guide. Additional documentation for the SecureAdmin 3.0 product is available at: http://now.netapp.com/NOW/knowledge/docs/saon/rel30/pdf/secadmin.pdf Once administrative access has been configured, the next step for managing a secure NetApp storage system is to organize your data. The most important documentation for this process is in Chapter 6 (Volume management) and Chapter 7 ("Qtree Management") of the Storage Management Guide. In particular, pay attention to the following sections: Chapter 7: Qtree Management Understanding qtrees. Creating qtrees. Understanding security styles. Changing security styles. Although the choices for Volume and Qtree security styles may seem confusing at first, the selection process is actually very simple for most customers. If a volume or qtree is to be accessed predominantly or exclusively by NFS clients, select the "unix" style. If a volume or qtree is to be accessed predominantly or exclusively by CIFS clients, select the "ntfs" style. If a volume or qtree is to be accessed equally by both NFS and CIFS clients and both types of clients need full control over file access security, select the "mixed" style. If a volume or qtree is to be used exclusively as a storage location for FCP or iSCSI LUNs, the security style has no effect.
When creating volumes and qtrees for data management, it is strongly recommended that data be organized by security requirements. For example, if the NetApp storage system will store data for two groups (maybe the Finance and Engineering departments within a company) with different access controls, placing each data set in a separate qtree or on separate volumes will make security configuration simpler. After creating and configuring volumes and qtrees to store user data, Data ONTAP must be configured to identify users so that it can control access to data. Documentation about this subject is available the File Access Management Guide. Note that the users discussed in this chapter are NOT the local administrative users discussed above. Instead, these are the non-administrator users who access data stored by the system using NFS or CIFS. For security information, the most important sections of this document are: Chapter 2: File Access Using NFS. Read the entire chapter, especially the section on providing secure NFS access. Chapter 3: File Access Using CIFS. How CIFS users obtain UNIX credentials. Sharing directories.
14
Displaying and changing share properties. Understanding authentication issues. Understanding local user accounts. How share-level access control lists work. Specifying how group IDs work with share-level ACLs Changing and displaying a share-level ACL Changing and displaying file-level ACLs Chapter 7: File Sharing Between NFS and CIFS Using LDAP services Installing SecureShare Access. Changing UNIX permissions and DOS attributes from Windows. An important concept to remember is that there are really two different realms of security to manage when using Data ONTAP for file access; one realm is the security of the NetApp storage system running Data ONTAP, including security controls on exported filesystems (for NFS) and shared directories (for CIFS). The other is security of individual files and directories, which is controlled by the individual users who own each file or directory. This control is exercised from NFS clients using the chown and chmod unix commands, or from CIFS clients using the procedures in the "Changing and displaying file-level ACLs" and "Changing UNIX permissions and DOS attributes from Windows" sections. While the first kind of security is entirely controlled by authorized system administrators, the second kind is under the control of each individual nonadministrative user. Thus it is VERY IMPORTANT that users receive training and guidance on what policies and procedures should be followed for setting access controls and permissions on files and directories. Even if the NetApp storage system and the Data ONTAP operating system are managed in an entirely secure fashion, a user who sets incorrect ACLs or permissions on a sensitive file may inadvertently compromise the security of the data within that file. Programs must be implemented to ensure constant awareness and education of individual, non-administrative users on local security policy. Although Data ONTAP 7.0 provides support for the pc-nfs protocol, it is an inherently insecure protocol and should be avoided. Since NFS, CIFS, iSCSI, and administrative clients access Data ONTAP over TCP/IP networking, it is important to configure the networking on the NetApp storage system in a secure fashion. The most important documentation for this purpose is the Network Management Guide, and in particular the following sections: Chapter 3: Network Routing Configuration. About routing in Data ONTAP.
o