Cloudflare Security Effectiveness Assessment — actualpeoplesearch.com

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

1. Executive Summary

• By far the smallest property in the estate. The zone served 12.86M requests / 0.15 TB over 30 days — one to two orders of magnitude below the estate's larger properties — with almost no caching (0.4%). (Confirmed)
• Low absolute attack pressure, but actively scraped. Only 94K requests (0.7%) carried the legacy "threat" flag, yet 1.47M requests (11.4%) were rate-limited (429) and 1.66M were challenged — the real mitigation footprint. Traffic skews to Southeast Asia (Myanmar 15%, Philippines, Pakistan, Malaysia) alongside a clean US majority. (Confirmed)
• Rate limiting is the dominant, well-targeted control here. It fired 1.48M times, challenging the directory-enumeration surface (/people, /directory, /lastnames/<name>, /firstnames/<name>, /areacodes, /zipcodes). This is the highest rate-limit-to-traffic ratio in the estate. (Confirmed)
• Bot Management is active. botScore is populated across traffic (only ~1% unscored); of ~12.77M scored requests, ~50% score as likely-human, ~38% automated, ~12% grey. (Confirmed)
• The Managed WAF / OWASP ruleset is inactive. It generated only 420 events in 30 days — no signature-based defense and no WAF-layer telemetry. (Confirmed)
• Custom-rule depth is thin. The custom firewall phase is lightly configured (v30, mostly skip, ~90K blocks); the security tuning here is the lightest in the estate (rate-limit phase at v1). (Confirmed)
• Perimeter hygiene is clean. DNS (28 records): production is proxied (AWS Elastic Beanstalk); no origin IP, admin panel, or RFC1918 is exposed. (Confirmed)
• Overall risk: MEDIUM — a small, low-volume PII property whose primary threat (directory scraping) is being actively and appropriately mitigated by rate limiting + bot management on a clean perimeter, but which lacks an active signature WAF, has minimal custom-rule depth, and caches almost nothing. Executive score: 64/100.

2. Traffic Overview

30-day totals (Confirmed — httpRequests1dGroups)

Edge response codes (Confirmed): 200 10.88M (84.6%) · 429 1.47M (11.4%) · 403 292.7K (2.3%) · 301 104K · 404 54K · 499 47K · 302 6.1K · 502 972 · 500 927. The 11.4% 429 rate — not the 403 rate — is this zone's defining enforcement signal: rate limiting, not blocking, is the primary control.

Human vs Bot breakdown

Derived from the adaptive bot-score dataset — estimates with stated assumptions. Only ~143K (1.1%) of the adaptive total (≈12.9M) was unscored — because near-zero caching means essentially all requests reach the bot engine. Percentages are given as a share of scored traffic.

Verified good bots (Confirmed — verifiedBotCategory, ~2.1M total): Search Engine Crawler 836K · AI Assistant 489K · AI Crawler 479K · SEO 235K · other <25K each.

Assumptions: (1) botScore < 30 = automated per Cloudflare guidance; (2) unscored traffic excluded from ratios; (3) verified good bots reported separately as they legitimately score low. Note: Bot Management scoring is confirmed active on this zone (botScore populated across traffic). Takeaway: about half of scored traffic is likely-human; the automated share is concentrated in directory-enumeration scraping (see §4).

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 1.66M · skip 1.40M · managed_challenge_bypassed 1.04M · block 90.5K · managed_challenge_non_interactive_solved 4.1K · managed_challenge_interactive_solved 3.7K · allow 590.

3.3 Per-protection scorecard

Challenge math (Confirmed): 1.66M challenges issued, ~7.8K solved → ~99.5% abandonment (the overwhelming majority of challenges — driven by rate limiting — are abandoned). A further 1.04M "bypassed" events are returning clients with valid clearance tokens.

Rate-limiting finding — the primary control (Confirmed): rate limiting is the zone's dominant defense, firing 1.48M times and correctly targeting the directory/enumeration surface (/people, /directory, /lastnames/<name>, /firstnames/<name>, /people/<state>). This is appropriate and effective against the observed scraping.

Managed WAF finding (Confirmed): the Cloudflare Managed Ruleset (v377) and OWASP Core Ruleset (v88) appear in the ruleset inventory but generated only 420 events in 30 days — no active signature defense and no WAF-layer telemetry.

Custom-rule finding (Confirmed): the custom phase is lightly configured (v30) and mostly issues skip/allow decisions, with only ~90K blocks — the thinnest custom-rule depth in the estate.

4. Attack Analysis

(All Confirmed from 30-day firewall events; because hard blocks are low, figures below reflect mitigated events — challenge + block + rate-limit — excluding skip.)

Top mitigated countries: Myanmar 1.07M · United States 1.03M · Malaysia 228K · Philippines 136K · Singapore 132K · Canada 44K · Pakistan 16K · Brazil 13K · Germany 10K · Saudi Arabia 8K · Argentina 7K · Iraq 7K. (Myanmar is the single largest mitigated source — see ASN below.)

Top mitigated ASNs (operator names from public registries, not Cloudflare data — Likely): AS14593 SpaceX Starlink 1.30M (dominant — the Myanmar scraping rides Starlink) · AS18779 143K · AS45102 Alibaba Cloud 130K · AS36352 ColoCrossing (US hosting) 125K · AS64286 101K · AS55286 (server hosting) 93K · AS4775 Globe Telecom (Philippines) 89K · AS16509 Amazon AWS 65K · AS212238 Datacamp/CDN77 61K · AS21928 T-Mobile 35K. A Starlink-borne scraping campaign plus cloud/hosting sources.

Top targeted paths (mitigated): /people 47.5K · /blog 31.9K · /directory 20.0K · / 18.6K · /areacodes 15.9K · /firstnames 12.8K · /lastnames 12.1K · /zipcodes 11.9K · /lastnames/smith, /lastnames/brown, /lastnames/jones, /lastnames/williams · /firstnames/robert, /firstnames/john · /find/person/<name>-<id>. (Systematic enumeration of the name/location index — walking common surnames and given names.)

Top abusive IPs (mitigated): 150.228.149.193 (401K), 150.228.149.105 (357K), 150.228.148.255 (96K) (a concentrated scraper netblock) · 65.181.16.208 (162K), 65.181.16.148 (51K) · 129.224.203.90 (125K) · 172.121.235.202 (103K) · 107.174.136.152 (ColoCrossing, 84K) · 173.244.41.18 (64K) · one IPv6 (63K).

Top blocked user-agents (Confirmed): generic spoofed browser UAs — Chrome 150/145/144/143 on Windows/Mac — each ~4.7–5.7K (low volume, since hard blocks total only ~90K). (Chrome 150 is a future/spoofed version string — a fabricated-UA scraping signal.)

Most common WAF detections (Confirmed): the managed WAF is inactive (420 events), so mitigation comes from rate limiting and custom rules, not signature detections. Rule names/expressions were not readable (403).

Most common rate-limit triggers (Confirmed): /people, /directory, /lastnames/<name> (smith, brown, williams, jones, garcia), /firstnames/robert, and /people/<state> (texas, california) — all via managed challenge.

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.

5. Protection Coverage

✓ Enabled / Confirmed active

• Enterprise plan; Universal TLS certificate (Let's Encrypt active, valid to 2026-09-19; SSL.com backup)
• Apex, www, and product subdomains (pro, dev, qa, …) proxied (origin is AWS Elastic Beanstalk)
• Rate limiting — active and well-targeted at the directory-enumeration surface (the primary, effective control; 1.48M events)
• Bot Management — entitled and scoring live traffic; Managed Challenge in heavy use (~99.5% abandon)
• Custom firewall ruleset — present (v30), though lightly configured
• Cloudflare Managed Ruleset (v377), OWASP Core (v88), Exposed Credentials Check, DDoS L7 — present in inventory (but see gaps)
• URL Normalization; cache-settings and response-header phases present
• Clean DNS — production proxied, no origin IP / admin panel / RFC1918 exposed

⚠ Missing / inactive protections

• Managed WAF / OWASP enforcement — present in inventory but generating only 420 events. No signature defense, no WAF telemetry.
• Security-level reputation challenge — no securitylevel events observed; appears off.

⚠ Weak configuration

• Thin custom-rule depth — v30, mostly skip; only ~90K blocks. Lightest security tuning in the estate.
• Near-zero caching (0.4%) — essentially all traffic hits the AWS origin; a performance, cost, and availability concern (the origin absorbs the full scraping load rather than the edge cache).

⚠ 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. Certificates are Universal-only (no Advanced certificate).

6. Operational Risk: MEDIUM

Why MEDIUM (not HIGH):

• The primary threat is being actively and appropriately mitigated. Directory-enumeration scraping (Starlink/Myanmar, concentrated netblocks) is met with well-targeted rate limiting (1.48M events) and bot-management challenges, driving a ~99.5% challenge-abandonment rate. (Confirmed)
• The perimeter is clean — production is proxied, no origin IP, admin panel, or RFC1918 exposed; the edge cannot be trivially bypassed. (Confirmed)
• Low absolute attack volume (12.86M total requests) and a ~50% likely-human traffic share. (Confirmed)

Why not LOW:

• The managed WAF is inactive (420 events) — no signature defense or telemetry against injection/exploit attempts. (Confirmed)
• Custom-rule depth is minimal (v30, mostly skip) and security level is off — the defense leans on essentially one mechanism (rate limiting) plus bot challenges, with little layering. (Confirmed)
• Near-zero caching (0.4%) pushes the full request load — including scraping — onto the origin, an availability/cost exposure. (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) to add signature defense and telemetry the zone currently lacks entirely. Evidence: 420 managed events in 30 days. — Low–Medium effort
2. Add caching for the directory/index pages. At 0.4% cache, the origin absorbs nearly all traffic including scraping; caching the enumerable index pages (/lastnames/<name>, /areacodes, /zipcodes) would cut origin load and blunt scraping economics. Evidence: 0.4% cache ratio, 99.6% uncached. — Low–Medium effort

Sustaining

1. Deepen custom rules to complement rate limiting (e.g., country/ASN handling for the Starlink/Myanmar and hosting-ASN scraping already visible). Evidence: custom phase v30, mostly skip, 90K blocks. — Low–Medium effort
2. Turn security level on to add a reputation-challenge layer. Evidence: zero securitylevel events. — Low effort
3. Preserve the rate-limiting and clean-DNS strengths — the well-targeted rate limiting and fully-proxied DNS are this zone's best controls. — Low effort (governance)

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: 64 / 100

Interpretation: A small, low-volume property whose primary threat is well-mitigated by rate limiting and bot management on a clean perimeter, but whose defense is thin in depth — no active signature WAF, minimal custom rules, and almost no caching.

Bottom line: actualpeoplesearch.com is a small property that is, for its size, defending its main threat well — directory-enumeration scraping (Starlink-borne from Myanmar, plus cloud/hosting sources) is actively met by well-targeted rate limiting and bot-management challenges on a clean, fully-proxied perimeter. The gaps are depth: the managed WAF is inactive, custom rules are minimal, security level is off, and caching is near-zero (the origin absorbs everything). Activating the managed WAF and adding caching to the index pages — both within the current plan — would move this from a single-mechanism defense to a properly layered, resilient one.