Global WAF Event Log

What Is Global WAF Event Log?

Global WAF Event Log is the screen that gathers the logs of all the WAF-protected vServices on the device in a single table. Its view and its working logic are the same as Event Logs: the same columns, the same toolbar, the same two-layered filtering and the same three-tabbed preview are used. Its difference is its scope.

	Event Logs	Global WAF Event Log
Where it is opened from	From the WAF screen of a vService	From the Configuration Menu
The traffic covered	Only that vService	All the vServices with WAF protection enabled
The additional column	-	vService
The additional filter tab	-	vService
The default row limit	1,000	5,000
The reading form	The hourly files of a single vService	A time-sliced scanning in the files of all the vServices
Access	The WAF authorization	The WAF authorization and an unrestricted vService scope

The value of the screen is that it shows at a single glance whether an attack targets only a single application or whether it wanders across the device. The traces the same source address leaves in different vServices come side by side in a single list; how many times a signature has been triggered in all the applications is seen with a single query.

This changes the starting point of an investigation. Instead of visiting the log screen of every vService on the device one by one, it is started from a single table; the search can be made even before which application is affected is known. Even while only the identity of a blocked request is at hand, the record is reached directly.

A Single Table

The whole of the device

The logs of all the vServices with WAF protection on in a single list

UID

Direct access with the identity

The identity of the blocked request is enough; it is found without which vService it is being known

Cross Monitoring

The same attacker, many services

The trace that an address leaves in all the applications is seen side by side

One Click

Passing to the service

By clicking the vService name, the WAF dashboard of that service is opened

Cross Teaching

In a single operation

The rows belonging to different vServices can be selected and taught together

5,000

The default row limit

Five times that of the vService screen, for a scanning across the device

Scope Warning

An incomplete scanning is not hidden

If the scanning cannot reach the whole of the range, how far it has come is written above the list

Separate Settings

Its own view

The column layout and the filters are stored independently of the vService screen

The whole of the explanation is on the Event Logs page

The columns, the Action decision icons, the Attacks counter, the Severity values, the toolbar, the server filter fields, the filter strip tabs and the preview tabs are all as explained on the Event Logs page. On this screen one field is added to the server filter and one field to the advanced filter; both are explained below. The rest of the page deals only with the behavior specific to the working across the device.

What Is It For?

While only a request identity is at hand The most frequent use

When a user or an application team applies saying "my request was blocked", most of the time only the request identity on the blocking page is at hand. When this identity is entered in the Request Unique ID field in the server filter, the record is reached directly without which vService is affected being known. Visiting the vServices one by one is not needed.

Monitoring an attacker across the device Investigation

Whether a source address, a network or a country tries only a single application or whether it wanders in all the services is seen on a single screen with the Client IP, ASN and Country tabs. If the distribution turns out to be wide, the address is taken into the blacklist across the device instead of the service scope.

Measuring the real effect of a signature Rule maintenance

How many times a signature turned on or off in the global layer over Signature & Rule Library has been triggered in all the vServices is read from the Signature tab. Whether a signature that produces a false positive is the problem of a single application or a problem across the device is understood from here. Since the numbers in the tab are calculated over the pulled rows, in a search the row limit has cut they are not the period total but the sample number.

Producing a breakdown after the event Reporting

After an attack wave, a breakdown across the device is produced with the taxonomy tabs (Category, OWASP Web, CWE, MITRE ATT&CK) and the table is exported as Excel, CSV or PDF. The export contains by default not the visible page but the whole of the filtered and sorted records; if it is wanted, only the visible page can be exported as well.

How to Access?

1. The Configuration Menu is opened by clicking the TR7 logo at the bottom left.
2. The WAF → Global WAF Event Log steps are followed.

The screen is not shown to the users who do not have the WAF authorization. In the users whose authorization is limited to certain vServices it is not displayed in the menu at all; the server side also rejects the requests of these users with a scope inspection. To look at the logs of a single vService, the own Event Logs tab of that vService is used.

The Logs Listing Screen

Global WAF Event Log - The Listing Screen

The screen opens not inside the management screen of a vService but on its own; for this reason there is no tab bar carrying the WAF Management and Live Stats tabs above it.

In the table there are two differences from the screen specific to a vService:

• The vService column is added to the beginning of the list. The name in the column can be clicked: when it is clicked, the WAF dashboard of that vService opens.
• The vService tab comes to the beginning of the filter strip, right after the fixed server filter tab. This tab narrows the pulled logs according to the vService.

The remaining columns, the toolbar and the preview window are the same as the ones on the vService screen. The only subtlety is in the Client IP tab in the filter strip: since the address menu there is not bound to a single vService on this screen, it does not offer the service-scoped blacklist options. A service-scoped operation is done from the Attacker IP menu in the preview window.

The row limit in a cluster setup

On the vService screen the logs of the two devices are not trimmed to the row limit again after they are combined; on this screen, on the other hand, the combined result is trimmed to the limit again. For this reason the number of rows listed on the global screen does not exceed the Line Limit value.

The Determination of the Scanning Scope

The scope is determined from the server filter tab explained on the Event Logs page. On this screen the tab differs at two points:

INFO

Line Limit Default: 5,000

Since far more logs are scanned across the device, the default value is higher than the one on the vService screen. The upper limit of the field is 20,000 on both screens; the only thing that differs is the default.

INFO

vService Default: All vServices

It is determined in which vServices the scanning will be done. In the default state all the WAF-protected vServices are scanned; the list is narrowed by selecting Pick vServices.

This field is different from the vService tab in the filter strip: the tab only filters the pulled rows, this field narrows the scanning itself. When a selection is made, the log files of the other vServices are not opened at all and the whole of the row limit is spent on the selected ones.

While the selection is active, a summary chip that shows how many vServices are selected is displayed in the filter strip; the chip is cleared with a single click.

A field is added in the advanced filter as well: the vService field that filters the vService the log belongs to comes to the Request group. This field offers only the equality and list membership operators.

The vService condition in the advanced filter also narrows the scanning, just like the selector in the server filter: if the condition has to be valid for every row, the files of the vServices that stay outside are not opened at all.

The Working of the Scanning

The screen of a single vService reads only the hourly files of that vService. The global screen, on the other hand, spreads the query to all the vServices and advances from the newest to the oldest by dividing the time range into slices. Every round scans all the vService files of a slice.

The first slice is one hour; in every round the slice width grows by doubling and rises to at most twenty-four hours. Since the slice is positioned according to the newest file waiting to be scanned, the time ranges in which no record is found are passed in a single round.

When the row limit is filled, the scanning stops, because at that point it has become certain that the rows in the list are the newest rows across the device. For this reason the row limit is on this screen the stopping condition of the scanning as well.

The scanning has a time budget: the interface grants two minutes to every request, the server uses five seconds less than this as the budget and works up to at most five minutes. When the budget is filled, the scanning is not cut halfway; the rounds completed until that moment return as a complete result and how far it has been reached is reported.

According to the situation, an information strip is displayed above the screen:

Situation	What is written on the strip	Meaning
The time budget is filled	Results are complete back to <date> — narrow the range to go deeper	The scanning could not reach the whole of the range in the given time. The list is complete up to the date written; older than that has not been scanned.
A source error	<number> source(s) could not be scanned fully	The files of some vServices or regions could not be read entirely.
The scanning is busy	Another global scan is running right now — please try again shortly	The number of global scans that can run at the same time is full.
A scanning error	The global log scan failed — try refreshing	The scanning could not be completed.

A partial result is different from an empty result

When the scope warning is displayed, "not found" and "not scanned" are not the same thing. The record searched for may be in an older slice the scanning could not reach. In such a case the search is deepened by narrowing the time range.

The row limit being filled naturally does not produce this warning: in that case the list contains the newest rows of the range completely.

The simultaneous scanning limit

At most two global scans can run at the same time. The third request is not taken into a queue, it returns a busy response directly.

This quota is common with the other surfaces that do a scanning across the device: the Global WAF Report production and the Bot/DDoS log scanning across the device also pass through the same gate. For this reason the busy response may not arise only from this screen being open in another administrator.

Operations

The teaching button on the toolbar works on this screen as well and the rows belonging to different vServices can be selected together. The name of the button becomes Allow, Teach or Allow / Teach according to the selection. The teaching operation is grouped per vService and is applied separately, in order for every vService: every vService writes into its own rule set.

The service-scoped options of the Attacker IP menu in the preview window are named according to the vService the row belongs to. The general-scoped options, on the other hand, affect the whole of the device.

The screen settings are kept separately from the ones on the vService screen: the column layout, the filter strip tabs, the time range and the row limit are stored separately for this screen per user.

Operational Best Practices

• The search should be started with a narrow time range. The scanning processes the range from the newest to the oldest with hourly slices and has a time budget. A wide range leads to the budget being filled and the list staying partial; if the record searched for cannot be found, the range is narrowed and tried again.
• The conclusion "there is no record" should not be reached without the scope warning being read. If there is a strip above the list that reports how far the scanning has reached, the record searched for may be in a slice that has not been scanned.
• If the affected vService is known, the scanning should be narrowed beforehand. When a selection is made with the vService field in the server filter, the files of the other services are not opened at all and the whole of the row limit is spent on the selected ones. The vService tab in the strip does not do this job; that one only filters the pulled rows.
• A search with the request identity should be made not from the filter strip but from the server filter. The Request Unique ID field runs the search on the server side and reaches the record that carries the identity directly.
• The row limit should not be enlarged unnecessarily. On this screen the limit does not only cut the result, it is the stopping condition of the scanning: when the buffer is filled, the scanning ends. Enlarging the limit means more rounds and more file reading and increases the risk of the time budget being filled. To go deeper, the time range or the filter should be narrowed instead of the limit.
• In a cross teaching the selection should be reviewed. When the rows belonging to different vServices are taught together, every vService writes into its own rule set; a false positive should be taught only in the related services.
• The blacklist decision should be given by looking at the distribution. If an address tries a single application, the service scope is enough; if it appears in more than one vService, a blacklist across the device is more suitable.
• A refresh response should be waited for in the busy hours. Since at most two global scans can run at the same time, while the screen is being used by more than one administrator, the refresh request may get a busy response.
• This screen should not be used for continuous monitoring. The list does not refresh by itself; for a periodic summary across the device Global WAF Report, and for instant tracking the Live Stats screen of the related vService is used.

Scope and Limits

INFO

• The authorization. The screen is closed to the users whose authorization is limited to certain vServices. It is not seen in the menu and its request is rejected on the server side as well.
• The screen does not refresh by itself. The list is pulled at the opening, with Refresh and when the server filter is changed; there is no automatic time-based refresh.
• The log production depends on the vService settings. This screen reads only the logs that have been written. While the host group of a vService is in the Learning mode, a log is not produced for that vService and is not seen here either. In the same way the suppression conditions defined on the Log Settings screen hide the related rows in this list as well.
• Only the vServices of the HTTP type. Since WAF protection is present only in the vServices of the HTTP type, only the logs of these services take place in the list. The Network (Layer 4) and L7 TCP vServices are not seen under any condition.
• The server filter is permanent. The time range, the row limit, the request identity, the advanced filter and the vService selection are stored per user. At the next opening of the screen it runs a query automatically with this scope; for this reason the list may be carrying the narrowing left in the previous session.
• The storage duration. How long the logs will be kept depends on the Disk Management settings and is common across the device; there is no separate storage setting for this screen.