DDoS Attack Handling
Victims
When filtering attack traffic, RIOS filter devices first look to identify patterns of attack traffic using their configured algorithms against the associated zone destinations. When a pattern of traffic reaches a level that the associated algorithm considers it an attack, a Victim is declared for that attack type against a specific destination. At a base level, a Victim is thus a combination of destination address and attack type. Depending on the attack type and its associated subtype, this declaration could be made immediately (e.g. in the case of malformed packets or block listed traffic) or after some level of analysis (e.g. in the case of more involved session or application behaviors, or for suspected spoofed floods), so Victims are also declared distinctly in time. So any given Victim will be unique in its combination of attack type, destination address, start time, and end time. After a period of time without activity for the associated algorithm, it will close out the Victim automatically.
RIOS devices send these Victim reports to rWeb, which then aggregates and collates the data so this reporting is presented as unified network level view to users regardless of which individual filter devices are detecting the attacks. Two individual devices reporting the same attack type and destination address at the same time (or overlapping in time) would thus be presented as a single Victim in rWeb. rWeb can then be further configured to identify which Victims should be displayed or need to issue notifications. rWeb also allows a deeper dive into individual Victims, supplemented by additional samples from RIOS devices.
RIOS Devices
By default, RIOS Devices will report any detected Victims to rWeb. For each Victim, it tries to send at least one packet sample over a separate channel, and periodically send more samples for longer lived attacks. For any Victims that exceed 100,000 attack packets or 10,000,000 attack bytes, RIOS will independently emit an attack message over its Syslog. Starting in RIOS 8.2.1, changes have been made to help prevent high levels of Victim churn and unnecessarily filtering low level traffic events that can be handled on the host side.
Victim Creation Thresholds
Starting in RIOS 8.3.0, RIOS devices have a low level packet threshold that will prevent victim creation and traffic drops for network events that should normally not cause a problem for most network hosts. This threshold applies to a subset of the attack types and subtypes available and is used on a per zone basis. This threshold is set to the following by default:
# Default
attack_packet_thresh_min = 100
A new value can be applied for a zone using the advanced controls and using a value of anything other than the default. A value of 0 will disable this control and revert to pre-8.3.0 behavior, creating a victim and dropping packets immediately for traffic violating the relevant attack type and subtype.
With this value set to anything other than 0, the listed attack type/subtype combinations below will mark detected traffic as attack traffic (when viewing the traffic summary), but it will not create a Victim and subsequently drop traffic until the traffic exceeds the threshold value (or if there is already a declared Victim for that attack type). This counter is reset every 30 seconds, so the default value of 100 is roughly comparable to not creating Victims and dropping packets for a 3 packets per second (pps) flow of traffic. The attack types and subtypes listed below are the ones affected by this control (which is for an entire zone) and can independently have separate Victim Reporting Thresholds (outlined in the next section after the table):
| Attack Type | Subtype | Description | Details |
|---|---|---|---|
| AT 1 | ST 2 | Duplicate packets that exceed the configured threshold | Drop after duplicate AT1 packets in the session exceed the configured maximum allowed and if AT1 victim exists or AT1 duplicates in the zone have exceeded MIN_THRESH in the current 30 second cycle |
| AT 1 | ST 4 | Zero window packet | Drop if AT1 victim exists or after TCP attack packets in the zone exceed MIN_THRESH in the current 30 second cycle |
| AT 1 | ST 5 | TCP SYN with invalid ECN flag combination | Drop if AT1 victim exists or after TCP attack packets in the zone exceed MIN_THRESH in the current 30 second cycle |
| AT 2 | ST 2 | Duplicate packets that exceed the configured threshold | Drop after duplicate AT2 packets in the session exceed the configured maximum allowed and if AT2 victim exists or AT2 duplicates in the zone have exceeded MIN_THRESH in the current 30 second cycle |
| AT 2 | ST 4 | Zero window packet | Drop if AT2 victim exists or after TCP attack packets in the zone exceed MIN_THRESH in the current 30 second cycle |
| AT 2 | ST 5 | TCP SYN-ACK with invalid ECN flag combination | Drop if AT1 victim exists or after TCP attack packets in the zone exceed MIN_THRESH in the current 30 second cycle |
| AT 3 | ST 3, 4, 6, 7, 8 | Duplicate packets | Drop after duplicate AT3 packets in the session exceed the configured maximum allowed and if AT3 victim exists or AT3 duplicates in the zone have exceeded MIN_THRESH in the current 30 second cycle |
| AT 3 | ST 5 | Duplicate data packets after close | If the advanced control to drop data pockets after close is enabled then data packets after close are not subject to a threshold and will be dropped immediately If the advanced control to drop data pockets after close is not enabled then data packets after close will be dropped after duplicate ACK data packets in the session exceed the configured maximum allowed and if AT3 victim exists or AT3 duplicates in the zone have exceeded MIN_THRESH in the current 30 second cycle |
| AT 4 | ST 17 | Fragmented packets in the current 30 second cycle that exceed the configured threshold | Drop after fragmented packets in the zone exceed the configured percentage allowed and if AT4 victim exists or after MIN_THRESH fragmented packets in the current 30 second cycle |
| AT 5 | ST 1, 2 | Packets that don’t match an existing session and exceed the configured ratio in the current 30 second cycle | Drop after FIN or RST packets in the zone exceed the configured percentage allowed and if AT5 victim exists or after MIN_THRESH FIN or RST packets in the current 30 second cycle |
| AT 5 | ST 3, 4 | Packets that match an existing session | Drop after duplicate FIN/RST packets in the session exceed the configured maximum allowed and if AT5 victim exists or AT5 duplicates in the zone have exceeded MIN_THRESH in the current 30 second cycle |
| AT 6 | ST 1, 2, 3, 4 | IPv4/IPv6 address match | Drop if AT6 victim exists or after MIN_THRESH matching-IP attack packets in the zone in the current 30 second cycle |
| AT 18 | ST 17 | Fragmented packets in the current 30 second cycle that exceed the configured threshold | Drop after fragmented packets in the zone exceed the configured percentage allowed and if AT18 victim exists or after MIN_THRESH fragmented packets in the current 30 second cycle |
| AT 24 | ST 17 | Fragmented packets in the current 30 second cycle that exceed the configured threshold | Drop after fragmented packets in the zone exceed the configured percentage allowed and if AT24 victim exists or after MIN_THRESH fragmented packets in the current 30 second cycle |
| AT 62 | ST 7 | Invalid IPv4 fragmentation flags | Drop if AT62 victim exists or after MIN_THRESH IPv4 attack packets in the zone in the current 30 second cycle |
| AT 62 | ST 13 | Invalid TCP flags | Drop if AT62 victim exists or after MIN_THRESH TCP attack packets in the zone in the current 30 second cycle |
| AT 62 | ST 14 | Null TCP flags | Drop if AT62 victim exists or after MIN_THRESH TCP attack packets in the zone in the current 30 second cycle |
| AT 62 | ST 15 | Null UDP source port | Drop if victim exists or after MIN_THRESH UDP attack packets in the zone in the current 30 second cycle |
| AT 62 | ST 18 | Invalid IPv4 header checksum | Drop if AT62 victim exists or after MIN_THRESH IPv4 attack packets in the zone in the current 30 second cycle |
| AT 62 | ST 28 | TCP header checksum invalid | Drop if AT62 victim exists or after MIN_THRESH TCP attack packets in the zone in the current 30 second cycle |
| AT 62 | ST 29 | UDP header checksum invalid | Drop if AT62 victim exists or after MIN_THRESH UDP attack packets in the zone in the current 30 second cycle |
Victim Reporting Thresholds
Starting in RIOS 8.2.1, RIOS devices can be configured to not report Victims below a given packet threshold to rWeb. This doesn't mean the device will not filter this traffic, but that RIOS will not report this Victim to rWeb for further collation. This can help prevent rWeb from doing excessive amounts of work in the case of high rate, low packet count Victims that can occur in certain situations (most notably, when doing country code or ASN blocking using block lists) that otherwise may negatively impact rWeb performance. This threshold is adjusted by adding an entry of the following type to the advanced controls for a given zone:
at_XX_attack_packet_count_victim_reporting_threshold = N
# So if I only want to report victims for AT5 with 10 packets or more:
at_5_attack_packet_count_victim_reporting_threshold = 10
Where XX is the attack type threshold you want to adjust, and N is a number 0 or greater. 0 is the implicit default value of this control, and will report all detected Victims to rWeb. When you have configured these settings in a zone differently than the default state of reporting all Victims, you can see the number of unreported Victims by looking at the traffic detail for the zone. It will report data under the various "AT XX Unreported Victims" categories each time a filter device closed a Victim without exceeding the configured packet threshold. Regardless of whether or not it reported the Victim, the zone traffic reporting will always show the total amount of traffic that is being considered as an attack and either subsequently monitored or dropped.
rWeb Display and Notifications
rWeb receives all of the Victim reporting from its configured RIOS devices, and aggregates them to unique Victim entries in a given zone. Since Victims are unique by destination address, this means handling of display and notification for the Victim will be done in the zone with the most specific routing prefix for that destination address. Victims within a zone have their own display and notification thresholds:
- Display thresholds- These thresholds determine whether or not Victims are displayed when using common areas of rWeb's UI. This includes the "Recent Zones Under Attack" widget on the dashboard, viewing current victim summary when looking a zone's status page, or the base set of Victims that are displayed when drilling down into Victim details using the Zone Victim Tab. In the latter two cases, if rWeb is having trouble applying these thresholds it will recommend that you click the "Show hidden victims" button, which will then show all applicable Victims for the time period being searched without using the threshold values as a filter. These threshold values thus only affect immediate display areas within rWeb; they do not affect actual filtering.
- Notification thresholds- These values affect whether or not rWeb emits a notification over both Email and Syslog (they are not separately configured). Victims below these thresholds or with the threshold disabled will generate neither an email nor a syslog notification. If a particular channel (Email or Syslog) is not configured, the correspond notification will implicitly not be generated. These values can be configured to use the same settings as the display thresholds or their own unique criteria, for each attack type.