Cloudflare

Cloudflare in front of your server hides its address, absorbs volumetric attacks that no software on the server can stop, and caches your pages around the world. WardPane can run behind it, but you have to mark each proxied site, otherwise every visitor looks like Cloudflare to the panel.

Behind Cloudflare

In the site’s settings, turn on Behind Cloudflare for every site whose DNS records are proxied (the orange cloud). The switch affects the four things described below.

Real visitor IPs

Behind Cloudflare, every connection to your server comes from a Cloudflare address, and the visitor’s own address is in the CF-Connecting-IP header. WardPane takes the visitor’s IP from that header, but only for sites marked “Behind Cloudflare” and only when the connection really comes from a Cloudflare address. From any other source the header is ignored, since anyone could write any address into it.

Cloudflare’s address ranges are built in and refreshed once a day from cloudflare.com.

Once the real IP is known, these work per visitor: the rate limit and bans, Bot Fight Mode address checks, Geo-blocking, the global blocklist, the IP binding of required URL parameters, the logs, and REMOTE_ADDR for PHP scripts.

Certificates behind the orange cloud

WardPane issues Let’s Encrypt certificates even when the domain’s DNS points to Cloudflare instead of your server. Set the zone’s SSL/TLS mode in Cloudflare like this:

1. For the very first certificate, use Full or Flexible. Until the certificate exists the server answers with a self-signed one, which “Full (strict)” refuses.
2. Once the certificate is issued, switch to Full (strict). Cloudflare then checks your server’s certificate, and the connection between Cloudflare and your server is properly encrypted.

The SSL/TLS mode is a zone-wide setting: it affects every site in that Cloudflare zone.

If the zone uses “I’m Under Attack” mode or a high security level, Let’s Encrypt’s validation requests can be stopped by Cloudflare’s challenge. The API integration described below handles that.

HTTPS redirects without loops

In “Flexible” mode Cloudflare talks plain HTTP to your server even when the visitor uses HTTPS. A plain HTTP to HTTPS redirect would then loop forever. WardPane reads the visitor’s real scheme from the CF-Visitor header and redirects only visitors who really came over HTTP. PHP scripts also get HTTPS=on for HTTPS visitors, which keeps WordPress out of a redirect loop as well.

Allow traffic only through Cloudflare

With Allow traffic only through Cloudflare on, direct requests for this site to your server’s IP get a 404. An attacker who has found your server’s real address then cannot reach the site around Cloudflare’s protection. Turn it on once the site works through Cloudflare.

If the switch is off but the site is behind Cloudflare

In that case every request comes from a Cloudflare address, and each such address stands for many of your visitors at once. Banning one would close the site for everyone routed through that Cloudflare server, so WardPane recognises Cloudflare addresses and handles them differently:

• Cloudflare addresses are never banned.
• The rate limit is counted per Cloudflare server, with ten times the site’s limit.
• Bans, the public IP blocklists, crawler verification and blocking by IP, scan detection, countries and networks are skipped for such requests. Only the checks of the request itself still work: User-Agent rules, attack payloads in the URL, probes and methods. The browser language filter works too.
• The IP binding of required URL parameters is off: remembering a Cloudflare address would open the site to everyone behind the same Cloudflare server.
• The activity log gets a warning, at most once a day per site, suggesting that you turn on “Behind Cloudflare”.

The site keeps working, but most of its protection stays idle until you turn the switch on.

Cloudflare Workers

Requests made by a Cloudflare Worker also come from Cloudflare addresses, and anyone can create a free Worker. If such requests counted as “Cloudflare”, an attacker with a Worker would escape every per-IP rule. WardPane therefore counts them by the Worker’s zone, from the CF-Worker header (worker:<zone>), with the normal limits and bans, and a misbehaving Worker gets banned like any visitor.

A Worker of the site’s own zone (the site’s domain or a parent domain of it) carries all your real visitors, so it is treated as an ordinary Cloudflare address, never banned.

Connecting the panel to Cloudflare

The panel can talk to the Cloudflare API to check and fix your zones. The connection is optional. Without it the panel never contacts Cloudflare’s API, and everything above still works. In 2.0 you connect with an API token; signing in with Cloudflare is planned for 2.4.

With an API token

1. In the panel, press Create Cloudflare token. The button opens Cloudflare’s API token page with a template that already has the needed permissions:

   • Zone: Read
   • DNS: Edit
   • Zone Settings: Edit
   • Config Settings: Edit (this is what Cloudflare calls the permission for Configuration Rules)

2. Create the token in Cloudflare, limit it to your zones if you like, and copy it.

3. Paste it into the panel in Settings > Integrations, or set it in /opt/wardpane/.env:

   CLOUDFLARE_API_TOKEN=your_token
   

   A value saved in the panel applies at once; a change in .env applies after sudo systemctl restart wardpane.

Use a limited API token, never your Global API Key: the Global API Key gives full control of your whole Cloudflare account. The panel never sends the token back to your browser; it only shows that a token is set.

Sign in with Cloudflare

Planned for 2.4, see the roadmap. Sign in with Cloudflare will connect the panel without copying a token: you approve the access on Cloudflare’s site.

The panel starts the authorisation itself, using PKCE, so the secret part of the exchange is created in your panel and never leaves it. Every WardPane panel runs on its own address, while a Cloudflare OAuth client has one fixed address to return to. So after you approve, Cloudflare sends you first to a relay page at https://cloudflare.wardpane.com/callback.

That relay page shows, in large letters, the address of the panel the authorisation will be sent to, and sends it there only after you press Continue:

• Press Continue only if the address shown is your own panel.
• If it is not, or you did not start a connection just now, press Cancel.

The relay never redirects on its own, and it stores and logs nothing about the authorisation. If Cloudflare refused the authorisation, the relay offers to tell your panel that the connection did not work.

The Cloudflare API integration

With a connection in place, the Behind Cloudflare section of a site’s settings has a Check Cloudflare setup button. It reads the zone and shows what is there, without changing anything:

• the DNS records of every domain and alias of the site: whether each exists, points to this server and is proxied (orange cloud);
• the zone’s SSL/TLS mode, and the recommended one: Full while the site has no trusted certificate yet, Full (strict) once it has;
• the security level, and whether the ACME challenge path is exempt from it.

It then offers to fix only the problems it found, and nothing changes until you press Apply:

• create or correct the A records so each name points to this server through the orange cloud;
• set the recommended SSL/TLS mode (zone-wide);
• add the ACME rule (below).

Every change is listed in the result and written to the activity log.

The ACME rule

Let’s Encrypt validates a domain by fetching a file under /.well-known/acme-challenge/. With Cloudflare’s “I’m Under Attack” mode or a high security level, that request meets a challenge page and validation fails. A Configuration Rule in the zone that turns the security level off for that one path solves this. That path holds nothing but one-time random tokens, and the rest of the site keeps its full protection.

This rule is the only change the panel makes without asking: it is added automatically before a certificate is issued, because without it issuance cannot work. The panel touches no other rule, and if you already made an equivalent rule yourself, the panel recognises it.

Lifting Under Attack mode as a last resort

If Cloudflare refuses to create the rule (for example, the token lacks the Config Settings permission), the panel can, for the moment the challenge takes, switch the zone from “I’m Under Attack” to “High” and then straight back. The previous level is written to disk first, so it is restored even if the panel crashes in the middle; a failed restore is retried with increasing pauses, and the log tells you if you need to turn it back on by hand.

The whole zone is less protected during those seconds, so the panel does this only when the targeted rule was refused. To forbid it completely, set:

CLOUDFLARE_LIFT_UNDER_ATTACK=false

(in .env, or in Settings > Integrations; the default is true).

DNS sync

Syncing DNS zones with Cloudflare is planned for 2.4, together with WardPane’s own DNS server; see DNS. In 2.0, Check Cloudflare setup already creates or corrects the A records of each site in its Cloudflare zone, as described above.

Behind other proxies

WardPane trusts the visitor address only from Cloudflare. Behind any other proxy or CDN, every request carries the proxy’s address: do not turn on DDoS protection for such a site, since one ban would block everyone.