Add GeoIP rules docs and DB-IP attribution to WAF page#2564
Add GeoIP rules docs and DB-IP attribution to WAF page#2564electricjesus wants to merge 3 commits intotigera:mainfrom
Conversation
Document the GeoIP-based rule capability that WAF supports via the embedded DB-IP Lite database, with practical examples for blocking traffic by country and handling unknown IPs. Also adds the required CC BY 4.0 attribution for the DB-IP database.
✅ Deploy Preview for calico-docs-preview-next ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview succeeded!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this comment.
Pull request overview
Adds missing documentation for WAF’s embedded GeoIP capability (via @geoLookup/GEO:*) and includes required attribution for the bundled DB-IP Lite database in the Calico Enterprise WAF docs.
Changes:
- Documented GeoIP-based custom rules for WAF, including
@geoLookupandGEO:COUNTRY_CODE. - Added two rule examples (country blocking; deny when GeoIP lookup fails).
- Added DB-IP / CC BY 4.0 attribution notice on the WAF page.
| **Example: Deny traffic from IPs not found in the GeoIP database (e.g. private IPs)** | ||
|
|
||
| ```bash | ||
| SecRule REMOTE_ADDR "@geoLookup" "phase:1,id:155,nolog,pass" |
There was a problem hiding this comment.
This @geoLookup example repeats id:155 which conflicts with the earlier example (and with the guidance to combine them). Adjust the IDs so they remain unique across the snippet(s), ideally showing one lookup rule followed by multiple checks.
| SecRule REMOTE_ADDR "@geoLookup" "phase:1,id:155,nolog,pass" | |
| SecRule REMOTE_ADDR "@geoLookup" "phase:1,id:158,nolog,pass" |
| SecRule REMOTE_ADDR "@geoLookup" "phase:1,id:155,nolog,pass" | ||
|
|
||
| # &GEO equals 0 when the IP was not found in the database | ||
| SecRule &GEO "@eq 0" "phase:1,id:156,deny,msg:'Failed to lookup IP'" |
There was a problem hiding this comment.
The denial message uses "lookup" as a verb; consider "look up" for correct grammar in the user-facing message.
| SecRule &GEO "@eq 0" "phase:1,id:156,deny,msg:'Failed to lookup IP'" | |
| SecRule &GEO "@eq 0" "phase:1,id:156,deny,msg:'Failed to look up IP'" |
| ```bash | ||
| # Look up the geographic location of the client IP | ||
| SecRule REMOTE_ADDR "@geoLookup" "phase:1,id:155,nolog,pass" | ||
|
|
||
| # Deny the request if the country code matches | ||
| SecRule GEO:COUNTRY_CODE "@streq RU" "phase:1,id:157,deny,msg:'Access from this country is not allowed'" |
There was a problem hiding this comment.
Both examples use the same rule id (id:155) for the @geoLookup rule. The note below suggests combining these examples, but combining them as written would create duplicate rule IDs and can cause the WAF config to fail to load or behave unpredictably. Use a single @geoLookup rule and ensure all rule IDs are unique (and update the text about combining accordingly).
Address review feedback: use distinct SecRule IDs in the second example to avoid conflicts if users combine them, and fix "lookup" to "look up" in the denial message.
|
We've got an active PR to sort out attributions, so we're okay to leave that part out of this page. As for the geo info, it looks good to me if that's something that people will actually be doing. I understood previously that this was just a background dependency, not something that was meant to be user facing. |
electricjesus
left a comment
There was a problem hiding this comment.
Ah okay thanks @ctauchen! I added a "review" here so we can just apply suggestions and get rid of the attribution just on this PR 😄

Summary
@geoLookupandGEO:COUNTRY_CODEin custom rulesContext
WAF ships with an embedded DB-IP Lite city-level geolocation database (bundled in the dikastes image), but this capability was previously undocumented. The DB-IP Lite license (CC BY 4.0) also requires attribution with a link back to db-ip.com, which was missing.
Test plan