This article describes how to lock down the NetScaler management interfaces with ACLs.

Background

Customers wanting to run a secure environment should limit access to the NetScaler management interface as a best practice. Ideally, the management interfaces should be on isolated networks (physical or VLAN) where only network administrators are allowed on the network itself. In this ideal configuration, everyone who can send packets to the management interface are trusted/known individuals who already have privileged access. Jump hosts or authenticating firewalls can be used to limit access.

Lacking a private management network, the NetScaler management interfaces should be on internal networks only (not Internet-facing) with Access Control Lists (ACLs) limiting access to select networks and hosts that are needed for daily administration, monitoring, and automation.

What Makes an Interface a “Management Interface”?

1. The NetScaler Management IP (NSIP) is the default management interface from which the management stack operates.
2. The Subnet IP (SNIP) primarily serves as the internal IP address from which proxied traffic is sent. Each SNIP has the option of having management capabilities enabled.
3. Special ports on the GSLB IP for site-to-site management coordination.

Caution! The SNIP and GSLB IP addresses also carry traffic. When applying ACLs, make sure you do not inadvertently block traffic as well. This can be done by limiting ACLs to specific management functions such as SSH, Web UI, NITRO API, and SNMP.

Instructions

ACL Strategies

The Jump Host Strategy

Jump Hosts (sometimes called bastion hosts) are designated servers that only serve to allow a user to log in 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.



Some considerations:

1. Traffic to authentication servers (e.g., Active Directory) is forwarded 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 data center 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 an 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

• NetScaler 13.0: https://docs.netscaler.com/en-us/citrix-adc/13/networking/access-control-lists-acls.html
• Netscaler 13.1: https://docs.netscaler.com/en-us/citrix-adc/13-1/networking/access-control-lists-acls.html
• NetScaler 14.1: https://docs.netscaler.com/en-us/citrix-adc/current-release/networking/access-control-lists-acls.html

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, you would need Console access to revert back the changes. 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 set up 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.

Special Thanks!

Thanks to our Citrix CTP Carl Stalhood’s excellent post, NetScaler Firewall Rules for numerous suggestions captured in this article.