Trusted IP Lists for FirewallD, NGINX and fail2ban

Every production firewall eventually accumulates hardcoded trusted IP lists: Stripe webhook ranges pasted into an ipset, Cloudflare CIDRs copied into an NGINX geo block, Googlebot networks whitelisted in fail2ban. They all share the same failure mode. The vendor rotates their ranges, nobody updates the server, and things break silently: webhooks stop arriving, crawlers get rate-limited into deindexing your pages, or attackers slip through ranges the vendor abandoned long ago.

The trusted-lists project from the GetPageSpeed repository solves this class of problem with the operating system’s own update mechanism. It packages the current, officially published IP ranges of 30+ services as RPM packages. Install a package once, and every dnf update refreshes the ranges from the vendor’s authoritative source. No cron scripts to write, no stale lists to remember.

This page is the canonical reference for all trusted-lists packages. For the firewall management companion tool, see fds FirewallD Made Easy; for a worked single-service example, see Whitelist OpenAI IP Ranges in NGINX and fail2ban.

How It Works

A generator fetches each service’s IP ranges directly from the vendor’s authoritative endpoint: cloudflare.com/ips for Cloudflare, openai.com/gptbot.json for GPTBot, Google’s official crawler ranges for Googlebot, Stripe’s webhook IP list for Stripe, and so on.

Package versions derive from the upstream publication timestamp, so firewalld-ipset-cloudflare-v4-20251215 means “Cloudflare ranges as published on 2025-12-15”. Packages are rebuilt only when the upstream ranges actually change. Consequently, a routine dnf update picks up new vendor ranges within a day or two of publication.

Each of the trusted IP lists ships in up to three consumable forms:

Both package families reload their consumer automatically after an update: nginx-iplist-* packages run nginx -t and reload NGINX when it is active, and firewalld-ipset-* packages run firewall-cmd --reload. An unattended dnf-automatic update therefore takes effect immediately, without manual intervention.

Installation

The trusted IP lists are available for RHEL-based distributions (RHEL, AlmaLinux, Rocky Linux, Oracle Linux, CentOS Stream) versions 8, 9 and 10, from the GetPageSpeed repository. They are architecture-independent (noarch), so x86_64 and ARM servers use the same packages. Debian and Ubuntu packages are not available yet.

Set up the repository, then install any list you need:

sudo dnf -y install https://extras.getpagespeed.com/release-latest.rpm
sudo dnf -y install firewalld-ipset-cloudflare-v4 nginx-iplist-cloudflare-v4

Available Lists

The package name is always firewalld-ipset-<list> or nginx-iplist-<list>. Lists whose upstream publishes IPv4 and IPv6 ranges separately carry a -v4 / -v6 suffix; single-package lists cover everything the vendor publishes.

Payment providers (keep webhooks flowing even under aggressive blocking):

Search engine crawlers (never rate-limit or ban a real crawler):

AI crawlers (allow or block them deliberately, at the network level):

CDN and cloud infrastructure:

SaaS callbacks and monitoring:

FirewallD Usage

Installing a firewalld-ipset-* package registers the ipset with FirewallD immediately. Verify:

sudo dnf -y install firewalld-ipset-cloudflare-v4
sudo firewall-cmd --get-ipsets

cloudflare-v4

To whitelist the service system-wide, attach the ipset to the trusted zone:

sudo firewall-cmd --permanent --zone=trusted --add-source=ipset:cloudflare-v4
sudo firewall-cmd --reload
sudo firewall-cmd --zone=trusted --list-sources

ipset:cloudflare-v4

The same ipset works for blocking: attach it to the drop zone instead to ban a service outright, which is the standard approach for unwanted AI crawlers. For zone priority subtleties, such as whitelisting one IP inside an otherwise blocked network, see FirewallD and trusted IP addresses.

NGINX Usage

Each nginx-iplist-* package provides three ready-to-include configuration files in /etc/nginx/iplist/, one per access-control pattern.

The geo Variant: a Detection Variable

<list>.geo.conf defines a geo block that sets $is_<list> (hyphens become underscores) to 1 when the client IP belongs to the service:

# /etc/nginx/iplist/cloudflare-v4.geo.conf defines $is_cloudflare_v4
geo $is_cloudflare_v4 {
    default 0;
    103.21.244.0/22 1;
    # ... all current Cloudflare IPv4 ranges
}

Include it at the http level, then use the variable anywhere. For example, expose it for testing:

include /etc/nginx/iplist/cloudflare-v4.geo.conf;

server {
    listen 8088;

    location /geo-test {
        default_type text/plain;
        return 200 "cf=$is_cloudflare_v4\n";
    }
}

Verified on Rocky Linux 10 with NGINX 1.28, requests from a Cloudflare address and a local address produce exactly what you would expect:

$ curl http://127.0.0.1:8088/geo-test
cf=0
$ curl --interface 104.16.0.1 http://104.16.0.1:8088/geo-test
cf=1

The allow Variant: Locking Down an Endpoint

<list>.allow.conf contains plain allow directives. Include it in a location and follow with deny all; to restrict the endpoint to that service. The classic use case is a payment webhook endpoint:

location /webhook/stripe {
    include /etc/nginx/iplist/stripe.allow.conf;
    deny all;

    proxy_pass http://127.0.0.1:8000;
}

Runtime-tested behavior: a request from a Stripe webhook address (3.18.12.63) receives HTTP 200, while any other source receives HTTP 403.

One gotcha worth knowing: allow and deny run in NGINX’s access phase, but a return directive in the same location executes earlier, in the rewrite phase. Therefore, a location that only contains return will answer before access control ever runs. Always pair the allow variant with real content handling (proxy_pass, try_files, static files), never with a bare return.

The nolimit Variant: Rate-Limit Bypass

Rate limiting protects your server from abusive clients, but crawlers that receive 429 or 503 responses reduce their crawl rate, and your search rankings pay for it. <list>.nolimit.conf contains bare geo entries mapping each trusted CIDR to an empty string, which is exactly what the limit_req module treats as “do not count this request”.

The complete, tested pattern:

geo $googlebot_nolimit {
    default 1;
    include /etc/nginx/iplist/googlebot-v4.nolimit.conf;
}

map $googlebot_nolimit $rate_limit_key {
    ""      "";
    default $binary_remote_addr;
}

limit_req_zone $rate_limit_key zone=perip:10m rate=2r/s;
limit_req_status 429;

server {
    listen 8088;
    root /srv/www;

    location / {
        limit_req zone=perip;
        try_files $uri $uri/ =404;
    }
}

Trusted addresses resolve to an empty $rate_limit_key and bypass the limit entirely; everyone else is keyed by their address. A burst test shows the difference immediately:

# Ordinary client, 6 rapid requests:
200 429 429 200 429 429

# Googlebot address (34.22.85.1), 6 rapid requests:
200 200 200 200 200 200

Plain Lists for Your Own Tooling

Every nginx-iplist-* package also drops the raw CIDR list into /usr/share/trusted-lists/plain/<list>.txt, one CIDR per line. Downstream scripts, other daemons, or your own automation can consume these files and inherit the same auto-update lifecycle.

fail2ban Integration

The fail2ban-trusted-lists-helper package exempts every installed trusted list from all fail2ban jails at once. It wires a [DEFAULT] ignorecommand into /etc/fail2ban/jail.d/00-trusted-lists.local, pointing at a helper script that matches the candidate IP against every file in /usr/share/trusted-lists/plain/ using grepcidr.

fail2ban and grepcidr come from EPEL, so enable it first:

sudo dnf -y install epel-release
sudo dnf -y install fail2ban-trusted-lists-helper

Install it alongside any nginx-iplist-* packages, and those services can no longer be banned by fail2ban, no matter which jail matched them. Verify the hook is active:

sudo fail2ban-client get sshd ignorecommand

/usr/share/trusted-lists/scripts/fail2ban-ignoreip-check <ip>

The helper script is also handy on its own. It exits 0 when the IP belongs to one of the installed trusted IP lists:

/usr/share/trusted-lists/scripts/fail2ban-ignoreip-check 3.18.12.63 && echo trusted

trusted

Staying Current Automatically

The whole point of packaging trusted IP lists is that updates arrive through the package manager. Enable dnf-automatic so vendor range changes apply without your involvement:

sudo dnf -y install dnf-automatic
sudo systemctl enable --now dnf-automatic-install.timer

When Cloudflare adds a range or OpenAI rotates crawler infrastructure, the corresponding package version bumps, the update installs, and the post-install scripts reload FirewallD or NGINX as appropriate. Your allowlists simply never rot.

Conclusion

Trusted IP lists are only as good as their last update. Vendor ranges drift constantly, and every hardcoded CIDR in your firewall or NGINX config is a silent outage waiting to happen. GetPageSpeed Amplify runs scheduled gixy scans across every host and ties findings to live NGINX runtime metrics. Drop-in compatible with the deprecated nginx-amplify-agent (EOL January 2026).

The trusted-lists packages turn allowlist maintenance into a solved problem: one dnf install per service, and the operating system keeps the ranges current for FirewallD, NGINX and fail2ban alike. Combine them with fds for one-command country and Tor blocking, and with the NGINX honeypot for automatic bot banning that never catches a legitimate crawler.

Missing a service you need? Get in touch and it can usually be packaged within a day.