We have a web server which is protected behind of IPS, in front of IPS is akamai cloud proxy. So basically the network diagram for inbound traffic is somehow like this
(Akamai Proxy) --> (Upstream Router) --> (Firewall) --> (IPS) ---> (Web Server)
A few days ago, there is a SYN attack that targeted on our web server, good thing is, our IPS detected the burst rate, and activated DOS blocking upon saw
"Inbound TCP SYN or FIN Volume Too High" attack. However, due to all the incoming traffic including SYN packet was proxified by Akamai, hence, the legit user was also being blocked from accessing our page.
Understanding that SYN flood is operating on layer 4, it seems not possible for IPS to determined the source of SYN packet when attack occurred and to block only on the bad source IP.
Due to the attack signature blocking seems not really working well when the traffic is proxified, I planning to utilize the SYN cookie next for further protection, and I wonder if there is any other options that I can utilize?
You could set a threshold on connection rate using connection limiting policies. I would say you will need to stick to connection rate on the policy, as during the SYN flood you wont see many 'active' connections, just the incoming connection requests.
Combining SYN cookie + connection rate limiting may work better than DoS Learning in your case, as the single source IP for the attack will always be the Akamai reverse proxy. I've never had the need to combine these in prod so cannot tell you what to expect.
I believe though, even combining these, you can still run into issues, as the link between the Akamai IP and the IPS could get saturated depending on the DOS traffic generated.
Mitigating the attack at the proxy level seems the logical solution... But then we would not be talking about the IPS
Thanks for this info, on the other hand, I wish to set the number of SYN Cookie Inbound Threshold Value, is there any guide line that you think that I can refer from the Flows under Traffic Statistics?
As you can see from the screenshot you posted, the sensor supports over 500k flows, but that may be far too many for your servers/load balancers. So when configuring DoS/DDoS prevention mechanism, I usually always check what is the maximum number of connections supported on the server side, and then decide what limits/thresholds configure on the policies.
So if for example your servers/LB support 100k connections, you may want to limit that to 80k (so 80%) of the maximum supported.
However, each environment is different and depending on how your web server/application works, you may want to lower that number - i.e., other things you may want to take into account when setting thresholds:
- What the max supported sessions at each application tier? Front end, middle tier, back end?
- How much traffic a single request to the front end web server will be generating against the application (middle tier) and back end (i.e database)?
- How much response traffic will be generated by a single request? It could be that 100k incoming request would saturate the pipe outbound?
If you have NTBA or another netflow analyser, I would also suggest you check the inbound/outbound throughput and sessions stats to get a better understanding of what the limit/thresholds should be on your DoS/DDoS policies.