OnCommand Workflow Automation Pack for Security Hardening
Introduction to the Security Hardening pack
The OnCommand Workflow Automation Pack for Security hardening assists administrators in configuring settings to help an organisation meet its prescribed security objectives.
Why you should use the Security Hardening pack
Using this workflow pack increases productivity as storage administrators need to manually configure security settings for the cluster and this process takes time. The security configuration is done based on user inputs provided in the workflow that can be customized by the storage administrators.
Prerequisites for executing the Security Hardening pack on a single cluster
You must ensure that the following prerequisites are met before executing the Security Hardening pack. You must have storage administrator privileges to execute this workflow.
The following prerequisites apply:
§ Your system must be running clustered Data ONTAP 9.3.
§ You must have a cluster management IP address configured and accessible by WFA.
§ You must have Workflow Automation (WFA) 4.2 installed.
§ You must have added the WFA credentials for the Active Directory (AD) domain from the Credentials window.
For the AD domain, you must provide the following input parameters:
§ DNS details should be added in the WFA credentials window:
§ A CIFS license must be enabled on the cluster.
§ You must have added WFA server credentials to the WFA database using the option Execution > Credentials, type: Other and Name/IP: localhost:
Prerequisites for executing a multiple cluster configuration for the Security Hardening pack
You must ensure that the following prerequisites are met before executing the security hardening pack on multiple clusters. You must have storage administrator privileges to execute this workflow.
The following prerequisites apply:
· User inputs are provided in a comma separated value (CSV) file.
· The multiconfig.csv file can be accessed from here. You must place the multiple cluster configuration file in the C:/ drive of the installed Windows WFA machine.
· When the multiple cluster configuration for security hardening workflow is executed, multiple job IDs are executed for each cluster.
Example of a CSV file for two clusters:
Steps to complete for the Security Hardening pack
The following steps must be completed for the security hardening pack for clustered Data ONTAP:
1. Input the cluster IP address.
Input the applicable IP address and by default, this step enables the IPv6 option in the cluster.
Note: Once IPv6 has been enabled, configure the required interfaces with their respective IPv6 addresses.
Provide the cluster username and new password to be configured after the executing the modify security login role configuration command in the workflow.
Ensure that the same password (provided in the workflow) is provided when resetting the new password in the cluster. Next approve and resume the workflow. Once the workflow has resumed, the password provided earlier is modified in the WFA credentials for the cluster.
2. Disable Service Processors (SP) IPv4/IPv6
This step disables the configured SP for each node with respect to the IPv4/IPv6 address type.
3. Disable AutoSupport
This step is used to disable the configured auto support in the cluster.
4. Setup encryption ciphers and key exchange algorithms used by the SSH protocol
This step removes unwanted ciphers and key exchange algorithms from the cluster Vserver and keeps only, for example:
Ciphers: aes256-ctr, aes192-ctr,aes128-ctr,aes128-gcm,aes256-gcm
Key exchange algorithm: Diffie-hellman-group-exchange-sha256
After executing this step, configured encryption cipher and key exchange algorithm will inherit new settings for all the newly created data Vservers.
5. Setup secure firewall policies
This step covers creating the management access firewall policy and is applied to both cluster and node management LIFs.
This step only allows the following services:
· DNS
· SSH
· NTP
All other services are not allowed.
Note: An HTTPS service is allowed for the secure_mgmt policy due to a current requirement within WFA.
6. Active Directory Domain access firewall policy
This step covers creating the AD domain access firewall policy and it is applied to data management LIFs.
A policy is created specifically for the SVM running the CIFS protocol granting access to the Microsoft Active Directory Domain.
This step only allows the following services:
· DNS
· NTP
All other services are not allowed.
Note: An HTTPS service is allowed for the domain_access policy due to a current requirement within WFA.
7. Create failover group
This step creates a new failover group with the specified node name and ports. The newly created failover group should be assigned to the data Vserver.
8. Create CIFS SVMs
This step is used to create and configure an SVM with the CIFS protocol. The SVM is created with CIFS configured and enabled. It also provides access to storage administrators who need to use their AD Domain credentials to authenticate and manage the SVM. The SVM data LIF is created with AD and DNS details.
9. Create an Active Directory Domain Tunnel
This step is used to link the cluster management SVM to the domain via an internal tunnel, allowing for management via AD domain user account authorization.
Note: The SVM must be running CIFS.
10. Network Time Protocol (NTP) configuration
This step configures a cluster to use a network time protocol (NTP) server.
11. Session timeout value
This step is used to set the current CLI session timeout value (in minutes).
Note: This session timeout also applies to console sessions.
12. Create event notification destination, create event filter, add event filter rule, and create event notification (configure syslog)
The event destination ‘allevents1’ is used and configured to point to an external Syslog server. Event messages are assigned and routed to the ‘allevents1’ destination. As there are over 7000 different event messages currently defined for ONTAP, care should be taken when determining which messages to select.
13. Create administrative user accounts and account access roles
This step outlines how to create administrative user accounts and account access roles.
It is appropriate to assign the ‘admin’ role to the emergency login account, as this account must have complete administrative capability on the cluster. The following modifications must be made to that role in order to comply with DISA STIGs. The values supplied should reflect the current data center polices in effect at the installation site.
A role ‘admin_ssh’ should be created for top-level administrative users who use SSH to login and are authenticated by the Microsoft Active Directory Domain. The role is similar to the built-in ‘admin’ role with the exception that the ability to access/manage the SP configuration settings is removed.
Note: The values used in the configuration settings should mirror (as closely as possible) those used in the Microsoft Active Directory Domain used for login authentication. In addition, other access roles may be defined and tailored to meet the specific need of lower-level administrators.
13.1 Create the local emergency administrator account
This step creates an emergency administrative account for use during network outages. This account has access via the controller serial console only. Authentication is by local password. Full CLI and security capability roles are granted to this account by it being granted the ‘admin’ role. This account is defined twice. Once for serial console access, and once for SP login access.
Note: The workflow creates the username E_User for both the services.
13.2 Create administrative user accounts authenticated by the Microsoft Active Directory Domain
Administrative user accounts that are authenticated by the Microsoft Active Directory Domain require that the user account already exist within the domain.
Note: The username is expressed as the NETBIOS name of the domain followed by a double backslash (“\\”) and followed by the username of the domain. When logging into the cluster, the same syntax for the username must be used.
14. Disable External Web Access
This step augments the system firewall policies that prevent Web access (http/https) by clients external to clustered Data ONTAP. Firewall policies must deny HTTP and HTTPS access.