Events Log
Revealing the composition and details of your traffic
Last updated
Revealing the composition and details of your traffic
Last updated
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 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 top part of this section is identical to the Query specification section on the Dashboard page, 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.)
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:
...and the $FIELDs are the Field names described here.
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 Reblaze'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, Reblaze 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.)
Monitor reason: if the request triggered at least one Action 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 tags 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 Download button or the Copy Request as JSON command, described below.
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.
Reblaze 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 Request as Curl: Copies a curl 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 Reblaze. The log data structure is the same as described above for the Download button, except that only one request will be returned.
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".
The Dashboard has similar query-filtering capabilities in its Top Metrics section.
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 (...)
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 Events Log entry 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 Events Log, 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).
