test

[joon]

Hello!

If you look at the ip item on the Quantum Spark(Gaia Embeded OS)
There is a dos attack called Non-TCP-Flood-Attack.
I'm in the middle of an attack test.
But I don't know how to test it.
Even after http flood, udp flood, and icmp flood attacks, no logs are generated for Non-TCP-Flood-Attack.
Could you please let me know the test scenario for generating the log?
Thank you.

[PhoneBoy]

From what I can see in some TAC cases, at least on non-Spark devices, this protection activates when the number of non-TCP connections in the connections table exceeds a certain threshold.
That would imply your test traffic should include traffic from multiple sources to multiple destinations to ensure connections table entries are generated.
More details about exactly how you are testing would be helpful.

[joon]

I tried udp flood, icmp flood, and http flood attack, but I confirmed that non-tcp-flood attack is not responding.
It's not a syndefender.
Please check what kind of test we need to proceed for the non-tcp-flood attack to operate.

[PhoneBoy]

You said "I tried udp flood, icmp flood, and http flood attack"
What tool(s) did you use to generate this traffic?
Any specific configuration used for this tool?
Where is the target of this flood in relation to the client generating the traffic and the gateway under test?

[joon]

I used the ddos attack tool provided by github.
The target is Spark equipment.

[PhoneBoy]

If it's on Github, you should be able to provide a link to the exact tool used as well as screenshot of the relevant options you chose and/or the exact CLI command used to generate the test.
Please also provide the exact appliance used and firmware version.

[Lesley]

What type of an attack you perform and what features you have enabled to prevent this attack? 

Flood attack sounds like SYN defender , do you mean this maybe? 

https://sc1.checkpoint.com/documents/Appliances/Quantum_Spark_R82.00.X/CLI/EN/Content/Topics/fwaccel...

[joon]

[joon]

I tried udp flood, icmp flood, and http flood attack, but I confirmed that non-tcp-flood attack is not responding.
It's not a syndefender.
Please check what kind of test we need to proceed for the non-tcp-flood attack to operate.

[Lesley]

Able to edit the protection? These are from Smart Console (could be different for GAIA embedded system)

If you able to edit you can see the parameters that are checked in order for the protection to be active. 

[PhoneBoy]

Embedded Gaia does not have an option to change the threshold for this protection (at least in the WebUI). 
However, it would make sense that it have the same default value (50%). 

[the_rock · Accepted solution]

I ran your EXACT query through MS copilot (GPT 5.2-think deeper setting) and for what is worth, below is what it gave me.

*****************************************

Hi! Great question — and you’re not the first person to be confused by that “Non‑TCP‑Flood‑Attack” item on Quantum Spark / Gaia Embedded.

Before I jump in: I can’t provide step‑by‑step instructions for launching flooding attacks. But I can explain what that protection actually detects, why your HTTP/UDP/ICMP tests don’t trigger it, and how to validate it safely in an authorized lab by focusing on state-table behavior and thresholds (not “how to flood”).

---

1) What “Non‑TCP Flooding / Non‑TCP‑Flood‑Attack” actually means

In Check Point terminology, Non‑TCP Flooding is about preventing non‑TCP “connections” from filling the firewall’s connection/state table. The official SmartConsole help wording is very explicit: it’s there “to stop non‑TCP connections from flooding the connection table.” [sc1.checkpoint.com]

Check Point’s advisory explains the underlying issue: the firewall maintains state information for both TCP and connectionless non‑TCP protocols, and an attacker can send high volumes of non‑TCP traffic to fill the state table and cause DoS (preventing new connections). It also notes that unlike TCP, these protocols don’t have a built‑in reset/clear mechanism, so SYN Defender doesn’t apply. [advisories...kpoint.com]

✅ Key takeaway:
This is usually not a packets‑per‑second flood detector like “UDP Flood” or “ICMP Flood.”
It’s typically a state/connection-table quota style protection. [sc1.checkpoint.com], [advisories...kpoint.com]

---

2) Why your HTTP/UDP/ICMP flood tests didn’t generate a “Non‑TCP Flood” log

A few common reasons:

A) You’re triggering different flood protections

HTTP flood is application/TCP oriented, and UDP/ICMP floods have their own dedicated protections. So even if you are “flooding,” the gateway may classify and log it under those specific protections rather than the “Non‑TCP Flooding” quota mechanism. [sc1.checkpoint.com], [advisories...kpoint.com]

B) Your traffic may not be creating lots of state entries

Non‑TCP Flooding is about connection table pressure. If your test traffic is handled in a way that doesn’t create many tracked entries, you won’t hit the quota and therefore won’t see the log. The advisory’s focus on state table exhaustion is the clue here. [advisories...kpoint.com]

C) “Non‑TCP” may mean “Other IP protocols” (not UDP/ICMP)

On some Check Point platforms and profiles, “Non‑TCP” can refer broadly to non‑TCP traffic, but in other contexts (and in many UIs) it effectively maps to IP protocols other than TCP (6) and UDP (17) — e.g., GRE (47), ESP (50), AH (51), etc. Quantum Spark even has an object type explicitly for “a protocol other than TCP (6) or UDP (17).” [sc1.checkpoint.com]

So if your testing only covered HTTP(TCP), UDP, and ICMP, you still might not be hitting what your specific “Non‑TCP‑Flood‑Attack” counter expects.

---

3) A safe, authorized validation approach that usually produces the log

Instead of “how to flood,” think: How do I make the gateway believe its non‑TCP quota/state allocation is being consumed?

Step 1 — Confirm the protection is actually enabled and set to log

In SmartConsole (for gateways managed that way), the help path is:
Manage & Settings → Blades → General → Inspection Settings → Protections table → Non‑TCP Flooding → Profile → Advanced [sc1.checkpoint.com]

On Quantum Spark (locally managed), the UI layout differs, but the concept is the same: ensure the “Non‑TCP‑Flood‑Attack” item is:

• Enabled
• Track/Log = On (or “Detect + Log” depending on wording)
• Not overridden by a higher-level profile that disables logging

Step 2 — Lower thresholds in a lab to make testing feasible

Because this protection often relies on percent-of-table / quota style triggers, defaults can be high enough that your test won’t reach them without risking instability.

In other words: make it easier to hit the condition in a test window by temporarily lowering the threshold/quota (again, only in an isolated lab or scheduled maintenance window).

(Why this is reasonable: the feature is explicitly designed around preventing connection table flooding, and triggering it depends on crossing that limit.) [sc1.checkpoint.com], [advisories...kpoint.com]

Step 3 — Validate what the gateway is “seeing” (connection table visibility)

If you have access to Gaia shell / expert mode on the device (varies by Spark firmware and admin permissions), Check Point documents how to inspect kernel tables:

• fw tab -t connections -s for a short summary of the connections table
• and fw tab -t connections -f for more detailed output [sc1.checkpoint.com]

This step is important because it tells you whether your test traffic is producing the type/volume of state entries that would contribute to a “quota reached” condition.

If you can’t run these commands on Spark due to role/CLI limits, use the available monitoring/logging view (or central management logs) to confirm state pressure indirectly (e.g., concurrent connection counts, drops, or “quota reached” style messages).

Step 4 — Use legitimate non‑TCP protocols already in your environment

Since Spark supports services “other than TCP (6) or UDP (17)”, the safest lab approach is to validate with authorized, legitimate traffic patterns that use “other IP protocols” (for example, VPN-related protocols) rather than arbitrary packet blasting. [sc1.checkpoint.com]

I’m intentionally keeping this high level (no “do this tool with these flags”), but the practical idea is:

• generate many new non‑TCP stateful flows in a controlled way
• with the threshold temporarily reduced, the gateway should log when the quota is crossed

---

4) If you still don’t get logs: checklist

1. Log destination & log view
   Confirm you’re looking in the right place: local logs vs central logs vs SmartEvent correlation. Sometimes events are aggregated or rate-limited.

2. Profile precedence / overrides
   Another profile (or global “Inspection Settings”) might override your per‑protection “log” flag. [sc1.checkpoint.com]

3. Earlier protections trigger first
   If UDP/ICMP flood protections drop traffic early, you may never build enough state entries to hit the non‑TCP quota condition.

4. Your traffic isn’t contributing to the state table
   Use the connection table inspection approach (above) to verify. Check Point emphasizes the state table as the DoS target for this protection. [advisories...kpoint.com], [sc1.checkpoint.com]

[PhoneBoy · Accepted solution]

@joon this seems like a reasonable approach to validate this particular protection.
I would also try this with a target reachable through the Spark appliance rather than the device itself.
If you need further assistance with this, I recommend reaching out to your local Check Point SE.

[joon · Accepted solution]

This part you mentioned

On Quantum Spark (locally managed), the UI layout differs, but the concept is the same: ensure the “Non‑TCP‑Flood‑Attack” item is:

• Enabled
• Track/Log = On (or “Detect + Log” depending on wording)
• Not overridden by a higher-level profile that disables logging

How can I activate it in Spark?
You cannot change to prevent unless you set override.
Please help me.
Thank you.

[Lesley]

Override with prevent is fine. It means that the current profile has it inactive as default. Same goes for central managed system there is also default disabled depending on the profile (default inspection or recommended inspection)

[the_rock · Accepted solution]

I would say override should be an acceptable otion.

[PhoneBoy · Accepted solution]

Setting override is exactly how you enable it.