Hardening Nginx Rate Limiting: Deploying dry_run Mode and Automated Fail2ban Jails for Layer 7 DDoS Mitigation in Pakistan

High-traffic e-commerce storefronts, classified portals, ticket booking platforms, and government web applications across Pakistan face persistent application-layer (Layer 7) threats. Malicious competitors, aggressive web scrapers, automated credential-stuffing bots, and distributed HTTP flood attacks routinely barrage login endpoints and checkout APIs with thousands of requests per second.

While Nginx’s native ngx_http_limit_req_module provides the industry standard leaky-bucket rate limiting mechanism, enabling aggressive rate limiting directly in production carries a severe risk: False Positives. Legitimate mobile users operating behind shared carrier-grade NAT (CGNAT) gateways on cellular networks in Pakistan (such as Jazz, Zong, and Telenor) share a single public IPv4 address across hundreds of concurrent smartphones. An overly strict rule can accidentally lock out genuine customers during high-stakes sales events.

By deploying Nginx’s powerful limit_req_dry_run directive alongside custom logging pipelines and automated Fail2ban iptables/nftables jails, security engineers can safely audit rate-limiting thresholds in real time without blocking a single legitimate user. Once calibrated, persistent offenders are automatically banned at the Linux firewall level before their requests ever reach the Nginx worker process.

---

1. Architectural Architecture: From Dry-Run Auditing to Kernel Firewall Banning

Traditional rate limiting immediately drops violating requests with HTTP 429 Too Many Requests or HTTP 503 Service Temporarily Unavailable. The hardened two-stage defensive model decouples inspection from enforcement:

                          Incoming HTTP Traffic
                                   │
                                   ▼
             ┌──────────────────────────────────────────┐
             │       Nginx Reverse Proxy Layer          │
             │   - limit_req_zone binary leaky bucket   │
             │   - limit_req_dry_run on;                │
             └─────────────────────┬────────────────────┘
                                   │
                    Rate Limit Exceeded Condition?
                    ┌──────────────┴──────────────┐
                    │                             │
                   YES                            NO
                    │                             │
                    ▼                             ▼
    Flagged as: "limit_req_dry_run"       Request Routed to Backend
    Logged to: /var/log/nginx/ratelimit.log  (Normal 200 OK Response)
                    │
                    ▼
    ┌───────────────────────────────────────────┐
    │          Fail2ban Security Daemon         │
    │   Monitors: /var/log/nginx/ratelimit.log  │
    │   Triggers: 10 violations in 10 seconds   │
    └─────────────────────┬─────────────────────┘
                          │
                          ▼
    ┌───────────────────────────────────────────┐
    │     Linux Kernel Firewall (IPTables/NFT)  │
    │     Offending IP Banned for 2 Hours       │
    │     (Packets Dropped at Wire-Speed)       │
    └───────────────────────────────────────────┘

The Power of limit_req_dry_run

Introduced in modern Nginx versions (1.17.1+), limit_req_dry_run evaluates the rate-limiting rules, accounts for the request in shared memory, and logs an alert if the threshold is exceeded—but does not reject or delay the request. The variable $limit_req_status is populated with PASSED, DELAYED, REJECTED, DELAYED_DRY_RUN, or REJECTED_DRY_RUN.

---

2. Step 1: Configuring Nginx with limit_req_dry_run and Audit Logging

Create /etc/nginx/conf.d/ratelimit_hardening.conf:

# /etc/nginx/conf.d/ratelimit_hardening.conf
# NextGen Infrastructure: Zero-False-Positive Rate Limiting Pipeline

# Define shared memory zones (10MB holds ~160,000 unique IP states)
limit_req_zone $binary_remote_addr zone=general_api:10m rate=20r/s;
limit_req_zone $binary_remote_addr zone=login_auth:10m rate=5r/s;

# Custom Log Format to capture rate-limiting violations for Fail2ban
log_format ratelimit_json escape=json '{'
    '"time_local":"$time_local",'
    '"remote_addr":"$remote_addr",'
    '"request":"$request",'
    '"status":"$status",'
    '"body_bytes_sent":"$body_bytes_sent",'
    '"http_referer":"$http_referer",'
    '"http_user_agent":"$http_user_agent",'
    '"limit_req_status":"$limit_req_status"'
'}';

server {
    listen 443 ssl http2;
    server_name api.example.pk;

    # SSL configuration omitted for brevity...

    # Dedicated Rate Limit Audit Log
    access_log /var/log/nginx/ratelimit_audit.log ratelimit_json;

    # Protect Login & Authentication Endpoints
    location /api/v1/auth/login {
        limit_req zone=login_auth burst=10 nodelay;
        
        # ACTIVATE DRY-RUN MODE: Evaluates rules without blocking legitimate users
        limit_req_dry_run on;
        
        # Log dry-run violations with notice level
        limit_req_log_level notice;

        proxy_pass http://backend_upstream;
    }

    # Protect General Catalog and API Endpoints
    location /api/ {
        limit_req zone=general_api burst=50 nodelay;
        limit_req_dry_run on;
        limit_req_log_level notice;

        proxy_pass http://backend_upstream;
    }
}

Verify and reload Nginx:

nginx -t && systemctl reload nginx

---

3. Step 2: Analyzing Dry-Run Logs to Calibrate Thresholds

Let Nginx run in dry-run mode for 24 to 48 hours across peak business hours in Pakistan. Then analyze the audit log using standard command-line tools:

# Count rate-limiting triggers by IP address
grep "REJECTED_DRY_RUN" /var/log/nginx/ratelimit_audit.log | \
    jq -r '.remote_addr' | sort | uniq -c | sort -nr | head -n 20

Sample output:

 14290 195.154.120.45   <--- Malicious Scraper Bot!
  8910 185.220.101.5    <--- Tor Exit Node Brute Force!
    12 39.42.15.110     <--- Normal User behind Jazz CGNAT (12 alerts, perfectly safe!)

By inspecting user agents and request patterns, you can immediately identify true botnet attackers versus legitimate cellular users, allowing you to fine-tune rate and burst parameters with mathematical confidence.

---

4. Step 3: Integrating Fail2ban for Kernel-Level Banning

Once you have verified that legitimate users are not consistently triggering limits, configure Fail2ban to parse the Nginx audit log and ban abusive IP addresses.

Install Fail2ban

dnf install -y epel-release
dnf install -y fail2ban

Create Fail2ban Filter (/etc/fail2ban/filter.d/nginx-limit-req.conf)

[Definition]
# Match log entries where limit_req_status is REJECTED_DRY_RUN or REJECTED
failregex = ^\{.*"remote_addr":"<HOST>".*"limit_req_status":"REJECTED(_DRY_RUN)?"\}$
ignoreregex =

Configure Fail2ban Jail (/etc/fail2ban/jail.d/nginx-limit-req.local)

[nginx-limit-req]
enabled = true
port = http,https
filter = nginx-limit-req
logpath = /var/log/nginx/ratelimit_audit.log
maxretry = 15
findtime = 30
bantime = 7200
banaction = iptables-multiport
action = %(banaction)s[name=%(__name__)s, bantime="%(bantime)s", port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]

(If an IP triggers more than 15 rate limit violations within 30 seconds, Fail2ban immediately inserts a DROP rule in iptables for 2 hours).

Start and enable Fail2ban:

systemctl enable --now fail2ban
fail2ban-client reload

---

5. Live Diagnostics and Verification

To verify that the Fail2ban jail is actively inspecting the Nginx log:

fail2ban-client status nginx-limit-req

Sample output:

Status for the jail: nginx-limit-req
|- Filter
|  |- Currently failed: 4
|  |- Total failed:     3189
|  `- File list:        /var/log/nginx/ratelimit_audit.log
`- Actions
   |- Currently banned: 14
   |- Total banned:     112
   `- Banned IP list:   195.154.120.45 185.220.101.5 45.143.200.12 ...

Inspect active kernel firewall drops:

iptables -L f2b-nginx-limit-req -v -n

You will see millions of malicious bot packets rejected at wire-speed before they can consume CPU cycles, memory, or database connection pool slots on your backend application.

---