Communication Security

Communications with the Unisphere and CLI interfaces are conducted through HTTPS on port 443. Attempts to access Unisphere on port 80 (through HTTP) are automatically redirected to port 443.

The storage system automatically generates a self-signed certificate during its first initialization. The certificate is preserved both in NVRAM and on the backend LUN. Later, the storage system presents it to a client when the client attempts to connect to the storage system through the management port.

The certificate is set to expire after 3 years; however, the storage system will regenerate the certificate one month before its expiration date. Also, you can upload a new certificate by using the svc_custom_cert service command. This command installs a specified SSL certificate in PEM format for use with the Unisphere management interface. For more information about this service command, see the Service Commands Technical Notes document. You cannot view the certificate through Unisphere or the Unisphere CLI; however, you can view the certificate through a browser client or a web tool that tries to connect to the management port.

Note:  When the array is in FIPS mode and a certificate is generated off-array, in addition to the certificate being in PEM format, the private key needs to be in PKCS#1 format. You can use an openssl command to do this conversion. Once the .cer and .pk files are generated, this additional step is required when the certificate will be used on an array in FIPS mode.

To increase security, some organizations use CA certificate chaining. Certificate chaining links two or more CA certificates together. The primary CA certificate is the root certificate at the end of the CA certificate chain. Since the system needs the complete certificate chain to verify the authenticity of a certificate that is received, ask the directory server administrator if certificate chaining is used. If so, you must concatenate all the relevant certificates into a single file and upload that version. The certificate must be in PEM/Base64 encoded format and use the suffix .cer.

You can configure the interfaces on a system and use Internet Protocol version 6 (IPv6) addresses to configure different services and features. The following list contains features where IPv6 protocol is supported:

• Interfaces (SF, iSCSI) - to statically assign an IPv4 or IPv6 address to an interface
• Hosts - to enter a network name, an IPv4 address or an IPv6 address of a host
• Routes - to configure a route for IPv4 or IPv6 protocol
• Diagnostics - to initiate a diagnostic ping CLI command using either an IPv4 or IPv6 destination address. In Unisphere select Settings > Access > Routing > Ping/Trace to access the Ping/Trace screen which supports the IPv6 destination addresses as well.

All storage system components support IPv4, and most support IPv6. Table 3 shows the availability of IPv6 support by setting type and component:

When you set up management connections in the storage system, you can configure the system to accept the following types of IP addresses:

• Static Internet Protocol version 6 (IPv6) addresses, IPv4 addresses obtained through DHCP, and static IPv4 addresses
• IPv4 addresses only

You can statically assign the IPv6 addresses to the management interface. An IPv6 address on the management interface can be set to one of two modes, manual/static or disabled. When you disable IPv6, the protocol does not unbind from the interface. The disable command removes any unicast IPv6 addresses assigned to the management interface and the storage system will no longer answer requests addressed over IPv6. IPv6 is disabled by default.

After you finish installing, cabling, and powering up the system, an IP address must be assigned to the storage system management interface. If you are not running the storage system on a dynamic network, or if you would rather manually assign a static IP address, you must download, install, and run the Connection Utility. For more information about the Connection Utility, see Running the Connection Utility.

Inbound requests using IPv6 to the storage system through the management interface are supported. You can configure the management interface on a storage system to operate in an IPv4-only, IPv6-only, or a combined IPv4 and IPv6 environment and you can manage the storage system using Unisphere UI and the command line interface (CLI).

Outbound services such as Network Time Protocol (NTP) and Domain Naming System (DNS) support IPv6 addressing either by using explicit IPv6 addresses or by using DNS names. If a DNS name resolves to both IPv6 and IPv4, the storage system will communicate with the server over IPv6.

The manage network interface set and show CLI commands that are used to manage the management interfaces include attributes related to IPv6. For more information about these manage network interface commands and attributes, refer to the Unisphere Command Line Interface User Guide.

After you finish installing, cabling, and powering up the system, an IP address must be assigned to the storage system management interface. If you are running the storage system on a dynamic network that includes a Dynamic Host Control Protocol (DHCP) server and a Domain Name System (DNS) server, the management IP address can be assigned automatically.

Note:  If you are not running the storage system in a dynamic network environment, or you would rather manually assign a static IP address, you must install and run the Connection Utility. For more information concerning the Connection Utility, see Running the Connection Utility.

The appropriate network configuration must include setting the range of available IP addresses, the correct subnet masks, and gateway and name server addresses. Consult your specific network's documentation for more information on setting up DHCP and DNS servers.

DHCP is a protocol for assigning dynamic Internet Protocol (IP) addresses to devices on a network. DHCP allows you to control Internet Protocol (IP) addresses from a centralized server and automatically assign a new, unique IP address when a storage system is plugged into your organization's network. This dynamic addressing simplifies network administration because the software keeps track of IP addresses rather than requiring an administrator to manage the task.

The DNS server is an IP-based server that translates domain names into IP addresses. As opposed to numeric IP addresses, domain names are alphabetic and are usually easier to remember. Since an IP network is based on IP addresses, every time you use a domain name, the DNS server must translate the name into a corresponding IP address. For example, the domain name www.Javanet.com translates to the IP address 209.94.128.8.

No administrative information such as user names, passwords, and such are exchanged during the DHCP/Dynamic DNS configuration. Configuration of the management IP items (DHCP preference, DNS and NTP server configuration) fall under the existing Unisphere framework related to security. DNS and DHCP events including obtaining a new IP address on lease expiration are recorded in storage system audit logs. If DHCP is not used for the storage system management IP configuration, no additional network ports will be opened.

Dynamic IP addresses (DHCP) should not be used for any components of the EMC Secure Remote Services (ESRS) Virtual Edition (VE) servers, Policy Manager servers, or managed devices.

Note:   If you use DHCP to assign IP addresses to any ESRS components (ESRS VE servers, Policy Manager, or managed devices), they must have static IP addresses. Leases for the IP addresses that EMC devices use cannot be set to expire. EMC recommends that you assign static IP addresses to those devices you plan to have managed by ESRS.

SMB 3.0 and Windows 2012 support on the storage system provides SMB encryption for those hosts capable of using SMB. SMB Encryption provides secure access to data on SMB file shares. This encryption provides security to data on untrusted networks, that is, it provides end-to-end encryption of SMB data sent between the array and the host. The data is protected from eavesdropping/snooping attacks on untrusted networks.

SMB Encryption can be configured for each share. Once a share is defined as encrypted, any SMB3 client must encrypt all its requests related to the share; otherwise, access to the share will be denied.

To enable SMB Encryption, you either set the Protocol Encryption option in the advanced SMB share properties in Unisphere or set it through the create and set CLI commands for SMB shares. There is no setting required on the SMB client.

Note:  For more information about setting SMB encryption, refer to the Unisphere online help and the Unisphere Command Line Interface User Guide.

SMB also provides data integrity validation (signing). This mechanism ensures that packets have not been intercepted, changed, or replayed. SMB signing adds a signature to every packet and guarantees that a third party has not changed the packets.

To use SMB signing, the client and the server in a transaction must have SMB signing enabled. By default, Windows Server domain controllers require that the clients use SMB signing. For Windows Server domains (Windows 2000 and later), SMB signing is set by using a group policy object (GPO) policy. For Windows XP, GPO services for SMB signing are not available; you must use the Windows Registry settings.

Note:  Configuring SMB signing through GPOs affects all clients and servers within the domain and overrides individual Registry settings. Refer to Microsoft's security documentation for detailed information about enabling and configuring SMB signing.

In SMB1, enabling signing significantly decreases performance, especially when going across a WAN. There is limited degradation in performance with SMB2 and SMB3 signing as compared to SMB1. The performance impact of signing will be greater when using faster networks.

NOTICE   If the older SMB1 protocol does not need to be supported in your environment, it can be disabled by using the svc_nas service command. For more information about this service command, see the Service Commands Technical Notes.

Configure SMB signing with GPOs

Table 4 explains the GPOs available for SMB1 signing.

Note:   For SMB2 and SMB3, each version has a GPO for each side (server-side and client-side) to enable the Digitally sign communications (always) option. Neither server-side nor client-side has a GPO to enable the Digitally sign communications (if client agrees) option.

Table 4. SMB1 signing GPOs

GPO name	What it controls	Default setting
Microsoft network server: Digitally sign communications (always)	Whether the server-side SMB component requires signing	Disabled
Microsoft network server: Digitally sign communications (if client agrees)	Whether the server-side SMB component has signing enabled	Disabled
Microsoft network client: Digitally sign communications (always)	Whether the client-side SMB component requires signing	Disabled
Microsoft network client: Digitally sign communications (if server agrees)	Whether the client-side SMB component has signing enabled	Enabled

You can also configure SMB signing through the Windows Registry. If a GPO service is not available, such as in a Windows NT environment, the Registry settings are used.

Configure SMB signing with the Windows Registry

Registry settings affect only the individual server or client that you configure. Registry settings are configured on individual Windows workstations and servers and affect individual Windows workstations and servers.

Note:  The following Registry settings pertain to Windows NT with SP 4 or later. These Registry entries exist in Windows Server, but should be set through GPOs.

The server-side settings are located in: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\lanmanserver\parameters\

Note:  For SMB2 and SMB3, each version has a Registry key for each side (server-side and client-side) to enable the requiresecuritysignature option. Neither server-side nor client-side has a Registry key to enable the enablesecuritysignature option.

Table 5. Server-side SMB1 signing Registry entries

Registry entries	Values	Purpose
enablesecuritysignature	0 disabled (default) 1 enabled	Determines if SMB signing is enabled.
requiresecuritysignature	0 disabled (default) 1 enabled	Determines if SMB signing is required.

The client-side settings are located in: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\lanmanworkstation\parameters\

Table 6. Client-side SMB1 signing Registry entries

Registry entries	Values	Purpose
enablesecuritysignature	0 disabled 1 enabled (default)	Determines if SMB signing is enabled.
requiresecuritysignature	0 disabled (default) 1 enabled	Determines if SMB signing is required.

IP packet reflect provides your network with an additional security level. Because the majority of network traffic on a NAS server (including all file system I/O) is client initiated, the NAS server uses Packet Reflect to reply to client requests. With Packet Reflect, there is no need to determine the route to send the reply packets. Because reply packets always go out the same interface as the request packets, request packets cannot be used to indirectly flood other LANs. In cases where two network devices exist, one connected to the Internet and the other connected to the intranet, replies to Internet requests do not appear on the intranet. Also, the internal networks used by the storage system are not affected by any packet from external networks.

IP packet reflect can be enabled for each NAS server. It is disabled for all NAS servers by default.

IP multi-tenancy provides the ability to assign isolated, file-based storage partitions to the NAS servers on a storage processor. Tenants are used to enable the cost-effective management of available resources, while at the same time ensuring that tenant visibility and management is restricted to assigned resources only.

Note:  If this is the first creation of a tenant in your environment, have the system automatically generate a Universal Unique Identifier (UUID) value for the tenant. For existing tenants in your environment that have a system generated UUID value, enter that UUID value manually.

With IP multi-tenancy, each tenant can have its own:

• IP addresses and port numbers.
• VLAN domain.
• Routing table.
• IP firewall.
• DNS server or other administrative servers to allow the tenant to have its own authentication and security validation.

IP multi-tenancy is implemented by adding a tenant to the storage system, associating a set of VLANs with the tenant, and then creating one NAS server for each of the tenant's VLANs, as needed. It is recommended that you create a separate pool for the tenant and that you associate that pool with all of the tenant's NAS servers.

Note:  A pool is a set of drives that provide specific storage characteristics for the resources that use them.

Note the following about the IP multi-tenancy feature:

• There is a one-to-many relationship between tenants and NAS servers. A tenant can be associated with multiple NAS servers, but a NAS server can be associated with only one tenant.
• You can associate a NAS server with a tenant when you create the NAS server. Once you create a NAS server that is associated with a tenant, you cannot change any of its properties.
• During replication, data for a tenant is transferred over the service provider's network rather than the tenant's network.
• Because multiple tenants can share the same storage system, a spike in traffic for one tenant can negatively impact the response time for other tenants.

Federal Information Processing Standard 140-2 (FIPS 140-2) is a standard that describes US Federal government requirements that IT products should meet for Sensitive, but Unclassified (SBU) use. The standard defines the security requirements that must be satisfied by a cryptographic module used in a security system protecting unclassified information within IT systems. To learn more about FIPS 140-2, refer to FIPS 1402-2 publication.

The storage system supports FIPS 140-2 mode for the SSL modules that handle client management traffic. Management communication into and out of the system is encrypted using SSL. As a part of this process, the client and the storage management software negotiate a cipher suite to use in the exchange. Enabling FIPS 140-2 mode restricts the negotiable set of cipher suites to only those that are listed in the FIPS 140-2 Approved Security Functions publication. If FIPS 140-2 mode is enabled, you may find that some of your existing clients can no longer communicate with the management ports of the system if they do not support FIPS 140-2 Approved cipher suites. FIPS 140-2 mode cannot be enabled on a storage system when non-FIPS-compliant certificates exist in the certificate store. You must remove all non-FIPS compliant certificates from the storage system before you enable the FIPS 140-2 mode.

Management communication into and out of the storage system is encrypted using SSL. As a part of this process, the client and the storage system negotiate an SSL protocol to use. By default, the storage system supports TLS 1.0, TLS 1.1, and TLS 1.2 protocols for SSL communications. The storage system includes an administrative setting to disable TLS 1.0 from the system. Disabling the TLS 1.0 protocol using this setting means that the storage system will only support SSL communications using the TLS 1.1 and TLS 1.2 protocols and TLS 1.0 will not be considered a valid protocol.

Note:   Disabling TLS 1.0 may impact existing client applications which are not compatible with TLS 1.1 or TLS 1.2 protocols. In this case, TLS 1.0 support should remain enabled. The following functionality will not work when TLS 1.0 is disabled: Technical advisories Software, drive firmware, and language pack upgrade notifications Replication from OE versions earlier than 4.3 to OE version 4.3

The storage system SSH service interface is hardened with restricted shell (rbash) mode. This feature is enabled by default for the service account upon upgrading to Unity OE version 4.5 or later. Although temporarily disabling restricted shell mode is possible, it is not persistent and it will be automatically re-enabled when one of the following occurs:

• The primary Service Processor is re-booted.
• 24 hours elapse since restricted shell mode was disabled.

This feature enhances the security posture of the Unity storage system by restricting service account users to the following functions:

• Operate only a limited set of commands that are assigned to a member of a non-privileged Linux user account in restricted shell mode. The service user account does not have access to proprietary system files, configuration files, or user or customer data.
• Restricts service users from executing untrusted code that could be potentially leveraged to exploit local privilege escalation vulnerabilities.

Besides service scripts, a white list contains basic commands that are available to service personnel. These are the safe commands or the commands with security control from which users cannot escape the restricted shell mode. These commands are essential for Dell EMC service personnel to provide maintenance service without elevating the privilege to root. For information about these commands, see Knowledge Based Article 528422.

NOTICE  A network vulnerability scan cannot be performed with restricted shell by default. Unisphere Admin users need to disable restricted shell mode in order to facilitate a security scan. For maximum system security, it is highly recommended to leave the restricted shell mode enabled at all times unless it is needed to perform a security scan. To ensure that the system is not exposed to local privilege escalation vulnerabilities, enable restricted shell mode as soon as the security scan completes.