Smarter by Design.Simpler for Business
L4 DDoS Protection
L4 DDoS Protection is the DDoS protection module of TR7 that works at the packet and connection layer. It evaluates the traffic entering a route table before it has become a request: how many packets a source sends per second, how many connections it holds at the same time and whether the packet it sends complies with the protocol's own grammar.
The module is not a list of thresholds. Twenty-five of the twenty-nine rules are divided into five protection bands, and the remaining four form the common layer that serves all the rules at once (the forwarding of the quarantine entries to log destinations is not a rule but a setting of the Quarantine box, and it is not included in this count); every band meets an attack family and every rule carries its own mode. The decisions are given on individual packets; a persistent source, on the other hand, can be taken into the rule's own quarantine list and all the traffic of that source entering the route table stops.
The protection is not a feature that is enabled per vService: it is ready in every route table. The rule catalog is born together with the table and, since the catalog defaults are written to the configuration while the route table is being created and at device startup, in a route table that has never been touched a part of the rules runs in enforcement and a part in monitoring.
The inspection stands at a different place from the protections at the application layer. Here it is not necessary to wait for a session to be opened, a header to be read or a body to be parsed: the decision is given by looking at the packet itself. For this reason the protection covers not only the device's own services but also the traffic passed through the device.
The link before the load balancing chain
L4 DDoS protection is not bound to a vService, it is bound to the route table. The traffic passes through this inspection before it is met by a vService, before TLS is terminated and before a target is selected. For this reason the protection is independent of the vService type: the traffic of all the services of the HTTP, L7 TCP and Network types is subject to the rules of the same route table.
The Bot/DDoS and WAF protections at the application layer do not replace this layer; they look at the content of the request and at the behavior of its source, while this layer looks at the packet itself.
Its Place in the TR7 Product Structure
L4 DDoS Protection is an add-on in the TR7 product structure. Every ADC license comes with L4 DDoS protection for a standard number of route tables; the add-on extends the protection to more route tables. The licensing details are on tr7.com.
5
Protection Bands
TCP, UDP, ICMP & Reflection, Packet Integrity and TR7 Management Access
29
Rules
The catalog is fixed; no rule is added, the mode and the limit of every rule are adjusted. The quarantine log forwarding is not a rule but a setting of the Quarantine box
4
Enforcement Levels
Disabled · Monitor · Block · Quarantine: selected separately per rule
Route Table
Protection Scope
Every table carries its own modes, limits and exemption list
24
Rules That Produce Measurements
Each carries its own series on the dashboard and in the live view; three of them are only in the DEFAULT table of the main device
From Day One
Defaults
The catalog defaults are written together with the table; there is no protection to be switched on
Passing Traffic Included
Inspection Area
The traffic directed to the device and the traffic passed through it are measured together; the concurrency rules look only at the traffic directed to the device
Uninterrupted
Setting Change
A change takes effect immediately; there is no separate deployment step
No separate device or service is needed
The protection runs inside the network layer of the device. There is no separate component to be installed, no separate service to be enabled and no separate device to be routed to; the rule catalog comes ready together with the route table.
There is no module-specific limit on the number of route tables
The protection does not carry a separate quota for how many route tables it can run in; every defined table comes with its own rule set. The limits are within the module itself and are per table: such as the quarantine list being listed with at most 2,500 rows or at most five countries being written to the exemption list.
There is no separate deployment step
Changing the mode or the limit of a rule is applied immediately: the firewall rules are rewritten, and no separate publishing or restart step is run.
What Is L4 DDoS Protection?
In order to make a service unreachable, it is not necessary to touch its content. The cheapest method in the attacker's hands is to use the protocol's own mechanisms in a way that produces cost: handshakes that are not completed, connections that are not closed, responses that have no counterpart or packets coming from spoofed sources that are known never to be reached.
The common feature of this traffic is that it never reaches the application layer. A half-finished handshake does not give birth to an HTTP request; it also looks ordinary to a firewall rule, because the address and the port are correct. Nevertheless, each of them consumes memory, the connection table and the processor.
L4 DDoS protection closes exactly this gap: it gives its decision before a request is formed, by looking at the packet itself.
Four Separate Questions, Five Bands
What happens while the connection is being established? TCP
In TCP, every connection is opened with a three-step handshake and holds resources at both ends until it is closed. The band measures these two facts separately: the handshake rate, the number of open connections and the flag pattern carried by the packet.
At what rate is it coming? UDP
UDP has no handshake: the only thing that can be measured is the sending rate itself. The band limits the number of packets per second per source, puts a separate ceiling on DNS requests and recognizes two known attack forms from their signature.
Who had it sent? ICMP & Reflection
In a reflection attack, the attacker does not send any packet to the target; it takes on the victim's address and asks third systems, and the answers rain down on the target. The band stands at the point where these answers arrive and also determines from here whether ICMP traffic is allowed at all.
Is this packet credible? Packet Integrity
This is the band that does not look at the rate at all. Does the packet have an open session, could the source address it carries have come from that address, is it dictating the path it will follow itself. There is no legitimate explanation for a packet whose answer is no; the first packet is already violating the rule.
The fifth band takes on a job separate from the other four: TR7 Management Access limits the concurrent connections opened to the device's own management ports. It protects not the carried traffic but the device's own management surface and is displayed only in the DEFAULT route table of the main device.
Measurement Methods
The rules do not use a single method. The method with which they work directly determines how a rule is adjusted and what it can catch.
| Method | What it measures | Example |
|---|---|---|
| Rate | The number of packets per second per source. It carries its own limit and is applied to the traffic that exceeds the threshold. | Handshake flood, UDP flood, ICMP echo request rate |
| Concurrency | The number of connections a source holds open at the same time. It is not a rate: the number is instantaneous. | Open connection ceiling per source, management port ceilings |
| Signature | The packet's own format. Most of them carry no threshold; when the pattern matches, it is valid from the first packet on. In the UDP signatures, on the other hand, there is a fixed or adjustable ceiling per source. | Malformed flag combinations, scan patterns, sessionless packets |
| Posture | Not a firewall rule but the way the system works. Most of them produce no measurement. | SYN cookies, source routing rejection, dead connection cleanup (only this last one measures connection states) |
A rule without a threshold is more definite than one with a threshold
The correct value of a rule that measures a rate changes from service to service and, when it is chosen wrongly, it can cut legitimate traffic. Most of the signature rules do not carry this risk: malformed flag combinations and scan patterns do not come out of a legitimate protocol stack. Four of them, however, stand apart; sessionless packets, new packets that do not open a handshake, suspicious MSS values and private address ranges can also be seen in a healthy network.
The learning engine also recognizes this distinction. For the rules that have no numerical threshold, the backtest and confidence threshold conditions are not run; the engine can propose taking such a rule in monitoring directly into enforcement.
The Difference from Bot/DDoS and WAF
All three modules stop the attack, but they work at different places and with different questions. When they are enabled together on the same device, they do not replace one another, they take effect in turn.
| L4 DDoS Protection | Bot/DDoS Protection | WAF | |
|---|---|---|---|
| The layer it works at | The packet and connection layer | The application layer | The application layer |
| The object it is bound to | The route table | The vService | The vService |
| The question it asks | At what rate, in what number and in what format is this packet coming? | How much, from where and from whom is the request coming? | Is the content of the request malicious? |
| The information it looks at | Packet headers, rate counters, the connection table | Counters, source reputation, client behavior | The content of the path, the query, the header and the body |
| What it typically catches | Handshake flood, connection exhaustion, reflected amplification, scanning | Request flood, scraper, credential stuffing, botnet | SQL injection, XSS, file path attack |
| Decision time | Before the request is formed | Before the content is opened | After the content is parsed |
| The traffic it covers | The traffic directed to the device and the traffic passing through the device; the concurrent connection ceilings and the management rules are applied only to the traffic directed to the device | The HTTP and L7 TCP requests coming to the vService | The HTTP requests coming to the vService |
The three layers do not replace one another
A half-finished handshake never gives birth to an HTTP request: the WAF never sees it, and no request counter is formed for Bot/DDoS either. On the other hand, a request that comes from a clean browser and whose format is flawless but whose content is malicious is not caught by any rule of the L4 layer.
The vServices of the Network type cannot enter the application layer inspection at all; this is the only protection layer for that traffic.
L4 DDoS in TR7
In TR7 this protection is gathered under a single module and is managed from the route table's own screen. The module has four design decisions:
- Rules are not added, they are adjusted. The catalog is fixed and is displayed with the same rules in every route table. The job of the operator is not to write new rules but to adjust the mode and the limit of the ready rules according to their own traffic.
- Every rule carries its own mode. There is no master switch that turns the whole protection. One rule can be applying enforcement while another is only monitoring and a third is disabled.
- The enforcement layer is common. The quarantine is kept in a separate list per rule, but the duration is common with all the rules and in the live view the lists are combined in a single table; in every row it is written which rule sent the source. The exemption list is also a single definition and is applied in front of all the rules except the blacklist.
- The decisions are shown with readable sentences. The management screen is not a list of forms: every rule is read in its own row with a full sentence instead of field names.
Why Is It Needed?
- Availability. A flood consisting of handshakes that are not completed can take the service out of service without using any vulnerability. The rate and concurrency limits keep the load passing to the back end in a predictable band.
- Resource consumption. Connections that are left open and are not closed fill the memory and the connection table; how long after that the dead connections will be collected is adjusted from here.
- Reflection attacks. The unwanted responses coming from amplification services fill the bandwidth of the target with multiples of what the attacker sent.
- Reconnaissance and scanning. The scan traffic that tries to map the services comes before the attack itself and is caught from the first packet with the signature rules.
- Spoofed source traffic. The packets that take on the device's own address or claim to come from private address ranges are rejected the moment they arrive.
- Protection of the management access. The device's own management surface is a surface independent of the carried traffic and asks for its own ceilings.
How Does It Work?
01 · ExemptionExempt sources are taken out of the inspectionThe addresses, network blocks and countries in the exemption list are evaluated in front of all the rules except the IP reputation blacklist. An exempt source is not caught by any threshold and is not written to the measurements either.
02 · ReputationThe sources in the blacklist are separatedThe IP reputation blacklist kept device-wide is applied with the mode selected in this route table. The decision is a single list reading and it also cuts the established connections.
03 · RulesThe rules of the five bands evaluate the packetThe rules that measure a rate read their counters per source, the ones that measure concurrency look at the connection table, and the signature rules test the format of the packet. Every rule decides in its own mode.
04 · ResultThe packet passes, is dropped or the source is taken into quarantineThe rules in monitoring mode only measure. The ones in enforcement mode drop the packet; the ones in quarantine mode also write the source to a timed list and all the new traffic of that source stops.
The quarantine cuts wider than the scope of the rule itself
When a source is taken into quarantine by any rule, the traffic of that source stops not only for the triggering rule but in the whole route table: no port or protocol distinction is made.
In the traffic directed to the device, the cut is applied only to the new connections, the established sessions continue for their durations. In the traffic passed through the device, on the other hand, the established sessions are also cut.
The monitoring mode is a rehearsal mode
A rule in Monitor mode makes its measurement and writes it to the dashboards, but it does not drop any packet. When these measurements are read before passing to enforcement, it is seen in advance which traffic would stop if the limit came into force.
The monitoring mode has one limit: the drop counters are fed only in the enforcement modes. A zero drop value on the dashboard does not mean "there is no attack", it can also mean "the rule is not in enforcement yet".
Five Protection Bands
TCP
It meets the attacks that target the connection establishing and holding open mechanisms. It carries ten rules and is divided into three boxes: the handshake itself, the number of open connections and the flag pattern of the packet.
On the handshake side, the new packet rate per source is limited and the packets that do not comply with the handshake rule and that carry suspicious values are also caught; next to these, the stance of the kernel against the accumulation of half-open connections is switched on and off from here. On the connection side, there are the concurrent connection ceiling per source and the collection durations of the connections that are not closed. The four rules on the flag side, on the other hand, carry no threshold: twelve separate malformed flag combinations and the empty and fully flagged scan packets are dropped from the first packet on. The port scan rule differs from these: all the traffic of the source that touches a trap port is dropped for a period, because the purpose is not to block a single packet but to cut the scan halfway.
UDP
It limits the traffic carried without establishing a session. It carries four rules and is divided into two boxes.
On the flood side, the number of UDP packets per second per source is limited; DNS requests also carry their own ceiling, because this service, which can produce a large answer with a small request, can be both a direct target and a tool for attacking others. On the signature side, the packets whose payload is completely empty and the attack that targets the file sharing ports are recognized by name; this second one covers both the UDP and the TCP side.
ICMP & Reflection
It meets the traffic that is had sent to the device by the hand of other systems. It carries four rules and is divided into three boxes.
The first box is the band's only permission setting: it determines whether ICMP traffic is given any passage at all. The second box limits the echo request rate per source and the rate of the connection reset packets coming to the device. When the echo request rule is taken into enforcement, it also drops three reconnaissance types without regard to the rate: the address mask request, the timestamp request and the router request. The third box, on the other hand, counts the unwanted responses coming from the eight service ports that are known to be used in amplification.
The box names show the scope narrower than it is
The distinguishing sign of the classic reflection attacks is that the packet is sent to a broadcast address; no rule of the band uses such a criterion. The rules look not at the target but at the source and at the rate.
The reflection box also meets the situation in which the device is the victim: it limits the incoming unwanted responses, it does not prevent the device from being used as a reflector for attacking others.
Packet Integrity
It inspects the packet's own consistency and does not look at the rate at all. It carries four rules: the packets that cannot be associated with an open session, the packets that show the device's own address as the source, the packets that claim to come from private and reserved address ranges and the packets that carry their route within themselves.
The rules of the band are among the most definite rules; for this reason two of them come in the catalog directly with an enforcement default, and the source routing rejection comes as an explicit stance. The rule that targets the private address ranges, on the other hand, is born in monitoring; on a line that faces the internal network these ranges can be legitimate.
TR7 Management Access
It limits the concurrent connections opened to the device's own management ports. It carries three rules: the command line access and the unencrypted and encrypted access of the management interface.
All three measure not a rate but concurrency: it is looked at how many connections a source holds open at a certain moment. The band is displayed only in the DEFAULT route table of the main device.
Operating Modes
Most of the rules use the same four levels and the levels are selected separately per rule.
Disabled
The rule is completely disabled
Neither a firewall rule is written nor a measurement is produced. The limit of the rule remains recorded, but it is not applied anywhere.
Monitor
It measures, it does not apply
The rule is in force and writes its measurement to the dashboards; only it has no result. It is the rehearsal mode before passing to enforcement.
Block
The packet that exceeds the threshold is dropped
The decision is per packet: only the packet caught by the rule is dropped, the other traffic of the source is not affected.
Quarantine
The source is kept outside for a period
The address of the source that exceeds the threshold is written to a timed list; during that period all the new traffic of the source entering the route table stops.
Not all the rules use these four levels. Some of them are an on/off setting (Enabled · Disabled), the ICMP rule is a permission setting (Allow · Deny) and in two rules the quarantine level is not offered at all.
The status strip on the L4 DDoS Management screen of the route table shows a reading derived from these modes and reads only the rules that can apply enforcement: if at least one is applying enforcement, Active, if none is applying it but at least one is monitoring, Monitoring, if all of them are disabled, Not Active. The on/off settings and the ICMP permission setting do not enter this reading. This text on the strip is not a setting; the modes are changed only from the rules' own rows.
The Common Layer
Above the rules there are three boxes that serve all of them at once.
| Box | Its job |
|---|---|
| Blacklist | Determines how the IP reputation blacklist kept device-wide will be applied in this route table. The list is common, the mode is per table and it takes three values: the quarantine level is not offered. Unlike many other enforcements, it also cuts the established connections. |
| Quarantine | Determines the quarantine duration; the duration is common with all the rules in the route table and its default is ten minutes. The sources taken into quarantine are listed in the live view and can be released manually. The second row of the box carries the quarantine log forwarding: while a destination is selected it reads Quarantine entries are forwarded to <destinations>, and while none is selected it reads the gray Quarantine entries are not forwarded to a log destination. The forwarding is edited with its own pencil icon and at most 5 Log Forwarding profiles are selected. |
| Whitelist & Known Peers | Defines the sources that will stay outside all the measurements: single addresses, network blocks and countries. In addition to this, the servers derived from the device's own infrastructure can be exempted with a single switch. |
The exemption list also turns off the measurement
The traffic of an exempt source does not only stay outside the enforcement, it is not written to the counters either. This makes the exemption both a security and a measurement decision: the load produced by an exempt source is not seen on the dashboards. The only exception is the IP reputation counter: even if it is exempt, an address seen in the blacklist continues to be recorded.
A route table that has not been touched comes with a local network entry that covers the private and reserved address ranges. As long as this entry stands in the list, the scope of the rule that targets those ranges is also narrowed.
AI Learning
The correct value of a rate limit changes from line to line: the same number is loose for one route table and narrow enough to cut the service for another. The module does not expect the operator to guess this value. The learning engine reads the past measurements of the route table, calculates the suitable range for every rule and presents its result as a recommendation.
What Does the Engine Produce?
The engine produces two kinds of recommendation: changing the limit of a rule and passing a rule from monitoring to enforcement. The two go through separate gates.
| Recommendation | Its condition |
|---|---|
| Limit recommendation | The rule must have an adjustable limit. The recommended value does not go below a floor defined per rule; this floor limits only the recommendations of the engine, it does not limit the values entered manually. |
| Mode promotion | It changes according to the class of the rule. In the signature rules that do not produce false positives, the engine can propose a promotion directly; in the rules that measure a threshold and in the signature rules that can also be seen in a healthy network, the Mode Promotion permission is additionally required. This permission is disabled by default. |
Three Operating Modes
| Mode | Behavior |
|---|---|
| Learning Off | No periodic evaluation is made. When the screen is opened, an instant evaluation is still run, for this reason the counters can look full. |
| Smart Advisor | The default mode. The engine learns, writes its reasoning and recommends; it applies nothing by itself. The evaluation runs every hour. |
| Automatic | The engine applies what it has learned itself in the defined period. The period can be selected only in this mode. |
The learning window comes from the Learning Lookback setting. The entered value is rounded to the ready windows in which the engine works; even though the entered value is written on the card, the calculation is made with the rounded window.
The Limits of the Application
The recommendations are approved or skipped one by one in the review window on the Learning strip; the approved ones are sent as a single package and applied in a single write operation.
A rule that has telemetry can also be taken outside the scope of the engine: when the Learning Lock switch of the rule is turned on, the engine cannot touch the limit and the mode of that rule.
The strip is displayed even while learning is off
What stops in Off mode is only the periodic run. The strip continues to stay on the screen and an instant evaluation is made every time the screen is opened; for this reason the counters on the card can look full.
Monitoring and Visibility
Dashboard Dashboard
The traffic carried by the route table and the telemetry produced by the protection are read side by side in the same time range. The network counters are collected every two seconds and the protection measurements every five seconds; since the data is stored in tiers, both the last five minutes and the past year are looked at from the same screen.
Instant status L4 DDoS Live View
Which rule is under pressure, who is in quarantine at that moment and how the open connections are distributed are read in a view that is refreshed every ten seconds. The operations that touch the traffic immediately, such as manual release from quarantine, are done only from this screen.
Threat status Threat State
The measurements are reduced to a single reading with five bands. Three pressure axes are averaged, and the reaction given by the protection pulls the result up to a certain floor; in this way the question "am I under attack right now" is answered at a single glance.
Getting informed Notifications
The learning recommendations are notified through the interface. The quarantine entries can also be forwarded to log destinations and are listed on the Quarantine History screen. The threat status, on the other hand, does not carry a notification trigger; it is read from the dashboard and from the live view.
Management and Operation
- The protection is per route table. There is no separate enabling step; the rule catalog also comes the moment the table is defined.
- The changes are uninterrupted. Changing a mode or a limit takes effect immediately; no separate publishing step is run.
- The authorization comes from the Network area. Displaying the screens requires monitoring and all the edits require change authorization. While the network configuration is locked during synchronization, editing is disabled independently of the authorization.
- In a cluster the configuration is synchronized, the measurements are not. The modes and the limits are written to both devices; the counters, the quarantine lists and the connection tables are separate per device. A source taken into quarantine on one device does not enter quarantine on the other by itself.
- The learning engine runs on a single device in the cluster. Only the first device carries out the periodic evaluation; the recommendations it produces are carried to the peer device together with the configuration.
- The settings can be returned to the defaults at once. The reset operation on the learning strip returns all the rules to the catalog values; the same operation also returns the exemption list to its default state. The quarantine log forwarding selection, on the other hand, is preserved in the reset.
Use Cases
Handshake flood
Thousands of sources start to open connections, but none of them completes the handshake. The new packet rate per source is limited, the stance of the kernel for half-open connections is kept on; the sources that persist are taken into quarantine and the connection table is emptied.
Reflected amplification
The line is filled with name resolution and time synchronization responses that come although they were not requested. The reflection rule recognizes these responses from their source ports and limits them per source; the answers to the device's own queries are not affected.
Reconnaissance scan
Before the attack, an attempt is made to map the services. The flag and scan rules catch these packets from the first attempt; since they do not wait for a threshold, the scan stops before it is completed.
Load on the management access
A large number of concurrent connections are opened to the management interface or to the command line. The ceilings of the management band are applied per source; having their own addresses in the exemption list is the only condition before passing to enforcement.
A different stance for different lines
On the same device, the table that faces the internet and the table that faces the internal network do not have to be equally strict. Since the protection is defined per route table, every line carries its own limits and exemptions.
Closing what is below the application layer
The WAF and Bot/DDoS see only the requests that reach a vService. For the traffic of the services of the Network type and for the traffic routed through the device, this is the only protection layer.
Terminology
| Term | Description |
|---|---|
| Route table | The object to which the protection is bound. Every table carries its own rule modes, limits, exemption list and quarantine duration. |
| Band | The rule group that meets an attack family. There are five bands; the bands have no setting of their own, the editing is in the rule row. |
| Box | A subgroup within a band. The box also has no setting of its own. |
| Disabled · Monitor · Block · Quarantine | The four modes of the rules that use the enforcement levels. They are selected separately per rule. |
| Allow · Deny | The two values of the ICMP permission setting. It is not a protection but a passage decision. |
| Enabled · Disabled | The two values of the settings with an on/off structure. These mostly write not a firewall rule but the way the system works. |
| Quarantine | Keeping the source that exceeds the threshold outside for a period. The list is separate per rule, the duration is common with all the rules and in the live view the lists are combined in a single table. |
| Exemption list | The sources that are kept outside all the measurements. Exempt traffic is neither subjected to enforcement nor written to the counters. |
| Known Peers | The servers derived from the device's own infrastructure. They are taken into the exemption scope with a single switch. |
| Mode Promotion | The setting that allows the learning engine to pass a rule that can produce false positives from monitoring into enforcement. It is disabled by default. |
| Learning Lock | The switch that closes a rule to the learning engine. While it is on, the rule is changed only manually. |
| Threat State | The threat reading with five bands derived from the measurements: No Attack, Low Activity, Possible Attack, Attack Detected, Active Attack. |
| Idle | The rule on which no pressure is seen in the live view. In the rules that have a limit, the measure is the ratio of the measurement to the limit; in the ones that have no limit, it is the packet rate itself. A disabled rule is seen here in every case. |
Sections
The module consists of five sections and all of them are in the context of a single route table. The two groups in the other protection modules have no counterpart here: since the protection comes ready, there is no enabling page, and since work is always done in the context of a single table, there is no device-wide list or combined log screen either.
Route Tables & L4 DDoS
The management screen of a route table: four tabs, the access paths and the division of work of the tabs.
→
Dashboard
The traffic and threat dashboard: eight view tabs, the preview panel, the time range and the panel controls.
→
L4 DDoS Management
All the configuration: the protection mode strip, the learning strip and the five protection bands.
→
L4 DDoS Live View
The live view: the threat strip, the family cards, the quarantine table and the connection detail panel.
→
Quarantine History
The quarantine history: the log screen in which the sources that entered quarantine are listed according to the date range.
→
Typical Deployment Flow
1
Step 1 Read the stance the line is born with
Since the protection comes ready, the first step is not to switch something on but to see what is on. On the L4 DDoS Management screen, the status strip and the distribution badges of the bands are read: which rule is born in enforcement and which one in monitoring.
2
Step 2 Set up the exemption list
The addresses and network blocks belonging to one's own infrastructure are written in the Whitelist & Known Peers window. This step is done before enforcement: the learning engine also refuses to pass the management rules into enforcement while the exemption list is empty.
3
Step 3 Learn the ordinary load in monitoring mode
Enough measurement is accumulated to cover the ordinary usage cycle of the line. The rules in monitoring mode do not drop any packet during this period; the real load is read from the Dashboard dashboards and from the L4 DDoS Live View screen.
4
Step 4 Adjust the limits according to the measured load
The rate and concurrency limits are adjusted by leaving a safe margin above the measured peak values. The recommendations on the Learning strip are reviewed at this step; the reasoning and the calculation of the engine are read in the recommendation window.
5
Step 5 Take the signature rules into enforcement
Since the malformed flag combinations and the scan patterns do not carry a false positive risk, these are passed into enforcement first. This step provides a visible gain without touching the rate limits. The rules that catch sessionless and inconsistent packets, on the other hand, are kept in monitoring for a while, since in asymmetric routing they can also be triggered on legitimate traffic.
6
Step 6 Pass the rate and concurrency rules into enforcement
When the measurements have settled, the rules that measure a threshold are taken into Block or Quarantine mode. The quarantine is preferred for the sources that persist; for one-off exceedances, dropping the packet is sufficient.
7
Step 7 Review the management access and the quarantine duration
The Management Ports ceilings are adjusted according to one's own way of working and the Quarantine duration is determined. The sources that fall into quarantine are monitored from the live view; a source that falls in by mistake is released from the same screen.
