Block known attackers in nginx with a free list that updates itself

To block known attackers in nginx, load their addresses into a geo map and return 403 to every visitor on it. Keep the list in its own file, refresh it on a timer, and reload nginx only after nginx -t passes. FFraud publishes a free list of 2,000 addresses seen attacking web applications, rebuilt every six hours. In our test, that list added 1.7 MB of memory to an nginx worker and 0.007 milliseconds to the median request.

#Which free list should you load?

FFraud publishes four plain-text lists with one address per line, strongest entries first. Each file's header states what qualifies an address. All four were rebuilt at 05:17 UTC on October 23, 2026, and FFraud rebuilds them every six hours.

For a website or an API, start with webattack.txt. Use worst.txt alone if you want only the most confirmed offenders, or merge all four, which gave 6,403 distinct IPv4 addresses on October 23. Three lists hold IPv4 addresses only; freships.txt also carried 27 IPv6 addresses that day. The script below loads IPv4 and skips IPv6 lines.

#Why use a geo map instead of deny lines?

nginx checks allow and deny rules in order until one matches. Its own documentation says that with many rules, the geo module is the better choice (nginx docs). A geo map sets a variable from the client address in a single lookup, and it can read its addresses from a file.

We measured what a list costs on nginx 1.24.0 with one worker process, on October 23, 2026. Each run loaded a list into a geo map and sent 2,000 requests from listed addresses and 2,000 from clean ones.

Lookups stayed fast at every size, and every listed address got 403 while every clean one got 200. Memory is the cost that grows. The full IPv4 part of FFraud's open data needed 736.6 MB for one worker and almost two seconds to test. A list that large belongs in the kernel firewall, with ipset, where it took 39.2 MB. The curated lists fit nginx easily.

#How do you set it up?

The steps below assume Ubuntu or Debian, where nginx reads every file in /etc/nginx/conf.d/ inside its http block. First, create an empty list so nginx can start before the first download:

sudo touch /etc/nginx/ffraud-blocklist.conf

Next, define the map. Every address in the list file gets the value 1, and everything else gets 0:

geo $ffraud_blocked {
    default 0;
    include /etc/nginx/ffraud-blocklist.conf;
}

Then refuse listed visitors in each server block you want to protect:

server {
    # your listen, server_name and location blocks stay as they are
    if ($ffraud_blocked) {
        return 403;
    }
}

The update script

Save this as /usr/local/bin/ffraud-nginx-blocklist and make it executable with chmod +x. It downloads the list, keeps only IPv4 addresses and ranges, removes your own addresses, and writes the map file:

#!/bin/sh
# Refresh nginx's list of known attackers from FFraud's free web-attacker feed.
# A failed download, a short list or a config that fails `nginx -t` leaves the old list in place.
set -eu
LIST_URL="https://ffraud.com/free/webattack.txt"
OUT=/etc/nginx/ffraud-blocklist.conf
ALLOW=/etc/nginx/ffraud-allowlist.txt   # your own addresses, one per line (optional)

tmp=$(mktemp)
trap 'rm -f "$tmp" "$tmp.raw"' EXIT

curl -fsS --max-time 30 "$LIST_URL" -o "$tmp.raw"

# Keep IPv4 addresses and ranges only, drop your own addresses, write geo lines.
grep -E '^[0-9]{1,3}(\.[0-9]{1,3}){3}(/[0-9]{1,2})?$' "$tmp.raw" \
  | if [ -s "$ALLOW" ]; then grep -v -x -F -f "$ALLOW"; else cat; fi \
  | sed 's/$/ 1;/' > "$tmp" || true

n=$(wc -l < "$tmp")
if [ "$n" -lt 100 ]; then
  echo "only $n addresses in the download, keeping the old list" >&2
  exit 1
fi

[ -f "$OUT" ] && cp -p "$OUT" "$OUT.prev"
install -m 644 "$tmp" "$OUT"
if nginx -t -q; then
  nginx -s reload
  echo "loaded $n addresses"
else
  echo "nginx -t failed, restoring the previous list" >&2
  if [ -f "$OUT.prev" ]; then mv "$OUT.prev" "$OUT"; else : > "$OUT"; fi
  exit 1
fi

Put your own office, monitoring and partner addresses in /etc/nginx/ffraud-allowlist.txt, one per line, so a shared address of yours can never lock you out. The script refuses a download with fewer than 100 addresses, so an error page cannot replace a good list. If nginx -t fails for any reason, it restores the previous list and nginx keeps its running configuration.

A reload is safe for live traffic. nginx checks the new configuration first and keeps working with the old one when the check fails. When it passes, new workers start and the old ones finish their open requests (nginx docs).

Run it every six hours

A systemd timer matches the six-hour rebuild. Its random delay of up to ten minutes spreads the downloads of many servers over time (systemd docs):

# /etc/systemd/system/ffraud-nginx-blocklist.service
[Unit]
Description=Refresh the FFraud blocklist for nginx
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/ffraud-nginx-blocklist

# /etc/systemd/system/ffraud-nginx-blocklist.timer
[Unit]
Description=Refresh the FFraud blocklist for nginx every six hours

[Timer]
OnCalendar=*-*-* 00/6:40:00
RandomizedDelaySec=10m
Persistent=true

[Install]
WantedBy=timers.target

sudo /usr/local/bin/ffraud-nginx-blocklist
sudo systemctl daemon-reload
sudo systemctl enable --now ffraud-nginx-blocklist.timer

Without systemd, one cron line does the same: 40 */6 * * * root /usr/local/bin/ffraud-nginx-blocklist in /etc/cron.d/ffraud-nginx-blocklist.

#What if nginx sits behind Cloudflare or a load balancer?

Behind a proxy, nginx sees the proxy's address in place of the visitor's. A geo map then either blocks the proxy or never matches anyone. The realip module fixes this by replacing the client address with the one a trusted proxy sends (nginx docs).

Cloudflare puts the visitor's address in the CF-Connecting-IP header. It also asks you to keep its list of ranges current, because they change (Cloudflare docs):

# Trust Cloudflare's ranges and read the visitor from CF-Connecting-IP.
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
# ...one line for each range at https://www.cloudflare.com/ips-v4 and /ips-v6
real_ip_header CF-Connecting-IP;

nginx applies the real address as soon as it reads the request, before the geo map is looked up. Our guide to the real client IP covers load balancers, the spoofing risk of X-Forwarded-For, and a script that keeps Cloudflare's ranges current.

#How do you see what got blocked?

Give blocked requests their own log. The if= parameter of access_log skips a request when the condition is 0 or empty (nginx docs). Add the format to the http block and the log line to each protected server block:

# http block
log_format ffraud_blocked '$time_iso8601 $remote_addr "$request" $status';

# server block, next to your normal access_log
access_log /var/log/nginx/blocked.log ffraud_blocked if=$ffraud_blocked;

Each blocked request then appears as one line with the time, the visitor's address, the request and the 403. To check why an address is on the list, paste it into the free IP blacklist check.

#How did we test it?

We ran the script and the map on nginx 1.24.0 under Ubuntu 24.04 on October 23, 2026, on a private test instance. To send requests from listed addresses without spoofing packets, the test instance trusted 127.0.0.1 in realip and took the visitor from a header. Clean requests used the documentation range 198.51.100.0/24, which can never be on an attacker list (RFC 5737).

1. The first run loaded 2,000 addresses. A listed address got 403, a clean one got 200, and the blocked request appeared in the log.
2. With that listed address in the allowlist, the script loaded 1,999 addresses and the address got 200.
3. When the download answered 404, the script stopped and the old list stayed in place.
4. When the download was a web page and not a list, the script found 0 addresses and kept the old list.
5. When the nginx configuration was broken on purpose, nginx -t failed, the script restored the previous list, and nginx kept serving.

On a production server, check the blocked log after the first few hours. A few lines from scanners and exploit attempts show that the map works.

#Should you return 403 or 444?

A 403 answers the request with Forbidden. Code 444 belongs to nginx alone: it closes the connection without sending a response header (nginx docs). A 444 saves a little traffic on scanners. A real person behind a listed shared address, such as a mobile carrier's CGNAT gateway, then sees a dropped connection with no reason. We suggest 403 for websites.

#Questions people ask

For the complete list of confirmed attackers as a free download, see the malicious IP database.