Using .htaccess to prevent a DDOS attack not working with Permalinks

Question

We have become the victim of a vicious DDOS attack on a WordPress site.

Thankfully, they should be easily removed as they are GET requests with the string ?ptrxcz appended to the end of the URL.

With this in mind we have set up rules to give 403 permission error pages to requests that fulfill this using .htacess. The trouble is these don't appear to work with permalinks installed also.

Here is my full .htaccess file as it is.

RewriteEngine On
RewriteCond %{QUERY_STRING} .*ptrxcz.*
RewriteRule (.*) - [F]

# BEGIN WordPress

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

The beginning part is redirecting users with ptrxcz to the 403 page. This works perfectly if I remove the WordPress rules underneath it, but with them included it just never works.

Frustratingly using a negative regex with the QUERY_STRING search works in reverse correctly (blocking everything except request with the query string, as so:

RewriteCond %{QUERY_STRING} !.*ptrxcz.*

(Note the added !)

Does anyone have any idea:

1. Why it doesnt work with permalinks
2. How I can make it work with permalinks
3. Why a negative regex on the query string works but not a positive one.

Answer 1

If you replace QUERY_STRING in the code above with THE_REQUEST then this works fine and does exactly as required within WordPress.

Answer 2

I had the same problem, but it was severe enough that I brought up a small web server to act as a front end and filter out these requests. The relevant iptables rule is:

iptables -A INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'ptrxcz_' -j DROP

It instructs the system to examine up to the first 70 characters of the request and if it finds 'ptrxcz_ ', to silently drop the request. I tried returning an error message, but the bandwidth consumed by the error code was not worth it considering there would never be a user on the other end of the connection to read the error.

I created a blog post describing the steps I took:

http://web.htcomp.net/?pageid=85&blogid=2

Larry