Events Log
Revealing the composition and details of your traffic
Overview
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
Query specification
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 includes a pulldown for selecting the number (200, 500, 1000, 1500, or 2000) of the results displayed.
Query results
When a query is run, a list of matching requests is shown. See screenshot at the top for an example.
Each request can be expanded to show its details.
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, this section will show why.
Monitor Reason: if the request triggered at least one Action with a Type of "Monitor", the source(s) of this will be shown here. Note that Block Reasons and Monitor Reasons are not mutually exclusive; a request can have both types simultaneously.
Processing Stage: The furthest stage in the traffic filtering process that the request reached. To conserve compute resources, Reblaze stops processing a request when a blocking action is triggered. Thus, if the final stage was not reached (as in the example above), it's possible that other problems with the request would have been discovered if further stages of traffic filtering had been performed.
Tags: the various tags that were attached to the request during processing.
Building queries while investigating security events
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 a request has been expanded in the UI (as shown above), right-selecting on it 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 all the request data to the clipboard as JSON for further analysis, including the data and tags added by Reblaze.
Copy Value to Clipboard: Copies the value of whatever was right-clicked to the clipboard. In the example above, this string would be copied: Custom - content filter 300158[lvl5] - default contentfilter - [uri].
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: block_reason="Custom - content filter 300158[lvl5] - default contentfilter - [uri]".
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: block_reason!="Custom - content filter 300158[lvl5] - default contentfilter - [uri]".
The Dashboard has similar query-filtering capabilities in its Top Metrics section.
Truncated Log Entries
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 omit 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 (...)
Last updated
