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.
- First, to initiate the connection, the client sends an SYN packet to the server
- Then the server responds to that initial packet with an SYN/ACK packet, in order to acknowledge the communication.
- 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:
- First, the attacker sends a high volume of SYN packets to the targeted server, often with spoofed IP addresses.
- The server then responds to each one of the connection requests and leaves an open port ready to receive the response.
- 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]
Conclusion
Today, we saw how our Support Engineers mitigate this syn flood attack.
0 Comments