Cloudflare Security Effectiveness Assessment — fastpeoplesearch.com

Scope: Single zone — fastpeoplesearch.com (zone ID e59519a86a7a62ab0316874ed58b1e17, Enterprise Website plan) Evidence window: Last 30 days (2026-06-25 → 2026-07-25)

1. Executive Summary

• Very high traffic under the heaviest attack pressure and heaviest filtering in the estate. The zone served 904.6M requests / 15.42 TB over 30 days, but only 20.7% cached — because 437.7M requests (48.4%) were served a 403 and 18.4% of all traffic was flagged as threats. (Confirmed)
• Automation is the majority of scored traffic. Of ~895M scored requests, ~51% score as automated, ~43% likely-human, ~6% grey. US/Canada/Mexico traffic is clean; foreign traffic (Netherlands, Vietnam, Germany, Brazil, Ireland) runs at 99%+ threat rates. (Confirmed)
• Cloudflare is containing an enormous scraping campaign — very effectively, but through one rule. Custom rules generated 730.6M events (166.5M blocks + 262.6M challenges) at a ~93.5% challenge-abandonment rate — yet 99.99% of all blocks come from a single custom rule. (Confirmed)
• The Managed WAF / OWASP ruleset is completely inactive. It generated zero firewall events in 30 days — no signature-based defense (SQLi/XSS/RCE) and no WAF-layer telemetry, despite an exposed /api/v1/adHandler API. (Confirmed)
• Rate limiting is configured but functionally inert. The rate-limit phase is the most heavily-iterated config in the estate (v165) yet fired only 9,830 times in 30 days — heavily tuned but not materially triggering. (Confirmed)
• Security-level challenging is off and there is no signature or reputation backstop behind the single custom rule. (Confirmed / Likely)
• Perimeter hygiene is largely clean. Production is proxied (AWS Elastic Beanstalk origin); no admin panel or RFC1918 is exposed. One minor exposure: autodiscover is an unproxied A record to origin IP 204.44.57.32 (mail autodiscover). (Confirmed)
• Overall risk: HIGH — the most-attacked PII property in the estate, defended by a single custom rule with no active signature WAF, no functional rate limiting, and security level off. Offset by the strongest observed enforcement effectiveness in the estate, which is why it is not CRITICAL. Executive score: 60/100.

2. Traffic Overview

30-day totals (Confirmed — httpRequests1dGroups)

Edge response codes (Confirmed): 403 437.7M (48.4%) · 200 409.8M (45.3%) · 301 16.6M · 304 14.6M · 302 9.21M · 404 5.81M · 400 3.01M · 499 2.66M · 429 2.65M · 204 1.71M. The 48.4% 403 rate is the largest security-enforcement footprint of the estate, and explains the low cache ratio (most traffic is blocked/challenged, not served from cache).

Human vs Bot breakdown

Derived from the adaptive bot-score dataset — estimates with stated assumptions. The adaptive total (≈1.79B) counts more broadly than the billing rollup; ~893M were unscored (predominantly cached edge hits). Percentages are given as a share of scored traffic.

Verified good bots (Confirmed — verifiedBotCategory, ~117M total): Search Engine Crawler 36.7M · Advertising & Marketing 31.6M · SEO 20.6M · AI Search 15.6M · Security 8.11M · AI Assistant 3.34M · other <0.5M each.

Assumptions: (1) botScore < 30 = automated per Cloudflare guidance; (2) unscored traffic excluded from ratios (cache-dominated); (3) verified good bots reported separately as they legitimately score low. Takeaway: this is the most heavily automated property reviewed — over half of scored traffic is automated, with an unusually decisive human/bot split (only 6% grey), consistent with the 18.4% threat rate.

3. Cloudflare Protection Effectiveness

Observed firewall events over 30 days. Rule thresholds/bodies were not readable (403); ratings rest on observed action volumes.

3.1 Events by source (Confirmed)

3.2 Events by action (Confirmed, all sources)

managed_challenge 262.6M · skip 206.8M · block 166.5M · managed_challenge_bypassed 73.4M · managed_challenge_non_interactive_solved 12.3M · managed_challenge_interactive_solved 4.73M · log 4.47M · allow 161K.

3.3 Per-protection scorecard

Challenge math (Confirmed): 262.6M challenges issued, 17.01M solved → ~93.5% abandonment. A further 73.4M "bypassed" events are returning clients with valid clearance tokens (benign).

Single-rule concentration (Confirmed): of 166.49M blocks, 166.48M (99.99%) come from one custom rule (d8e9312ff3ed466089353926418857ad). This rule is extraordinarily effective, but it is also a single point of failure — a misconfiguration, disable, or bypass of this one rule would collapse the zone's blocking with no managed-WAF or rate-limit backstop. One additional custom rule runs in log mode (4.47M events, monitoring only).

Managed WAF finding (Confirmed): the Cloudflare Managed Ruleset (v377) and OWASP Core Ruleset (v88) appear in the ruleset inventory but generated zero firewall events in 30 days. There is no active signature defense and no WAF-layer telemetry, despite an exposed /api/v1/adHandler API and dynamic record endpoints.

Rate-limiting finding (Confirmed): notable anomaly — the rate-limit phase is the most-iterated in the estate (version 165), yet it fired only 9,830 times in 30 days. The configuration is being actively maintained but is not materially triggering (thresholds likely far above real traffic, or the single custom rule pre-empts it). Functionally, rate limiting is not contributing to the zone's defense.

Security-level finding (Likely): no securitylevel events were observed, indicating reputation-based challenging is not active. The exact setting value returned 403 (Unknown), but its behavioral signature is absent.

4. Attack Analysis

(All Confirmed from 30-day firewall events unless noted.)

Top attacking countries (block events): Netherlands 37.47M · Vietnam 16.58M · Germany 13.70M · Brazil 11.40M · Ireland 11.06M · Argentina 6.15M · Pakistan 4.70M · South Africa 4.24M · France 3.96M · Bangladesh 3.71M · Iraq 2.96M · Colombia 2.73M. (US/CA/MX do not appear — that traffic is clean. NL and IE dominance reflects cloud-datacenter scraping.)

Top attacking ASNs (operator names from public registries, not Cloudflare data — Likely): AS396982 Google Cloud 25.10M · AS14061 DigitalOcean 19.19M · AS45899 VNPT (Vietnam) 15.00M · AS63949 Akamai/Linode 11.41M · AS16509 Amazon AWS 10.83M · AS13238 Yandex 2.27M · AS36903 1.16M · AS22927/AS7303 Telecom Argentina 1.07M/0.97M · AS5384 Etisalat (UAE) 1.07M · AS17557 (Pakistan) 0.99M. The top five ASNs — all cloud/hosting plus VNPT — account for ~81M blocks. This is overwhelmingly cloud-based scraping.

Top targeted paths (block events): /robots.txt 4.93M · / 620.8K · /favicon.ico 409.9K · /904-200 39.7K · /doug-cadaret_id_G1318019234813829881, /brian-piccolo_id_G…, /maria-karam_id_G… (person-record pages) · /api/v1/adHandler 29.8K (API) · /address/7780-c-ave_hesperia-ca-92345 22.6K (address-record page) · assets (/css/app.css, /js/wam.js, /manifest.json).

Top abusive IPs (block events): 63.32.23.121 (AWS Ireland) 4.24M · 52.215.186.214 (AWS Ireland) 2.88M · 54.194.183.189 (AWS Ireland) 2.67M · then a DigitalOcean droplet fleet — 209.38.104.65, 159.223.225.123, 134.209.94.6, 165.232.83.183, 167.99.214.52, 164.92.217.61, 167.99.39.255 — 715K–920K each. (The three AWS-Ireland IPs explain the high Ireland block count.)

Top blocked user-agents (Confirmed): SirdataBot 30.57M (ad-tech crawler) · then a near-uniform cluster of Chrome version strings — Chrome 123, 120, 110, 107, 99, 131, 119 — each ~6.40–6.45M. (The uniform distribution across mixed current/obsolete Chrome versions is a textbook user-agent-rotation scraping signature.)

Most common "WAF" detections (Confirmed): with the managed WAF inactive, all blocks come from custom rules — a single rule (d8e9312f…) accounts for 166.48M blocks (99.99%). A separate custom rule (e68d5da3…) runs in log mode (4.47M events, monitoring). Rule names/expressions were not readable (403).

Most common rate-limit triggers (Confirmed): one rule (a6689c21…) fired ~9,830 times (challenge) — negligible; no path is materially protected by rate limiting.

Abuse-indicator summary

Two evidence limits: (1) Cloudflare edge data cannot confirm account-level/authenticated abuse — needs backend correlation. (2) With the managed WAF inactive, the zone has no telemetry on signature-based attacks — their absence here is a visibility gap, not proof they aren't occurring, and it is especially relevant given the live /api/v1/adHandler endpoint.

5. Protection Coverage

✓ Enabled / Confirmed active

• Enterprise plan; Universal TLS certificates (Google Trust Services active, valid to 2026-10-08; Let's Encrypt backup)
• Apex and www proxied (origin is AWS Elastic Beanstalk); pro-dev and staging proxied
• Custom firewall ruleset — the enforcement engine (166.49M blocks + 262.60M challenges), actively tuned (v416)
• Bot Management — entitled and scoring live traffic; Managed Challenge in heavy use (93.5% abandon)
• DDoS L7 managed ruleset — active (209,980 mitigations)
• Cloudflare Managed Ruleset (v377), OWASP Core (v88), Exposed Credentials Check — present in inventory (but see gaps)
• URL Normalization; 96.9% encrypted traffic

⚠ Missing / inactive protections

• Managed WAF / OWASP enforcement — present in inventory but generating zero events. No signature defense, no WAF telemetry, on a property with a live API.
• Security-level reputation challenge — no securitylevel events observed; appears essentially off.
• Functional rate limiting — configured (and heavily iterated at v165) but firing only 9,830 times; effectively not contributing.

⚠ Weak / inconsistent configuration

• Extreme single-rule dependence — 99.99% of all blocks come from one custom rule; no signature or reputation backstop. Single point of failure.
• autodiscover.fastpeoplesearch.com is an unproxied A record to origin IP 204.44.57.32 — exposes one address in the origin range (mail autodiscover; minor recon value).
• Only Universal certificates (no Advanced certificate).

⚠ Unverifiable configuration (Unknown — 403)

• SSL/TLS mode, min-TLS version, HSTS, exact security-level value, Page Shield status, Bot Management action config. Verify with a settings-scoped token; Page Shield is worth confirming on a data-collection property.

6. Operational Risk: HIGH

Why HIGH:

1. The entire defense rests on a single custom rule. 99.99% of 166.5M blocks come from one rule, with no active managed WAF, no functional rate limiting, and security level off to back it up. A fault in that one rule would collapse enforcement on the most-attacked property in the estate. (Confirmed)
2. No active signature WAF on a dynamic API surface. The Managed WAF/OWASP ruleset generated zero events, so injection/exploit attempts against /api/v1/adHandler and dynamic record endpoints are neither blocked nor recorded. (Confirmed)
3. Heaviest attack pressure in the estate — 18.4% of all traffic flagged as threats, 48.4% served a 403 — absorbed by that single tier. (Confirmed)

Why not CRITICAL:

• The single tier is currently the estate's most effective — 48.4% of traffic 403'd, 93.5% challenge abandonment, foreign hostile traffic blocked at the edge, and the custom rules are actively maintained (v416). (Confirmed)
• DNS is largely clean — production is proxied, no admin panel or RFC1918 exposed; the only origin-IP exposure is a single mail-autodiscover record. (Confirmed)
• No edge evidence of successful mass exfiltration. (Confirmed)

7. Recommendations (evidence-prioritized)

Highest impact

1. Activate the managed WAF / OWASP ruleset. Bring it into active execution (block high-confidence signatures; brief log-then-tune for the rest). This adds the missing signature-defense tier and telemetry on /api/v1/adHandler, and — critically — provides a backstop behind the single custom rule. Evidence: 0 managed events in 30 days. — Low–Medium effort
2. Fix or repurpose rate limiting. The v165 config is being maintained but only fired 9,830 times — investigate whether thresholds are set far too high, then set effective limits on record/address/API endpoints so rate limiting actually contributes a second enforcement mechanism. Evidence: 9,830 rate-limit events vs 166.5M blocks. — Low effort

Sustaining / resilience

1. Reduce single-rule dependence. Split the dominant block logic across layered rules (and/or lean on the managed WAF once active) so no single rule failure collapses enforcement. Evidence: 99.99% of blocks from one rule. — Medium effort
2. Turn security level on to add a reputation-challenge layer ahead of the custom rule. Evidence: zero securitylevel events. — Low effort
3. Proxy or remove the autodiscover origin-IP record if direct reachability isn't required. Evidence: unproxied A → 204.44.57.32. — Low effort

Verify (blocked by token scope this run)

1. Confirm SSL/TLS mode = Full (strict), min-TLS ≥ 1.2, HSTS enabled, and Page Shield status with a settings-scoped read token. — Low effort

None of these require new licensing — all sit within the existing Enterprise entitlement.

8. Executive Score: 60 / 100

Interpretation: Extremely effective, extremely concentrated. The estate's most aggressive and effective enforcement contains the estate's heaviest attack — but it all rests on one custom rule, with the managed WAF inactive, rate limiting inert, and security level off.

Bottom line: fastpeoplesearch.com absorbs the heaviest scraping load in the estate and, on the surface, does so extremely well — 48.4% of traffic 403'd and a 93.5% challenge-abandonment rate. The concern is resilience and depth, not current effectiveness: the entire blocking function is one custom rule, the managed WAF is dormant (no signature defense or telemetry for the live API), rate limiting is heavily configured but not firing, and security level is off. Activating the managed WAF and restoring functional rate limiting — both inside the current plan — would give the zone the layered defense its traffic profile demands and remove the single-point-of-failure exposure.