Network-Wide Threat Intelligence: How Deliverypath Secures WordPress Hosting
WordPress is the most widely deployed CMS on the internet, which also makes it the most widely attacked. Any site running it will see credential stuffing attempts, REST API enumeration, plugin vulnerability scanning, XML-RPC abuse, and content scraping within hours of going live. This is baseline internet weather, not a sign that a particular site has been singled out.
The question for a hosting provider is not whether this traffic arrives. It’s what the platform does about it. Deliverypath rebuilt its hosting platform around a specific answer to that question, and this article explains how it works and why we chose it.
The old model: per-site and reactive
On our previous platform, mitigation happened one site at a time. A site would show elevated load or a spike in failed logins, someone would investigate, and a rule or an IP block would go into place for that site.
That approach works, but it has structural problems:
- It’s reactive. Protection is applied after a site has already absorbed the attack.
- It doesn’t scale. Every site is defended in isolation, so the same attacker gets a fresh attempt against every property in the portfolio.
- It depends on someone noticing. Low-and-slow attacks that never trip a resource alarm run indefinitely.
- It expires badly. Manual blocks tend to be permanent, which means IP addresses stay blocked long after they’ve been reassigned to someone else.
It is also expensive, which turns out to matter quite a bit. More on that below.
We rebuilt the platform to remove the human from the loop entirely.
The new model: a sensor network feeding a shared blocklist
1. Honeypot sites as sensors
We operate an array of websites that exist for one purpose: to be attacked. They carry no real content, are not linked from anywhere meaningful, and are not intended for human visitors. Essentially all traffic they receive is automated.
2. Behavioral profiling, not signature matching
Each request against the sensor network is evaluated against a set of behavioral rules. We are not matching known-bad IP addresses from a purchased list. We are watching what a client actually does and classifying it on that basis.
The rule set is maintained continuously. When attackers develop new probing patterns, we add profiles for them, and the sensor network begins identifying that behavior across the board.
3. Propagation to the entire fleet
When a source IP trips a rule, it is added to a universal blocklist. That list is enforced at the edge on every website Deliverypath hosts.
This is the part that changes the economics. An attacker who probes one of our honeypots is blocked from all Deliverypath customer sites before they get to any of them. Every customer benefits from every attack against every other property on the platform, including the decoys built specifically to attract them.
4. Automatic expiry and re-blocking
Blocks are not permanent. After a defined dwell time, an IP address is released automatically and can reach hosted sites again.
This matters more than it might appear. IP addresses are recycled constantly. Residential addresses change hands on DHCP lease renewal, cloud provider IPs are reassigned to new tenants daily, and mobile carrier ranges rotate through enormous user populations. A permanent block on any of these is a guarantee that legitimate visitors will eventually be locked out of a site for something a previous occupant of that address did.
If the address resumes hostile behavior after release, it is re-blocked immediately. Persistent attackers stay out. Recycled addresses come back into service on their own.
Why we built it this way: capacity is cost
There is a business reason behind the engineering, and we’d rather state it plainly than pretend the motivation was purely technical.
Hostile traffic is not free. Every scanner request that reaches PHP consumes a worker process, a database connection, memory, and CPU time. At scale, that adds up to real infrastructure spend on serving requests that will never become a customer, a reader, or a lead for anyone.
There is a labor cost on top of that. Investigating incidents site by site, writing one-off rules, and maintaining per-site block lists is skilled work performed repeatedly on problems that are essentially identical. Under the old model, growth in the number of hosted sites meant a roughly proportional growth in security overhead.
Both of those costs land somewhere. In this industry, they usually land on the customer as a price increase, a lower resource ceiling, or a “premium security” line item added to the invoice.
Automating the work and filtering hostile traffic before it reaches the application changes the shape of that curve. The security overhead per site drops toward zero as the platform grows, because the same blocklist protects one site or four thousand at the same cost. That efficiency is what lets Deliverypath absorb rising attack volume without repricing hosting or moving protection behind an upsell. Holding prices steady was an explicit design goal, not a side effect.
Good bots are welcome
Blocking automated traffic indiscriminately is a mistake. A large share of the automated traffic hitting a modern website is doing something a site owner actively wants.
Deliverypath’s policy is behavioral rather than categorical. Search crawlers, social preview fetchers, uptime monitors, and AI indexing agents are all permitted, provided they observe basic crawl hygiene: reasonable request rates, honest user agent identification, and respect for robots.txt. A crawler that requests eighty pages per second is not indexing, it’s a denial of service, and it gets treated as one regardless of whose name is on the user agent string.
This applies to AI crawlers specifically, because customers ask about them. Our default is to allow them. Being present in AI-generated answers is increasingly a meaningful source of discovery, and for most of our customers, that visibility is worth having.
If you’d rather not participate, we can exclude AI crawlers from your site on request. It’s a per-site setting, and the decision is yours.
What this looks like from the customer side
Lower total server load. Hostile traffic is rejected at the edge before it reaches PHP or the database. Server resources go to real visitors instead of to scanners.
More consistent performance under attack. A brute force campaign against one site no longer competes for resources with everyone else’s traffic.
Analytics numbers may shift downward. This is the change customers are most likely to notice, so it’s worth being clear about. If your reporting includes any server-side or log-based component, you should expect the raw request count to drop. That drop is not lost audience. It’s traffic that was never a potential customer, never converted, and never did anything for your business except consume capacity you were paying for.
Less noise in security plugin reports. Attacks that get stopped at the edge never reach the application, so they stop generating alerts.
No configuration work. There is nothing to install, enable, or maintain. This is a property of the Deliverypath platform, included with hosting.
Where this differs from typical WordPress hosting
Most hosting providers do apply some form of protection. What varies is the architecture, and the architecture is what determines the outcome.
The common approaches are a per-site security plugin, which spends your server’s own resources to evaluate an attack that has already arrived; a generic managed firewall with a vendor-supplied rule set that isn’t derived from attacks against your neighbors; or a purchased commercial IP reputation feed, which reflects what a third party observed somewhere else, often days ago.
Deliverypath runs its own sensor network and generates its own intelligence. The blocklist protecting your site is built from attacks recorded against infrastructure we operate, propagated across the fleet automatically, and expired on a schedule so it doesn’t accumulate stale entries. We are not aware of many hosts at our scale running purpose-built honeypots as a standard part of the platform, and we haven’t seen it offered as an included feature rather than a paid add-on.
What this doesn’t do
It would be dishonest to present edge filtering as complete security. It isn’t, and no single control is.
Network-level blocking stops known-hostile sources. It does not patch a vulnerable plugin, it does not make a weak administrator password strong, and it does not stop an attack originating from an address with no prior history. It is one layer, and it works alongside the others Deliverypath maintains: isolated per-site users and PHP processes, current core and plugin versions, enforced credential standards, and backups.
What it does eliminate is the volume. The overwhelming majority of hostile traffic aimed at WordPress is automated, opportunistic, and repetitive. Filtering that at the network edge, automatically and continuously, lets both our attention and your server’s resources go toward things that actually matter.
Questions about your site’s traffic patterns or crawler settings? Contact Deliverypath support.