DoS & DDoS protection with NetScaler Access Control Lists (ACLs)
NetScaler provides many capabilities to protect against both DoS and DDoS attacks. These capabilities include Access Control Lists (ACLs), layer 3 and 4 protection mechanisms, HTTP protocol validation, IP reputation protection to identify likely bad actors, automated bot detection, rate-limiting, a full web application firewall with TCP signature scanning and L7 rules, and a cloud-based DDoS protection service.
What is a Denial of Service (DoS) and Distributed Denial of Service attack?
A Denial of Service (DoS) attack is an action intended to make a service or platform unavailable, generally by consuming one or more constrained resources by flooding the service with a large number of requests or by sending requests known to trigger a crash.
A Distributed Denial of Service or DDoS attack is an attack that originates from multiple sources, perhaps each sending a small number of requests which when added together overwhelm the platform. DDoS attacks are more difficult to protect against as it can be challenging to identify and separate the illegitimate traffic from perfectly valid requests.
You can learn more about DDoS attacks and their motivations in Pankaj Gupta's excellent blog in "Info Security" magazine.
How can NetScaler help you?
Because DDoS attacks happen at all layers, we need a mitigation strategy for each. Alone, each strategy would have weaknesses, and it is only by bringing protection capabilities together that we reap the full benefits. Attacks can have different vectors. The most common are:
- Volumetric, simply filling the network by sending too much traffic.
- Protocol, creating excessive sessions to exhaust the resources on networking devices.
- Application, abusing an application's capabilities to bring it down.
Increasingly, attackers are using multi-vector attacks to defeat individual mitigations and to divert attention away from their real target.
The most common attacks happen at the Network (layer 3), Transport (layer 4), Presentation (layer 6) and Application (layer 7).
Open Systems Interconnection (OSI) Model
# | Layer | Application | Description | Attack Example |
---|---|---|---|---|
7 | Application | Data | Network process to applications | HTTP flood, SQL Injection, Buffer overflow |
6 | Presentation | Data | Data representation and encryption | SSL and TLS (BEAST, POODLE. Heartbleed) |
5 | Session | Data | Interhost communication | Session hi-jacking |
4 | Transport | Segments | End-to-end connections and reliability | SYN flood, UDP flood, TCP session hi-jacking |
3 | Network | Packets | Path determination and logical addressing | ICMP flood, MITM |
2 | Datalink | Frames | Physical addressing | ARP Spoofing |
1 | Physical | Bits | Media, signal, and binary transmission | Wire cutters |
While the OSI model is useful way to think about attacks, it's common for modern applications to have functions that encompass layers 5-7 which makes it tricky to categorize an application into a single layer. In practice, layers 5-7 are generally thought of as "the upper layers", layers 2-3 as the "infrastructure layer", and layer 1 as "the physical connection". With this in mind, NetScaler can offer the following protection capabilities:
Can Citrix offer any further help?
Beyond the capabilities of individual NetScaler, Citrix Web App and API Protection (CWAAP) service provides a ready to go DDoS mitigation offering with one of the world's largest DDoS scrubbing capacities. Its scrubbing service cleans incoming requests of superfluous DDoS traffic before it reaches your platforms. CWAAP has a scrubbing capacity of 12 Tbps and can protect against the very largest volumetric DDoS attack.
You can find out more about Citrix's cloud-based protection service here.
Access Control Lists
The first protection capability that I'm going to talk about, and the focus of this article, is Access Control Lists (ACLs). ACLs are a good way to prevent unwanted requests tying up processing capacity at higher layers. They won't prevent a volumetric attack but, they are helpful when combined with other techniques as part of a broader program of holistic protection. ACLs provide an extremely basic mechanism of blocking traffic as it arrives at your NetScaler and preventing further processing. ACLs are network filters that control incoming and outgoing traffic. ACLs are used to improve security by restricting or allowing communication from specified hosts. They can be extremely helpful when you need to block illegitimate request from known sources that are tying up processing capacity at the higher layers of the computing stack.
ACL Security Models
ACLs are used in either a default allow or deny security model. In a default allow (block list) model, all hosts except those specified will be able to communicate with the NetScaler. This default allow model is well suited to a public website where you wish to provide services to the whole Internet except for a few bad actors. In a default deny (allow list) model, all hosts are restricted and only able to connect if your ACLs allow it. This is a good model for situations where you want to limit management traffic to a small number of hosts or a few partners need access to a website.
The default deny security model is generally considered to be more secure by virtue of its restrictive nature but, it will take more work to maintain. NetScaler supports Access Control Lists (ACLs), defaults to an allow/blocklist model, but can be configured to use either model. I have provided some examples of each in the sections that follow.
Datasets
NetScaler's ACLs support both explicit values, like a range of IP addresses or ports, and datasets which reference a collection of values. Datasets enable you to create and manage a small number of ACLs that reference a collection of values such as "management IP addresses", "management ports", or "legitimate clients". Here, we will create a small number of datasets to use in the default allow and deny configuration examples that follow. Here's an example of how to create a dataset.
Creation of a dataset
add policy dataset RestrictedClients IPV4bind dataset RestrictedClients 10.0.1.0 -endrange 10.0.1.255add policy dataset RestrictedPorts NUMbind dataset RestrictedPorts 22bind dataset RestrictedPorts 110bind dataset RestrictedPorts 143add policy dataset ADC_Management_IPs IPV4bind dataset ADC_Management_IPs 192.168.11.1 -endrange 192.168.11.10add policy dataset ADC_Management_Clients IPV4bind dataset ADC_Management_IPs 10.0.5.1 -endrange 10.0.5.21add policy dataset ADC_Management_Ports NUMbind dataset ADC_Management_Ports 22bind dataset ADC_Management_Ports 443
Configuring ACLs in a default allow (block list) model
You can configure ACLs within the NetScaler's GUI by selecting System, Network, ACLs, Extended ACLs and clicking the Add button. You can also configure ACLs using the CLI. Here are two examples in which client IP addresses are blocked using explicit and dataset based ACL rules:
Creation of two deny ACLs using datasets
add ns acl Example1 DENY -protocol TCP -srcIP 10.0.0.0-10.0.0.255 -srcPort 1024-65535 -destIP = 192.168.10.0-192.168.10.255 -destPort 443 -priority 10add ns acl Example2 DENY -protocol TCP -srcIP RestrictedClients -destPort RestrictedPorts -priority 11apply ACLs
Here, we are explicitly telling the NetScaler to deny communication between the listed source and destination addresses. Addresses that are not specified within the ACL will be allowed access.
Note the order of ACL evaluation begins with the lowest priority number and finishes with the highest. The "protocol", "srcIP", "srcPort", "destIP", "destPort", and "priority" parameters are optional and serve to further restrict the ACL rule.
Configuring ACLs in default deny (allow list) model
To implement a default deny ACL list, we start by explicitly allowing communication from our management range at the lowest priority and then denying all other traffic at the highest possible priority number (remembering that ACLs with a lower priority number are evaluated first).
Creation of an allow ACL using datasets
add ns acl Allow_Management_Range ALLOW -protocol TCP -srcIP ADC_Management_Clients -destIP = ADC_Management_IPs -destPort ADC_Management_Ports -priority 1add ns ACL Deny_All DENY -priority 100000apply ACLs
Now, having restricted all access to the NetScaler beyond that of our management range, we can create additional ACLs allowing communication to and from legitimate hosts.
add ns acl Example1 ALLOW -protocol TCP -srcIP 10.0.0.0-10.0.0.255 -destIP 192.168.10.5 -destPort 443 -priority 10add ns acl Example2 ALLOW -protocol TCP -srcIP Good_Clients_Dataset_Name -destIP Business_Service1_IPs_Dataset_Name -destPort Business_Service1_Ports_Dataset_Name -priority 11apply ACLS
ACL Logging with log rate limiting
NetScaler does not log ACL violations to Syslog by default. To change this behavior, you need to modify the global syslog parameters to activate ACL logging and then enable logging on each ACL for which you desire a log entry. The following command will modify the global syslog parameters to record ACL logs:
set audit syslogParams -acl ENABLED
To enable logging on an ACL, we need only include the -logstate ENABLED
parameter. However, to ensure that we don't overwhelm the Syslog server, it is usually wise to also include the optional -ratelimit
parameter to specify a maximum number of log entries that should be created each second. The following command will create an ACL with logging enabled and a rate limit of 200 log entries per second.
add ns acl Example1 ALLOW -protocol TCP -srcIP 10.0.0.0-10.0.0.255 -destIP 192.168.10.5 -destPort 443 -priority 10 -logstate ENABLED -ratelimit 200
Implicit ACLs
By default, a NetScaler has a small number of implicit ALLOW ACLs and will not block some types of important HA and clustering traffic even when a deny ACL is configured.
These implicit ACLS are:
Mode | Source | Destination | Destination Port | Protocol | Purpose |
All | All | NSIP & SNIPs | 3008-3011 | TCP | Metric Exchange and synchronization |
All | All | NSIP & SNIPs | 179 | TCP | BGP |
All | All | NSIP & SNIPs | 520 | UDP | RIP |
HA | HA Partner | NSIP | 3003 | TCP | HA Heartbeat |
HA | HA Partner | NSIP | 4001 | TCP | Zebra routing configuration sync |
HA | HA Partner | NSIP | 22 | TCP | SSH/SCP |
Cluster | Cluster nodes | NSIP | 7000 | UDP | Cluster heartbeat |
If you wish to disable the implicit ACLs, perhaps to replace them with more restrictive rules, you can do so using the following command:
set l3param -implicitACLallow DISABLED
Next steps
You can see the power of ACLs in blocking unwanted traffic. This can be extremely useful on your network, especially if you want to prevent certain users from accessing sites or servers. Remember, though, that ACLs should only be used as a supplement to other security measures. They should not be relied on as the only security measure on your network.
Recommended Comments
There are no comments to display.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now