- Products
- Learn
- Local User Groups
- Partners
-
More
Join Us for CPX 360
23-24 February 2021
Important certificate update to CloudGuard Controller, CME,
and Azure HA Security Gateways
How to Remediate Endpoint & VPN
Issues (in versions E81.10 or earlier)
IDC Spotlight -
Uplevel The SOC
Important! R80 and R80.10
End Of Support around the corner (May 2021)
I see just too much of "fw ctl zdebug..." flying around these days. To explain my issue with this practice, I have posted an entry in my blog:
https://checkpoint-master-architect.blogspot.ch/2017/11/kernel-debug-best-practices-or-why-fw.html
Feel free to read and comment
debug kernel_debug best practices
I've used zdebug a lot and never got into trouble. It also helped me fixing issues. Perhaps I was lucky.
On the other hand...more often I had to issue specific debug commands (received from TAC) that really did make things worse on production environments.
I understand your concerns about debugging but I guess you need to be carefull with every debug command. With or without 'z' in front of it.
So in theory if there was ‘fw ctl lzdebug’ (“l” for Loukine) macro , what would u have it do ?
Do not get me wrong, as internal R&D tool, zdebug is just fine. My problem is that you guys do not discourage using it on the field and even post SK articles of HOWTO kind to promote it.
My issues are:
Fixing the buffer is no brainer, Tamir could fix it with a blink of an eye. The other two points are a bit more tricky. Ideally, if you really want CP users to run debug in production (which is questionable by itself), do a GUI based tool. Because, if you don't someone else will. Actually, there is already something for the matter: Check Point debugging GUI
Valeri Loukine wrote:
Ideally, if you really want CP users to run debug in production (which is questionable by itself), do a GUI based tool.
like Packet-Mode search and SmartLog search?
When I think about it, yes. SmartConsole extension with particular limited kernel debug abilities would be an ideal solution. You can call it ldebug, where L stands for "light"
so can we open this discussion to at which cases would you choose to kernel debug rather than search a log or a matched rule? just rules with Track=none or other cases?
There is not much to discuss. kernel debug should be only employed when other means of troubleshooting, mentioned above included, are exhausted. This is my main personal issue with zdebug: people use it instead of other means to find their config errors.
However, there are troubleshooting scenarios, where log and policy search may not produce conclusive results, if any. In these cases kernel debug, if performed in educated and controlled manner, might help
So what you're saying is you're against the idea of putting fw ctl zdebug on a t-shirt
As part of wider subject, yes. why should check point promote a debug command in the first place, I might ask? Some people say, a good product does not need to be debugged on the field after being released to GA 🙂
I'd much rather see this T-Shirt instead
I guess it has more to do with the Geek factor.
I've used zdebug a lot and never got into trouble. It also helped me fixing issues. Perhaps I was lucky.
On the other hand...more often I had to issue specific debug commands (received from TAC) that really did make things worse on production environments.
I understand your concerns about debugging but I guess you need to be carefull with every debug command. With or without 'z' in front of it.
Absolutely correct, Rick. To execute kernel debug, one needs to understand and appreciate the implications. However, using zdebug shortcut saves you all those efforts of understanding and appreciation.
About CheckMates
Learn Check Point
Advanced Learning
WELCOME TO THE FUTURE OF CYBER SECURITY