Redpaper

Alex Osuna
Jesse Acosta

IBM System Storage N series Best

Practices for Secure Configuration

This IBM® Redpaper provides guidelines for the secure configuration of IBM
System Storage™ N series running Network Appliance Data ONTAP. It is
intended for storage and security administrators that wish to improve the overall
security posture of their storage networks. For each configuration area, we
provide only the most secure settings.

Note: As with any other information technology, an improvement in the overall

level of security can result in a reduction in functionality or usability and
administrators should be cautious when applying these configurations to avoid
an interruption of required services.

The second part of this IBM Redpaper provides a high-level discussion of Data
ONTAP security concepts in the context of a documentation map. Security
administrators should be able to use this map to develop a good working
knowledge of Data ONTAP security even if they have no previous storage
management experience.

© Copyright IBM Corp. 2008. All rights reserved. ibm.com/redbooks 1

Security configuration best practices
This section provides specific settings and option values that you can use to
configure an N series storage system so that it is as secure as possible. Many of
these settings do not need to be modified in a new system because they are
already set to the most secure value by default; however, this complete list can
assist with the audit of already-deployed systems.

Administrative access
This section describes Data ONTAP settings for administrative access.

Root password
Root password (Example 1) is used to set and modify user passwords. We
recommend implementing strong password options for root and user accounts.

Example 1 Root password

isotuc1> passwd
Login: root
New password:*******
Retype new password: *******

Trusted host access

Trusted host access (Example 2) enables or disables access to N series storage
systems by certain hosts without authentication. We recommend disabling this
option.

Example 2 Trusted host access

isotuc1> options trusted.hosts - (Disables telnet for all hosts)
isotuc1> options trusted.hosts + (Enables telnet for up to 5 hosts)
isotuc1> options trusted.hosts * (Allows telnet access all hosts)

Telnet access
Telnet access enables and disables telnet access to the N series storage system.
We recommend disabling telnet access (Example 3).

Example 3 Telnet access off

isotuc1> options telnet.enable off

2 IBM System Storage N series Best Practices for Secure Configuration

RSH access
RSH access enables and disables RSH access to the N series storage system.
We recommend disabling RSH access (Example 4).

Example 4 RSH off

isotuc1> options rsh.enable off

Note: Disabling both telnet and rsh access can provide tighter security.

HTTP access
HTTP access enables and disables HTTP (Web) access to the N series storage
system. We recommend that you disable HTTP access (Example 5).

Example 5 Disabling HTTP access

isotuc1> options httpd.admin.access host=none

Note: Setting this access to hosts=none denies access to FilerView.

Secureadmin
Secureadmin enables SecureAdmin for SSH and SSL security features. We
recommend installing SecureAdmin (Example 6).

Example 6 Installing SecureAdmin

isotuc1> secureadmin setup –f ssh
isotuc1> secureadmin enable ssh
isotuc1> secureadmin setup ssl
isotuc1> secureadmin enable ssl

Restrict SSH logins

Restrict SSH logins filters access to SSH to only authorized SSH clients. We
recommend limiting access to authorized SSH clients only (Example 7).

Example 7 Restricting SSH logins

isotuc1> options ssh.access host=[ipaddress],[ipaddress],[hostname]

Non-root users
Non-root users (Example 8 on page 4) creates additional accounts for the N
series storage system. We recommend creating non-root user accounts for each
administrator.

IBM System Storage N series Best Practices for Secure Configuration 3

 Example 8 Creating non-root user accounts
isotuc1> useradmin useradd [username]

Automatic logout
Automatic logout enables (Example 9) and sets an automatic logout from the N
series storage system for console and network sessions. We recommend
enabling it. The specific number of minutes you configure should be based on
your local security policy.

Example 9 Enabling automatic logout and setting timeouts

isotuc1> options autologout.console.enable on
isotuc1> options autologout.telnet.enable on
isotuc1> options autologout.console.timeout 30
isotuc1> options autologout.telnet.timeout 15

Note: The default parameters for these are on with 60 minute timeouts.

Logging administrative access

Logging administrative access enables and configures logging for administrative
sessions. We recommend enabling this logging (Example 10). The log file size
you specify depends on your local security policy, but it should be large enough
to record at least several days of administrative usage. You may set this to a large
value (several megabytes) and then adjust it after you see how quickly it fills up in
your environment.

Example 10 Enabling logging for administrative sessions

isotuc1> options auditlog.enable on
isotuc1> options auditlog.max_file_size [logfilesize]

Note: The data is logged into /etc/log/auditlog.

HOSTS.EQUIV access
This file contains trusted remote hosts for access without authentication. We
recommend disabling this access (Example 11).

Example 11 Disabling hosts.equiv access

isotuc1> options httpd.admin.hostsequiv.enable off

4 IBM System Storage N series Best Practices for Secure Configuration

 Password checks
Password checks controls whether a check for minimum-length and password
composition is performed when you specify new passwords. We recommend
enabling them (Example 12). The default for this is on. It does not apply to root or
administrator.

Example 12 Enabling password checks

isotuc1> options security.passwd.rules.enable on

Role-based access control

Role-based access control is a method for managing the set of actions that a user
or administrator can perform in an N series storage system. Using role-based
access controls, you can define sets of capabilities (roles) that are not assigned
to any particular user. Users are assigned to groups based on their job functions,
and each group is granted the set of roles for performing them.

NFS settings
This section describes Data ONTAP configuration settings for NFS.

Kerberos authentication
Kerberos authentication enables Kerberos authentication for NFS and requires
NFS clients to support Kerberos. We recommend enabling it with this command:
isotuc1> nfs setup

Then, edit /etc/exports for the N series storage system to set sec=krb5,
sec=krb5i, or sec=krb5p in the options field of the exported file systems.

LDAP authorization
LDAP authorization enables LDAP directory lookup service for user
authorization. SSL is also supported for secure connection. We recommend
enabling it and either LDAP over SSL (Example 13) or SASL .

Example 13 Enabling LDAP over SSL

isotuc1> options ldap.ssl.enable on
isotuc1> options ldap.enable on

IPSec
IPSec enables IPSec between NFS clients and the N series storage system. We
recommend enabling AH authentication and ESP payload encryption.

IBM System Storage N series Best Practices for Secure Configuration 5

 Exports file
The exports file provides lists of file systems in the N series storage system that
are exported (Example 14). We recommend ensuring that only data file systems
are exports and not administrative file systems, such as /etc. Additionally, ensure
that all world readable exports are read-only.

Example 14 Exports file list

/etc/exports
/vol/vol0-sec=sys,ro,rw=192.168.3.182,root=192.168.3.182,nosuid
/#/vol/vol1-sec=sys,rw,root=192.168.3.182,nosuid
//vol/vol0/home-sec=sys,rw,root=192.168.3.182,nosuid
/vol/test-sec=sys,rw,root=192.168.3.182,nosuid
/vol/test2-sec=sys,rw
/vol/test1-sec=sys,rw,root=192.168.3.182,nosuid
/vol/test3-sec=sys,rw,root=192.168.3.182,nosuid

You should also examine the /etc/exports file. See “The /etc/exports file” on
page 6 for more information.

NFS over TCP

NFS over TCP (Example 15) enables NFS sessions using TCP packets instead
of UDP. We recommend enabling it. TCP is generally more secure than UDP and
can facilitate the use of NFS over firewall boundaries. However, it also opens up
so many ports in both directions that usually it is better to deploy the NFS clients
and servers in the same security zone rather than pass the traffic over a firewall.

Example 15 Enabling NFS over TCP

isotuc1> options nfs.tcp.enable on

isotuc1> options nfs.udp.enable off

NFS mount request

NFS mount request (Example 16) enables and disables the NFS mount request
over ports with high numbers. We recommend using ports with low numbers only.

Example 16 Enabling mount request

isotuc1> options nfs.mount_rootonly on

The /etc/exports file

The man na_exports command provides a description of all the available
options for NFS export. This section describes the options related to security.

6 IBM System Storage N series Best Practices for Secure Configuration

Access rules
You must make sure that the appropriate security options are used in the NFS
export files to prevent unsolicited clients from mounting or gaining elevated
access rights to the desired volumes in the N series storage system. For
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. To do this with Data ONTAP 7.x and higher, enter:
/vol/volx -rw=host1,ro=host2

Security-related export options

The following NFS export options are related to security; you must use these
options appropriately 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 does not provide valid NFS credentials; a root NFS client user has a user
ID of 0. Data ONTAP determines a user’s file access permissions by checking
the effective user ID against the /etc/passwd file of the NFS server. 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 in
the file system path. Unless the file system is a root partition of a diskless
NFS client, set nosuid 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
Data ONTAP supports the specification of multiple security (sec) options for
each exported resource. The administrator can determine how secure NFS
access is to the N series storage system. Basically, the following two security
service types are supported:
– UNIX® (AUTH_SYS) authentication (sys): This is the default security
service used by Data ONTAP. It does not use strong cryptography and is
the least secure of the security services. Basically, AUTH_SYS credentials
are a user ID and up to 17 group IDs. A user that logs in as a superuser on
a UNIX system could use su to become a user with authorization for full
access to a volume. One way to prevent this is to implement strong
authentication mechanisms such as Kerberos.

IBM System Storage N series Best Practices for Secure Configuration 7

 – Kerberos version 5: This service provides the following three security
methods:
• Authentication (krb5): This method uses strong cryptography to prove a
user’s identity to a filer and to prove a filer’s identity to a user.
• Integrity (krb5i): This method provides a cryptographic checksum of the
data portion of each request and the response message to each
request. This defends against tampering with filer NFS traffic.
• Privacy (krb5p): This method 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 examples show how these security services are used:
򐂰 To specify one security type:
/vol/volx –sec=sys,rw=host1
򐂰 To specify multiple security types:
/vol/volx –sec=krb5:krb5i:krb5p,rw=host1

CIFS settings
This section describes Data ONTAP configuration settings for CIFS.

Kerberos authentication
Kerberos authentication for CIFS enables Microsoft® Active Directory
authentication, which uses Kerberos by default. To do this, select an Active
Directory domain during CIFS setup. We recommend using this authentication.

LDAP authorization
LDAP authorization for CIFS enables Active Directory LDAP for user
authorization. We recommend that you enable LDAP signing and sealing with
SASL and enable LDAP over SSL.

SMB signing
SMB signing ensures the integrity of CIFS communications. We recommend
enabling it for both the N series (Example 17) and Windows® clients.

Example 17 SMB signing for the N series storage system

isotuc1> options cifs.disable_server_smbsign off

For the Windows clients, set EnableSecuritySignature and

RequireSecuritySignature in the registry.

8 IBM System Storage N series Best Practices for Secure Configuration

 Share level permissions
This sets the share level permission for CIFS shares. We recommend changing
the share level ACL to authorized users only (Example 18) and removing
Everyone/Full Control.

Example 18 Share level permissions

isotuc1> cifs access <sharename> [-g] <user|group> <rights>

Audit CIFS access

Audit CIFS access enables and disables CIFS access audits. We recommend
enabling it (Example 19).

Example 19 Enabling CIFS access audits

isotuc1> options cifs.audit.enable on

Anonymous connections (restrict anonymous)

You can use anonymous connections to give anonymous users access to a list of
CIFS shares in the N series storage system or to prevent this access. We
recommend preventing this access (Example 20).

Example 20 Disabling access to CIFS shares

isotuc1> options cifs.restrict_anonymous.enable on

Guest access
This setting (Example 21) enables and disables CIFS guest access. We
recommend disabling it.

Example 21 Guest access

isotuc1> options cifs.guest_account “”

Multiprotocol settings
This section describes multiprotocol configuration settings for Data ONTAP.

Ignore ACLs
When ignore ACLs is on, ACLs do not affect root access from NFS. The option
defaults to off. We recommend that you disable it (Example 22 on page 10).

IBM System Storage N series Best Practices for Secure Configuration 9

 Example 22 Disabling ignore ACLs
isotuc1> options cifs.nfs_root_ignore_acl off

CIFS bypass traverse checking

When CIFS bypass traverse checking is on (the default), directories in the path to
a file do not require the “X” (traverse) permission. This option does not apply to
UNIX qtrees. We recommend that you enable traverse checking by turning this
option off (Example 23).

Example 23 Turning off CIFS bypass traverse checking

isotuc1> options cifs.bypass_traverse_checking off

CIFS GID checks

This option affects security checking for Windows clients of files with UNIX
security, where the requestor is not the file owner. In all cases, Windows client
requests are checked against the share-level ACL. If the requestor is the owner,
the user permissions are used to determine the access permissions.

If the requester is not the owner and if cifs.perm_check_use_gid is on, it means

that files with UNIX security are checked using normal UNIX rules (that is, if the
requester is a member of the file’s owning group, then the group permissions are
used; otherwise, the other permissions are used). If the requester is not the
owner and if cifs.perm_check_use_gid is off, files with UNIX security style are
checked in a way that works better for controlling access with share-level ACLs.
In that case, the requester’s desired access is checked against the file’s “group”
permissions, and the “other” permissions are ignored. In effect, the group
permissions are used as though the Windows client were always a member of
the file’s owning group, and the other permissions are not used.

We recommend enabling CIFS GID checks to require UNIX style security

(Example 24).

Example 24 Enabling CIFS GID checks

isotuc1> options cifs.perm_check_use_gid on

Default NT user
Default NT user specifies the NT user account to use when a UNIX user
accesses a file with NT security (has an ACL) and that UNIX user would not
otherwise be mapped. We recommend setting the option to a null string, denying
access (Example 25 on page 11).

10 IBM System Storage N series Best Practices for Secure Configuration

Example 25 Setting default NT user to deny access
isotuc1> options wafl.default_nt_user “”

Note: Perform this step only in multiprotocol systems that have NFS/CIFS
user mapping configured correctly; disabling it in an NFS-only N series
storage system results in access problems for legitimate users.

Default UNIX user

Default UNIX user specifies the UNIX user account to use when an NT user
attempts to log in and that NT user would not otherwise be mapped. We
recommend setting the option to a null string, denying access (Example 26).

Example 26 Setting default UNIX to deny access

isotuc1> options walf.default_unix_user “”

Note: Perform this step only in multiprotocol systems that have NFS/CIFS
user mapping configured correctly; disabling this access in a CIFS-only N
series storage system results in access problems for legitimate users.

Root to administrator mapping

When root to administrator mapping is on (the default), an NT administrator is
mapped to the UNIX root. We recommend disabling it by default (Example 27).

Example 27 Disabling root to administrator mapping

isotuc1> options walf.nt_admin_priv_map_to_root off

Change permissions
When change permissions is enabled, only the root user can change the owner of
a file. We recommend enabling it (Example 28).

Example 28 Allowing only root access to change permissions to files

isotuc1> options walf.root_only_chown on

Cache credentials
Cache credentials specifies the number of minutes a WAFL credential cache
entry is valid. The value can range from 1 through 20160; we recommend 10
(Example 29 on page 12).

IBM System Storage N series Best Practices for Secure Configuration 11

 Example 29 Setting cache credential minutes to 10
isotuc1> options walf.wcc_minutes_valid 10

Network settings
This section describes network settings for Data ONTAP.

Incoming packets
This setting (Example 30) enables and disables the checking of incoming
packets for correct addressing. We recommend enabling packet checking.

Example 30 Incoming packets configuration

isotuc1> options ip.match_any_ifaddr off

MAC Fastpath
The N series storage system uses MAC address and interface caching
(“Fastpath”) to return responses to incoming network traffic using the same
interface as the incoming traffic. In some cases, the destination MAC address is
equal to the source MAC address of the incoming data. We recommend disabling
this option (Example 31). When it is enabled, it increases the possibility of ARP
spoofing and session hijacking attacks.

Example 31 Disabling MAC Fastpath

isotuc1> options ip.fastpath.enable off

Logging ping flood

Logging ping flood enables and disables ping flood attack logging. We
recommend enabling it (Example 32).

Example 32 Enabling ping flood attack logging

isotuc1> options ip.ping_throttle.alarm_interval 5

SnapMirror access
SnapMirror access sets the IP address and host name for nodes that can receive
SnapMirror/SnapVault backups. We recommend setting IP address and host
names to authorized users for backup (Example 33 on page 13).

12 IBM System Storage N series Best Practices for Secure Configuration

 Example 33 Setting IP address and host names to authorized users for backup.
isotuc1> options snapmirror.access host=[ipaddress],[hostname]

SnapMirror source access

SnapMirror source access enables and disables the IP address-based
verification of SnapMirror destination N series storage systems by source N
series storage systems. We recommend that you enable source address
verification (Example 34).

Example 34 Enable SnapMirror source address verification

isotuc1> options snapmirror.checkip.enable on

NDMP
NDMP restricts control and data connections to authorized hosts. We
recommend limiting backup using NDMP to authorized hosts only (Example 35).

Example 35 Limiting backup using NDMP

isotuc1> options ndmpd.access host=[ipaddress],[hostname]

NDMP authentication
This configuration sets the NDMP authentication type (Example 36).

Example 36 Enabling NDMP authentication type

isotuc1> options ndmpd.authtype md5

DataFabric Manager (now Operations Manager)

This configuration displays the version of DataFabric Manager (now Operations
Manager). We recommend ensuring that version 3.0 or higher is used.

System services
This section describes Data ONTAP configuration settings for system services.

FTP
This enables and disables FTP. We recommend disabling it (Example 37).

Example 37 Disabling FTP

isotuc1> options ftpd.enable off

IBM System Storage N series Best Practices for Secure Configuration 13

 PCNFS
This enables and disables PCNFS. We recommend disabling it (Example 38).

Example 38 Disabling PCNFS

isotuc1> options pcnfs.enable off

SNMP
This enables and disables SNMP. We recommend disabling it (Example 39).

Example 39 Disabling SNMP

isotuc1> options snmp.enable off

RSH
This enables and disables RSH. We recommend disabling it (Example 40).

Example 40 Disabling RSH

isotuc1> options rsh.enable off

Telnet
This enables and disables telnet. We recommend disabling it (Example 41).

Example 41 Disabling telnet

isotuc1> options telnet.enable off

TFTP
This enables and disables TFTP. We recommend disabling it (Example 42).

Example 42 Disabling TFTP

isotuc1> options tftpd.enable off

Protocol access filter

Data ONTAP permits the installation of filters for rsh, telnet, ssh, httpd, httpd.
admin, snmp, ndmpd, SnapMirror, and SnapVault. (For a detailed description of
the usage, refer to the man page of the na_protocolaccess option.) The filters
can specify host names, IP addresses, IP subnets, or interface names, which are
either allowed or disallowed for each protocol. Each application ( attaches the
filter to the listening socket. Table 1 on page 15 shows some examples.

14 IBM System Storage N series Best Practices for Secure Configuration

Table 1 Protocol access control examples
Command Description

options ndmpd.access legacy Allow an NDMP server to accept a control connection request from
any client.

options rsh.access “host = Allow remote shell access for only one host, named gnesha.zo.
gnesha.zo”

options telnet.access Allow access for Telnet subnet 10.42.69.

host=10.42.69.1/24

options ssh.access “host=abc,xyz Allow ssh access for hosts abc and xyz when on network interface
AND if=e0” e0.

options snmp.access “if=e0,e1,e2” Allow access to SNMP for network interfaces e0, e1, and e2.

options httpd.access “if != e3” Do not allow access to HTTPD for network interface e3.

options httpd.admin.access Allow access to administrative HTTPD for two hosts.

“host=champagne,tequila”

options telnet.access “host=-” Disallow all access to Telnet.

options snapmirror.access legacy Check access to sources from other N series storage systems.

options snapvault.access all Allow a SnapVault server to accept any client requests.

iSCSI settings
This section describes iSCSI settings for Data ONTAP.

Per-interface configuration
This enables and disables iSCSI drivers (Example 43) for each network interface.
We recommend enabling iSCSI only where you intend to use it.

Example 43 Disabling iSCSi interface

isotuc1> iscsi interface disable [-f ] {-a | <interface>…}

Default security method

This selects the security method to use for initiators that do not have a security
method specified. We recommend setting the default iSCSI security method to
deny (Example 44), disabling access.

Example 44 Disabling access for initiators with no defined security method

isotuc1> iscsi default –s deny

IBM System Storage N series Best Practices for Secure Configuration 15

 Initiator security method
Initiator security method specifies the security method to be used for each
specific iSCSI initiator. We recommend using CHAP authentication (Example 45)
for all iSCSI initiators. The next section shows you how to generate a random
128-bit CHAP password.

Example 45 Specifying CHAP authentication for iSCSI initiators

isotuc1> iscsi security add –i initiator –s CHAP –p password –n name

Random CHAP passwords

This method (Example 46) generates a 128-bit random password that can be
used with iSCSI CHAP authentication. We recommend using this or another
method of your choice to generate completely random passwords for use with
iSCSI CHAP authentication.

Example 46 Generating a random CHAP password

isotuc1> iscsi security generate

Security documentation map

This section is an overview of the security-relevant documentation that is
available for Data ONTAP. It is intended to help security administrators that are
not storage experts learn enough about Data ONTAP security quickly to make
good deployment and configuration decisions. This is not an exhaustive list of all
possible security resources, but it is a very good starting point. This
documentation map refers to the current Data ONTAP documentation; however,
documentation for other versions of Data ONTAP is organized in a similar
manner. Always refer to the documentation for the version of Data ONTAP that
you are actually using.

The first section describes the administrative functions and interfaces that are
available to administrators and how to administer Data ONTAP securely. The
second section describes the limited set of security interfaces and functions that
are available to the users, describes their use, and includes warnings about
user-accessible functions and privileges that should be controlled.

Administrative guidance
The first step to understanding the security-relevant administrative functions and
interfaces of Data ONTAP is to learn about the basic steps required to access
and manage an N series storage system. The most important documentation on

16 IBM System Storage N series Best Practices for Secure Configuration

this subject is chapters 2, 4, 6 and 7 of the IBM System Storage N series System
Administration Guide (GC26-7974-00). In particular, pay close attention to the
following sections:
򐂰 Chapter 2: Interfacing with Data ONTAP
– How you administer a storage system
򐂰 Chapter 4: Accessing the Storage System
– Managing access from administration hosts.
– Controlling system access
򐂰 Chapter 6: Managing Administrator Access
– Managing users
– Managing roles
򐂰 Chapter 7: Performing General System Maintenance
– Synchronizing system time
– Configuring message logging
– Configuring audit logging
– Maintaining filer security through options

It is important to note that the users described in chapter 6 are local and should
only be created and used for system administrators and not for normal users.
Basically, when the Data ONTAP documentation refers to users, local users, or
local user accounts, they should be interpreted as local administrator user
accounts. It is possible, in some small workgroup environments, to use these
local accounts for normal user access to files; however, there are many security
problems with this approach and those who wish to use Data ONTAP in a secure
manner should not consider it.

Because the security of the administrative interfaces of the N series storage

system depend on limiting access to authorized administrators, it is extremely
important that administrator passwords be selected and managed very carefully.
Great caution should be exercised to ensure that administrator passwords are
difficult to guess; words found in any dictionary or wordlist (including names,
dates, place-names, social security, or other identifying numbers) should be
avoided. Passwords should contain a mix of upper and lower case letters,
punctuation marks, symbols, and numbers. Data ONTAP provides an option to
check for a minimum length and password composition when a new password is
chosen; this option (security.passwd.rules.enable) is enabled by default but is
not a substitute for a clear password selection policy and administrator training
on correct password selection.

The N series storage system may also be managed using the SSH remote login
protocol or with an SSL-protected version of FilerView called Secure FilerView.
These two methods are only available if the SecureAdmin product is installed

IBM System Storage N series Best Practices for Secure Configuration 17

 and configured in the N series storage system. SecureAdmin provides many
security advantages over administrative access by telnet, rsh, and http and
should be strongly considered by anyone who wants to maximize security. For
more information, see chapter 9 of the System Administration Guide:
http://www-1.ibm.com/support/docview.wss?uid=ssg1S7001339&aid=1

After administrative access has been configured, the next step for managing a
secure N series storage system is to organize your data. The most important
documentation for this process is in chapters 6 and 8 of the IBM System Storage
N series Storage Management Guide:
http://www-1.ibm.com/support/docview.wss?uid=ssg1S7001227&aid=1

In particular, pay attention to the following sections of chapter 8:

򐂰 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 unix.
򐂰 If a volume or qtree is to be accessed predominantly or exclusively by CIFS
clients, select ntfs.
򐂰 If a volume or qtree is to be accessed equally by both NFS and CIFS clients
and both types of clients require full control over file access security, select
mixed.
򐂰 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 you are creating volumes and qtrees for data management, we strongly
recommend organizing data by security requirements. For example, if the plan for
the N series storage system is to store data for two groups (maybe the Finance
and Engineering departments of company) with different access controls, placing
each data set in a separate qtree or in separate volumes makes security
configuration simpler.

After creating and configuring volumes and qtrees to store user data, you must
configure Data ONTAP to identify users so that it can control access to data.
Documentation about this subject is available in the File Access and Protocols
Management Guide:
http://www-1.ibm.com/support/docview.wss?uid=ssg1S7001596&aid=1

18 IBM System Storage N series Best Practices for Secure Configuration

The users that are discussed in this chapter are not local administrative users.
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
– 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 you use Data ONTAP for file access; one realm is the
security of the N series storage system running Data ONTAP, including security
controls on exported file systems (for NFS) and shared directories (for CIFS).
The other is security of individual files and directories. 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.

The first kind of security is entirely controlled by authorized system

administrators, but the second kind is under the control of each individual
non-administrative user. Therefore, users must receive training and guidance
about what policies and procedures should be followed for setting access
controls and permissions on files and directories. Even if the N series storage
system and the Data ONTAP operating system are managed securely, a user
that sets incorrect ACLs or permissions on a sensitive file may inadvertently
compromise the security of the data within that file. Therefore, programs that
ensure constant awareness and education of individual, non-administrative users
on local security policy are very important.

IBM System Storage N series Best Practices for Secure Configuration 19

 Although Data ONTAP provides support for the pc-nfs protocol, it is an inherently
insecure protocol and should be avoided.

Because NFS, CIFS, iSCSI, and administrative clients use TCP/IP networking to
access Data ONTAP, the networking for the N series storage system should be
configured for maximum security. The most important documentation for this
purpose is the IBM System Storage N series Network Management Guide:
http://www-1.ibm.com/support/docview.wss?uid=ssg1S7001334&aid=1

The following sections are particularly important:

򐂰 Chapter 3: Network Routing Configuration
– About routing in Data ONTAP
– About fast path
򐂰 Chapter 4: Host Name Resolution
򐂰 Chapter 8: Internet Protocol Security Configuration

In addition to the information supplied in chapter 3, one important configuration

for secure deployments of N series storage systems with multiple network
interfaces is the ip.match_any_ifaddr option. By default this option is turned on,
which increases performance of the system but also increases exposure to
certain types of IP forgery attacks. Turn this option off using options
ip.match_any_ifaddr off (Example 47) on the command line interface.

Example 47 Turning off ip.match_any_ifaddr

isotuc1> options ip.match_any_ifaddr off

We strongly recommend that you configure and enable IPSec (see chapter 8 of
the IBM System Storage N series Network Management Guide).

For systems configured to provide LUN access through iSCSI, read the Block
Access Management Guide for iSCSI and FCP. In particular, pay attention to the
following security-relevant sections:
򐂰 Chapter 6: Managing iSCSI igroups
򐂰 Chapter 12: Managing the iSCSI Network
– Managing security for iSCSI initiators
– Managing the iSCSI service on storage system interfaces

Important: Enable CHAP authentication for all iSCSI LUNs and select strong
CHAP passwords.

20 IBM System Storage N series Best Practices for Secure Configuration

This manual also provides information about LUN access using FCP; chapter 7
is particularly useful:
http://www-1.ibm.com/support/docview.wss?uid=ssg1S7001526&aid=1

You can also enhance FCP security by implementing zoning restrictions on the
Fibre Channel switch that might be deployed as part of the configuration; check
the documentation for your switch for details. Many switch vendors provide two
forms of zoning, known as hard and soft. Hard zoning is based on the physical
port that a cable is connected to and provides a better level of security than soft
zoning in environments where the switch is in a physically secure location.

Regardless of the types of data stored in the system or which methods you use
to access that data, you must perform backups to protect the data if there is a
system failure or other disaster. Data ONTAP gives you the option of backing up
data to local tape devices, in which case there are no security considerations
other than ensuring that only authorized administrators gain possession of the
backup tapes.

Data ONTAP also provides several methods (SnapMirror, SnapVault, and NDMP)
you can use to perform backups over a TCP/IP network. This kind of network
backup has security considerations that must be addressed. You can find
information about how to configure security for these kinds of backups, in The
IBM System Storage N series Data Protection Online Backup and Recovery
Guide:
http://www-1.ibm.com/support/docview.wss?uid=ssg1S7001226&aid=1

These sections are of particular importance:

򐂰 Chapter 4: Data Protection Using SnapMirror
– Specifying destination filers on the source filer
򐂰 Chapter 5: Data Protection using SnapVault
– Setting up SnapVault backup on Open Systems platforms
– Managing SnapVault backup of Open Systems platforms.
– Enabling SnapVault

Note: Open Systems SnapVault is a software product that protects data from
a Windows, UNIX, or Linux® system by backing it up to an N series storage
system running Data ONTAP. Security procedures for the Windows, Unix or
Linux backup client systems (other than SnapVault settings and NDMP) are
outside the scope of this document.

Chapter 10 of this documentation also contains information about how to provide

virus scanning services for files accessed via CIFS. This functionality requires a
third party AntiVirus Scanner system from McAfee, Computer Associates,

IBM System Storage N series Best Practices for Secure Configuration 21

 Symantec, or Trend. We strongly recommend deploying an antivirus server if you
use CIFS.

For more information about network-based NDMP tape backups, see:

http://www-1.ibm.com/support/docview.wss?uid=ssg1S7001593&aid=1

The following sections in Chapter 5 of this document focus on security relevant

features:
򐂰 Managing NDMP security features
򐂰 Specifying the NDMP versions

User guidance
For individual users that access data stored in an N series storage system
running Data ONTAP, the security configuration options are quite limited because
most of the security features and options are controlled by system
administrators. In fact, a user that accesses data in an iSCSI or FCP LUN cannot
modify or configure any security controls on the N series storage system.

When accessing files by NFS, most users become owners of one or more files or
directories. Users can only manage security with chmod and chown for files or
directories that they own, and only if the NFS file system they are accessing is
located in a volume or qtree with the unix or mixed security style. Users and
administrators should consult the documentation for their Unix operating system
for details on how to use these commands or their equivalents, as the specific
syntax and operation can vary between platforms. Users may find that chown
does not function (unless they are logged in as the "root" user) if the Data
ONTAP administrator has set the "wafl.root_only_chown" option; we strongly
recommend that this be set.

When accessing files by CIFS, most users become owners of one or more files
or directories. Users may only manage security on files or directories that they
own, and only if the CIFS filesystem they are accessing is located in a volume or
qtree with the "ntfs" or "mixed" security style.

Regardless of the methods individual users use to access and manage files
stored in the N series storage system, an external server in the environment,
such as a Kerberos, LDAP, or Microsoft Active Directory server, often performs
the user authentication or authorization. Administrators keep these servers
secure, but users must manage their passwords in accordance with local
password policies to prevent security incidents.

22 IBM System Storage N series Best Practices for Secure Configuration

The team that wrote this Redpaper
This Redpaper was produced by a team of specialists from around the world
working at the International Technical Support Organization, Poughkeepsie
Center.

Alex Osuna is a Project Leader at the International Technical Support

Organization (ITSO), Tucson Center. He writes extensively and teaches IBM
classes worldwide on all areas of storage. Before joining the ITSO two years ago,
Alex worked as a IBM Tivoli® Systems Engineer. Alex has over 29 years in the IT
industry, 20 of them specifically related to storage. He has more than 10
certifications from IBM, Microsoft, and Redhat.

Jesse Acosta is a Technical Support Engineer from AVNET Partner solutions.

Thanks to Roger Sanders of the Network Appliance Corporation for his review.

IBM System Storage N series Best Practices for Secure Configuration 23

24 IBM System Storage N series Best Practices for Secure Configuration
Notices

This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM's application
programming interfaces.
© Copyright International Business Machines Corporation 2008. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by
GSA ADP Schedule Contract with IBM Corp. 25
Send us your comments in one of the following ways:
򐂰 Use the online Contact us review Redbooks form found at:
ibm.com/redbooks ®
򐂰 Send your comments in an email to:
redbook@us.ibm.com
򐂰 Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099, 2455 South Road
Poughkeepsie, NY 12601-5400 U.S.A.

Trademarks Redpaper ™
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:

Redbooks (logo) ® System Storage™

IBM® Tivoli®

The following terms are trademarks of other companies:

SecureAdmin, Network Appliance, WAFL, SnapVault, SnapMirror, SecureShare, FilerView, Data ONTAP,
and the Network Appliance logo are trademarks or registered trademarks of Network Appliance, Inc. in the
U.S. and other countries.
Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States,
other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.

26 IBM System Storage N series Best Practices for Secure Configuration