> Source: [sk101570](https://support.checkpoint.com/results/sk/sk101570) # sk101570 - Some fields in logs on 3rd party LEA OPSEC client show "*** Confidential ***" | Property | Value | |----------|-------| | Solution ID | sk101570 | | Date Created | 2014-07-14 | | Last Modified | 2024-05-21 | | Technical Level | General | | Products | Security Management Server, Multi-Domain Security Management Server | | Versions | R81.20, R81.10 (EOS), R81 (EOS) | ## Solution ### Introduction This article describes different scenarios when some fields in logs on 3rd party LEA OPSEC client shown "`*** Confidential ***`". Each Scenario has its own cause and solution. **Table of Contents:** 1. "User" fields and "Machine" fields show "`*** Confidential ***`" in logs for each user/machine obtained via Identity Awareness blade 2. "User" fields show "`*** Confidential ***`" in logs due to incorrect SIC name provided by the 3rd party client 3. "User" fields show "`*** Confidential ***`" in logs when connection to OPSEC server is on non-authenticated port (clear port) 4. On ArcSight LEA OPSEC client, some fields in the logs show "`*** Confidential ***`" Show the Entire Article ### (1) "User" fields and "Machine" fields show "`*** Confidential ***`" in logs for each user/machine obtained via Identity Awareness blade {#Scenario 1} **Symptoms:** * "User" fields and "Machine" fields show "`*** Confidential ***`" for each user/machine obtained via Identity Awareness blade in logs on 3rd party LEA OPSEC client. Show / Hide solution **Issue ID:** * 00815453 **Cause:** > Confidentiality in user fields is an expected behavior and by design. > Starting in R75.20, certain fields are deliberately set with permission requirements in order to prevent unauthorized clients from accessing confidential log fields of any type (e.g., for both DLP and Application Control). > Therefore, the information in these fields is obfuscated. **Solution:** > [Contact Check Point Support](http://www.checkpoint.com/support-services/contact-support/index.html) to get a Hotfix for this issue. > A Support Engineer will make sure the Hotfix is compatible with your environment before providing the Hotfix. > For faster resolution and verification, please collect [CPinfo file](http://supportcontent.checkpoint.com/solutions?id=sk92739) from each Security Management Server / Multi-Domain Security Management Server / Log Server involved in the case. > > 1. Hotfix has to be installed on *each* involved ***Security Management Server / Log Server / Multi-Domain Security Management Server / Multi-Domain Log Server***. > > **Notes:** > * In Management HA environment, this procedure must be performed on *both* Management Servers / Log Servers. > * In Multi-Domain Security Management Server environment, the hotfix must be installed on *all* MDSs and MLMs. > 2. Procedure: > > * Using CPUSE on Gaia OS: > > Refer to [sk92449: CPUSE - Gaia Software Updates (including Gaia Software Updates Agent)](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk92449#How to work with CPUSE): > * Section "[(4-A-c)](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk92449#How to work with CPUSE - How to download and import a CPUSE package - Import instructions for Offline procedure - Gaia Portal)" / "[(4-A-d)](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk92449#How to work with CPUSE - How to download and import a CPUSE package - Import instructions for Offline procedure - Gaia Clish)" - refer to import instructions for *Offline procedure* > * Section "[(4-B-a)](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk92449#How to work with CPUSE - How to install a CPUSE package - Installing a Hotfix package / Minor Version package)" - refer to installation instructions for *Hotfixes* > > **Note:** Reboot is required. > * Using Legacy CLI on Gaia/SecurePlatform/IPSO OS: > > 1. Transfer the hotfix package to the machine (into some directory, e.g., */some_path_to_fix/*). > > 2. Unpack and install the hotfix package: > > ***\[Expert@HostName:0\]# cd /some_path_to_fix/*** > ***\[Expert@HostName:0\]# tar -zxvf fw1_wrapper_\.tgz*** > ***\[Expert@HostName:0\]# ./fw1_wrapper_\*** > **Note:** The script will stop all of Check Point services (*cpstop*) - read the output on the screen. > 3. Reboot the machine. > > 3. In the OPSEC application object in SmartDashboard, go to the "LEA Permissions" tab and select the "Show all log fields" option. > > Note: If the OPSEC application object does not exist, then create it (in the left-hand menu of SmartDashboard, above Network Objects, choose "Servers and OPSEC" and create a new OPSEC application). > *Example* : > ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk101570/11506250421.png) > 4. Enable the *new permission* for DLP Logs in the Permissions Profile: > > This permission lets an administrator: a) See all fields of DLP logs in SmartView Tracker; b) See the actual message of the incident; c) Send or discard quarantined user e-mails from SmartView Tracker. > 1. Connect with SmartDashboard to the Security Management Server / Domain Security Management Server. > > 2. Go to *Manage* menu - click on *Permissions Profiles...*: > > [![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk101570/Manage_menu.png)](https://sc1.checkpoint.com/sc/SolutionsStatics/sk101570/Manage_menu.png "Click the image to see it in full size in a new tab/window") > 3. Select the existing profile and click on *Edit...* button, or create a new profile (click on *New...* button - select *Permissions Profile...*). > > 4. Enable the new permission for DLP Logs: > > * If you selected the permissions *Read/Write All* , then select a new checkbox "*Read DLP logs including confidential fields and incidents*". > > Example: > [![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk101570/Permissions_Profile_ReadWriteAll.png)](https://sc1.checkpoint.com/sc/SolutionsStatics/sk101570/Permissions_Profile_ReadWriteAll.png "Click the image to see it in full size in a new tab/window") > * If you selected the permissions *Customized* , then click on *Edit...* button - go to *Monitoring and Logging* pane and select a new checkbox "*DLP Logs including confidential fields*". > > Example: > [![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk101570/Permissions_Profile_Customized.png)](https://sc1.checkpoint.com/sc/SolutionsStatics/sk101570/Permissions_Profile_Customized.png "Click the image to see it in full size in a new tab/window") > 5. Go to *Policy* menu - click on *Install Database...* > > 6. Make sure the the OPSEC connection port is configured in the *$FWDIR/conf/fwopsec.conf* file as the *auth_port* in the following line: > > *lea_server auth_port \* > If not, then edit the file accordingly and restart Check Point services with *cpstop;cpstart* commands. ### (2) "User" fields show "`*** Confidential ***`" in logs due to incorrect SIC name provided by the 3rd party client {#Scenario 2} **Symptoms:** * "User" fields show "`*** Confidential ***`" in logs on 3rd party LEA OPSEC client. * OPSEC object is assigned to a Permission Profile with "Read/Write All" permissions. * Debug of FWD daemon (per [sk86321](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk86321)) on Check Point Security Management Server / Log Server shows in *$FWDIR/log/lea_session.\.elg\** files: * ` [lea_session.`*PID*` ...]@HostName[Date Time] field dst_user_name permissions = 4 permissions_mask = 0` ` [lea_session.`*PID*` ...]@HostName[Date Time] field dst_machine_name permissions = 4 permissions_mask = 0` ` [lea_session.`*PID*` ...]@HostName[Date Time] field user permissions = 4 permissions_mask = 0 ` * ` [lea_session.`*PID*` ...]@HostName[Date Time] lea_server_init_permissions: peer_sic_name is cn=XXX` ` [lea_session.`*PID*` ...]@HostName[Date Time] lea_server_init_permission: fwopsec object not found ` Show / Hide solution **Cause:** > When an OPSEC object is assigned to a Permission Profile, the 3rd party client's SIC name is requested by the Security Management Server. > If, for some reason, the SIC name provided by the 3rd party client to the Security Management Server is wrong, then the Security Management Server will treat the client as if it has no permissions at all. > Therefore, the information in these fields is obfuscated. **Solution:** > 1. On the 3rd party OPSEC LEA client - check the SIC name in the relevant configuration file (refer to OPSEC vendor documentation). > > 2. On the Security Management Server /Domain Management Server - check the SIC name created for the 3rd party OPSEC LEA client (in SmartDashboard, go to *Manage* menu - click on *Servers and OPSEC Applications...* - select the involved 3rd party LEA OPSEC application - click on *Edit...* - go to *General* tab - refer to *Secure Internal Communication* section - refer to *DN* field). > > 3. Compare both SIC names: > > * the one defined on the 3rd party OPSEC LEA client > * the one defined on the Security Management Server /Domain Management Server > > If the SIC names are not identical, then the Management Server will deny any permission for the 3rd party OPSEC LEA client. > > In such case, correct the SIC name defined on the 3rd party OPSEC LEA client to match the SIC name defined on the Security Management Server /Domain Management Server. > > Note: The SIC names are case-sensitive. ### (3) "User" fields show "`*** Confidential ***`" in logs when connection to OPSEC server is on non-authenticated port (clear port) {#Scenario 3} **Symptoms:** * "User" fields show "`*** Confidential ***`" in logs on 3rd party LEA OPSEC client. * Connection to OPSEC server is on non-authenticated port (clear port). The *$FWDIR/conf/fwopsec.conf* file on the Log Server is configured to connect on clear port: ``` lea_server auth_port 0 lea_server port 18185 ``` Show / Hide solution **Issue ID:** * 01533783 **Cause:** > In R76 and above, some information in logs that were retrieved over clear non-authenticated port is considered confidential. > Therefore, the information in these fields is obfuscated. **Solution:** It is possible to disable confidentiality on clear non-authenticated connection using a Check Point environment variable ***LEA_CLEAR_DISABLE_CONFIDENTIALITY*** . **Note:** Working on a clear port will prevent using Permissions Profile in LEA OPSEC application in order to manage the information displayed to users. > 1. **For R76 / R77 / R77.10 / R77.20 / R80 only - Install a Hotfix on the Log Server:** > > 1. Hotfix has to be installed on ***machine that acts as Log Server***. > > **Notes:** > * In Management HA environment, this procedure must be performed on *both* Management Servers. > * In Multi-Domain environment, this procedure must be performed on the Multi-Domain Security Management Server and Multi-Domain Log Server. > 2. Procedure: > > * Using CPUSE on Gaia OS: > > Refer to [sk92449: CPUSE - Gaia Software Updates (including Gaia Software Updates Agent)](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk92449#How to work with CPUSE): > * Section "[(4-A-c)](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk92449#How to work with CPUSE - How to download and import a CPUSE package - Import instructions for Offline procedure - Gaia Portal)" / "[(4-A-d)](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk92449#How to work with CPUSE - How to download and import a CPUSE package - Import instructions for Offline procedure - Gaia Clish)" - refer to import instructions for *Offline procedure* > * Section "[(4-B-a)](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk92449#How to work with CPUSE - How to install a CPUSE package - Installing a Hotfix package / Minor Version package)" - refer to installation instructions for *Hotfixes* > > **Note:** Reboot is required. > * Using Legacy CLI on Gaia/SecurePlatform/IPSO OS: > > 1. Transfer the hotfix package to the machine (into some directory, e.g., */some_path_to_fix/*). > > 2. Unpack and install the hotfix package: > > ***\[Expert@HostName:0\]# cd /some_path_to_fix/*** > ***\[Expert@HostName:0\]# tar -zxvf fw1_wrapper_\.tgz*** > ***\[Expert@HostName:0\]# ./fw1_wrapper_\*** > **Note:** The script will stop all of Check Point services (*cpstop*) - read the output on the screen. > 3. Reboot the machine. > > 2. **For R76 and above - Disable the confidentiality on clear connection:** > > The behavior is controlled through environment variable for operating system - ***LEA_CLEAR_DISABLE_CONFIDENTIALITY***: > * To *disable* the confidentiality on clear connection, set the value of this variable to 1 (one). > * To *enable* the confidentiality on clear connection, set the value of this variable to 0 (zero), or unset this environment variable completely. > > In order to set the value of this variable *permanently* , it has to be added manually to **all** Check Point shell scripts that define environment variables for the given operating system: > * Show / Hide instructions for Security Management Server R80.X, which runs on Gaia / Linux OS > 1. In the ***$CPDIR/tmp/.CPprofile.sh*** script: > > Add this line: > ***_cpprof_add LEA_CLEAR_DISABLE_CONFIDENTIALITY "1" 0 0*** > Under this line: > *_cpprof_add DONT_LOAD_FWM_OBJECTS "1" 0 0* > 2. In the ***$CPDIR/tmp/.CPprofile.csh*** script: > > Add this line: > ***setenv LEA_CLEAR_DISABLE_CONFIDENTIALITY 1*** > Under this line: > *setenv INFODIR "/opt/CPinfo-10"* > 3. Restart all Check Point services: > > ***\[Expert@HostName\]# cpstop ; cpstart*** > 4. Verify that the variable was applied: > > ***\[Expert@HostName\]# echo $LEA_CLEAR_DISABLE_CONFIDENTIALITY*** > Output should show "1". If it does not, then reboot the machine. > > **Note:** To unset this variable permanently, remove it from the above shell scripts and restart Check Point services with "*cpstop;cpstart*" commands. > >
> > * Show / Hide instructions for Security Management Server R7x, which runs on Gaia / SecurePlatform / Linux / IPSO OS > 1. In the ***$CPDIR/tmp/.CPprofile.sh*** script: > > Add this line: > ***LEA_CLEAR_DISABLE_CONFIDENTIALITY=1 ; export LEA_CLEAR_DISABLE_CONFIDENTIALITY*** > Under this line: > *INFODIR=/opt/CPinfo-10 ; export INFODIR* > 2. In the ***$CPDIR/tmp/.CPprofile.csh*** script: > > Add this line: > ***setenv LEA_CLEAR_DISABLE_CONFIDENTIALITY 1*** > Under this line: > *setenv INFODIR "/opt/CPinfo-10"* > 3. Restart all Check Point services: > > ***\[Expert@HostName\]# cpstop ; cpstart*** > 4. Verify that the variable was applied: > > ***\[Expert@HostName\]# echo $LEA_CLEAR_DISABLE_CONFIDENTIALITY*** > Output should show "1". If it does not, then reboot the machine. > > **Note:** To unset this variable permanently, remove it from the above shell scripts and restart Check Point services with "*cpstop;cpstart*" commands. > >
> > * Show / Hide instructions for Multi-Domain Security Management Server R8x, which runs on Gaia / Linux OS > 1. Go to context of MDS: > > ***\[Expert@HostName\]# mdsenv > \[Expert@HostName\]# mcd*** > 2. In ***$MDSDIR/scripts/mdsstart_customer*** script: > > Add this line: > ***setenv LEA_CLEAR_DISABLE_CONFIDENTIALITY 1*** > Above the last line: > *exit 0* > 3. In ***$CPDIR/tmp/.CPprofile.sh*** (*/var/opt/CPshrd-Rxx/tmp/.CPprofile.sh*) script: > > Add this line: > ***_cpprof_add LEA_CLEAR_DISABLE_CONFIDENTIALITY "1" 0 0*** > Under this line: > *_cpprof_add DONT_LOAD_FWM_OBJECTS "1" 0 0* > 4. In ***$CPDIR/tmp/.CPprofile.csh*** (*/var/opt/CPshrd-Rxx/tmp/.CPprofile.csh*) script: > > Add this line: > ***setenv LEA_CLEAR_DISABLE_CONFIDENTIALITY 1*** > Under this line: > *setenv INFODIR "/opt/CPinfo-10"* > 5. Restart all Check Point services on Multi-Domain Security Management Server: > > ***\[Expert@HostName\]# mdsstop > \[Expert@HostName\]# mdsstart*** > 6. Verify that the variable was applied - run this command in the context of each Domain: > > ***\[Expert@HostName\]# echo $LEA_CLEAR_DISABLE_CONFIDENTIALITY*** > Output should show "1" > > **Note:** To unset this variable permanently, remove it from the above shell scripts and restart Check Point services with "*mdsstop;mdsstart*" commands. ### (4) On ArcSight LEA OPSEC client, some fields in the logs show "`*** Confidential ***`" {#Scenario 6} **Symptoms:** * On HPE Security ArcSight client, some fields in the logs show "`*** Confidential ***`". * LEA Permissions in the ArcSight LEA OPSEC client object are set either to "*Show all log fields* ", or "*According to Permissions Profile* " (in SmartDashboard, go to *Manage* menu - click on *Servers and OPSEC Applications...* - select the ArcSight LEA OPSEC application - click on *Edit...* - go to *LEA Permissions* tab - select the permission - click on OK - go to *Policy* menu - click on *Install Database...* - select all objects) Show / Hide solution **Cause:** > Problem with the SIC certificate as reported by ArcSight. **Solution:** > Compare the results from ***lea_session.\.elg\**** files and the output of ***cpca_client lscert*** command on the Security Management Server: > > 1. Start the debug the FWD daemon per [sk86321](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk86321). > > 2. Generate traffic, for which logs should be created and sent to ArcSight LEA OPSEC client. > > 3. Stop the debug the FWD daemon per [sk86321](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk86321). > > 4. Analyze the ***$FWDIR/log/lea_session.\.elg\**** files. > > Search for: > `lea_server_init_permissions: 3rd-pty client detected` > ` lea_server_init_permissions: peer_sic_name is `**CN=xxxxx ,O=xxxxx..xxxx** > 5. List the known certificates: > > ***\[Expert@HostName:0\]# cpca_client lscert*** > > Output should be similar to: > ` CN=xxxxx_OPSEC,O=xxxxx...xxxx` > ` CN=ArchSight,O= O=xxxxx...xxxx` > ` CN=arcsight,O= O=xxxxx...xxxx ` > 6. If the ***CN*** values do *not* match, then contact HP Support for *HPE Security ArcSight*. --- # Agent Instructions This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products. ## Navigating This Knowledge Base - **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt) - **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml) - **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}` - **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content