Today, I’d like to talk about SYN cookies and how they can help protect your network from SYN and TCP floods, which are very harmful cyberattacks, cyberattacks on the Network layer 3/4.
Have you ever experienced a situation where your network was bombarded with a lot of SYN and TCP flood attacks, causing problems like false alarms or making it hard to connect to your servers during these attacks?
Don’t worry!! Our SYN cookies feature, which can be enabled by request, can come to the rescue. It’s designed to deal with these attacks effectively while keeping false alarms to a minimum.
Let’s simplify what SYN cookies are: SYN cookies are often employed in servers as a resource-saving measure because they eliminate the need for servers to reserve resources for the initial connection state.
Yet, when it comes to Imperva Cloud WAF BH mitigation, SYN cookies serve a different purpose. They act as a whitelisting mechanism, confirming that the source trying to establish a connection is not a fraudulent or impersonated source.
Here’s how it works in simpler terms:
- When someone tries to connect to your network (let’s call them the “source”), they send a SYN packet.
- Our protection system (let’s call it the “BH”) responds with a “SYN+ACK.” This message also includes a sequence number and expects to see another message back within a short time.
- If the source sends the right message back (we call it an “ACK”), the BH checks it. If it’s correct, the BH sends a “RST packet” saying, “I’m not the server you’re looking for, so please try again.” This makes the source reconnect.
- The source then sends another request, and this time BH forwards it to the real server knowing it is a legitimate request and not a part of the ongoing SYN flood.
- If the client fails to send an ACK back within the expected timeframe, the BH would recognize this as a potential sign of a spoofed or fraudulent IP address, which is often a component of an attack. In response, the BH would take action to block further SYN packets from this source, preventing additional connection attempts.
Please Note -
- One important thing to note is that you can turn on this feature when you need it. It’s not always active; you can ask our SOC team to turn it on when it’s necessary.
- The client needs to be able to support a Reset packet.
I hope this has been informative.