Hello Checkpoint Community,
I’m thrilled to share more findings from my ongoing research on Checkpoint firewall logs!
I’ve been investigating a confusing issue with the "Drop" label in logs when the firewall handles URG flags
I’ve found something that confuses users like someone who are new to this
I’ll explain my findings step by step, share my analysis, and propose a new improvement for Checkpoint to make logs easier to understand. I hope you’ll join me in discussing this!
What I’m Seeing in the Logs:
TCP Flags
I have a log for traffic on port 1525 (service "sqlnet2-1525") from a computer (1x.x.x.x) to a server (y.y.y.y). The log says:
- "sqlnet2-1525 Traffic Dropped from x.x.x.x:63470 to y.y.y.y due to TCP segment with urgent pointer. Urgent data indication was stripped. Please refer to sk36869."
- It also mentions "Streaming Engine: TCP Urgent Data Enforcement" and says the severity is "Informational."
- Due to TCP segment with urgent pointer. Urgent data indication was stripped. Please refer to sk36869."
Drop and accept
With lots of "Log" and "Connection" entries. Some of these are about port 1525 so some are accept connection and some are drop logs.
The fw ctl zdebug + drop command, showing drops at the kernel level. It mentions drops due to rule 93 in the "Firewall Policy Network" layer, involving my server (y.y.y.y) and a other IP address (z.z.z.z) but not also specifically for port 1525.
My Step-by-Step Research Process:
Understanding the Basics:
- A TCP segment is a small package of data, and the URG flag is like a "rush" sticker telling the server to handle some data quickly.
- Log says the firewall removed the "rush" sticker (stripped the URG flag) for port 1525 and let the rest of the package go to the server.
Checking the Log Details:
- But the log description says "Traffic Dropped," which confused me. Does this mean the whole package was blocked, or just the "rush" sticker was removed?
Reading sk36869:
- I read the Checkpoint knowledge article sk36869, which explains that the default behavior for most ports (like 1525, not 21, 23, or 513) is to strip the URG flag, not drop the traffic. Ports 21 (FTP), 23 (TELNET), and 513 (RLOGIN) allow the URG flag by default.
Running fw ctl zdebug + drop:
- To see if the firewall was dropping traffic at a deeper level, I ran fw ctl zdebug + drop. The output showed drops due to rule 93, like "y.y.y.y:1866 -> z.z.z.z:8746 dropped by fw_send_log_drop Reason: Rulebase drop - on layer 'Firewall Policy Network' rule 93."
- These drops involved my server (y.y.y.y), but they weren’t for port 1525 or URG flags—they were due to a different rule.
No URG-Specific Drops:
- There’s no indication in the zdebug output that the firewall is dropping traffic on port 1525 specifically because of the URG flag (e.g., via "URGENT_DATA_RESET"). May be the stripping action in the log is handled at a higher level (by the Streaming Engine), not necessarily reflected as a kernel-level drop.
Putting It All Together:
- Firewall is stripping the URG flag on port 1525 (default behavior), not dropping the whole traffic,
-
"URGENT_DATA_RESET" (which would drop URG-flagged traffic) isn’t enabled by default, as my log shows stripping, not dropping, and zdebug doesn’t mention URG-related drops.
- The source (x.x.x.x) is sending URG flags often, and the firewall logs each time it strips them.
Testing Another Port (1524):
- I added the Trinoo service on port 1524 and checked the logs. I saw the same URG flag stripping issue, with both "Accept" and "Drop" actions, confirming the problem isn’t just for port 1525.
Why This Matters for Everyone:
This issue isn’t just about my firewall—it could affect many Checkpoint users. If the firewall strips URG flags on ports like 1524 and 1525 and calls it "Traffic Dropped," users might think their traffic is blocked when it’s not. This could lead to:
- Wasted time troubleshooting: Someone spent hours figuring out the traffic wasn’t really dropped.
- Misdiagnosis: Someone might think their app (like "signet2" or "Trinoo") is failing due to a block, when it’s just the URG flag being removed.
- Security risks: If users ignore these logs thinking they’re harmless, they might miss real issues, like why the source is sending so many URG flags.
My Proposed Improvement: Replace "Drop" with "Warning"
I’ve noticed a big problem with the logs, and I have an idea to make them better:
The Problem: The log says "Traffic Dropped," but the action is only stripping the URG flag, not blocking the whole traffic. The "Informational" severity also doesn’t match "Dropped," which makes me think the package was stopped when it wasn’t. This is confusing, especially for new users like me who might panic or misunderstand what’s happening.
My Suggestion: I think Checkpoint should change the log description from "Traffic Dropped" to "Traffic Warning" or "URG Flag Stripped Warning" when the firewall is just removing the URG flag. "Warning" sounds gentler and matches the "Informational" severity, letting me know it’s not a full block but something to watch.
Why It’s Better: A "Warning" label would be clearer and less scary. It would tell me the firewall is handling the "rush" sticker safely without stopping the package, so I don’t worry about my "signet2" app failing. This small change could help everyone understand logs better and save time troubleshooting.
I came up with this idea after studying my logs, reading sk36869, and running fw ctl zdebug + drop. I think it’s a breakthrough because it addresses a real confusion point, and I’d love to see Checkpoint consider it!
Please Share Your Thoughts and correct me if I am wrong!
Regards
