DDoS Protection

A distributed denial-of-service (DDoS) is a large-scale attack using multiple IP addresses, attempting to overwhelm a site with requests, crashing it or slowing it to a crawl. DDoS attacks vary in sophistication. The most sophisticated use thousands of IPs accessing multiple URLs with random query strings to bypass caching and increase the CPU load.

DDoS Protection

Sophisticated attacks require time and effort from the hacker, so are usually used against high-value targets. Other than using a paid DDoS protection service, which I’m not going to do, I don’t know of a proactive way to prevent these. But my sites are low-value from a hacker prospective, so I am unlikely (I think) to be a target. If the unlikely were to happen I could react by ratcheting up my CloudFlare security level to “I’m under attack”.

What about less sophisticated attacks, which my sites are more likely to encounter? DDoS attacks against WP sites frequently target wp-login.php or xmlrpc.php. I can prevent these attacks on most of my sites, where I’m the only one who logs in and I don’t use xmlrpc. I can change the login URL, then block access to wp-login.php and xmlrpc.php using htaccess, a CloudFlare firewall rule, or the Protection Against DDoS plugin. I don’t really want to add another plugin, so …

Using htaccess:
# -
# Restrict access to wp-login.php
<Files wp-login.php>
order allow,deny
deny from all
# -
# Restrict access to xmlrpc.php
<Files xmlrpc.php>
order allow,deny
deny from all
# -

Using a CloudFlare firewall rule:
(http.request.uri.path contains "/wp-login.php") or
(http.request.uri.path contains "/xmlrpc.php")
then Block

Which method to use? A CloudFlare firewall rule is my preference. The processing load of dealing with swarms of malicious requests – even just to block them – could be high. A firewall rule moves all that processing off of my site/server and onto CloudFlare.

The WP search feature mysite.com/?s=searchterm is another common DDoS target. Each search uses more resources than a simple page request, and search results are unlikely to be cached. In this case I don’t want to block the requests. I want users to be able to search my site. Instead, I’ll use a CloudFlare firewall rule to serve a javascript challenge except when the search request is directly from my site.

The JS challenge is intended to block bots while causing only brief inconvenience to human visitors.
(http.request.full_uri contains "/?s="
and not
http.referer contains "wppov.com")
then JS Challange

According to the description of the Protection Against DDoS plugin, additional WP DDoS targets include autodiscover.xml, wpad.dat, and /feed/. I have not been able to find confirmation of these, and WP does not even use the first two. But what the heck, I’ll block them anyway, except for /feed/ on sites where I post frequently.

WPPOV supports freedom from Net Neutrality and the GDPR. The Internet of the people, by the people, for the people, shall not perish from the Earth.