Firewall Whitelist for Monitoring: Correctly Configure Fail2Ban, ModSecurity & WAFs

Why firewalls block monitoring traffic

Modern Web Application Firewalls work with signature-based and behavior-based rules. A typical uptime check sends one HTTP request per minute from the same IP, with a non-browser User-Agent, no cookie and no referrer. To a WAF ruleset these are exactly the hallmarks of an automated scanner. The Cloudflare WAF achieved 99.938% accuracy on legitimate traffic detection in 2024 (openappsec WAF benchmark, 2024) — but the flip side is: one in roughly 1,600 legitimate requests gets blocked. With a 30-second monitoring interval from a single node that's statistically about 54 false blocks per day.

The consequences go beyond sporadic false alarms. On 5 December 2025, a misconfigured Cloudflare WAF rule caused a 25-minute, 28% outage of global HTTP traffic (Cloudflare Blog, December 2025). Zoom, LinkedIn and others were affected — along with the monitoring dashboards of Cloudflare customers that were supposed to flag the outage. A well-known monitoring service's EU monitoring region collapsed in August 2025 by 45% of its capacity, triggering cascades of false alarms for thousands of users (industry incident report, August 2025). The lesson: monitoring infrastructure must be explicitly whitelisted in firewall rules, otherwise it becomes a single-point-of-failure itself.

Fail2Ban: the most common misconfigurations

Fail2Ban reads web server logs and bans IPs that trigger certain patterns in a short time. The default apache-botsearch filter or the nginx-http-auth jail kicks in on failed authentication — but also on the typical monitoring workflow with 401 responses on protected paths. Custom http-get-dos filters that ban any IP with more than X requests per minute are especially problematic. A monitoring setup with 30-second interval hits 2,880 requests per day — well above typical thresholds.

The clean fix: add monitoring IPs to ignoreip in the Fail2Ban main config. This entry applies globally to all jails and fully exempts the monitoring nodes from surveillance.

# /etc/fail2ban/jail.local
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 \
           213.133.103.229 \
           89.167.106.0 \
           2a01:4f8:a0:935d::2 \
           2a01:4f9:c012:730b::1
# After changes: systemctl restart fail2ban

Important: the IPs change when new monitoring nodes are added or removed. A statically stored list will inevitably drift. XICTRAQ publishes the current list as a JSON endpoint that can be polled automatically.

ModSecurity and OWASP Core Rule Set 4.x

ModSecurity with OWASP CRS is the standard WAF on many Apache and nginx installations. The Core Rule Set in 4.x was fundamentally overhauled after eight years and leans more toward blocking over alerting — the trade-off: higher security quality, lower detection quality (Linux Compatible, 2024). Translated: more legitimate traffic gets blocked along with threats. For monitoring tools three rules are particularly critical:

Instead of disabling individual rules — which reduces protection against real attackers — monitoring IPs should be selectively removed from the rule engine via IP match. The following exception rule runs in phase 1 and disables the entire rule-engine mode for the listed IPs:

# /etc/modsecurity/crs-setup.conf or conf.d/xictraq-whitelist.conf
SecRule REMOTE_ADDR \
    "@ipMatch 213.133.103.229,89.167.106.0,2a01:4f8:a0:935d::2,2a01:4f9:c012:730b::1" \
    "id:1000,phase:1,pass,nolog,ctl:ruleEngine=Off"

Rule ID 1000 is a free slot (OWASP CRS uses 900000–999999). For ISPConfig, Plesk or Cloudpanel setups there is typically a UI input for custom ModSecurity rules where this block can be stored without editing files.

Cloudflare WAF and rate limiting

Cloudflare sits between visitor and origin for many websites — every monitoring request hits the Cloudflare edge first. Managed Rules, Bot-Fight Mode, Rate Limits and IP Reputation all apply there. Under Security → WAF → Tools → IP Access Rules in the Cloudflare dashboard IPs can be set to 'Allow' — they then skip all subsequent security rules for the zone.

For more complex scenarios a custom rule is recommended that explicitly exempts the monitor IP range from rate limiting. The Cloudflare expression language allows multiple IPs in a bracketed list:

# Cloudflare WAF Custom Rule (Security → WAF → Custom rules → Create)
# Field:  IP Source Address
# Operator: is in
# Value: {213.133.103.229 89.167.106.0 2a01:4f8:a0:935d::2 2a01:4f9:c012:730b::1}
# Action: Skip → All remaining custom rules, Managed rules, Rate limiting
# Description: xictraq-monitoring-whitelist

iptables, nginx and Apache — native configuration

Besides the big WAFs there are setups where the firewall acts at the network or web-server layer. Key configs:

# iptables / ip6tables — insert Allow rules BEFORE DROP
iptables -I INPUT -s 213.133.103.229 -j ACCEPT
iptables -I INPUT -s 89.167.106.0 -j ACCEPT
ip6tables -I INPUT -s 2a01:4f8:a0:935d::2 -j ACCEPT
ip6tables -I INPUT -s 2a01:4f9:c012:730b::1 -j ACCEPT
# Persist with: netfilter-persistent save

For nginx a variable is recommended that sets different rate-limit keys depending on source IP — legitimate monitors run without limit, everyone else hits the standard cap:

# /etc/nginx/conf.d/xictraq-whitelist.conf
geo $xictraq_node {
    default 0;
    213.133.103.229 1;
    89.167.106.0 1;
    2a01:4f8:a0:935d::2 1;
    2a01:4f9:c012:730b::1 1;
}
map $xictraq_node $limit_req_key {
    0 $binary_remote_addr;
    1 "";
}
limit_req_zone $limit_req_key zone=default:10m rate=10r/s;

Apache allows IP allow lists via <RequireAll> blocks in the vhost or .htaccess. Important: order matters — Require all granted must come before the IP entries, otherwise only the allowlist passes.

Automated whitelist maintenance with the XICTRAQ endpoint

Every manual whitelist becomes stale the moment new monitoring nodes arrive. At XICTRAQ the check-node pool grows dynamically: currently three distributed EU nodes (DE + FI). Instead of broadcasting an IP list via email whenever a node rolls out, the public endpoint /api/public/nodes publishes the current list as JSON. Any firewall admin can poll it every 5 minutes via cron and regenerate the firewall config.

A minimal Fail2Ban example — the cron generates the ignoreip line in a separate file that Fail2Ban loads via include. When a new node arrives, the line is added within 5 minutes with zero admin effort:

#!/bin/bash
# /usr/local/bin/sync-xictraq-whitelist.sh
NODES=$(curl -s https://api.xictraq.com/api/public/nodes \
        | jq -r '.nodes[] | (.ipv4[], .ipv6[])' | tr '\n' ' ')
cat > /etc/fail2ban/jail.d/99-xictraq.local <<EOF
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 $NODES
EOF
systemctl reload fail2ban

The same approach works for ModSecurity, iptables and nginx. The full copy-paste snippets including IPv4 and IPv6 lists are in the XICTRAQ docs under Firewall whitelist — generated live from the node pool just like the JSON endpoint.

What happens on a rule collision?

Firewall rules are processed sequentially. An Allow rule placed after a Block rule no longer takes effect. Common pitfalls: in Fail2Ban ignoreip entries are processed before all jail filters — that works. In iptables the ACCEPT rule must be before DROP rules, otherwise DROP fires first. In Cloudflare WAF custom rules execute in the order they were created — the whitelist rule should be at the top with action 'Skip → All remaining custom rules, Managed rules, Rate limiting'. In ModSecurity ID order drives processing — the whitelist rule should have a low ID (e.g. 1000) so it runs before CRS rules (900000+).

Checklist for new setups

1. Fetch current monitoring IPs: curl https://api.xictraq.com/api/public/nodes
2. Set Fail2Ban ignoreip and run systemctl reload fail2ban
3. Add ModSecurity exception rule with ID 1000 to CRS setup
4. On Cloudflare: create Custom Rule with IP Source match + Skip action
5. Insert iptables/ip6tables Allow rules before DROP rules and persist
6. Configure nginx rate-limit bypass via geo and map
7. Trigger manual scan in XICTRAQ dashboard and verify 200 response on all nodes
8. Set up cron auto-sync every 5 minutes for automatic node expansion

Set up the monitoring whitelist now

A clean firewall configuration is the precondition for your monitoring to tell the truth. XICTRAQ publishes the current node list as a public JSON endpoint and the full documentation includes ready-to-paste snippets for every common firewall system. Start free and have your site checked from multiple regions every 30 seconds — without your WAF getting in the way.

Frequently asked