R80.20 - SYN Defender on SecureXL Level

[HeikoAnkenbrand]

I think the new feature "Accelerated SYN Defender" is a good choice to effectively prevent "SYN Flood Attack" on Check Point Gateways with enabled SecureXL.

 

A TCP SYN Flood attack occurs when a host, typically with a forged IP address, sends a flood of TCP [SYN] packets. Each of these TCP [SYN] packets is handled as a connection request, which causes the server to create a half-open (unestablished) TCP connection. This occurs because the server sends a TCP [SYN+ACK] packet, and waits for a response TCP packet that does not arrive. These half-open TCP connections eventually exceed the maximum available TCP connections that causes a denial of service condition. The Check Point Accelerated SYN Defender protects the Security Gateway by preventing excessive TCP connections from being created. The Accelerated SYN Defender uses TCP [SYN] Cookies (particular choices of initial TCP sequence numbers) when under a suspected TCP SYN Flood attack. Using TCP [SYN] Cookies can reduce the load on Security Gateway and on computers behind the Security Gateway. The Accelerated SYN Defender acts as proxy for TCP connections and adjusts TCP {SEQ} and TCP {ACK} values in TCP packets.

You can find more in the manual under:

• fwaccel synatk
• fwaccel6 synatk

Regards,

Heiko

[MRossi92]

Hello

This feature is supported by R80.20 SP in a 64000 Appliance?

Thank you

[Yair_Shahar]

Yes, Supported using “g_fwaccel synatk” command.

Note that it is supported via Gateway CLI only and not via Smart Console

[Raymondn]

I am wondering if someone may clarify for me about the “Syn Attack protection” and the “Accesslerated SYN Defender (i.e. fwaccel synatk).

Are they the same thing, or they are two different things?

I feel the "Syn Attack protection" was the legacy configuration from the Syn Defender in R65, whereas this "Accesslerated SYN Defender" is a new(?) generation of the Syn Defender?

Am I correct?  Please educate me if I misunderstand these two terms.

Anyway, I hope I can understand these terms better, and start to configure one or both of them according to some kind "best practice" suggestion from Check Point.

Thanks.

[_Val_]

@Raymondn , in a nutshell,  the idea of Syn Defender is still the same. It is just with R80.20, it can be moved from FW into SXL. If so, it is called "Accelerated Syn Defender". THis functionality did not exist in the previous releases. 

More information can be found here: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut... 

and here (under "Accelerated Syn Defender" chapter"): https://sc1.checkpoint.com/documents/R80.20_GA/WebAdminGuides/EN/CP_R80.20_PerformanceTuning_AdminGu...

[Raymondn]

Thanks for the info.

Spent sometime reading some of those and now I have a better understanding.

If I read SK correctly, in the end of the sk it did leave a statement where keeping this Syn Attack protection feature 'disable' until you are facing a DOS attack, may be a wise choice.

How do people feel about this?  Is this a feature people typically disable, or leave it as "monitor only", and only set to enforcement when facing DOS issue?

Thanks.

[Timothy_Hall]

I would agree with the recommendation in the SK and leave SYN Defender off unless you need it.  In R80.10 and earlier, enabling SYN Defender would kill SecureXL acceleration of most traffic traversing the firewall and make it go F2F, which could cause its own performance problems if the firewall was already under high load.  This is why the Inspection Setting "SYN Attack" still shows a Performance Impact rating of "Critical".  Now that SecureXL itself can perform this protection in R80.20+ turning it on is not likely to cause other performance problems.

Setting an email/SNMP alert for the Aggressive Aging signature could be one way to get alerted that you might need to turn on SYN Attack.

[Daniel_Westlund]

Hello. I wonder the reasoning for only turning this protection on when the issue occurs? Is it possible this idea is left over from when it was not available via SecureXL and therefore caused a critical performance hit? My customer has a requirement to have DDOS protection on and doesn't prefer to have it work via an alert and then a manual change. I told them it's not recommended, but I'd like to know the reasoning, as they may have to find another solution if this is the case.

[Timothy_Hall]

Although this SYN protection can now be handled inside SecureXL/sim, it still causes some overhead at the start of every TCP connection.  If the new connection rate through your firewall is high this overhead can really add up.  What I would suggest is making sure the Aggressive Aging Inspection Setting is enabled, and configuring alerting for it.  When the alert fires due to excessive memory consumption for tracking connections, you can assess the situation and enable SYN Defender if appropriate.  Aggressive Aging is always a great "canary in the coal mine" to let you know that something unusual is happening.

[Daniel_Westlund]

Thank you. I'm sure this is correct, but now I need to figure out how to setup alerts for Aggressive Aging. In sk25941 when describing how to setup internal_sendmail, there is a note that says:

• Mail Alerts may not work even after configuring as per this sk. To receive mail alert you need to have an SMTP server configured with "Mail Relay" and "No Authentication". 

I'm guessing this customer does not have their SMTP server setup with mail relay and no authentication, and I don't want to ask them to do that. There is another post here that says I need to write a script to get this to work. Do you have any other thoughts on how I can get alerts working for Aggressive Aging? Sorry I'm asking a new question here, but hoping I'm missing a more realistic way to do this.

[Timothy_Hall]

The customer just needs to allow emails from the IP address of the SMS to be relayed by their SMTP server, which would normally be denied by default.  They don't have to allow mail relay for all IP addresses.  They also need to allow unauthenticated emails from that single IP address.  The setup for the mails will be on the Global Properties "Alert" screen, and then set the Aggressive Aging Inspection Track setting to Mail. 

I don't see the ability to fire a mail-based Automatic Reaction from SmartEvent when Aggressive Aging kicks in but it might be possible to create a new Event type that could do so.

[Daniel_Westlund]

I have a couple of questions about setting up an SNMP trap for Aggressive Aging. One is, AA turns on when the connections table or memory hits X%, 80% by default. This made sense to me when the connections table used to have a finite limit. Now that the connections table is dynamically set, how does it calculate when it hits 80%?

Another question is, is there a good way to generate an Aggressive Aging SNMP trap? My thought is if I understand how the 80% connection table works, then I could open a change window where I artificially drop the connection % to generate some traps, and turn on Aggressive Aging. My monitoring guy says he wants to get a trap from this protection so he can use it to build a template to create a ticket when we receive this drop. Thank you as always.

[Timothy_Hall]

This is answered in sk122154: How is Aggressive Aging enforced when Concurrent Connections Capacity Limit is calculated ...

When the connections table sizing is set to "Automatically", if the overall memory utilization of the gateway exceeds the specified threshold percentage, Aggressive Aging will start up and send an SNMP trap if so configured.  So for example if a system has 16GB of RAM and you run free -m, with the default 80% setting the amount of "used" memory would need to exceed ~12.8GB which would correlate to "available" reporting approximately ~3.2GB.  All other values reported by this command such as "free", "shared", and "buff/cache" are irrelevant to this calculation for Aggressive Aging and should be ignored, especially "free" which does not mean what most people think it means.