Version v26.10

In a scenario where countermeasures in a protection policy must not affect traffic until there is an attack, the autodetection mechanism is usually used. Autodetection allows controlling the state of countermeasures by various thresholds and provides extensive capabilities for describing complex countermeasure activation logic, establishing dependencies of the states of some countermeasures on others, using safety mechanisms, and more.

However, autodetection has a limitation on the minimum reaction time. With the strictest settings, when the “Number of detected intervals” in autodetection is equal to one, countermeasures are activated no earlier than after one interval, which is five seconds.

A mechanism of autoactivation has been added, which allows activating filtering in countermeasures within milliseconds.

Countermeasures can be activated by one or several traffic counters located at the input of the “Autoactivation counters” element. The position of the element in the protection policy processing pipeline can be controlled using the “Countermeasure application order” functionality.

Activation threshold values are set in each countermeasure independently. Several thresholds can be set simultaneously for each countermeasure.

Previously, autoactivation was already used in LIM and LIM6 countermeasures. In these countermeasures, the triggering logic remains the same: regardless of the position of the “Autoactivation counters” element in the protection policy, LIM and LIM6 countermeasures always take into account only their own counters, that is, they are activated only by the values of the metrics of the traffic that has reached them.

Previously, unfinished or forgotten packet captures were deleted after 24 hours. Now an option has been added to automatically send a forgotten capture via the selected delivery channel.

To do this, you need to select delivery channels for the results of forgotten captures in the user profile.

In version v26.06, due to the change in the mechanism for determining country affiliation of IP addresses, specifying at least one countermeasure in the “Only for countermeasures” field became mandatory when the “Pass traffic from other countries without processing” checkbox is activated.

Now the ability to pass traffic that is not described by GEO rules around all countermeasures has been restored.

Now it is possible to limit the rate of passing DNS requests to domain names that are not in the allow list of domain names and in the list of domain names formed as a result of learning. Traffic exceeding the specified limit is dropped.

If the “Respond NXDOMAIN to requests for domains not on the allowed lists” flag is set, the countermeasure sends an NXDOMAIN response only to requests that were dropped as a result of the rate limiting.

Now in Logan you can write rules based on the number of bytes transferred in requests:

block 300 src.bytes limit 1000 period 60

This rule will add to TBL the IP address whose requests received more than 1000 bytes within 10 seconds.

In detection:

detect dst.bytes.on limit 1000000 period 60

Rules without “detect” will trigger only if more than 1000000 bytes arrive at the protected server within 60 seconds.

Also, in the streaming filter and log capture you can now specify a volume in bytes:

rtime - rsize gt 1000 rsize lt 5000

Responses from 1001 to 4999 bytes will be captured.

CODE is a range of codes (1xx, 2xx, 3xx, 4xx, 5xx), or a specific response code value.

Example:

block 300 src.uri.4xx limit 5 period 60

This rule will add to TBL for 300 seconds the IP address to which the protected server sent more than 5 responses with codes 400-499 within 60 seconds, for the same uri.

Search by prefix or IP address has been added. Search is available for lists with all source types except “Mitigator feeds”.

Matching rules depend on what is specified in the query and what is contained in the list:

• if an IP address is specified in the query and a prefix is contained in the list, the presence of the address in this prefix is checked;
• if a prefix is specified in the query and an IP address is contained in the list, the presence of the address from the list in the specified prefix is checked;
• if both the query and the list contain prefixes, their full or partial presence is checked.

Only lists in which matches were found are included in the search result. Under each such list, the “Prefixes” label and the list of matched values are displayed.

Added the ability to get reports on vertical and horizontal scanners based on flow data.

Added widgets of tops tables and rate graphs for various BGP attributes:

• source peer ASN;
• destination peer ASN;
• source AS path;
• destination AS path;
• source community;
• destination community;
• source next hop;
• destination next hop.

The ability to filter by the values of these attributes is also supported in the section’s filter field.

The tabular widgets “Source IP address” and “Destination IP address” in the advanced display mode, as well as the widgets “Source IP and packet length” and “Destination IP and packet length”, now have a “IP lists” column that shows the named IP address lists containing the given address.

The column is displayed if a match with a named list was found for at least one of the table rows.

A similar column has also been added to the “Flow Analysis” section on the incident page for the “Source IP address” and “Destination IP address” cards.

Now protection policies and routing rules on the “IPv4 processing” and “IPv6 processing” pages are separated into different tabs.