SSLv Security Best Practices
Article ID: 258800
Updated On:
Products
Issue/Introduction
View best practices for running the SSL Visibility appliance securely.
Resolution
Sensitive Data
SSL Visibility and other Symantec products that are deployed on customer premises as data processing tools offer features to enable or support the customer’s compliance with requirements such as the GDPR. For instance, as Data Controllers under the GDPR, SSL Visibility customers have several options to configure those features as best suited to the particular requirements that are applicable to them. Liken SSL Visibility data processing to the following analogy: “We make the turn signals in the car, but it’s the driver’s responsibility (and liability) to use them to indicate a turn.” Symantec neither has nor needs any knowledge of the particular requirements applicable to the customer, so the customer does not need to disclose any such information to Symantec for the product to be fully functional. Moreover, Symantec is not involved as a Data Processor in the operation of on-premise products, which means that the customer retains full control of all personal data that SSL Visibility collects, generates, or stores. The SSL Visibility appliance collects certain information, including personal data, in system logs regarding administrators who log in to configure the appliance. Customers can optionally upload additional data to Symantec using the “sosreport” feature to help Customer Support debug issues they are having. The personal data contained in “sosreport” includes administrator user names and IP addresses of client machines. SSL Visibility Session Logs contain the system host name and IP address. SSL Visibility packet capture files may contain sensitive data including, but not restricted to, IP addresses, host names, user names, user activity, and login credentials. Sensitive information should be reviewed and possibly edited or redacted by customers before submitting to Symantec Customer Support. Delete packet capture files if they are no longer needed.
Managing User Access
SSL Visibility offers ways to authenticate local users (accounts that are created on the system) and remote users (accounts that are managed by a remote LDAP or TACACS+ server).
Role-Based Authentication
The SSL Visibility appliance uses role-based authentication with separation of duties, which prevents authenticated users from performing undesired actions. For example:
- The Manage Appliance role is for system and network administrators, who need to manage the system and network settings.
- The Manage Policy role is for policy and compliance administrators, who need to manage rules for processing and decrypting SSL traffic.
- The Manage PKI role is for PKI administrators who need to manage the cryptographic keys, certificates and CRLs on the appliance.
- The Auditor role is for auditors, who need to view the appliance configuration and log files, but cannot modify any settings.
Create different user accounts with different user roles to implement a level of privilege separation appropriate for the security policies and requirements set by the organization deploying the SSL Visibility appliance. Elevated privilege separation would prevent authenticated users from performing unauthorized functions, such as an auditor from modifying the decryption policy. For more information about the functions authorized for each user role, refer to Table: User Roles and Privileges.
Password Policy
When local authentication is implemented, administrators have the ability to configure password policy. Ensure the password policy at a minimum meets the following default requirements for password complexity:
- Password length: At least eight characters
- Number of lower case characters: At least one
- Number of upper case characters: At least one
- Number of digit characters: At least one
- Number of special characters: At least one
- Prohibit common words
- Prohibit whitespace characters
Password complexity requirements apply to local user accounts and SNMPv3 User and Trap User passwords. They do not apply to TACACS+ or LDAP user accounts. When remote authentication is used, the password rules are controlled on the remote server, by the LDAP or TACACS+ server. However, these passwords should conform to similarly stringent policy.
User Session Management
Ensure administrators configure a session inactivity timeout to minimize open, unattended sessions on the appliance. By default, the Inactivity Timeout is enabled. You should keep this setting enabled and configure the minimum inactivity timeout consistent with user’s needs. The User Session Inactivity Timeout option applies to local and remote users. Furthermore, administrators should limit the number of concurrent logins allowed per user. The Concurrent Login Sessions controls the number of concurrent logins for the combined total of WebUI and SSH logins per user, both remote and local users. Combined with a session inactivity timeout, it helps to minimize unattended sessions on the appliance. This option is disabled by default. Enable Limit Concurrent Login Sessions Per User and configure the minimum number of concurrent sessions consistent with users' needs.
See Limit Time of Idle User Sessions and Limit Concurrent Login Sessions for information on configuring these options.
For enhanced security, the maximum number of unsuccessful SSH login attempts is limited to three. After three failed
attempts, the SSH session is disconnected.
Remote Authentication
For security best practices, use LDAP, rather than TACACS+, since SSL Visibility has an option for encrypted LDAP communication (via TLS) when authenticating SSL Visibility appliance users. See LDAP Authentication for information on
configuring an LDAP server for remote authentication using TLS. Depending on your company’s security standards, you may want to configure a Management Certificate Authority List that contains the CAs that signed the LDAP server’s certificate, then create an SSL Context for this list, and configure the remote-auth management service. See Management Trust for details. Whether you are implementing remote authentication via LDAP or TACACS+, you must decide whether you want the system to fall back to local authentication. Falling back to authenticating users against the appliance's local user list is useful in situations such as:
- When the remote authentication server is not available
- When using device-specific local accounts that might not be maintained in the remote authentication server (such as the default administrator account 'admin')
- When allowing automated functions (such as device interactions with Management Center) to bypass two-factor authentication mechanisms used by remote authentication servers
CAUTION
If you disable the Fallback to Local Authentication, you will be unable to access the SSL Visibility appliance in the event of a failure in the remote authentication infrastructure.
For more information on fallback settings, see Set Remote Authentication Options.
Management Interfaces Access Control
Develop the SSL Visibility appliance in a secured network that appropriately restricts access to the appliance management network interfaces. Doing this will prevent non-authorized users from accessing the appliance management interfaces—WebUI, command line interface (CLI), and SNMP interface. Network administrators can use firewall rules to restrict access to the SSL Visibility appliance’s IP address. Authenticated users with the Manage Appliance role can also use the Access Control Lists feature to restrict incoming WebUI, CLI, and SNMP connections. To avoid a potential DNS rebinding vulnerability, set the hostname of the localhost to the DNS hostname for the appliance. To use the Fully Qualified Domain Name (FQDN) to log on to the In SSL Visibility appliance, the appliance hostname must match the FQDN exactly.
For more information about controlling access to management interfaces, see Access Control Lists.
Secure Network Connections
The SSL Visibility appliance intercepts and decrypts network traffic on dedicated physical network interfaces, which are physically separate from the appliance management interfaces. The data interfaces do not provide management access to the SSL Visibility appliance. Although the data interfaces need not be subject to the same access control restrictions as the management network interfaces, they should be configured securely to segregate decrypted content from the general network. When connecting the SSL Visibility appliance to a ProxySG device, or any other device in the active loop, directly wire the device to the SSL Visibility appliance when possible, or use a dedicated network infrastructure (i.e., independent switches).
Secure SNMP Monitoring
The SSL Visibility appliance supports the more secure SNMP version 3, which supports authentication and encryption for SNMP monitoring. Even though SNMP versions 1 and 2c are also supported, keeping them disabled to prevent nonauthorized users from monitoring the appliance is the best practice. Additionally, use the default options of AES-128 for encryption and SHA1 (160 bit) for authentication for SNMP version 3. Consider configuring SNMP v3 Trap Users, which provides authentication and privacy passphrases, and requires configuration of the SSL Visibility appliance EngineID on the trap listener. For configuration information see Enable SNMPv3 Access.
System and Session Log Monitoring
Send SSL Visibility system and session logs to a remote syslog server and monitoring the logs. When monitoring these logs, look for critical process failures, segments failing, and unexpected user login attempts. Login credentials in the system logs are limited to logging username for auditing purposes. If you have sensitive flows that you don't want mentioned in the session log, uncheck the Include in Session Log option when defining or editing a rule. See Configure Rulesets to Handle SSL Traffic.
When configuring remote syslog servers, set up secure connections by choosing TLS for the Protocol when defining the server. The TLS version is defined as part of the SSL context for the remote-logging management trust service. This context specifies the minimum and maximum TLS versions used in remote logging sessions; as a security best practice, specify TLS 1.2 as the minimum and maximum version. See Set Up Secure Connections with a Remote Syslog Server and Management Trust.
Secure Email Alerts
When configuring an SMTP server that the SSL Visibility appliance will use to send alert messages, enable TLS for the most secure method of sending emails. See Add Alert SMTP Server. The SSL context associated with the email-alerts management trust service specifies the minimum and maximum TLS versions SSL Visibility uses when sending email alerts. You may want to create a custom SSL context for the email-alerts service; see Management Trust.
Secure Connections with NTP Servers
When NTP is enabled on the SSL Visibility appliance, the appliance periodically connects with the configured NTP server(s) and synchronizes its date and time. To avoid denial-of-service attacks against NTP servers, set up secure connections with the NTP servers you add to SSL Visibility. See Use NTP Servers. To ensure only secure NTP servers are used, delete any non-secure ones from the list.
Certificate Resigning Using Secure Key Sizes
When the SSL Visibility appliance policy decrypts an SSL flow using a “Decrypt (Resign Certificate)” rule, the appliance will modify and resign the flow’s server certificate. It signs the certificate using a resigning certificate authority configured through the WebUI. Resigning a server certificate with an insecure certificate authority key is a security vulnerability because it allows a downstream attacker to perform a man-in-the-middle attack and decrypt the encrypted TLS payload. When configuring resigning certificate authorities in the PKI store, use RSA keys of size 2048 bits or higher, or Elliptic Curve keys on curves of size 224 bits or higher.
HSM Authentication Using Secure Key Sizes
When using an HSM appliance for certificate resigning, the SSL Visibility appliance authenticates to the HSM using a TLS client certificate and key. Using insecure key sizes for client authentication may allow an attacker to impersonate an SSLV appliance and get a malicious certificate signed by the HSM. Clients are typically configured to trust the HSM signing key certificate, allowing the attacker to stage a man-in-the-middle attack. Configure client authentication to HSM appliances to use RSA client certificates and keys of size 2048 bits.
SSL Visibility WebUI Keys and Certificates Using Secure Key Sizes
The SSL Visibility WebUI is only accessible over encrypted and authenticated TLS connections. The WebUI server is configured with a private key and certificate for TLS authentication. Using insecure key sizes may allow an attacker to impersonate the WebUI server and cause appliance administrators to inadvertently reveal sensitive password information. Use RSA keys of size 2048 bits or higher for the appliance WebUI. For increased security, import a customer supplied key and certificate to authenticate SSL Visibility WebUI connections. To import a key and certificate:
- From the Platform Management (system name) menu, select Import UI Certificate/Key.
- Upload the certificate and key files, or paste the certificate and key data on the Paste tab, supplying an encryption password if required, and click Add.
- Reboot the appliance to enable the changes to take effect.
Using Secure Cipher Suites
Refer to Cipher Suites for a list of cipher suites that SSL Visibility supports. The table indicates the strength of each cipher suite (Strong, Adequate, Weak, Insecure). If possible, only use Strong cipher suites. To find out the cryptographic strength of the algorithms used in SSL sessions, you can view the Session Strength doughnut chart in the WebUI Dashboard. See Dashboard for more information. SSL Visibility currently does not provide a way to disable cipher suites, nor can the Administrator change the cipher suites for managing SSL Visibility.
Wiping Appliance Hard Disk Before RMA
The SSL Visibility appliance stores configuration data, log files and statistics on internal persistent storage. When decommissioning a deployed appliance or before returning an already configured appliance to Symantec, erase data on internal persistent storage devices. Erasing persistent data is done using the restore-defaults factory-defaults operation from the CLI:
- Connect via serial console to the appliance.
- Log on the CLI, and enter the enable password.
- Execute the restore-defaults factory-defaults halt command.
- The appliance clears the contents of the persistent storage devices, restores the factory default settings, and shuts down.
After the appliance restarts, user data will be wiped.
NOTE
The wipe procedure used by the “restore-defaults factory-defaults halt” command may not purge all sensitive data from the internal storage devices.
Additional Information
Feedback
