Patching the Heartbleed OpenSSL Vulnerability with Puppet Enterprise

Patch management can be quick and easy with Puppet Enterprise. In cases like the recent Heartbleed vulnerability, time is of the essence: As system administrators, we need to quickly and efficiently deploy patches for these security vulnerabilities, and just as important, be able to show our management team that we’ve done it.

In the video below, I show how I used tools and features in Puppet Enterprise to discover which machines were running an OS affected by a vulnerable version of OpenSSL. (Note that Puppet Enterprise itself does not need to be patched.) Based on the data returned to me through the live management features in the console, I was able to see the current state of those machines and identify which needed a patch.

After identifying the patch I needed to remediate the security vulnerability in OpenSSL, I was able to create some simple Puppet code using a package resource to enforce the safe version. I used this site for validating the patched version of OpenSSL for my CentOS boxes:
http://lists.centos.org/pipermail/centos-announce/2014-April/020249.html

I wrapped the code in a Puppet module, which I was then able to distribute to the rest of the machines I had identified as running the affected OS and packages. Here’s what that code looked like when I was done:

class openssl_update {
  package { 'openssl':
   # ensure => '1.0.1e-15.el6',
    ensure  => '1.0.1e-16.el6_5.7',
  }
}

That’s it — just six lines of code! The commented-out line of code is the old version of OpenSSL that is currently installed. I’m keeping this around in the event that I want to rollback.

Before distributing the module, I used the console to create a group, to which I added all affected nodes I wanted to update. Then it’s as easy as running Puppet! To do that, I used live management again to run Puppet on each of the machines in the group. (Orchestrating a change like this is one of the big benefits to running Puppet Enterprise.)

In just a few minutes, I had a report based on the run status for each of the machines, and I could also audit those packages again to make sure they were the latest, safe version. It's important to note here that we'll still need to restart any affected services, or better yet just reboot the box for the changes to take effect. We can easily accomplish all of these by building them into our Puppet code.

It takes about 5 to 10 minutes to identify all machines affected, create code around deploying the patches, and then audit the results, depending of course on the size of your deployment.

Puppet Labs recommends regenerating certificates for both masters and agents since the agent’s private key could have been compromised. For more information on this process, please see our blog post, Heartbleed Update: Regeneration Still the Safest Path.

For more detail, watch this 8-minute video. Please feel free to ask questions or share your experiences in the comments section below.

Spencer Seebald is a technical solutions engineer at Puppet Labs.

##Learn More

Puppet sites use proprietary and third-party cookies. By using our sites, you agree to our cookie policy.