Tag: open source

Reset the Net Gotchas
All my domains will not be HTTPS by the end of 2014.

Sorry. It’s one of those things that just isn’t (at this time) something I can pull off. If I only had one domain and everything was subs, I could get one wildcard subdomain cert and be done with it. But with the number of domains I have it’s not feasible. Which brings me to what I think one of the major issues with our desire to protect the net is… But let’s step back!

Yesterday, as you may have noticed, was Reset The Net day. It was a call to action, much like we did when we went dark one day.

Now on this site, I’m using the Internet Cat Signal, which cleverly updates itself as I need to alert people to crap like this. The tldr is that the NSA is spying on us. I leave that plugin on all the time, it fires up when there’s something people need to know. It doesn’t slow down my site, and I hope it brings awareness to folks who otherwise have no idea about this stuff. About 75% of my traffic on this server can be described as people who don’t know about any of this.

What have I done for this? The recommendations are to use HTTPS, HSTS, and PFS. Since HeartBleed, I enabled PFS. This is a non-logical sort of thing to do, in that few people seem to explain how to do it. On my box, which uses WHM, it was pretty easy. In my WHM Panel, I went to Apache Configuration -> Global Configuration -> SSL Cipher Suite. Then I picked the PCI Recommended suite, not the default, and rebuilt the configuration. Then I went to Apache Configuration -> Include Editor -> Pre Main Include and, for all builds of Apache, added this:
```
# Enabling PFS
SSLHonorCipherOrder On
SSLProtocol All -SSLv2
# CVE-2011-3389
SetEnvIf User-Agent &quot;.*MSIE.*&quot; nokeepalive ssl-unclean-shutdown
```
The last bit lets me support any IE 6 users who visit my store. But as I said, I don’t have SSL on for all my domains. So what are my HTTPS issues?

The cost is insane. Let’s look at wildcard ssl, which is what you want for *.example.com situations. It’s pretty much $100 a year. That’s not too bad until you factor in how many domains I have on this server. Six family members, six of my own sites (including short domains like helf.us). So that’s either $1200 a year, which is obscene, or $145 a year at the cheapest I could find, and that’s for the simple green lock and no wildcards. For the big green bar, it’s back to around $1000 a year. Oh and I forgot one of my domains, so that’s $164 and $1047. Now I could totally afford the $164 a year, it’s doable with my ad revenue (which pretty much breaks me even at the end of a year) but….

It’s slower. Look, I get it how it’s important to be secure, but right now, the nginx proxy setup I’m using doesn’t work on HTTPS. That sets me back some since using it has sped up my site considerably. I know how to (and have) set Google Pagespeed to play nicely with HTTPS, so I’d be back to where I was before. This isn’t bad, it’s just not a great experience. Right now I have a secure login, secure email, a fully secure store, and ssh/sftp only, so the only place your data could get ‘sniped’ is when you’re leaving a public comment on my public site, which makes me less worried than I might be. Even my git repo is secured.

Also it’s hard. And no, that’s not an excuse. PFS (Perfect Forward Secrecy) isn’t easy to add to your servers, and it’s way outside the realm of what most people can do. Hell, it’s outside the realm of what I’m comfortable doing. It took until my server had the specs for OpenSSL that will support PFS for me to do it. The point is, this part has to be done by the webhost for most people, and that is a big issue. It’s not easy or fast to upgrade servers, and it’s far, far more persnickety than updating WordPress. It’s complex, and you have to think about everyone on the server. Again, not an excuse, just a caution that it takes a while to finish up.

Speaking of WordPress, multisite isn’t great at it. In fact, it’s less great than normal WP. I have two sites with SSL right now, ipstenu.org and store.halfelf.org. Ipstenu is only SSL on the back end, but even with that, there are inconsistencies. First, all the links are HTTPS, so when I click on “My Sites” the link to NON HTTPS sites are using HTTPS, which doesn’t work. Also if I made a new domain, it defaults to HTTP and not HTTPS. So I have to edit that manually. This is annoying, thought not insurmountable, and I know it’s something being worked on.

In the end, the absolute biggest reason I’m not switching to HTTPS is that the only person who needs secure communication are the people logging in or the people buying things, and I’ve taken care of that. For the rest of you, know that my store is secure, my logins are secure, and if you’re commenting on the site, for god’s sack, don’t post anything you don’t want people to know!

I’m sure in a few years if not months all this will change, but this is where I am today. The racket with SSL certs costing that much needs an easier solution, and then the rest will fall into place.
6 June, 2014
Nginx Proxy
Will you all quit nagging me now? I kid. Very few of you actually got on my case about nginx.

Nginx is a HTTP server and reverse proxy, which is a really fancy way of saying “It runs websites.” Most people still use Apache, and Nginx is perceived as being faster with how it serves static files. My issues with it are twofold:
1. I don’t just run WordPress here
2. I need my .htaccess for those other things
Yes, there are older webapps that don’t support nginx. But at the same time, what if I could have my cake and eat it too? What if I could use nginx to serve up the static files and apache for the rest? That would mean I would be able to install nginx on my CentOS 6 box as a reverse proxy.

It’s actually not that hard, but let me explain why this is a good idea. Apache takes up a lot of server memory, which nginx does not. Nginx is awesome at static files, but not the best at dynamic, and you’ll need a module like php-fpm for that. But… One of the sites on this server has a gallery that takes up 50% of the webspace of all accounts on the server. Stop and ponder that for a moment. While I do have server-side caching (memcached and ZendOptimizerPlus) running, adding in nginx up front means my images would be served faster.

Speaking of faster, by putting nginx in front, it makes it so only true http requests get passed on, which protects against attacks like DDOS and other brute-force attacks that aren’t nginx-related. I still have (and use) mod security, of course, as well as ConfigServer Firewall. More on that later. Let’s get this sucker installed!
```
yum install nginx
```
Install Nginx

Oh, sorry? Was that supposed to be harder? It’s not. This is pretty much the simple part.

Install nginxCP

Normally my next step would be to configure nginx (see Ben Tasker’s CentOS: Using NGinx to serve static files and Apache for dynamic for details) and apache. Unlike Ben, I have WHM on my server, which means when I build apache it’s with Easy Apache, which means any edits I make to my httpd.conf file get lost when I rebuild, which I do for when I need to upgrade PHP. It’s not super rare, nor is it super common. Still, I don’t really want to mess with it more than I have to.

So I took the time to research my options, and came up with nginxCP and cpnginx. The real difference is CPNginx comes with a service to help you (yes, it’s pay). Since I’m an Open Source woman, I did nginxCP. The cost ($55 a year) for cpnginx was not a deal breaker, since they had a trial.

The install directions are quick:
```
cd /usr/local/src
wget http://nginxcp.com/latest/nginxadmin.tar 
tar xf nginxadmin.tar
cd publicnginx
./nginxinstaller install 
```
A reboot of the httpd service and now all my non-SLL sites are served up on nginx!

Configure nginxCP and Apache

I love when I can just slap it on and go, but I run ConfigServer Firewall to save my ass from DDoS, so I knew I’d be getting a slew of ‘Suspicious process’ alerts from my firewall once I added in a new feature. The fix is to add this to csf.pignore:
```
# nginxCP
exe:/usr/local/sbin/nginx
```
That was all I needed! Emails, by the way, from CSF have plummeted. I was worried I wasn’t getting any emails or logs from my servers for a while. But then I re-checked my logs to see what was happening. See I used to get a lot of emails like this:
```
Failures: 5 (mod_security)
Interval: 300 seconds
Blocked:  Permanent Block
```
They stopped, because nginx didn’t let them get to Apache and CSF. Mind. Blown.

Results?

Everything worked out of the gate, so I sat and watched my server load. Per-expected, since an httpd restart flushes my PageSpeed cache, the load spiked at .52 (this is still low). Then it dropped to .31 and then to .20, and it pretty much stuck around the .10 area. Memory, however, dropped for a while. That’s good! Slowly as things settled in, I made sure to post something new on a news/fan site, and watched things not go up very much.

Nothing is weirder than watching your load drop to 0. The 93% memory is not a bad thing. On this server setup, I want to see somewhere around that at any point in time. The first time I saw it, though, I flipped out and my friend Benny (who is a cPanel goddess) calmed me down and explained how the ‘storm’ server worked. Real memory usage is about 40%, when load is above .40.

The big spike was installing. The normal spikes at 14:00 and 14:30 were posts made in WordPress before nginx was installed. The ones at 16:00 and just after 17:00 are WP posts as well. That’s a nice change.

Problems?

SSL. Wouldn’t you know? Now you can use nginx as an SSL revese proxy, but it would obviate my cpanel add in, which right now seems a little smarter for long term sustainability than doing it 100% manually. The less I have to remember when I’m rebuilding apache, after all, the better.

Still. Part of why I’m looking at nginx seriously is to speed up my SSL site which gets less caching by it’s nature. Weighing the pros and cons, I decided to stick with nginxCP as my theory is that by speeding up the rest, SSL will in turn be faster since there’s less memory being sucked up. Oh and I did check cpnginx about SSL, and they don’t support it either. That’s alright for now. I’m sure the future will change.
28 May, 2014
It’s Not Beer It’s Homebrew
If you’re a rookie getting your hands around all this webdev stuff, and you’re on a Mac, you may have already come to a rude awakening when you find out that, for reasons unknown to man, Mac decided we didn’t need wget.

That’s how I was introduced to Homebrew.

I love wget, because it’s a super simple and fast way to download something. wget http://wordpress.org/latest.zip is the fastest way for me to download a zip, and I use it regularly. So one day, when deving code, I realized I needed a plugin. I went to wget it and got a horrible message.

-bash: wget: command not found

After searching around, I was about to download, compile, and install wget when a comment on StackExchange said “Try Homebrew.”

Everyone’s dersive comments aside about how ‘real’ programers don’t install packages (seriously people), I said to myself “Ipstenovich,” I said. Yes, I call myself that sometimes. “You use yum to install packages on your server because it’s easier and safer. Why wouldn’t you use the same thing here?” Over to http://brew.sh/ I went and stared at the installer command like a fish.
```
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
```
The call ‘ruby -e’ means “run Ruby and tell it to call this URL externally…” And then it clearly was calling github for an installer. It’s tough to decide to trust a new program but after some serious banging around, I trust the Homebrew.

Once installed, which doesn’t take long at all, I ran the check brew doctor which told me a couple things:
1. I’d installed SVN and Git on my own (truth) so I needed to change my .profile (with directions how)
2. I had a half-baked attempt at installing ImageMagick that needed cleaning (with suggestions how)
3. I had MacPorts still in my /opt/ folder, that needed removing (with directions how)
4. I needed to install xcode command line tools (with directions how)
5. xQuartz was out of date
6. I hadn’t updated my brew list in a bajillion years
Most people won’t have that last one. I did once have an older install of Homebrew that I’d never really cleaned up. However the other ones took me about an hour to clean up properly, because I was watching Fargo (the movie) at the time. Once installed and set up, I was able to install wget and upgrade it. Ditto OpenSSL (because Heartbleed, you know). It’s great.

Homebrew is pre-1.0 which means there can and will be issues. Don’t panic, for most of what anyone needs, this is perfect. It’s also good at upgrading when you need to:

The little beer mug is awesome.

One of the nice things about Homebrew is that it doesn’t use (nor advocate the use of) sudo. This is really good for security and makes me feel much safer.

Go forth, rookies, and install Homebrew! It will make your development much happier!
21 May, 2014
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
Very Voluminous Vagrants
I finally sat down and installed Vagrant.

Specifically I installed Varying Vagrant Vagrants. I read, like I do, and the directions were thankfully pretty clear for a change about what the prerequisites were, and I found myself with an install of Vagrant up and running within an hour. At this point I joked “Now what?”

Vagrant is yet another tool you can use to create test websites. It’s a super-powerful command line tool one might use instead of DesktopServer or MAMP. Now, I love MAMP. While I find DesktopServer more ‘flexible’ in that I can spin up a client’s site really fast to check it, MAMP is even faster to boot when I just want to see one site and test a plugin on it, in part because I use MAMP No Password and run it on port 80 (which lets me use Multisite).

But… Sometimes when I want to test, I want to test different configurations at once. Like I want to test on current (3.8.1) and trunk, and I probably want a Multisite Network as well. But Vagrant is way more than just a lot of different environments in one go. I mean, if that was all it was, I could edit my hosts file and make a couple extra sites in MAMP or DesktopServer and be done.

What do you get?

You get a lot with VVV, and if all that seems weird to you, it’s okay. The more I work on servers, the more I see a varity of weird setups and the more I want to mess with them for testing. This isn’t to say VVV is perfect. You can’t switch (easily) between PHP 5.2 and 5.3 and 5.4. There’s a whole discussion ticket on the matter.

Vagrant makes multiple servers. Not PHP/Apache instances. Servers. They’re virtual, but let’s be honest, so is the server this site is running on. That means I can mess with the server, install extra features if I need to test a clash with PHP version or add ons or whatever, I can do so without blowing up my laptop (or a real server) pretty quickly. That means my plugins test site (on a live server) may not be needed anymore, which led me to the first actual thing I had to do with Vagrant: Make my own sites.

My own sites!

You get five ‘default’ sites when you use VVV:
- http://local.wordpress.dev for WordPress stable (/www/wordpress-default)
- http://local.wordpress-trunk.dev for WordPress trunk (/www/wordpress-trunk)
- http://src.wordpress-develop.dev for trunk WordPress development files (/www/wordpress-developer/src)
- http://build.wordpress-develop.dev for a Grunt build of those development files (/www/wordpress-developer/build)
That’s four, I know. The fifth is “vvv.dev” which lists the other four sites. That’s pretty much what most of us need when testing. A local site, one on trunk, one using src, and one with grunt for those CSS/JS things.

I needed more:
- http://multisite.dev Subdomain Multisite (/wordpress-musubdomain)
- http://local.multisite.dev Multisite subsite foo (/wordpress-musubdomain)
- http://bar.multisite.dev Multisite subsite bar (/wordpress-musubdomain)
- http://baz.multisite.dev Multisite subsite baz (/wordpress-musubdomain)
- http://folder.multisite.dev Subfolder Multisite (/wordpress-mufolder)
- http://local.plugins.dev Plugins tests (/wordpress-plugins)
Those all run stable. I though about naming them wordpress-something, but I needed the subdomains and it was easier to just make multisite.dev for that. I know what it is, and this is for me first. The way you do this is with Auto Site Setups, where Vagrant looks in your www folder and if it finds more folders with the right files, will build sites! Natually that means I made a little Github repo for this called VVV ASS. Because you’ve met me before, right?

What do you do with it?

Test all the things, really. Bang on plugins and code that isn’t right, make patches, and have a generally clean environment to play with. It’s also good for building on (core or plugins or themes).

I’ve been struggling with PHP Unit Tests, as well. I understand them, but I don’t really grok them yet. While I dig the idea of unit tests, creating them is a little complicated to me. Suffice to say, I know WordPress on push day wants to unit test all the things, so I should get used to this.
1. In terminal, navigate to your clone of the VVV repo.
2. Run vagrant ssh to connect to the virtual machine.
3. Run cd /srv/www/wordpress-develop and go into the folder.
4. Run phpunit
And there you go. What did all that do? A lot. Check out the Core Handbook on Automated Testing. Beyond that, I cannot tell you. Yet. Expect more on that later when I’ve gotten someone to explain it better.

Do I have to use VVV?

Nope! There’s VIP Quickstart, by Automattic (yes, that Automattic) which lets you bring up a WordPress.com-esque site. And there’s WP Vagrant which gives you more testing environments, so when you want to blow up core on PHP 5.2, you can do it easy as another vagrant up.

Am I sold?

Developer Ipstenu is sold. User Ipstenu still likes MAMP best. “Yes, I’ll fix your site” Ipstenu likes DesktopServer. Each has their own place. I’m so comfortable in CLI now, it’s more natural to use MAMP and VVV. DesktopServer comes in to play for me when I need to spin up a site specifically to test an existing site someone else broke.
4 April, 2014