Version v25.12

Version v25.12 adds: commenting on setting changes, changing the order of policy countermeasures, a new countermeasure RECK, DNAT in General IPv4 Protection, many improvements to the autodetection mechanism.

The functionality of RETR, RETR6, HTTP, ATLS, DTLS, DNS, SLOW, BPF, SIP, HCA, USF countermeasures has been expanded, as well as PCAP, system event notifications and report sending, the synchronization mechanism, sFlow sending, bulk changes to protection policies, BGP interaction and TACACS+.

Multiple UX improvements made.

Changes in v25.12

EventLog. Added comments on settings changes.

To increase the transparency of changes made to the protection settings during operation, as well as for the convenience of recording both the changes themselves and the motivation for them, or other additional information on the work being done, an “Editing session” has been added.

An editing session is a mode in which all settings changes that the user has made during the session are linked to the session ID and accompanied by a comment. The Event Log shows the session ID for all changes made during the editing session.

A new tab has been added to the event log that displays a list of all editing sessions. From each session, you can navigate to the events of that session.

Clicking the “Start session” button in the upper panel on any page of the Web interface opens a window for entering comments and a button for launching. You can add comments at any time while the editing session is active.

A new parameter “Editing session usage” has been added to the user’s profile. The value of this parameter determines how the user is allowed to make changes to the settings:

• Disabled – the user can make changes to the settings without starting the editing session as it was before the v25.12 MITIGATOR version. The controls of the editing session are not displayed;
• Optional – the user can start an editing session and log changes, but the system allows him to make changes without starting an editing session;
• Required – in order to make any changes to the settings, the user must start an editing session.

The default value is “Disabled”.

EventLog. Added logging of values in events of manual modification of countermeasures tables.

The changed values are now recorded in the event log in the “Details” field during manual editing of the countermeasures tables.

Policy. Added the ability to change the order of policy countermeasures.

Now, on the “Settings” tab of the protection policy page in the “Countermeasures application order” panel, you can change the order of policy countermeasures.

You can not change the order for some elements.

A new protection policy is always created with a “standard” order of countermeasures. If the order of countermeasures has been changed, it is possible to restore the standard order. When a protection policy is copied, the current order of countermeasures within it is also copied.

New protection policies are created with a standard arrangement of countermeasures. When copying the protection policy, the arrangement of countermeasures is also copied.

At any time, the order of the countermeasures in the policy can be reset to the default one.

Important: Modifying the countermeasure application order allows adapting the protection policy to user-specific scenarios, but it involves risks. When a new countermeasure is added to MITIGATOR, its position in the processing chain is determined, among other factors, by its resource intensity. In the default configuration, less resource-intensive countermeasures are applied to traffic first, while more complex ones — which require more resources, are applied to the remaining traffic. If complex countermeasures are moved to the beginning of the list, they will handle more traffic, which may negatively impact system performance.

Policy. New actions have been added for bulk changes to protection policies.

Added actions:

• Enable Flow thresholds for BGP;
• Disable Flow thresholds for BGP;
• Change Flow accounting rules;
• Delete Flow accounting rules.

Detect. Thresholds for relative change per clock cycle have been added.

In addition to the <element>.Xxx.Diff. thresholds, which were triggered by an absolut change in the monitored metric, <element>.Xxx.Ratio. thresholds have been added for the relative change in the metric per cycle — that is, for the ratio of the metric value in the current cycle to its value in the previous cycle.

Refer to the built-in autodetection documentation for details.

Detect. Thresholds for relative and absolute changes in the metric have been added for BGP announcement based on Flow data.

To enable BGP announcements in case of sudden traffic changes, .Diff. and .Ratio. thresholds have been added for both incoming and dropped traffic.

Detect. Thresholds for relative and absolute changes in the metric have been added for policy activation and statuses.

Added:

Detect. Thresholds for the number of IP addresses in TBL have been added.

For all countermeasures, policies, and BGP announcements, On/Off thresholds have been added for the number of IP addresses in TBL: <element>.TBL.IPs.On and <element>.TBL.IPs.Off.

Additionally, similar thresholds <element>.TBL.IPs.Diff are available for changes in the number of IP addresses in TBL. In particular, if you set <element>.TBL.IPs.On but do not set <element>.TBL.IPs.Off, you get a threshold that keeps the countermeasure enabled as long as the specified number of IP addresses remains in TBL.

Detect. Thresholds for incident registration based on entry data into the packet processor and Collector have been added.

Now, incident recording is triggered by the following thresholds:

• Incidents.Input{Pps,Bps} — for total incoming traffic;
• Incidents.Drop{Pps,Bps} — for total dropped traffic;
• Incidents.Flow.Input{Pps,Bps} — for total incoming traffic based on Collector data;
• Incidents.Flow.Drop{Pps,Bps} — for total dropped traffic based on Collector data.

Additionally, thresholds for absolute and relative rate changes are available: .Diff. and .Ratio.

Refer to the built-in autodetection documentation for details.

Detect. Thresholds for incoming traffic minus WL‑passed traffic have been added.

Thresholds have been added for incoming and passed traffic, minus the traffic sent to output by the WL countermeasure:

• <element>.Protected.Input{Pps,Bps}.{On,Off} — for incoming traffic;
• <element>.Protected.Pass{Pps,Bps}.{On,Off} — for passed traffic;
• <element>.Protected.Input{Pps,Bps}.{Diff,Ratio}* — for changes in incoming traffic;
• <element>.Protected.Pass{Pps,Bps}.{Diff,Ratio}* — for changes in passed traffic.

Detect. A mechanism to keep a countermeasure enabled in case of frequent switching has been added.

If the countermeasure <element> switches more than <element>.Latch.SwitchLimit times within <element>.Latch.ObservationTicks cycles, it is activated and held enabled for <element>.Latch.HoldTicks cycles.

Refer to the built-in autodetection documentation for details.

RECK. New RECK countermeasure has been added in General Protection.

A new countermeasure, RECK “Repetition Check”, has been added to General Protection IPv4. This countermeasure enables defense against Flood attacks without using the challenge‑response procedure.

In terms of configuration settings and traffic processing behavior, RECK is similar to RETR.

DNAT. DNAT function has been adedd to General Protection IPv4.

HTTP. A limit on the number of HTTP requests from an IP address has been added.

Now the countermeasure can either limit the rate of HTTP requests from an IP address or add IP addresses that exceed the limit to the TBL.

ATLS. The reassembly of segmented «ClientHello» messages has been added.

An option has been added that, when enabled, allows the countermeasure to assemble ClientHello messages from segments and process them. The collection of TLS fingerprints also takes assembled ClientHello messages into account.

If reassembly is enabled, it is performed even for ClientHello messages from clients being already authenticated.

SLOW. An independent test mode activation option has been added.

Now the test mode for SLOW can be enabled independently of LCON.

BPF. Added the "Connection Monitoring" function usage.

sFlow. Added sending sFlow on passed traffic.

The packet processor can now send sFlow on traffic passed to the system output.

TACACS+. The capability to work with multiple TACACS+ servers has been added.

When multiple servers are added, the account attributes are verified against the first server in the queue. If it is unavailable, the next server in the list is used, and so on.

Groups. The maximum limits for restrictions in groups have been increased.

Now a group can impose the following limits:

• maximum number of policies — up to 2000;
• maximum number of routing rules — up to 5000;
• maximum number of named lists of IP addresses, TLS fingerprints, and rule sets — up to 1000.

Routing Rules. The ability to specify ICMP6 in routing rules has been added.

An ICMP6 alias has now been added to the «Protocol» field for routing rules within IPv6 protection policies.

Routing Rules. Filtering has been added to the rule list page.

Now the routing rule list page supports filtering by multiple criteria:

• protocol;
• source prefix;
• source port;
• destination prefix;
• destination port;
• group name;
• protection policy name;
• rule activity status (enabled/disabled);
• named IP list.

You can filter by one or several fields simultaneously, by substring match or full string match.

The functionality for determining the protection policy based on packet content has been preserved and moved to a adjacent tab.

Routing Rules. Navigation to a rule by line number has been added.

Now you can go to a specific rule table line by entering its number in the field and pressing Enter.

Core. Traffic bypass mode during congestion is now managed only through the web interface and is no longer configured via dataplane.conf.

Traffic bypass during system congestion is now controlled only using the “Pass traffic without processing when system congestion occurs” option on the “Common Settings” page in the system settings.

The congestion_bypass parameter must be removed from dataplane.conf. Refer the special instructions for details.

BGP. System prefix lists .aggregated. and .protected. for IPv6 have been added.

Sync. ДList of countermeasures supported by the table synchronization mechanism have been extended.

Now table data in countermeasures can be synchronized between instances:

• RETR «Retransmission Authentication»,
• RETR6 «Retransmission Authentication»,
• DTLS «DTLS Protection»,
• DNS «DNS Protection»,
• SIP «SIP Protection»,
• USF «Unknown Session Filter»,
• HCA «HTTPS Challenge-Response Authentication».

Sync. An indication of the blocking source has been added to TBL synchronization.

Previously, when table synchronization was enabled on instances, any entry added to the TBL table via the synchronization mechanism showed sync as the source of addition. Now, for all instances, the display has been updated to show the short name of the countermeasure that originally placed the IP address into blocking. The synchronization indicator has been changed to a boolean flag.

Example:

instance_id,instance_name,ip,ttl,source,from_sync,policy_id,policy_name,country,city,as_number,as_name
1,Mitigator0,1.1.1.1,300,ATLS,false,1,Default,"Finland","Tampere",39699,"Lounea Palvelut Oy"

Overview. Export and import of widget presets for the "Overview" page have been added.

Now on the “Overview” page you can copy the set and layout of widgets to the clipboard, as well as add a preset from the clipboard. This allows you to share the dashboard configuration with other users.

Overview. A setting for displaying section widgets has been added.

Now on the “Overview” page you can configure the display layout of widgets — the number of columns per row and the column height, just like in Flow Analysis.

Flow Analysis. A widget has been added to display the number of source and destination IP addresses for each collector.

User. Support for sending notifications to Telegram chat topics has been added.

In the Telegram ID field on the user profile page, you can now specify the chat identifier in the format 987654321/12345, which allows you to send system event notifications, incident reports, and files with the results of manually performed packet captures to a specific Telegram chat topic.

PCAP. Support for sending automatic capture files to Telegram chat topics has been added.

Reports. Support for sending scheduled reports to Telegram chat topics has been added.

UX. Animation for graph updates has been added.