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.

The first option, SSL Certificate, allows you to change the SSL certificate used for the Virtual 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.

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

Ivanti recommends making a note of the fingerprint upon setting up a new Virtual 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:

Now admin server SSL certificate is secured via zcli. Prior to this enhancement, admin could manage this certificate only through the UI at System > Security > SSL Certificate.

This feature exposes the same certificate management capabilities through zcli enabling administrators to:

CLI Example:

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

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

The Virtual 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 Virtual 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.

Each Virtual Traffic Manager runs it’s own Admin Server on the default port 9090. During initial configuration, if the Virtual Traffic Manager determines that the default port is unavailable, the port number is incremented by 1 until the Virtual 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 Virtual 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 Virtual Traffic Manager’s network port requirements, see Default Ports Used by the Virtual 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 Virtual Traffic Manager: Installation and Getting Started Guide applicable to your product variant.

Virtual 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 Virtual 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.

Virtual 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:

The Virtual 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.

Communication between cluster members is handled through secure communications designed to withstand man-in-the-middle and other types of attacks or interventions. The Virtual 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 Virtual 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 Virtual 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 Virtual 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 Virtual Traffic Manager in the cluster has a control!canupdate flag. This can either be enabled for trusted Virtual Traffic Managers, or disabled for untrusted Virtual Traffic Managers. You must have more than one Virtual Traffic Manager in your cluster to use this setting.

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

ATTENTION As the Admin UI is disabled on untrusted Virtual 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 Virtual 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 Virtual Traffic Manager in your cluster at all times. Contact your support provider if you require further assistance.

These settings control advanced SSL options for connections to and from the Admin Server, and for secure connections internal to the Virtual 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 Virtual 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.

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 Virtual Traffic Manager includes the following settings, used to control HSTS policy behavior, from System > Security > HTTP Strict Transport Security (HSTS) Settings for Admin Server.

When using HSTS, consider the following points:

The Virtual 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 Virtual 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 Virtual Traffic Manager, click Import certificate or CRL, and use one of the following methods:

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

The “REST API” section contains a number of settings applicable to the Virtual 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 Virtual Traffic Manager system.

Click Update to save any changes.

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