How to Lock Down Citrix ADC 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

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 Citrix ADC can affect the types of traffic that must be allowed to the management interfaces on the Citrix ADC appliance.

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 Citrix ADC appliance’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 Citrix ADC appliance 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 Citrix ADC appliance 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 Citrix ADC

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

• Citrix ADC 13.0: https://docs.citrix.com/en-us/citrix-adc/13/networking/access-control-lists-acls.html
• Citrix ADC 12.1: https://docs.citrix.com/en-us/citrix-adc/12-1/networking/access-control-lists-acls.html
• NetScaler 12.0: https://docs.citrix.com/en-us/netscaler/12/networking/access-control-lists-acls.html
• NetScaler 11.1: https://docs.citrix.com/en-us/netscaler/11-1/networking/access-control-lists-acls.html
• NetScaler 10.5: https://docs.citrix.com/en-us/netscaler/10-5.html

Note: The following instructions are based on firmware version 11.1, however, they should work on versions later than 10.1. You are advised to confirm any configuration changes against the documentation for the version of Citrix ADC you are using.

ACLs provide packet filtering capabilities on the Citrix ADC appliance. 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. ACLs have been a part of the Citrix ADC 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! A Citrix ADC appliance communicates with its high-availability peer as well as other Citrix ADC appliances in the same GSLB group. Whatever policy you set must include an explicit allow for these other appliances or the product will not function correctly.

Caution! Setting strict ACLs with a default deny can lock you out of your Citrix ADC appliance 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 Citrix ADC appliance 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 with which the Citrix ADC communicates 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/