DDoS Protection

Denial of Service and DDoS Attacks

An online service relies on servers, links, and applications to process user requests. If an attacker consumes these resources with a large number of requests or packets, users may not receive responses within the required time. The load may affect link bandwidth measured in bits per second, packet processing, or memory reserved for connection state.

A Denial of Service (DoS) attack disrupts the availability of a service, server, or network. It may come from one system or many sources. The result can be rejected requests, delays, or exhaustion of resources intended for legitimate users. Availability is the primary affected property. A vector may operate at the network, transport, or application layer.

When traffic comes from many sources, it is a Distributed Denial of Service (DDoS) attack. It can overload the target or an intermediate network. Its direct objective is to reduce availability, and the incident may also distract from other attacker activity. Botnets, reflection services, and spoofed source addresses can distribute the traffic.

Botnets Used in DDoS Attacks

Coordinating many devices to send traffic to one target at the same time requires control infrastructure, often based on a botnet. A command server issues a task, and the devices execute it with selected protocols and traffic parameters.

A botnet is a network of hijacked, internet-connected devices. These devices, known as bots or zombies, have been infected with malware that allows an attacker, the botmaster, to control them remotely without their owners' knowledge. A botnet can be composed of a diverse range of devices, including:

• Desktop computers and laptops.
• Servers.
• Mobile devices (smartphones and tablets).
• IoT devices (security cameras, smart home devices, routers).

After building a botnet, an attacker can issue a command from a command-and-control (C2) server that directs the bots toward the victim's IP address. Traffic from many locations and addresses can be difficult to distinguish from user traffic and filter effectively. Distributed sources increase the load on the target and its protective devices. Some traffic may use a spoofed source address, so the sender address alone does not establish trust. Detecting the botnet and removing malware limits further use of the devices.

Types of DDoS Vectors

DDoS vectors can be grouped by the resource or network layer they exhaust. One incident can combine several vectors and change its traffic mix over time. Monitoring should include throughput, packet rate, request rate, application errors, and latency. These values should be compared with a normal traffic baseline and a recorded service profile.

1. Volumetric Attacks

Volumetric attacks aim to consume the bandwidth of the target or intermediate devices. Their size is measured in bits per second (bps), including gigabits (Gbps) and terabits (Tbps). Analysis also considers packet rate and traffic sources, because bandwidth alone does not describe the processing cost of each packet.

When a link is saturated, legitimate user packets may not reach the service even if the servers continue to operate.

Common volumetric attacks include:

• UDP Flood:The User Datagram Protocol (UDP) is connectionless. An attacker sends a large number of packets, often to ports without a listening application. The system may generate 'ICMP Destination Unreachable' messages depending on its configuration and rate limits, consuming resources and outbound capacity. The incoming UDP load can also exhaust packet processing.
• ICMP Flood:This variant uses the Internet Control Message Protocol (ICMP), which is also used for diagnostics. An attacker sends many 'ICMP Echo Request' packets. 'ICMP Echo Reply' responses depend on configuration and rate limits, but processing the requests can consume target bandwidth and resources.
• Amplification Attacks:An attacker sends small requests to publicly accessible services, such as DNS resolvers or NTP servers, and places the victim's spoofed source address in those requests. The service sends its response to that address, sometimes with more data than the request. The victim then receives unsolicited responses from many servers. Response limiting, reflection filtering, and source-address validation reduce this vector at providers.

2. Protocol and State-Exhaustion Attacks

State-exhaustion attacks consume resources in firewalls, load balancers, and other infrastructure devices. They target connection-state tables, queues, or packet-processing limits instead of only the link bandwidth.

The attack imposes many operations and states that the infrastructure must maintain. Its volume is measured in part as packets per second (pps).

The classic example is:

• SYN Flood:This attack exploits the TCP three-way handshake ('SYN', 'SYN-ACK', 'ACK'). The attacker sends many 'SYN' packets, often with spoofed source addresses. The server may create half-open connection state and wait for the final 'ACK'. When the acknowledgement does not arrive, those states consume resources and limit new connections. Mechanisms such as SYN cookies can reduce this effect by limiting stored state before an acknowledgement arrives.

3. Application-Layer Attacks

Application-layer, or Layer 7, attacks consume resources in a specific application or service, such as a web server or database. They may resemble ordinary requests, which complicates detection. Analysis can require URL paths, parameters, sessions, response codes, and processing time.

An attacker can target functions that require many operations, such as a complex database query, a site search, or a large file download. A small number of concurrent sessions can keep application resources busy for a long time.

These attacks are measured in requests per second (rps) and include:

• HTTP Flood: A botnet is used to send what appear to be legitimate HTTP GET or POST requests to a web server. These requests can be crafted to target resource-intensive functions, like a complex database query, a site search, or a large file download. Since the requests look like normal user traffic, it can be very difficult for simple defense mechanisms to distinguish them from legitimate requests. Rules can consider session limits, operation cost, and client behavior.
• Low-and-Slow Attacks (e.g., Slowloris): An attacker opens many connections to a web server and keeps them open by sending data at a low rate. The server waits for each request, so occupied connections can exhaust available slots. The attack uses little bandwidth while limiting new sessions. Timeouts, connection limits, and stream handling reduce the impact.

DDoS Protection Strategies

DDoS protection requires several control layers: monitoring, filtering, rate limiting, and prepared response procedures. The team should know the service owner, escalation point, DNS dependencies, and how to contact the link provider. Acceptable latency and protection-activation criteria should be set in advance. The procedure should preserve logs and include a post-incident review.

1. On-Premises Protection

These are defenses deployed within an organization's own data center. They include firewall rules, ACLs, connection limits, server protection, and traffic monitoring. Monitoring should include throughput, packet rate, request rate, and service latency.

• Rate Limiting: Configuring network devices to limit the number of requests in a given period. Rules based only on source IP can be bypassed, but rate limiting helps with simple floods. Limits must match normal traffic so legitimate clients are not rejected. Separate limits can be applied to sessions, endpoints, and costly operations. The limits should be reviewed after traffic patterns change.
• DDoS Mitigation Appliances:Specialized hardware can inspect traffic, detect attack patterns, and filter selected packets. It helps only when the traffic reaches the appliance. An attack that exceeds the organization's link capacity saturates the connection before local filtering, so cooperation with the link or protection provider is also required. The appliance must be sized for normal traffic and expected bursts.

2. Cloud-Based Protection

Cloud services move traffic analysis and filtering to a provider's distributed infrastructure. Their effectiveness depends on capacity, configuration, and the traffic-redirection method. Before activation, the organization must define which prefixes, domains, and services are covered, together with the expected clean-traffic return path.

• Cloud Scrubbing Services:When an attack is detected, an organization's traffic may be rerouted through DNS or BGP changes to the DDoS provider's scrubbing centers. DNS changes direct application requests, while BGP can change the route for selected IP prefixes. The selected method determines which traffic is inspected.

  The centers analyze traffic, discard packets matching attack rules, and forward accepted traffic to the organization's servers. The return path may use a private link or another channel selected by the provider. Rules must reduce attack traffic without dropping required requests, and their effect requires monitoring. Incorrect rules can increase latency or interrupt legitimate clients. The provider and organization need an agreed procedure for changing filters during the incident. The configuration should also cover server health and withdrawal of the redirection.

• Content Delivery Networks (CDNs): A CDN caches selected content on distributed edge servers, so some requests do not reach the origin server. This can reduce application-layer attacks when the CDN service and its rules cover the traffic. A CDN does not replace origin protection or filtering for content that cannot be cached. When the architecture permits, access to the origin should be limited to edge servers, with health checks and origin rate limits configured separately.

3. Hybrid Protection

A hybrid approach combines an on-premises appliance for some protocol and application-layer attacks with an on-demand cloud scrubbing service for attacks that may saturate the local link. The local layer filters traffic that reaches the network, while the provider handles traffic requiring greater capacity. The plan should define activation criteria, procedure tests, contact roles, and the return to ordinary routing. Logs from both layers should be correlated after the event, including the time of each routing change.