security

I do a lot of local development, and since almost everything web-related is supposed to use SSL these days, and since I like to make local match production as closely as possible, I generate a lot of self-signed certificates using OpenSSL (usually using Ansible's openssl_* modules).

This presents a problem, though, since I use Safari. Every time I rebuild an environment using my automation, and generate a new certificate for a domain that's protected with HSTS, I end up getting this fun error page:

Safari Can't Open the Page – Safari can't open the page because Safari can't establish a secure connection to the server 'servername'.

Every few weeks, when some of my automated Jenkins build jobs are running (using Ansible and my Jenkins role on Ansible Galaxy), they hit an error while configuring Jenkins plugins. The error is something like:

I use Ansible Vault to securely store the project's secrets (e.g. API keys, default passwords, private keys, etc.) in the git repository for many of my infrastructure projects. I also like to make sure I cover everything possible in automated tests/CI, using either Jenkins or Travis CI (usually).

But this presents a conundrum: if some of your variables are encrypted with an Ansible Vault secret/passphrase, and that secret should be itself store securely... how can you avoid storing it in your CI system, where you might not be able to guarantee it's security?

The method I usually use for this case is including the Vault-encrypted vars at playbook runtime, using include_vars:

Most of my servers are using TLS certificates to encrypt all traffic over HTTPS. Since Let's Encrypt (and certbot) have taken the world of hosting HTTPS sites by storm (free is awesome!), I've been trying to make sure all my servers use the best settings possible to ensure private connections stay private. This often means setting up things like HSTS, which can make local / non-production test environments harder to manage.

Consider the following:

One of Ansible's strengths is the fact that its 'agentless' architecture uses SSH for control of remote servers. And one classic problem in remote Git administration is authentication; if you're cloning a private Git repository that requires authentication, how can you do this while also protecting your own private SSH key (by not copying it to the remote server)?

As an example, here's a task that clones a private repository to a particular folder:

If you run this task, you'll probably end up with something like:

From time to time, I need to clean off the contents of a hard drive on one of my Macs—most often this is the case prior to selling the mac or giving it to someone else. Instead of just formatting the drive, installing macOS, then handing it off, I want to make sure all the contents I had stored on it are irrecoverably erased (I sometimes work on projects under NDA, and I also like having some semblance of privacy in general).

Disk Utility used to expose this functionality in the UI, which made this a very simple operation. But it seems to have gone missing in recent macOS versions. Luckily, it's still available on the command line (via Terminal.app):

diskutil secureErase freespace 0 "/Volumes/Macintosh HD"

This command would write zeroes on the entire 'Macintosh HD' drive. You can see a list of all the drives connected to your Mac with ls /Volumes. There are a few other common options available (instead of 0) if you run man diskutil and scroll down to the secureErase section. I most commonly use:

I build and rebuild servers quite often, and when I want to jump into the server to check a config setting (when I'm not using Ansible, that is...), I need to log in via SSH. It's best practice to let SSH verify the host key every time you connect to make sure you're not getting MITMed or anything else is going on.

However, any time you rebuild a server from a new image/OS install, the host key should be new, and this will result in the following message the next time you try to log in:

With the rampant speculation there will be a new Raspberry Pi model released next week, I was wondering if the official Raspberry Pi blog might reveal anything of interest; they just posted a Four Years of Pi blog post on the 26th, which highlighted the past four years, and mentioned the excitement surrounding 4th anniversary of Pi sales, coming up on February 29th, 2016.

Glancing at the blog's source, I noticed it looks like a Wordpress blog (using httpie on the cli):

Having set up a few WP sites in the past, I knew there was a simple way to load content by its ID, using a URL in the form:

Drupal.org has an excellent resource page to help you create a static archive of a Drupal site. The page references tools and techniques to take your dynamically-generated Drupal site and turn it into a static HTML site with all the right resources so you can put the site on mothballs.

From time to time, one of Midwestern Mac's hosted sites is no longer updated (e.g. LOLSaints.com), or the event for which the site was created has long since passed (e.g. the 2014 DrupalCamp STL site).

I though I'd document my own workflow for converting typical Drupal 6 and 7 sites to static HTML to be served up on a simple Apache or Nginx web server without PHP, MySQL, or any other special software, since I do a few special things to preserve the original URL alias structure, keep CSS, JS and images in order, and make sure redirections still work properly.

Earlier today, the Drupal Security Team announced SA-CORE-2014-005 - Drupal core - SQL injection, a 'Highly Critical' bug in Drupal 7 core that could result in SQL injection, leading to a whole host of other problems.

While not a regular occurrence, this kind of vulnerability is disclosed from time to time—if not in Drupal core, in some popular contributed module, or in some package you have running on your Internet-connected servers. What's the best way to update your entire infrastructure (all your sites and servers) against a vulnerability like this, and fast? High profile sites could be quickly targeted by criminals, and need to be able to deploy a fix ASAP... and though lower-profile sites may not be immediately targeted, you can bet there will eventually be a malicious bot scanning for vulnerable sites, so these sites need to still apply the fix in a timely manner.

In this blog post, I'll show how I patched all of Midwestern Mac's Drupal 7 sites in less than 5 minutes.