Walkthrough: Setting up geo-blocking without breaking our legit APAC traffic.

Our initial implementation of geographic threat mitigation on Radware's Cloud WAF created an immediate and severe operational incident: we successfully blocked a significant volume of malicious traffic from regions we had no business in, but we also severed all connections from our legitimate, contracted partners in South Korea and Japan. The error was architectural, not merely configurational. We treated geo-blocking as a simple "allow/deny list" at the edge, which is fundamentally incompatible with a globally distributed business presence.

The core failure was applying a blanket country-code block at the WAF policy level, which lacks the granularity to distinguish between, for example, a malicious script kiddie in Country X and a known-good API client from a partner's data center in that same country. The solution required a layered security model that decouples *initial filtering* from *trusted source validation*. Here is the refined workflow we deployed:

1. **Initial Geo-Filter at the Edge:** A broad, restrictive geo-block is applied at the Radware WAF policy level. This catches the bulk of unsophisticated, geographically-based attacks.
2. **Exception via Verified Source Lists:** Legitimate traffic from blocked regions is permitted only if it passes a subsequent, more granular check. This is achieved by leveraging Radware's "Source IP/CIDR" allow list feature, which is evaluated *after* the geo-policy but before the request is passed upstream.

The critical implementation detail is the orchestration of the allow list. Maintaining a static list is untenable. We manage it as dynamic infrastructure, treating the allow list as code. Our partners' egress IPs are published as AWS Security Group IDs, which we then ingest and transform into a Radware-compatible format using a Terraform module.

```hcl
# Example Terraform data source to fetch partner egress IPs (conceptual)
data "aws_security_group" "partner_asia_egress" {
id = "sg-0xyz123"
}

# Module to convert and update Radware Source List
module "radware_asia_allowlist" {
source = "./modules/radware-ip-list"

list_name = "partner-asia-legacy-egress"
ip_cidrs = data.aws_security_group.partner_asia_egress.ipv4_cidr_blocks
waf_policy_id = radware_waf_policy.main.id
}
```

This setup is coupled with a CI/CD pipeline that validates changes and applies them on a scheduled basis. The observability pillar is covered by shipping Radware WAF logs to our SIEM, with a dedicated dashboard tracking:
* Total requests blocked by geo-policy.
* Requests from blocked regions that were permitted via source list.
* Alerting on any successful request from a blocked region *not* on the source list (potential false negative or new partner infrastructure).

The result is a defensive posture that is both aggressive and precise. We maintain a default-deny stance for entire geographic regions, while programmatically allowing a continuously verified set of legitimate business IPs. This pattern has proven robust and is now a template for other nuanced access-control scenarios, like permitting specific security scanner ranges while blocking general vulnerability scan traffic.

--from the trenches