CDN-Fronted and WAF-Protected Services in Edgewatch

Edgewatch identifies whether an internet-facing service is CDN-fronted and/or WAF-protected as part of every scan. By default we use safe, passive techniques (DNS, IP ranges/ASN, HTTP headers, and TLS hints). We do not run heavy exploit attempts against Cloudflare or other CDN/WAF edges because it is technically noisy, usually ineffective, and risks collateral impact to third parties.
Customers on the Professional plan can optionally enable WAF detection & bypass checks to evaluate WAF configurations in a controlled, rate-limited manner.

What “CDN-fronted” and “WAF-protected” mean

• CDN-fronted: Content is delivered through a Content Delivery Network acting as a reverse proxy (e.g., Cloudflare, CloudFront, Fastly, Azure Front Door, Akamai, Edgio).
• WAF-protected: A Web Application Firewall sits in front of the origin, filtering and inspecting requests (e.g., Cloudflare WAF, Imperva, F5, ModSecurity-based).

A target can be both CDN-fronted and WAF-protected (common with integrated CDN+WAF providers).

How Edgewatch detects CDN/WAF (default: passive, safe)

We combine multiple low-risk signals and return a confidence score plus evidence:

• DNS & CNAME patterns – e.g., *.cloudfront.net, *.azurefd.net, etc.
• IP range / ASN matching – first-party CIDR lists and ASN hints for major providers.
• HTTP response headers – provider-specific markers (e.g., cache IDs, proxy Via, known Server values).
• TLS certificate/SAN hints – occasional edge-certificate indicators.

Why Edgewatch avoids exploit attempts against CDN/WAF edges

1) Technically noisy & easily detected
CDN/WAF platforms are purpose-built to spot probing and rate-limit or tarpitting scanners. Aggressive payload spraying generates large, obvious signal with little diagnostic value.

2) Low signal for the origin
Attacking the edge rarely reaches the origin application; results reflect the provider’s shared mitigation, not your app’s true risk posture.

3) Risk of collateral impact
CDN IPs and PoPs are multi-tenant. Excessive testing can affect unrelated domains behind the same edge, trigger broad rate-limits, or violate provider AUPs/ToS.

4) Compliance & reputational considerations
“Loud” exploit attempts from public clouds or data-centers can be interpreted as abuse, complicating incident response and legal/compliance posture.

Bottom line: Passive fingerprinting provides the high-value answer (whether a service is shielded and by whom) without unnecessary noise.

Professional plan: optional WAF detection & bypass checks

For customers who need to assess WAF coverage and rule efficacy, Edgewatch offers an opt-in module with strict guardrails.

What’s included

• WAF fingerprinting (low-impact): identify likely vendor/engine and key behaviors.
• Lightweight evasion checks (configurable): safe variants of header/method/encoding handling to reveal misconfigurations (e.g., inconsistent normalization).
• Controlled execution: rate-limited, concurrency-capped, geo-scoped, and respect for target scopes you define.
• Evidence & guidance: clear pass/fail indicators, sample requests (redacted), and remediation tips.
  

Enabling the module

1. Plan: Professional or higher.
2. Scope: define permitted domains/paths and maintenance windows.
3. Settings: enable WAF Detection & Bypass Checks in your scan profile (Dashboard → Scanning Profiles).
4. API: set waf_tests: “passive” | “light” in the scan request body.
5. Audit: review results in the Findings panel with evidence and replayable (sanitized) samples.
   

Note: This module targets configuration validation, not exploitation. It is designed to avoid denial-of-service conditions and adheres to provider AUPs and your internal testing policies.

Best practices when your service is CDN-fronted

• Origin hardening still matters: assume bypass paths exist (direct IP, mis-scoped DNS, alternate hostnames).
• Restrict origin access: allow-list CDN egress ranges or use private connectivity (e.g., “origin pull” over private links).
• Explicit WAF policies: enable/ tune managed rules, add app-specific virtual patching, and monitor false positives.
• Logging & visibility: ensure edge logs are ingested into your SIEM; correlate with origin logs for full coverage.
• Periodic validation: rerun Edgewatch passive checks and, if needed, Professional WAF tests after rule or architecture changes.

Does Edgewatch ever run exploits?

No. By default we do not run exploit payloads. Professional plan customers may enable light WAF tests aimed at configuration validation—not exploitation.