DDoS Knowledge Base & Frequently Asked Questions

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.

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.

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 effect 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 a 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 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, making firewalls ineffective as a defense.

Fake session attacks generate a forged SYN packet, multiple ACK packets, and one or more FIN/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 → multiple ACKs → one or more FIN/RST packets
• Variation 2: Skips the SYN entirely, starting with multiple ACKs → one or more FIN/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 is the category where most conventional, volumetric-focused, or flow-based protection solutions are most vulnerable. These attacks target the application layer (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; 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 HTTP 1.1's ability 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, making 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 (memory, 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 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 (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 (pings) 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.

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 5 minutes. Navigate to:

Administration → rWeb → rWebCustomization

From there, upload a custom CSS stylesheet that overrides rWeb's 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 + 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's remarkably efficient. Because rWeb's theming system is based entirely on CSS custom property (variable) overrides, the structure is well-suited to AI-assisted generation.

Providing a tool like Claude with RioRey's published 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 (text color, surfaces, borders, chart lines indicators, and mode-specific variants) without requiring any manual CSS expertise on your part.

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 truly looks like their own product, this is now the fastest path to get there.