Events Log
Revealing the composition and details of your traffic
Last updated
Was this helpful?
Revealing the composition and details of your traffic
Last updated
Was this helpful?
This page provides the ability to review and analyze the most recent traffic, up to and including real time. It is a powerful tool for traffic control; if a security event occurs, this page will allow you to quickly find its root cause.
Running a query will display a list of requests matching the specified criteria. Each request can be expanded to display additional details.
The Events Log page contains two primary sections:
Query specification
Query results
This section determines the events, if any, that will be displayed in the Query results section.
The Events Log also provides three additional controls:
This downloads a JSON file containing complete log data for the requests in the current query results, in this structure:
...where each $REQUEST has this structure:
Selecting this button will display a row of controls at the top of the query results. Entering text into a control will quickly filter the results list, to display only those events which match the filter. For example, to only display "Passed" requests, enter P into the Result control.
This specifies the number (200, 500, 1000, 1500, or 2000) of the results displayed.
When a query is run, a list of matching events is shown. See screenshot at the top of this page for an example.
Clicking on an event will open a window with more information, including an expandable Additional details section.
Some of the data shown comes from the request itself, while some of it was added during L11WAAP's processing. Important information in the latter category includes:
Block reason: if the request was blocked, the reason will be shown. In the example above, a Global Filter blocked the request. (To conserve compute resources, L11WAAP stops processing a request when a blocking action is triggered. Thus, it's possible that additional problems with the request would have been discovered if further stages of traffic filtering had been performed.)
By default, when the Events Log responds to a query, all arguments in the requests will be retrieved. In some environments, incoming requests can contain excessively large arguments, or a large number of arguments, either of which can delay the delivery of the results.
If this situation arises frequently, there is an internal system setting that will defer argument retrieval until a button is clicked (the Show All Arguments button in the Arguments tab). This can improve Events Log performance, and will also make it easier to find specific arguments (because argument data will be displayed in a table with search capabilities).
When security incidents occur, the investigator will frequently submit a succession of queries, often starting from a broad scope and then drilling down into a narrower focus while trying to discern the underlying cause.
L11WAAP provides some tools to make this process easier. When viewing an event, right-clicking on one of its values will reveal a popup menu, as shown below.
The menu options are as follows.
Copy Value to Clipboard: Copies whatever was right-clicked to the clipboard.
Show Matching: Adds a filter parameter (for whatever was right-clicked) to the existing query in the Search field at the top of the page. Submitting the modified query will restrict the results to requests that match the field and value that was selected. In the example above, the following string would be added to the query: result="Blocked by origin".
Hide Matching: Adds a filter parameter (for whatever was right-clicked) to the existing query in the Search field at the top of the page. Submitting the modified query will exclude requests that match the field and value that was selected. In the example above, the following string would be added to the query: result!="Blocked by origin".
Potentially, a very large request could exceed the maximum allowable size of a log entry. This makes it impossible for the system to capture all the request's data in the log.
In this situation, the system will truncate the log entry by omitting some of the request's details, and the log entry will contain a notice of this.
Omissions will occur in this order:
Additional log entries (the last section in the Events Log)
Parameters (arguments/headers/cookies, but see note below on protected headers), in this order :
Ignored parameters
Examined parameters
Examined parameters that triggered an Action
Monitor reasons
Block reasons that were not final
Content from the main block reason (e.g., a large value of a parameter), noting the omission with an ellipsis (...)
In the event data, the body will be preceded by this message: The request contains a malformed body (displaying only first 500 characters):.
If a POST request with content-type: application/json contains a malformed JSON payload, the system will not be able to process the payload.
The event data (in the Events Log entry and any active Log Exporters) will contain an error message, noting that a malformed body was received. However, the system will be unable to parse the body to count the number of arguments. Thus, in the event data, the request will have a tag of args:0, even though strictly speaking, arguments might have been present.
Note also that the payload will not be subjected to content filtering. Thus, the disposition of the request will depend solely on whether or not it violated other security rulesets (e.g., rate limiting).
By default, expanding an entry will display all of its data. When a request contains thousands of arguments, or very large arguments, the data retrieval can negatively affect the performance of the Events Log display. If your planet commonly receives such requests, the Events Log can be configured to only retrieve the arguments when the Arguments tab is selected in the Additional Details display, which will improve performance. To enable this, .
The top part of this section is identical to the , except that it contains a button to transfer the current query criteria to the Dashboard. (Note that in order for the query to transfer, it must have been run already.)
...and the $FIELDs are the Field names described .
Monitor reason: if the request triggered at least one with a Type of "Monitor", the source(s) of this will be shown. Note that Block reasons and Monitor reasons are not mutually exclusive; a request can have both types simultaneously.
Tags: the various that were attached to the request during processing, shown in blue. User-defined tags are shown in the top section; system-defined tags are shown in the Additional details section.
The UI displays the most important request data. Full details of an event can be obtained by using the button or the Copy Request as JSON command, described below.
To enable this feature, contact . Note that if this setting is enabled, it will no longer be possible to (successfully) run queries based on arguments, since argument data will not be available when the queries are processed.
Copy Request as Curl: Copies a command containing this request to the clipboard, so that an admin can re-submit that exact request to the system. This can be useful in various situations, e.g., to test a security setting that was modified.
Copy Request as JSON: Copies the request's log data to the clipboard as JSON for further analysis, including the data and tags added by L11WAAP. The log data structure is the same as described above for the , except that only one request will be returned.
The Dashboard has .
Requests with large (longer than 500 characters) malformed bodies will have their bodies truncated in the Events Log, and in the events exported via .
Note: 500 characters is the default limit, but this can be changed if necessary. To do this, contact .
