Block revslider Scans

One of the most annoying, persistent scans I’ve seen in a long time are those hunting for the revslider vulnerability. In the five or so months since the exploit was discovered, many sites have been compromised. And based on what I’ve been seeing in my traffic logs, the risk is far from over. Apparently every 2-bit script kiddie and their pet hamster wants a piece of the “revslider action”.

Hour after hour, week after week, month after month, hundreds and thousands of malicious URI requests such as:

These examples show revslider in the query string, but they also are seeking for it in the main URI request. For example:

I’m seeing thousands of these requests and I’ve never even touched any “revslider” plugin — nothing of the sort exists anywhere on any of my sites. But the idiots just won’t stop. Nor are they clever enough to log server responses to avoid repetition and save resources (like CPU, RAM, bandwidth, and of course time). So they mindlessly keep hammering away at the same targets over and over and over..

How to block ’em

Here is what I added to my site’s root .htaccess file in to block the endless revslider scans:

<IfModule mod_rewrite.c>
	RewriteCond %{QUERY_STRING} revslider [NC,OR]
	RewriteCond %{REQUEST_URI} revslider [NC]
	RewriteRule .* - [F,L]

Done. Test thoroughly. Note that this code will block all requests for any revslider-related resources, so probably don’t use if you are running the revslider plugin.

What’s the code doing? Well, if you re-examine the example URLs above, you’ll notice a common pattern:




In order for dirtbags to successfully “hit” the revslider vulnerability, the “revslider” string must be included in the requested URI or the query string. That’s good news because it makes blocking all such requests quite trivial. As seen in the previous .htaccess snippet, we can match all revslider requests with two lines:

RewriteCond %{QUERY_STRING} revslider [NC,OR]
RewriteCond %{REQUEST_URI} revslider [NC]

The first directive targets revslider in the query string, while the second directive targets it in the requested URI. With Apache (.htaccess), matching against the query string is achieved via the QUERY_STRING variable. So basically the first directive tells the server:

If the request includes “revslider” anywhere in the query string, then block it with a 403 response.

Likewise for the second directive, where we use the REQUEST_URI variable to match against the requested URI. There we tell Apache:

If the request includes “revslider” anywhere in the URI, then block it with a 403 response.

These two directives are associated via the [OR] flag, which tells Apache that either match is sufficient to execute the RewriteRule. The [NC] flag is for case-insensitivity, because we don’t care if revslider requests contain capital letters or not.

Note that in this blocking technique, we are simply denying the request with a server status 403 – Forbidden, which suits the needs of most. But you can get creative with the response, here are some fun ideas.

Take home

Take home message here is that there are super scummy people out there, who couldn’t care less about you or anyone else. They will relentlessly chew up your bandwidth and resources in depraved, mindless fashion. Fortunately, in this case it is trivial to utterly stop the fools cold with a fresh slice of .htaccess.

Check out more .htaccess techniques »


Here is a new and improved slab of .htaccess that blocks a LOT of pesky requests:

<IfModule mod_rewrite.c>
	RewriteCond %{REQUEST_URI}  (mssqlil|register).php [NC,OR]
	RewriteCond %{REQUEST_URI}  (img|thumb|thumb_editor|thumbopen).php [NC,OR]
	RewriteCond %{QUERY_STRING} (img|thumb|thumb_editor|thumbopen).php [NC,OR]
	RewriteCond %{REQUEST_URI}  revslider [NC,OR]
	RewriteCond %{QUERY_STRING} revslider [NC]
	RewriteRule .* - [F,L]

This will block some of the most common malicious scans, saving much bandwidth and resources. Just drop it into your root .htaccess and relax.