Save 25% on our pro plugins with coupon code: SPRING2023
Web Dev + WordPress + Security

Evil Incarnate, but Easily Blocked

As my readers know, I spend a lot of time digging through error logs, preventing attacks, and reporting results. Occasionally, some moron will pull a stunt that deserves exposure, public humiliation, and banishment. There is certainly no lack of this type of nonsense, as many of you are well-aware.

3G Blacklist

Even so, I have to admit that I am very happy with my latest strategy against crackers, spammers, and other scumbags, namely, the 3G Blacklist. Since implementing this effective HTAccess security method, I have seen a dramatic decrease in the overall volume of malicious activity recorded in my Apache, PHP, and 404 error logs. Thankfully, the 3G Blacklist has kept things pretty quiet around here, at least as far as malicious activity is concerned. In fact, it has been awhile since I’ve seen anything worthy of sharing with you — until now.

Evil Incarnate

The depths to which spammers and crackers sink never ceases to amaze me. From cryptic character strings and cloaked IP information to SQL injection and denial-of-service attacks, I’ve seen my share of sinister business hitting the server. Not much surprises me these days, but seeing a few log entries like this certainly caught my attention:

TIME: September 2nd 2008, 10:00am

404: *


SOURCE: Perishable/Perishable


QUERY STRING: l=/../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ


USER AGENT: <? $x0e=\\\"\\\\145x\\\\x65\\\\x63\\\"; $x0f=\\\"\\\\x66eo\\\\146\\\"; 
$x12=\\\"i\\\\163\\\\x5f\\\\162\\\\x65s\\\\157ur\\\\x63\\\\x65\\\"; $x13=\\\"\\\\152\\\\157\\\\x69\\\\156\\\"; 
$x15=\\\"ob\\\\137\\\\x65\\\\156d\\\\137\\\\x63lea\\\\156\\\"; $x16=\\\"\\\\x6fb_st\\\\x61\\\\x72\\\\164\\\"; 
$x17=\\\"\\\\x70\\\\141\\\\163s\\\\164\\\\x68\\\\162\\\\165\\\"; $x18=\\\"\\\\x70\\\\143\\\\154ose\\\"; 
$x19=\\\"p\\\\157\\\\160e\\\\x6e\\\"; $x1a=\\\"\\\\163h\\\\145\\\\154l\\\\137\\\\x65\\\\170e\\\\143\\\"; 
function x0b($x0b){ global $x0e,$x0f,$x10,$x11,$x12,$x13,$x14,$x15,$x16,$x17,$x18,$x19,$x1a,$x1b;  
$x0c = \\\'\\\'; if (!empty($x0b)) {if($x11(\\\'exec\\\')) {@$x0e($x0b,$x0c);$x0c = $x13(\\\"\\\\n\\\",$x0c); 
}elseif($x11(\\\'shell_exec\\\')) {$x0c = @$x1a($x0b); }elseif($x11(\\\'system\\\')) {@$x16();@$x1b($x0b);$x0c = 
@$x14();@$x15(); }elseif($x11(\\\'passthru\\\')) {@$x16();@$x17($x0b);$x0c = @$x14();@$x15(); }elseif(@$x12($x0d = 
@$x19($x0b,\\\"\\\\x72\\\"))){ $x0c = \\\"\\\"; while(!@$x0f($x0d)) { $x0c .= @$x10($x0d,1024); } @$x18($x0d);} } 
return $x0c;}echo x0b(\\\"ec\\\\150\\\\157\\\\x20c\\\\1624n\\\\153\\\\137\\\\x72oc\\\\153s\\\");?>


DUDE!! — WTF is up with that!?!?! Did you check out the user-agent on that thing!? And what about that query string? How far up the directory structure did you want to go? I mean, seriously.. that is some evil business right there. Somebody clearly put a lot of effort into that one, obviously intending to do some major damage to something deep within the server. What kind of depraved, evil bastard is writing this stuff?

Even worse, what kind of scumbag loser is going around probing random servers with this demented nonsense? I don’t know, and don’t even know if I want to know. Messing with other people’s property like that — you should be hung out and shot dead, twice in the face.

Child’s Play

Fortunately, stopping this ebil nonsense is easier than flushing a toilet. First, let’s block that nasty query-string by adding the following line to the Query String section of the 3G Blacklist1:

 RewriteCond %{QUERY_STRING} \.\.\/ [NC,OR]

Next, let’s seal the deal by blocking any user agents containing scripted information. Do this by adding the following lines to the User Agent section of the 3G Blacklist:

SetEnvIfNoCase User-Agent "shell_exec"  keep_out
SetEnvIfNoCase User-Agent "passthru"    keep_out
SetEnvIfNoCase User-Agent "function"    keep_out

Or, if you would like to use this protective method by itself (i.e., independent of the 3G Blacklist), simply drop this code into your site’s web-accessible HTAccess file to enjoy complete protection against such attacks:

# block evil incarnate query strings
<ifmodule mod_rewrite.c>
 RewriteCond %{QUERY_STRING} \.\.\/    [NC,OR]
 RewriteRule .* -                      [F,L]
# block evil incarnate user agents
SetEnvIfNoCase User-Agent "shell_exec"  keep_out
SetEnvIfNoCase User-Agent "passthru"    keep_out
SetEnvIfNoCase User-Agent "function"    keep_out
<Limit GET POST>
 order allow,deny
 allow from all
 deny from env=keep_out

The first part of this code is basically telling Apache to kick to the curb any requests for URLs with query strings containing the “../” character string. There is no reason this string should ever appear in legitimate URLs.

Then, the second part of this code simply blocks any user agents containing the terms “shell_exec”, “passthru”, or “function”. Again, there is no reason for these strings to appear in legitimate user-agent strings.

There are actually many different ways to block this type of aggressive attack, but I think targeting the URL/query-string attack vector while blocking scripts in the user-agent string will prove the most effective. Think of it as breaking both legs and one arm of the attacker (i.e., the query string may be changed, but there is no way around the blocked scripts). Of course, I will be keeping a close eye on this type of attempted exploit, and will certainly post afresh with any further information, suggested updates, edits, additions, etc.


1 This protection will also be included in the upcoming 4G Blacklist.

Jeff Starr
About the Author
Jeff Starr = Fullstack Developer. Book Author. Teacher. Human Being.
.htaccess made easy: Improve site performance and security.

6 responses to “Evil Incarnate, but Easily Blocked”

  1. Avatar photo
    Rick Beckman 2008/09/15 9:53 am

    Wouldn’t blocking “../” prevent things like style sheets from referencing images relatively in different directories?

    For instance, if a theme is set up like this:


    If the style sheet in /custom/ needs to refer to one of the Theme’s image, it must use “../images/” to get there. Wouldn’t that be blocked?

  2. Avatar photo

    No sir, we are blocking query strings and user agents here. Stylesheets and other external resources are not affected.

  3. Avatar photo
    Rick Beckman 2008/09/15 10:12 am

    Oh, I see what you did there. :)

  4. I’m glad you’ve figured that out! Malicious spam can be such a pain to deal with!

  5. Avatar photo
    F. Andy Seidl 2008/09/20 6:53 pm

    As a webmaster, you definitely should use user-agent headers to manager server traffic. But understand that this is purely a pragmatic tactic and not a serious security measure.

    I wrote more about this here:

    Webmaster Tips: Blocking Selected User-Agents (404 link removed 2017/01/21)

  6. Avatar photo
    Jeff Starr 2008/09/21 9:04 am

    Trust me, when your site is hosted on a shared server, this is as serious as it gets.. ;)

Comments are closed for this post. Something to add? Let me know.
Perishable Press is operated by Jeff Starr, a professional web developer and book author with two decades of experience. Here you will find posts about web development, WordPress, security, and more »
SAC Pro: Unlimited chats.
There is no end to what humans can achieve when they work together.
Excellent (and free) tool to test your site's SSL configuration.
Plugin updates! All of our free and pro plugins ready for WordPress 6.2.
Daylight savings is a complete waste of time and needs to be eliminated.
Got a couple of snow days here in mid-March. Fortunately it's not sticking.
I handle all email in real time as it comes in, perpetually clear inbox for years now.
Added some nice features to Wutsearch search engine launchpad. Now 21 engines!
Get news, updates, deals & tips via email.
Email kept private. Easy unsubscribe anytime.