How to deal with SYN Attack or Syn Retransmission Attack ?

[Ven]

Hello Experts, 

How to deal with SYN Attack or SYN Retransmission Attack ? Looking for some tips and best practices!!

Thanks,

Ven

[_Val_]

Please start here: sk112241, and also look into sk120476

[Timothy_Hall]

Val responded with the appropriate SKs to check out, the only best practice I would add is make sure you are using R80.20+ on your gateway. The Inspection Settings "SYN Attack" signature should not be enabled in R80.10 and earlier unless you are truly desperate, as it will disable acceleration for practically all traffic traversing the gateway by forcing it F2F.  The performance impact of enabling it on R80.10 and earlier may end up being worse than the actual SYN flood itself.  Here is the relevant page from my Max Power 2020 book mentioning this:

[Wolfgang]

This is a screenshot from a blocked attack. I'm wondering about the lower part "PPAK ID: 0"

PPAK mean PerfomancePack or not ?

Was the attack blocked via SecureXL or not ?

Can someone explain the difference between the upper and lower part.

[Timothy_Hall]

Unless you have a Falcon accelerator card, there should always be only one instance of SecureXL (#0) irrespective of the number of SND/IRQ cores in your CoreXL split.  Performance Pack (PPAK) and SecureXL more or less mean the same thing these days.

The upper part is the SYN Defender implementation in the Firewall Worker/Instance cores, and the lower part is in SecureXL/sim.  Remember that the first packet of every new connection (TCP SYN) always goes to a Firewall Worker/Instance in R80.20+ (unlike R80.10 and earlier where SecureXL itself could match a new connection on a template), so it would make sense that most blocks are occurring on the Firewall Worker/Instance in the upper part.  But SecureXL can enforce SYN Defender as well in R80.20+; it couldn't do that in earlier releases which led to all traffic subject to the SYN Defender protection going F2F in R80.10 and prior.

[Wolfgang]

@Timothy_Hall you‘re right. The shown screenshot is from a R80.40 gateway attacked from a external system sending only syn packets with different source IPs, nothing else. These packets are handled by the firewall workers as you described.

„fwaccel synatk“ works, attackers are detected and blocked immediately. Not much overhead for this for all CPUs. Without „fwaccell synatk“ the same attack will be blocked by stateful inspection or cleanup rule, but with 95% CPU utilization on all cores.

[Bob_Zimmerman]

It's possibly worth noting a "SYN retransmission attack" is often caused by a connectivity problem. If the client doesn't get a SYN-ACK in response to its SYN, it will send the SYN again. If anything about the SYN changes, the firewall reports it as an attack. "Retransmitted SYN with different window scale", for example. This almost always means the client simply didn't hear back from the server.