Securing Clustered Data ONTAP. December 2015 SL10250 Version PDF Free Download

Securing Clustered Data ONTAP December 2015 SL10250 Version 1.0

TABLE OF CONTENTS 1 Introduction... 4 1.1 Basic Clustered Data ONTAP Security Practices...4 1.2 Lab Objectives... 5 1.3 Prerequisites... 5 2 Lab Environment... 6 3 Lab Activities... 8 3.1 Lab Preparation... 8 3.2 Route Event Messages and Command-History to an External Syslog Server Destination... 10 3.2.1 Exercise... 10 3.3 Administrative User Account Custom Roles...11 3.3.1 Exercise... 13 3.4 Configuring Firewalls...16 3.4.1 Exercise... 18 3.5 Configure SSH... 19 3.5.1 Exercise... 20 3.6 Configure CLI Session Timeouts...21 3.6.1 Exercise... 21 3.7 Configure SSL/TLS...21 3.7.1 Exercise... 22 3.8 NFS/CIFS Export Policies... 25 3.8.1 CIFS Exercise...26 3.8.2 NFS Exercise...35 3.9 NFS and SMB (CIFS) ACLs... 40 3.9.1 Exercise... 41 2 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

1 Introduction This lab introduces several basic techniques for Securing Clustered Data ONTAP version 8.3.1. This lab utilizes, as its starting point, an environment that contains a virtualized, single node Data ONTAP cluster, and several virtualized servers that allow you to perform and verify some simple steps in securing your data storage environment. This lab is not intended to be an all-encompassing best practices guide for securing clustered Data ONTAP; there is no one size fits all security configuration that is ideal for every situation. Rather, this lab introduces many of the security features available to you in clustered Data ONTAP so that you can learn how they work. With this knowledge you can then decide if and how to best apply those features to meet the unique security needs of your own environment. 1.1 Basic Clustered Data ONTAP Security Practices These days system administrator and end-users alike are justifiibly very concerned about the security of their IT environments and the data they contain. These concerns stem from a constant stream of newly exploited vulnerabilities, and the discovery of data breaches occurring at an ever alarming rate. Although you may not be able to prevent all attempts at unauthorized incursion, you can better safe-guard your IT resources and your data through the use of some basic security practices. Security, itself, is a rather complex subject with many different facets. In this lab you will focus on a small list of basic security concepts, as described in the following table. Table 1: Table A: Basic Security Concepts Security Concept Discussion 1 Accountability Is Big Brother watching? Is there a record of my actions (successful or failed)? Where is this record kept? 2 Access How do I access my IT resources? 3 Identification Who am I? What protocols do I use? Will my on-line sessions automatically terminate if I am away from my workstation too Long? Where is my username stored? 4 Authentication How do I prove I m really me? What kind of secret can I provide to prove who I really am? 5 Authorization Now that I have access, what am I allowed to do? What are my restrictions? For Clustered Data ONTAP, there are two (2) major areas for security focus. These are: Administrative access for management of the Data ONTAP cluster, and the Storage Virtual Machines (SVMs) hosted on the cluster. User (data consumer) access to data hosted and served by the SVMs. 4 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

For the first case, Administrative access, this lab limits the focus to Cluster/Storage administrators connecting to the Data ONTAP cluster (or a hosted SVM) using the Secure Shell (SSH) protocol. This is just one of several access methods that can be employed, but for brevity this lab focuses only on SSH access. For the second case, this lab focuses on two Network Attached Storage (NAS) protocols used to access stored data. These are CIFS (predominantly used by Windows), and NFS (predominantly used by Linux/UNIX). All of the concepts shown in Table A apply to NAS served data, as well as these three (3) additional concepts (as shown in Table B). These concepts sometimes go by the acronym CIA (which should not be confused with the Company located in Langley, VA.) Table 2: Table B: Additional Security Concepts Security Concept Discussion C Confidentiality Can any unauthorized persons or entities read my private data? I Integrity Can any unauthorized persons or entities modify or delete my private data? A Availability Is all of my data reliably accessible with minimal or no latency? All of the security concepts presented in these two tables are addressed by one or more sections in this lab. 1.2 Lab Objectives In this lab you will learn techniques for hardening the security of a clustered Data ONTAP system. You will specifically learn how to: Configure cluster command logging to an external syslog server. Create custom roles for administrative accounts. Configure firewall to protect cluster services. Restrict cluster SSH access to more secure encryption. Configure CLI session timeouts. Restrict cluster core web services. Create and test CIFS and NFS export policies. Create SMB (CIFS) shares ACLs. Review command histrory captured by syslog. 1.3 Prerequisites This lab assumes that you are familiar with the basic concepts of administering clustered Data ONTAP 8.3. This lab makes extensive use of the clustered Data ONTAP comand line interface (CLI) because OnCommand System Manager, NetApp's graphical administration tool, does not support the features necessary to complete many of the exercises you will be performing. Experience with the clustered Data ONTAP CLI is helpful but not required. The instructions are designed to allow a novice to complete the lab. This lab also uses Linux CLI commands, but again, experience is not required in order to complete the lab. 5 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

2 Lab Environment The following illustration depicts the lab environment: Figure 2-1: Table 3: Table of Systems Server \ Resource Purpose IP Address User JUMPHOST Windows 2012R2 Remote Access Host 192.168.0.5 DEMO\Ad RHEL1 Red Hat 6.6 x64 Linux Host 192.168.061 root RHEL2 Red Hat 6.6 x64 Linux Host 192.168.0.62 root SYSLOG Red Hat 6.6 x64 Linux Syslog Server 192.168.0.63 root WIN2K12R2 Windows 2012R2 Server 192.168.0.41 DEMO\Ad DC1 Active DIrectory and DNS Server 192.168.0.253 DEMO\Ad CLUSTER1 Data ONTAP 8.3.1 cluster 192.168.0.101 admin CLUSTER1-01 Data ONTAP cluster node 192.168.0.111 admin CIFS CIFS Server SVM 192.168.0.131 vsadmin NFS NFS Server SVM 192.168.0.141 vsadmin Table 4: User IDs and Passwords User User Type Username or UID Group Membership or GID Login Password CIFS Data User # 1 Windows demo\datauser1 CIFS Data Users Netapp1! CIFS Data User # 2 Windows demo\datauser2 CIFS Data Users Netapp1! 6 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

User User Type Username or UID Group Membership or GID CIFS Data User # 3 Windows demo\datauser3 CIFS 2nd Data Users CIFS Data User # 4 Windows demo\datauser4 CIFS 2nd Data Users Login Password Netapp1! Netapp1! NFS Data User # 1 Linux ldatauser1 (500) NFS Data User # 2 Linux ldatauser2 (501) NFS Data User # 3 Linux ldatauser3 (502) NFS Data User # 4 Linux ldatauser4 (503) nfs_users1 (5001) nfs_users1 (5001) nfs_users2 (5002) nfs_users2 (5002) Netapp1! Netapp1! Netapp1! Netapp1! 7 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

3 Lab Activities This lab contains the following activities and tasks: Lab Preparation on page 8 Configuring Firewalls on page 16 Route Event Messages and Command-History to an External Syslog Server Destination on page 10 Administrative User Account Custom Roles on page 11 Configure SSH on page 19 Configure CLI Session Timeouts on page 21 Configure SSL/TLS on page 21 NFS/CIFS Export Policies on page 25 NFS and SMB (CIFS) ACLs on page 40 Review Syslog Events on page 53 3.1 Lab Preparation You need to establish a terminal session to cluster1 in order to complete the exercises in this lab. 1. On the desktop of JUMPHOST, launch PuTTY by clicking the two-terminal icon on the taskbar. 1 Figure 3-1: 2. By default PuTTY displays the Basic options for your PuTTY session view after launch. If you accidentally navigate away from this view just click on the Session category item in the left pane to return to this view. 3. In the Saved Sessions box, double-click the entry for cluster1. 8 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

2 3 Figure 3-2: The cluster1.demo.netapp.com - PuTTY window opens. 4. Log into cluster as the user admin with the password Netapp1!. 5. You will need this terminal session throughout all the sections of this lab, so do not close it between exercises. If you do accidentally close it, you can come back to this procedure to open a new terminal session. If you are new to the clustered Data ONTAP CLI, the length of the commands can seem a little initimidating. However, the commands are actually quite easy to use if you remember the following 3 tips: Make liberal use of the Tab key while entering commands, as the clustered Data ONTAP command shell supports tab completion. If you hit the Tab key while entering a portion of a command word, the command shell will examine the context and try to complete the rest of the word for you. If there is insufficient context to make a single match, it will display a list of all the potential matches. Tab completion also usually works with command argument values, but there are some cases where there is simply not enough context for it to know what you want, in which case you will just need to type in the argument value. You can recall your previously entered commands by repeatedly pressing the up-arrow key, and you can then navigate up and down the list using the up and down arrow keys. When you find a command you want to modify, you can use the left arrow, right arrow, and Delete keys to navigate around in a selected command to edit it. Entering a question mark character? causes the CLI to print contextual help information. You can use this character by itself, or while entering a command. If you would like to learn more about the features of the Data ONTAP CLI, the Advanced Concepts for Clustered Data ONTAP 8.3.1 lab includes an extensive tutorial on this subject. 9 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

Caution: The commands shown in this guide are often so long that they span multiple lines. When you see this, in every case you should include a space character between the text from adjoining lines. If you intend to use copy/paste of commands from the guide to the lab, when dealing with multi-line commands you can only copy one line at a time. If you try to copy multiple lines at once then the commands will fail in the lab. 3.2 Route Event Messages and Command-History to an External Syslog Server Destination In this section, you will configure Clustered Data ONTAP to forward cluster and member node events to an external syslog server. New to Clustered Data ONTAP 8.3.1 is the ability to also forward the command history log file entries to a designated syslog server. This works for commands entered through the clustered Data ONTAP CLI as well as through the NetApp Zephyr API (ZAPI), which means that management activities performed through System Manager, the NetApp PowerShell Toolkit, and the NetApp Management Software Development Kit (NMSDK) are also captured. For this lab, the designated syslog server is on a host running Red Hat Enterprise Linux version 6.6. The syslog server application is rsyslog v5 which is the standard remote syslog server daemon provided with this RHEL release. In production environments, other syslog applications may be used in place of the default rsyslog. The destination IP address of this server syslog.demo.netapp.com is 192.168.0.63. Once you've configured remote syslog destination/routing for both the Event Management System (EMS) and the command history log entries, any clustered Data ONTAP configuration activities you perform in other sections of this lab will get logged to syslog. At the end of the lab you will revisit the syslog server to review those captured logs. 3.2.1 Exercise 1. In the PuTTY window for cluster1, display a list of the existing event destinations. An event destination is a list of addresses that receive event notifications. event destination show Hide Name Mail Dest. SNMP Dest. Syslog Dest. Params ---------------- ----------------- ------------------ ------------------ ------ allevents - - - false asup - - - false criticals - - - false pager - - - false traphost - - - false 5 entries were displayed. Observe that there is no syslog destination listed for allevents. 2. Modify the allevents destination to use the syslog server at 192.168.0.63, which corresponds to syslog.demo.netapp.com. event destination modify -name allevents -syslog 192.168.0.63 -syslog-facility default -hide-parameters false 3. Display the updated list of event destinations. event destination show Hide Name Mail Dest. SNMP Dest. Syslog Dest. Params ---------------- ----------------- ------------------ ------------------ ------ allevents - - syslog.demo.netapp.com 10 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

false asup - - - false criticals - - - false pager - - - false traphost - - - false 5 entries were displayed. 4. Add the allevents destination to all the defined types of events. event route add-destination -messagename * -destinations allevents 7873 entries were acted on. 5. Display a list of the log forwarding destinations. cluster log-forwarding show This table is currently empty. Note that there are no defined destinations. 6. Create the syslog server as a new forwarding destination. cluster log-forwarding create -destination 192.168.0.63 -port 514 -facility user 7. Display the updated list of log forwarding destinations. cluster log-forwarding show Syslog Destination Host Port Facility ------------------------- ------ -------- 192.168.0.63 514 user Both EMS Events and Command-history records are now forwarded to the designated syslog server. Towards the end of the lab exercise you will examine the command history captured by the syslog server. 3.3 Administrative User Account Custom Roles In this activity, you are introduced to administrative user account roles, and how they can be used to grant and restrict administrative privileges to users assigned to that role. In this exercise you will create a customized role, and then assign a newly created user account to that customized role. Every administrative user account must be assigned a role. That role specifies what capabilities your account has when you login to Data ONTAP. These capabilities dictate what you can access, what you can see, and most importantly, what you can change. Clustered Data ONTAP includes several pre-defined roles that are used for managing account access to the cluster or SVMs. These pre-defined roles are listed in the following table.: Table 5: Table: Clustered Data ONTAP Pre-defines Roles Cluster Pre-defined Roles admin autosupport backup Vserver (SVM) Pre-defined Roles vsadmin vsadmin-backup vsadmin-protocol 11 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

Cluster Pre-defined Roles none readonly Vserver (SVM) Pre-defined Roles vsadmin-readonly vsadmin-volume Roles also control clusterd Data ONTAP user account name and password policies via role atrributes that you specify as command line parameters. You can see the details of these policy attributes in the following table: Table 6: Table: Role Configuration Attributes Useful for Implementing Password and Login Policy Role Attribute Parameter Description Default Value Recommended Value -username-minlength Minimum username length required 3 3 -username-alphanum Username alpha-numeric disabled disabled -passwd-minlength Minimum password length required 8 8 -passwd-alphanum Password alpha-numeric enabled enabled -passwd-min-special-chars Minimum number of special characters required in the password -passwd-expiry-time -require-initial-passwdupdate -max-failed-login-attempts -lockout-duration -disallowed-reuse -change-delay Password Expires In (Days) Require password change on 1st login Maximum number of failed attempts Maximum lockout period (Days) Disallow last 'N' passwords Delay between password changes (Days) 0 1 unlimited (never) 60 disabled 0 6 0 = (1 day) 30 6 6 0 = (no delay) 0 enabled When defining customized roles, you utilize the following CLI parameters to further specify the scope of the role. Table 7: Table: Role Creation Parameters Parameter -vserver -role -cmddirname -access Description This optionally specifies the Vserver name associated with the role. This specifies the name of role that is to be created. This specifies the command or command directory to which the role has access. To specify the default setting, use the special value "DEFAULT". This optionally specifies an access level for the role. Possible access level settings are none, readonly, and all. The default setting is all. 12 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

Parameter -query Description This optionally specifies the object that the role is allowed to access. The query object must be applicable to the command or directory name specified by -cmddirname. The query object must be enclosed in double quotation marks (""), and it must be a valid field name. For this exercise, you will create a custom role called stats, and create a user account called stat_acct that will be assigned the stats role. You will then login to that user account and see which access capabilities are allowed for this user. 3.3.1 Exercise 1. In the PuTTY window for cluster1, create a new role named stats that initially has no access to any of the adminitrative CLI commands. security login role create -role stats -cmddirname DEFAULT -access none 2. Grant the stats role access to all of the statistics CLI commands. security login role create -role stats -cmddirname statistics -access all 3. Grant the stats role access to the security login whoami command. security login role create -role stats -cmddirname "security login whoami" -access all 4. Display the hierarchy of the command access rules for the stats role. security login role show -role stats Role Command/ Access Vserver Name Directory Query Level ---------- ------------- --------- ----------------------------------- -------- cluster1 stats DEFAULT none cluster1 stats security login whoami all cluster1 stats statistics all 3 entries were displayed. The initial ordering of the rules listed is important, as the first entry takes away all access, and the second and third rules selectively add back in access to the desired commands. The fact that the second and third commands show up in a different order than you entered them is unimportant, as there is no dependency between these two commands. 5. Display the configuration attribute settings for the " stats role. security login role config show -role stats -instance Vserver: cluster1 Role Name: stats Minimum Username Length Required: 3 Username Alpha-Numeric: disabled Minimum Password Length Required: 8 Password Alpha-Numeric: enabled Minimum Number of Special Characters Required In The Password: 0 Password Expires In (Days): unlimited Require Initial Password Update on First Login: disabled Maximum Number of Failed Attempts: 0 Maximum Lockout Period (Days): 0 13 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

Disallow Last 'N' Passwords: 6 Delay Between Password Changes (Days): 0 As you can see, the username and password complexity attributes all match the default values shown in the Role Configuration Attributes Useful in Implementing Password and Login Policy table. The default values are fine for this lab, but if you wanted to modify then then you could use the security login role config modify command along with the attributes from the table to accomplish that task. 6. Create a new user account named stat_acct on cluster1 and assign it to the stats role. When prompted for the new account's password, enter Netapp1!. security login create -user-or-group-name stat_acct -application ssh -authmethod password -role stats Please enter a password for user 'stat_acct': Please enter it again: Now you will log into cluster1 using the stat_acct account to see how the stats role restricts the account's command access. 7. Enter just the? character in your cluster1 PuTTY session to produce a list of the CLI commands available to the admin user account.? up cluster> dashboard> event> exit export-policy history job> lun> man metrocluster> network> qos> redo rows run security> set snapmirror> statistics> storage> failover system> top volume> mirrors vserver> Go up one directory Manage clusters (DEPRECATED)-Display dashboards Manage system events Quit the CLI session Manage export policies and rules Show the history of commands for this CLI session Manage jobs and job schedules Manage LUNs Display the on-line manual pages Manage MetroCluster Manage physical and virtual network connections QoS settings Execute a previous command Show/Set the rows for this CLI session Run interactive or non-interactive commands in the nodeshell The security directory Display/Set CLI session settings Manage SnapMirror Display operational statistics Manage physical storage, including disks, aggregates, and The system directory Go to the top-level directory Manage virtual storage, including volumes, snapshots, and Manage Vservers The admin user is assigned the admin role, which grants full access to all of the CLI commands, so you see quite a few commands listed. 8. Open a new PuTTY session. (Don't close your existing "admin" user PuTTY session to cluster1, as you will need that later in this exercise). 14 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

8 Figure 3-3: 9. Double-click the saved session for cluster1. 9 Figure 3-4: 10. Log in as the stat_acct user using the password Netapp1!. 11. Verify your login identity. whoami (security login whoami) User: stat_acct 12. Press the? key to see a list of the CLI commands available to the "stat_acct" account..? up exit Go up one directory Quit the CLI session 15 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

history man redo rows security> statistics> top Show the history of commands for this CLI session Display the on-line manual pages Execute a previous command Show/Set the rows for this CLI session The security directory Display operational statistics Go to the top-level directory Observe that the list of available commands is quite short, limited to just the statistics command and a few navigational commands. Compare this list to the list of commands you saw available in your "admin" user login session. 13. Exit out of your login session for the stat_acct account. exit 3.4 Configuring Firewalls This section introduces the configuration of firewalls. Firewalls control which network protocols (services) are allowed to pass data on Cluster Data ONTAP s network interfaces. The firewalls are services running on each node in the cluster that determine which network traffic is allowed or disallowed for each specific node s network ports, according to defined firewall policies. Firewall policies are defined and maintained by cluster administrators. Note: Firewalls do not control or influence NAS data traffic. They do control how administrators and external management applications may access the cluster for management purposes, and communications between cluster peers. There are three built-in policies defined in Clustered Data ONTAP. These policies cannot be removed, however cluster administrators can define new policies to use instead of the predfined policies. The network protocol services that can be used in a policy are listed in the following table. Table 8: Table: Network Protocols Allowed in Firewall Policies Protocol dns http https ndmp ndmps ntp rsh snmp ssh telnet Description Use for Domain Name Services Hyper-text transfer protocol (not recommended) Secure Hyper-text transfer protocol (recommended over HTTP) Network Data Management Protocol Secure Network Data Management Protocol (recommended over NDMP) Network Time Protocol Remote Shell (highly discouraged and not recommended) Simple Network Management Protocol Secure Shell Telnet Protocol (highly discouraged and not recommended) The next table the default comfiguration of the built-in firewall policies. 16 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

Table 9: Table: Built-in Firewall Policies Built-In Policy Name data intercluster mgmt Default Protocol Entries and Allowed Networks dns 0.0.0.0/0 ndmp 0.0.0.0/0 ndmps 0.0.0.0/0 https 0.0.0.0/0 ndmp 0.0.0.0/0 ndmps 0.0.0.0/0 dns 0.0.0.0/0 http 0.0.0.0/0 https 0.0.0.0/0 ndmp 0.0.0.0/0 ndmps 0.0.0.0/0 ntp 0.0.0.0/0 snmp 0.0.0.0/0 ssh 0.0.0.0/0 Each policy will contain one (1) or more entries specifying which network protocol service to allow, and a list of the valid IP networks and IP addresses that are allowed to access that network service. The absence of a particular network protocol service entry prevents any access using that protocol over the network interfaces relying on that firewall policy. The firewall commands are located in the system services firewall command sub-directory and the system services firewall policy sub-directory beneath that. The following tables list the commands and their purpose. Table 10: Table: Cluster System Service Firewall Commands Command modify policy> show Purpose Change the status of the firewall running on a cluster node. Navigate into the policy commands sub-directory. Show the current status of the firewall(s). Table 11: Table: Cluster Systerm Service Firewall Policy Commands Command clone create delete modify show Purpose Clone (copy) an existing firewall policy. Create a firewall policy entry for a network service. Remove a service from a firewall policy. Modify a firewall policy entry for a network service. Show firewall policies. For this exercise, you will: 17 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

Create two new firewall policies, one for the cluster management level, and one specifically for an SVM running in the cluster. Remove unwanted protocols from the policy. Restrict the remaining protocols to a specific network subnet. In practice you would typically build upon these steps by applying these firewall polices to network interfaces, but you will not be taking that step in this lab. 3.4.1 Exercise 1. Using your PuTTY session for cluster1, create a new policy named mgmt2 for the cluster SVM cluster1 that permits SSH protocol access to just the 192.168.0.0/24 subnet. system services firewall policy create -vserver cluster1 -policy mgmt2 -service ssh -allow-list 192.168.0.0/24 2. Add to the mgmt2 policy DNS protocol access for just the 192.168.0.0/24 subnet. system services firewall policy create -vserver cluster1 -policy mgmt2 -service dns -allow-list 192.168.0.0/24 3. Add to the mgmt2 policy https protocol https access for just the 192.168.0.0/24 subnet. system services firewall policy create -vserver cluster1 -policy mgmt2 -service https -allow-list 192.168.0.0/24 4. Add to the mgmt2 policy ntp protocol access for just the 192.168.0.0/24 subnet. system services firewall policy create -vserver cluster1 -policy mgmt2 -service ntp -allow-list 192.168.0.0/24 5. Create a new policy named cifs_mgmt2 for the SVM cifs_svm that permits SSH protocol access to just the 192.168.0.0/24 subnet. system services firewall policy create -vserver cifs_svm -policy cifs_mgmt2 -service ssh -allow-list 192.168.0.0/24 6. Add to the cifs_mgmt2 policy DNS protocol access for just the 192.168.0.0/24 subnet. system services firewall policy create -vserver cifs_svm -policy cifs_mgmt2 -service dns -allow-list 192.168.0.0/24 7. Display a listing of the new policies you just created. system services firewall policy show Vserver Policy Service Allowed ------- ------------ ---------- ------------------- cifs_svm cifs_mgmt2 dns 192.168.0.0/24 ssh 192.168.0.0/24 cluster1 data dns 0.0.0.0/0 ndmp 0.0.0.0/0 ndmps 0.0.0.0/0 cluster1 18 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

cluster1 mgmt intercluster https 0.0.0.0/0 ndmp 0.0.0.0/0 ndmps 0.0.0.0/0 dns 0.0.0.0/0 http 0.0.0.0/0 https 0.0.0.0/0 ndmp 0.0.0.0/0 ndmps 0.0.0.0/0 Vserver Policy Service Allowed ------- ------------ ---------- ------------------- cluster1 mgmt ntp 0.0.0.0/0 snmp 0.0.0.0/0 ssh 0.0.0.0/0 cluster1 mgmt2 dns 192.168.0.0/24 https 192.168.0.0/24 ntp 192.168.0.0/24 ssh 192.168.0.0/24 20 entries were displayed. 3.5 Configure SSH For administrative management connections to Clustered Data ONTAP, the Secure Shell (SSH) protocol is frequently used. The effectiveness of maintaining a secured network connection is very dependent on which keyexchange algorithms and encryption ciphers are used. The basic SSH protocol supports a number of different algorithms and ciphers, some more secure than others. SSH services in Clustered Data ONTAP support four (4) different key-exchange algorithms, and seven (7) different ciphers. These are listed in the following table ordered from most secure to least. Table 12: SSH Supported Encryption Ciphers and Key-Exchange Algorithms Encryption Ciphers aes256-ctr aes192-ctr aes128-ctr aes256-cbc aes192-cbc aes128-cbc 3des-cbc Key-Exchange Algorithms diffie-hellman-group-exchange-sha256 diffie-hellman-group-exchange-sha1 diffie-hellman-group14-sha1 diffie-hellman-group1-sha1 By restricting the available ciphers and algorithms, administrators can force the use of more secure SSH clients when connecting to the Data ONTAP cluster, or SVM management network interfaces. Using algorithms and ciphers with larger key lengths will also help deter man-in-the-middle eaves-dropping on SSH connections, and possible disclosure of critical login credentials. Data ONTAP maintains a configuration for the cluster administration SVM and each other SVM allowing SSH access. Configuration of which SSH key-exchange algorithms and encryption ciphers are to be allowed is accomplished by commands found in the security ssh commands sub-directory. For this exercise, you will list the current SSH configurations, and then modify the cluster s SSH configuration to only include the three (3) most secure encryption ciphers, and the two (2) most secure key-exchange algorithms. 19 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

3.5.1 Exercise 1. In your PuTTY session to cluster1, view the cluster's current SSH configuration. security ssh show Vserver Ciphers Key Exchange Algorithms --------------- ---------------- -------------------------------------------- cifs_svm aes256-ctr, diffie-hellman-group-exchange-sha256, aes192-ctr, diffie-hellman-group-exchange-sha1, aes128-ctr, diffie-hellman-group14-sha1, aes256-cbc, diffie-hellman-group1-sha1 aes192-cbc, aes128-cbc, 3des-cbc cluster1 aes256-ctr, diffie-hellman-group-exchange-sha256, aes192-ctr, diffie-hellman-group-exchange-sha1, aes128-ctr, diffie-hellman-group14-sha1, aes256-cbc, diffie-hellman-group1-sha1 aes192-cbc, aes128-cbc, 3des-cbc nfs_svm aes256-ctr, diffie-hellman-group-exchange-sha256, aes192-ctr, diffie-hellman-group-exchange-sha1, aes128-ctr, diffie-hellman-group14-sha1, aes256-cbc, diffie-hellman-group1-sha1 aes192-cbc, aes128-cbc, 3des-cbc 3 entries were displayed. Observe that there are independent ssh configuration settings for each SVM. 2. Refine the SSH configuration for cluster1 so it only accepts the more secure algorithms. security ssh modify -vserver cluster1 -key-exchange-algorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1 -ciphers aes256-ctr,aes192-ctr,aes128-ctr Note: Modifications to the cluster SSH configuration become the default for any newly created SVMs that enable SSH management access. Pre-existing SVMs retain their previous SSH configuration. 3. View the cluster's SSH configuration again. security ssh show Vserver Ciphers Key Exchange Algorithms --------------- ---------------- -------------------------------------------- cifs_svm aes256-ctr, diffie-hellman-group-exchange-sha256, aes192-ctr, diffie-hellman-group-exchange-sha1, aes128-ctr, diffie-hellman-group14-sha1, aes256-cbc, diffie-hellman-group1-sha1 aes192-cbc, aes128-cbc, 3des-cbc cluster1 aes256-ctr, diffie-hellman-group-exchange-sha256, aes192-ctr, diffie-hellman-group-exchange-sha1 aes128-ctr nfs_svm aes256-ctr, diffie-hellman-group-exchange-sha256, aes192-ctr, diffie-hellman-group-exchange-sha1, aes128-ctr, diffie-hellman-group14-sha1, aes256-cbc, diffie-hellman-group1-sha1 aes192-cbc, aes128-cbc, 3des-cbc 3 entries were displayed. Cluster1 now only accepts a more restrictive set of cipher and key-exchange algorthims, but other SVMs still retains their previous SSH configuration. 20 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

3.6 Configure CLI Session Timeouts As administrators routinely manage systems from centralized, remote locations, they may do a lot of multitasking and lose track of CLI sessions they have open on various system and Data ONTAP storage clusters. On other occasions, they may be called away from their workstations in order to deal with some other situations. Leaving an unattended, open connection to a critical resource can pose a serious security risk, as a passer-by may see or have access to something which they are not authorized. To help minimize this risk, Clustered Data ONTAP allows you to configure an inactivity timeout feature for CLI type sessions. Since there is no session-lock feature in ONTAP, any logged in session that is idle for more than the inactivity time limit will be terminated. For this exercise, you will modify the CLI session timeout value (in minutes) from the Data ONTAP default of 30 minutes to a new value of 10 minutes. 3.6.1 Exercise 1. In your PuTTY session to cluster1, view your current timeout for CLI sessions. system timeout show CLI session timeout: 0 minutes Your current system timeout is 0 minutes, which means the CLI session will never time out. 2. Change the CLI timeout to 10 minutes. system timeout modify -timeout 10 3. View your current CLI timeout again. system timeout show CLI session timeout: 10 minutes Note: When a CLI session times out in this lab, the associated PuTTY window closes. To avoid the inconvenience of having console sessions close on you during this lab, you might want to consider disabling timeouts entirely by setting the timeout value to 0. 3.7 Configure SSL/TLS Some management features of Clustered Data ONTAP require the existence of certain core web services running on cluster member nodes. The management features might include the following: Web Browser access to the on-board OnCommand System Manager GUI Access by other OnCommand products to the built-in Data ONTAP ontapi interface (using HTTP or HTTPS protocols) By default, the core web services are enabled at time of installation. This allows external web clients access to the exported web content. Enabling these services does not guarantee visibility to clients, only that ONTAP is capable of exporting such content. The system services firewall policies will actually determine which web protocols (HTTP, HTTPS, or both) are visible on a management interface. Note: To enable HTTPS access only, use a custom firewall policy which excludes HTTP as a protocol. 21 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

The HTTPS service supports the following SSL (Secure Socket Layer) capabilities: TLSv1 (Transport Layer Security version 1) which is enabled by default and cannot be turned off. SSLv3 (Secure Socket Layer version 3) which is enabled by default. SSL FIPS 140-2 compliance which is disabled by default. Note: SSLv3 and FIPS 140-2 are mutually exclusive. Enabling FIPS 140-2 mode disables SSLv3. Assuming that HTTPS is allowed in the current firewall policies, access by an external HTTPS client will be determined by the following rules: Table 13: Table: HTTPS Client Access Rules SSL Setting SSLv3 Enabled SSLv3 Disabled FIPS 140-2 Enabled For Access, Client Must Client has access with SSLv3 or TLSv1 Client has access with TLSv1 only Client has access with TLSv1 if FIPS 140-2 compliant For this exercise, you will perform the following tasks: 3.7.1 Exercise View the current SSL/TLS settings and status (both from a cluster and member node perspective). Disable web services. Try connection from a web browser. Enable web services. Try connection from a web browser. Disable the use of SSLv3. Enable FIPS 140-2 compliance. View modified SSL/TLS settings and status. 1. In your PuTTY session for cluster1, display the current availability of web services on the cluster. system services web show External Web Services: true Status: online HTTP Protocol Port: 80 HTTPs Protocol Port: 443 TLSv1 Enabled: true SSLv3 Enabled: true SSL FIPS 140-2 Enabled: false 2. Display the operational configuration for the web server processes on the nodes in the cluster. system services web node show Total Total Node External HTTP Port HTTPs Port Status HTTP Requests Bytes Served ------------- -------- --------- ---------- -------- ------------- ------------ cluster1-01 true 80 443 online 5 2728 3. Disable remote client access to HTTP and HTTPS service content hosted on the cluster. This command will prompt you if you want to continue; respond y. system services web modify -external false Warning: Modifying the cluster configuration will cause pending web service requests to be interrupted as the web servers are restarted. Do you want to continue? {y n}: y 22 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

4. On the desktop of JUMPHOST, launch the Chrome web browser by clicking on the Chrome icon found on the taskbar. 4 Figure 3-5: The Chrome browser opens. 5. Chrome is preconfigured to automatically connect to cluster1 s OnCommand System Manager login page. Since you disabled web services to external clients, the browser should display a message stating This web page is not available. If Chrome does not display this message in your lab, place your cursor at the end of the URL and hit the Enter key to reload the page, which should correct the problem. Figure 3-6: 6. In your PuTTY session to cluster1, re-enable web services. Once again, when prompted whether you want to continue, respond y. system services web modify -external true Warning: Modifying the cluster configuration will cause pending web service requests to be interrupted as the web servers are restarted. Do you want to continue? {y n}: y 23 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

7. Refresh your Chrome browser page. 7 Figure 3-7: The OnCommand System Manager login page now comes up successfully. 8. In your PuTTY session to cluster1, disable SSLv3 by enabling FIPS 140-2 compliance mode. Respond y both times when asked if you want to continue. system services web modify -ssl-fips-enabled true Warning: Modifying the cluster configuration will cause pending web service requests to be interrupted as the web servers are restarted. Do you want to continue? {y n}: y Warning: SSLv3 will be disabled for FIPS compatibility. Do you want to continue? {y n}: y 9. Again, display the current availablility of web services on the cluster. system services web show External Web Services: true Status: online HTTP Protocol Port: 80 HTTPs Protocol Port: 443 TLSv1 Enabled: true SSLv3 Enabled: false SSL FIPS 140-2 Enabled: true 10. Also display again the the operational configuration for the web server processes on the nodes in the cluster. system services web node show Total Total Node External HTTP Port HTTPs Port Status HTTP Requests Bytes Served ------------- -------- --------- ---------- -------- ------------- ------------ cluster1-01 true 80 443 online 1 680 24 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

3.8 NFS/CIFS Export Policies This section introduces the topic of NAS (NFS and SMB) export policies. Export policies are used to restrict NAS access to specific clients. These access restrictions are based on the client host's identity (determined by the host s IP address or subnet) as opposed to an ACL which enforces restrictions based on the identity of the accessing user or group. As of Clustered Data ONTAP 8.2, assigning export policies for SMB (CIFS) access is optional. Many customers are able to sufficently meet their CIFS access control requirements solely through the implementation of ACLs, but customers with more stringent CIFS security requirements can opt to use a combination of CIFS export policies and ACLs to enforce even greater protection. Export policies are mandatory for NFS. A client cannot mount an NFS volume or qtree if there is no associated export policy. When you create a volume for an SVM, clustered Data ONTAP automatically creates a default export policy. It is not populated with any rules. You must explicitly add the rules required to allow client access to NAS data. When you create a CIFS service for an SVM, by default the CIFS export policy is disabled. You can enabled the export policy via the vserver cifs options modify command, which must be issued at the advanced privilege level. If the CIFS service option for using export policies is disabled, then CIFS shares do not require an export policy to operate. Note: You must still create CIFS shares to allow external client access to data over CIFS. Just creating an export policy does not automatically export the data via the CIFS protocol. On the other hand, data served through NFS is exported immediately after NFS centric rules are added to an applied export policy. Export policies are simple containers which hold the rules that are used for access validation. The policy, itself, has a name and is associated with the SVM which owns it. Export policies contain zero (0) or more rules, and access rules must be added to an empty (0 rules) policy before any NAS data can be accessed by clients. These rules contain the following components: Table 14: Table: Export Policy Rule Components Component vserver policy rule index client match access protocol Purpose SVM holding the export policy The export policy name relative placement (index) of rule within the policy (starting at 1) How the client(s) is/are identified: Hostname IPv4 address IPv6 address IPv4 subnet Ipv6 subnet Netgroup Domain Protocol used to access the exported/shared data any - Any current or future protocol nfs - Any current or future version of NFS nfs3 - The NFSv3 protocol 25 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

Component read-only access rule (security type) read/write access rule (security type) anonymous user map superuser access rule (security type) allow suid flag allow dev flag Purpose nfs4 - The NFSv4 protocol cifs - The CIFS protocol flexcache The FlexCache protocol One or more authentication methods allowed for readonly access: sys - AUTH_SYS request krb5 - Kerberos v5 request krb5i - Kerberos v5 with integrity request ntlm - CIFS NTLM request any - match on all types of access request none - allow access as anonymous user never - disallow any type of access request Same access method requests as defined in the readonly access description. User ID to which anonymous users are mapped (65534 default) Same access method requests as defined in the readonly access description with the exception of "never". Honor SetUID bits in SETATTR when true (default) Allow creation of devices is true (default). Access rules are processed sequentially in ascending index order. Placing more restrictive rules before others may prevent access being granted. In addition, a client can only get read-write access for a specific security type if the export rule also allows read-only access for that security type. If the read-only parameter is more restrictive than the read-write parameter, the client might not get read-write access. This exercise consists of two (2) parts, one for CIFS export policies, and one for NFS export policies. For brevity, some customized export policies have been pre-created for the CIFS SVM. You will create customized export policies for the NFS SVM and apply them to several qtrees existing in a volume owned by that SVM. In both cases, you will use the vserver export-policy check-access command to validate that these policies will achieve the proper access requirements desired. 3.8.1 CIFS Exercise In this exercise you will enable CIFS export policy enforcement on the SVM cifs_svm, configure three CIFS export policies, and then apply them to several of the SVM's volumes as detailed in the CIFS Exercise Export Policies table. You will also verify that these policies properly grant/deny access to two different Windows clients in the lab. Table 15: CIFS Exercise Export Policies Volume Export Policy Rule Resulting Access cifs_svm_root default 1 Grant read-write access to all CIFS clients in the lab IP subnet. cifsdv1 cifs_pol1 1 Grant read-only and read-write access to the client WIN2K12R2 2 Deny access to all other clients 26 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

Volume Export Policy Rule Resulting Access cifsdv2 cifs_pol2 1 Grant read-only access to the client "WIN2K12R2". 2 Deny access to all other clients 1. In the PuTTY session for cluster1, switch to advanced mode. set advanced -confirmations off cluster1::*> 2. Determine whether CIFS export policy enforcement is enabled for the SVM cifs_svm. cluster1::*> vserver cifs options show -vserver cifs_svm -fields is-exportpolicy-enabled vserver is-exportpolicy-enabled -------- ----------------------- cifs_svm false cluster1::*> 3. Enable CIFS export policy enforcement for the SVM cifs_svm. cluster1::*> vserver cifs options modify -vserver cifs_svm -is-exportpolicy-enabled true cluster1::*> Note: You can still configure CIFS export policies and rules and apply them to volumes if the vserver s is-exportpolicy-enabled CIFS option is not enabled, but those policies, rules, and assignments will be ignored by clustered Data ONTAP until the SVM's is-exportpolicy-enabled option is set to true. 4. Leave advanced mode. cluster1::*> set admin 5. List the volumes that reside on the SVM cifs_svm. volume show -vserver cifs_svm Vserver Volume Aggregate State Type Size Available Used% --------- ------------ ------------ ---------- ---- ---------- ---------- ----- cifs_svm cifs_svm_root aggr_data1 online RW 20MB 18.85MB 5% cifs_svm cifsdv1 aggr_data1 online RW 10GB 9.50GB 5% cifs_svm cifsdv2 aggr_data1 online RW 10GB 9.50GB 5% 3 entries were displayed. 6. View the export policy assignments for each volume. volume show -vserver cifs_svm -fields policy vserver volume policy -------- ------------- ------- cifs_svm cifs_svm_root default cifs_svm cifsdv1 default cifs_svm cifsdv2 default 3 entries were displayed. For CIFS, export policies can only be applied to volumes. The output lists three volumes, all of which are using the default export policy. The volume names match those in the CIFS Exercise Export Rules table shown earlier in this exercise, but if you look closely, the assigned export policies don t (yet) all match what is in that table. That is because you will configure these policies later in this exercise. 7. View the current list of export policies. vserver export-policy show Vserver Policy Name 27 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

--------------- ------------------- cifs_svm default nfs_svm default 2 entries were displayed. A policy s scope is limited to a single SVM. As you can see, both cifs_svm and nfs_svm have an export policy named default, but these are in fact two separate export policies. Clustered Data ONTAP automatically creates the default policy when you create the SVM. 8. View the rules for cifs_svm's export policies. vserver export-policy rule show -vserver cifs_svm There are no entries matching your query. There are no export rules at present. When a policy gets created it does not contain any rules, and without any rules all mount requests for a volume assigned that policy will be denied. 9. Create a rule in the default export policy that will allow all CIFS clients on the lab s local network. vserver export-policy rule create -vserver cifs_svm -policyname default -ruleindex 1 -protocol cifs -clientmatch 192.168.0.0/24 -rorule krb5 -rwrule krb5 10. View the rules for cifs_svm s export policies again. vserver export-policy rule show -vserver cifs_svm Policy Rule Access Client RO Vserver Name Index Protocol Match Rule ------------ --------------- ------ -------- --------------------- --------- cifs_svm default 1 cifs 192.168.0.0/24 krb5 Observe that this command only shows a partial set of the rule parameters you specified when you created the rule. 11. View the details of the rules for the default export policy. vserver export-policy rule show -vserver cifs_svm -policyname default -instance Vserver: cifs_svm Policy Name: default Rule Index: 1 Access Protocol: cifs Client Match Hostname, IP Address, Netgroup, or Domain: 192.168.0.0/24 RO Access Rule: krb5 RW Access Rule: krb5 User ID To Which Anonymous Users Are Mapped: 65534 Superuser Security Types: none Honor SetUID Bits in SETATTR: true Allow Creation of Devices: true Now you can see the full set of rule properties. This rule grants read-only and read-write access to any CIFS host on the lab s local network (192.168.0.0/24). The krb5 value on the access rule authorizes Kerberos 5 authentication, which is the authentication method used by the Windows 2012 hosts in this lab. The properties that you did not explicity specify were populated with default values, but since these extra properties are not important for this exercise, this guide will not explore them further here. You will now create a new, more restrictive policy and assign it to the cifsdv1 share. 12. Create a new policy named cifs_pol1 for the SVM cifs_svm. vserver export-policy create -vserver cifs_svm -policyname cifs_pol1 28 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

13. Observe that this newly created export policy contains no rules. vserver export-policy rule show -vserver cifs_svm -policyname cifs_pol1 There are no entries matching your query. 14. Add a rule to this policy granting read and read-write access to the IP address assigned to the WIN2K12R2 host. vserver export-policy rule create -vserver cifs_svm -policyname cifs_pol1 -ruleindex 1 -protocol cifs -clientmatch 192.168.0.41 -rorule krb5 -rwrule krb5 15. Add another rule to this policy denying access to all other hosts. vserver export-policy rule create -vserver cifs_svm -policyname cifs_pol1 -ruleindex 2 -protocol any -clientmatch 0.0.0.0/0 -rorule never -rwrule never While this rule is not strictly necessary, as the first rule will only grant explicit access to the 192.168.0.41 host (implying that all others will be denied), it is good security practice to explicitly deny any hosts that you want to exclude as an extra layer of protection. 16. View the details of the rules for the cifs_pol1 export policy. vserver export-policy rule show -vserver cifs_svm -policyname cifs_pol1 -instance Vserver: cifs_svm Policy Name: cifs_pol1 Rule Index: 1 Access Protocol: cifs Client Match Hostname, IP Address, Netgroup, or Domain: 192.168.0.41 RO Access Rule: krb5 RW Access Rule: krb5 User ID To Which Anonymous Users Are Mapped: 65534 Superuser Security Types: none Honor SetUID Bits in SETATTR: true Allow Creation of Devices: true Vserver: cifs_svm Policy Name: cifs_pol1 Rule Index: 2 Access Protocol: any Client Match Hostname, IP Address, Netgroup, or Domain: 0.0.0.0/0 RO Access Rule: never RW Access Rule: never User ID To Which Anonymous Users Are Mapped: 65534 Superuser Security Types: none Honor SetUID Bits in SETATTR: true Allow Creation of Devices: true 2 entries were displayed. As you saw in the CIFS Exercise Export Policies table, the cifs_pol1 policy grants read-only and readwrite access to the host WIN2K12R2, and denies access to all others. 17. Apply this export policy to the volume cifsdv1. volume modify -vserver cifs_svm -volume cifsdv1 -policy cifs_pol1 Volume modify successful on volume cifsdv1 of Vserver cifs_svm. 18. Create the cifs_pol2 policy. vserver export-policy create -vserver cifs_svm -policyname cifs_pol2 29 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

19. Create a rule for this policy granting read-only access to the host WIN2K12R2. vserver export-policy rule create -vserver cifs_svm -policyname cifs_pol2 -ruleindex 1 -protocol cifs -clientmatch 192.168.0.41 -rorule krb5 -rwrule none 20. Add another rule to this policy denying access to all other hosts. vserver export-policy rule create -vserver cifs_svm -policyname cifs_pol2 -ruleindex 2 -protocol any -clientmatch 0.0.0.0/0 -rorule never -rwrule never 21. View the rules for the cifs_pol2 policy. vserver export-policy rule show -vserver cifs_svm -policyname cifs_pol2 -instance Vserver: cifs_svm Policy Name: cifs_pol2 Rule Index: 1 Access Protocol: cifs Client Match Hostname, IP Address, Netgroup, or Domain: 192.168.0.41 RO Access Rule: krb5 RW Access Rule: none User ID To Which Anonymous Users Are Mapped: 65534 Superuser Security Types: none Honor SetUID Bits in SETATTR: true Allow Creation of Devices: true Vserver: cifs_svm Policy Name: cifs_pol2 Rule Index: 2 Access Protocol: any Client Match Hostname, IP Address, Netgroup, or Domain: 0.0.0.0/0 RO Access Rule: never RW Access Rule: never User ID To Which Anonymous Users Are Mapped: 65534 Superuser Security Types: none Honor SetUID Bits in SETATTR: true Allow Creation of Devices: true 2 entries were displayed. 22. Apply the cifs_pol2 export policy to the cifsdv2 volume. volume modify -vserver cifs_svm -volume cifsdv2 -policy cifs_pol2 Volume modify successful on volume cifsdv2 of Vserver cifs_svm. One method to test whether these policies and rules accomplish what you want is to log into the listed clients and attempt to access the applicable shares. However, this would be a labor-intensive exercise, especially if you are dealing with a large number of shares, rules, and clients. Alternately, you can test the processing of the rules directly from the clustered Data ONTAP CLI using the vserver exportpolicy check-access command. 23. In the Putty session for cluster1, test to see if WIN2K12R2 has read access to the cifsdv1 share over the CIFS protocol using Kerberos 5 authentication. You have to use the client's IP address for this test, which in the case of WIN2K12R2 is 192.168.0.41. vserver export-policy check-access -vserver cifs_svm -volume cifsdv1 -protocol cifs -authentication-method krb5 -client-ip 192.168.0.41 -access-type read Policy Policy Rule Path Policy Owner Owner Type Index Access ----------------------------- ---------- --------- ---------- ------ ---------- / default cifs_svm_root volume 1 read /cifsdv1 cifs_pol1 cifsdv1 volume 1 read 2 entries were displayed. 30 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

The output shows the complete access path to the volume, first through the root volume of the cifs_svm SVM's namespace (volume cifs_svm_root, path / ), then through the cifsdv1 volume. As you can see, the 192.168.0.41 client has read access through each of those paths. 24. Test to see if WIN2K12R2 has read-write access to the cifsdv1 volume over the CIFS protocol using Kerberos 5 authentication. vserver export-policy check-access -vserver cifs_svm -volume cifsdv1 -protocol cifs -authentication-method krb5 -client-ip 192.168.0.41 -access-type read-write Policy Policy Rule Path Policy Owner Owner Type Index Access ----------------------------- ---------- --------- ---------- ------ ---------- / default cifs_svm_root volume 1 read /cifsdv1 cifs_pol1 cifsdv1 volume 1 read-write 2 entries were displayed. WIN2K12R2 has read-write access to the path /cifsdv1. 25. Test to see if JUMPHOST has read access to the cifsdv1 volume over the CIFS protocol using Kerberos 5 authentication. The IP address for JUMPHOST is 192.168.0.5. vserver export-policy check-access -vserver cifs_svm -volume cifsdv1 -protocol cifs -authentication-method krb5 -client-ip 192.168.0.5 -access-type read Policy Policy Rule Path Policy Owner Owner Type Index Access ----------------------------- ---------- --------- ---------- ------ ---------- / default cifs_svm_root volume 1 read /cifsdv1 cifs_pol1 cifsdv1 volume 2 denied 2 entries were displayed. Read access is denied at the /cifsdv1 volume level. 26. Test to see if JUMPHOST has read-write access to the cifsdv1 volume over the CIFS protocol using Kerberos 5 authentication. vserver export-policy check-access -vserver cifs_svm -volume cifsdv1 -protocol cifs -authentication-method krb5 -client-ip 192.168.0.5 -access-type read-write Policy Policy Rule Path Policy Owner Owner Type Index Access ----------------------------- ---------- --------- ---------- ------ ---------- / default cifs_svm_root volume 1 read /cifsdv1 cifs_pol1 cifsdv1 volume 2 denied 2 entries were displayed. Write access is also denied at the /cifsdv1 level. 27. On the desktop of JUMPHOST, open Windows Explorer. 27 Figure 3-8: 28. In Windows Explorer, in the navigation pane select This PC. 29. On the menu bar click Computer. 30. Click Map Network Drive. 31 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

29 28 30 Figure 3-9: The Map Network Drive window opens. 31. Set the fields in the window as follows: Drive: X: Folder: \\cifs\cifsdv1 In this lab, DNS is configured to use the hostname cifs for the IP address assigned to the SVM cifs_svm. 32. Click Finish. 32 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

32 Figure 3-10: The Windows Security window opens. 33. Note that the window reports Access is denied. Windows attempted to use your login credentials to access the share, but was unable to because the export policy rules denied access. Windows does not understand the reason for the denial, it just assumes that you need different credentials which is why it prompts you for a login and password. But tegardless of which credentials you enter, the access policy rules prevent you from accessing this share from JUMPHOST. 34. Click the Cancel button. 33 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

33 34 Figure 3-11: The Windows Security window closes, and focus returns to the Map Network Drive window. 35. Click Cancel. 34 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

35 Figure 3-12: The Map Network Drive window closes. In the interest of saving time, you won't check access to the cifsdv1 share from WIN2K12R2 host in this exercise because you will use that share in the next exercise. This will clearly demonstrate that the host WIN2K12R2 can access that share. 3.8.2 NFS Exercise In this exercise you create an NFS export policies for the nfs_svm SVM and apply it to one of the nfsdv volumes two qtrees, as detailed in the NFS Exercise Export Policies table. You will also verify that this policy properly grants/denies access to two different Linux clients in the lab. Table 16: NFS Exercise Export Policies Volume Qtree Export Policy Rule Resulting Access nfsdv default 1 Grant access to underlying qtrees, directories, and files to all NFS clients in the lab IP subnet. qt1 nfs_pol1 1 Grant read-write access to client rhel1 using protocol NFSv4 and AUTH_SYS security 2 Grant read-only access to client rhel1 using protocol NFSv3 and AUTH_SYS security 35 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

Volume Qtree Export Policy Rule Resulting Access 3 Grant read-only access to client rhel2 using protocol NFSv4 and AUTH_SYS security 4 Prohibit access to client rhel2 if protocol is other than NFSv4 qt2 default 1 Grant access to underlying qtrees, directories, and files to all NFS clients in the lab IP subnet. The nfs_svm SVM, the nfsdv volume, and the qt1 and qt2 qtrees have all been pre-created for you. NFS has also been pre-configured for the nfs_svm to support the NFSv3, NFSv4, and NFSv4.1 protocols. The Linux clients you configure the export policies to support are rhel1 (IP address 192.168.0.61) and rhel2 (IP address 192.168.0.62). 1. In the PuTTY session for cluster1, display the list of policies for the svm nfs_svm. vserver export-policy show -vserver nfs_svm Vserver Policy Name --------------- ------------------- nfs_svm default When you first create an SVM, clustered Data ONTAP automatically creates an empty export policy named default. When you create a new volume, clustered Data ONTAP automatically assigns the default export policy to that volume. When you create a qtree, that qtree inherits the parent volume's export policy assignment. 2. Display the list of rules of the default policy for the SVM nfs_svm. vserver export-policy rule show -vserver nfs_svm -policyname default There are no entries matching your query. The default export policy contains no rules, as is the case for any newly created export policy. 3. Add a rule to the default policy that grants read-only access to any client on the labs local network (192.168.0.0/24). vserver export-policy rule create -vserver nfs_svm -policyname default -clientmatch 192.168.0.0/24 -protocol any -rorule any -rwrule never -superuser none -anon 65534 -ruleindex 1 4. Display the updated list of rules for the default policy. vserver export-policy rule show -vserver nfs_svm -policyname default Policy Rule Access Client RO Vserver Name Index Protocol Match Rule ------------ --------------- ------ -------- --------------------- --------- nfs_svm default 1 any 192.168.0.0/24 any 5. Create a new policy named nfs_pol1. vserver export-policy create -vserver nfs_svm -policyname nfs_pol1 6. Add a rule to the nfs_pol1 policy that grants NFSv4 read-write access to rhel1 (IP address 192.168.0.61). vserver export-policy rule create -vserver nfs_svm -policyname nfs_pol1 36 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

-clientmatch 192.168.0.61 -protocol nfs4 -rorule sys -rwrule sys -allow-suid true -allow-dev false -superuser sys -anon 65534 -ruleindex 1 7. Add a rule to the nfs_pol1 policy that grants NFS v3 read access to rhel1. vserver export-policy rule create -vserver nfs_svm -policyname nfs_pol1 -clientmatch 192.168.0.61 -protocol nfs3 -rorule sys -rwrule never -allow-suid false -allow-dev false -superuser none -anon 65534 -ruleindex 2 8. Add a rule to the nfs_pol1 policy that grants NFS v4 read access to rhel2 (IP address 192.168.0.62). vserver export-policy rule create -vserver nfs_svm -policyname nfs_pol1 -clientmatch 192.168.0.62 -protocol nfs4 -rorule sys -rwrule never -allow-suid false -allow-dev false -superuser none -anon 65534 -ruleindex 3 9. Add a rule to the nfs_pol1 policy that denies access to rhel2 via any other protocol than NFSv4. vserver export-policy rule create -vserver nfs_svm -policyname nfs_pol1 -clientmatch 192.168.0.62 -protocol any -rorule never -rwrule never -allow-suid false -allow-dev false -superuser none -anon 65534 -ruleindex 4 10. Display the updated list of rules for the nfs_pol1 policy. vserver export-policy rule show -vserver nfs_svm -policyname nfs_pol1 Policy Rule Access Client RO Vserver Name Index Protocol Match Rule ------------ --------------- ------ -------- --------------------- --------- nfs_svm nfs_pol1 1 nfs4 192.168.0.61 sys nfs_svm nfs_pol1 2 nfs3 192.168.0.61 sys nfs_svm nfs_pol1 3 nfs4 192.168.0.62 sys nfs_svm nfs_pol1 4 any 192.168.0.62 never 4 entries were displayed. 11. List the qtrees on the nfs_svm SVM, along with their assigned export policy. volume qtree show -vserver nfs_svm -fields export-policy vserver volume qtree export-policy ------- ------------ ----- ------------- nfs_svm nfs_svm_root "" default nfs_svm nfsdv "" default nfs_svm nfsdv qt1 default nfs_svm nfsdv qt2 default 4 entries were displayed. The volume qtree show command output does not ordinarily include export policy assignment information, but as you have seen, you can print all of the available fields in a non-table format by using the -instance parameter. The -fields parameter you used here allows you to selectively list the names of just the specific fields you want to display while retaining the table format. The output shows that the all the qtrees are currently assigned the default export policy. When a qtree is created it inherits the export policy associated with it's parent volume. 12. Change the export policy assignment for qtree qt1 to nfs_pol1. volume qtree modify -vserver nfs_svm -volume nfsdv -qtree qt1 -export-policy nfs_pol1 37 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

13. Display the updated qtree export policy assignments. volume qtree show -vserver nfs_svm -fields export-policy vserver volume qtree export-policy ------- ------------ ----- ------------- nfs_svm nfs_svm_root "" default nfs_svm nfsdv "" default nfs_svm nfsdv qt1 nfs_pol1 nfs_svm nfsdv qt2 default 4 entries were displayed. Now test the proper configuration and application of these export policies relative to the rhel1 NFS client by using the vserver export-policy check-access command. 14. Test to see if rhel1 has read access to the qt1 qtree over the NFSv4 protocol using sys authentication. You have to use the client's IP address for this test, which in the case of rhel1 is 192.168.0.61. vserver export-policy check-access -vserver nfs_svm -volume nfsdv -authentication-method sys -client-ip 192.168.0.61 -qtree qt1 -protocol nfs4 -access-type read Policy Policy Rule Path Policy Owner Owner Type Index Access ----------------------------- ---------- --------- ---------- ------ ---------- / default nfs_svm_root volume 1 read /nfsdv default nfsdv volume 1 read /nfsdv/qt1 nfs_pol1 qt1 qtree 1 read 3 entries were displayed. Access is allowed. 15. Test to see if rhel1 has read-write access to the qt1 qtree over the NFSv4 protocol using sys authentication. vserver export-policy check-access -vserver nfs_svm -volume nfsdv -authentication-method sys -client-ip 192.168.0.61 -qtree qt1 -protocol nfs4 -access-type read-write Policy Policy Rule Path Policy Owner Owner Type Index Access ----------------------------- ---------- --------- ---------- ------ ---------- / default nfs_svm_root volume 1 read /nfsdv default nfsdv volume 1 read /nfsdv/qt1 nfs_pol1 qt1 qtree 1 read-write 3 entries were displayed. Access is allowed. 16. Test to see if rhel1 has read access to the qt1 qtree over the NFSv3 protocol using sys authentication. vserver export-policy check-access -vserver nfs_svm -volume nfsdv -authentication-method sys -client-ip 192.168.0.61 -qtree qt1 -protocol nfs3 -access-type read Policy Policy Rule Path Policy Owner Owner Type Index Access ----------------------------- ---------- --------- ---------- ------ ---------- / default nfs_svm_root volume 1 read /nfsdv default nfsdv volume 1 read /nfsdv/qt1 nfs_pol1 qt1 qtree 2 read 3 entries were displayed. Access is allowed. 17. Test to see if rhel1 has read-write access to the qt1 qtree over the NFSv3 protocol using sys authentication. vserver export-policy check-access -vserver nfs_svm -volume nfsdv -authentication-method sys -client-ip 192.168.0.61 -qtree qt1 -protocol nfs3 38 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

-access-type read-write Policy Policy Rule Path Policy Owner Owner Type Index Access ----------------------------- ---------- --------- ---------- ------ ---------- / default nfs_svm_root volume 1 read /nfsdv default nfsdv volume 1 read /nfsdv/qt1 nfs_pol1 qt1 qtree 2 denied 3 entries were displayed. Access is denied. Now test the proper configuration and application of these export policies relative to the rhel2 NFS client, again by using the vserver export-policy check-access command. 18. Test to see if rhel2 has read access to the qt1 qtree over the NFSv4 protocol using sys authentication. vserver export-policy check-access -vserver nfs_svm -volume nfsdv -authentication-method sys -client-ip 192.168.0.62 -qtree qt1 -protocol nfs4 -access-type read Policy Policy Rule Path Policy Owner Owner Type Index Access ----------------------------- ---------- --------- ---------- ------ ---------- / default nfs_svm_root volume 1 read /nfsdv default nfsdv volume 1 read /nfsdv/qt1 nfs_pol1 qt1 qtree 3 read 3 entries were displayed. Access is allowed. 19. Test to see if rhel2 has read-write access to the qt1 qtree over the NFSv4 protocol using sys authentication. vserver export-policy check-access -vserver nfs_svm -volume nfsdv -authentication-method sys -client-ip 192.168.0.62 -qtree qt1 -protocol nfs4 -access-type read-write Policy Policy Rule Path Policy Owner Owner Type Index Access ----------------------------- ---------- --------- ---------- ------ ---------- / default nfs_svm_root volume 1 read /nfsdv default nfsdv volume 1 read /nfsdv/qt1 nfs_pol1 qt1 qtree 3 denied 3 entries were displayed. Access is denied. 20. Test to see if rhel2 has read access to the qt1 qtree over the NFSv3 protocol using sys authentication. vserver export-policy check-access -vserver nfs_svm -volume nfsdv -authentication-method sys -client-ip 192.168.0.62 -qtree qt1 -protocol nfs3 -access-type read Policy Policy Rule Path Policy Owner Owner Type Index Access ----------------------------- ---------- --------- ---------- ------ ---------- / default nfs_svm_root volume 1 read /nfsdv default nfsdv volume 1 read /nfsdv/qt1 nfs_pol1 qt1 qtree 4 denied 3 entries were displayed. Access is denied. 21. Test to see if rhel2 has read-write access to the qt1 qtree over the NFSv3 protocol using sys authentication. vserver export-policy check-access -vserver nfs_svm -volume nfsdv -authentication-method sys -client-ip 192.168.0.62 -qtree qt1 -protocol nfs3 -access-type read-write Policy Policy Rule 39 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

Path Policy Owner Owner Type Index Access ----------------------------- ---------- --------- ---------- ------ ---------- / default nfs_svm_root volume 1 read /nfsdv default nfsdv volume 1 read /nfsdv/qt1 nfs_pol1 qt1 qtree 4 denied 3 entries were displayed. Access is denied. If you would like to test access to these qtrees directly from rhel1 and rhel2, that activity is not covered in this lab guide, but you are welcome to do so on your own. You can use the PuTTY to establish linux terminal sessions to rhel1 and rhel2. 3.9 NFS and SMB (CIFS) ACLs In the previous section, you learned how to control access to NAS exports from client servers and workstations. This section introduces how to control share and file access by users and user groups (data consumers). ACLs have always been a fundamental part of the Microsoft Windows NTFS file system. More recently, ACLs have become a feature in NFS file systems, starting with their introduction in NFSv4. To keeping the length of this exercise manageable, this section will primarily focus on CIFS ACLs. For CIFS, ACLs are commonly implemented at the SMB (CIFS) share level, but may also be implemented at the NTFS directory and file level. Share ACLs and NTFS directory and file level ACLs are not mutually exclusive, meaning they can be used together. When they are used together, the most restrictive ACL takes precedence, so to avoid confusion you should generally make your file/folder ACLs more restrictive than their containing share ACLs. For example, if your share ACL denies write access to all users, you will not be able to write to a folder on the share even if that folders ACL grants Full Control to everyone, a scenario that is often very confusing for end users. When you first create a SMB (CIFS) share, clustered Data ONTAP automatically creates a share level ACL for the share. This default ACL grants full control to the Windows built-in group Everyone. If this default ACL does not provide the exact level of access control you desire, you may use System Manager or the clusterd Data ONTAP CLI to modify and/or delete the default ACL, and add in new ACLs as appropriate to meet your needs. Note: Once you mount a share on a windows client, it is possible to manage the share-level ACLs from that client using the Microsoft Management Console (MMC) Computer Management plug-in. You should do so with caution however, as ii is possible to modify the ACLs such that the client will no longer have access to the share, in which case you will have to resort to using System Manager or the clustered Data ONTAP CLI to recover. The base CLI command for managing share-level ACLs is vserver cifs share access-control, and it has the following subcommands. create modify delete show When you issue the create, modify, and delete commands, you will specify the vserver hosting the share, the share name, the user or group to which the ACL pertains, the type of user or group (windows, Unix-user, Unix group), and a specific permission (access) type from the following table: Table 17: Table: Share-Level ACL Permissions Permission Type No_access Description All access is denied. 40 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

Permission Type Read Change Full_Control Description Can see, open, execute, and view permissions and attributes of the item. Can also list contents of folder. Can create items; see, open, read, write, synchronize and delete the item. Viewing permissions and attributes is also allowed. Can create items; see, open, read, write, delete the item; modify access rights and attributes and take ownership of the item. NFSv4 ACLs (both v4.0 and v4.1) are actually created from the client, but the clustered Data ONTAP vserver nfs modify command includes options that allow you to control whether NFSv4 options are enabled or disabled at the vserver level. NTFS directory and file level ACLs refer to the ACLs on individual files and folders within a share. You are most likely already familiar with managing these kinds of ACLs for NTFS file systems by using Windows Explorer (by viewing a file or folder's properties and going to the Security tab), or perhaps by using the Windows ICACLS command line utility. You can use these same tools to manage the ACLs for individual folders and files hosted on NetApp SMB (CIFS) shares, provided that the underlying volume is using the NTFS security style. The clustered Data ONTAP command line interface (CLI) also provides the vserver security file-directory commands for managing directory and file level access control lists. Using these commands to manipulate ACLs requires a deeper understanding of how Microsoft implements security descriptors, ACLs, and Access Control Entries (ACE), a discussion that falls outside the scope of this lab guide. This lab exercise will also not address managing directory and file ACLs using the vserver security file-directory commands. System Manager does not support managing directory and file level ACLs. Using ACLs to control or restrict access, as well as control the authorized access permissions of users and groups can be a very complex undertaking. Before you attempt to implement ACLs in your own environment, we strongly recommend that you learn more about managing ACLs by reading the following guides: 3.9.1 Exercise Clustered Data ONTAP 8.3 File Access Management Guide for CIFS Clustered Data ONTAP 8.3 File Access Management Guide for NFS Clustered Data ONTAP 8.3 Commands: Manual Page Reference In this exercise, you create several SMB (CIFS) shares, and then view the shares to see how the default sharelevel ACL was created for each. You will next add several share-level ACLs to each share and modify/remove the default Everyone ACL. You will then be able to mount (map to windows drive letters) the shares you have created. 1. In the PuTTY session to cluster1, view a list of the current shares for the SVM cifs_svm. vserver cifs share show -vserver cifs_svm Vserver Share Path Properties Comment ACL -------------- ------------- ----------------- ---------- -------- ----------- cifs_svm admin$ / browsable - - cifs_svm c$ / oplocks - BUILTIN\Administrators / Full Control browsable changenotify cifs_svm cifsdv1 /cifsdv1 oplocks - Everyone / Full Control browsable changenotify cifs_svm cifsdv2 /cifsdv2 oplocks - Everyone / Full Control browsable changenotify cifs_svm ipc$ / browsable - - cifs_svm test_folder /cifsdv2/test_ oplocks - Everyone / Full Control Folder browsable 41 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

6 entries were displayed. changenotify The admin$, c$, and ipc$ shares are automatically created at SVM creation time. They have no direct bearing on shares created for user data use. The cifsdv1, cifsdv2, and test_folder shares were pre-created for this lab. 2. Display a list of the existing share-level ACLs for the SVM cifs_svm. vserver cifs share access-control show -vserver cifs_svm Share User/Group User/Group Access Vserver Name Name Type Permission -------------- ----------- --------------------------- ----------- ----------- cifs_svm c$ BUILTIN\Administrators windows Full_Control cifs_svm cifsdv1 Everyone windows Full_Control cifs_svm cifsdv2 Everyone windows Full_Control cifs_svm test_folder Everyone windows Full_Control 4 entries were displayed. The cifsdv1, cifsdv2, and test_folder shares all grant Full Control to Everyone, which is the default ACL configuration for a newly created share. In the next portion of this exercise you will deploy more restrictive ACLs on these shares. 3. Grant Domain Admins Full Control of each of the the cifsdv1, cifsdv2, and test_folder shares. vserver cifs share access-control create -vserver cifs_svm -user-group-type windows -user-or-group "Domain Admins" -permission Full_Control -share cifsdv1 vserver cifs share access-control create -vserver cifs_svm -user-group-type windows -user-or-group "Domain Admins" -permission Full_Control -share cifsdv2 vserver cifs share access-control create -vserver cifs_svm -user-group-type windows -user-or-group "Domain Admins" -permission Full_Control -share test_folder 4. Add a change permissions ACL to the cifsdv1 share for the CIFS Data Users group. vserver cifs share access-control create -vserver cifs_svm -user-group-type windows -user-or-group "CIFS Data Users" -permission change -share cifsdv1 5. Add a change permissions ACL to the cifsdv2 share for the CIFS 2nd Data Users share. vserver cifs share access-control create -vserver cifs_svm -user-group-type windows -user-or-group "CIFS 2nd Data Users" -permission change -share cifsdv2 6. Add a change permissions ACL to the test_folder share for the CIFS Data Users group. vserver cifs share access-control create -vserver cifs_svm -user-group-type windows -user-or-group "CIFS Data Users" -permission change -share test_folder 7. Remove Everyone from each of the cifsdv1, cifsdv2, and test_folder shares. vserver cifs share access-control delete -vserver cifs_svm -user-or-group "Everyone" -share cifsdv1 vserver cifs share access-control delete -vserver cifs_svm -user-or-group "Everyone" -share cifsdv2 vserver cifs share access-control delete -vserver cifs_svm -user-or-group "Everyone" -share test_folder 42 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

If you had removed the Everyone ACLs before adding the other ACLs then you would have cut off all access to anyone using the share. By adding the new ACLs first, your targeted users can at least still access the share through the ACL change. 8. Display a list of all the share-level ACLs for the SVM cifs_svm. vserver cifs share access-control show -vserver cifs_svm Share User/Group User/Group Access Vserver Name Name Type Permission -------------- ----------- --------------------------- ----------- ----------- cifs_svm c$ BUILTIN\Administrators windows Full_Control cifs_svm cifsdv1 CIFS Data Users windows Change cifs_svm cifsdv1 Domain Admins windows Full_Control cifs_svm cifsdv2 CIFS 2nd Data Users windows Change cifs_svm cifsdv2 Domain Admins windows Full_Control cifs_svm test_folder CIFS Data Users windows Change cifs_svm test_folder Domain Admins windows Full_Control 7 entries were displayed. Now log into the WIN2K12R2 host as two different users ( datauser1 and datauser3 ) to observe these ACLs in action. These accounts both have the shares in the Share Info table pre-mapped. The Share ACL permissions column of this table describes which accounts are granted access to this share by the ACLs you just created, Table 18: Table: Share Info Drive Letter Share Share ACL permissions X: \\cifs\cifsdv1 Change Control for group "CIFS Data Users", of which datauser1 is a member. Y: \\cifs\cifsdv2 Change Control for group "CIFS 2nd Data Users", of which datauser3 is a member. Z: \\cifs\test_folder Change Control for group "CIFS Data Users", of which datauser1 is a member. 9. On the desktop of jumphost, double-click the shortcut named WIN2K12R2, which will launch Remote Desktop Connection Manager for that system. 9 Figure 3-13: The WIN2K12R2 - Remote Desktop Connection Manager window opens. 10. Right-click on WIN2K12R2 in the left pane. 43 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

11. Select Connect group... from the context menu. 10 11 Figure 3-14: Remote Desktop Connection Manager initiates two RDP sessions to the host WIN2K12R2, one for each of the users DEMO\datauser1 and DEMOdatauser3. However, at this point the application will only display a thumbnail window for each desktop session. 12. Expand the desktop session for datauser1 by clicking on the datauser1 entry in the left pane. 12 Figure 3-15: 13. On the WIN2K12R2 desktop for datauser1, open Windows Explorer. 14. In the left pane of Windows Explorer, expand This PC. 15. Observe that the X: and Z: drives are accessible for this account, but the Y: drive is not. This matches the permissions described in the Share Info table. 44 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

14 15 13 Figure 3-16: 16. In the left pane of Windows Explorer, select the X: drive. 17. Right-click in the main pane. 18. Select New > Text Document from the context menu. 19. Name the file "newfile". As expected from the data in the Share Info table, you are able to create the file successfully. 45 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

17 16 18 Figure 3-17: 20. Navigate to the Z: drive. 21. Right-click in the main pane. 22. Select New > Text Document from the context menu. 46 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

21 20 22 Figure 3-18: A "Destination Folder Access Denied" window opens, explaining that you need permission to perform this action. Wait, you created the same ACLs for both the cifsdv1 and test_folder shares, so why is datauser1 able to write to cifsdv1 and not to test_folder? The error message gives no indication as to why permission is denied, all it says is that you need permission, which on it's own isn't very illuminating. The answer lies in the export policy you created in the last exercise. Recall that the cifsdv1 volume is using the cifs_pol1 export policy that grants read and write access to the host WIN2K12R2. The test_folder share is hosted on the cifsdv2 volume, which is using the cifs_pol2 policy that only grants read access to the host WIN2K12R2. So, although the share ACL says you have write permission, the export policy for the share's containing volume takes precedence and restricts you to read-only access. This example illustrates some of the complexities that arise when you deploy both CIFS export polices and share ACLs, which is why CIFS export policy implementations are uncommon. 23. Click the Cancel button. 47 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

23 Figure 3-19: The read-only export policy being used for the cifsdv2 volume will also interfere with the rest of this exercise, so you need to remove this restriction by having the cifsdv2 volume use the same export policy being used for cifsdv1. 24. In the Putty session for cluster1, configure the cifsdv2 volume to use the cifs_pol1 export policy. volume modify -vserver cifs_svm -volume cifsdv2 -policy cifs_pol1 Volume modify successful on volume cifsdv2 of Vserver cifs_svm. 25. In the Remotes Desktop Manager window, in the left pane select the entry for datauser3. 26. Open Windows Explorer. 27. In the left pane of Windows Explorer, expand This PC. 28. Observe that the Y: drive is accessible to this account, but that the X: and Z: drives are not.this matches the desired result described in the Share Info table. 48 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

25 27 28 26 Figure 3-20: 29. Select the Y: drive. 30. In the main pane of Windows Explorer, right-click and select New > Text Document from the context menu. 49 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

29 30 Figure 3-21: Name the file anotherfile, and observe that you are able to create it successfully. 31. Double-click Test_Folder to open it. 50 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

Figure 3-24: Once again, you may wonder why this works given that you set up a share ACL for the Test_Folder share that only grants change control to members of the CIFS Data Users group. The datauser3 account is not a member of that group, so why can it write here? Take a look at the share mappings for datauser3 again, and notice that this account is not able to map to the test_folder share, which is correct behavior based on the share ACLs you configured to meet the requirements listed in the Share Info table. So, access was not granted that way, meaning you must have gained access through some other share. In this example the only mount share is cifsdv2, which is coincidentally the volume on which Test_Folder resides. Share ACLs are enforced when you mount the exact share to which the ACL is assigned. When you have nested shares, and mount the parent share as you did here, it's the parent share's ACL that gets enforced; the share ACLs on the nested shares never come into play. While this is expected behavior, it creates the potential for unintended access, which is why you should avoid deploying nested shares that utilize different export polices unless you also utilize other compensating access controls, such as file system ACLs. 3.10 Review Syslog Events In this section, you connect to the Host functioning as the external syslog server for this lab environment. Once connected, you will navigate to the directory where the log files for the Data ONTAP cluster are stored. By examining the contents of these log files, you will see an audit record of everything you did during your activities in this lab. 53 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

The rsyslog daemon running on the syslog server utilizes a custom configuration designed to filter your CLI activities into a separate log file to make them easier to find and understand. 3.10.1 Exercise 1. On the desktop of JUMPHOST, right-click the PuTTY icon on the task bar. 2. Select syslog from the list of recent sessions. 3. Log in with the username root and the password Netapp1!. 4. Change your working directory to the directory where syslog is capturing the log files for cluster1. [root@syslog ~]# cd /var/log/cluster1-01-logs [root@syslog cluster1-01-logs]# 5. List the contents of the log directory. [root@syslog cluster1-01-logs]# ls -l total 324 -rw------- 1 root root 29971 Sep 27 04:23 command-history-audit.log -rw------- 1 root root 289267 Sep 27 04:23 syslog.log [root@syslog cluster1-01-logs]# The two files you see listed are the product of a custom syslog configuration created for this lab. The syslog.log file captures all of the Data ONTAP EMS events, as well as all user and system generated commands. This includes commands entered through the clustered Data ONTAP CLI as well as management activities initiated tools like through System Manager and the Data ONTAP PowerShell Toolkit that utilize ZAPI API calls. The command-history-audit.log file contains a subset of the entries in the syslog.log file. Specifically, it filters out the EMS and system generated commands so you can more easily view the CLI commands you entered in this lab. If you made configuration changes through tools that use ZAPI, like System Manager, then this file would contain some record of those activities too, although you would need to refer to the syslog.log file to view some additional context information. 6. Use the more command to review the contents of the command-history-audit.log file. [root@syslog cluster1-01-logs]# more commands-history-audit.log Sep 27 03:08:18 cluster1-01 cluster1-01: 00000015.00005e52 00023ff9 Sun Sep 27 2 015 03:08:16 +00:00 [kern_command-history:info:909] ssh :: 192.168.0.61 :: admin :: cluster log-forwarding create -destination 192.168.0.63 -port 514 -facility user :: Pending Sep 27 03:08:18 cluster1-01 cluster1-01: 00000015.00005e54 00023ff9 Sun Sep 27 2 015 03:08:16 +00:00 [kern_command-history:info:909] ssh :: 192.168.0.61 :: admin :: cluster log-forwarding create -destination 192.168.0.63 -port 514 -facility user :: Success Sep 27 03:09:19 cluster1-01 cluster1-01: 00000015.00005e5e 00024264 Sun Sep 27 2 015 03:09:18 +00:00 [kern_command-history:info:909] ssh :: 192.168.0.61 :: admin :: security login role create -role stats -cmddirname DEFAULT -access none :: P ending Sep 27 03:09:19 cluster1-01 cluster1-01: 00000015.00005e61 00024264 Sun Sep 27 2 015 03:09:18 +00:00 [kern_command-history:info:909] ssh :: 192.168.0.61 :: admin :: security login role create -role stats -cmddirname DEFAULT -access none :: S uccess Sep 27 03:09:50 cluster1-01 cluster1-01: 00000015.00005ee8 00024399 Sun Sep 27 2 015 03:09:49 +00:00 [kern_command-history:info:909] ssh :: 192.168.0.61 :: admin :: security login role create -role stats -cmddirname statistics -access all :: Pending Sep 27 03:09:50 cluster1-01 cluster1-01: 00000015.00005eeb 00024399 Sun Sep 27 2 015 03:09:49 +00:00 [kern_command-history:info:909] ssh :: 192.168.0.61 :: admin :: security login role create -role stats -cmddirname statistics -access all :: [7m--More--(4%) The more command displays the file contents one screen at a time. You can page forward using the space bar, and you can terminate the more command at any time by hitting the q key. Each line in the file contains a number of fields separated by double colons. 54 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

The first field starts with a timestamp, followed by some information about the reporting host, more timestamp information, and then in brackets details about the syslog logging facility for this message. The second field contains information about the vector used to enter the command. The string ssh means this entry represents a CLI command entered over ssh. The string ontapi would indicate an activity issued over ZAPI, such as would be the case if you were applying a configuration change through System Manager. The third field is the IP address of the client host that initiated the activity. In this lab 192.168.0.5 is the IP address of JUMPHOST. The fourth field indicates the Data ONTAP user ID under which the operation was performed. In this lab you issued all CLI commands as the admin user. In the case of a CLI command, the fifth field represents the actual clustered Data ONTAP command. In the case of an ontapi entry this field contains some indication of the configuration activity, but you'would need additional context from surrounding entries, and probably from the full syslog.log file, to fully understand the activity. The sixth field indicates the overall status of the activity/command. Pending for an activity in progress, success for one that succeeded, and so on. 7. If you are interested in how this syslog server was configured to segregate log messages in the manner used in this lab, this exercise does not explicitly cover that material, but you are welcome to review the configuration on your own. That configuration is managed through the /etc/rsyslog.conf file on the linux host syslog. [root@syslog cluster1-01-logs]# cat /etc/rsyslog.conf # rsyslog v5 configuration file # For more information see /usr/share/doc/rsyslog-*/rsyslog_conf.html # If you experience problems, see http://www.rsyslog.com/doc/troubleshoot.html #### MODULES #### $ModLoad imuxsock # provides support for local system logging (e.g. via logger command) $ModLoad imklog # provides kernel logging support (previously done by rklogd) #$ModLoad immark # provides --MARK-- message capability # Provides UDP syslog reception $ModLoad imudp $UDPServerRun 514 # Provides TCP syslog reception $ModLoad imtcp $InputTCPServerRun 514 #### GLOBAL DIRECTIVES #### # Use default timestamp format $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # File syncing capability is disabled by default. This feature is usually not required, # not useful and an extreme performance hit #$ActionFileEnableSync on # Include all config files in /etc/rsyslog.d/ $IncludeConfig /etc/rsyslog.d/*.conf #### LOCAL TEMPLATES #### # Template to separate logs by host names $template FILENAME,"var/log/%HOSTNAME%-logs/syslog.log" # Template to capture cdot nteractive command history to a separate file $template FILENAME2,"var/log/%HOSTNAME%-logs/command-history-audit.log" ################################################################################ #### RULES #### ################################################################################ ################################################################################ #### Rules for external sources #### ################################################################################ # Log all external source messages to appropriate directory named for source 55 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

if $fromhost-ip!= '127.0.0.1' then?filename # Filter out non-interactive command history messages if $fromhost-ip!= '127.0.0.1' and $msg contains 'console :: console :: root ::' and $syslogfacility-text == 'user' then ~ if $fromhost-ip!= '127.0.0.1' and $syslogfacility-text == 'user' and $msg contains '[kern_command-history:info:' then?filename2 # If message is external, then we are done. Suppress from further processing. :fromhost-ip,!isequal, "127.0.0.1" ~ ################################################################################ #### Rules for local host server #### ################################################################################ # Log all kernel messages to the console. # Logging much else clutters up the screen. #kern.* /dev/console # The authpriv file has restricted access. authpriv.* # Log all the mail messages in one place. mail.* # Log cron stuff cron.* /var/log/secure -/var/log/maillog /var/log/cron # Everybody gets emergency messages *.emerg * # Save news errors of level crit and higher in a special file. uucp,news.crit /var/log/spooler # Save boot messages also to boot.log local7.* #Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none;cron.none /var/log/boot.log /var/log/messages ################################################################################ ### begin forwarding rule ### # The statement between the begin... end define a SINGLE forwarding # rule. They belong together, do NOT split them. If you create multiple # forwarding rules, duplicate the whole block! # Remote Logging (we use TCP for reliable delivery) # # An on-disk queue is created for this action. If the remote host is # down, messages are spooled to disk and sent when it is up again. #$WorkDirectory /var/lib/rsyslog # where to place spool files #$ActionQueueFileName fwdrule1 # unique name prefix for spool files #$ActionQueueMaxDiskSpace 1g # 1gb space limit (use as much as possible) #$ActionQueueSaveOnShutdown on # save messages to disk on shutdown #$ActionQueueType LinkedList # run asynchronously #$ActionResumeRetryCount -1 # infinite retries if host is down # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional #*.* @@remote-host:514 # ### end of the forwarding rule ### # A template for higher precision timestamps + severity logging $template SpiceTmpl,"%TIMESTAMP%.%TIMESTAMP:::date-subseconds% %syslogtag% %syslogseveritytext%:%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n" :programname, startswith, "spice-vdagent" /var/log/spice-vdagent.log;spicetmpl [root@syslog cluster1-01-logs]# This concludes the activities for this lab. 56 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

4 References The following references were used in writing this lab guide. All guides related to Clustered Data ONTAP are specific to the version used in this lab. Table 19: Table: Lab References Guide Title Publish Date NetApp P/N Clustered Data ONTAP 8.3 System Administration Guide June 2015 215-10116_AO Clustered Data ONTAP 8.3 Commands: Manual Page Reference June 2015 215-10102_AO Clustered Data ONTAP 8.3 File Access Management Guide for CIFS June 2015 215-10104_AO Clustered Data ONTAP 8.3 File Access Management Guide for NFS June 2015 215-10105_AO Clustered Data ONTAP 8.3 Network Management Guide March 2015 215-09157_BO 57 Securing Clustered Data ONTAP 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

Refer to the Interoperability Matrix Tool (IMT) on the NetApp Support site to validate that the exact product and feature versions described in this document are supported for your specific environment. The NetApp IMT defines product components and versions that can be used to construct configurations that are supported by NetApp. Specific results depend on each customer's installation in accordance with published specifications. NetApp provides no representations or warranties regarding the accuracy, reliability, or serviceability of any information or recommendations provided in this publication, or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS, and the use of this information or the implementation of any recommendations or techniques herein is a customer s responsibility and depends on the customer s ability to evaluate and integrate them into the customer s operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document. Go further, faster 2015 NetApp, Inc. All rights reserved. No portions of this presentation may be reproduced without prior written consent of NetApp, Inc. Specifications are subject to change without notice. NetApp and the NetApp logo are registered trademarks of NetApp, Inc. in the United States and/or other countries. All other brands or products are trademarks or registered trademarks of their respective holders and should be treated as such.

Securing Clustered Data ONTAP. December 2015 SL10250 Version 1.0