System Security

This chapter covers important aspects of running your Virtual Traffic Manager software in a secure environment. The points in this chapter that consider operating system configuration apply only to the Virtual Traffic Manager software variant, and not to appliance or cloud variants.

Firewall and Operating System Settings

The Virtual Traffic Manager is not a network-level firewall and it is highly recommended that any Virtual Traffic Manager system is placed behind a firewall of your choosing. There are extra measures that can be taken to reduce potential security problems related to your choice of operating system, and UNIX security in general. These are discussed briefly below.

ATTENTION
The notes that follow are brief and deal specifically with the Virtual Traffic Manager product line. Customers are advised to take extra care over all security considerations related to Internet service providing, and to seek specialized advice if required.

Firewalling Techniques

The Virtual Traffic Manager must be able to respond to requests, and certain protocols (such as FTP) may need to open additional connections with clients. Stateful firewalls can be configured to allow outgoing connections to be established from the Virtual Traffic Manager on any port, and for subsequent responses from clients to be allowed back to the server.

The recommended firewall configuration for the Virtual Traffic Manager is therefore a stateful firewall that denies all inbound traffic by default, allowing named ports on the Virtual Traffic Manager to be contacted and any responses to the Virtual Traffic Manager to be allowed through the firewall.

Default Ports Used by the Virtual Traffic Manager

The Virtual Traffic Manager requires some ports and protocols in addition to those used by the virtual servers configured. These are:

•The Admin Server port (HTTPS): By default, this is port 9090 (TCP and UDP). Use this port, together with the host name or IP address, to browse to the Admin UI. This port must be open to any device from which you want to access the Admin UI, including all other Virtual Traffic Managers in your cluster. This port is additionally used by the Virtual Traffic Manager’s SOAP-based Control API and Command-line Interface (CLI).

For Virtual Traffic Manager appliance/virtual appliance/cloud instance variants, the current value of the Admin Server port is displayed on the console. For software variants, read the configuration file ZEUSHOME/admin/website. The absence of an entry in this file means that the Admin Server port is the default 9090.

•The control port: By default, this is TCP port 9080. The Virtual Traffic Manager uses this port for the control protocol to communicate changes in configuration data between Virtual Traffic Managers. This port does not need to be exposed outside the cluster.

To learn the current value of the control port, read the configuration file ZEUSHOME/zxtm/global.cfg. The absence of a entry in this file means that the control port is the default 9080.

•The REST API port: By default, this is TCP port 9070. The REST API is an alternative programmatic method of configuring the Virtual Traffic Manager. For more information, see the Virtual Traffic Manager: REST API Guide available from the Ivanti Web site, at www.ivanti.com.

To learn the current value of the REST API port, click System > Security > REST API in the Admin UI and observe the value set in rest!port.

During initial configuration, if the Virtual Traffic Manager determines that any of the default ports are unavailable, the affected 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. This is equivalently true for the Control port (8081 or higher) or the REST API port (9071 or higher).

ATTENTION
All references to port values shown throughout this guide and all other Virtual Traffic Manager user documentation should be read to mean the default value shown here or whatever value has been set/chosen in its place.

The Admin Server and REST API ports can be user-redefined as required on the System > Security page of the Virtual Traffic Manager Admin UI. You should then update your firewall rules accordingly.

The Virtual Traffic Manager also uses broadcasts to identify other Virtual Traffic Managers. These broadcasts are sent to the multicast address, 239.100.1.1 on port 9090 (or alternative). All Virtual Traffic Manager cluster members listen on this address. To modify the broadcast IP address and port, use the settings in System > Fault Tolerance.

If you have configured each Virtual Traffic Manager in your cluster to use a dedicated Management Network as described in Dedicated Management Network, this management traffic will be restricted to that network alone. It should not be possible to connect to any of the Virtual Traffic Manager management ports from another network. Nevertheless, you should still firewall these ports off from untrusted sources, for example, in the event that a configuration error relaxes the Virtual Traffic Manager’s management restrictions, or the management network is accidentally exposed.

Virtual Traffic Manager virtual appliances and cloud instances run a local NTP service that listens for NTP (time) requests on all interfaces (see Synchronizing Time from the Virtual Traffic Manager). The NTP services runs on port 123 (UDP and TCP). It is safe to firewall these ports off if you do not wish to use the Virtual Traffic Manager as a local time source.

ATTENTION
One of the tests the Virtual Traffic Manager uses to detect network availability is ping. The Virtual Traffic Manager may not function correctly if your firewall or local TCP/IP tunings disable or rate-limit ICMP packets to the default gateway, the back-end nodes and the other Virtual Traffic Managers in the cluster.