CPUG: The Check Point User Group

Resources for the Check Point Community, by the Check Point Community.

First, I hope you're all well and staying safe.
Second, I want to give a "heads up" that you should see more activity here shortly, and maybe a few cosmetic changes.
I'll post more details to the "Announcements" forum soon, so be on the lookout. -E


Results 1 to 2 of 2

Thread: UDP Flood on Deny rule (Downtime) - Drop Optimization??

  1. #1
    Join Date
    Rep Power

    Default UDP Flood on Deny rule (Downtime) - Drop Optimization??


    A few times per year, we face a problem with machine being infected and/or acting weirdly by sending a TON of UDP packets towards destinations protected by a Deny rule.

    This leads the firewall CPU to 100% and is creating downtime, no matter how big the firewall is (we have 30 CheckPoint firewall, including various models like Datacenter ones).

    When we test it in the lab, we can reproduce the problem (with the simple so called LOIC software).
    This only happens with UDP (i guess TCP is protected by Syn Cookies or other methods).

    My question is : how can we prevent or limitate this effect?

    I saw in the SmartCenter that a feature is called "Drop Optimization" (Gateway Parameters -> Optimization -> Firewall Policy Optimization -> Enable drop optimization).
    If i understand correctly (sk90861 and sk90941) this is supposed to help in my case by sending dropped packets to SecureXL.

    However, i tried to activate it (and also some CLI tweaks) but the result in the same : the firewall is instantly killed if I send it a storm of denied UDP.

    Do anyone has an idea how to deal with that?

    Is there any tool on the firewalls that I can use to mitigate this issue?

    The last resort fix will be to deploy some basics QoS for UDP on the user side, but we have more than 800 switches of different models, so it's not easy.

    Thank you!

  2. #2
    Join Date
    Rep Power

    Default Re: UDP Flood on Deny rule (Downtime) - Drop Optimization??

    I’m still digging into the issue and I found interesting but odd things.

    Here is the detail.

    After enabling the Drop Optimization on the SmartCenter, I tried to verify in CLI that if it was really working on the gateway.

    [Expert@lab-fw1:0]# fwaccel stat
    Accelerator Status : on
    Accept Templates : disabled by Firewall
    Layer lab-fw1-policy Security disables template offloads from rule #5
    Throughput acceleration still enabled.

    Drop Templates : enabled
    NAT Templates : disabled by user
    NMR Templates : enabled
    NMT Templates : enabled

    Accelerator Features : Accounting, NAT, Cryptography, Routing,
    HasClock, Templates, Synchronous, IdleDetection,
    Sequencing, TcpStateDetect, AutoExpire,
    DelayedNotif, TcpStateDetectV2, CPLS, McastRouting,
    WireMode, DropTemplates, NatTemplates,
    Streaming, MultiFW, AntiSpoofing, Nac,
    ViolationStats, AsychronicNotif, ERDOS,
    McastRoutingV2, NMR, NMT, NAT64, GTPAcceleration,
    Cryptography Features : Tunnel, UDPEncapsulation, MD5, SHA1, NULL,
    3DES, DES, CAST, CAST-40, AES-128, AES-256,
    ESP, LinkSelection, DynamicVPN, NatTraversal,
    EncRouting, AES-XCBC, SHA256

    The Drop Optimization is actually enabled, but the Accept Templates is being disabled “from rule #5” caught my attention

    The rule 5 is a legitimate DHCP & DHCP-Relay rule which has absolutely no link with my tests

    I tried to disable this rule for testing, and the same output of “fwaccel stat” then showed the same thing for another rule involving Active Directory services (DCE_RPC, Kerberos, LDAP, etc..).

    So I then tried to disable this second rule and… Everything is just working perfectly, including the Drop Optimization (Accept Template are On)!
    I can’t take down my fw even with sending it 1 millions denied UDP packets / sec.

    I’m pretty sure it’s linked to “inspected” protocols like RPC or DHCP(-Relay), stuff like that.

    Having a DHCP Rule or ActiveDirectory rule on the first rules of your ruleset seems to simply disable SecureXL for ALL the others rules BELOW it.
    Pretty odd behavior.

    Do you have any idea why is that, any technical explanation?
    Is there any way to make it work without disabling those mandatory rules (I mean, this is just DHCP..)?

    Is there a work-around and or fix (if it's not the normal behavior)?

    I need help :-(

Similar Threads

  1. Weired drop on accept rule
    By slowfood27 in forum R77.30
    Replies: 7
    Last Post: 2018-01-19, 13:19
  2. Drop rule and create a new zone in firewall. 1430 Appliance.
    By MrKindell in forum Check Point Small Appliances
    Replies: 1
    Last Post: 2017-02-10, 23:39
  3. Replies: 7
    Last Post: 2017-01-08, 18:45
  4. ARP Flood after Failing over
    By thefunkygibbon in forum Clustering (Security Gateway HA and ClusterXL)
    Replies: 1
    Last Post: 2010-07-09, 21:28
  5. Replies: 5
    Last Post: 2006-11-12, 14:56

Tags for this Thread


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts