Cloudflare Configuration

ORIGIN PROTECTION

Inbound traffic to the origin must be restricted to Cloudflare's published IP ranges plus any whitelisted VPN exit IP for direct dev access. This forces all public traffic through Cloudflare's proxy — nobody can bypass CF and hit the origin directly, which is what makes CF's WAF, rate limiting, and bot mitigation effective - otherwise an attacker could just find the origin IP and go around all of it.

• https://www.cloudflare.com/ips-v4
• https://www.cloudflare.com/ips-v6

Some of this is supposed to be enabled now, although it should be done at the hardware/cloud level, not just on the server.

• Verify this is complete

BOT DETECTION

Bot fight mode should be enabled.  If on the Pro plan, Super Bot Fight mode can be customized, but start with the default values:

• Javascript detections = On
• Optimize for WordPress = Off
• Static resource protection = Off
• Definitely automated traffic = Allow
• Verified bots = On

SECURITY SECTION

Managed rule: Cloudflare OWASP Core (disable)

This is a managed ruleset provided by Cloudflare and should be disabled initially.  It prevents many documented types of attacks like cross site scripting (xss) and sql injection (sqli) among others.  It’s worth monitoring the security event log to verify against any potential false positives which could be significant.

• OWASP anomaly = Medium (40+)
• Paranoia level = PL1
• Action = Block

Managed rule: Cloudflare Managed Ruleset (enable)

Another managed ruleset that Cloudflare handles.  We should leave it on, but again, monitor the security event log for false positives, although this rule set known to be more accurate in Cloudflare’s environment.

• Action = Default
• Status = Default

Custom rule: Allow access by IP

• When incoming requests match: IP is in Administrators list
• Take action: Skip
• Log requests
• Skip WAF rules... Custom, rate limiting, managed, bot fight

Rate limiting rule: Limit login requests

• When requests match...

(http.request.uri.path eq "/wp-login.php") and (http.request.method eq "POST")

• When rate exceeds... 5 requests in 1 minute
• Action: Block, Response type: default
• Duration: 20 minutes

CACHING SECTION

The caching behavior is broken down into an Allow, then Exclude order, to increase the readability and understanding of the setup.  Rules are named semantically.

Rule: Cache *

• All incoming requests
• Eligible for cache
• Edge TTL: Use cache-control header if present, cache request with Cloudflare's default TTL for the response status if not.
  • Default TTLs are below
  • http code 200, 206, 301 = 120m
  • http code 302, 303 = 20m
  • http code 404, 410 = 3m

Rule: Exclude basic paths

• URI Path starts with: /wp-admin/, URI Path starts with /wp-json/, URI Path equals /wp-login.php, URI Path equals /xmlrpc.php
• Bypass cache

Rule: Exclude basic cookies

• Cookie contains: wordpress_logged_in_, Cookie contains wordpress_sec_, Cookie contains wfwaf-authcookie
• Bypass cache

PLUGIN INTERACTIONS

Cloudflare Plugin 

We are using this plugin solely to purge the cache.  It is capable of doing APO (automatic platform optimization) but this can be overreaching – the most straightforward path is to simply understand the moving parts and minimize their interaction.

The plugin requires an API token – we start with the global token, then limit that after verifying the desired results have been achieved.  When this API token is entered, the plugin immediately begins to properly purge the cloudflare cache upon post edit/publish.

• Limit the scope of the token to the minimally required permissions 

Wordfence Plugin

Wordfence can largely operate as normally, although it will essentially only be protecting the administration area.  

• IP address detection should use the “CF-Connecting-IP” option
• Firewall can be optimized
• Rate limiting and DDOS protection can be enabled

A large site should utilize the paid professional version to enable the realtime protection, geolookups, and malware definitions.

• Verify the plugin is actually optimized