¶ How to enable Subnet detection
¶ Purpose of this Wiki
Demonstrate how to enable and configure Subnet detection in the anti-DDos module, highlighting the differences with respect to single IP detection, its advantages and disadvantages, and how to adjust the decoders for this type of detection.
¶ Detection types: IP single vs Subnet
Before configuring a Threshold in the anti-DDoS module, it's important to understand the differences between the two available detection modes:
**Detection by unique IP: Greater control and accuracy, especially in environments with critical IPs or specific services.
Definition: The detection rules individually analyze the traffic of each IP within the prefixes registered on threshold.
Advantage: It allows identifying attacks aimed at specific IPs, with greater precision and control over false positives.
Disadvantage: It can generate a lot of alerts if there is heavy traffic on multiple IPs at the same time.
Subnet Detection: Broader detection, useful in high-density networks or for clients that share the same block.
Definition: The rules consider the combined total traffic of all the IPs of the prefixes assigned to the threshold, that is, the detection is carried out in an aggregated form.
Advantage: Ideal for shared environments or when traffic through IP is low, but the total volume may indicate an attack. Reduces the number of alerts.
Disadvantage: Lower accuracy — attacks on individual IPs can go unnoticed if the total subnet traffic is below the defined threshold.
¶ Starting Setup
¶ Accessing the module
Through the left side menu of Made4flow, enter the anti-DDos module:
¶ Creating a Decoder Approval Response
Important point so that false positives can be adjusted without impacting legitimate traffic, for this we will create an associated Response without action (mitigation, blackhole, or flowspec), to temporarily link to the Subnet decoders that we will add. To do this, access the Actions and Responses tab, click the Add Answer button:
On this screen we will define the Answer Name as “Decoder Approval”, in Associate thresholds we leave the options unselected, in the Description we can use something like “Response without associated action, to be used to approve new decoders”, then we save the Answer and on the next screen we save it again without adding the actions:
We will have the Response created as in the image below, with no associated Thresholds and no associated Trigger/Expire actions, so we can move on to the Subnet decoders:
¶ Adding the Decoders
In the Thresholds tab, click the Edit button for the threshold you want to enable subnet detection:
When accessing the threshold, all active decoders for that threshold will be displayed, in the case, only detected by a single IP, you can confirm by the Type column:
Through the Add a new decoder button, a popup will open and in it we will select the Type as Subnet, define the value (we will discuss it in a specific topic on this wiki), the unit that in the vast majority of cases is used as standard for Packets - PPS (packets per second) and for Bits - Mbps (megabits per second), and finally the personalized response for this decoder, where we can define the Response created without associated action that we call “Homologator Decoding”:
¶ To define the values for the Subnet decoders, we have two recommendations, namely:
¶ Approach based on decoders already approved for unique IP:
We set the subnet decoders with values approximately 3x greater than what is configured for unique IP, since the traffic that will be analyzed is based on the prefixes registered in the threshold. If possible, use prefixes with a similar peak of traffic at the same threshold, so that the rules are consistent for the same prefixes, avoiding false positives and increasing detection accuracy. In the example in the image below, we added the “Total” decoders for Subnet with 315000 pps and 3500 Mbps, taking into account the unique IP values multiplied by 3:
The advantage of this approach is the speed with which we added the new Subnet decoders, but as a disadvantage, we have a longer period of adjusting false positives until the rules have stable false positives.
For all scenarios, you choose to set lower rules and adjust false positives until they stabilize, and it's also important to remember that we have a wiki that guides how to validate and adjust false positives.
¶ Traffic-based approach from prefixes
For this case, we will need to register in advance in Made4flow the prefixes that will be separated into the thresholds (even if temporarily) and create the rules based on the traffic of those prefixes looking at the traffic of each specific prefix.
To register the prefixes, we must return to Made4flow, access the Prefixes tab and if these prefixes are no longer registered, we can click the “Add prefix” button, add the block, the description, the version, leave it as monitored and save. Do the same for the other prefixes:
From that moment on, the filters on the graphics based on these prefixes will be possible, remembering that the traffic on the graphics will be counted for those prefixes from the moment of registration, so the ideal is to wait 24 hours for the traffic to be counted at the time of low and peak traffic.
After the data accounting period, we can access the Prefix graph in the Graphics tab, select the prefix and generate the graph twice, the first using the output value in Bits per Second:
Then under Packets per Second, then we take the peak traffic amount, which is generally around 9 p.m., and add an additional margin of five to ten percent to avoid false positives:
We can also use the App graphic by accessing the graphics tab, which will show us the general traffic by applications considering all the prefixes registered in Made4flow in general, we can see by UDP Port 0, BGP 179 TCP, DNS 53 UDP, SNMP 161 UDP, SSH 22 TCP, Telnet 23 TCP, and other options. This information can serve as a basis for setting the rules for specific decoders:
For all scenarios, you choose to set lower rules and adjust false positives until they stabilize, and it's also important to remember that we have a wiki that guides how to validate and adjust false positives.
After adding the decoders with the values found using one of the approaches above, simply save the changes to the thresholds:
¶ Applying changes
After creating and saving the decoders, it is necessary to apply the changes:
- Click See changes (yellow button).
- Click Apply changes.
¶ Final Thoughts
Enabling subnet detection is an effective strategy for scenarios with multiple IPs and a large volume of aggregated traffic. It requires a careful approach when defining decoders to balance accuracy and number of alerts. Whenever possible, use historical traffic data to initiate the approval of rules with values more aligned with the reality of the network.