CLIENT AREACall Us 1-800-383-5193


Call Us 1-800-383-5193


Call Us 1-800-383-5193

Need help?

Our experts have had an average response time of 13.52 minutes in October 2021 to fix urgent issues.

We will keep your servers stable, secure, and fast at all times for one fixed price.

SYN flood attacks – How we mitigate

by | Feb 24, 2021

Wondering how to mitigate syn flood attacks? We can help you.

An SYN flood is a form of a denial-of-service attack. Here an attacker will send a succession of SYN requests to a target’s system in an attempt to consume enough server resources to make the system unresponsive to legitimate traffic.

By repeatedly sending initial connection request (SYN) packets, the attacker overwhelms all available ports on a targeted server machine

Here at Bobcares we often handle DOS attacks as a part of our Server Management Services.

Today let’s see some of the steps which our Support Engineers follow to mitigate this issue.


How do SYN flood attacks work?

SYN flood attacks works involve the process of exploiting the handshake process of a TCP connection. Under normal conditions, a TCP connection has three distinct processes in order to make a connection.

  1. First, to initiate the connection, the client sends an SYN packet to the server
  2. Then the server responds to that initial packet with an SYN/ACK packet, in order to acknowledge the communication.
  3. Finally, the client returns an ACK packet to acknowledge the receipt of the packet from the server. After sending and receiving the packet, the TCP connection is open and able to send and receive data.

In order to create denial-of-service, an attacker utilizes the fact that after an initial SYN packet has been received, the server will respond back with one or more SYN/ACK packets and wait for the final step in the handshake. Here’s how it works:

  1. First, the attacker sends a high volume of SYN packets to the targeted server, often with spoofed IP addresses.
  2. The server then responds to each one of the connection requests and leaves an open port ready to receive the response.
  3. While the server waits for the final ACK packet, which never arrives, the attacker continues to send more SYN packets. The arrival of each new SYN packet causes the server to temporarily maintain a new open port connection for a certain length of time, and once all the available ports have been utilized the server is unable to function normally.


How to mitigate syn flood attack

Now let’s see some of the steps which our Support Engineers follow to mitigate this issue.


1. Increasing Backlog queue

On a targeted device, each OS has a certain number of half-open connections that it allows. One response to high volumes of SYN packets is to increase the maximum number of possible half-open connections the operating system will allow.

To increase the maximum backlog, the system must reserve additional memory resources to deal with all the new requests. However, if the system doesn’t have enough memory to handle the increased backlog queue size, system performance will be negatively impacted.


2. Recycling the Oldest Half-Open TCP connection

Another way to mitigate this error is to overwrite the oldest half-open connection once the backlog has been filled. This strategy requires that the legitimate connections can be fully established in less time than the backlog can be filled with malicious SYN packets.


3. SYN cookies

In this strategy, the server must create a cookie. To avoid the risk of dropping connections when the backlog fills, the server responds to each connection request with an SYN-ACK packet. But then drops the SYN request from the backlog. Then it removes the request from memory and leaves the port open and ready to make a new connection.

If the connection is a legitimate request, and a final ACK packet is sent from the client machine back to the server, the server will then reconstruct the SYN backlog queue entry.


4. RST cookies

For the first request from the client, the server intentionally sends an invalid SYN-ACK. This results in the client generating an RST packet, which tells the server something is wrong. If this is received, the server knows the request is legitimate, logs the client, and accepts subsequent incoming connections from it.


5. Stack tweaking

To mitigate the effect of SYN floods, administrators can tweak TCP stacks. This can either involve reducing the timeout until a stack frees memory allocated to a connection, or selectively dropping incoming connections.

[Still not able to mitigate the syn flood attack? – We are here to help you]



Today, we saw how our Support Engineers mitigate this syn flood attack.


Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.


var google_conversion_label = "owonCMyG5nEQ0aD71QM";


Submit a Comment

Your email address will not be published. Required fields are marked *




Privacy Preference Center


Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

PHPSESSID - Preserves user session state across page requests.

gdpr[consent_types] - Used to store user consents.

gdpr[allowed_cookies] - Used to store user allowed cookies.

PHPSESSID, gdpr[consent_types], gdpr[allowed_cookies]


Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.

_ga - Preserves user session state across page requests.

_gat - Used by Google Analytics to throttle request rate

_gid - Registers a unique ID that is used to generate statistical data on how you use the website.

smartlookCookie - Used to collect user device and location information of the site visitors to improve the websites User Experience.

_ga, _gat, _gid
_ga, _gat, _gid


Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.

IDE - Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.

test_cookie - Used to check if the user's browser supports cookies.

1P_JAR - Google cookie. These cookies are used to collect website statistics and track conversion rates.

NID - Registers a unique ID that identifies a returning user's device. The ID is used for serving ads that are most relevant to the user.

DV - Google ad personalisation

IDE, test_cookie, 1P_JAR, NID, DV, NID
IDE, test_cookie


These are essential site cookies, used by the google reCAPTCHA. These cookies use an unique identifier to verify if a visitor is human or a bot.