Jump to content
Welcome to our new Citrix community!
  • DoS & DDoS protection with NetScaler: Layer 3 and 4 Protocol Attacks


    Steven Wright
    • Validation Status: Work In Progress
      Summary: In this article, we explaining why NetScaler is the ideal solution for web server-side and internet service provider-edge protection against Layer 3/4 attacks. We will also cover how NetScaler protects backend servers against these network attacks by acting as a proxy with a high-performance and standards-compliant TCP stack.
      Has Video?: No

    DoS & DDoS protection with NetScaler: Layer 3 and 4

    Protocol attacks

     

    Welcome to the second in my Denial of Service (DoS) and Distributed Denial of Service (DDoS) attack protection articles .

     

    In this article, we explain why NetScaler is the ideal solution for web server-side and internet service provider-edge protection against Layer 3/4 attacks. We will also cover how NetScaler protects backend servers against these network attacks by acting as a proxy with a high-performance and standards-compliant TCP stack.

     

    What we won't cover here, but will return to in a future article, is Citrix's cloud-based DDoS protection service. If you're looking for a managed solution that "just works” and can act on traffic before it arrives at your datacentres, you should investigate our Cloud DDoS protection service  

     

     

    How can NetScaler help you?

    You will remember from our first article that DoS attacks happen at all layers, and we need a mitigation strategy for each.

     

    Layer 3 and 4 attacks broadly fall into two categories: Volumetric and Protocol. Some attacks fall into both categories. However, in simple terms, a protocol attacks aim to exhaust server resources, whereas a volumetric attack seeks to overwhelm the network by flooding it with traffic.

     

    NetScaler provides layer 3/4 protection for your datacentre resources, can help you mitigate volumetric attacks and protect you against protocol attacks.

     

     

    How can NetScaler help mitigate common L3/L4 attacks? In many cases, NetScaler can protect you from protocol attacks simply by processing incoming traffic with its high-performance and standards-compliant TCP stack and acting as a proxy rather than allowing potentially vulnerable servers to receive and interpret raw traffic directly.

     

    Here, we will cover attacks frequently mentioned in vendor DoS and DDoS documentation. Many of these attacks have been around for a long time, and they are mentioned regularly without explanation of how they work or how protection is provided.

     

    We’ll cover SYN floods, teardrop, ping of death, LAND, forged TCP resets, Smurf and Fraggle attacks. Although many of these attacks are old, understanding them continues to have value as there is a relationship to the attacks we see today. They also illustrate well how NetScaler can provide protection.

     

    In addition to blocking well-known attacks, it would be remiss not to mention that NetScaler also includes a dynamically updated signature database that it uses to detect and block threats. Simliarly, it hosts a dynamically updated database of IP address reputation data to block IP addresses known to be compromised. We will cover these in a future article.

     

     

    Protocol attacks

    A protocol attack makes resources unavailable by subverting network protocol features to give an unintended result. For example, generating many requests that must be processed at the network level or by manipulating requests to crash the target device’s network stack.

     

    An effective defence to such attacks is to ensure the requests are initially processed by a high-performance and standards-compliant TCP stack that doesn't suffer from the vulnerabilities being targetted, such as a NetScaler.

     

     

    SYN Flood (Half-open attack)

    One of the most well-known (and still current) protocol attacks is a "SYN Flood".

     

    A SYN flood, or half-open attack, is a type of DoS attack in which an attacker sends many initial connection requests (SYN packets) that appear to come from legitimate clients.

     

    On receipt, the target of the SYN flood allocates resources to allow each client to establish a connection. It sends the client an acknowledgement (a SYN-ACK), and awaits their reply. But, of course, there will be no reply as a legitimate client did not attempt the connection.

     

    As the server can only handle a limited number of concurrent connections, the flood of SYN packets from the attacker overwhelms the server causing it to respond slowly or not at all.

     

     

    image.png.e6ae8a20832835a3b7d104fe5ebf153f.png

     

     

    A NetScaler in front of the servers will receive and handle the SYN flood.

     

    NetScaler protects against SYN floods by default, using "SYN cookies" - a well-recognized mechanism for handling SYN flood attacks. SYN cookies are a form of connection tracking that allows the appliance to remember the state of TCP sessions that have been initiated but are not yet established and open.

     

    Citrix's SYN cookie implementation is performance optimized (to maximize throughput for negotiated connections) and security enhanced (to render forged connection techniques obsolete).

     

    In Citrix's SYN cookie implementation, the NetScaler sends a cookie to each client that requests a TCP connection, and only allocates system memory for the connection when it receives the final ACK packet. This prevents SYN attacks and allows normal TCP communications with legitimate clients to continue uninterrupted.

     

     

     

    Teardrop (IP Fragmentation attack)

    Although old, the Teardrop remains interesting because of the parallels with recent attacks in which attackers manipulate the reassembly of data to bypass Intrusion Detection (IDS) and Intrusion Prevention Systems (IPS). 

     

    Teardrop relies on IP Fragmentation. When a packet is too big to send over the network, it will be fragmented into several smaller packets, each including an offset so the original can be reconstructed without overlap. The Teardrop attack sends fragments with offsets that overlap, crashing operating systems that don’t check for this.

     

    A NetScaler in front of the server, will receive and process the malicious fragments. By default NetScaler checks the frame alignment of incoming packets and discards those with an overlapping or invalid alignment. Teardrop packets are dropped at the NetScaler hence the attack never reach internal servers.

     

     

    image.png.4ea8fc890c1a7ed0aebd873b09ee9dd6.png

     

     

     

    Ping of Death (oversized ICMP)

    "Ping of Death" is yet another older attack. caused by a failure to validate the size of data supplied by a remote endpoint and a resultant buffer overflow. While the attack is no longer relevant, the need for validation remains.

     

    The "Ping of Death" also used specially crafted packet fragments. Attackers would create fragments that, when reassembled, result in an ICMP echo request (ping) packet larger than the maximum 65,535 bytes defined in the IP specification.

     

    A vulnerable operating system reassembling the packet in memory, would write the reassembled packet into the intended memory space and the additional data into surrounding memory, crashing the platform!

    A NetScaler in front of the servers receives and processes the ICMP request without it ever reaching potentially vulnerable servers.

     

     

     

    LAND attack (spoofed packet from the target)

    A LAND attack used specially crafted packets that appeared to originate from the target’s own IP address. When this malicious packet was received, the target tried to connect to itself, potentially causing it to lock up and freeze.

     

    The original LAND attack was against Windows 95 and NT; however, other old operating systems were also vulnerable. As before, moving vulnerable servers behind a NetScaler allows the NetScaler to validate the supplied data (in this case, the source IP) and prevent the attack.

     

     

     

    Forged TCP Resets (RST Window Attenuate)

    Forged TCP resets are a more recent attack in which an attacker crafts reset packets to disrupt a connection. The BGP routing protocol is especially vulnerable to such attacks, as are web servers with well-known large-scale caches.

     

    Here, an attacker would send one system a reset packet that appeared to come from its peer, closing the connection. In the case of BGP, a connection loss to a peer is likely to result in the flushing of routes to that peer and has the potential to cause network instability or poor performance.

     

     

    image.png.6b8be2492100d06d9ab070fe34b98d5f.png

     

    Like all other TCP packets, TCP resets contain sequence numbers that should protect against such an attack. However, as RFC 4953 details, spoofing the required sequence number and bypassing that check is likely to take around 10 milliseconds on a 100mbps network.

     

    In this case, the appropriateness of the checks on the RST packet have changed and newer validations are required.  NetScaler includes RFC-compliant protection against forged TCP resets, which reply to a reset (RST) packet with a corrective acknowledgement (ACK) for an invalid sequence number and expects the client to resend the RST if it was legitimate.

     

    In this case, protection against forged RST packets can be achieved by positioning nodes behind a NetScaler and by creating a custom TCP profile bound to a virtual server using the following commands:

     

    > set ns tcpProfile profile1 -rstWindowAttenuate ENABLED

    Done

    > set lb vserver lbvserver1 -tcpProfileName profile1

    Done

     

     

     

    Next steps

    We have seen that protocol attacks take advantage of inherent weaknesses in design and in platforms with insufficient validation controls. You will have noticed commonalities in how these attacks are performed, many of which are echoed in more recent attacks.

     

    The common thread here is most attacks can be overcome by ensuring that traffic is initially processed by an appropriately hardened platform such as NetScaler.

     

    In the next article, I will cover volumetric attacks, along with the protection that Citrix can provide.

     

    User Feedback

    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 account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

×
×
  • Create New...