CLOUDFLARE
Cloudflare Security Baseline¶
The NetWise Cloudflare baseline is the canonical set of custom WAF rules expected on managed client zones. The baseline auditor checks the estate daily and automatically adds missing canonical rules only when it discovers a genuinely new zone.
Exact Cloudflare expressions belong in the Worker source, not in this wiki. This page describes what the rules are intended to do and how the automation handles them.
Canonical baseline¶
The baseline currently contains exactly three rules, in a defined relative order.
Let's Encrypt¶
Allows ACME challenge requests under /.well-known/acme-challenge/ to bypass the relevant Cloudflare security layers required for certificate validation.
The purpose is to allow legitimate Let's Encrypt certificate validation without broadly bypassing protection for the rest of the site.
Malicious Probe Protection¶
Blocks direct requests targeting exposed .env and .git resources.
These are common reconnaissance/probing targets and should not be publicly accessible.
Managed Challenge Protection¶
Applies a managed challenge to traffic matching the current NetWise suspicious-request policy.
The policy includes:
- WordPress login requests;
- non-GB requests to
/event,/eventsand their child paths, while excluding iCal requests; - probes for sensitive files, source-control paths, environment/configuration data and known malicious filenames;
- traversal and encoded-traversal patterns covered by the current Worker implementation.
The exact expression can change as the protection evolves. Refer to workers/baseline-auditor/src/baseline.ts when the exact current matching logic is required.
New-zone onboarding¶
When the daily audit encounters a Cloudflare zone ID that is not already in the registry, it treats it as a new zone.
If the zone already matches the canonical baseline, no WAF write is needed.
If canonical rules are missing, the Worker adds only the missing rules and preserves unrelated rules. It then verifies:
- that each canonical rule exists exactly once;
- that its definition matches the canonical definition;
- that the canonical rules appear in the required relative order;
- that unrelated rules have not changed.
There is also a configured custom-rule slot limit. If onboarding cannot safely fit the missing baseline rules, it fails rather than deleting or replacing unrelated rules to make space.
Known-zone drift¶
Once a zone is known to the registry, the daily auditor does not automatically repair it.
A known zone that matches the baseline is reported as PASS. A known zone with missing, duplicate, changed or incorrectly ordered canonical rules is reported as DRIFT, with no WAF writes.
This is an important safety boundary. Do not rely on the next daily run to repair an established zone, and do not automatically treat every difference as something that should be overwritten.
Failed onboarding and rollback¶
A failed first-seen onboarding is recorded as failed and is not automatically retried on subsequent daily runs.
If the Worker has already created rules during that onboarding attempt and later verification fails, it removes only the rule IDs created during that run and verifies the rollback. Existing unrelated rules are preserved.
Failed onboarding therefore requires supervised investigation rather than an endless automatic retry loop.
Meta and Facebook crawler rules¶
Historical Meta/Facebook crawler rules are explicitly excluded from the canonical baseline.
If such rules already exist, the onboarding process preserves them as unrelated rules, but the Worker does not generate them.
Where a Meta/Facebook exception is intentionally present, its purpose is limited to allowing Facebook/Meta to retrieve the metadata and preview image required when a client shares a website link. It is not intended as a general privileged-access or broad security bypass.
Do not add or remove these rules merely to make a zone match the canonical baseline.
Changing the baseline¶
Treat a baseline change as an estate-wide security change, not as an isolated edit to one client zone.
Before changing the canonical baseline:
- establish the reason for the change and the traffic it is intended to affect;
- review the current Worker implementation and existing estate exceptions;
- test the proposed behaviour safely;
- consider the effect on new-zone onboarding as well as established zones;
- validate the estate after deployment and investigate reported drift rather than blindly overwriting it.
The Worker source remains authoritative for the exact canonical definitions.