Setup Log Triggers
CloudGuard AppSec protects web servers from attacks. It is possible to trigger a logging event that includes information about the event that was detected or prevented.
Logs can be configured to reach a variety of destinations.
The default setup of CloudGuard AppSec is already configured with a log trigger, and so, to view logs triggered by cloudGuard AppSec event detection, no additional action is required.
The default Log Trigger object is configured to log the most interesting events:
- Malicious events.
- High severity (and above) suspicious events.
- Most important identifying data from the request.
The configuration of the default Log Trigger object can be altered, but the object cannot be deleted.
If the default configuration has been altered, it is possible to click "RESET TO DEFAULT VALUES" at the bottom of the edit window to return to the default factory settings of this object as defined by Check Point.
Go to Cloud->Triggers and click New, the select Log:
Configure a new name to the new trigger object:
Select the conditions in which logs are issued:
- Detect/Prevent Events - Logs events caught by CloudGuard AppSec engines in "Detect" mode or blocked by CloudGuard AppSec engines in "Prevent" mode in addition to blocking.
If configuration in CloudGuard AppSec is set to "Detect" mode, Log Trigger configuration is the only action CloudGuard AppSec will take upon detecting an attack.
- Logging all web requests regardless of CloudGuard AppSec configuration.
Logging all web requests has a substantial impact on resources and network bandwidth consumed by CloudGuard AppSec.
Select the additional data you want to appear in the log sent upon event.
Additional logging for suspicious events from Severity "X" - Allows conditionally adding the Response Body and Response Code to logs according to the severity of the event reported.
Adding Request Body and Response Body to logs has the potential of substantially impacting the resources and network bandwidth consumed by CloudGuard AppSec, depending on the traffic. For this reason:
- The response body is conditional to the severity of the suspicious event.
- Either body content will not appear in the log if AppSec blocked the request prior to reading their values (for example, upon blocking a request based on its URL). In the case of response body, it will be logged only if the action is set to "Detect" and not "Prevent" as no response will ever arrive, if the request is blocked.
This configuration determines the destination of the logs sent from the AppSec agent, and multiple options can be selected.
The trigger destination can be:
- Cloud - CloudGuard AppSec Cloud, to be viewed by the CloudGuard Application event views under Monitor.
- Gateway/agent - Logging will be saved locally when possible in the folder /var/log/nano_agent.
- Syslog service and/or CEF service - Log to an external Syslog/CEF service by adding the destination IP address and UDP port (Usually 514 in both cases).
Browse to Cloud->Assets and edit the asset you wish to modify.
Go to the Threat Prevention tab and scroll to the bottom.
Click on the '+' icon next to Triggers and add your new Log Trigger object.
Syslog protocol is defined by RFC 5242. The structure starts with a priority value in '<>' followed by a timestamp of the log. The agent will also send a value in the syslog header for:
- Host name - indicating the host name where the agent is installed
- Application name - indicating the nano-service issuing the log.
Following the syslog header there are space delimited key value pairs in the structure of
<133>1 2022-05-17T05:55:37.623Z cpnano-agent-915faaab-6a40-4b55-be93-872e911397c0 HTTPTransactionHandler - 5 - title='API Request' agentId='915faaab-6a40-4b55-be93-872e911397c0' issuingEngineVersion='1.2228.372599' serviceName='HTTP Transaction Handler' eventReferenceId='eff9c697-d689-46c8-b702-87c92c728164' eventConfidence='Very High' matchedParameter='[readingValue]' matchedSample='[-45]' matchReason='[Value is lower than the minimum allowed value: -45 < 1.000000]' sourceIP='192.168.154.1' httpSourceId='192.168.154.1' sourcePort='64758' httpHostName='192.168.154.129:8080' httpMethod='POST' httpUriPath='/myApp/setParam' httpUriQuery='' ruleId='d8c0fda7-2ad1-e7ab-32bc-d1a6af6a2ca0' securityAction='Prevent' waapOverride='None' practiceType='Threat Prevention' practiceSubType='Web API' assetId='d8c0fda7-2ad1-e7ab-32bc-d1a6af6a2ca0' assetName='Customer Portal' practiceId='08c0fdac-3295-e034-be39-5ab4c2d11a28' practiceName='MY WEB API PROTECTION PRACTICE' waapIncidentType='Schema Validation' waapIncidentDetails='OpenAPI schema validation failed'
CEF protocol is explained here. The protocol fields are '|' character delimited and the agent will send the value for:
- Device Vendor - Check Point.
- Device Product - indicating the nano-service issuing the log.
- Event Name - This field will appear in the log structure but is not sent in the key-value pair system.
Following the CEF protocol fields there are space delimited key value pairs in the structure of
CEF:0|Check Point|HTTPTransactionHandler||Event Driven|API Request|High|agentId=915faaab-6a40-4b55-be93-872e911397c0 issuingEngineVersion=1.2228.372599 serviceName=HTTP Transaction Handler eventReferenceId=ad7a5181-b5d3-4b54-bd5b-106e180f0c9d eventConfidence=Very High matchedParameter=[readingValue] matchedSample=[-90] matchReason=[Value is lower than the minimum allowed value: -90 < 1.000000] sourceIP=192.168.154.1 httpSourceId=192.168.154.1 sourcePort=56060 httpHostName=192.168.154.129:8000 httpMethod=POST httpUriPath=/myApp/setParam httpUriQuery= ruleId=d8c0fda7-2ad1-e7ab-32bc-d1a6af6a2ca0 securityAction=Prevent waapOverride=None practiceType=Threat Prevention practiceSubType=Web API assetId=d8c0fda7-2ad1-e7ab-32bc-d1a6af6a2ca0 assetName=Customer Portal practiceId=08c0fdac-3295-e034-be39-5ab4c2d11a28 practiceName=MY WEB API PROTECTION PRACTICE waapIncidentType=Schema Validation waapIncidentDetails=OpenAPI schema validation failed