WordPress Add-on for 5G Blacklist
Ill requests and malicious scans have been spiking recently, to the point where server performance was really taking a hit. One scan in particular hammered the server with thousands of bad requests in just a few minutes. There are people out there with strong scripts and small minds that are constantly scanning sites for vulnerabilities, and much of what I’ve seen is aimed primarily at WordPress.
That sort of mindless phishing and scanning for crumbs and holes is just silly. So I whipped up this WordPress add-on for the 5G Blacklist, for those who are using it. For those who aren’t but are using WordPress, this add-on works perfectly well on its own — i.e., you don’t need the 5G to use it.
5G WordPress Add-on
5G WP add-on is designed to help protect your site against a broad spectrum of bad URL requests, focusing on the latest wave of malicious server scans. Simply copy/paste the following code into your site’s root .htaccess file (beneath the 5G, if present):
# 5G:[WordPress]
<ifModule mod_rewrite.c>
RedirectMatch 403 /\$\&
RedirectMatch 403 (?i)/\&(t|title)=
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|shadow|userfiles)
</ifModule>No editing is required up front, but you may need to fine-tune depending on which plugins, themes you may be using. For example, if the XYZ widget suddenly stops working, remove the 5G add-on from your .htaccess file and either 1) walk away, 2) test further and remove the offending character string. If all else fails, leave a comment and someone will try to help.
I can only do so much testing, so if you notice anything weird or if something breaks, leave a comment or send an email — your feedback will help make the 5G add-on even better.
How it works, what it does
Once the code is in place, all URL requests are checked against each of the character strings. For example, let’s say some scumbag attacks your site (as they did with mine recently) with a barrage of random strings:
http://example.com/tag/icons/rndWRr8VfM0B
http://example.com/tag/icons/rndqyG87KROd
http://example.com/tag/icons/rnd2JSAL4n8a
http://example.com/tag/icons/rndA52wTv0ma
http://example.com/tag/icons/rndUDESMbgRC
http://example.com/tag/icons/rndy24JOTQrN
http://example.com/tag/icons/rndCHSkcgPNP
http://example.com/tag/icons/rndXd9XF8il5
http://example.com/tag/icons/rndUFvb60VNk
http://example.com/tag/icons/rndBCvCRsKnB
.
.
.The 5G directives check the URLs and match them against the “/rnd” character string, and then silently blocks the entire swarm from accessing your site. And that’s just one of many bad requests that are blocked, here’s a list showing some of the other requests blocked by the 5G add-on.
For whatever reason, those phrases, files, and directories are among the most heavily scanned-for resources in recent months. The 5G WP add-on aims to neutralize this new wave of attacks by working with the 5G Blacklist, but is also effective as stand-alone protection for your WordPress-powered site.
33 responses to “WordPress Add-on for 5G Blacklist”
Just wanna say thanks. From block bad queries to the to the 5g.
That’s all :)
Thank you very much for this. I have installed in all of my blogs and works perfect! :)
Hi Jeff,
Will this make it in to 6G in it’s entirety or will it continue to live as an add on?
I assume for WordPress sites we should be using both 5G and this add on…
Thanks,
Anders
Correct, the addon should be used with the 5G. For the 6G (beta), most of the coverage is already included, so not necessary at this point. If it makes sense in the future, a 6G-addon may be a good idea. It depends on how quickly things change on both sides of the fence.
Thanks for this tip. I am here looking to strengthen the security of my site. :D
More power
Found |timtumb| causing thumbnail images on my WP website to disappear. I deleted this string, and everything worked out fine. Thanks.
Since I’ve updated my sites to WordPress 3.5, the sites will sometimes load very slowly. I went to the WordPress Support Forums and found this trac ticket on script loading which says it’s an issue with .htaccess and this notice about your 5G blacklist. I use the add-on above and your ultimate hotlink protection. What, if anything, needs to change?
The only issue with 5G is with WP 3.5’s improperly encoded URLs. They should not be using unencoded square brackets in any URLs; it’s a security vulnerability at worst and just bad practice at best. In any case, the 5G is nothing to do with 3.5 performance issues, it simply blocks the invalid square-bracket URLs, and there is a known easy “fix” for it. I.e., the issue is only with a few improperly encoded URLs getting blocked in the WP Admin.
It’s also not likely that the anti-hotlink rules are causing performance issues. They’re very general .htaccess rules that are used all over the Web on many sites.
Ask yourself this, how were your sites running before 3.5 and how are they running now? If there is a difference, what has changed?
It’s an WP 3.5 issue since my sites didn’t load that slowly with 3.4.2 My sites have share buttons that haven’t changed, I believe somehow those scripts are being interfered with by something. Or that the plugins themselves are doing stuff that 3.5 doesn’t like.
What do you mean by “unencoded square brackets in any URLs”? (I haven’t gotten there in your .htaccess book.)
In the Admin area, WP now includes unencoded characters, “[” and “]” in a some URLs. These characters are considered unsafe and should always be encoded. Because they are often associated with malicious scanning and server attacks, the 5G blocks them. Here is one of the conversations about the issue.
Thanks for explaining. Now I know it’s not a .htaccess issue, it’s probably an issue of the share buttons.
Hi Jeff,
With all of the things you have come up with for WordPress’ .htaccess… And things others have.. What’s the best *order* of placing things in a WordPress .htaccess? I’m assuming that the standard WordPress htaccess block would always come at the end? So, for example
Is there anything that should come after the WP block?
Thanks!