How to Lock Down the NetScaler Management Interfaces with ACLs

ACL Strategies

There are two key strategies that are used with ACLs: locking down access to jump hosts and limiting access to management subnets.

Jump Host and Subnet Strategy

User-added image

The Jump Host Strategy

Jump Hosts (sometimes called bastion hosts) are designated servers that only serve to allow a user to login and then connect to an allowed set of servers on a protected network. These hosts are typically kept to minimal installations with significant focus put on locking down functionality. Administrator access to these machines is limited.

The Subnet Strategy

In the subnet strategy, selecting a narrow range of IPs that represent the network from which other management infrastructure / administrators will mitigate risk significantly. Like the jump host strategy, this approach significantly reduces the number of people / machines down to those that have some kind of privileged access.

Considerations for your Strategy

The health monitoring and authentication capabilities of the NetScaler can affect the types of traffic that must be allowed to the management interfaces on the NetScaler.

User-added image

Some considerations:

  1. Traffic to authentication servers (e.g., Active Directory) are done from the NSIP by default. To separate out this traffic, create an internal load balancing virtual server (“vserver”) with a service pointing to the actual server. This will make authentication traffic appear as regular datacenter traffic and narrow the use of the NSIP to administrator functions only.
  2. Custom health monitors must use the NSIP as they are not part of NetScaler’s data plane. If you have such monitors, be sure that your ACLs allow traffic to the needed servers. Note that application traffic never goes through the NSIP.
  3. The NetScaler management console needs access to DNS and uses a ping to verify the presence of the server. Be sure your ACLs allow this.
  4. By default, the NetScaler will use a SNIP to source management traffic if it cannot find a route via the NSIP. If there is an upstream router that can help the NSIP, be sure to configure a static route for each network that you want accessed from the NSIP.
  5. For additional ports to be mindful of, see CTX101810, Communication Ports Used by Citrix.

Configuring ACLs on NetScaler

Official documentation for configuring ACLs on NetScaler can be found on https://docs.citrix.com.

Note: The following instructions are based on 11.1, however, they should work on NetScaler 10.1+. You are advised to confirm any configuration changes against the documentation for the version of NetScaler you are using.

ACLs provide packet filtering capabilities on the NetScaler. They are one of the first checks done to a packet upon receipt. Because of how early this check is done in packet processing, it is a very effective means of blocking traffic. NetScaler ACLs have been a part of the product for many years and are a well-tested, proven capability.

This article assumes you have an IPv4 network and will use extended ACLs via CLI. For other ACL capabilities, see the official documentation.

Caution! NetScaler communicates with its high-availability peer as well as other NetScalers in the same GSLB group. Whatever policy you set must include an explicit allow for these other NetScalers or the product will not function correctly.

Caution! Setting strict ACLs with a default deny can lock you out of your NetScaler if done incorrectly. Make sure you have a way of clearing the ACLs in case something goes wrong. When in doubt, use a test system first.

Start by making sure that internal traffic to the NetScaler is not accidentally blocked.

> set l3param -implicitACLAllow ENABLED

For this example, we are going to allow two jump hosts: 10.1.1.1 and 10.1.1.2. The NSIP is for the primary is 10.1.1.42 and the secondary is 10.1.1.43.

> add ns acl jumpHost1 ALLOW -srcIP 10.1.1.1 -destIP 10.1.1.42 -priority 1 -logstate ENABLED -ratelimit 120> add ns acl jumpHost2 ALLOW -srcIP 10.1.1.2 -destIP 10.1.1.42 -priority 2 -logstate ENABLED -ratelimit 120> add ns acl peerNS ALLOW -srcIP 10.1.1.43 -destIP 10.1.1.42 -priority 3 -logstate ENABLED -ratelimit 120> add ns acl defaultDeny DENY -priority 100> apply ns acls 

Locking down SNIPs by comparison requires more care as they will also handle application traffic. Here, we assume that the servers the NetScaler communicates with are on subnet 10.1.2.0/24 and the SNIP itself is 10.1.1.44. The above policies are the same, but we also need to insert a policy to allow traffic to/from the servers. Because traffic to/from the servers are a constant occurrence, we do not want to log each packet.

> add ns acl toOK ALLOW -srcIP 10.1.1.44 -destIP 10.1.2.1-10.1.2.254 -priority 5 -logstate DISABLED> add ns acl serversOKfrom ALLOW -srcIP 10.1.2.1-10.1.2.254 -destIP 10.1.1.44 -priority 6 -logstate DISABLED 

Finally, if you have any GSLB sites, ports 3008-3010 are part of the management subsystem. In an ideal world, these are not exposed to the Internet and are using a private network for site-to-site communication. However, if you need to use the Internet, explicitly calling out your peer sites is important. Assume that your GSLB IP is 1.2.3.4 and your peer site is 4.3.2.1. In this case however, you cannot use a default deny since you need to otherwise let traffic to your GSLB site. Thus, we explicitly allow the peer traffic by port, block all other traffic destined to the port, and otherwise allow traffic to the IP.

> add ns acl peerOK ALLOW -srcIP 1.2.3.4 -destIP 4.3.2.1 -destPort 3008-3010 -priority 10 -logstate DISABLED> add ns acl peerOK2 ALLOW -srcIP 4.3.2.1 -destIP 1.2.3.4 -destport 3008-3010 -priority 11 -logstate DISABLED> add ns acl no3008 DENY -destIP 1.2.3.4 -destPort 3008-3010 -priority 12 -logstate ENABLED -ratelimit 120> add ns acl gslbOK ALLOW -destIP 1.2.3.4 -priority 13 -logstate DISABLED 

Don’t forget to setup your peer site. There, you will need the no3008 rule to reflect the destIP of 4.3.2.1.

Conclusion

The changes described above are an example of how to lock down your management interface to the minimum number of hosts that need access. The narrower you can make your access list, the more secure you are. As mentioned at the start of this document, having a network that has strict access rules is the best case but that is not always possible. Using ACLs are the next best solution.

If you have questions about ACLs, be sure to check the official documentation first. You can also contact Citrix Support for help. Information on opening a support case can be found here: https://www.citrix.com/support/open-a-support-case/

Related:

  • No Related Posts

The LM386 server cannot be started because CACHE.EXE is not running.

Details
Product: Windows Operating System
Event ID: 3091
Source: System
Version: 5.0
Symbolic Name: SERVICE_UIC_M_LAZY
Message: The LM386 server cannot be started because CACHE.EXE is not running.
   
Explanation

This message should occur only on a workstation. Any action to correct the problem should be performed on that computer. The CACHE.EXE program must be running before the LAN Manager 386 server can be started.

   
User Action

Run CACHE.EXE by typing CACHE. You can also add a RUN line to the configuration file to have CACHE.EXE start automatically whenever the computer starts.

Related: