Blocking /xmlrpc.php Scans in the Apache .htaccess File

Someone out there on the internet is repeatedly hitting this blog’s /xmlrpc.php service, probably looking to enumerate the user accounts on the blog as a precursor to a password scan (as described in Huge increase in WordPress xmlrpc.php POST requests at Sysadmins of the North). My access logs look like this:

176.227.196.86 - - [04/Sep/2014:02:18:19 +0000] "POST /xmlrpc.php HTTP/1.0" 200 291 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
195.154.136.19 - - [04/Sep/2014:02:18:19 +0000] "POST /xmlrpc.php HTTP/1.0" 200 291 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
176.227.196.86 - - [04/Sep/2014:02:18:19 +0000] "POST /xmlrpc.php HTTP/1.0" 200 291 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
176.227.196.86 - - [04/Sep/2014:02:18:21 +0000] "POST /xmlrpc.php HTTP/1.0" 200 291 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
176.227.196.86 - - [04/Sep/2014:02:18:22 +0000] "POST /xmlrpc.php HTTP/1.0" 200 291 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
176.227.196.86 - - [04/Sep/2014:02:18:24 +0000] "POST /xmlrpc.php HTTP/1.0" 200 291 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
195.154.136.19 - - [04/Sep/2014:02:18:24 +0000] "POST /xmlrpc.php HTTP/1.0" 200 291 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
176.227.196.86 - - [04/Sep/2014:02:18:26 +0000] "POST /xmlrpc.php HTTP/1.0" 200 291 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"

By itself, this is just annoying — but the real problem is that the PHP stack is getting invoked each time to deal with the request, and at several requests per second from different hosts this was putting quite a load on the server. I decided to fix the problem with a slight variation from what is suggested in the Sysadmins of the North blog post. This addition to the .htaccess file at the root level of my WordPress instance rejects the connection attempt at the Apache level rather than the PHP level:

Slight Tweak to WordPress Broken Link Checker Plugin

In a futile effort to fight link rot on DLTJ, I installed the Broken Link Checker plugin by “White Shadow”. I like the way it scans the entire content of this blog — posts, pages, comments, etc. — looking for pages linked from here that don’t respond with an HTTP 200 “Ok” status code. The dashboard of problem links has a nice interface for updating or deleting these links, including the ability to add a CSS style deleted links to note that they were formerly there. One of the things I wished it did, though, was to add a message to posts/pages that noted a link was changed or deleted. You know — just to document that something changed since the page was first published. Tonight I hacked into the code to add this function. And with apologies to the original author of this beautifully structured object-oriented PHP code, it is a gruesome hack.

DLTJ Updated to WordPress 2.5

Unlike previous upgrades, this left some functionality broken — notably some of the links in the second block under the “about” heading to the left (if you are reading this from http://dltj.org/ itself). But, you know what? — it’s Friday afternoon and all of the important bits are working. I think. So if you see anything odd, please let me know.

SSL for WordPress Admin and the Problem with XMLHttpRequest

Note! The updates to SSL handling in WordPress version 2.6 handle the problem of SSL-encrypted admin sessions in a much less hackish sort of way. It doesn’t make any sense to use this plugin with WordPress version 2.6 when you can simply add define(’FORCE_SSL_ADMIN’, true); to your wp-config.php file.

The WordPress Codex has documentation for running the login, registration, and administration interfaces on an SSL server. There is even a plug-in that will do much of the heavy lifting for you. I have found both of these methods, by themselves, to be rather unsatisfactory, though, in that admin services that rely on AJAX calls back to WordPress break (such as the periodic saving of drafts). What happens is this:

DLTJ Updated, Readers Yawn

At least I hope that is the correct headline. I’ve been having some problems with this installation of WordPress lately — in particular, I could no longer activate or deactivate plugins — and the only solution offered in the WordPress codex was to start with a fresh installation of WordPress. Now you know how I spent my free time this weekend. While doing so, I updated the Barthelme theme and along the way gained some really need Semantic Web coolness to the underlying XHTML of the blog pages. The version of Barthelme is still a heavily, heavily hacked one, but hopefully the clean up this weekend will make it possible to keep up with new versions of the underlying theme files without major headaches. I also updated all of the plugins and cleaned out lots of old cruft in the plugins directory and in the theme files. As a result, the pages seem to load faster. Maybe that is just my wishful thinking.

DLTJ now Running on WordPress 2.3

Last night DLTJ was upgraded to WordPress 2.3. As far as I can tell, everything is working okay, but please let me know in the comments or the comment form if something doesn’t seem right. There were two tricky parts to the upgrade. (Well, three really, if you count the tasks necessary to extract the reminants of the Ultimate Tag Warrior (UTW) from the theme.) Fortunately, one of them was not the upgrade itself; after abandoning the Gentoo portage ebuild for WordPress, I switched to the Subversion update method. This was the first time I did an ‘svn switch‘ to get the new version, and it worked great.

Schemes to Add Functionality to the Web OPAC

Schemes to add functionality to the web OPAC fall into four categories: web OPAC enhancements, web OPAC wrappers, web OPAC replacements, and integrated library system replacements. I’m outlining these four techniques in a report I’m editing for an OhioLINK strategic task force and a bit of a reality check on this categorization is desired, so if I’m missing anything big (conceptually or announcements of projects/products that fall into these categories), please let me know in the comments. Generally speaking, this list is ordered by cost/complexity to implement — from lowest to highest — as well as the ability to offer the described enhanced services from least likely to most likely.

Gentoo Abandons WordPress in Portage

I don’t think this has been widely announced, but while waiting for an update to Gentoo‘s portage entry for WordPress to cover the latest security and bug fixes, I discovered in the comments of a bug in Gentoo’s bugzilla database that they are making no effort to support WordPress on Gentoo. I think this is really a poor move on Gentoo’s part. As one of the bug commenters noted, “WordPress is, in general, a good product with an extremely active user community and good upstream maintenance.” 1

A GLSA was issued for WordPress vulnerabilities in March — problems that have since been fixed — with this ‘resolution’: