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

blog_if_a_syn_flood_attacks_your_networkThere 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”

syn_ack_flood_1In 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”

syn_ack_flood_1As 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”

syn_ack_flood_stats_3A 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. Also, detection and protection theories suggest a few very basic concepts to effectively block complex and intermittently changing threats, using two main concepts:

  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).

Introducing MazeBolt’s RADAR™ technology

RADAR™, MazeBolt's new patented technology solution, is the only 24/7 automatic DDoS attack simulator on a live environment with ZERO downtime/ disruption. It automatically detects, analyses, and prioritizes the remediation of DDoS vulnerabilities in any mitigation system. Raising the efficiency of your Mitigation solution and delivering the ultimate DDoS protection.    

This new technology allows you to address the two gaps discussed above through:

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. 

Guided Remediation Process and Revalidation of specific network vulnerability intelligence collection throughout the process creates a prioritized remediation plan, guiding customers in closing vulnerabilities in the most accurate and effective manner.

Finally, the system immediately revalidates the protection level, ensuring the highest level of protection is achieved. 

Here is a quick demo that highlights how DDoS RADAR™ detects and eliminates DDoS vulnerabilities.

About MazeBolt

Israel-based MazeBolt is an innovation leader in cybersecurity, with over two decades of experience in pioneering DDoS protection solutions. The company’s new flagship product, RADAR™, is a patented, new technology. It offers DDoS protection through automated DDoS simulations on live production, with zero downtime. Working in conjunction with any mitigation solution installed. Its unique capabilities have ensured business continuity and full DDoS security posture for enterprises worldwide including Fortune 1000 & NASDAQ-listed companies.

Picture of Vova Kamenker

About Vova Kamenker

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.