This topic describes the data security and compliance considerations related to local laws when you use Alibaba Cloud Web Application Firewall (WAF) 3.0.
Security compliance for WAF CNAME connections
If your origin server is deployed in the Chinese mainland, you must activate a WAF instance in the Chinese mainland and complete the ICP filing for your domain name before you connect to WAF using a CNAME record.
If your website or app is hosted on an Alibaba Cloud server in the Chinese mainland, and an ICP filing has not been obtained for the entity or the domain name, you must complete the ICP filing through the Alibaba Cloud ICP Filing system before you can make the service for your website or app publicly accessible.
If the entity and the domain name already have an ICP filing through another service provider, and you want to switch to or add Alibaba Cloud as a service provider, you must add Alibaba Cloud to the ICP filing information as a service provider.
For more information about how to add a domain name using a CNAME record, see Protect a website using a CNAME record.
If your origin server is deployed outside the Chinese mainland, activate a WAF instance outside the Chinese mainland. WAF is available in China (Hong Kong), Singapore, Dubai, Japan (Tokyo), Malaysia (Kuala Lumpur), Indonesia (Jakarta), US (Silicon Valley), and Germany (Frankfurt). If your origin server is deployed in a region where WAF is not available, your traffic is routed to the WAF cluster in Singapore.
WAF security reports and data storage locations: The control plane that manages a WAF instance and the storage location of its data depend on the instance's region. WAF instances in the Chinese mainland are managed by the control plane in China (Hangzhou), and their data is stored in data centers in the Chinese mainland. WAF instances outside the Chinese mainland are managed by the control plane in Singapore, and their data is stored in data centers in Singapore. On the Security Reports page, you can centrally view protection statistics and log information for all your protected resources. The displayed charts and information are based on the control plane that corresponds to the region of your WAF instance.
Notes on cross-border data transfer:
When you use the CNAME connection feature of WAF, your business data is transferred to the region that you select or the region where the product is deployed. This may involve cross-border data transfer.
You agree and confirm that you have the full rights to manage this business data and are solely responsible for the data transfer.
You must ensure that your data transfer complies with all applicable laws. This includes providing adequate data security technologies and policies, and fulfilling legal obligations such as obtaining explicit consent from individuals and completing data export security assessments and declarations. You also agree that your business data does not contain any content that is restricted or prohibited from being transferred or disclosed under applicable laws.
If you fail to comply with the preceding statements and guarantees, you will be held responsible for the corresponding legal consequences. If Alibaba Cloud or its affiliates incur any losses as a result, you are liable to provide compensation.
To avoid cross-border data transfer issues, you can connect to WAF using the cloud native mode or hybrid cloud connection types.
Opening non-standard WAF ports
Some scanners may report that domain names connected to WAF via a CNAME record have listeners on ports other than 80 and 443, and may flag these as vulnerable ports. Alibaba Cloud WAF forwards data only for ports configured in the console after a successful TCP three-way handshake. For unconfigured ports, WAF immediately sends an RST packet to close the connection after the TCP three-way handshake, and no data is forwarded. The ports identified as vulnerable by scanners do not pose an actual security threat.
By default, WAF blocks certain vulnerable ports, which prevents the TCP three-way handshake from completing. These ports are: 9, 20, 21, 22, 23, 25, 42, 53, 67, 68, 69, 135, 137, 138, 139, 143, 161, 389, 445, 593, 1434, 1521, 3127, 3306, 3389, 4444, 5554, 5800, 5900, 6379, 9996, 11211, 27017, 27018, 50030, 50070, 61613, 61616, and 61617.
Supported cipher suites in WAF
When you use the CNAME, ECS, or Layer 4 CLB (TCP) connection type to protect your HTTPS services with WAF, you can customize the cipher suites that WAF uses according to the cipher suites supported by your origin server. This ensures that WAF listens only to requests from clients that support the customized cipher suites. For more information about the cipher suites that WAF supports, see Supported cipher suites in WAF.
If you use the Layer 7 CLB (HTTP/HTTPS) connection type, WAF automatically synchronizes its cipher suite configuration with that of the origin CLB instance.
WAF log storage
Simple Log Service for WAF lets you collect and store web access logs and mitigation logs for objects protected by WAF, such as cloud service instances and domain names. Built on Alibaba Cloud Simple Log Service, this service provides features such as query analysis, statistical charts, an alert service, and integration with downstream computing and delivery services. This frees you to focus on analysis rather than on tedious query and organization tasks.
By default, Simple Log Service for WAF is disabled. To store and analyze log data for your protected objects, you must first enable the service and select a log storage region.
For more information about the configuration, usage, and billing of Simple Log Service for WAF, see Log Management. For more information about compliance issues related to cross-border log queries, see Query logs across Logstores.
The log storage region that you select when you enable Simple Log Service for WAF cannot be changed later. To change the region, you must release the WAF instance. Therefore, carefully select a log storage region before you enable the service.
WAF cookie insertion
WAF inserts cookies for your services in the following three scenarios.
Scenario 1: When you use features such as HTTP flood protection and scan protection, if a request does not contain the acw_tc cookie, WAF, by default, inserts the acw_tc cookie into the response.
WAF inserts a cookie into a client, such as a browser, to differentiate between and track clients. When the client accesses the website, the HTTP message includes this cookie. WAF uses this cookie information, along with your configured HTTP flood protection rules and session-based rules for scan protection and custom frequency control, to determine whether the service traffic contains HTTP flood attacks.
To disable cookie insertion in this scenario, log on to the Web Application Firewall console. In the top menu bar, select the resource group and region of your WAF instance. Then, navigate to Mitigation Settings > Protected Object > Settings and configure the Cookie Settings for a specific cloud service instance or domain name.
For more information on cookie settings, see Configure protected objects and protected object groups.
Scenario 2: The scenario-specific bot management module is configured for a cloud service instance or domain name, and automatic web SDK integration is enabled.
When you configure a scenario-specific bot management template and enable automatic web SDK integration, WAF inserts the ssxmod_itna, ssxmod_itna2, and ssxmod_itna3 cookies into the HTTP message header to collect the client's browser fingerprint. This fingerprint includes information such as the Host field of the HTTP message and the browser's height and width.
To disable cookie insertion in this scenario, you must disable the corresponding bot management template. For more information, see Bot management (Legacy).
Scenario 3: Custom rules or bot management is configured for a cloud service instance or domain name, where the rule action is set to JavaScript (JS) challenge or slider challenge.
When traffic hits a rule, WAF challenges the client with a JS or slider challenge. If the client passes the challenge, WAF inserts the acw_sc__v2 and acw_sc__v3 cookies into the HTTP message header to mark the client as authenticated.
To disable cookie insertion in this scenario, go to Mitigation Settings > Protection Rules or Mitigation Settings > Scenario-specific Protection > Bot Management > Scenario-specific Protection and disable the corresponding protection rule or policy. For more information about JS Challenge and Slider, see Custom rules or Bot management (Legacy).
Data collection for the app protection feature of WAF bot management
Web Application Firewall provides a Software Development Kit (SDK) for native apps, such as Android and iOS, to enhance protection in this scenario. Once integrated, the SDK collects risk features from the client and generates a security signature for requests. WAF then uses this signature to detect and block threats.