FAQs about web service addition - Web Application Firewall

This topic provides answers to frequently asked questions about adding web services to Web Application Firewall (WAF) 3.0.

Overview

Questions about WAF capabilities
Issues that may occur when web services are added to WAF
- I cannot find the CLB, NLB, or ECS instance to add on the Website Configuration page. What do I do?
- When I add an HTTPS listener port of a CLB instance to WAF, the system prompts that the certificate required for instance is incomplete. What do I do?
Issues that may occur on origin servers after web services are added to WAF
- WAF returns HTTP 502 status codes after web services are added to WAF. What do I do?
- File upload fails after web services are added to WAF. What do I do?

What is the difference between the origin IP address and the back-to-origin IP address in WAF?

Back-to-origin IP address of WAF The back-to-origin IP address of WAF refers to the IP address range that WAF uses to forward legitimate traffic to the origin server after security inspection. These IP addresses are assigned by Alibaba Cloud and identify WAF as the proxy server that initiates requests to the origin server.
- The back-to-origin IP address range is typically fixed.
- From the perspective of the origin server, all requests from clients are intercepted and forwarded by WAF. The originating IP addresses of clients are recorded in HTTP header fields, such as X-Forwarded-For or custom header fields.
Origin IP address The origin IP address refers to the public IP address of the backend server that hosts your business or the IP address resolved from the domain name. It is the destination address that ultimately receives requests and returns responses when users access your website.
- The origin IP address can be a single IP address or multiple IP addresses (for load balancing).
- The origin IP address is the actual service address of your website, which can be deployed on Alibaba Cloud ECS, SLB, OSS, or other cloud service providers.

Can I use the private IP address of an ECS instance as an origin IP address?

No, you cannot. This is because WAF forwards requests to an origin server over the Internet.

Can WAF protect multiple origin IP addresses for one domain name?

Yes, you can enter a maximum of 20 origin IP addresses when you add a domain name in the WAF console.

How does WAF balance request loads among origin servers?

If you configure multiple origin servers, WAF automatically uses the IP hash method to balance request loads among these origin servers. You can also use other load balancing algorithms based on your business requirements. For more information, see Add a domain name.

Does WAF support the health check feature?

Yes, WAF supports the health check feature, which is enabled by default. WAF checks the availability of all origin IP addresses. If an origin server is unavailable, WAF forwards the requests to another origin server.

If an origin server does not respond, WAF automatically sets a cooldown period for the origin server. After the period ends, WAF may still forward requests to the origin server.

Can a WAF instance that uses an exclusive IP address defend against DDoS attacks?

An exclusive IP address prevents other domain names from becoming inaccessible when a domain name is under large-volume DDoS attacks. For more information, see Benefits of exclusive IP addresses.

Can WAF be deployed together with CDN or with Anti-DDoS Pro or Anti-DDoS Premium?

Yes, WAF is fully compatible with Alibaba Cloud CDN and Anti-DDoS Proxy. If you want to deploy WAF together with Alibaba Cloud CDN or Anti-DDoS Proxy, you need to only set the address of the origin server to the CNAME assigned by WAF when you add a domain name to Alibaba Cloud CDN or Anti-DDoS Pro. When the address of the origin server is set to the CNAME assigned by WAF, requests are forwarded by Alibaba Cloud CDN or Anti-DDoS Proxy to WAF and then to the origin server. For more information, see Use Anti-DDoS Pro and WAF to protect your website and Use WAF and CDN to protect a domain name that has CDN acceleration enabled.

Can I deploy WAF together with CDN and Anti-DDoS Pro or Anti-DDoS Premium by using different Alibaba Cloud accounts?

Yes, you can deploy WAF together with CDN and Anti-DDoS Pro or Anti-DDoS Premium by using different accounts. This allows you to defend against DDoS attacks and web application attacks.

How does WAF ensure the security of an uploaded certificate and its private key? Does WAF decrypt HTTPS traffic and record the content of HTTPS requests?

If you use WAF to protect HTTPS services, you must upload the required SSL certificate and its private key. This way, WAF can decrypt HTTPS traffic to detect attacks and analyze the characteristics of attacks. Alibaba Cloud uses a dedicated key server to store and manage private keys. The key server is based on Alibaba Cloud Key Management Service (KMS) and can ensure the data security, integrity, and availability of certificates and private keys. This helps meet the requirements for regulation, classified protection, and compliance. For more information about KMS, see What is Key Management Service.

WAF uses an uploaded certificate and its private key to decrypt HTTPS traffic only in scenarios where attacks are detected in real time. WAF records only specific content of request payloads. The content is determined based on attack characteristics. Then, WAF can provide attack reports and data statistics based on the content. WAF can record the full content of requests or responses only when WAF is authorized.

WAF has passed various authoritative certifications, including ISO 9001, ISO 20000, ISO 22301, ISO 27001, ISO 27017, ISO 27018, ISO 27701, ISO 29151, BS 10012, Cloud Security Alliance (CSA) STAR certification, Cybersecurity in China Multi-level Protection Scheme (MLPS 2.0) Level III, Service Organization Control (SOC) 1, SOC 2, SOC 3, Cloud Computing Compliance Controls Catalog (C5), Green Finance Certification Scheme developed by Hong Kong Quality Assurance Agency (HKQAA), Outsourced Service Provider's Audit Report (OSPAR), and Payment Card Industry Data Security Standard (PCI DSS). WAF also provides the same security and compliance qualifications as Alibaba Cloud. For more information, see Alibaba Cloud Trust Center.

A domain name is added to WAF. Why am I unable to find the domain name in the domain name list?

The domain name may have been automatically removed by WAF. This happens when the ICP filing information of the domain name is invalid. You must complete an ICP filing for the domain name and add the domain name to WAF again. For more information about ICP filing in Alibaba Cloud, see ICP filing process.

Important

Before you add a domain name to a WAF instance in the Chinese mainland for protection, make sure that the ICP filing information of the domain name is valid. To comply with relevant laws and regulations, WAF instances in the Chinese mainland regularly remove domain names whose ICP filing information is invalid.

How does WAF obtain and record the originating IP addresses of clients by using custom header fields?

WAF obtains the originating IP addresses of clients in the following way: If a Layer 7 proxy is deployed in front of WAF, such as Anti-DDoS Proxy or Alibaba Cloud CDN, you can use custom header fields, such as X-Client-IP and X-Real-IP, to include the originating IP addresses of clients in request headers. This prevents attackers from forging the X-Forward-For header to bypass the detection of WAF and enhances business security. After you configure a custom header field in WAF, WAF uses the value of the header field as the originating IP address of a client. If you configure multiple custom header fields, WAF reads the originating IP addresses of clients from the header fields in sequence.

WAF records the originating IP addresses of clients in the following way: When you add a website to WAF, you can enable the traffic marking feature. The feature allows WAF to record the originating IP addresses of clients in custom header fields when WAF forwards requests to the origin server. This way, the origin server can obtain the originating IP addresses of clients from the custom header fields for business analysis.

I cannot find the CLB, NLB, or ECS instance to add on the Website Configuration page. What do I do?

Problem description

You cannot find the Classic Load Balancer (CLB), Network Load Balancer (NLB), or Elastic Compute Service (ECS) instance that you want to add to WAF on the Website Configuration page.

Solution

Cause	Operation
The CLB, NLB, or ECS instance does not meet the requirements.	Verify that the CLB, NLB, or ECS instance meets the requirements specified in the "Limits" section in the following topics: Enable WAF protection for a Layer 7 CLB instance, Enable WAF protection for a Layer 4 CLB instance, Enable WAF protection for an NLB instance, and Enable WAF protection for an ECS instance.
The required listener is not added to the CLB instance.	Add a listener to a Layer 7 CLB instance. For more information, see Add an HTTP listener and Add an HTTPS listener. Add a listener to a Layer 4 CLB instance. For more information, see Add a TCP listener.
The CLB, NLB, or ECS instance is not synchronized to WAF.	Log on to the WAF 3.0 console. In the top navigation bar, select the resource group and region of the WAF instance. You can select Chinese Mainland or Outside Chinese Mainland. In the left-side navigation pane, click Website Configuration. Select the required cloud service and click Add. In the panel that appears, click Synchronize Instances.

When I add an HTTPS listener port of a CLB instance to WAF, the system prompts that the certificate required for instance is incomplete. What do I do?

Problem description

When you add an HTTPS listener port of a CLB instance to WAF, WAF checks the source of the certificate configured for the port. The following error message appears: The CLB certificate whose port number is {port} is incomplete. Go to the SLB console and select a certificate that is from Certificate Management Service.

Cause

The certificate is not purchased by using Alibaba Cloud Certificate Management Service and is not uploaded to Certificate Management Service.
The certificate configured for the HTTPS listener port of the CLB instance is uploaded in the CLB instance. In this case, the certificate cannot be automatically synchronized to Certificate Management Service. However, WAF obtains certificate information only from Certificate Management Service. As a result, WAF cannot obtain the complete information of the certificate and the error message appears.
The certificate was uploaded to Certificate Management Service but was manually deleted. In this case, WAF cannot obtain the information about the certificate from Certificate Management Service.

Solution

Upload your certificate to Certificate Management Service. For more information, see Upload an SSL certificate.
Add the certificate in the CLB console and select Alibaba Cloud Certificates for Select Certificate Source. For more information, see Use a certificate from Alibaba Cloud SSL Certificates Service.
In the CLB console, select the added certificate for your port. For more information, see Step 2: Configure an SSL certificate.

WAF returns HTTP 502 status codes after web services are added to WAF. What do I do?

Problem description

When you access the web services that are added to WAF, WAF returns HTTP 502 status codes. Logs are queried, and the results include requests for which WAF returns HTTP 502 status codes.

Cause and solution

Scenario 1: HTTP 502 status codes are returned in CNAME mode

In CNAME mode, when the origin server (such as an ECS or CLB instance) is inaccessible to WAF, HTTP 502 status codes may be returned in some cases. We recommend that you first check for rules or software that may restrict WAF access, such as security groups, iptables, firewalls, Security Dog, or Cloud Lock. For example, you need to allow access from WAF back-to-origin CIDR blocks in the security group of your ECS instance.

You also need to ensure that the domain name and origin server information configured in the WAF console match your actual business. Mismatched domain name and origin server information can also cause this error.

Scenario 2: HTTP 5XX status codes are occasionally returned after you enable WAF protection for a Layer 7 CLB instance

Current network architecture

Cause analysis

The timeout period of idle connections from WAF to CLB is 3,600 seconds, equivalent to 1 hour.

If no data is transmitted over a connection from WAF to CLB within 1 hour, WAF automatically closes the connection.

The timeout period of idle connections from CLB to WAF is 15 seconds.

In this case, WAF serves as the clients of CLB. If no data is transmitted over a connection from CLB to WAF within 15 seconds, CLB automatically closes the connection.

In extreme cases, WAF returns a back-to-origin request to CLB over a persistent connection at the point in time when the connection is aged. CLB ages a persistent connection if no data is transmitted over the connection within 15 seconds. In this case, CLB does not store information about the persistent connection and sends an RST packet to terminate the connection. In this case, WAF logs the request by using an HTTP 502 status.

Solution

Change the value of the Timeout Period of Idle Keep-alive Requests parameter in the configuration of the CLB instance to a value that is shorter than the timeout period of idle connections from CLB to WAF. For example, you can change the value to 14 seconds.

Scenario 3: HTTP 502 status codes are returned if URIs are excessively long

Current network architecture

Cause analysis

Layer 7 CLB serves as the next hop when WAF forwards traffic. However, CLB supports only requests whose Uniform Resource Identifiers (URIs) are up to 32 KB in length. If the URI length of requests exceeds the upper limit, CLB rejects the requests. In this case, CLB records HTTP 414 status codes in logs, and WAF returns HTTP 502 status codes.

Solution

Reduce the URI length. For large amounts of data, use the POST method to transmit data.

Scenario 4: HTTP 502 status codes are occasionally returned by multiple Layer 4 CLB instances to which WAF forwards back-to-origin requests

Current network architecture

In the current network architecture, web services are added to WAF in reverse proxy mode. WAF forwards back-to-origin requests to multiple Layer 4 CLB instances. The ECS instances serve as backend servers for the CLB instances and listen to the same port.

Cause analysis

If an ECS instance serves as a backend server for multiple Layer 4 CLB instances and the CLB instances use the same backend server port, the following issue may occur: If multiple clients concurrently request the web service provided by CLB and the requests are forwarded by the same node of WAF to CLB, connections to the web service may fail or time out because the same back-to-origin IP address is used and causes conflicts at the TCP layer.

Case 1: Five-tuple conflicts and TCP stream disorder

When WAF protects multiple CLB instances, the instances may receive requests from the same back-to-origin IP address of WAF.

When a WAF instance node forwards a back-to-origin request to CLB1, the connection (WIP:CPORT->VIP1:VPORT1) is converted to (WIP:CPORT->DIP:DPORT) when it reaches the backend ECS instance.
When a WAF instance node forwards a back-to-origin request to CLB2, the connection (WIP:CPORT->VIP2:VPORT2) will be converted to (WIP:CPORT->DIP:DPORT) when it reaches the backend ECS.
The connection fails to establish because of conflicts in the sequence numbers and status of the two TCP connections on the backend server. Specifically, the two initiated TCP connections are considered to have the same five-tuple (TCP:WIP:CPORT:DIP:DPORT) on the backend server. This type of five-tuple conflict may cause SYN packets to be discarded.

Case 2: Response disorder

In a complete request path, the CLB instance that initiates the request differs from the CLB instance that returns the response.

When WAF sends a SYN packet to CLB2, the five-tuple is WIP:CPORT->VIP1:VPORT1. After the packet reaches the backend ECS2, the five-tuple becomes WIP:CPORT->DIP:DPORT.
If ECS2 has a connection in the TIME-WAIT state with the five-tuple TCP:WIP:CPORT:DIP:DPORT at this time, it receives the SYN packet from the first step, determines that the SYN is valid, and responds with a SYN-ACK packet.
Because ECS2 is mounted to multiple SLB instances, it might respond with SYN-ACK packets to CLB1. If CLB1 does not have a session with this five-tuple, CLB1 will reset the data packets in both directions, causing WAF to return a 502 error.

Solutions

(Recommended) Solution 1

Adjust the network architecture. For example, replace Layer 4 CLB instances with Layer 7 CLB instances to prevent request forwarding from different Layer 4 CLB instances to the same backend server on the same port.

Solution 2

Replace CLB instances with NLB instances. When you configure the NLB instances, turn off Client IP Preservation to resolve five-tuple conflicts. Then, enable the Proxy protocol for the backend servers to obtain the originating IP addresses of clients. For more information, see Enable the Proxy protocol.

Procedure

Log on to the Network Load Balancer (NLB) console.In the top navigation bar, select the region where your NLB instance is located.
In the left-side navigation pane, choose Network Load Balancer (NLB) > > Server Groups.
Find your server group and click Edit Basic Information in the Actions column. In the Edit Basic Information dialog box, turn off Client IP Preservation and save your changes.

(Not recommended) Solution 3

You can submit a ticket to enable the FULLNAT mode. When multiple CLB instances forward requests to the same backend server on the same port, FullNat modifies the source address to make the five-tuple of each connection unique, avoiding conflicts. Enable the FULLNAT mode for CLB listeners to prevent five-tuple conflicts.

File upload fails after web services are added to WAF. What do I do?

This issue may occur because the file size exceeds the maximum limit of 2 GB. WAF supports file uploads of up to 2 GB. When the request body exceeds 2 GB, WAF returns an HTTP 413 status code. You can determine whether the file transfer size limit is reached based on the returned status code.