Support Center > Search Results > SecureKnowledge Details
Check Point response to PASTEBIN claim that Check Point Firewalls are vulnerable to simple SYN flooding Technical Level
  • There is a blog post that reports Check Point Firewalls are vulnerable to simple SYN flooding. For more details refer to

  • Check Point offers a HotFix for this issue. This solution was confirmed by the original reporter. For more details, refer to

  • This issue is relevant to R70.x, R71.x, R75.x, R76.X and R77.X on SecurePlatform / Gaia / Linux platforms.

  • This issue is not relevant to IPSO platform.


Table of Contents:

  • Background
  • Solution
    • Description
    • Procedure
    • Note
  • Additional recommended improvements
    • Increasing the size of RX buffer for NIC
    • Multi-Queue feature
    • Performance optimization



SYN Flood is a 'brute force' attack, which is based on a client that sends an enormous amount of TCP SYN segments, usually with a purpose of filling up the Server (or Gateway) memory.

Nevertheless, the Gateway still needs to process the packets that the attacker sends - and of course, there is a limit to the number of packets that a Gateway can process per second, and it varies according to the Gateway configuration and specification.

This article suggests several ways to dramatically improve (per Check Point QA tests, 3-10 fold) the maximal number of TCP SYN segments per second that a Check Point Security Gateway can handle under a 'SYN Flood' attack.



  • Description:

    Check Point IPS protection called 'SYN Attack' (especially in 'SYN Cookie mode') prevents the attacker from filling the Gateway (and Server) memory completely, and there is no issue (or claim) with this core functionality of 'SYNDefender'.

    To configure this IPS protection, go to SmartDashboard → 'IPS' tab → Protections → By Protocol → IPS Software Blade → Network Security → TCP.

    Performance of Check Point Security Gateway under a SYN Flood, when "SYN Attack" protection (SYNDefender) is configured to work in "SYN Cookie mode", can be increased even more by enabling a global kernel parameter 'asm_synatk_dont_route' that will bypass the Linux routing code for sending SYN-ACK packets back to the sender, thus releasing the greatest bottleneck in the process.
    The new parameter 'asm_synatk_dont_route' should not be activated in "Relay mode".

  • Procedure:

    Follow the sk74480 ('dst cache overflow' messages under a SYN Flood when 'SYN Attack' IPS protection is enabled).

  • Note:

    This solution was confirmed by the original reporter. For more details, refer to


(1) Increasing the size of RX buffer for NIC


Increasing the size of the RX buffer improves the ability of the Security Gateway to handle the incoming traffic. Increased size of the RX buffer allows the NIC driver to queue more incoming packets, and thus decreases packet drop, especially in scenarios with high CPU utilization, such as under the SYN Floods.


Follow the sk42181 (How to increase sizes of buffer on SecurePlatform/Gaia for Intel NIC and Broadcom NIC).


This change does not depend on the Multi-Queue feature (see the relevant paragraph below).
This change is much more noticeable when Multi-Queue hotfix (sk80940) is not installed.



(2) Multi-Queue feature


As SYN Flood usually arrives at one network interface card only, the bottleneck is usually the SecureXL dispatcher, which [without the Multi-Queue feature] is bound to a single interface only.

The Multi-Queue feature improves the Security Gateway's performance during SYN Flood attacks by configuring more than one traffic queue for each network interface card and using more CPU dispatcher cores for traffic acceleration.


Follow the sk80940 (Multi-Queue hotfix for Security Gateway R75.47 and lower).


(3) Performance optimization


It is strongly recommended to check if the performance of a Security Gateway can be improved even more.


Follow the sk98348 (Best Practices - Security Gateway Performance).

Give us Feedback
Please rate this document