CP 16200 overloaded by "small" DDoS

[Dilian_Chernev]

Hi mates,

I have a problem with a CP 16200 running in cluster that have overloaded by small DDoS.

As you can see, connections are around 113k (limit is 200k, so aggressive aging is not activated), incoming bandwidth should be around 200Mbit/s and all 43 workers are at 100%. There are no interface drops, 4x SNDs are at about 30%.

Attack is TCP- HTTPS and all connections are out of state, so firewall is dropping them with First packet isn't SYN.

Devices are running R81.10 with JHF109 and following blades enabled:  Firewall, VPN, Mobile Access, Application Control, IPS, Identity Awareness, AntiBot, Monitoring.

Usually device is handling about 1Gbit traffic with 70k connections in normal days.
Recommendations in sk112241 are reviewed and applied but still device is almost not responding during such attack.

What could be the reason that it is so easy overloaded?

Thanks,

Dilian

[Daniel_3]

Which steps from sk112241 did you apply?

I had the best results with aggressive aging, lower tcp start timeout (5 seconds) and malicious IP block. We also implemented penalty box recently. SYN Defender was also in use but it consumed way too much performance which lead to more impact.

Also make that drop optimization is enabled.

[Dilian_Chernev]

I believe all of them without Network Quota and Geo Location. 

Connections are about 60% of maximum, so aggressive aging is not activated.
SYN defender is on, but maybe we should consider turning it off, as attack was not SYN flood.
Penalty box is enabled, was modified to 350 packets/s, now is lowered to 50.
Drop optimization is enabled.

[Daniel_3]

Ok, sounds like a good configuration already.

Overall the settings still might need ajdustments depending on the legitimate application traffic. It took us a few big hits to find the sweet spots for all the values for timeouts, packet rate etc.

Worst case scenario you need some anti-ddos solution (like cloud scrubbing or an on-premise anti-ddos appliance).

[Timothy_Hall]

If I had to take a wild guess, I'd say you have a very high percentage of traffic in F2F/slowpath due to how your blades are configured, which is saturating your workers.  Please post outputs of the Super Seven commands taken on the active cluster member (if applicable), ideally while the system is heavily loaded:

https://community.checkpoint.com/t5/Scripts/S7PAC-Super-Seven-Performance-Assessment-Commands/td-p/4...

Could also be multiple elephant flows getting handled in F2F/slowpath, so try fw ctl multik print_heavy_conn to see all current elephant flows and also those detected in the last 24 hours to get some insight there,