If a SYN Flood Attacks Your Network Tomorrow – Would Your Mitigation Be Able to Block It?

This blog was originally published by MazeBolt here.

Written by Vova Kamenker, MazeBolt.

There are various DDoS vectors that cause networks to crash, resulting in downtime for enterprises. One of these vectors, a common one, is the SYN flood. As DDoS attackers continue to change and vary their strategies and methods, it becomes important to truly understand one’s network vulnerabilities to damaging DDoS attacks. So let us start by aligning on what a SYN flood DDoS attack is.

What is a SYN Flood DDoS Attack?

A SYN (Synchronization) flood, generally caused by botnets, is a form of attack that targets server resources via the firewall or perimeter defenses. The attack is aimed at consuming connection resources on the backend servers and on stateful elements, like firewalls and load balancers by sending numerous TCP-SYN requests toward targeted services while spoofing the attack packets source IP (Internet Protocol). This leaves the TCP backlog saturated and the server and/or daemon attacked will not be able to receive any new connections. It begins with the attacker sending a message to the targeted server, that responds with a “SYN ACK” (synchronize acknowledgment) message signaling receipt and awaiting the connection to be completed by the requesting machine (the attacker). Instead, the connection remains pending until it times out, ultimately exhausting resources and causing the server to go offline. By continuously sending TCP-SYN packets towards a target, stateful defenses can go down (In some cases into a fail-open mode). This flood could also be used as a smokescreen for more advanced attacks. This is true for other out-of-state floods too.

Technical Analysis of SYN Floods

In Image 1 below, you can see the flood of SYN packets coming from a single source. Notice the rate at which the packets are sent.

“Image 1 – Example of a single SYN packet being sent to port 80”

In Image 2, you can see the victim responding with an SYN-ACK packet. The reason this SYN-ACK packet is received in response to the original SYN packet is because the victim considers this packet to be a legitimate connection request, and thus responds with a SYN-ACK in accordance with the TCP Handshake.

“Image 2 – SYN-ACK packet received”

As seen in Image 3. The capture analyzed is 14 seconds long and the average number of packets per second is at 355, with a rate of around 161Kbps. It includes the returning SYN-ACK packets as well. Attack rates could be much higher.

“Image 3 – SYN Flood stats”

A typical SYN flood running against an unsuspecting host will look similar to the above analysis. Generally, what is seen is a high rate of SYN packets and a slightly lesser rate of SYN-ACK packets coming from the targeted server.

Download PCAP file to analyze Syn Flood in Wireshark.

Here are some mechanisms and techniques used by mitigation companies to mitigate SYN Flood attacks:

SYN cookies

In this case, a cookie is created by the network server, and using codes, the server responds with a SYN-ACK response. The response will have a digit that is made up of the client IP address, port number, and so forth. On receiving a response, this is included in the acknowledgment packet. The network server can therefore identify the ACK and after that ensure network connection.

RST cookies

When the network server receives a request for connection, it firstly sends a wrong or invalid SYN-ACK. The client-server automatically responds with an RST (Reset) packet. On receiving this packet, the network server knows that the request is a real one, allows the client entry.

TCP Intercept (Transparent Proxy)

TCP intercept is a type of transparent proxy which can be used to protect a server against a SYN flood attack. It stops incoming traffic, accepts client requests, and nods in affirmation. It then connects to the server and on receiving an ACK connects the client-server to the webserver. This method is often referred to as a three-way handshake.

Did Your Mitigation Solution React to the SYN Flood and Thereby Prevent it?

• Most enterprises with mitigation solutions become aware of SYN floods only after they have happened. By then it is already too late, and disruption and downtime would follow.
• In some cases, mitigation mechanisms have set thresholds for SYN floods, but these must be configured correctly and, most likely, reconfigured again in the future following changes to the network. If that doesn’t happen, again there will be disruption.
• In other cases, the mitigation system will mitigate a portion of the attack, but this is finite and as the number of packets increases, there will be a denial of service.
• In certain other mitigation strategies, the earliest half-open connection is recycled but this may fail if the traffic volume speed increases or if the backlog is very small in size.

All these challenges associated with SYN-Floods occur because there is no insight into the mitigation configuration and there is no sure-fire way of knowing that your mitigation solution is configured to mitigate SYN floods, and it is not maintained continuously to always be up to date. To ensure detection and prevention of Syn Flood DDoS attack (and in fact all DDoS attacks), here are a few suggested processes:

1. Continuously validate and remediate your entire DDoS protection posture in peaceful times, fix known areas of weakness proactively, as you will have no time to do so once an attack starts. Any DDoS attack that is not automatically blocked when an attack starts, means downtime.
2. Break complex attacks into building blocks to ensure that you are protected against any known attack vector individually; complex attacks are essentially composed of many individual attack vectors, once you are protected against every attack building block, you will automatically block any mixed vectors attack (solve the problem by separation of variables).
3. Vulnerability Identification across the complete attack surface, automatically discovering the attack surface, running thousands of non-disruptive smart attack simulations against protections in place to identify the entire vulnerability landscape.
4. Guided remediation process and revalidation of specific network vulnerability intelligence collection throughout the process creates a prioritized remediation plan, guiding in closing vulnerabilities in the most accurate and effective manner.

About the Author

Vova Kamenker is a Solution Architect & Technical Account Manager responsible for leading design of technical solutions, driving and managing the pre-sales process with direct and channel customers as well as managing relationships with current clients and assisting them with product technical aspects.