Help Center/ Web Application Firewall/ Best Practices/ Configuring IP- or Geolocation-based Access Control Policies
Updated on 2026-10-14 GMT+08:00

Configuring IP- or Geolocation-based Access Control Policies

Overview

For external web services, API services, and global sites, fine-grained access control is required based on IP network segments, countries, and regions to defend against web attacks, malicious IP address scanning, and unauthorized access to backend paths. In addition, unified security rules are required for gateway traffic in different regions and global CDN acceleration traffic to enable independent protection, layered defense, and a unified security baseline.

To meet these security requirements, Huawei Cloud WAF builds an in-depth security system for access control and attack defense. It uses blacklists, whitelists, and geolocation access control as the first layer of defense. On top of these, it enables threat intelligence access control, precise access control (path-based blocking), and basic web protection to comprehensively defend against various cyber security risks.

Regional protection policies and global CDN protection policies are supported, selectable by traffic type to fit various deployment architectures. This capability is ideal for services with stringent public network access controls, such as government portals, enterprise websites, external APIs, and globally distributed sites.

Resource Preparations

  • You have enabled Huawei Cloud cloud WAF (professional edition or above), application load balancer, API Gateway, and Content Delivery Network (CDN), and have permissions to manage WAF, ELB, APIG, CDN, domain name resolution, and LTS.
  • If your origin server is deployed in the Chinese mainland, the associated domain name must have a valid Internet Content Provider (ICP) filing.
  • You have organized trusted IP addresses or IP address ranges, countries or regions that are allowed to access your website, and management paths that need to be protected.
  • You have prepared a valid SSL certificate for your HTTPS services.

Procedure

Take the following steps to configure IP address- and geolocation-based access control rules.

Step 1: Configure Basic Global Data.

  • Creating an IP Address Group

    An IP address group can be used by multiple protection policies. If IP addresses change, you only need to modify the corresponding IP address group instead of modifying rules one by one.

    1. Log in to the WAF console.
    2. In the navigation pane on the left, choose Objects > Address Groups.
    3. On the My Address Groups tab, click Add Address Group.
    4. In the Add Address Group dialog box, add the identified trusted IP addresses or IP address ranges.
      Figure 1 Adding an address group
  • Identifying the management access control list
    • Determine the countries and regions that are allowed to access the service.
    • Sort out the management paths to be blocked, such as /admin, /manage and /backend.

Step 2: Create a Protection Policy

Create a regional protection policy and a global protection policy. The rule configurations of the two policies are the same, but the resources that the policies apply to are different. You can create a regional protection policy first and copy it as a global protection policy then.

The rules are created in descending order of priority. The key configurations are as follows:

  1. Configuring a Blacklist or Whitelist Rule
    Figure 2 Configuring a blacklist or whitelist rule
    Key parameters:
    • IP Address/Range/Group: Select Address group and select the address group created in Step 1: Configure Basic Global Data..
    • Protective Action: Select Log only. WAF will then only record requests that match the rule and do not take any action.

      You are not advised to set it to Allow. If the protective action is set to Allow, WAF directly allows the current request and stops checking the rule based on subsequent rules.

    For details, see Configuring IP Address Blacklist and Whitelist Rules to Block or Allow Specified IP Addresses.

  2. Configuring a Geolocation Access Control Rule
    Figure 3 Configuring a geolocation access control rule
    Key parameters:
    • Geolocation: Select all regions that are not allowed to access your services.
    • Protective Action: Select Block. Requests from regions that are not selected will be allowed.

      You are not advised to set it to Allow. If the protective action is set to Allow, WAF directly allows the current request and stops checking the rule based on subsequent rules.

    For details, see Configuring Geolocation Access Control Rules to Block or Allow Requests from Specific Locations.

  3. Configuring a Threat Intelligence Access Control Rule
    Figure 4 Configuring a threat intelligence access control rule
    Key parameters:
    • IP Reputation Library Type: Set it to IDC and select all reputation libraries that are not allowed to access.
    • Protective Action: Select Block. Requests from reputation libraries that are not selected will be allowed.

      You are not advised to set it to Allow. If the protective action is set to Allow, WAF directly allows the current request and stops checking the rule based on subsequent rules.

    For details, see Configuring Threat Intelligence Access Control Rules to Block or Allow IP Addresses in a Specified IP Address Library.

  4. Configuring a Precise Protection Rule (Blocking Management Paths)
    Figure 5 Configuring a precise protection rule (blocking management paths)
    Key parameters:
    • Condition List
      • Field: Path
      • Logic: Include
      • Content: /admin
    • Protective Action: Log only.

      You are advised to set Protective action to Log only in the initial phase of the configuration. If no service traffic is blocked after a period of time, change Protective Action to Block. After this parameter is set to Block, requests to paths containing /admin will be blocked.

    For more details, see Configure Precise Protection Rules to Enable Custom Protection.

  5. Configuring a Basic Web Protection Rule
    Figure 6 Configuring a basic web protection rule
    Key parameters:
    • Enabling General Check, Deep Inspection, Header Inspection, Shiro Decryption Check, and Webshell Detection
    • Protection Level: Default rule set (loose)
    • Protective Action: Log only.

    You are advised to set the protection level to Default rule set (loose) and Protective Action to Log only in the initial phase of the configuration. After your service system runs for a period of time, adjust the protection level based on your service requirements. If no normal service traffic is blocked, change Protective Action to Block.

    For details, see Configuring Basic Web Protection to Defend Against Common Web Attacks.

Step 3: Apply a Policy to Resources

To make the policy you created take effect, you still need to apply it to the corresponding resources.

Applying a Policy to Regional Service Resources

This method is applicable to regional services, internal services, and dedicated APIs. You can apply a regional protection policy to them all.

  • Method 1: Connecting ELB (Application Load Balancer) to WAF
    Connect your ELB load balancer configured for your services to WAF using cloud load balancer access. For details, see Connecting Your Website to WAF Using Cloud Load Balancer Access .
    Figure 7 Cloud load balancer access
    Key parameters:
    • Policy: Select the regional protection policy created in Step 2: Create a Protection Policy.
    • ELB Load Balancer: Select the load balancer to be connected to WAF.
    • Domain Name: Enter the domain name to be protected. * indicates that all domain names are matched and all domain name traffic that passes through the ELB load balancer are protected.
    • ELB Listener: Select All listeners or Specific listener based on service requirements.
  • Method 2: Connecting APIG to WAF
    1. Connect your API Gateway to WAF using cloud CNAME access. For details, see Connecting Your Website to WAF Using Cloud CNAME Access.
      Figure 8 Cloud CNAME access
      Key parameters:
      • Protected Domain Name: Enter the external domain name of the API.
      • Protected Port: Enter the port you want to protect.
      • Server Configuration
        • Client Protocol: HTTPS
        • Server Protocol: HTTPS
        • Server Address: Enter the APIG group debugging address.
        • Server Port: Specify the service port used by WAF to access the server.
      • International: Select the certificate associated with the website.
      • Policy: Select the regional protection policy created in Step 2: Create a Protection Policy.
    2. Domain name resolution: Map the CNAME of the API domain name to the WAF CNAME address.
    3. Allow back-to-origin IP addresses: Configure an APIG access control policy that allows only WAF back-to-origin IP addresses.

Applying a Policy to Global Content Delivery Network (CDN) Traffic

This practice applies to websites and public network service sites that are accessed globally. You can apply a global protection policy to them in a unified manner.

  1. Deploy WAF and CDN together. For details, see Combining CDN and WAF to Get Improved Protection and Load Speed.
    • WAF side
      Figure 9 Cloud CNAME access
      Key parameters:
      • Protected Domain Name: Enter the external domain name of the website.
      • Protected Port: Enter the port you want to protect.
      • Server Configuration
        • Client Protocol: HTTPS
        • Server Protocol: HTTPS
        • Server Address: Enter the actual IP address of the origin server.
        • Server Port: Specify the service port used by WAF to access the server.
      • International: Select the certificate associated with the website.
      • Policy: Select the global protection policy created in Step 2: Create a Protection Policy.
    • CDN side
      Figure 10 Adding a domain name
      Key parameters:
      • Domain Names: Enter the domain name to be accelerated.
      • Origin Servers:
        • Type: Domain name
        • Address: Enter the CNAME address of the WAF instance.
  2. Allow back-to-origin IP addresses: Configure the security group for the origin server to allow only WAF back-to-origin IP address ranges.

Step 4: Perform Routine O&M

  • Rule O&M management
    • Regularly maintain IP address groups. You can add trusted IP addresses and remove unused CIDR blocks in a timely manner. Address group changes are automatically updated in protection policies. You do not have to change them in protection policies.
    • When expanding services to new regions, add the corresponding regions to the geographical location control.
    • Rule changes must follow the gray release process. For rules configured in 4 and 5, enable the Log only mode in the test environment first. After they are verified, enable the Block mode.
  • Logging and audit
    • Regularly view WAF protection logs and check details about blocked IP addresses, regions, and attacks.
    • Perform source tracing for frequently blocked sources to distinguish normal visitors from malicious attacks.
    • Enable Log Tank Service (LTS) to store protection logs for a long time, which helps meet audit and source tracing requirements.
  • Alarm configuration

    Enable WAF multi-dimensional alarm reporting in Cloud Eye for scenarios such as blocking abnormal IP addresses, unauthorized access from certain regions, high-risk online attacks, and large-scale abnormal requests. Cloud Eye will push alarm notifications via SMS messages or emails in a timely manner.

Configuration Suggestions for Your Production Environment

  • Strict back-to-origin access control: Security groups and access control policies on ELB, APIG, origin servers, and CDN origin servers are configured to allow only the WAF back-to-origin IP address range. This prevents Internet requests from bypassing WAF and directly accessing the service backend.
  • Unified certificate management: HTTPS certificates are configured on WAF in a unified manner. You do not need to configure them on backend resources and CDN again, simplifying certificate O&M and update processes.
  • Independent policy management: Regional and global protection policies are created separately to support flexible adjustments. For example, the global traffic can be restricted to specific regions as needed.
  • Gray release principle: New domain names and protection rules must run in Log only mode for 24 to 48 hours. After confirming that no false alarms are reported, switch to the block mode.
  • Handling false alarms: If legitimate access is blocked, extract the corresponding IP address or region from the protection logs and add it to the IP address whitelist or allowed region list.