DDoS knowledge base and frequently asked questions

RioRey protects against all 25 classes in the RioRey Taxonomy of DDoS Attacks, spanning TCP, TCP-HTTP, UDP and ICMP based methods at Layer 3, Layer 4 and Layer 7. The taxonomy groups attacks by their underlying methodology rather than by tool name or botnet identity, because the method required to execute a successful attack changes far less often than the tools used to run it.

Each of the 25 classes can be independently configured per zone to Auto for active mitigation, Monitor for reporting only, or Bypass. The same coverage applies across hardware appliances, virtual machine deployments and cloud scrubbing, because all of them run the same RIOS filtering software.

Attack tools change constantly. Their names, signatures and infrastructure evolve rapidly, and that churn is often deliberate. What changes far less, and frequently cannot change if the attack is going to succeed, is the underlying method required to execute it.

A detection model built on tool signatures or botnet identity is tracking the variable part of an attack, so it is reactive by definition. RioRey analyzes protocol behavior, traffic characteristics and attack technique instead, which means a newly named attack tool is not treated as a zero-day. It is recognized as a new variation of a methodology that is already covered.

The practical consequence for an operator is that there is no learning period, no signature feed to update and no manual rule writing. Protection is the same whether or not an engineer is watching.

A carpet bombing DDoS attack distributes attack traffic across many destination IP addresses within a target prefix rather than concentrating the flood on a single victim IP. For example, an attack against a /24 can spread traffic across as many as 256 destination addresses. Individually, each destination may receive a relatively modest amount of attack traffic, while the combined traffic can overwhelm a shared upstream link, router, or firewall.

This distribution makes carpet bombing particularly challenging for defenses and monitoring systems that rely on per-host traffic thresholds. No individual destination necessarily appears to be under a significant attack, even though the aggregate traffic across the network is enough to cause congestion.

Carpet bombing is not a separate DDoS attack methodology. The traffic itself typically consists of familiar volumetric attacks distributed across a larger destination space. In the RioRey DDoS Taxonomy, common carpet bombing traffic maps primarily to the TCP classes AT1 SYN flood, AT2 SYN-ACK flood, AT3 ACK and PUSH ACK flood and AT9 Misused Application, and to AT17 UDP flood. The challenge is therefore one of visibility and reporting rather than the emergence of a fundamentally new attack class.

BGP FlowSpec's inherent limitations make it unsuitable as a standalone solution for comprehensive DDoS protection, though it provides useful capabilities for traffic redirection in off-ramp, hybrid, or cloud mitigation architectures.

BGP does provide tools of value in certain scenarios and for certain forms of DDoS attacks, but intelligent, software-driven mitigation platforms like RIOS offer greater flexibility, accuracy and adaptability in combating evolving DDoS threats.

In a RioRey deployment, RioRey Director can issue BGP FlowSpec rules to upstream routers as one of several configurable responses, alongside redirecting traffic to a RioRey mitigation device, redirecting to rCloud cloud scrubbing, or applying RTBH. FlowSpec becomes one tool in a workflow rather than the whole defense.

No. A SYN-Cookie defense is generally not a best practice for defending against DDoS floods. While it can theoretically defend against large-scale SYN floods, it requires all servers to support this capability and demands a vast amount of resources to operate at scale.

Normal clients generate a 64-byte SYN packet to request a new session. As the TCP three-way handshake is created, the host tracks and allocates each client's session until it is closed. This creates a resource burden quickly, making SYN-Cookie defenses difficult and costly to scale to a level where they are genuinely effective against a determined attack.

No, in most cases a firewall cannot protect against a Synonymous IP attack. Even a well-configured firewall that correctly discards attack packets will not be able to protect against link saturation, which is the primary goal of this attack type. The attack consumes upstream bandwidth before traffic ever reaches the firewall.

Defending against saturation requires mitigation upstream of the saturated link, either at the network edge with sufficient headroom or through hybrid DDoS protection that offloads volumetric attacks to cloud scrubbing.

During a SYN flood, a victim server receives spoofed SYN requests at a high packet rate containing fake source IP addresses. The flood overwhelms the server by depleting its connection table memory, resources normally used to store and process incoming packets, resulting in performance degradation or a complete server shutdown.

A well-crafted SYN flood often fools deep-packet inspection filtering techniques, making it one of the more persistent attack vectors at the network layer.

A SYN-ACK flood occurs when host servers generate SYN-ACK packets in response to incoming SYN requests. In the attack, the victim receives spoofed SYN-ACK packets at a high packet rate which exhausts the server's memory and CPU resources as it attempts to compute the irregularity of unrequested SYN-ACK packets, resulting in performance degradation or a complete server shutdown.

During normal traffic flow, ACK or PUSH ACK packets are used to exchange data within an established TCP session. During an ACK DDoS flood, the victim receives spoofed ACK packets at a high rate that do not belong to any session within its connection list.

The server must evaluate each arriving packet against its session table before discarding it. This matching process depletes memory and CPU resources, resulting in performance degradation or a complete server shutdown.

A Fragmented ACK attack is a variation of the ACK flood that uses maximum-size 1500-byte packets to consume large amounts of bandwidth, rather than relying purely on high packet rates. Because routers do not reassemble fragmented packets at the IP level, these packets pass through routers, ACLs, firewalls and IDS/IPS systems unimpeded.

The packet content is typically randomized, irrelevant data. The goal is to saturate all available bandwidth of the victim's network and affect the performance of every server on that network, not just the targeted one.

RST and FIN packets are used in TCP's three-way or four-way handshake to close a session between a client and a host. During an RST or FIN flood, a victim server receives spoofed RST or FIN packets at a high rate that do not belong to any session in its connection tables.

The server must attempt to match each arriving packet against its session state, depleting memory and CPU resources in the process, resulting in performance degradation or an outage.

A victim receives spoofed packets of any protocol at a high rate in which the victim's own IP address is specified as both the Source IP and the Destination IP. If a TCP Synonymous IP packet reaches the server, it will cause the server to send a SYN-ACK or an ICMP "port closed" response to itself, consuming resources without advancing any legitimate session.

UDP and ICMP variants produce similar self-referential responses depending on whether a service is listening on the target port. In all cases, the primary effect is link saturation. Bandwidth is exhausted before packets reach the server, which makes firewalls ineffective as a defense.

Fake session attacks generate a forged SYN packet, multiple ACK packets, and one or more FIN or RST packets in sequence. Taken together, these packets resemble a complete, valid TCP session, designed to fool defense tools that only monitor incoming traffic.

There are two variations:

• Variation 1: multiple forged SYNs, then multiple ACKs, then one or more FIN or RST packets
• Variation 2: skips the SYN entirely, starting with multiple ACKs, then one or more FIN or RST packets

The low TCP-SYN rate makes this attack harder to detect than a typical SYN flood, while achieving the same result: depletion of the victim's system resources.

Unlike spoofed-packet floods, session based attacks establish valid TCP-SYN sessions between attacker bots and the victim server. Once a session is open, the attacker manipulates it to maximally drain the victim's resources. Common techniques include:

• Setting excessively small TCP windows to slow data transfer and hold the session open longer
• Setting excessively high timeouts while sending no data, keeping sessions open indefinitely
• Creating large numbers of empty sessions, preventing legitimate traffic from consuming those resources

Because these are non-spoofed attacks, the source IP of each bot is its real public IP address. This makes source IP based blocking somewhat viable, though typically impractical at botnet scale.

Layer 7 attacks are the most sophisticated class of DDoS and the category where most conventional, volumetric-focused, or flow-based protection solutions are most vulnerable. These attacks target the application layer at the top of the OSI model, mimic legitimate traffic extremely well, and generally produce very little inbound traffic volume.

Because traffic levels appear normal, these attacks are very difficult to detect or stop. They exhaust server resources by exploiting application-layer processes, running them in parallel and non-stop, rather than overwhelming bandwidth.

A useful analogy: if a volumetric flood is 150 people simultaneously ordering a draft beer from one bartender, a Layer 7 attack is one person ordering 150 consecutive chocolate martinis. The total volume looks low and the resource cost is extreme.

Yes. Certain DDoS attacks rely on a misused application rather than a botnet. During a misused application attack, the attacker redirects valid clients of a high-traffic application, such as a peer-to-peer service, toward a victim server. The victim is then overwhelmed with connection attempts from computers that believe they are forming legitimate connections.

Once traffic is misdirected, the attacker becomes untraceable by dropping off the network. The victim's system resources are depleted by the volume of incoming, legitimate-looking connection requests.

In an HTTP Fragmentation attack, the attacker establishes a valid HTTP connection with a web server and then fragments legitimate HTTP packets into tiny pieces, sending each fragment as slowly as the server's timeout allows. This holds the connection open for an extended period without raising any alarms.

For Apache and many other web servers with improper timeout mechanisms, this session can be held open nearly indefinitely. By opening multiple such extended sessions per bot, an attacker can effectively stop a web service using just a handful of bots with almost no detectable traffic volume.

An Excessive VERB attack generates a large number of valid HTTP requests, typically GET requests for a common or large page or image, against a victim web server. Because each bot can generate many valid requests, the attacker can achieve a successful attack with a relatively small number of bots.

These attacks are non-spoofed, meaning the source IP is the bot's real public IP. While the most common form uses GET requests, POST or other HTTP verbs can cause the same effect. An Excessive VERB attack typically does not cause a significant bandwidth increase on the network, but can render the server unresponsive by consuming its processing resources.

A variation of the Excessive VERB attack that exploits the ability of HTTP 1.1 to send multiple requests within a single session. By limiting the session rate, the attack bypasses session rate limiting defenses that many security systems rely on. The impact on the victim web server is the same as a standard Excessive VERB attack.

Another variation of the Excessive VERB strategy. Rather than sending requests one after another, the attacking bot embeds multiple HTTP requests within a single packet. This maintains high server load at a very low packet rate, making the attacker nearly invisible to netflow anomaly detection.

With careful selection of the HTTP VERB, these attacks can also bypass certain deep packet inspection techniques, which makes them particularly difficult to mitigate with standard tools.

A refinement of the VERB attack in which the attacker collects a set of pages or images and generates GET requests that cycle through them in sequence. Because the requests are varied and appear to correspond to real site content, they look like legitimate browsing behavior. This technique can be combined with any of the VERB attack methods to further evade detection.

A variant of the Recursive GET specifically designed for forum or news sites where pages are indexed numerically in sequential order. The attacking GET requests insert a random number within the valid range of page index numbers, making each request unique and further reducing the likelihood of pattern-based detection.

Faulty Application attacks exploit websites with poor design or improper database integration. Using SQL injection style requests, the attacker can trigger database queries that lock up, consuming server resources such as memory and CPU persistently. These attacks are highly targeted and effective because they exploit specific weaknesses in the application architecture itself rather than relying on traffic volume.

During a UDP flood, a victim server receives spoofed UDP packets at a very high packet rate and from a large source IP range. The attack consumes network resources and available bandwidth, exhausting the network until it shuts down.

UDP does not use a full communication handshake to exchange data, which makes UDP attacks difficult to detect and extremely effective at flooding network bandwidth. UDP floods can overwhelm a network with packets containing randomized or fixed source IP addresses, and can be aimed at a specific server by using the victim's information as the destination port and IP.

A variation of the UDP flood in which the attacker uses large 1500-byte packets to consume more bandwidth with fewer packets. Because these fragmented packets are forged and have no real relationship for reassembly, the victim server spends CPU resources trying to reassemble packets that will never form a valid message.

This often overloads the processors and can reboot the entire system. The attack is harder to identify than a standard UDP flood because it resembles good traffic.

A DNS flood is an application-specific variation of the UDP flood. A victim DNS server receives valid but spoofed DNS request packets at a very high packet rate from a very large pool of source IP addresses. The server cannot determine which packet comes from a real resolver, so it proceeds to respond to all of them and is overwhelmed.

Spoofed DNS attacks are well crafted: the content of the packets is designed to mimic actual DNS requests. Because they are entirely normal-looking packets, this attack is not detectable by deep packet inspection, and the wide range of attacking source IP addresses lets the attacker evade most traffic anomaly detection techniques.

A VoIP flood is an application-specific variation of the UDP flood. A victim VoIP server receives spoofed VoIP packets at a very high packet rate from a very large source IP range. The server has to sort the proper VoIP connections from the forged ones, which consumes a detrimental amount of resources.

VoIP floods can use randomized or fixed source IP addresses. A fixed source IP VoIP attack mimics traffic from large VoIP servers and can be very difficult to identify because it closely resembles good traffic.

UDP floods can take the form of any media data, producing a Media Data flood of video, audio or similar traffic. The victim server receives spoofed media data packets at a very high packet rate from a very large source IP range and is overwhelmed by the volume, consuming network resources and available bandwidth until the network shuts down.

As with VoIP floods, randomized or fixed source IP addresses can be used, and the resemblance to legitimate media traffic makes the attack difficult to identify. Both modes can exhaust network bandwidth as well as CPU resources.

In a non-spoofed UDP flood, a victim server receives UDP packets at a very high packet rate and is overwhelmed by the volume, consuming network resources and available bandwidth until the network shuts down.

The source IP is the actual public IP of each attacker bot, so the source IP range equals the number of bots used in the attack. This type of attack is harder to identify than a spoofed flood because it resembles good traffic and the sources are real.

During an ICMP flood, a victim server receives spoofed ICMP packets at a very high packet rate from a very large source IP range. The attack consumes network resources and available bandwidth until the network shuts down. Because ICMP does not use a full communication handshake to exchange data, ICMP based attacks are particularly difficult to detect.

ICMP floods can use randomized or fixed source IP addresses, and can target a specific server by embedding the victim's information as the destination IP in each packet.

In an ICMP Fragmentation flood, the victim receives spoofed, oversized fragmented ICMP packets of 1500 bytes at a high incoming rate. These packets cannot be reassembled into a valid message. The large packet size amplifies the bandwidth consumption of the attack, while also forcing the victim's CPU to waste resources attempting to reassemble fragments that will never complete. This attack commonly causes victim servers to overload and reboot.

A Ping flood is an application-specific adaptation of the ICMP flood. The victim receives spoofed ICMP echo requests at a very high packet rate from a very large source IP range. The overwhelming volume of incoming ping packets consumes network resources and available bandwidth, exhausting the network until it shuts down.

The spoofed source IP can be random or set to the victim's own address. Because ping requests are usually well formed and arrive from a large number of source addresses, a ping flood cannot easily be detected by deep packet inspection or anomaly detection.

Yes. RioRey rWeb can provide a client-facing, white-label portal with visibility into traffic, attacks and mitigation activity, along with user controls and alerting. Service providers can customize the portal with their own logo and naming, and rWeb 10.0 adds CSS-based theming that allows the interface to visually match an organization's existing customer portal or branding in both light and dark modes.

Yes. rWeb is designed to function as a fully white-labeled client portal for ISPs, hosting providers and managed security service providers. Customizable elements include:

• Logo. Replace the RioRey logo with your own
• Portal name and version labeling. Surface your own product identity
• Full visual theming. As of rWeb 10.0, the complete interface appearance is controllable via CSS, including colors, surfaces, borders, chart lines, LED indicators and mode-specific variants

Custom themes can be applied independently to both Light and Dark modes, and end users can set their own individual mode preference. This allows operators to deliver a DDoS management experience that is graphically consistent with their existing client-facing tools and brand identity, with minimal configuration overhead.

Applying a custom CSS theme requires the appropriate rWeb administration permissions and takes approximately five minutes. Navigate to:

Administration → rWeb → rWebCustomization

From there, upload a custom CSS stylesheet that overrides the rWeb design token variables, controlling colors, surfaces, borders, chart line colors, LED indicators and mode-specific variants across Light and Dark modes. After uploading, perform a Shift and Refresh in your browser to apply the changes.

To switch between Light and Dark mode as a user, navigate to User → Profile → Preference.

RioRey publishes a complete example stylesheet covering all available CSS variables as a downloadable reference and starting point.

Yes, and it is remarkably efficient. Because the rWeb theming system is based entirely on CSS custom property overrides, the structure is well suited to AI-assisted generation.

Providing a tool like Claude with the published RioRey example CSS stylesheet alongside a screenshot of your existing website or brand guidelines can produce a solid, deployment-ready theme in minutes. The AI maps your brand colors to the appropriate rWeb design variables, covering text color, surfaces, borders, chart lines, indicators and mode-specific variants, without requiring manual CSS expertise.

From there, minor visual adjustments can be made by comparing the output against your live rWeb instance and iterating. For operators who want a client portal that genuinely looks like their own product, this is the fastest path to get there.

Yes. Current RioRey customers with an active contract can refer colleagues, business partners, clients, or other organizations to RioRey and receive account credit when a qualifying referral results in a purchase. Rewards vary based on the RioRey product you currently use and the hardware or virtual mitigation product purchased by the referral, and can include support or service credits. There is no limit on the number of qualifying referrals a customer can make.