Alibaba Anti-DDoS + Cloud Firewall, in depth: blackhole thresholds, Origin versus Proxy, the three firewall borders, policy as code and an attack runbook

The free baseline: Anti-DDoS Origin Basic and blackholing

Every public IP on supported Alibaba Cloud assets, such as ECS instances, load balancers and NAT gateways, gets Anti-DDoS Origin Basic at no charge. It detects and scrubs attacks up to a mitigation capacity that, according to Alibaba's documentation, ranges from 500 Mbit/s to 5 Gbit/s depending on region and on the asset's specification and purchased bandwidth. You can see the exact figures for each asset on the Assets page of the Traffic Security console, along with configurable BPS and PPS thresholds that decide when scrubbing starts.

When an attack exceeds that capacity, Alibaba applies blackhole filtering: all inbound traffic to the attacked IP is dropped upstream, legitimate users included, to protect the shared network. The documented default is 2.5 hours, and the actual duration ranges from 30 minutes to 24 hours depending on how frequent and sustained attacks on that IP have been. Frequently attacked assets get longer blackholes and lower thresholds. Without a paid Anti-DDoS product you cannot lift a blackhole early; you wait. That single fact is the usual reason teams buy protection: the attack itself is often short, but the outage it triggers is not.

Anti-DDoS Origin versus Anti-DDoS Proxy

The paid products take two architectural approaches. Documentation paths still use the older names Anti-DDoS Pro and Anti-DDoS Premium for the proxy products; the current names are Anti-DDoS Proxy (Chinese Mainland) and Anti-DDoS Proxy (Outside Chinese Mainland).

Choose Origin when services must keep their IPs, for example when partners allowlist them, when attacks are moderate, and when everything runs on Alibaba Cloud. Choose Proxy for public websites and game or API front ends that attract large attacks, for origins outside Alibaba Cloud, or when you serve users in mainland China and elsewhere from different scrubbing networks. Blackhole deactivation limits differ by product: Alibaba documents a maximum of five deactivations a day for Proxy (Chinese Mainland), each after a minimum two-minute blackhole, and a monthly quota for Origin plans.

Onboarding a website to Anti-DDoS Proxy

1. Add the domain in the Proxy console, choose the protocol and ports, and enter the origin addresses. The console issues a CNAME for the domain.
2. Upload the TLS certificate if the proxy terminates HTTPS, so layer 7 protection can see requests.
3. Before switching DNS, test locally by pointing a hosts entry at the proxy and checking that pages, redirects and WebSockets work. Alibaba documents this verification step.
4. Add the proxy's back-to-origin CIDR blocks, listed in the Website Config page, to the origin's security groups and any host firewall. Then remove every other inbound rule on the service ports.
5. Lower the record's TTL a day ahead, then change the DNS record to the CNAME so you can roll back quickly; the TTL and failover mechanics are the same as in DNS failover and traffic steering.
6. Rotate the origin's public IP if it was ever exposed, because historical DNS records and certificate logs let attackers find it and send traffic straight past the proxy.

For non-HTTP services, create port forwarding rules on the proxy instead of a CNAME and point clients at the proxy's IP. Client source IPs then arrive as proxy addresses, so check how your service recovers the real client address before relying on it for rate limiting or logging.

Cloud Firewall: three borders

Cloud Firewall is a managed, stateful firewall with intrusion prevention, applied at three borders. The Internet firewall covers inbound and outbound traffic between the Internet and public IPs, IPv4 and IPv6. The NAT firewall covers private assets reaching the Internet through a NAT gateway, which is where you control egress from workloads that have no public IP. The VPC firewall covers traffic between VPCs and between VPCs and on-premises networks, including networks joined through Cloud Enterprise Network.

Editions decide which borders you get. Alibaba lists Free, Premium, Enterprise and Ultimate editions and a pay-as-you-go option. Premium centres on the Internet border with IPS and traffic analysis; Enterprise adds VPC firewalls, centralised security group management and multi-account management; Ultimate adds protection of traffic between VPCs across accounts. Pay-as-you-go covers the Internet firewall with inbound and outbound controls.

Security groups do not go away. They are per-instance, stateful and free, and they remain the last check; the general VPC, subnet and security group model is covered in cloud networking architecture. Cloud Firewall adds what security groups lack: one policy view across accounts, application identification (it can match HTTP, SSH or MySQL traffic regardless of port), domain-based destinations for egress, logging and IPS.

The policy model and IPS

Access control policies are evaluated in priority order, where 1 is the highest priority. Each policy has a source (CIDR, address book or region), a destination (CIDR, address book, domain or region), protocol, destination port or port group, application and an action. The console shows the actions as Allow, Monitor and Deny; the API uses accept, log and drop. Monitor passes the traffic but records matches, which is how you test a rule before enforcing it.

IPS runs separately from access control. In monitor mode it logs and alerts on attacks without blocking; in block mode it blocks with a loose, medium or strict rule set, trading false positives against coverage. Start new deployments in monitor mode for one or two weeks, review what would have been blocked, then move to block-medium.

Policy as code with the CLI

Clicking rules into a console does not survive audits or multiple accounts. Keep policies in a reviewed file and push them with the Alibaba Cloud CLI, which exposes the AddControlPolicy API. The parameter names below are taken from the API reference.

# Internet border, inbound: allow HTTPS from anywhere to the public load balancer
aliyun cloudfw AddControlPolicy \
  --Direction in --AclAction accept --Proto TCP \
  --SourceType net --Source 0.0.0.0/0 \
  --DestinationType net --Destination 203.0.113.10/32 \
  --DestPortType port --DestPort 443 \
  --ApplicationName HTTPS \
  --NewOrder 1 --Description "web: public HTTPS to SLB"

# Internet border, outbound: let a public instance reach one package mirror by domain.
# A lower-priority log (Monitor) rule for other outbound HTTPS would show what else it calls.
aliyun cloudfw AddControlPolicy \
  --Direction out --AclAction accept --Proto TCP \
  --SourceType net --Source 203.0.113.20/32 \
  --DestinationType domain --Destination mirrors.example.com \
  --DestPortType port --DestPort 443 \
  --ApplicationName HTTPS \
  --NewOrder 1 --Description "egress: package mirror"

These rules apply at the Internet border. Egress from private workloads behind a NAT gateway is governed by NAT firewall policies, which are managed separately.

Before pushing, lint the file. A short check catches the mistakes that cause incidents: an allow rule from 0.0.0.0/0 to a management port, a broad rule ordered above a narrow one so the narrow one never matches, and drops added directly without a monitor period.

MGMT_PORTS = {"22", "3389", "3306", "6379"}

def lint(policies):
    errors = []
    for i, p in enumerate(sorted(policies, key=lambda p: int(p["NewOrder"]))):
        if p["AclAction"] == "accept" and p["Source"] == "0.0.0.0/0" and p.get("DestPort") in MGMT_PORTS:
            errors.append(f"{p['Description']}: management port open to the Internet")
        if p["AclAction"] == "drop" and not p.get("monitored_days", 0) >= 7:
            errors.append(f"{p['Description']}: run as log (Monitor) for 7 days before drop")
        if p["Source"] == "0.0.0.0/0" and not p.get("DestPort") and i < len(policies) - 1:
            errors.append(f"{p['Description']}: catch-all ordered above more specific rules")
    return errors

Observability and data flow

Each layer sees a different slice of an incident, so wire all of them into one place before you need them. The Anti-DDoS consoles show inbound bandwidth and packet rate per IP, scrubbed versus forwarded traffic and blackhole events; Cloud Firewall records policy hits, IPS events and traffic logs per border; the load balancer and application logs show what finally arrived. Ship the firewall and proxy logs to your log service, keep them long enough to compare with the previous attack, and alert on three signals: an IP entering blackhole, origin traffic arriving from outside the back-to-origin ranges, and a sudden rise in Monitor-rule hits after a deployment, which usually means a new dependency nobody added to the allowlist.

A worked attack

A shop runs its storefront on two ECS instances behind a load balancer with only Anti-DDoS Origin Basic. At 20:00 a 12 Gbit/s UDP reflection attack hits the load balancer's IP, well above Basic capacity, and the IP is blackholed. The site is down for the full blackhole period because nobody can lift it, and the attack itself stopped after 15 minutes.

After the incident the team moves the storefront behind Anti-DDoS Proxy with a CNAME, locks the origin's security group to the back-to-origin CIDR blocks, rotates the load balancer's IP, adds Cloud Firewall in front of the remaining public IPs with IPS in block-medium and an allowlist of HTTPS and the payment provider's callback ranges, and puts egress from the application subnet through a NAT firewall with domain rules. The next attack, at similar size, is absorbed at the scrubbing centre; the origin sees normal traffic, and the dashboards show only a rise in dropped traffic on the proxy.

Runbook and failure modes

• During an attack: confirm in the Traffic Security console whether the IP is scrubbing or blackholed; if blackholed and you hold a paid plan, deactivate within your quota only once the attack has subsided, or it will re-trigger.
• Origin leak: traffic to the origin from outside the back-to-origin ranges means attackers have found it. Rotate the IP and audit DNS history, mail headers and certificate transparency logs.
• Health checks blocked: load balancer and monitoring probes must be allowed through Cloud Firewall and security groups, or a new deny rule takes the service down.
• Asymmetric routing: adding a VPC firewall to an existing CEN path changes routing; schedule it, and test connections in both directions.
• IPS false positives: moving straight to block-strict breaks unusual but legitimate clients. Promote one level at a time.
• Cost surprise: proxy plans and firewall editions are billed on protected bandwidth and assets; size from real peak legitimate traffic, not from total instance bandwidth.

What to do next

1. List every public IP and check its Basic mitigation threshold and blackhole history in the Traffic Security console.
2. Decide per service between Anti-DDoS Origin and Anti-DDoS Proxy using the table above; put public websites behind Proxy.
3. When onboarding to Proxy, restrict the origin to back-to-origin CIDR blocks and rotate any previously exposed IP.
4. Enable Cloud Firewall on the Internet border, with IPS in monitor mode for one to two weeks, then block-medium.
5. Move policies into a reviewed file, lint them, and push with the CLI; add NAT firewall egress rules by domain.
6. Write and rehearse the attack runbook, including who can lift a blackhole and what the remaining quota is.