156-587 Check Point Certified Troubleshooting Expert - R81.20 (CCTE) Questions and Answers

If you have modified kernel parameters (infwkern.conf, for example) and the gateway starts dropping traffic or behaving abnormally after a reboot, the best practice is to restore the original or a known-good configuration from backup. Then, reboot again so that the gateway loads the last known stable settings.

Option A(fw ctl set int fw1_kernel_all_disable=1) is not a standard or documented method for “undoing” all kernel tweaks.

Option B(Restore fwkem.conf from backup and reboot the gateway) is the correct and straightforward approach.

Option C(fw unloadlocal) removes the local policy but does not revert custom kernel parameters that have already been loaded at boot.

Option D(Remove all kernel parameters from fwkem.conf and reboot) might help in some cases, but you risk losing other beneficial or necessary parameters if there were legitimate custom settings. Restoring from a known-good backup is safer and more precise.

Hence, the best answer:

“Restore fwkem.conf from backup and reboot the gateway.”

Check Point Troubleshooting References

sk98339– Working with fwkern.conf (kernel parameters) in Gaia OS.

sk92739– Advanced System Tuning in Gaia OS.

Check Point Gaia Administration Guide– Section on kernel parameters and system tuning.

Check Point CLI Reference Guide– Explanation of using fw ctl, fw unloadlocal, and relevant troubleshooting commands.

 The fw ctl zdebug command is a powerful tool that can be used to collect debug messages from the kernel, clean the buffer, and automatically allocate a 1MB buffer. However, it cannot be used to debug additional modules, such as SecureXL, CoreXL, or VPN. For those modules, other commands or tools are needed, such as fwaccel dbg, fw ctl affinity, or vpn debug.

The kernel component associated with Content Awareness and data collection from contexts (often provided by the Context Management Infrastructure - CMI) is dlpda.  

According to the Check Point R81.20 Quantum Security Gateway Administration Guide, within the listing of kernel modules, dlpda is described as follows:

Exact Extract:

Module "dlpda" (Data Loss Prevention - Download Agent for Content Awareness)

The dlpda module functions as a "Download Agent for Content Awareness." This role involves collecting data necessary for the Content Awareness blade to inspect and understand the content of traffic. The Content Awareness blade works in conjunction with the Context Management Infrastructure (CMI), which provides the initial context about the traffic. The dlpda component then uses these contexts to gather the relevant data for deeper inspection and to determine if the content matches any defined data types or policies. While the guide lists it as a "Module," exam questions in the CCTE context often refer to such components involved in kernel operations as "kernel processes." The function described clearly aligns with collecting data for Content Awareness.  

Options analysis:

A. PDP (Policy Decision Point): This process is primarily associated with Identity Awareness for making access decisions based on user identity, not directly for Content Awareness data collection from CMI contexts.

B. cpemd (Check Point Endpoint Management Daemon): This daemon is related to endpoint security management and does not fit the role of a kernel process for gateway-level Content Awareness data collection.

D. CMI (Context Management Infrastructure): CMI is an infrastructure that provides contexts to various blades, including Content Awareness. It is the source of the contexts, not the kernel process that collects data based on those contexts.

Therefore, dlpda is the kernel component specifically tasked with collecting data for Content Awareness.

The input that is suitable for debugging HTTPS inspection issues is fw debug tls on TDERROR_ALL_ALL=5. This input will enable the TLS debug mode and set the debug level to 5, which is the highest level of verbosity. The fw debug command is used to control the debug features of the firewall modules, such as TLS, CPTLS, HTTP, etc. The tls option will enable the debug mode for the TLS module, which is responsible for handling the HTTPS inspection feature. The TDERROR_ALL_ALL environment variable will set the debug level to 5, which will generate the most detailed and comprehensive debug output. The debug output will be written to the $FWDIR/log/tls.elg file, whichcan be collected and analyzed with the TLSView tool1 to see the details of the HTTPS inspection process, such as certificate validation, SSL/TLS negotiation, encryption/decryption, etc. The other options are incorrect because:

fw ctl debug -m fw + conn drop cptls will enable the kernel debug mode for the firewall module, with the flags conn, drop, and cptls. The kernel debug mode will generate the kdebug.txt file in the $FWDIR/log directory, which contains information about the firewall traffic processing in the kernel. The kernel debug mode is useful for troubleshooting issues related to policy, NAT, routing, and inspection, but not for issues related to HTTPS inspection, which is handled by the TLS module in the user space2.

vpn debug cptls on will enable the IKE debug mode for the CPTLS module, which is a component of the VPN module. The IKE debug mode will generate the ike.elg and ikev2.xmll files in the $FWDIR/log directory, which contain information about the IKE negotiation, authentication, and key exchange between the VPN peers. The CPTLS module is responsible for handling the SSL/TLS encryption/decryption for the VPN traffic, but not for the HTTPS inspection traffic3.

fw diag debug tls enable is not a valid command and will not enable the TLS debug mode. The fw diag command is used to control the diagnostic features of the firewall, such as packet capture, core dump, etc. The debug option is not a valid option for the fw diag command, and the tls option is not a valid option for the debug option. References:

How to use the TLSView tool

How to debug the Firewall kernel (fw) module

How to debug VPN issues on Quantum Spark (SMB) Appliances

[fw diag - Check Point CLI Reference Card]

The System Domain of the Postgres database is a special domain that contains the configuration data of the Security Management Server and the Log Servers. It includes information such as the trusted GUI clients, the administrators, the licenses, the global properties, and the audit logs. The System Domain is not accessible by the user and can only be modified by the Check Point processes. The user modified configurations, such as network objects, policies, and rules, are stored in the User Domain of the Postgres database. The saved queries for applications are stored in the Application Domain of the Postgres database. 

The main components of Check Point’s Security Management architecture are1:

Management server: This is the central component that manages the security policy, configuration, and licenses for the Security Gateways and other Check Point devices. It also provides the SmartConsole interface for the administrators to manage the security environment.

Management database: This is the database that stores the security policy, configuration, and objects for the Security Management Server. It also stores the logs and events from the Security Gateways and other Check Point devices.

Log server: This is the component that receives and stores the logs and events from the Security Gateways and other Check Point devices. It also provides the SmartLog and SmartEvent interfaces for the administrators to view, analyze, and manage the logs and events.

Automation server: This is the component that provides the REST API and the CLI for the administrators to automate and script the security management tasks.

1: (CCTE) - Check Point Software

A core dump file is essentially a snapshot of the process's memory at the time of the crash. This snapshot includes crucial information that can help diagnose the cause of the crash. Here's why all the options are relevant:

i. Program Counter:This register stores the address of the next instruction the CPU was supposed to execute. It pinpoints exactly where in the code the crash occurred.

ii. Stack Pointer:This register points to the top of the call stack, which shows the sequence of function calls that led to the crash. This helps trace the program's execution flow before the crash.

iii. Memory management information:This includes details about the process's memory allocations, which can reveal issues like memory leaks or invalid memory access attempts.

iv. Other Processor and OS flags/information:This encompasses various registers and system information that provide context about the state of the processor and operating system at the time of the crash.

By analyzing this information within the core dump, you can often identify the root cause of the crash, such as a segmentation fault, null pointer dereference, or stack overflow.

Check Point Troubleshooting References:

While core dumps are a general concept in operating systems, Check Point's documentation touches upon them in the context of troubleshooting specific processes like fwd (firewall) or cpd (Check Point daemon). The fw ctl zdebug command, for example, can be used to trigger a core dump of the fwd process for debugging purposes.

The PDP process is the Identity server, which is a component of the Identity Awareness blade on the Security Gateway. The PDP process is responsible for collecting and managing identity information from various sources, such as Active Directory, Identity Agents, Captive Portal, Terminal Servers, and RADIUS. The PDP process also communicates with the PEP process, which is the Policy Enforcement Point, to enforce identity-based policies on the traffic passing throughthe Security Gateway1. The other options, such as Log Sifter, Captive Portal Service, andUserAuth Database, are either not related to Identity Awareness or not processes, but rather files or services. References: 1: sk93046: Identity Awareness - How to Configure

The Core Dump Manager (CDM) is a utility that helps manage core dump files on Check Point systems. Its main functions include:  

Limiting file size and number:CDM can be configured to limit the size of individual core dump files and the total amount of disk space used for core dumps. This prevents core dumps from filling up valuable disk space.  

Compression:CDM can compress core dump files to reduce their storage size. This is particularly helpful when dealing with large core dumps.  

Process filtering:CDM allows you to specify which processes should be allowed to generate core dumps. This can help prevent unnecessary core dumps from being created.  

Remote collection:CDM can be configured to send core dump files to a remote server for analysis. This is useful in environments where direct access to the system generating the core dump is limited.

By using CDM, you can effectively manage core dump files and ensure that they are not overwhelming your system's resources.

The doctor-log script is a tool that provides information about the logging system and helps to identify and troubleshoot common issues. The script runs automatically every night and generates a report that contains the following information:

Current and daily average logging rates: This shows how many logs are being generated and received by the log server per second. It can help to monitor the logging performance and identify any spikes or drops in the logging rate.

Indexing status: This shows the status of the log indexing process, which enables faster and more efficient log searches. It can help to identify any issues with the indexing system, such as delays, failures, or errors.

Size: This shows the size of the log files and the disk space used by the logging system. It can help to manage the disk space and plan for log rotation and backup.

The doctor-log script also provides some troubleshooting tips and repair options for common logging issues, such as corrupted log files, missing log indexes, or low disk space. The script can be run manually or scheduled to run at a specific time. The script output can be viewed in the SmartConsole or in the log server file system.

To troubleshoot Identity Awareness issues related to user identification and Access Role application, you need to enable debugging for both Identity Collectors (IDC) and Identity Providers (IDP). The command pdp debug set IDC all IDP all on the gateway achieves this.

Here's why this is the correct answer and why the others are not:

A. on the gateway: pdp debug set IDC all IDP all:This correctly enables debugging for all Identity Collectors and Identity Providers, allowing you to see detailed logs and messages related to user identification and Access Role assignment. This helps pinpoint issues with user mapping, authentication, or authorization.

B. on the gateway: pdp debug set AD all and IDC all:This command only enables debugging for Active Directory (AD) as an Identity Provider and all Identity Collectors. It might miss issues related to other Identity Providers if they are in use.

C. on the management: pdp debug on IDC all:This command has two issues. First, it should be executed on the gateway, not the management server, as the gateway is responsible for user identification and policy enforcement. Second, it only enables debugging for Identity Collectors, not Identity Providers.

D. on the management: pdp debug set all:While this command might seem to enable debugging for everything, it's not specific enough for Identity Awareness troubleshooting. It might generate excessive logs unrelated to the issue and make it harder to find the relevant information.

Check Point Troubleshooting References:

Check Point Identity Awareness Administration Guide:This guide provides detailed information about Identity Awareness components, configuration, and troubleshooting.

Check Point sk113963:This article explains how to troubleshoot Identity Awareness issues using debug commands and logs.

Check Point R81.20 Security Administration Guide:This guide covers general troubleshooting and debugging techniques, including the use of pdp debug commands.

The STAT column in the output of the cpwd_admin list command shows the status of the monitored process. The possible values are E for established, meaning that the process is running, or T for terminated, meaning that the process is not running. The STAT column is useful for quickly checking if any critical process has crashed or failed to start. If the value is T, the process should be restarted and the reason for the termination should be investigated. The STAT column does not show the Watch Dog name, the number of times the process was started, or the monitoring method of the Watch Dog. 

The Resource Application Daemon (RAD) is a critical component in Check Point’s Application Control and URL Filtering blades, responsible for processing and categorizing web traffic. The configuration file $FWDIR/conf/rad_settings.C on the Security Gateway defines settings related to RAD’s operation.

Option A: Incorrect. The rad_settings.C file does not store entitlement information for Application Control or URL Filtering. Entitlements are managed by the Security Management Server and stored in licensing databases, not in this file.

Option B: Incorrect. The rad_settings.C file does not specify how the Security Gateway communicates with the Security Management Server’s RAD service. Communication settings are typically handled by SIC (Secure Internal Communication) and other configuration files, such as $FWDIR/conf/fwopsec.conf.

Option C: Correct. The rad_settings.C file contains proxy settings for the RAD daemon, such as HTTP proxy configurations used for accessing external services (e.g., Check Point’s online URL Filtering database). This is critical when the Gateway requires a proxy to reach external resources for URL categorization.

Option D: Incorrect. Hostname settings for the online application detection engine are not stored in rad_settings.C. These are typically managed by the Application Database (application_db.C) or resolved via DNS.

 The CPD process controls logging on the Security Management Server or the Log Server. It is responsible for receiving logs from the Security Gateways, storing them in the log files, and forwarding them to the SmartLog and SmartEvent servers. It also handles the communication with the SmartConsole clients and the CPM process. The CPD process runs on the Security Management Server or the Log Server as part of the Management High Availability module.

The simplest and most efficient way to check all dropped packets in real time is C. fw ctl zdebug + drop in expert mode. This command is a shortcut command that sets the kernel debug flags to a predefined value and prints the debug output to the standard output. It is useful for general debugging of common issues, such as traffic drops, NAT, VPN, or clustering. It has a small buffer size and does not require additional steps to start or stop the debugging. However, it has some limitations, such as it cannot be used with SecureXL, it cannot filter the output by chain modules, and it cannot save the output to a file12.

The other commands are not as simple or efficient as the fw ctl zdebug + drop command. The command tail -f $FWDIR/log/fw.log |grep drop in expert mode will only show the drops that are logged in the fw.log file, which may not include all the drops that occur in the kernel. The command cat /dev/fw1/log in expert mode will show the raw binary data of the kernel debug buffer, which is not human-readable and may contain irrelevant information. The command Smartlog will show the drops that are indexed and stored in the SmartEvent database, which may not be in real time and may depend on the log server performance12.

1: https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_AdvancedTechnicalReferenceGuide/html_frameset.htm  2: https://www.checkpoint.com/downloads/training/DOC-Training-Data-Sheet-CCTE-R81.10-V1.0.pdf

The Check Point R81.20 Gaia Administration Guide describes fw ctl zdebug as a key troubleshooting tool for real-time packet analysis, particularly for drops. The CCTE R81.20 course emphasizes using fw ctl zdebug for kernel-level debugging, including monitoring dropped packets.

For precise details, refer to:

Check Point R81.20 Gaia Administration Guide, section on “fw ctl zdebug” (available via Check Point Support Center).

CCTE R81.20 Courseware, which covers advanced troubleshooting techniques for packet drops (available through authorized training partners).

cpsemd is the process responsible for logging into the SmartEvent GUI. Therefore, you need to check the status of this process and debug it, if necessary. Usually, the issue withthe cpsemd process is that it is crashing, or not coming up. What causes this process to crash or not come up is that the PostgreSQL database is down. Therefore, in order to run the cpsemd process successfully, you need to run the PostgreSQL database successfully.

The correct statement explaining the differences between the two procedures for debugging in the firewall kernel is D. (i) is used for general debugging, has a small buffer and is a quick way to set kernel debug flags to get an output via command line whereas (ii) is useful when there is a need for detailed debugging and requires additional steps to set the buffer and get an output via command line.

The command fw ctl zdebug is a shortcut command that sets the kernel debug flags to a predefined value and prints the debug output to the standard output. It is useful for general debugging of common issues, such as traffic drops, NAT, VPN, or clustering. It has a small buffer size and does not require additional steps to start or stop the debugging. However, it has some limitations, such as it cannot be used with SecureXL, it cannot filter the output by chain modules, and it cannot save the output to a file12.

The command fw ctl debug is a command that allows the administrator to set the kernel debug flags to a custom value and specify the chain modules to debug. It is useful for detailed debugging of specific issues, such as policy installation, CoreXL, or Identity Awareness. It has a larger buffer size and can save the output to a file. However, it requires additional steps to start and stop thedebugging, such as setting the buffer size, clearing the buffer, dumping the buffer, and resetting the debug flags12.

The command fw ctl kdebug is a command that is used in conjunction with fw ctl debug to dump the kernel debug buffer to the standard output or to a file. It is part of the procedure (ii) for detailed debugging in the firewall kernel12.

The other statements are not correct or relevant for explaining the differences between the two procedures for debugging in the firewall kernel. The command fw ctl zdebug can be used to debug more than just the access control policy, and the command fw ctl debug/kdebug can be used to debug more than just the unified policy. Both commands can be used on both the Security Gateway and the Security Management Server, depending on the issue to be debugged12.