Block trackback spammer operating on Ubiquity Server Solutions
For the past few days I have discovered that a script, or person operating a server farm, at Ubiquity Server Solutions, is attempting to post spam trackbacks to my blog. I don't even allow trackbacks on my blog, for this very reason, yet, this spamming idiot keeps blasting away with his script, ignoring a constant flow of Server 403 (Forbidden) responses. The page that the spammer is trying to POST to is no longer on the blog database, having been deleted in the spring of 2006! So, he is wasting his time and amusing me as I look at all the IP addresses I can add to my Exploited Servers Blocklist.
In fact, I have discovered that this blog trackback spammer is using a server farm assigned to Ubiquity Server Solutions, in Seattle, Washington, USA. Their full assigned CIDR is 64.120.4.0/22, covering IPs ranging from 64.120.4.0 through 64.120.7.255. However, to be fair to this clueless hosting service, the spammer is rotating through a group of servers with IP addresses only in the range of 64.120.5.0 - 64.120.5.255. To minimize possible collateral damage to innocent hosting customers, I am only blocking the narrow range encompassed by the CIDR 64.120.5.0/24.
UPDATE
November 20, 2009
Ubiquity Servers is now hitting MovableType blogs with trackback spam exploit attempts from a different CIDR: 174.34.144.0/23. I have updated the evidence and blocklist rules below to include this new CIDR.
The evidence:
174.34.145.115 - - [19/Nov/2009:12:59:57 -0800] "POST /cgi-bin/mt/mt-tb.cgi/18 HTTP/1.0" 403 137 "-" "tbr/0.1.0"
174.34.145.117 - - [19/Nov/2009:15:16:17 -0800] "POST /cgi-bin/mt/mt-tb.cgi/18 HTTP/1.0" 403 137 "-" "tbr/0.1.0"
64.120.5.197 - - [18/Nov/2009:07:07:08 -0800] "POST /cgi-bin/mt/mt-tb.cgi/18 HTTP/1.0" 403 137 "-" "tbr/0.1.0"
64.120.5.241 - - [18/Nov/2009:07:12:57 -0800] "POST /blogs/2007/08/stupid_blog_trackback_spammers_dont_understa.html HTTP/1.0" 302 378 "-" "tbr/0.1.0"
64.120.5.246 - - [18/Nov/2009:07:32:26 -0800] "POST /cgi-bin/mt/mt-tb.cgi/18 HTTP/1.0" 403 137 "-" "tbr/0.1.0"
64.120.5.254 - - [18/Nov/2009:07:49:48 -0800] "POST /cgi-bin/mt/mt-tb.cgi/18 HTTP/1.0" 403 137 "-" "tbr/0.1.0"
64.120.5.236 - - [18/Nov/2009:08:22:27 -0800] "POST /cgi-bin/mt/mt-tb.cgi/18 HTTP/1.0" 403 137 "-" "tbr/0.1.0"
64.120.5.196 - - [18/Nov/2009:08:30:16 -0800] "POST /blogs/2007/08/stupid_blog_trackback_spammers_dont_understa.html HTTP/1.0" 302 378 "-" "tbr/0.1.0"
64.120.5.225 - - [18/Nov/2009:08:49:54 -0800] "POST /cgi-bin/mt/mt-tb.cgi/18 HTTP/1.0" 403 137 "-" "tbr/0.1.0"
Enough already! You will notice that the spammer is only attempting to POST to two items. One is identified as blog entry number 18, which dates back to May of 2006 and was deleted from my blog in early 2007. The other target of this hapless spammer is an article I wrote about "Stupid Blog Trackback Spammers"not understanding a 403 Forbidden response, when they try to post trackback comments to a blog that has all trackbacks and comments disabled! There are no trackbacks or comments allowed on my blog! Spammers cannot POST anything!
I find this amusing, but others who do allow trackbacks or comments may not be so amused by this a-hole, whom I previously may have traced to Romania. If your website is hosted on an Apache web server, you can serve him a steady diet of Server 403 Forbidden responses by blocking his IP CIDR and his user agent in your public web root .htaccess file, as demonstrated below.
<Files *>
order deny,allow
deny from 64.120.5.0/24
deny from 174.34.144.0/23
</Files>
Options +FollowSymLinks
RewriteEngine On
RewriteOptions inherit
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} ^tbr/0\.1\.0$
RewriteRule .* - [F]
You should determine if legitimate visitors to your blogs are using the tbr/0.1.0 user agent. If so, don't block it. In all likelihood, only spammers use that tool with that version number.
Details about the .htaccess file are found in my extended comments.
In the first half of this article I described how a spammer was attempting to POST spam comments to my blog, using a tool made to create blog "trackbacks." These are comments that usually include a link to the website owned by the person placing the trackback. This system has been abused by spammers to place spam trackbacks to their websites that promote illegal drugs and pornography.
The end of the first half included codes to be used in an Apache web server file named .htaccess. Some of those codes, officially known as "directives," blocked access to a website (or server) by the IP address range, known as a CIDR. This makes use of the Apache Mod_Access module. The last part of the directives utilize the Mod_Rewrite module to block access to the user agent known as "tbr/"(version), which is used to POST trackbacks to blogs that allow them. This is software is usually used by spammers in an automated script.
Most of the personal websites in the World are hosted on a box running an Apache Web Server, running on a Unix or Linux operating system. Other websites run on Microsoft Windows IIS Servers, mainly because they may require proprietary Microsoft technologies (e.g. .NET, .ASP) to be supported. This article only deals with Apache web server access controls, which do not apply directly to Windows Servers (sorry).
One of the things I like about operating a website on an Apache web server is that I can control who gets access to any part of the website by means of a special server file named .htaccess. The file name has no prefix, just a period and a suffix. This type of file has a special meaning to Apache servers and is normally hidden from view in a file manager, or ftp client. Some new shared hosting websites come with a .htaccess file with some basic directives, others have none to start. Contact your web hosting company to find out if they allow users to create custom .htaccess directives, including "Mod_Access" and "AllowOverride All."
If your web host does allow users to create or modify their own .htaccess file, you need to know a few basic things about it. First of all, as I mentioned before, it is normally hidden, because it has a file name beginning with a period. If you use a file manger supplied by your hosting company, they probably have unhidden these files in the view options. However, if, like most webmasters, you use what is known as an "FTP client" to upload and download files to and from the server, you may need to input a special command in a "file mask" box, to unhide normally hidden files on the server.
Most, if not all ftp clients have a means of unhiding .htaccess and other hidden server control files. Some may have a checkbox option that you select and apply. Others, like WS_FTP have an input box named "Remote File Mask" - in which you can type the code: -AL and apply it. This code would be placed inside the configuration box for every Apache based website you intend to log onto, with that FTP client. The next time you log onto that website you should see any hidden control files, including any .htaccess that may already exist.
If there is a .htaccess file in the public web root directory, that is the one you will probably want to modify to block spammers, hackers and other unwanted traffic. Anything you block in the master .htaccess, in, for instance, your "public_html directory, will apply to all sub-directories on your website. If there is no .htaccess yet, you can create one from scratch, using Windows Notepad, or any other plain ASCII text editor that is installed on your computer. Note, that some text editors don't like files that have no prefix and may try to force the name to end in .txt. If this happens, allow it for the time being. After you have added all of the directives you want, save the file, then rename it to .htaccess, then upload it, then immediately check a page on your website to make sure you didn't cause a fatal error by using bad syntax.
Be extremely careful when editing .htaccess files. One mistyped or unrecognized, uncommented character will break your website, until you find and correct the error. Server 500 errors indicate a misconfigured directive in .htaccess, or some other critical file. All non-directives must be preceded with the # sign and be typed on one long line. If your editor has Word Wrap enabled, the lines may occupy more than one line of text, which is ok, as long as you do not use the Enter key to force a line break. Only hit Enter to create blank lines, or new lines of comments, or lines of directives.
Example of a comment in .htaccess:
# This is a comment in .htaccess. It occupies just one code line, even if it wraps due to word wrap.
Example of a Mod_Rewrite Directive in .htaccess
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/5\.0$
RewriteRule .* - [F]
The above condition states that if the exact user agent is "Mozilla/5.0" - a known exploit tool, then return a Server 403 Forbidden to any request for any page or resource.
Blank lines are acceptable and are a good idea for keeping different lists and directives separated. Just make sure that anything other than a blank line starts with and completely includes a proper directive, or else a # sign, if it is a comment.
Actual .htaccess directives are not negotiable. You must learn the correct syntax for the version of Apache your server is using, if you are going to succeed with your custom .htaccess directives. You can search Google, Yahoo, Bing, or Ask.com for the keywords ".htaccess+directives" to learn about the various recognized directives, modules and correct syntax. The following Google search box is already setup to return results on .htaccess tutorials, but you can change it to .htaccess+directives if you prefer:
Another great place to learn the fine points about applying .htaccess directives to achieve specific goals, is the Webmaster World Apache Web Server Forum. You should read as many posts and replies as possible, searching for topics about the problems you want to solve, before asking for help. They teach by example (literally, using example.com) and corrections, but will not write code for you, from scratch. You must have a basic understanding before getting into advanced .htaccess concepts.
By using a combination of Mod_Access IP address/CIDR blocklists and Mod_Rewrite conditions and rules - to block known bad user agents, referrers, requests or exploit attacks, you will go the extra mile in protecting your server and or websites from unwanted traffic, scammers, spammers and hackers.
If you like this article please share it.
The content on this blog may be reprinted provided you do not modify the content and that you give credit to Wizcrafts and provide a link back to the blog home page, or individual blog articles you wish to reprint. Commercial use, or derivative work requires written permission from the author.