Latest TweetsDifference between mod_alias and mod_rewrite perishablepress.com/difference…
Perishable Press

The Perishable Press 4G Blacklist

[ 4G Stormtrooper ] At last! After many months of collecting data, crafting directives, and testing results, I am thrilled to announce the release of the 4G Blacklist! The 4G Blacklist is a next-generation protective firewall that secures your site against a wide range of automated attacks and other malicious activity.

Update: Check out the new and improved 6G Blacklist/Firewall »

Like its 3G predecessor, the 4G Blacklist is designed for use on Apache servers and is easily implemented via HTAccess or the httpd.conf configuration file. In order to function properly, the 4G Blacklist requires two specific Apache modules, mod_rewrite and mod_alias. As with the third generation of the blacklist, the 4G Blacklist consists of multiple parts:

  • HTAccess Essentials
  • Request-Method Filtering
  • IP Address Blacklist
  • Query-String Blacklist
  • URL Blacklist

Each of these methods is designed to protect different aspects of your site. They may be used independently, mixed and matched, or combined to create the complete 4G Blacklist. This modularity provides flexibility for different implementations while facilitating the testing and updating process. The core of the 4G Blacklist consists of the last two methods, the Query-String and URL Blacklists. These two sections provide an enormous amount of protection against many potentially devastating attacks. Everything else is just icing on the cake. Speaking of which, there are also two more completely optional sections of the 4G Blacklist, namely:

These two sections have been removed from the 4G Blacklist and relegated to “optional” status because they are no longer necessary. Put simply, the 4G Blacklist provides better protection with fewer lines of code. Even so, each of these blacklists have been updated with hundreds of new directives and will be made available here at Perishable Press in the near future. But for now, let’s return to the business at hand..

Presenting the Perishable Press 4G Blacklist

As is custom here at Perishable Press, I present the complete code first, and then walk through the usage instructions and code explanations. So, without furhter ado, here is the much-anticipated 4G Blacklist [for personal use only – may not be posted elsewhere without proper link attribution]:

### PERISHABLE PRESS 4G BLACKLIST ###

# ESSENTIALS
RewriteEngine on
ServerSignature Off
Options All -Indexes
Options +FollowSymLinks

# FILTER REQUEST METHODS
<IfModule mod_rewrite.c>
 RewriteCond %{REQUEST_METHOD} ^(TRACE|DELETE|TRACK) [NC]
 RewriteRule ^(.*)$ - [F,L]
</IfModule>

# BLACKLIST CANDIDATES
<Limit GET POST PUT>
 Order Allow,Deny
 Allow from all
 Deny from 75.126.85.215   "# blacklist candidate 2008-01-02 = admin-ajax.php attack "
 Deny from 128.111.48.138  "# blacklist candidate 2008-02-10 = cryptic character strings "
 Deny from 87.248.163.54   "# blacklist candidate 2008-03-09 = block administrative attacks "
 Deny from 84.122.143.99   "# blacklist candidate 2008-04-27 = block clam store loser "
 Deny from 210.210.119.145 "# blacklist candidate 2008-05-31 = block _vpi.xml attacks "
 Deny from 66.74.199.125   "# blacklist candidate 2008-10-19 = block mindless spider running "
 Deny from 203.55.231.100  "# 1048 attacks in 60 minutes"
 Deny from 24.19.202.10    "# 1629 attacks in 90 minutes"
</Limit>

# QUERY STRING EXPLOITS
<IfModule mod_rewrite.c>
 RewriteCond %{QUERY_STRING} \.\.\/    [NC,OR]
 RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]
 RewriteCond %{QUERY_STRING} tag\=     [NC,OR]
 RewriteCond %{QUERY_STRING} ftp\:     [NC,OR]
 RewriteCond %{QUERY_STRING} http\:    [NC,OR]
 RewriteCond %{QUERY_STRING} https\:   [NC,OR]
 RewriteCond %{QUERY_STRING} mosConfig [NC,OR]
 RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|<|>|'|"|;|\?|\*).* [NC,OR]
 RewriteCond %{QUERY_STRING} ^.*(%22|%27|%3C|%3E|%5C|%7B|%7C).* [NC,OR]
 RewriteCond %{QUERY_STRING} ^.*(%0|%A|%B|%C|%D|%E|%F|127\.0).* [NC,OR]
 RewriteCond %{QUERY_STRING} ^.*(globals|encode|config|localhost|loopback).* [NC,OR]
 RewriteCond %{QUERY_STRING} ^.*(request|select|insert|union|declare|drop).* [NC]
 RewriteRule ^(.*)$ - [F,L]
</IfModule>

# CHARACTER STRINGS
<IfModule mod_alias.c>
 # BASIC CHARACTERS
 RedirectMatch 403 \,
 RedirectMatch 403 \:
 RedirectMatch 403 \;
 RedirectMatch 403 \=
 RedirectMatch 403 \@
 RedirectMatch 403 \[
 RedirectMatch 403 \]
 RedirectMatch 403 \^
 RedirectMatch 403 \`
 RedirectMatch 403 \{
 RedirectMatch 403 \}
 RedirectMatch 403 \~
 RedirectMatch 403 \"
 RedirectMatch 403 \$
 RedirectMatch 403 \<
 RedirectMatch 403 \>
 RedirectMatch 403 \|
 RedirectMatch 403 \.\.
 RedirectMatch 403 \/\/
 RedirectMatch 403 \%0
 RedirectMatch 403 \%A
 RedirectMatch 403 \%B
 RedirectMatch 403 \%C
 RedirectMatch 403 \%D
 RedirectMatch 403 \%E
 RedirectMatch 403 \%F
 RedirectMatch 403 \%22
 RedirectMatch 403 \%27
 RedirectMatch 403 \%28
 RedirectMatch 403 \%29
 RedirectMatch 403 \%3C
 RedirectMatch 403 \%3E
 RedirectMatch 403 \%3F
 RedirectMatch 403 \%5B
 RedirectMatch 403 \%5C
 RedirectMatch 403 \%5D
 RedirectMatch 403 \%7B
 RedirectMatch 403 \%7C
 RedirectMatch 403 \%7D
 # COMMON PATTERNS
 Redirectmatch 403 \_vpi
 RedirectMatch 403 \.inc
 Redirectmatch 403 xAou6
 Redirectmatch 403 db\_name
 Redirectmatch 403 select\(
 Redirectmatch 403 convert\(
 Redirectmatch 403 \/query\/
 RedirectMatch 403 ImpEvData
 Redirectmatch 403 \.XMLHTTP
 Redirectmatch 403 proxydeny
 RedirectMatch 403 function\.
 Redirectmatch 403 remoteFile
 Redirectmatch 403 servername
 Redirectmatch 403 \&rptmode\=
 Redirectmatch 403 sys\_cpanel
 RedirectMatch 403 db\_connect
 RedirectMatch 403 doeditconfig
 RedirectMatch 403 check\_proxy
 Redirectmatch 403 system\_user
 Redirectmatch 403 \/\(null\)\/
 Redirectmatch 403 clientrequest
 Redirectmatch 403 option\_value
 RedirectMatch 403 ref\.outcontrol
 # SPECIFIC EXPLOITS
 RedirectMatch 403 errors\.
 RedirectMatch 403 config\.
 RedirectMatch 403 include\.
 RedirectMatch 403 display\.
 RedirectMatch 403 register\.
 Redirectmatch 403 password\.
 RedirectMatch 403 maincore\.
 RedirectMatch 403 authorize\.
 Redirectmatch 403 macromates\.
 RedirectMatch 403 head\_auth\.
 RedirectMatch 403 submit\_links\.
 RedirectMatch 403 change\_action\.
 Redirectmatch 403 com\_facileforms\/
 RedirectMatch 403 admin\_db\_utilities\.
 RedirectMatch 403 admin\.webring\.docs\.
 Redirectmatch 403 Table\/Latest\/index\.
</IfModule>

That’s the juice right there. This 4G Blacklist is some powerful stuff, blocking and filtering a wide range of potential attacks and eliminating tons of malicious nonsense. Much care has been taken to beta test this firewall on multiple configurations running various types of software, however, due to my limited financial resources, it is impossible to test the 4G as comprehensively as I would have preferred. Even so, for the average site running typical software, everything should continue to work perfectly. With that in mind, please read through the remainder of the article before implementing the 4G Blacklist.

Installation and Usage

Before implementing the 4G Blacklist, ensure that you are equipped with the following system requirements:

  • Linux server running Apache
  • Enabled Apache module: mod_alias
  • Enabled Apache module: mod_rewrite
  • Ability to edit your site”s root htaccess file (or)
  • Ability to modify Apache’s server configuration file

With these requirements met, copy and paste the entire 4G Blacklist into either the root HTAccess file or the server configuration file ( httpd.conf ). After uploading, visit your site and check proper loading of as many different types of pages as possible. For example, if you are running a blogging platform (such as WordPress), test different page views (single, archive, category, home, etc.), log into and surf the admin pages (plugins, themes, options, posts, etc.), and also check peripheral elements such as individual images, available downloads, and alternate protocols (FTP, HTTPS, etc.).

While the 4G Blacklist is designed to target only the bad guys, the regular expressions used in the list may interfere with legitimate URL or file access. If the directives in the blacklist are blocking a specific URL, the browsing device will display a 403 Forbidden error; similarily, if the blacklist happens to block a file or resource required for some script to function properly, the script (JavaScript, PHP, etc.) may simply stop working. If you experience either of these scenarios after installing the blacklist, don’t panic! Simply check the blocked URL or file, locate the matching blacklist string, and disable the directive by placing a pound sign ( # ) at the beginning of the associated line. Once the correct line is commented out, the blocked URL should load normally. Also, if you do happen to experience any conflicts involving the 4G Blacklist, please leave a comment or contact me directly.

Set for Stun

As my readers know, I am serious about site security. Nothing gets my juices flowing like the thought of chopping up mindless cracker whores into small, square chunks and feeding their still-twitching flesh to a pack of starving mongrels. That’s good times, but unfortunately there are probably laws against stuff like that. So in the meantime, we take steps to secure our sites using the most effective tools at our disposal. There is no one single magic bullet that will keep the unscrupulous bastards from exploiting and damaging your site, but there are many cumulative steps that may be taken to form a solid security strategy. Within this cumulative context, the 4G Blacklist recognizes and immunizes against a broad array of common attack elements, thereby maximizing resources while providing solid defense against malicious attacks.

Many Thanks

A huge “Thank You” to the dedicated people who helped beta test the 4G Blacklist. Your excellent feedback played an instrumental role in the development of this version. Thank you!

Further Reading

For more insight into the mysterious realms of blacklisting, the creation of the Perishable Press Blacklist, and DIY site security in general, check out some of my other articles:

Next Up

Next up in the March 2009 Blacklist Series: The Ultimate User-Agent Blacklist. Don’t miss it!

Updates

Since the release of the 4G Blacklist, several users have discovered issues with the following 4G directives.

Joomla

In the query-string section, Joomla users should delete the following patterns:

request
config
[
]

In the character-string section, Joomla users should comment-out or delete the following lines:

RedirectMatch 403 \,
RedirectMatch 403 \;
RedirectMatch 403 config\.
RedirectMatch 403 register\.

WordPress

In the query-string section of the 4G Blacklist, the following changes have been made:

"%3D" character-string has been changed to "%5C"

Likewise, in the character-string section, the following change has been made:

"wp\_" character-string has been removed

And in the request-method filtering section, the following change has been made:

"HEAD" method has been removed

Also, the following changes may be necessary according to which plugins you have installed:

Ozh' Admin Drop Down Menu - remove "drop" from the query-string rules
WordPress' Akismet - remove "config" from the query-string rules

OpenID

OpenID users should read the information in this comment.

SMF

SMF users should read the information in this comment.

vBulletin

vBulletin users should read the information in these comments.

Jeff Starr
About the Author Jeff Starr = Web Developer. Book Author. Secretly Important.
Archives
233 responses
  1. Checked my logs today and observed that the .htaccess ban was ineffectual. About two dozen requests, some with completely different user-agents, had their IP resolve to “.” or “localhost”. I found an explanation as to how this can occur. See http://www.webmasterworld.com/forum10/8430.htm if interested.

  2. Ken Dawes June 23, 2010 @ 1:33 pm

    Hi,
    Just an FYI…

    I have been setting up a new WordPress installation for a client (hosted by Network Solutions if that has any relevance).

    The “old” site has html pages in the root and an old WordPress in a folder… I am installing a new WordPress into a new folder.

    I have placed 4g into a .htaccess in the root with the following result… Root html files-unaffected, but both WP installations immediately go to a 403 error page.

    I fiddled with the 4g and the problem resolves by commenting out the line
    #RedirectMatch 403 ~

    I’m happy that this “fixes” the problem, but I’d love it if someone could explain the “why”.

    Any clues?

    Ken

  3. @Ken Dawes — #194

    immediately go to a 403 error page.

    I fiddled with the 4g and the problem resolves by commenting out the line
    #RedirectMatch 403 \~

    I’m happy that this “fixes” the problem, but I’d love it if someone could explain the “why”.

    Ken same problem I just noticed your fix and I did this a while ago and was finally allowed to log in.

    Hopefully this #RedirectMatch 403 \~ isn’t a critical part of security. LOL .. oh man.

  4. Jeff Starr

    Commenting out the line:

    RedirectMatch 403 \~

    stops Apache from matching requests that include that particular character ( ~ ) in the request string. This match was included in the 4G because the ~ character is frequently seen with malicious attacks. Removing it is fine because most bad queries also include other characters that are blocked by other directives in the blacklist.

    As for the WordPress issue, there could be other factors involved. I am running numerous versions of WordPress all protected by the same 4G Blacklist. I will look into it the next time I’m there. Maybe other factors in my setup that prevent the conflict.

    Bottom line: removing any small number of directives from the 4G is perfectly fine. There may be a few bad requests, but overall the blacklist is providing strong protection for your site(s).

  5. Just to let you know I’ve found the following lines cause breakages in certain components – so if you use them, comment/remove the relevant parts…

    – Image thumbail generation when given a complete image URL (ie including http://) in the ?src= query string of your thumbnail generator
    …solution: comment out “RewriteCond %{QUERY_STRING} http\: [NC,OR]
    (in fact this would apply to any code that takes a complete URL as source…though obviously any code of that type would have to be very carefully designed to stop issues, so blocking http:// might not be a bad idea for most people)

    – JQuery module jquery-ui-droppable – if referenced as part of the query string – eg: in WordPress admin area, this reference call is made by the WooThemes framework custom navigation options page:
    <script type="text/javascript" src="/wp-admin/load-scripts.php?c=0&load=hoverIntent,common,jquery-color,jquery-ui-sortable,jquery-ui-droppable&ver=">
    …however I’m sure there are lots of other sites/cmses/plugins that use the JQuery drag and drop framework, not just WooThemes. Wp 3.0 might even use it for the new in-built menus, would have to check.
    …solution: remove “|drop” from this line
    RewriteCond %{QUERY_STRING} ^.*(request|select|insert|union|declare|drop).* [NC]
    …or else change “|drop” to “|drop%20” to at least catch anything with a space after the word drop, but not words like “droppable”

    Hope that helps someone! :-)

  6. Coppermine users (depending on the version) may need to remove INSERT from the query-string section. It may block bulk image additions after FTP upload.

    RewriteCond %{QUERY_STRING} (request|select|union|insert|declare|drop) [NC]

    I have been using this for a few months now and I must say it has significantly reduced traffic from malicious bots. If you do get a ‘permission denied’ error, just check the query string to see if the application is using a word that is blocked in the blacklist.

  7. Found another issue with WordPress 3.0.

    The following line:

    RewriteCond %{QUERY_STRING} ^.*(request|select|insert|union|declare|drop).* [NC]

    breaks the image editing feature in the media section:

    To fix, remove “select|” or else change it to “select%20|” to at least leave some of the protection.

  8. The comments filter removed part of the last post.

    The line that gets broken is:

    <script type="text/javascript" src="[removed]/wp-admin/load-scripts.php?c=0&load=hoverIntent,common,jquery-color,jquery-ui-core,jquery-ui-sortable,wp-ajax-response,imgareaselect,image-edit&ver=[removed]"</script>

  9. Garrett W. July 14, 2010 @ 12:35 pm

    Steve: At least part of your problem might be resolved by removing or modifying the bit that blocks the word “drop” in the query string. See comment #110 or the end of comment #197.

  10. Seems to be something in the 4G that is preventing my Widgets panel from functioning properly. This is stuff such as can not drag and drop or open any drop down menus.

    Any tips?

  11. Garret thanks. I’ll check it out. Also though, I enabled accessibility mode (widgets) and that works fine with 4G.

  12. Garrett . .

    Sorry, 2 T’s LOL

[ Comments are closed for this post ]