Skip to content
Popproxx brand logo in stylized cursive font.
Rows of cars lined up in lanes at a highway toll plaza, seen from directly above

What a DDoS Attack Means for a Small WordPress Site

Jamin Giersbach
· Updated

A DDoS attack doesn't try to break into your WordPress site. It tries to make the site unreachable, by sending more traffic than the site, or the network in front of it, can handle. So most of the defense has to happen before the traffic reaches WordPress, and a security plugin on its own can't stop a big one.

I host existing WordPress sites on LiteSpeed servers I run. Here's the plain version.

What a DDoS attack is

A distributed denial-of-service (DDoS) attack tries to disrupt a server, service or network by flooding it, or the infrastructure around it, with internet traffic (Cloudflare). Cloudflare compares it to an unexpected traffic jam on a highway: regular traffic can't get where it's going.

The traffic comes from many machines at once, usually a botnet: computers and other devices infected with malware and controlled remotely. Because it comes from so many sources, it's hard to trace and hard to block by IP address (CISA, FBI and MS-ISAC guide).

CISA and Cloudflare sort attacks into three kinds:

  • Volumetric: use up the bandwidth between the target and the rest of the internet.
  • Protocol: wear out the server, or network equipment like firewalls, by exploiting weaknesses in network protocols.
  • Application-layer: hit the part of the server that builds web pages, with requests that are cheap to send and expensive to answer.

That last kind is why a site can go down under less traffic than you'd expect. WordPress runs on PHP and keeps your content in a database (WordPress requirements). Building a page often means querying that database, while asking for the page costs the sender almost nothing; multiply that by a botnet and the server can be overwhelmed (Cloudflare). Form submissions are expensive too, because the server has to process the data and write it to the database (Cloudflare).

DDoS or a brute-force login attack?

WordPress's handbook describes a brute-force attack as automated guessing of usernames and passwords until one works. It's often run from botnets too, and even a failed one can swamp a site with requests (Brute Force Attacks). In your logs the two can look alike. What differs is the goal:

Brute-force login attackDDoS attack
What it wantsTo get into an accountTo make the site unavailable
What it hitsThe login page and xmlrpc.phpThe network, the server or any page
What you noticePiles of failed loginsThe site is slow or down for everyone
What stops itStrong passwords, two-factor sign-in, limits on login attemptsFiltering before the traffic reaches your server

The login defenses are in my WordPress security checklist. Two from the handbook bear repeating: turn off XML-RPC if nothing on your site uses it, since it's a frequent brute-force target, and limit login attempts at the web server or a firewall in front of it, not only inside WordPress.

How to tell if your site is under one

From CISA's list of signs, the ones you're most likely to notice:

  • The site is suddenly unreachable, or much slower than usual.
  • Traffic jumps, sometimes at odd hours, without a reason you can name.
  • Lots of requests come from one IP address, or go to one page.
  • The server's CPU, memory or bandwidth use climbs suddenly and stays high.

On WordPress that often looks like pages that time out, or a "503 Service Unavailable" error: the server isn't ready to handle the request, commonly because it's overloaded or down for maintenance (MDN).

None of that proves an attack. A spike from a post that takes off can bring a server down too (Cloudflare). Two quick checks:

  • Try another connection. Load the site on your phone over mobile data. If it loads there, the problem may be your own network.
  • Compare with a normal week. CISA recommends knowing your baseline so a jump stands out. Your analytics or your host's statistics will show it.

Then ask your host. It can see the traffic hitting the server; you can't.

Why the defense happens upstream

A volumetric attack fills the connection between your server and the internet. Your real visitors are stuck in the same jam, and nothing running on the server can clear it, because the server never gets to sort good requests from bad. Cloudflare notes that most networks can't even take in a large amplification attack (Cloudflare).

So the filtering has to happen before the traffic arrives, somewhere with more capacity than the attack:

  • At the network. Your host or its internet provider may have mitigation in place, or be able to reroute traffic, CISA's guide notes.
  • At a CDN. A content delivery network is a group of servers around the world that caches your pages closer to visitors. Because it sits in front of your server, it can identify and block many kinds of malicious traffic before that traffic reaches you (Cloudflare).
  • At a DDoS protection service. CISA's guide suggests considering a DDoS mitigation provider, which has the infrastructure to handle large attacks and filter them out before they reach your network.

They use tools like rate limits, a web application firewall (WAF) and spreading the attack across a large network (Cloudflare). The blunt one is blackhole routing: without finer rules, it drops all traffic to the target, real visitors included. Cloudflare points out that this hands the attacker what they wanted, but that a network may still do it to an attacked small site to protect everyone else on it (Cloudflare).

Where a plugin fits. A security plugin runs inside WordPress, so every request it blocks has already reached your server. The handbook makes the point about login limits: a plugin still uses server resources under a heavy attack, so throttle at the edge or the web server where you can (Brute Force Attacks). Against a full connection, a plugin can't help at all. It still earns its place for other jobs, like two-factor sign-in.

What you can do as an owner

You can't stop a large attack from your dashboard. You can make your site a cheaper target and hear about trouble fast.

  • Know your normal. Look at a typical week of traffic now, so a spike stands out later.
  • Hear it first. An uptime monitor tells you the site is down before a customer does. It's one of the checks in what it takes to look after a WordPress site.
  • Make pages cheap to serve. A page cache serves saved copies of your pages, which WordPress's handbook says reduces the processing load on the server (Cache). It won't stop a flood, but it helps a server keep up. My post on LiteSpeed Cache explains how one works.
  • Keep software updated and backups tested. CISA's guide lists both. My monthly maintenance tasks cover the routine.
  • Ask your host, before you need to:
    • Is there DDoS filtering in front of my server, and is it included?
    • If my site is attacked, could it be taken offline to protect the rest of the network?
    • Can I put a CDN or a DDoS protection service in front of my site?
    • How do I reach you when the site is down, and how soon will someone answer?

If you think it's happening now

From CISA's response steps, the ones that fit a small site:

  1. Tell your host. It may have mitigation in place or be able to reroute traffic.
  2. Write down what you see, with times. CISA recommends keeping timestamps and logs.
  3. Check for damage afterward. CISA's guide says to look for disruption, data loss or compromised systems. On WordPress, make sure your forms still send, your backups still run, and no unknown administrator accounts appeared.

What my hosting does

Here's how the WordPress sites I host answer two of those questions:

  • Is there DDoS filtering in front of the server? Yes. Every site I host sits behind Cloudflare, and Cloudflare says its DDoS protection is available on all of its plans (Cloudflare). Visitors' traffic reaches Cloudflare first, and only what gets through goes on to my server.
  • Can a CDN or protection service go in front? It already is. Cloudflare is the CDN, and its firewall runs a set of custom rules I've written and keep up to date. I don't publish the rules: a firewall works better when attackers can't read it.

Behind Cloudflare, each site runs the LSCache plugin on a LiteSpeed server, so most pages are served from cache instead of built fresh by WordPress for every request. My LiteSpeed post explains that part. The other two questions depend on your site, so ask me.

Hosting for an existing WordPress site

I host and look after existing WordPress sites case by case, on LiteSpeed servers I run. Tell me about yours and I'll send a written quote for hosting and upkeep before anything changes. Content and design changes aren't included. A $500 deposit starts the quote. It's refundable until you accept, and credited to the work. The questions above are fair to ask me too. Ask for a quote.

Jamin Giersbach, who runs Popproxx
Written by

Jamin Giersbach

Jamin Giersbach is one of the three designers who started Popproxx in New York City in 2000. Early clients included WebMD, MSD Capital and Bookmans. In 2007 he took Popproxx to Oregon, and he has run it on his own ever since.

Read the full story →