Securing the LoadMaster Access
Configuring Administrative Access
Locking down administrative access to your LoadMaster is important for several reasons; ranging from protecting your SSL certificate and private key, to ensuring the continuation of uninterrupted Virtual Service traffic. There are several simple steps that you can do to secure your LoadMaster, many of which are discussed below.
Web User Interface (WUI) Access – By default, the LoadMaster will use the IP address(es) associated with eth0 for WUI connectivity. Commonly, customers will also configure their Virtual Services on the same subnet on this very same interface. This often means that clients that are able to request a Virtual Service address can just as easily request the administrative WUI address.
It is best practice to isolate administrative access to its own separate interface, generally within its own private subnet or VLAN. This can be set in the Allow Web Administrative Access drop-down list in Certificates & Security > Remote Access.
SSH Access – Another default setting of the LoadMaster allows SSH requests on any interface address. Once accessed, clients will have the ability to change the LoadMaster configuration, and (if talented enough) gain root access.
Restricting SSH access will help further secure your LoadMaster from intruders. This can be set using the Allow Remote SSH Access drop-down list.
Packet Filtering – Often network users and servers use the LoadMaster for routing outside of their network. This means that the LoadMaster can potentially be used as a gateway between two subnets.
To avoid any routed traffic from traversing the LoadMaster, KEMP recommends enabling the Packet Routing Filter option within System Configuration > Network Setup > Packet Routing Filter in the main menu of the WUI. This will help ensure that DMZ-related traffic stays separate from the LAN segment.
High Availability (HA) Issues
Utilizing a HA pair can bring its own security concerns. Primarily, this is due to the fact an HA LoadMaster must be in constant communication with its partner; syncing the running configuration, updating persistence tables and sharing valuable information.
HA Update Interface – This is the interface used to send HA to HA updates. By default this is set to eth0. The data is shared via a TCP-based connection over port 6973.
To ensure the safe transmission of these packets, KEMP recommends changing the HA Update Interface used to a separate, administrative interface. Traffic passed over the administrative interface will be on a different network than traditional Virtual Service traffic and will provide one more layer of obscurity to anyone attempting to obtain this information. The interface can be specified by setting the HA Update Interface field value.
Inter HA L4 TCP Connection Updates/Inter HA L7 TCP Persistency Updates – If you have either of these features enabled (within System Configuration > Miscellaneous Options > HA Parameters) - the persistence tables are updated by default, being transferred over eth0. By specifying your administrative interface, you will move this traffic away from prying eyes and into a more secure subnet.