Author: Ipstenu (Mika Epstein)

Save Bacon With ModSecurity
Earlier this month, my company DreamHost had a small snafu with ModSecurity. The tl;dr is that we had a typo and it stopped some people from being able to access or properly use Jetpack. Thankfully, the WordPress community (including everyone at Jetpack, whom I owe drinks and/or dinner) is filled with amazeballs awesome people who helped us figure out everything and sort out customers who, upon getting what appeared to be a Jetpack error, went there when they needed to go to DreamHost.

These things happen. Code isn’t perfect, people aren’t perfect, and everyone makes mistakes. Of course, on the internet it’s unreasonable to assume a legit gaff, and I’ve seen people call out “Why was DreamHost pushing out these tweaks?” and “Didn’t they test?” so I thought perhaps it was time to explain why we use Mod Security and why, even though it’s my nemesis, I like it a lot.

What is ModSecurity anyway?

ModSecurity (aka modSec or mod_sec) is an open source web application firewall (WAF). That means it sits between your website and the world, blocking all the bad people. When we have those brute force attacks, ModSecurity is key in blocking them. It blocks people who attempt code injection attacks like this:
```
http://www.example.com/wp-login.php?username=admin'">DROP%20TABLE%20wp_users--
```
Now that would never work on WordPress core, but the Bobby Tables attacks have the potential to kill your site if you have a plugin or theme that’s insecure. Most hosts have customized their rules to check for things like hitting the wp-login page improperly or passing through credentials directly. That means if someone tries to log in to your site without clicking the submit button (yes, you can code that), it will block them.

One of my favorite things about ModSecurity is that you can hook it into another firewall like ConfigServer, Fail2ban, or even the built in linux feature of IPTables, and block any IP that routinely trips your security rules.

So why was DreamHost monkeying with it anyway?

Every host is constantly monkeying with ModSecurity. As attack patterns grow and change, your host has to adapt. There’s a team at pretty much every host on the planet who watches logs, studies them, and improves the ModSecurity rules. Heck, we even share our rules with other hosts when the situation calls for it, like that Brute Force attack back in 2012. It was brand new, we were all surprised at the aggressiveness, and we quickly shared information.

On any given week, your host is creating new rules and testing them in their dev environment, or on specific real servers that are designated “Go ahead, blow me up.” After all, we all know nothing beats real-world testing. And if push came to shove and one specific site was being hammered, we may push an experimental rule to them before we’re done testing everything, because it’s that or your site is down.

We’re always working and improving. Security is a moving target after all.

How come a typo slipped through?

If you can find me someone who makes a 100% perfect product every single time, I’ve got a bridge for you to buy. We tested everything we could think up, and interestingly enough, that Jetpack error didn’t impact all Jetpack users! We have a test box, with Jetpack, and it worked fine there. Go figure.

But I’ve often said your website is a pretty snowflake. It’s unique, and what you do with it is different from what everyone else does. Things I have and do on this server and this domain are wildly different from my other sites on this same server! The need for the site is different, and what it uses is different, so what it does when it communicates with the world? Different.

I’ve had days where one domain is acting like a prat, but the others are fine. And I’ve sat there thinking “But it’s the same on these domains! They’re on the same server for God’s Sack!” only to realize that the usage pattern of the sites were very much not the same. And that takes everything longer to fix because you have to narrow things down over and over until you actually find out what the heck you did wrong.

I can’t even tell you this will never happen again because I’m pretty sure someone will make a mistake again sometime in the future.

Conclusion?

I wouldn’t run a site without ModSecurity, but there are options.

In February 2013, Zero Science Lab released a study comparing it to Incapsula and Cloudflare. While ModSecurity came out on top (though it was noted to be more aggressive and caused more false positives), Incapsula has been working hard to fix it’s issues. There was actually a Round 2: Incapsula vs Cloudflare study in October 2013, and in this one, Incapsula is the clear winner. Of note, you won’t get the WAF protection on either for free.

The studies say, to me, that if you’re master of your own domain and want the firewall on your server to run yourself, use ModSecurity. If you’re going to farm that security out to the cloud, use Incapsula. There are, of course, benefits to putting the firewall on the cloud, and the major one is that you’ll be spared high CPU since the processing of the naughty people is done on their server, not yours. But of course, if they go down, you’re at risk, so you should probably have ModSecurity anyway.

After all, your website is important, right?
28 April, 2014
It’s Better to Extend

If you’ve heard me answer the question “Why is this a plugin and not in core?” then you’ve probably heard me say “It’s better for WordPress to be extendable than to include everything.” And you’ve certainly heard me tell folks that the concept of Open Source development is different than many of you think.

One of the many reasons I liked WordPress was that, unlike other apps, I didn’t have to spend the first week after install turning off a great number of features that I didn’t want, just to have the core application that I did want. WordPress stood apart by assuming very little. You want to publish content. That’s pretty much it in the beginning. As things changed with the times, comments and media uploading were added, but at it’s heart, WordPress has remained pretty on point.

Simplicity.

WordPress doesn’t want to get in the way of your content. It would rather make decisions, not options, to keep it simple. We constantly argue about better ways to simplify, how we can remove options to improve usability, how we can make things easier and faster.

Earlier this month, my friend George ruminated on decisions and specifically talked about how to make his code serve two masters:

To each according to their needs. Typical users need a simple, smooth, classy interface. Power users need to get under the hood. Why try to make something that doesn’t work well for either by trying to serve both?

This is the route WordPress tries to take, and it has some pretty incredible payoffs. If you don’t need to get under that hood, your site is lean, fast, and perfect. If you do, you can totally monkey with your engine all you want to make changes. But that user who has no idea what we mean when we say “add a filter to the output…” doesn’t have to learn anything new. They can just install a plugin and go.

By being extendable, WordPress is able to keep itself small and let you make the decision of what you need. It also lets you pick out what’s important to you, and this is a hard choice. We want a lot of bells and whistles on our sites, but we know they’ll possibly make things slow. We have to decide what we care about more, what can we sacrifice, and what must we keep.

So when I tell people “It’s better that WordPress is extendable.” I do so understanding that I put the work on you, and not core. I’m making you do the hard part, the part of weighing options and features. The part of telling a client “No” because that awesome slider will make their page slow. I’m putting you on the spot.

I think that may be why people get made about this whole thing, more so than the trials and tribulations of finding the right plugin. Of course finding a good plugin that won’t break is hard. You should be circumspect about plugins and themes, test them well, don’t just use them because they’re super pretty. But here I am saying that we’re lazy, over in WordPress land, and we want you to decide what you need.

Many of you use smartphones. Many of you buy in-app purchases. Many of you, like me, think that in-app purchases are kind of a terrible thing. Thomas Baekdal goes a step further and argues they are destroying the gaming industry. Many people argue WordPress does the same thing. The core is free and the add-ons may be free or they may cost money. Heck, I paid for this theme, it’s parent theme, and some plugins!

Let’s take Easy Digital Downloads, a plugin I use. It’s free. I have six specific add-on plugins for it, though to do things I want. One I wrote, three are free, and two I paid more for. Why is that okay? Because unlike the model of paying to speed things up, EDD lets me pay to add what I NEED. I needed a PayPal alternative (PayPal is free by the way), so I bought Stripe for my users who can’t use PayPal. I wanted (not needed) a way to let people pick prices in some places, so I decided to buy that as well. But everything else has been free. That’s nothing like the In-App payments, that’s what they wanted to be but didn’t manage.

So it’s better to extend because I decide what I want, and I decide where to spend money, and I decide what to do. WordPress without those extensions? Still works. There are hundreds of options to do what I did totally for free, legally and morally free of implications too. I paid for the speed and connivence, but I didn’t have to worry about things I didn’t want or need because I didn’t add them.

I like the place where I decide what I need.

25 April, 2014
The Person of WordPress

I read Manga, pretty much like every comic book nerd from the 1980s. I got hooked on some fairly grown up stuff as a tween, and today I read the stuff with entertaining and semi realistic stories. One of them I read is called “Space Brothers” about, get this, two brothers who decide to become astronauts. When the story starts, the younger brother, Nanba Hibito, is poised to make his first trip to the moon, while the older brother, Nanba Mutta, is fired for head-butting his boss. As the story goes on, Mutta overcomes obstacles and is accepted into JAXA, Japan’s version of NASA.

It’s during his first lecture as a newbie wanna-be astronaut that the lead of the support staff draws the Japanese character of Person on the white board:

And he tells them a famous person said this:

The character of person shows that people are living by supporting each other.

I was unable to verify the quote, but it sounds somewhat reasonable to me. Still, in looking at it, I thought that the stroke on the right seemed to be supporting a bit more than the one on the left. So did the character in the manga, who went on to explain that some people support more than others, but they do so with the intent of boosting the others higher. That’s why the leftmost stroke is taller.

Now, Japanese has three written languages: hiragana, katakana, and kanji. For those unfamiliar, you can read a brief explanation from Ancient Scripts, but the person character I used above is from kanji. There’s a historical basis in kanji that look like their meanings, so this interpretation isn’t outside the realm of possibility.

When I look at WordPress, I see that leftmost character as being the path taken by the people who manage to write amazing code. And I see myself as the rightmost character, who tests and debugs and supports them. I feed information into them as I find it, I help others to do the same and solve their problems. I am, indeed, a support guru.

There’s nothing wrong with this. If it wasn’t for me, and people like me, WordPress would fall over. I said this at WordCamp SF in 2012: If there weren’t users, there would be no WordPress. All of us, the users and the support people and the random one-plugin developer and that person who edited a theme once, we’re all the reason WordPress is still being used as well as it is. The app was made useful and deemed useful.

But consider the modern version of the character.

This may seem strange if you’ve never read about kanji before (I was once deeply into a manga about caligraphy), but it has it’s own version of print and cursive. Here are all the various ways one might write ‘person’ in kanji:

Now you may notice that’s a Chines Kanji exemplar. It’s the same thing for around 70% of the characters. And in this case, it happens to be the same.

If I was to extend my previous thought, that the support arm of WordPress helps it reach new heights, I would look at the modern character and say that the two arms keep each other from falling over and, only when combined, can they reach the future of marvelousness.

That’s a bit cheesy, I know, but the point is that we’re not alone. We don’t work on open source in a vacuum, we work together, relying on each other, to make everything better for everyone. We’re equal partners in the work of creation, even if we don’t see it as such all the time.

I don’t know what the kanji is for Open Source, or if there even is one, but I hope it represents people for being the crux of it all, always helping people.

23 April, 2014
Changing Your Domain Name In Multisite
Even I hate moving Multisite if I have to change folders (like from domain.com/wordpress to domain.com). But if you told me “Mika, I need to change my domain from cocobanana.com to cocoabanana.com!” I’d say “Hold my beer for five minutes.”

I will note: If this process freaks you out, remember to never make changes like this without a backup. If it’s still super spooky, you may not be ready for Multisite yet. I would consider this to be a good litmus test, though, for a wanna-be-multisite-master. You’re going to need to be able to do these things to get there.

Step 1: Search and Replace

This is the easiest one. If you have WP-CLI it’s super easy.
```
wp search-replace http://cocobanana.com http://cocoabanana.com
```
Don’t have WP-CLI? Okay, grab Interconnectit’s Search/Replace DB Tool and use that.

This will take care of 99.999999% of your site. It’s imperative you remember to use this tool! If you don’t use a tool that searches and replaces with consideration to data serialization, you will cry and reset all your themes and widgets. Manually. See? Told ya you’d cry!

Step 2: Edit the Database

Go into the database. Look at the wp_site table. Change the domain field from cocobanana.com to cocoabanana.com (seriously, that was it!).

Then look at wp_blogs and change those domains similarly as needed.

Step 3: Edit wp-config.php

Open the file and look for this:
```
define('DOMAIN_CURRENT_SITE', 'cocobanana.com');
```
Change the value to cocoabanana.com and save it.

Step 4: .htaccess and plugins

I lied. There’s another step. Make sure you weren’t super smart earlier. Like if you used some rules to block hotlinking, make sure the new domain is added in there. Also make sure your plugins aren’t calling your domain in some weird way (though that search and replace should have fixed that too).

Also if, like me, you hate www’s in your URLs, you’ll want to put this in your .htaccess to force everyone around. It also has the benefit of making sure the weird redirect of www being treated as a subdomain stops happening on Multisite. By the way, I still strongly encourage you to NOT use www in your Multisites, it’s a pain in the ass and you can educate people as to why no one has to have www anymore. Also WordPress itself has always suggested you NOT use it when activating Multisite. Do you know better than WordPress? No? Okay then, don’t use www.
```
&amp;lt;IfModule mod_rewrite.c&amp;gt;
	RewriteEngine On
	RewriteBase /
	RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
	RewriteRule ^(.*)$ http://%1/$1 [R=301,L]
&amp;lt;/ifModule&amp;gt;
```
Now can I have that beer back?
21 April, 2014
Apache 2.4 Kiboshed SPDY
I have a store running on SSL for security reasons. I mean, you kind of have to, right? The problem is you don’t really want to cache SSL pages, as I reminded myself lately. At best, I was able to work around PageSpeed’s idiosyncrasies and compress the HTML and JS somewhat, but still I know that there has to be a better way.

Everyone told me to look at SPDY. Now… this came with some issues. I needed Apache 2.2.4 (I was on 2.2.2):
```
	httpd >= 2.2.4 is needed by mod-spdy-beta-0.9.4.1-397.x86_64
	mod_ssl >= 2.2 is needed by mod-spdy-beta-0.9.4.1-397.x86_64
```
What’s an elf to do? Well… what about Apache 2.4? After all, it’s the latest and greatest. This is when my eyebrows jumped. There’s no support for Apache 2.4. And the mod release is only on SPDY 2 when the release is on SPDY 3.1? What on earth is Google doing!? Apparently giving up on mod_spdy which is horrible. Love the open source community though. Patrick Buckley forked it. I cannot stress enough the requirements in life to check into some random stranger before you just download and use their code. Especially when we’re talking servers! Sadly, looking into his code I saw it would upgrade apache and SSL.

Well. No. It’s not that I don’t trust this guy, the code looks okay. It’s trying to install HTTPD 2.4.7 which is not the latest and greatest for my server’s OS (currently 2.4.9). Not to mention some research on cPanel showed issues with mod_spdy and CentOS (including the note that Patrick’s code caused random coredumps). However. The odds are that when, eventually, the stars align and there is mod_spdy (or some alternative) for Apache, it’ll be for 2.4.x so I may as well put the effort into updating today.

Sidebar. Yes I know about nginx. Yes I’m aware of the package for CentOS. Yes I know it’s faster for static files and CSS and JS (and arguably even for PHP). Yes I know it’s easier to use default nginx than to tune Apache. But. I like having my .htaccess file to edit, and I’m not ready to do a total switch yet since this is not my server for me alone. Eventually yes, I will. Today is not that day.

So Apache 2.4! There aren’t a lot of Apache 2.4 issues, but what they have are major enough for me to sit up and pay attention. For example, MPM-itk is no longer provided as an easy install from cPanel, they wanted me to use mod_ruid2, which isn’t compatible with memcache. I really hate that. However. Many people informed me you can still use memcached, and besides which, Apache 2.4 doesn’t support Memcache. I still find it amusing that Cpanel outright says mod_ruid2 is just as dangerous as MPM-itk, but would rather use the one that’s less compatible. It’s not that I can’t install it on my own, of course, it’s as the amount of effort put into working around a problem gets large, the less pleased I am with that as a solution. Work smarter. By the way, mod_ruid2 is available on Apache 2.4. I learned a lot when I installed it myself, now I’ll learn more.

There was a catch in things of course. I’d set up mpm.conf files in /usr/local/apache/conf/userdata/std/2/ and had to roll those back, as they borked deployment. Took me an hour to sort out that. Remember to read the complete errors, folks. Of course I tested things once Apache 2.4 was up, before starting to make sure all my modules etc were still running. I was lucky, I only had to configure pagespeed for Apache 2.4. Everything else worked out of the box. Since I was using MPM Prefork already (worker is not available due to mod_ruid2) I didn’t have to edit anything there.

What did I notice? Memory and load stayed the same. And you’d think that meant this was for nothing. I should mention this happened to be on the same day I got nailed by a 60% bump in traffic on my busiest site. So … that would be better then.

I’m bummed that SPDY isn’t being actively developed for Apache right now, though. For folks who are pushing the HTTP 2.0 world, they seem intent on ignoring or not committing to getting others up to speed. While nginx is awesome, there will always be a reason for people to use other server types. I hope to either see mod_spdy get picked up and loved again, or for someone else (Microsoft’s HTTP S&M?) to pick up the thread and remember that abandonment doesn’t move things forward as fast as you’d think.
18 April, 2014
General Behavioral Guidelines
The following are cribbed from TWoP’s Dos and Don’ts. They should not be considered the be all and end all of how to behave on a site, but I find that abiding by these gets you going on pretty much every forum and comment site in the history of ever. Since a lot of people never saw TWoP (or the similar post I made on make/support in WordPress land), it’s useful here.

Good Manners and Respect Dos and Don’ts
- DON’T use “um,” be snotty to another user, or make the argument personal
- DO know the difference between differences of opinion and personal attacks
- DON’T present your opinions as facts
- DON’T post the same opinion over and over in the hopes of wearing other people down or “winning” a discussion; just move on
Starting New Threads Dos and Don’ts
- DO search for existing topics before starting new threads
- DON’T use all-caps or excessive punctuation in thread titles
Posting Messages Dos and Don’ts
- DON’T post in a thread until you’ve read the whole thread
- DON’T post “Me Too!” messages; add something of substance to the conversation
- DON’T sign your posts
- DO use proper spelling, capitalization, punctuation, et cetera
- DON’T pimp your site or product, et cetera;
- DON’T post copyrighted articles; link to them
- DON’T post the same thing in multiple areas; pick a spot and go with it
Warnings, Bans and Trolls Dos and Don’ts
- DO take any mod warnings you get seriously
- DON’T bug the mods to remove moderation on your posts
One thing I left out is something that drives me up the wall. Don’t reply to things in the wrong place. If you’re reading someone’s blog post about how to tie shoes and you post a comment of “Will Prince Harry get married?” because the blogger remarked about that in a separate post, you’re being really annoying. I personally delete off topic posts, and serial-off topic posters get blocked.

When you get off topic, you make it harder for a conversation to be followed. When you make it hard to follow, you get bad help (at least in support forums). Hate it.

Of course, when I suggested these to WordPress’s Support folks, I got some interesting replies which tell me that folks aren’t quite as receptive to things being spelled out, fairly friendly, that should be common sense. Allow me to quote Voltaire:

On dit quelquefois: “Le sens commun est fort rare.”

For those of you who do not speak French: People sometimes say: “Common sense is quite rare.”
16 April, 2014