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.)
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 (e.g., additional blocking reasons)
Arguments/Headers/Cookies, except for these protected headers that will never be omitted:
accept
connection
content-length
content-type
host
user-agent
via
x-cloud-trace-context
x-forwarded-for
x-forwarded-port
x-forwarded-proto
Monitor reasons
Block reasons
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.
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 .
