×
Community Blog Volumetric Attack Mitigation with Alibaba Cloud Anti-DDoS Pro

Volumetric Attack Mitigation with Alibaba Cloud Anti-DDoS Pro

This article examines how Alibaba Cloud Anti-DDoS Pro mitigates volumetric distributed denial-of-service attacks through the traffic diversion model, ...

Volumetric distributed denial-of-service attacks saturate either the upstream network capacity of a target or the resource limits of the protocol stack handling incoming connections. Once inbound traffic exceeds what the origin's network path can handle, legitimate requests are dropped alongside malicious ones, and the service becomes unreachable, regardless of application capacity.

Mitigating these attacks at the origin is structurally impractical; the traffic must be absorbed before it reaches the origin path, requiring aggregate scrubbing capacity measured in terabits per second across distributed ingress points. Alibaba Cloud Anti-DDoS Pro provides this capability for workloads hosted in mainland China regions. This article documents how traffic diversion is established, how the scrubbing pipeline discards malicious packets, and the policy decisions that determine effective mitigation under load.

ChatGPT_Image_May_26_2026_02_07_08_PM
Figure 1: Anti-DDoS Pro architecture overview.

Traffic Diversion to the Scrubbing Layer

Anti-DDoS Pro does not sit in the data path by default. Inbound traffic is diverted to scrubbing infrastructure through DNS resolution or port-forwarding, depending on the protection model.

For Layer 7 web workloads, the protected domain's authoritative DNS record resolves to an Anti-DDoS Pro CNAME rather than the origin. Client connections terminate at a scrubbing centre ingress, are inspected, and are then re-established toward the origin. For Layer 4 TCP and UDP workloads, port-forwarding rules at the Anti-DDoS Pro instance map a public scrubbing IP and port to the origin's address and port.

In both models, the origin's public IP should accept connections only from the documented back-to-origin IP ranges, enforced through the security group on Elastic Compute Service or the listener policy on Server Load Balancer. Failure to enforce this scope is a common misconfiguration. Attackers who discover the origin IP through historical DNS records or certificate transparency logs can bypass the scrubbing layer entirely and target the origin directly.

The Scrubbing Pipeline

Inbound traffic reaching a scrubbing centre traverses a multi-stage classification pipeline, with packets dropped at the earliest stage that recognises them as malicious.

Network-layer signature matching identifies SYN floods, ACK floods, ICMP floods, and UDP reflection from amplifiable protocols such as DNS, NTP, SSDP, Memcached, and CLDAP. Reflection traffic is particularly identifiable because it originates from a finite set of UDP source ports that legitimate clients rarely target. Stateful protocol validation then inspects TCP handshakes for completion before connection state is committed to the forwarding path, discarding half-open connection attacks and spoofed traffic generated by stateless attack tools.

Behavioural analysis evaluates per-source-IP request rates against baselines derived from the workload's normal traffic profile. Sources exceeding their baseline face challenge-response verification, a JavaScript challenge for browser clients or a TCP-level proof-of-work for non-browser clients that legitimate clients pass automatically. Sources that fail repeatedly are blocked at the edge for a configurable duration.

Layer 7 CC (challenge collapsar) protection inspects HTTP request patterns for flood characteristics: uniform user agents across distributed sources, identical request paths at unnaturally consistent intervals, and missing headers that real browsers always send. Enforcement is progressive rate limiting, challenge issuance, and then blocking.

Protection Policy Configuration

Default policies are calibrated for general-purpose web traffic. Workloads with non-standard profiles APIs serving programmatic clients, real-time game servers, and video streaming origins require tuning to avoid false positives.

Three policy dimensions warrant explicit configuration. The connection rate threshold limits new connections per second per source IP; raise it or whitelist client IPs for programmatic clients that legitimately open many concurrent connections. The Layer 7 CC request rate threshold should be set to approximately three to five times the observed P99 request rate per legitimate source IP, high enough for traffic spikes, low enough to detect flood patterns. Geographic blocking, where the user base is regional, eliminates a significant share of bot traffic at zero false-positive cost and is one of the highest-leverage adjustments available.

Custom CC rules supplement defaults with workload-specific patterns. Rules match on URI path, request method, header values, and source attributes, allowing tighter protection on sensitive endpoints, login, password reset, and payment initiation without affecting general traffic.

Connection forwarding can preserve the original client source IP through the X-Forwarded-For header for Layer 7 protection or the TOA (TCP Option Address) module for Layer 4 TCP forwarding. Applications relying on client IP for logging, rate limiting, or geolocation should read the forwarded address rather than the immediate TCP source, which will be a scrubbing centre IP.

Operational Considerations

Three operational factors determine whether mitigation holds under sustained attack load.

  1. Origin IP exposure history: Anti-DDoS Pro does not protect against attacks that target the origin IP directly. Origin IPs publicly resolvable before protection was enabled remain discoverable through historical DNS records, certificate transparency logs, and passive DNS databases. When onboarding an existing workload, migrate the origin to a previously unused IP and enforce the back-to-origin firewall scope from the moment of cutover.
  2. Protection and clean-traffic bandwidth: Instances are provisioned with two distinct metrics, protection bandwidth (peak attack volume the scrubbing tier absorbs before the workload is blackholed) and clean-traffic bandwidth (peak legitimate post-scrubbing throughput to the origin). Size protection bandwidth to the largest plausible attack against the threat profile, and clean-traffic bandwidth to peak legitimate load with growth headroom.
  3. Elastic protection and cost capping: Elastic protection bandwidth scales mitigation capacity beyond the contracted baseline during active attacks, billed against the peak observed during the attack. An explicit upper bound should be configured to cap cost exposure; without a cap, a prolonged terabit-scale attack can produce significant unbudgeted charges.

Conclusion

Anti-DDoS Pro mitigates volumetric attacks through managed traffic diversion and scrubbing at the network edge. Effectiveness depends on three architectural commitments: that all public traffic is diverted through the scrubbing layer, that the origin is hardened against direct access from any other source, and that protection policies are calibrated to the workload's traffic profile rather than left at defaults.

Engineers extending this model should evaluate three patterns. Anti-DDoS Premium provides equivalent scrubbing with a globally distributed ingress for workloads with cross-border traffic. Web Application Firewall, deployed alongside Anti-DDoS Pro, applies signature and behavioural inspection at the HTTP semantic layer for application-layer attacks that mimic legitimate request patterns. Anti-DDoS-integrated CDN distributes scrubbing across the CDN edge for workloads where attack tolerance must combine with content delivery acceleration.


Disclaimer: The views expressed herein are for reference only and don't necessarily represent the official views of Alibaba Cloud.

0 1 0
Share on

PM - C2C_Yuan

105 posts | 2 followers

You may also like

Comments

PM - C2C_Yuan

105 posts | 2 followers

Related Products