5G Blacklist 2013
Following up on much feedback (and this post), here is an update for the 5G Blacklist for 2013. As explained in the 2012 article (and elsewhere), the 5G Blacklist helps reduce the number of malicious URL requests that hit your website. It’s one of many ways to improve the security of your site and protect against evil exploits, bad requests, and other nefarious garbage. If your site runs on Apache and you’re familiar with .htaccess, the 5G is an effective way to secure your site against malicious HTTP requests and other suspect activity.
About the 5G Blacklist
The 5G Blacklist is a simple, flexible blacklist that checks all URI requests against a series of carefully constructed HTAccess directives. This happens quietly behind the scenes at the server level, saving resources for stuff like PHP and MySQL for all blocked requests.
How it works
Blacklists can block just about any part of a request: IP, user agent, request string, query string, referrer, and everything in between. But IP addresses change constantly, and user agents and referrers are easily spoofed. As discussed, request strings yield the best results: greater protection with fewer false positives.
The 5G works beautifully with WordPress, and should help any site conserve bandwidth and server resources while protecting against malicious activity.
5G Blacklist 2013
Here is the third version of the 5th generation blacklist:
# 5G BLACKLIST/FIREWALL (2013)
# @ https://perishablepress.com/5g-blacklist-2013/
# 5G:[QUERY STRINGS]
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{QUERY_STRING} (\"|%22).*(<|>|%3) [NC,OR]
RewriteCond %{QUERY_STRING} (javascript:).*(\;) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3) [NC,OR]
RewriteCond %{QUERY_STRING} (\\|\.\./|`|=\'$|=%27$) [NC,OR]
RewriteCond %{QUERY_STRING} (\;|\'|\"|%22).*(union|select|insert|drop|update|md5|benchmark|or|and|if) [NC,OR]
RewriteCond %{QUERY_STRING} (base64_encode|localhost|mosconfig) [NC,OR]
RewriteCond %{QUERY_STRING} (boot\.ini|echo.*kae|etc/passwd) [NC,OR]
RewriteCond %{QUERY_STRING} (GLOBALS|REQUEST)(=|\[|%) [NC]
RewriteRule .* - [F]
</IfModule>
# 5G:[USER AGENTS]
<IfModule mod_setenvif.c>
# SetEnvIfNoCase User-Agent ^$ keep_out
SetEnvIfNoCase User-Agent (binlar|casper|cmsworldmap|comodo|diavol|dotbot|feedfinder|flicky|ia_archiver|kmccrew|nutch|planetwork|purebot|pycurl|skygrid|sucker|turnit|vikspider|zmeu) keep_out
<limit GET POST PUT>
Order Allow,Deny
Allow from all
Deny from env=keep_out
</limit>
</IfModule>
# 5G:[REQUEST STRINGS]
<IfModule mod_alias.c>
RedirectMatch 403 (https?|ftp|php)\://
RedirectMatch 403 /(https?|ima|ucp)/
RedirectMatch 403 /(Permanent|Better)$
RedirectMatch 403 (\=\\\'|\=\\%27|/\\\'/?|\)\.css\()$
RedirectMatch 403 (\,|\)\+|/\,/|\{0\}|\(/\(|\.\.\.|\+\+\+|\||\\\"\\\")
RedirectMatch 403 \.(cgi|asp|aspx|cfg|dll|exe|jsp|mdb|sql|ini|rar)$
RedirectMatch 403 /(contac|fpw|install|pingserver|register)\.php$
RedirectMatch 403 (base64|crossdomain|localhost|wwwroot|e107\_)
RedirectMatch 403 (eval\(|\_vti\_|\(null\)|echo.*kae|config\.xml)
RedirectMatch 403 \.well\-known/host\-meta
RedirectMatch 403 /function\.array\-rand
RedirectMatch 403 \)\;\$\(this\)\.html\(
RedirectMatch 403 proc/self/environ
RedirectMatch 403 msnbot\.htm\)\.\_
RedirectMatch 403 /ref\.outcontrol
RedirectMatch 403 com\_cropimage
RedirectMatch 403 indonesia\.htm
RedirectMatch 403 \{\$itemURL\}
RedirectMatch 403 function\(\)
RedirectMatch 403 labels\.rdf
RedirectMatch 403 /playing.php
RedirectMatch 403 muieblackcat
</IfModule>
# 5G:[REQUEST METHOD]
<ifModule mod_rewrite.c>
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
</IfModule>
# 5G:[BAD IPS]
<limit GET POST PUT>
Order Allow,Deny
Allow from all
# uncomment/edit/repeat next line to block IPs
# Deny from 123.456.789
</limit>
To use: include the entire 5G Blacklist in the root .htaccess file of your site. Remember to backup your original .htaccess file before making any changes. Test thoroughly while enjoying your favorite beverage. If you encounter any issues, please read the troubleshooting tips and/or leave a comment to report a bug.
Note: in some cases it may be necessary to place the QUERY STRING rules before WP-permalink rules.
Update (2015/04/03): removed jakarta
from the user-agent portion of the list. Reason? LinkedIn actually includes the term “jakarta” in their user-agent string:
LinkedInBot/1.0 (compatible; Mozilla/5.0; Jakarta Commons-HttpClient/3.1 +http://www.linkedin.com)
</update>
Pre-changelog notes
The changes made for 5G 2013 are aimed at maximizing compatibility. Unfortunately, a number of required changes are due to improper coding and ignoring HTTP specifications. As mentioned previously, using unsafe characters in URLs obsoletes security measures that are based on pattern-matching, which is integral to the process of blocking malicious activity.
To illustrate, it is possible to protect against a wide range of malicious requests by blocking unsafe characters such as unencoded question marks “?
” included within the query string. Firewalls, blacklists, security plugins and scripts are able to safely block such bad requests UNTIL some widely used service such as Google Adwords decides to start including multiple unencoded question marks in their query strings. Suddenly blocking potentially dangerous “?
” requests is useless because nobody wants to block legitimate (Google) traffic.
Moral of the story: if you develop for the Web, contribute to its security by encoding your URLs according to spec. If you use security plugins, firewalls/blackists, and scripts that rely on pattern-matching to protect your site, please encourage and educate others about the importance of adhering to HTTP specifications.</rant>
Changelog
Removed from QUERY STRINGS
- Square brackets “
[
” and “]
” (details) - Colon “
:
” (details) - Unencoded question mark “
\?
” (WP previews, Piwik, Adwords, et al) - Removed “
(menu|mod|path|tag)\=\.?/?
” (WP menus, WP Super Cache, Joomla, Googlebot, et al) - Removed “
environ
” (common string) - Removed “
scanner
” (various WP plugins) - Removed “
%3E
” (common string) - Escaped backslash, from “
\
” to “\\
”
Removed from USER AGENTS
- Commented out match for blank/empty user-agent “
^$
” (PayPal, WP-Piwik, et al) - Removed match for “
libwww
” (used by Lynx browser)
Removed from REQUEST STRINGS
- Double forward slash “
//
” (Pingdom, gtmetrix, et al) - Removed match for “
/cgi/
” (Fancy indexes, Authentication)
Added to QUERY STRINGS (5G 2013)
- “
TRACE
” and “TRACK
” - “
base64_encode.*\(
” - “
\|%3E
” - “
GLOBALS(=|\[|\%)
” - “
REQUEST(=|\[|\%)
” - “
`
” - “
(\"|%22).*(<|>|%3)
” - “
(<|%3C).*script.*(>|%3)
” - “
(javascript:).*(\;)
” - “
(\;|\'|\"|%22).*(union|select|insert|drop|update|md5|benchmark|or|and|if)
”
Other changes
Optimized syntax, improved formatting.
Troubleshooting
If there is an error, remove the code and make a backup of your original .htaccess file (if you haven’t already done so). Investigate the URL for whichever page is blocked or not working, making note of any non-alphanumeric characters or anything else that looks unusual. With a good idea of what to look for, examine the 5G directives to see if anything looks similar. If so, try removing (or commenting out) the offending line (or characters) and see if that resolves the issue.
If that doesn’t work, further investigation is required, and there are numerous ways of going about it. Here is a good walkthrough of my halving method of isolating problematic code, which I recommend unless you have your own favorite way of troubleshooting ;)
Show support
If you benefit from my work with the 5G and would like to show support, consider buying a copy of my book, .htaccess made easy. You’ll get a complete guide to .htaccess, exclusive forum access, and a ton of awesome techniques for configuring, optimizing, and securing your site. Your generous support allows me to continue developing 5G/6G and other awesome resources for the community. Thank you!
Disclaimer
The 5G Firewall is provided “as-is”, with the intention of helping site administrators protect their sites against bad requests and other malicious activity. The code is open and free to use and modify as long as the first two credit lines remain intact. By using this code you assume all risk & responsibility for anything that happens, whether good or bad. In short, use wisely, test thoroughly, don’t sue me.
Learn more..
To learn more about the theory and development of the 5G Firewall, check out my articles on building the 3G, 4G and 5G Blacklist. The 6G beta article also contains some good information. And if all that’s not enough, a quick search for “blacklist” in the sidebar should also yield many results.
91 responses to “5G Blacklist 2013”
Does this 5G replace the below (which I got from a post of yours)?
RedirectMatch 403 /$& RedirectMatch 403 (?i)/.(bash|git|hg|log|svn|swp|tar) RedirectMatch 403 (?i)/(1|contact|i|index1|iprober|phpinfo|phpspy|product|signup|t|test|timthumb|tz|visit|webshell|wp-signup).php RedirectMatch 403 (?i)/(author-panel|class|database|manage|phpMyAdmin|register|submit-articles|system|usage|webmaster)/?$ RedirectMatch 403 (?i)/(=|_mm|cgi|cvs|dbscripts|jsp|rnd|userfiles)
(If I’ve asked this question before, I apologize but I can’t remember the answer.)
The 5G should be all you need, but I see some things in there that aren’t specifically covered. It’s totally safe to use both, despite some overlapping rules.
The order should be 5G then the above bit correct?
Yes that should work fine. Remember that any of the rules may be tested by appending the blocked string to any of the URLs on your site. Blocked strings return a 403 “Forbidden” response.
Jeff, The 5G list works great and I’m using it on all my sites. One question: I don’t know enough about mod_rewrite and what you’re doing to be able to tell if 5G blocks no referrer requests to wp-login.php – does it? This is in light of the current brute force attacks against WP logins. Re: http://codex.wordpress.org/Brute_Force_Attacks#Deny_Access_to_No_Referrer_Requests
Great little firewall. Cheers.
I couldn’t pinpoint which of those 5 lines is causing WordPress image editor not to work.
RewriteCond %{QUERY_STRING} ("|%22).*(<|>|%3) [NC,OR]
RewriteCond %{QUERY_STRING} (javascript:).*(;) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3) [NC,OR]
RewriteCond %{QUERY_STRING} (\|../|`|='$|=%27$) [NC,OR]
RewriteCond %{QUERY_STRING} (;|'|"|%22).*(union|select|insert|drop|update|md5|benchmark|or|and|if) [NC,OR]
They produce a 403 in the URL:
/wp-admin/admin-ajax.php?action=imgedit-preview&_ajax_non…ostid=4353&history=%5B%7B%22f%22%3A2%7D%2C%7B%22f%22%3A1%7D%5D&rand=964272
This line:
RewriteCond %{QUERY_STRING} ("|%22).*(|%3) [NC,OR]
..breaks the facebook “like” stories if the a user clicks through from the “activity” list. Facebook appends some URL arguments which then are “forbidden” by the Query String section of your blocklist. This very probably needs a fix:
http://mydomain.com/?fb_action_ids=10151583105966609&fb_action_types=og.likes&fb_source=timeline_og&action_object_map=%7B%2210151583105966609%22%3A10150220203269128%7D&action_type_map=%7B%2210151583105966609%22%3A%22og.likes%22%7D&action_ref_map=%5B%5D
Thanks Matt! Until the next update you can comment-out or remove that line if you need the FB stuff. Thanks for reporting the issue.
Thanks mate, you’re a legend.
I have seen the below string come through a few times even though I am using the 5G 2013 list and Bulletproof Security rules. I am not sure if something is just not working in my .htaccess or if this link just bypasses the rules somehow. The below returns a 404 error, but looks like I should be able to block it somehow.
http://www.mydomain.com/phppath/php?-d+allow_url_include%3d1+-d+safe_mode%3d0+-d+suhosin.simulation%3d1+-d+disable_functions%3d'
My bad. I am on a new host without a default 403 page. When I added one all is good with this error.
awesome Thanks Jeff
Hey Jeff, I’ve wanted to edit and utilise my htaccess for a long time, so I’m stoked at what you’ve got here. I’m really hoping I can integrate this in soon, as I’ve already had some header injections that I’d like to avoid again. I’m just wondering if you’ve done any testing against a WooCommerce theme or main plugin, or other eCommerce packages. I’d obviously like to avoid any conflicts that the packages have dependancies on if 5G ties down too hard on them
Glad to hear Dan, and yes the 5G is tested against as many plugins as possible, but needs to be specifically tested for each unique setup, especially if e-commerce/shopping cart related. Especially important to keep an eye on are the query-string rules, which are typically integral to the functionality of e-commerce transactions.