Logging
Note
Smart Web Security enables you to log and analyze data on requests and rules they trigger. You can use this data to configure protection and investigate incidents.
There are two logging options available:
- Logging via Smart Web Security.
- Logging via the Application Load Balancer instance the security profile is connected to.
This section covers logging via Smart Web Security. This method provides more advanced analysis compared to logging via Application Load Balancer. For information on request logging via an L7 load balancer, see Configuring logging via Application Load Balancer.
Logs contain information about HTTP requests processed by Smart Web Security. You can only log requests that were blocked with a DENY verdict or sent to captcha with a CAPTCHA verdict. Additionally, you can log some legitimate requests with an ALLOW verdict. To reduce the size of logs, specify a sampling rate for such requests between 1% and 100%.
Smart Web Security delivers logs in JSON format. Each log entry contains the following structural blocks:
- Log system fields that contain service information of the monitoring system. Only one field is significant for analysis: the
timethe event occurred in the protected system, with nanosecond precision. labelsblock: Set of<name>=<value>pairs for log identification and quick filtering by different slices. You can also use top-level fields for filtering.messageblock: Short text log message in Unicode format.metablock: Request metadata, which is detailed parameters of triggered rules and request parameters.
The description of SWS log fields is given in the table below.
Log contents
|
Field |
Description |
|
|
IP address of the client that sent the HTTP request. |
|
|
Time when the request was received. |
|
|
ID of the load balancer the request came through. |
|
|
HTTP request |
|
|
Internal request ID. |
|
|
HTTP version. |
|
|
HTTP request method, |
|
|
Host name specified in the HTTP request. |
|
|
Path in the HTTP request. |
|
|
Request parameters provided in the URL after the question mark. |
|
|
HTTP request headers. |
|
|
Security profile ID. |
|
|
Security profile name. |
|
|
SWS module that made the final decision on the request. The possible values are |
|
|
Action applied to the request: |
|
|
Triggered rule name. |
|
|
Name of the triggered rule that is in Dry run mode. In this mode, the action is not applied to the request, while information about the trigger is logged. |
|
|
Expected action (verdict) applied by the rule to the request. The possible values are |
|
|
Expected action that would be applied by the rule to the request, but it is not applied in Dry run mode. The possible values are |
|
|
WAF profile ID, if used in the rule. |
|
|
WAF profile ID in dry run mode. |
|
|
WAF profile name, if used in the rule. |
|
|
WAF profile name in dry run mode. |
|
|
ID of the rule set that made the final decision in the WAF profile. The possible values are ID of a specific set or |
|
|
ID of the rule set that made the final decision in the WAF profile in dry run mode. |
|
|
IDs of all rule sets included in the WAF profile. |
|
|
IDs of all rule sets included in the WAF profile in dry run mode. |
|
|
Triggered rules in the WAF profile. This field has nested fields. |
|
Anomaly level obtained when checking the request using the WAF profile. |
|
ID of the WAF rule added to the security profile. |
|
Rule set ID of this WAF rule. |
|
Group ID of this WAF rule. |
|
All values from the |
|
Name of the rule from the WAF rule set. |
|
Request parameter the anomaly (threat) was detected in. |
|
Parameter name the anomaly was detected in. |
|
Parameter value the anomaly was detected in. |
|
Blocking rule flag. |
|
|
Triggered rules in the WAF profile in dry run mode. Nested fields are similar to |
|
|
List of exclusion rules triggered in the WAF profile. |
|
Exclusion rule name. |
|
Rule IDs from the rule sets added to this exclusion rule. |
|
|
List of exclusion rules triggered in the WAF profile in dry run mode. Nested fields are similar to |
|
|
ARL profile ID. |
|
|
ARL profile name. |
|
|
Expected action (verdict) applied to the request by the ARL profile: |
|
|
Name of the rule in the ARL profile that made the final decision on the request. |
|
|
List of rules in the ARL profile triggered for the request. |
|
ARL rule name. |
|
Indicates that this rule allows requests. |
|
Indicates that dry run mode is enabled in the rule. |
|
Rule priority. |
|
Rule counter state. |
|
Number of requests matching the rule conditions. |
|
Period for which the number of requests is counted. |
|
Request limit. |
|
Time period during which requests are counted to reach the limit. |
|
|
Names of the ARL rules with the number of requests above the limit in dry run mode. |
|
|
Bot score, from |
|
|
Bot name. |
|
|
Bot category based on its purpose or nature of action. |
|
|
Bot verification indicator ( |
|
|
SSL/TLS connection's JA3 |
|
|
SSL/TLS connection's JA4 |
To analyze Smart Web Security logs, create requests with the required fields and their combinations. Check the examples of ready-made requests in Examples of preset log filters.
Using logs when setting up protection
To ensure Smart Web Security does not disrupt your service availability while maintaining an adequate level of protection:
- Enable logging in your security profile.
- Set all rules to Only logging mode.
- Check the logs for correct traffic filtering.
- After checking, disable the Only logging mode.
Each time you update or add security profile, WAF, or ARL rules, enable the Only logging mode. Activate a rule only after the logs confirm that it works correctly.