Alibaba Cloud WAF Hands-on Configuration: Website Web Attack Protection Guide

Hands-on Alibaba Cloud WAF setup: CNAME onboarding, web attack protection, CC protection, and bot management against SQL injection, XSS, and malicious crawlers.

Alibaba Cloud WAF configuration is the standard process for putting a website behind a Web Application Firewall. This article uses Alibaba Cloud Web Application Firewall as the example and walks through domain onboarding, protection-rule setup, and attack verification so site owners and security engineers can stand up cloud-side protection against SQL injection, XSS, and CC attacks.

Applicable scenarios

• Site is live but lacks web-layer protection; SQL injection, XSS, and similar vulns are a concern;
• Business is hit by high-frequency CC attacks or aggressive crawler scraping;
• Compliance such as MLPS 2.0 requires web attack protection;
• Nginx and iptables already in place; need an application-layer WAF on top.

Prerequisites

• Alibaba Cloud account with real-name verification completed;
• Domain has MIIT ICP filing (required for mainland China nodes);
• Origin server is running the app; record the origin public IP and service port;
• Permission to manage the domain's DNS.

How it works

Alibaba Cloud WAF uses CNAME onboarding: change the business domain from the origin IP to a CNAME issued by the WAF cluster. User requests hit the WAF cluster first, get inspected and scrubbed, then go back to the real origin. WAF includes a web attack protection engine (SQL injection, XSS, command injection, malicious crawlers, etc.), a CC protection engine (session-rate and IP-based rate limiting), and a Bot management module. Core value: the origin IP is hidden, so attackers cannot hit the origin directly.

Procedure

Step 1: Add a protected domain

Log in to the Alibaba Cloud console, open Web Application Firewall, go to protection configuration, and add a domain:

• Domain: helixcyber.ai;
• Protocol: HTTP/HTTPS, ports 80/443;
• Origin address: choose domain/IP, enter origin IP and port;
• Back-to-origin SNI: fill in the origin domain when the origin is HTTPS;
• Enable web application attack protection and CC security protection.

Step 2: Update DNS records

After the add succeeds, the console issues a CNAME (form: xxxx.waf.aliyuncs.com). At the DNS provider, change the helixcyber.ai A record to a CNAME:

`# Before
helixcyber.ai A 1.2.3.4
# After
helixcyber.ai CNAME xxxx.waf.aliyuncs.com`

Lower the original record TTL to 600 seconds first, wait for DNS to take effect, then cut over to reduce switch risk.

Step 3: Configure protection rules

On the protection configuration page, tune these policies:

• Web attack protection: medium protection level; enable SQL injection, XSS, command injection, and related rule groups; whitelist URLs that false-positive;
• CC protection: rate-limit when a single IP exceeds 20 requests in 5 seconds (tune to business peak); enable human-machine challenge;
• Geo blocking: if the business is China-only, block overseas regions (optional);
• Bot management: enable malicious-crawler detection; identify scanner UAs and block them;
• Precise access control: write custom rules, e.g. block specific attack paths or parameters.

Step 4: Configure the HTTPS certificate

When enabling HTTPS onboarding, upload an SSL certificate on the domain details page or pick one from Alibaba Cloud SSL Certificate Service. Enable HTTPS back-to-origin and set back-to-origin port 443.

Step 5: Whitelist WAF back-to-origin IPs (recommended)

`# On the origin security group or firewall, allow only the WAF origin CIDR ranges
# Alibaba Cloud ECS security group example (follow the actual console):
# Inbound rule 1: source = WAF origin IP CIDR, protocol TCP, ports 80/443, action Allow
# Inbound rule 2: source = 0.0.0.0/0, protocol TCP, ports 80/443, action Deny
# Also restrict sources for SSH and other management ports; allow office network CIDRs only`

Once the whitelist is in place, the origin public interface only accepts WAF back-to-origin traffic. Even if the origin IP leaks, it cannot be reached directly.

Verify the configuration

`# Verify 1: confirm DNS has switched to WAF
dig helixcyber.ai +short
# should return WAF CNAME or WAF cluster IP, not the origin IP

# Verify 2: simulate SQL injection (should be blocked by WAF)
curl -s -o /dev/null -w "%{http_code}\n"   "https://helixcyber.ai/search?id=1%20and%201=1"

# Verify 3: simulate XSS probe (should be blocked by WAF)
curl -s -o /dev/null -w "%{http_code}\n"   "https://helixcyber.ai/search?q=%3Cscript%3Ealert(1)%3C/script%3E"`

Legitimate requests return 200; attack requests return the WAF block page (403/405). That means the config works. Protection logs in the console then show block records and top attack types.

FAQ

FAQ1: CNAME onboarding vs transparent onboarding (SDK/WebAgent)?

CNAME onboarding does not change origin code. Traffic is steered via DNS. Simple to deploy, but depends on DNS cutover. Transparent onboarding installs an SDK (WebAgent) on the origin; requests hit the origin first, then the SDK forwards them to WAF for inspection. Use it when DNS cannot be changed. It consumes origin resources. For typical websites, use CNAME onboarding.

FAQ2: Does the origin IP leak after WAF onboarding?

Normally no. All user traffic goes through WAF; the origin IP is visible only on WAF back-to-origin. If the origin still exposes SSH, RDP, or similar ports, attackers can still find it via port scans. Always pair this with a security-group allowlist that only permits WAF back-to-origin CIDRs, and hide unnecessary ports.

Summary

Alibaba Cloud WAF via CNAME onboarding can put web attack protection in front of a site in tens of minutes, covering SQL injection, XSS, CC attacks, and malicious crawlers. Keys: change DNS correctly, tune CC thresholds to the business, lock origin exposure with a back-to-origin allowlist, then keep iterating rules from attack simulation and protection logs.