Imperva Cyber Community

Hello Revn,

Thank you for your suggestions.

We have reviewed the points you mentioned and would like to share our observations:

1. Gateway Connectivity: We checked the gateway status and connectivity during the alert period. The PCAP utilization remained well below the configured threshold. The quota is currently set to 50 GB, and the PCAP files did not consume even 10 GB

2. Data Compression: As recommended, we have enabled "Reducing Traffic Using Data Compression" by configuring the Compression Snappy switch in the Agent Advanced Configuration.
   

3. AMR Rules: We have already created and implemented AMR/exclusion rules for the agent to minimize unnecessary traffic. However, despite these changes, we have not observed any significant improvement, and the issue continues to occur intermittently.

Could you please review the above findings and advise if there are any additional checks, logs, or troubleshooting steps that we can perform? Any guidance or recommendations would be greatly appreciated, as we are trying to identify the root cause and reach a permanent resolution.

Thank you for your support.

1. Is /opt/imperva located on a dedicated filesystem, or is it shared with other applications under /opt? If other apps are using the same filesystem and their logs are stored in /opt, there is a possibility that space could become insufficient at times.
2. I noticed that the database in use is PostgreSQL. Could you please clarify whether it is being monitored in kernel mode or user-space mode? as i observed few missing parameters for SSL traffic capture  , are you able to observe PostgreSQL traffic, including SSL/TLS encrypted connections?
3. Please check the high-volume traffic in "Agent Traffic Distribution" under Handle outbound" for AMR fine-tuning.

Hello Revn,

Thank you for your suggestions.

We have reviewed the points you mentioned and would like to share our observations:

1. Gateway Connectivity: We checked the gateway status and connectivity during the alert period. The PCAP utilization remained well below the configured threshold. The quota is currently set to 50 GB, and the PCAP files did not consume even 10 GB

2. Data Compression: As recommended, we have enabled "Reducing Traffic Using Data Compression" by configuring the Compression Snappy switch in the Agent Advanced Configuration.
   

3. AMR Rules: We have already created and implemented AMR/exclusion rules for the agent to minimize unnecessary traffic. However, despite these changes, we have not observed any significant improvement, and the issue continues to occur intermittently.

Could you please review the above findings and advise if there are any additional checks, logs, or troubleshooting steps that we can perform? Any guidance or recommendations would be greatly appreciated, as we are trying to identify the root cause and reach a permanent resolution.

Thank you for your support.

Hi Revn,

Thank you for your suggestions and for taking the time to review the issue. We appreciate your valuable inputs.

Please find our observations below:

1. /opt Filesystem Utilization
   The /opt filesystem is shared with other applications as well. However, we have verified the available capacity, and there is currently more than 100 GB of free space available, so disk space does not appear to be a concern at this time.

2. PostgreSQL Monitoring and SSL Traffic Capture
   The PostgreSQL database is currently being monitored in user-space mode. Regarding the missing parameters for SSL traffic capture, could you kindly share any relevant documentation or references? This will help us review the configuration and verify whether any required parameters are missing.

3. Agent Traffic Distribution (Handle Outbound)
   We have reviewed the high-volume traffic under "Agent Traffic Distribution" → "Handle Outbound". During our analysis, we identified that a few exclusions required for AMR fine-tuning were missing. We have now applied the necessary AMRs based on the outbound agent traffic observations.

Thank you once again for your suggestions and support.

1. Is /opt/imperva located on a dedicated filesystem, or is it shared with other applications under /opt? If other apps are using the same filesystem and their logs are stored in /opt, there is a possibility that space could become insufficient at times.
2. I noticed that the database in use is PostgreSQL. Could you please clarify whether it is being monitored in kernel mode or user-space mode? as i observed few missing parameters for SSL traffic capture  , are you able to observe PostgreSQL traffic, including SSL/TLS encrypted connections?
3. Please check the high-volume traffic in "Agent Traffic Distribution" under Handle outbound" for AMR fine-tuning.

Hello Revn,

Thank you for your suggestions.

We have reviewed the points you mentioned and would like to share our observations:

1. Gateway Connectivity: We checked the gateway status and connectivity during the alert period. The PCAP utilization remained well below the configured threshold. The quota is currently set to 50 GB, and the PCAP files did not consume even 10 GB

2. Data Compression: As recommended, we have enabled "Reducing Traffic Using Data Compression" by configuring the Compression Snappy switch in the Agent Advanced Configuration.
   

3. AMR Rules: We have already created and implemented AMR/exclusion rules for the agent to minimize unnecessary traffic. However, despite these changes, we have not observed any significant improvement, and the issue continues to occur intermittently.

Could you please review the above findings and advise if there are any additional checks, logs, or troubleshooting steps that we can perform? Any guidance or recommendations would be greatly appreciated, as we are trying to identify the root cause and reach a permanent resolution.

Thank you for your support.

PostgreSQL Monitoring and SSL Traffic Capture, add below two parameters in advance configuration and restart the agent.

<collect-PostgreSql-in-user-space>true</collect-PostgreSql-in-user-space>
<collect-SSL-PostgreSql-in-user-space>true</collect-SSL-PostgreSql-in-user-space>

reference document. https://docs-cybersec.thalesgroup.com/bundle/v14.19-dam-user-guide/page/77566.htm

if you still get alert , as /opt filesystem is shared with other applications , during the agent quota alert time is it possible to check the space and find which one is filling the logs in this filesystem. 

Hi Revn,

Thank you for your suggestions and for taking the time to review the issue. We appreciate your valuable inputs.

Please find our observations below:

1. /opt Filesystem Utilization
   The /opt filesystem is shared with other applications as well. However, we have verified the available capacity, and there is currently more than 100 GB of free space available, so disk space does not appear to be a concern at this time.

2. PostgreSQL Monitoring and SSL Traffic Capture
   The PostgreSQL database is currently being monitored in user-space mode. Regarding the missing parameters for SSL traffic capture, could you kindly share any relevant documentation or references? This will help us review the configuration and verify whether any required parameters are missing.

3. Agent Traffic Distribution (Handle Outbound)
   We have reviewed the high-volume traffic under "Agent Traffic Distribution" → "Handle Outbound". During our analysis, we identified that a few exclusions required for AMR fine-tuning were missing. We have now applied the necessary AMRs based on the outbound agent traffic observations.

Thank you once again for your suggestions and support.

1. Is /opt/imperva located on a dedicated filesystem, or is it shared with other applications under /opt? If other apps are using the same filesystem and their logs are stored in /opt, there is a possibility that space could become insufficient at times.
2. I noticed that the database in use is PostgreSQL. Could you please clarify whether it is being monitored in kernel mode or user-space mode? as i observed few missing parameters for SSL traffic capture  , are you able to observe PostgreSQL traffic, including SSL/TLS encrypted connections?
3. Please check the high-volume traffic in "Agent Traffic Distribution" under Handle outbound" for AMR fine-tuning.

Hello Revn,

Thank you for your suggestions.

We have reviewed the points you mentioned and would like to share our observations:

1. Gateway Connectivity: We checked the gateway status and connectivity during the alert period. The PCAP utilization remained well below the configured threshold. The quota is currently set to 50 GB, and the PCAP files did not consume even 10 GB

2. Data Compression: As recommended, we have enabled "Reducing Traffic Using Data Compression" by configuring the Compression Snappy switch in the Agent Advanced Configuration.
   

3. AMR Rules: We have already created and implemented AMR/exclusion rules for the agent to minimize unnecessary traffic. However, despite these changes, we have not observed any significant improvement, and the issue continues to occur intermittently.

Could you please review the above findings and advise if there are any additional checks, logs, or troubleshooting steps that we can perform? Any guidance or recommendations would be greatly appreciated, as we are trying to identify the root cause and reach a permanent resolution.

Thank you for your support.