All Magic Pages sites now run behind CrowdSec, an open-source Web Application Firewall (WAF) that adds an extra layer of protection against malicious traffic, automated attacks, and vulnerability scanning.
Why another security layer?
Magic Pages sites already benefit from Bunny.net Shield, which provides basic DDoS protection, and managed WAF rules. It's solid protection that handles the broad strokes of web security well.
But here's the thing: Bunny Shield's free tier doesn't allow custom rules. Their advanced features, like custom regex rules, AI-powered threat detection, and bot mitigation, cost $9.50 per site per month. For a platform hosting 1100+ Ghost sites, that math gets..uhh...a bit prohibitive.
More importantly, I've been watching the actual attacks hitting Magic Pages servers. The patterns are specific: WordPress probes on Ghost sites, PHP file requests where no PHP exists, attempts to access .git directories, and the usual suspects trying their luck with wp-admin and xmlrpc.php.
Generic WAF rules catch some of this, but not all. And I wanted something tailored to how Ghost sites actually work.
What CrowdSec does differently
CrowdSec runs directly in front of your site, inspecting every request before it reaches your Ghost instance. It works alongside Bunny Shield, not instead of it.
The setup includes:
- Community threat intelligence: CrowdSec maintains a blocklist of known malicious IPs, updated in real-time from their global network of users. If an IP is attacking sites elsewhere, it's already blocked before it reaches yours.
- Ghost-specific rules: Custom detection for attack patterns that don't apply to Ghost, like PHP file requests, WordPress admin probes, and attempts to access package.json or node_modules. These get blocked instantly rather than wasting resources on requests that would fail anyway. There are other custom rules in place, which I am not disclosing publicly though.
- Real-time analysis: Every request is evaluated against both the community blocklist and our custom rules, with decisions made in a few milliseconds (the average, so far, is 3ms – in my eyes, a good compromise for an extra layer of security).
What this means for you
Nothing changes on your end. CrowdSec is already active on all Magic Pages sites. There's nothing to configure, no settings to toggle, no extra cost.
What you might notice: slightly fewer random bot traffic hitting your sites (hello, dear Singaporean/Chinese IP addresses in analytics 👋). On the Magic Pages site alone, this kind of traffic dropped by 95% since I deployed a first test of CrowdSec yesterday.
The technical bit
CrowdSec sits at the ingress layer of our Kubernetes infrastructure (as well as the ingress of the new Docker Swarm cluster that's being set up and tested in the backgroudn). When a request comes in, it's checked against the community blocklist (currently around 15,000 known malicious IPs) and then analysed by the AppSec component for suspicious patterns.
Legitimate requests pass through in about 2-4ms. Malicious requests get a 403 and never touch your Ghost instance.
The whole system runs on a MySQL backend for performance at scale, with connection pooling to keep latency minimal even under heavy traffic.