fds FirewallD Made Easy: Trusted Lists

Managing a Linux firewall shouldn’t require memorizing pages of firewall-cmd syntax. Yet that’s exactly what FirewallD demands for everyday tasks like blocking an abusive IP or whitelisting PayPal webhooks.

Enter fds and trusted-lists — two tools from the GetPageSpeed repository that transform fds FirewallD management from painful to pleasant. Together, they give you:

• fds: Block IPs, countries, continents, and Tor exit nodes with one command
• trusted-lists: Auto-updating IP whitelist packages for PayPal, Stripe, Google, OpenAI, and 20+ other services

Block entire countries in one command. Whitelist OpenAI GPTBot with a single package install. No manual IP tracking. No stale lists.

What is fds?

fds stands for “FirewallD doesn’t suck.” It’s a CLI wrapper for FirewallD with a human-friendly interface. Instead of juggling ipsets, zones, and reload commands, you get intuitive one-liners.

fds is available for CentOS/RHEL 7–9, Rocky Linux 8–10, and AlmaLinux 8–10. Install it:

sudo dnf -y install https://extras.getpagespeed.com/release-latest.rpm
sudo dnf -y install fds

Run the initial configuration — fds FirewallD setup detects your web server and opens the right ports:

sudo fds config

Blocking with fds FirewallD

Here’s why sysadmins love fds — compare the old way with the new:

Block a single IP:

# The old way (4 commands)
firewall-cmd --permanent --new-ipset=block --type=hash:net
firewall-cmd --permanent --ipset=block --add-entry=1.2.3.4
firewall-cmd --permanent --zone=drop --add-source=ipset:block
firewall-cmd --reload

# With fds (1 command)
sudo fds block 1.2.3.4

One command replaces four. fds creates the ipset, adds the entry, assigns it to the drop zone, breaks existing connections via conntrack, and reloads the firewall.

Block an entire country:

sudo fds block China

This downloads all Chinese IP ranges and adds them to the drop zone. A daily cron job keeps the list current.

More blocking commands:

sudo fds block Asia          # Block a continent
sudo fds block tor           # Block Tor exit nodes
sudo fds block 114.0.0.0/8   # Block a network range

Batch blocking — use --no-reload to defer the reload:

sudo fds block --no-reload 1.2.3.4
sudo fds block --no-reload 5.6.7.8
sudo fds block 9.10.11.12   # last one triggers reload

Manage your block list:

sudo fds list blocked        # Show all blocks
sudo fds unblock 1.2.3.4     # Remove a block
sudo fds unblock China       # Unblock a country

Here’s what fds list blocked actually outputs:

Listing blocked
==================
Blocked networks / IP addresses:
198.51.100.0/24
Blocked countries:

Cloudflare Sync

If you use Cloudflare, fds FirewallD can sync blocks to both your server firewall and Cloudflare simultaneously. Run sudo fds config, enter your Cloudflare API token, and every future fds block protects you at both layers.

The Problem Blocking Alone Doesn’t Solve

Aggressive blocking creates a dangerous side effect: false positives.

When you block entire countries or networks, you risk cutting off legitimate services:

• PayPal IPN webhooks may come from blocked IP ranges
• Googlebot might get dropped, devastating your SEO rankings
• Stripe webhook confirmations could fail, breaking checkout
• OpenAI GPTBot might be blocked when you want it indexing your content

You need whitelisting that stays current automatically — because these services regularly update their IP ranges.

Whitelist OpenAI, Google, PayPal and More: Trusted Lists

Trusted-lists solves this elegantly. Each service gets its own RPM package containing a FirewallD ipset. Install it, add it to your trusted zone, and forget about it. When the service updates its IPs, your next dnf update picks up the changes.

Available for CentOS/RHEL 7+, Rocky Linux 8–10, and AlmaLinux 8–10.

Whitelist OpenAI: AI Crawler Control

The most timely use case. These packages let you choose how to handle AI crawlers at the firewall level — far more reliable than robots.txt alone:

Want to whitelist OpenAI crawlers? Add to trusted zone:

sudo dnf -y install firewalld-ipset-openai-gptbot
sudo firewall-cmd --permanent --zone=trusted --add-source=ipset:openai-gptbot
sudo firewall-cmd --reload

The GPTBot ipset currently contains 21 CIDR ranges sourced directly from openai.com/gptbot.json. When OpenAI changes their infrastructure, a dnf update refreshes the list.

Want to block AI crawlers instead? Add to drop zone:

sudo firewall-cmd --permanent --zone=drop --add-source=ipset:openai-gptbot
sudo firewall-cmd --reload

Either way, you’re working with OpenAI’s actual published IPs — not guessing.

Whitelist PayPal IP Addresses

Critical for e-commerce. These packages ensure webhook notifications always reach your server:

Whitelist PayPal in two commands:

sudo dnf -y install firewalld-ipset-paypal
sudo firewall-cmd --permanent --zone=trusted --add-source=ipset:paypal
sudo firewall-cmd --reload

The PayPal ipset currently contains 8 CIDR ranges covering all PayPal IPN webhook source IPs. These come from PayPal’s official documentation.

Whitelist Search Engine Crawlers

Don’t let your firewall rules kill your search rankings:

Whitelist all major search engines:

sudo dnf -y install firewalld-ipset-googlebot-v4 firewalld-ipset-bingbot-v4 firewalld-ipset-applebot-v4

for ipset in googlebot-v4 bingbot-v4 applebot-v4; do
  sudo firewall-cmd --permanent --zone=trusted --add-source=ipset:$ipset
done
sudo firewall-cmd --reload

CDN, WordPress, and Other Services

NGINX Integration: IP-Based Access Control

Beyond firewall-level blocking, you can use the same IP lists directly in NGINX for per-location access control using geo blocks. This is powerful for scenarios where you want to allow/deny specific services at specific endpoints.

Cloudflare Real IP: Auto-Updating NGINX Config

If your server is behind Cloudflare, NGINX sees Cloudflare’s IP instead of the real visitor. The nginx-cloudflare-ips packages provide auto-updating set_real_ip_from directives:

sudo dnf -y install nginx-cloudflare-ips-v4 nginx-cloudflare-ips-v6

This installs /etc/nginx/cloudflare/realip-from-ipv4.conf containing:

set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
# ... all Cloudflare ranges

Use it in your NGINX config:

include /etc/nginx/cloudflare/realip-from-ipv4.conf;
include /etc/nginx/cloudflare/realip-from-ipv6.conf;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

NGINX geo Blocks for Per-Location Control

You can build NGINX geo blocks from the same IP data that powers the FirewallD ipsets. This enables fine-grained control: block AI crawlers on specific pages, or restrict webhook endpoints to specific payment processors.

Here’s a working example using IPs from trusted-lists packages:

# OpenAI GPTBot IPs (from firewalld-ipset-openai-gptbot)
geo $is_gptbot {
    default 0;
    4.227.36.0/25 1;
    20.171.206.0/24 1;
    52.230.152.0/24 1;
    # ... remaining ranges from openai.com/gptbot.json
}

# PayPal IPs (from firewalld-ipset-paypal)
geo $is_paypal {
    default 0;
    64.4.240.0/21 1;
    173.0.80.0/20 1;
    185.177.52.0/22 1;
    # ... remaining ranges from PayPal docs
}

server {
    # Block GPTBot from specific content
    location /premium-content {
        if ($is_gptbot) {
            return 403;
        }
        # ... serve content
    }

    # Restrict webhook endpoint to PayPal IPs only
    location /webhook/paypal {
        if ($is_paypal = 0) {
            return 403;
        }
        # ... process webhook
    }
}

We tested this on Rocky Linux 10 with NGINX 1.28 — results are exactly as expected:

$ curl -H "X-Forwarded-For: 4.227.36.1" http://server/test-ip
remote_addr: 4.227.36.1
is_gptbot: 1

$ curl -H "X-Forwarded-For: 173.0.80.10" http://server/test-ip
remote_addr: 173.0.80.10
is_paypal: 1

$ curl -H "X-Forwarded-For: 8.8.8.8" http://server/test-ip
remote_addr: 8.8.8.8
is_gptbot: 0
is_paypal: 0

This approach works at the NGINX level in addition to FirewallD-level blocking. Use both for defense in depth: FirewallD for network-level access control, NGINX geo for application-level decisions.

nginx-iplist: Auto-Updating NGINX IP Lists

While you can manually copy IPs into geo blocks, that defeats the auto-updating advantage. The nginx-iplist-* packages provide ready-to-include NGINX geo configuration files that update automatically.

Installation and Structure

Install the packages for the services you need:

sudo dnf -y install nginx-iplist-googlebot-v4 nginx-iplist-bingbot nginx-iplist-applebot

Each package installs two files in /etc/nginx/iplist/:

• <name>.geo.conf — NGINX geo block with a $is_<name> variable
• <name>.allow.conf — NGINX allow/deny rules for simple access control

For example, nginx-iplist-googlebot-v4 provides:

# /etc/nginx/iplist/googlebot-v4.geo.conf
# Google Search crawler (Googlebot) IP ranges (inet)
# Source: https://developers.google.com/static/search/apis/ipranges/googlebot.json
geo $is_googlebot_v4 {
    default 0;
    34.22.85.0/27 1;
    34.64.82.64/28 1;
    34.65.242.112/28 1;
    # ... all Googlebot IP ranges
}

Include it in your NGINX configuration:

include /etc/nginx/iplist/googlebot-v4.geo.conf;
include /etc/nginx/iplist/bingbot.geo.conf;
include /etc/nginx/iplist/applebot.geo.conf;

Now you have $is_googlebot_v4, $is_bingbot, and $is_applebot variables available throughout your config.

Bypass Rate Limiting for Search Engines

Here’s where nginx-iplist shines for SEO: preventing rate limit errors from hurting your search rankings.

When search engine crawlers hit your rate limits, they receive 503 Service Unavailable responses. This signals to search engines that your site is unreliable, which:

• Reduces crawl rate (fewer pages indexed)
• Can hurt rankings over time
• Delays indexing of new content

The solution is to bypass rate limiting for verified search engine crawlers. NGINX’s limit_req module skips rate limiting when the zone key evaluates to an empty string. Here’s the technique:

include /etc/nginx/iplist/googlebot-v4.geo.conf;
include /etc/nginx/iplist/bingbot.geo.conf;
include /etc/nginx/iplist/applebot.geo.conf;

# Combine search bots into single variable
map $is_googlebot_v4$is_bingbot$is_applebot $is_search_bot {
    "000"   0;
    default 1;
}

# Empty key for bots = bypass rate limiting
map $is_search_bot $rate_limit_key {
    0 $binary_remote_addr;
    1 "";
}

limit_req_zone $rate_limit_key zone=website:10m rate=10r/s;
limit_req_status 429;  # Use 429, not 503!

server {
    listen 80;

    location / {
        limit_req zone=website burst=20 nodelay;
        # ... your config
    }
}

This configuration:

1. Detects search bots using the geo variables from nginx-iplist packages
2. Sets an empty rate limit key for bots, which NGINX interprets as “skip rate limiting”
3. Uses 429 Too Many Requests instead of 503 for rate-limited humans (search engines understand 429 as temporary)

The empty-key bypass is a documented NGINX behavior. From the source code:

if (key.len == 0) {
    continue;  // Skip this rate limit zone
}

Testing with X-Real-IP

Before deploying, verify your bot detection works. Use set_real_ip_from and real_ip_header to simulate requests from bot IPs:

# Test configuration
set_real_ip_from 127.0.0.1;
real_ip_header X-Real-IP;

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

server {
    listen 8080;

    location /test-bot {
        add_header X-Is-Googlebot $is_googlebot_v4;
        return 200 "is_googlebot=$is_googlebot_v4\n";
    }
}

Test with curl:

# Googlebot IP (from the geo.conf file)
$ curl -H "X-Real-IP: 34.22.85.1" http://localhost:8080/test-bot
is_googlebot=1

# Regular IP
$ curl -H "X-Real-IP: 8.8.8.8" http://localhost:8080/test-bot
is_googlebot=0

The X-Real-IP header overrides $remote_addr, letting you test bot detection from any machine.

Available nginx-iplist Packages

All services with FirewallD ipsets also have corresponding nginx-iplist packages:

Real-World Scenarios

Scenario 1: E-Commerce Server

Block abusive traffic while ensuring payments work:

# Block abusive regions
sudo fds block China
sudo fds block Russia

# Whitelist payment processors
sudo dnf -y install firewalld-ipset-paypal firewalld-ipset-stripe
sudo firewall-cmd --permanent --zone=trusted --add-source=ipset:paypal
sudo firewall-cmd --permanent --zone=trusted --add-source=ipset:stripe
sudo firewall-cmd --reload

The trusted zone has higher priority than the drop zone, so PayPal and Stripe webhooks get through even if their IPs fall within blocked country ranges.

Scenario 2: AI Content Control

Whitelist OpenAI’s GPTBot so it can index your content for ChatGPT and SearchGPT, while blocking it from scraping premium pages via NGINX geo:

# Whitelist at firewall level (network access allowed)
sudo dnf -y install firewalld-ipset-openai-gptbot
sudo firewall-cmd --permanent --zone=trusted --add-source=ipset:openai-gptbot
sudo firewall-cmd --reload

Then in NGINX, use a geo block to restrict which pages GPTBot can access.

Scenario 3: NGINX Honeypot with Whitelisting

Combine fds FirewallD with NGINX honeypot traps for automatic bot blocking, while trusted-lists prevent false positives on legitimate crawlers:

sudo dnf -y install firewalld-ipset-googlebot-v4 firewalld-ipset-bingbot-v4
sudo firewall-cmd --permanent --zone=trusted --add-source=ipset:googlebot-v4
sudo firewall-cmd --permanent --zone=trusted --add-source=ipset:bingbot-v4
sudo firewall-cmd --reload

Scenario 4: SEO-Safe Rate Limiting

Protect your server from abuse while ensuring search engines can crawl freely:

# Install NGINX iplist packages
sudo dnf -y install nginx-iplist-googlebot-v4 nginx-iplist-bingbot nginx-iplist-applebot

Then use the rate limiting bypass configuration shown above. Search engine crawlers get unlimited access, while abusive bots and scrapers hit your rate limits.

Automatic Updates

Both tools handle updates without intervention:

fds installs a daily cron job at /etc/cron.daily/fds that refreshes country and Tor IP lists.

Trusted-lists packages update through standard package management:

sudo dnf update firewalld-ipset-*
sudo dnf update nginx-iplist-*

When PayPal adds new IP ranges or OpenAI rotates crawler IPs, the packages update automatically.

Complete Package Reference

Here’s every package available from trusted-lists, organized by category:

FirewallD ipset Packages

NGINX iplist Packages

Every FirewallD ipset above has a matching nginx-iplist-* package. Replace firewalld-ipset- with nginx-iplist-:

# Example: install NGINX geo configs for payment providers
sudo dnf -y install nginx-iplist-paypal nginx-iplist-stripe nginx-iplist-braintree

NGINX Cloudflare Real-IP Packages

Complete Production Setup

Here’s a production-ready fds FirewallD configuration with tested commands:

# 1. Install the tools
sudo dnf -y install https://extras.getpagespeed.com/release-latest.rpm
sudo dnf -y install fds

# 2. Initial configuration
sudo fds config

# 3. Block threats
sudo fds block --no-reload tor
sudo fds block --no-reload China
sudo fds block Russia

# 4. Install whitelist packages
sudo dnf -y install \
  firewalld-ipset-paypal \
  firewalld-ipset-stripe \
  firewalld-ipset-googlebot-v4 \
  firewalld-ipset-bingbot-v4 \
  firewalld-ipset-cloudflare-v4 \
  firewalld-ipset-openai-gptbot

# 5. Add to trusted zone
for ipset in paypal stripe googlebot-v4 bingbot-v4 cloudflare-v4 openai-gptbot; do
  sudo firewall-cmd --permanent --zone=trusted --add-source=ipset:$ipset
done
sudo firewall-cmd --reload

# 6. Verify
sudo fds list blocked
sudo firewall-cmd --zone=trusted --list-sources

The last command confirms your whitelist:

ipset:paypal ipset:stripe ipset:googlebot-v4 ipset:bingbot-v4 ipset:cloudflare-v4 ipset:openai-gptbot

Further Reading

• fds documentation — full reference for all fds FirewallD commands
• FirewallD and Trusted IP Addresses — deep dive into FirewallD zones and IP sets
• Ban Bad IPs with FirewallD — more blocking examples
• NGINX Honeypot — automatic bot blocking with NGINX and fds
• NGINX Bot Verification — verify legitimate crawlers at the NGINX level
• NGINX JavaScript Challenge — stop bots without CAPTCHAs
• OpenAI IP allowlisting — official OpenAI documentation