Category: WordPress

Posted on

How To Stop XML-RPC Attacks While Allowing Jetpack & VaultPress Access

Folks in the WordPress space have been following the XML-RPC Quadratic Blowup attack fairly closely these last few weeks, as the attack has the capability to cripple sites running an unpatched version of WordPress within minutes, if not seconds. WordPress 3.9.2 (and 3.8.4 and 3.7.4) fixed the root problem, the vulnerability to the XML-RPC Quadratic Blowup attack, but it still allows XML-RPC functionality to be enabled.
Unfortunately, the latest rounds of patches aren’t fully sufficient in denying persistent crackers/lamers the capability of taking down a site sheerly through repeated requests to xmlrpc.php. Unless a site has some sort of throttling enabled (via, say, fail2ban [WordPress plugin available here]), a single user can, through sheer persistence, overwhelm a site.
For many WordPress users, XML-RPC isn’t necessary. It offers a convenient way to enable remote editors, such as MarsEdit or Windows Live Writer, to publish posts and pages directly to WordPress. It also allows other blogs to issue pingbacks to posts and pages. Useful, but not critical. In these cases, XML-RPC can be disabled in its entirety.
However, for users of two plugins, it’s absolutely critical: VaultPress and Jetpack. These two plugins rely upon XML-RPC to communicate with Automattic‘s servers to perform backups, sync comments, track stats, and a host of other functionality. Sites using Jetpack or Vaultpress (or both) have to have XML-RPC enabled or the plugins simply stop working. As Jetpack and VaultPress see wider distribution, disabling XML-RPC entirely becomes less of an option.
I recently had a site that was getting hammered by regular XML-RPC attacks and the user needed to have both VP and JP running. The site itself is running on the now-standard stack of Nginx and PHP-FPM, so here’s what I did:
Basing my work off of this helpful article, I tracked down all of Automattic’s current public IP addresses. (The list in the article itself isn’t fully applicable for two reasons — the addresses aren’t in CIDR notation and the instructions are for Apache instead of Nginx). I translated all of the ranges to CIDR netblocks using a handy CIDR subnet calculator. Then, inside of the site’s Nginx config file, I added the following block:

location /xmlrpc.php {
    include blockips.conf;
}

Then, I created /etc/nginx/blockips.conf, the contents of which were Automattic’s netblocks:

# Automattic's netblocks
allow 216.151.209.64/26;
allow 66.135.48.128/25;
allow 69.174.248.128/25;
allow 76.74.255.0/25;
allow 216.151.210.0/25;
allow 76.74.248.128/25;
allow 76.74.254.0/25;
allow 207.198.112.0/23;
allow 207.198.101.0/25;
allow 198.181.116.0/22;
allow 192.0.64.0/18;
allow 66.155.8.0/22;
allow 66.155.38.0/24;
allow 72.233.119.192/26;
allow 209.15.21.0/24;
deny all;

Then I restarted Nginx.
That’s the solution in its entirety. In plain language, if a request for XML-RPC isn’t coming from one of the Automattic netblocks, Nginx will simply drop the traffic on the floor, no questions asked — the traffic will never even make it to PHP in order to get processed. The nice thing about this approach is that, should I ever need to set this solution up on another host or add another domain to the same host, I can simply make sure blockips.conf is present and then just point that new config file at it, and if Automattic adds/changes their netblocks, I can simply change one file and have it apply to all of my sites automatically. I can even make it into a Puppet-managed asset and then put it anywhere I could feasibly need it.

Posted on

Fork Puppet(-WP)

My fellow 10upper Eric Mann recently authored a post entitled Just Ship Already in which he encouraged developers to (get this) just ship their code, already! Well, in the interest of doing just that, I’d like to announce a fork of Ryan McCue’s Puppet WordPress module.

That’s Nice. Uh, What?

Puppet is an awesome systems automation tool. Essentially, you can describe (in a Puppet DSL) the way you want a system to be configured (packages installed, processes running, etc.) and then tell Puppet “Do it” and it will, to the best of its ability, make sure that your server looks exactly like you want it. There are all sorts of useful packages of Puppet code out there (they call them “modules”) that extend the base functionality and can do a lot of the heavy lifting for you, instead of you having to develop your own Puppet code. There’s code for Apache configurations, MySQL databases, firewalls, time servers — pretty much anything that you might want to configure and/or automate on a system.
Continue reading “Fork Puppet(-WP)”

Posted on

Ping!

tl;dr version: I joined 10up in October, been very busy since. We just released a fancy-dance new plugin named PushUp Notifications. You should get in on it.
Long version: I joined 10up last October as a Senior Systems Engineer and have been head-down in systems for some pretty large customers since then. Obviously, blog output has suffered. *grin*
We (10up) just launched a nifty little plugin called PushUp Notifications that ties in with Apple Push Notifications for Safari to, get this, send push notifications from your WordPress blog. Publish a post, click the “Push desktop notification” checkbox, and hit “Publish” and all your subscribers will be notified. No RSS feeds, no Facebook updates, it just goes right to their desktops. Right now, it’s a 1.0 product, so it works with Safari for OS X, but in the future, we’re talking about extending it to Firefox, Chrome, iOS — the sky’s the limit, really.
If you’re reading Literal Barrage on Safari, you would’ve been prompted to allow push notifications for the site on your first visit here. Make sure to hit “Allow” and you’ll get notified whenever* I update the site.
Check out the demo video if you want a better sense of how this all works:

*Yeah, I know.

Posted on

Theme Hook Alliance First Pass (1.0-draft)

After I published my previous post detailing the proposed Theme Hook Alliance, I decided to put virtual pen to virtual paper and started the themehookalliance project over on github. A couple of train rides later, I feel like I’m ready for folks to start commenting on it.
So please, if this effort interests you in the slightest, head over to github, comment away, fork and submit pull requests. I’d love to get this effort kicked off and under way.

Posted on

WordPress Theme Hook Alliance

Konstantin Kovshenin posted an interesting piece decrying WordPress theme frameworks1 and the extra amounts of work that they (can) require to get working Just The Right Way. Essentially, his complaint comes down to having to re-learn a system of hooks and filters in order to be cognizant of, if not competent with each of the frameworks in use. Konstantin calls out Genesis, which, to be frank, is the absolute best of the bunch2, as far as I’m concerned. Genesis, whenever and wherever possible, asks “What Would Core Do?” and then implements its innovations in a way as close to Core standards as is feasible.
I’ve actually been bothered by the same thing over time and have noticed that the net effect is that certain WordPress designers and even whole firms tend to pick at most 2-3 theme frameworks to specialize in. This leads to a bit of a “siloing” effect — designers and devs become experts in a certain way of doing things but ultimately end up being at least partly constrained by their choice of framework[s].
This also has the end effect of locking site owners into particular theme frameworks, making migrations and redesigns complicated and potentially expensive in terms of time and money.
So what can be done? I can see two approaches, the merits of which I will discuss below.

WordPress Core adds more hooks

WordPress already has quite a few hooks available, in the form of both regular action hooks and an extensive variety of template tags. These provide developers and designers with a consistent set of entry points to target for theme and site customization. If we could convince upstream WordPress to define a standard set of theme hooks, theme authors could code to a Core-supplied benchmark which would allow plugin developers greater opportunities to extend WordPress in new and better ways. Further, this would allow users in general to more easily change their theme-of-choice.
There are (at least) three decided downsides to this approach.

  1. Core Bloat WordPress Core has been getting both larger and more complex as time goes by. While there have been great leaps in performance over the past few versions, it’s indisputable that the size of a WordPress download has been creeping ever upwards, to the point that several previous pieces of Core functionality (such as the various importers) have been stripped out in order to allow WordPress to even install in certain low-memory hosting situations. Further, stripping the images out of the Twenty[Ten|Eleven] themes and moving core JavaScript libraries to an external CDN have been bandied about as ways to further fight bloat.

    While the actual size of the additions would likely be small (in terms of kilobytes added to the download), there’s no denying that additional hooks would greatly increase the complexity of the underlying code.

  2. Explicit dependence on WordPress release cycles WordPress itself is released on a (fairly) static schedule, with roughly 2.5-3 releases occurring per year. In the event that additional theme hooks were needed, theme authors would need to wait for the next WordPress release in order to be able to rely upon the hooks being in wide use.
  3. This isn’t something core WordPress is/should be concerned with Frankly, the whole concept of theme hooks is self-evidently not a core WP issue. Themes currently implement their own hook regimes in order to allow for customization and flexibility precisely because WordPress itself doesn’t supply these points of articulation. This is no knock against WordPress itself, but rather this reflects one of its core strengths: the Plugin API allows for almost unlimited customization opportunities. Core WordPress should limit itself, wherever possible, to providing users and developers with the tools for customization and extension and should get out of the way so that such customization is as “frictionless” as is feasible.

Theme developers agree upon an independent set of hooks

This option makes more sense to me. As I pointed out, these hooks are something that various and sundry theme development shops have taken to implementing on their own because they want more and/or different capabilities than WordPress template tags and action hooks offer by default. Heck, I have quite a few hooks on offer in Elbee Elgee for precisely this reason (all prefixed with lblg_, of course).
By taking this task out of the hands of the WordPress Core, we would gain quite a few advantages:

  1. Version independence Hook alliance member themes could debate the merits of various useful hooks and their places within themes on a timetable completely their own. There would be no need to have to wait for a lengthy Trac process and a new major dot-revision of WordPress — theme devs would be free to implement them whenever a consensus was reached.
  2. Know your role, jabroni!3 I’m drawing a bit of a blank on how best to summarize this thought other than “theme concerns generally exist at a level of abstraction above WordPress itself”. The code present in WordPress itself is concerned primarily with “how do we save and/or retrieve information from the database in a meaningful and orderly fashion?”4 It falls to the themes to determine
    1. Where each piece of retrieved information appears on-screen
    2. How each piece of retrieved information looks once on-screen
  3. Another thing to argue about, unendingly, in a place that isn’t Trac Okay, maybe that’s not a true advantage at first glance, but work with me here. How many arguments have cropped up on Trac or on the wp-hackers mailing list over issues that would be covered by the hook alliance? If a standard Core Trac reply could be “That’s a theme hook issue and not a Core one. Have you suggested something over there?”, would we not all benefit? This would allow Core developers to focus on the get/retrieve aspects where they excel and allow theme devs much greater control over their own destiny.
  4. Coordination with the Theme Review Team Not to put too fine a point on it, but the current incarnation of the WordPress Theme Review Team is the best example of a true community investment opportunity WordPress has going. Goals and standards are well-defined and the team itself is a large group of people working unapologetically towards making themes hew to a uniform code of quality, reliability, and security. Chip, Otto, Emil and Edward (among countless others) are to be commended for their ongoing efforts in this respect. The TRT could offer invaluable feedback in developing a uniformly useful set of agreed-upon hooks.

Implementation details

A simple first step would be to agree upon a standard prefix/namespace for Theme Hook Alliance hooks. I might suggest tha_ as a good place to start. I would also suggest a few simple hooks whose purpose should be quite obvious, such as

  • tha_before_header
  • tha_after_header
  • tha_before_content
  • tha_before_sidebars
  • tha_after_sidebars

Again, that’s just a sampler. I think there are a ton of other points of articulation that would be invaluable.
So, who’s with me in this idea? Am I crazy? Does anyone else see any utility? Who wants to argue over the utility of tha_before_content()?
UPDATE (10:03 AM): Chip points out on Twitter that this idea is not novel: it was discussed over on WP Tavern about three years ago. I think it’s time to resurrect it. *grin*

1Yes, I know the arguments about what constitutes a “framework” versus a “parent theme”. I’m working with the terms in play. Please don’t write me angry letters.
2“the bunch”, here, meaning “commercial and/or widely-used theme frameworks”.
3Do you smell what the Rock is cookin’?
4Yes, I know: gallery shortcodes and widget headers. Please don’t write.

Posted on

Elbee Elgee 1.3.2 Approved; 1.3.3 Incoming

I’ve released Elbee Elgee version 1.3.2 to the WordPress.org themes repository. The update got a clean bill of health and should be showing up in your WordPress Updates screens as soon as the Powers That Be mark it for “sync”.
This is a small update that addresses the menu issues some folks were seeing involving mutli-level menus. The quick fix was to make sure you specified a custom menu for the Primary menu location but 1.3.2 should fix it from the back-end side of things.
Additionally, I’m cobbling together a 1.3.3 release for WordPress 3.3 support (keep tabs on its status in the Theme Repository here. The change is minor — WP3.3 changed the way CSS stylesheets were included (see here and here for details) and so some of the Elbee Elgee styling has started to “bleed” over into the WP administration interface.
Ain’t that the way of things — I release a bugfix and then have to follow it up with another one, short-order? *grin*

Posted on

My WordCamp Philly 2011 Presentation: “Adding A Social ‘Stache To WordPress: BuddyPress, bbPress And Beyond”

The official WordCamp Philly blog has it right: #WCPhilly 2011 was a great success. We had awesome speakers, awesome sponsors, great volunteers and a ton of very enthusiastic WordPress users turn out for a wonderful weekend.
My presentation is embedded below. Warning: contains dangerous levels of mustache.

Adding a Social 'Stache to WordPress: BuddyPress, bbPress and Beyond

View more presentations from zamoose