Basic Administration Server Settings

To manage basic security settings, click System > Security. This takes you to the “Administration Security” page where you can configure the SSL certificate, IP-based access controls, and the ports used by the Administration Server.

Changing the Admin Server SSL Certificate

The first option, SSL Certificate, allows you to change the SSL certificate used for the Traffic Manager Admin Server Web-based user interface (the Admin UI). You can choose to generate a new, self-signed certificate, or upload new certificate and private key files. Click Update to save your changes.

You cannot choose a certificate from the catalog, since the Admin Server is not a public service but a separate, external process in the Traffic Manager framework.

The SHA-1 fingerprint of the SSL certificate is displayed here. This is useful for the following reasons:

•To verify the SSL certificate when connecting with a Web browser for the first time.

•To verify the authenticity of Traffic Manager identities when joining a cluster.

Ivanti recommends making a note of the fingerprint upon setting up a new Traffic Manager for the first time. For software variants, the fingerprint is displayed on the command line after completion of the installation process. For appliances and cloud instances, see the console.

Should you need to view the fingerprint again, display it from the command line using the following command:

$ZEUSHOME/admin/bin/cert -f fingerprint -in $ZEUSHOME/admin/etc/admin.public

Restricting Access to the Admin Server

As well as using the optional management network, the Traffic Manager can restrict access to the Admin Server using three techniques:

•By client IP address (xx.xx.xx.xx)

•By client IP and netmask (xx.xx.xx.xx/nn or xx.xx.xx.xx/xx.xx.xx.xx)

•By client DNS name or DNS wildcard (admin.mysite.com or *.mysite.com)

For example, you could specify 10.1.1.1, 10.0.0.0/24 or *.mysite.com.

The Traffic Manager must perform DNS lookups if you use DNS rules. You must ensure that the necessary DNS settings have been made to allow these lookups to take place.

After you have clicked Update, the Traffic Manager checks all connections to the Admin Server before allowing access to the Admin UI login page.

ATTENTION
In order for these restrictions to be effective, external firewalls and services must be trusted. IP addresses can be spoofed, and if your DNS service is subverted or hacked then relying on DNS tests may be ineffective.

Changing Admin Server Ports

Each Traffic Manager runs it’s own Admin Server on the default port 9090. During initial configuration, if the Traffic Manager determines that the default port is unavailable, the port number is incremented by 1 until the Traffic Manager detects a free port. Thus, in this scenario you might find that your Admin Server port is set to 9091, 9092, or higher.

To change this port manually, update the adminport setting in “Management IP Address and Admin Server Port”. Changes take place immediately when you click Update. If you change this port, the Traffic Manager redirects you automatically to the new URL.

Changing the Admin Server port affects any applications that use the Control API, and the connections made by the CLI.

The REST API uses an alternative port (typically 9070), configurable from the “REST API” section.

For more information on the Traffic Manager’s network port requirements, see Default Ports Used by the Traffic Manager.

You can specify a dedicated management port (network interface) at installation time. This value cannot be changed from the Admin UI. To change this value, or to disable the management port entirely, re-run the initial configuration procedure used at installation time. For more details, see the Pulse Secure Virtual Traffic Manager: Installation and Getting Started Guide applicable to your product variant.

Traffic Manager SSH Server Security

This section is not applicable to Traffic Manager software variants.

Traffic Manager virtual appliances and cloud instances provides command line access through a standard SSH server. This is reserved primarily for log retrieval and certain system maintenance operations and is not necessary for normal administrative functions.

To modify the Traffic Manager SSH server security settings, use the “SSH Server” section.

Restricting SSH access might form part of an organizational security policy. In this case, enable or disable SSH access for all users by setting appliance!ssh!enabled to “Yes” or “No” accordingly. Where access is enabled, set the preferred port (usually 22) in appliance!ssh!port. You can also restrict SSH access to use key-based authentication by setting appliance!ssh!passwordallowed to “No”, and installing authorized keys in /root/.ssh.

Traffic Manager virtual appliances and cloud instances include an SSH Intrusion Prevention tool to help prevent brute-force SSH attacks. This blocks remote hosts that have made multiple failed connection attempts within a set time period. Use the following settings to configure the behavior of the SSH Intrusion Prevention tool:

Setting	Description
Enabled	Whether SSH Intrusion Prevention is enabled or disabled.
Whitelist hosts	A space-separated list of hosts that the SSH Intrusion Prevention tool does not ban (unless the host also appears in the blacklist). Use IP addresses, DNS hostnames, or IP address ranges described by a subnet mask.
Time	The length of time, in seconds, a host is banned for.
Retry limit	The number of failed connection attempts a host can make to the Traffic Manager before being banned. Connection attempts made while a host is banned do not count toward the next ban, unless the time hosts are banned for ("Time") is less than the monitored time span ("Time span"). If this is the case, when the host is unbanned it might still have failed attempts recorded from before the ban started that are within the current monitoring window. Attempted connections while banned are immediately dropped, without an authentication challenge.
Time span	The time window, in seconds, the SSH Intrusion Prevention tool monitors for failed connection attempts.
Blacklist hosts	A space-separated list of IP addresses or DNS hostnames that the SSH Intrusion Prevention tool must never permit access to this Traffic Manager through SSH. Ivanti recommends you ensure that IP addresses and hostnames in the whitelist do not also appear in the blacklist (although the blacklist takes priority). Unlike the whitelist, you cannot blacklist an IP range described by a subnet mask.

The Traffic Manager displays currently banned hosts, including blacklisted hosts, under "Banned Hosts".

To download log files containing records of the IP addresses banned and unbanned, the times the SSH Intrusion Prevention tool is started or stopped, and any configuration changes, click Download Log.

Cluster Communication

Communication between cluster members is handled through secure communications designed to withstand man-in-the-middle and other types of attacks or interventions. The Traffic Manager provides secure public/private key cryptography using SSL to ensure that your cluster members, regardless of their location in the world, remain able to communicate securely and authentically.

The “Cluster Communication” section allows you to place restrictions on the inter-cluster communications in order to provide the precise level of security for your network setup.

The host IP addresses that can contact the internal administration port on each Traffic Manager can be specified by the setting controlallow. Specify a list containing IP addresses, CIDR IP subnets, and “localhost”, or set to “all” to allow any host to connect.

In the case of clusters that span beyond a single trusted network, it is not always possible to know if a cluster member outside this trusted network has been compromised. In order to prevent other Traffic Managers from becoming compromised, a system administrator can mark certain cluster members as being less secure than others. In other words, if a cluster member is exposed to a higher risk of compromise, you can mark it as “untrusted”. An untrusted Traffic Manager can still receive configuration updates, and still broadcasts state and statistical data, but effectively becomes unable to replicate configuration updates out to the other cluster members.

To enable this functionality, each Traffic Manager in the cluster has a control!canupdate flag. This can either be enabled for trusted Traffic Managers, or disabled for untrusted Traffic Managers. You must have more than one Traffic Manager in your cluster to use this setting.

The Admin UI and Control API on untrusted Traffic Managers is disabled for security purposes. If you need to modify machine-specific settings (for example, Networking, Time/Date, or SNMP settings) first enable control!canupdate. Depending on your network security requirements, it might also be necessary to temporarily remove that Traffic Manager from the cluster in order to make the change.

A default setting control!canupdate!default is provided for new Traffic Managers to inherit when they join the cluster. You might want to modify this to “No” prior to joining a new Traffic Manager from a less trusted location (such as in cloud environments).

ATTENTION
As the Admin UI is disabled on untrusted Traffic Managers, you cannot log on to or make changes to those cluster members. Should you run into a situation where your trusted cluster members become uncontactable for some reason, there exists the risk that you may not be able to administer your entire cluster. In addition, you will be unable to join new Traffic Managers in order to regain control of the cluster. In order to circumvent this risk, it is strongly advised that you maintain at least one redundant trusted Traffic Manager in your cluster at all times. Contact your support provider if you require further assistance.

SSL Settings for Admin Server and Internal Connections

These settings control advanced SSL options for connections to and from the Admin Server, and for secure connections internal to the Traffic Manager. The default settings offer a broad level of security and compatibility suitable for most installations.

Consult your system administrator or support provider should you need to enable compatibility with a specific protocol or connection setting. Ivanti recommends taking care when switching between SSL or TLS versions (or cipher suites) due to the potential effect on intra-cluster communication. For example, to switch from TLS 1.1 to TLS 1.2, enable admin!support_tls1_2 and allow your modified configuration to replicate across the entire cluster before disabling admin!support_tls1_1. During this transition, observe the Traffic Manager event log for any persistent warnings or errors that might indicate an incompatibility or communication failure.

For changes to take effect, you must restart the Admin Server. This happens automatically for changes made through the Admin Server itself, but not for changes made through other interfaces such as the REST or SOAP APIs. In these cases, restart the Admin Server manually through the System > Traffic Managers page.

If you are using the Traffic Manager REST API and you modify the setting admin!support_tls1_2, you must disable and then reenable the REST API before you can continue to use it with your changed configuration. For information on restarting the REST API, see Access to the REST API.

HTTP Strict Transport Security (HSTS) Settings for the Admin Server

These settings control the HSTS headers added to the Admin Server HTTP pages. HSTS is a web security policy mechanism (defined in RFC 6797) that helps to protect the Admin Server against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking. When enabled, HSTS headers declare that web browsers (or other user agents) should only interact with the Admin Server using HTTPS connections. In other words, using SSL or TLS.

HSTS protection applies only after a user has visited the site at least once, and works by ensuring that a user entering or selecting a URL to the site that specifies HTTP automatically upgrades to HTTPS, without making an HTTP request. This prevents the HTTP man-in-the-middle attack from occurring.

The HSTS policy is communicated by the Admin Server to the user agent through an HTTPS response header field named "Strict-Transport-Security". The Admin Server also configures a "max-age" key to specify how long the user-agent should continue to automatically upgrade to HTTPS.

The Traffic Manager includes the following settings, used to control HSTS policy behavior, from System > Security > HTTP Strict Transport Security (HSTS) Settings for Admin Server.

•admin!hsts_enable: Whether or not HSTS support is enabled for the Admin Server (Default: "No").

•admin!hsts_max_age: The maximum age, in seconds, for which the HSTS header applies (Default: "31536000", in other words 365 days)

For these settings to take effect, the Admin Server must be restarted. A restart is triggered automatically when a change is made from the Admin Server itself, but a restart must be activated manually for changes made through other interfaces, for example REST or SOAP.

When using HSTS, consider the following points:

1.HSTS can be enabled only when a non-self-signed SSL certificate has been configured for use by the Admin Server.

2.HSTS settings are not replicated around the cluster and must be enabled on each cluster member after installing a non-self-signed Admin Server SSL certificate.

Managing Administration Certificate Authorities

The Traffic Manager authenticates any SSL-enabled LDAP server that it connects to while performing user authentication through configured Certificate Authorities. Make sure you configure the Traffic Manager with the public certificates from the Certificate Authority (CA) that has issued the LDAP server’s certificate.

To manage your CA certificates, click Catalogs > SSL > Administration Certificate Authorities and Certificate Revocation Lists Catalog.

To import a new CA file into the Traffic Manager, click Import certificate or CRL, and use one of the following methods:

•Click Choose File to upload a certificate file from your local workstation to the Traffic Manager.

•Type an HTTP URL or an HTTPS URL into the File URL box for the Traffic Manager to download directly.

•Type or copy the contents of a file into the File Contents box (PEM-encoded).

Click Import File to complete the process. The Traffic Manager imports the CA file and propagates the new information to all Traffic Managers in the cluster.

Access to the REST API

The “REST API” section contains a number of settings applicable to the Traffic Manager REST API service. The service is enabled by default.

To disable the REST API service, set rest!enabled to "No". To enable the REST API service, set rest!enabled to "Yes".

To set the TCP port that the service listens on, use rest!port. The default is 9070, although any unreserved port can be used provided it does not conflict with other services already running on the Traffic Manager system.

Click Update to save any changes.

For information on the remainder of the settings on this page, see the Pulse Secure Virtual Traffic Manager: REST API Guide, available from the Ivanti Web site (www.ivanti.com). For more information on the Traffic Manager’s network port requirements, see Default Ports Used by the Traffic Manager.