Blog

Automating secure server baselines with Puppet

Security is an important part of the continuous deployment process.

A big part of my job here at CloudPassage, in addition to educating people about Halo, is to try and help everyone understand that security is far less effective as an afterthought than if transparently folded in as part of the continuous integration process.

Have you ever run so fast that you lose control, trip yourself up, and fall flat on your face? Not only is it embarrassing but…it hurts quite a bit. The same can be said with regards to deploying applications and servers at a breakneck pace without considering security.

Sure, you’ll get there fast but eventually, you’ll trip up and fall on your face. In this new cloud world, it may not be a single fall but rather a whole slew of falls if all of your cloud servers were deployed in the same fashion. This brings an entirely new meaning to the term fail-fast, doesn’t it?

The house that cloud built

A lot of people use the analogy of building a house on an unstable foundation when discussing the security of software and servers. That analogy is fine when we’re in control of the physical infrastructure but when we’re talking about deploying servers and applications in IaaS (Infrastructure-as-a-Service) cloud environments, the foundation (architecture) is poured and the main floor (hypervisor) is already built. We have the ability to build on the existing architecture (e.g. walls, fixtures, decorations) but cannot alter the underlying structure (e.g. gas, water, load bearing walls).

If we’re stuck building within the constraints of the foundation, why not create easily reproducible server and application images? If we borrow a page from how mobile homes are architected, we can design rugged and highly portable server images that can be reused time and time again.

A mobile home is built to be, well, mobile.

Mobile homes, also known as trailers or caravans (as our friends across the pond call them), have all of the amenities – well, most of the amenities — that one might need to enjoy indoor living. Perhaps their biggest advantage, however, is their ability to be moved from campsite to campsite with as little effort as possible. You can interpret this analogy in a number of different ways. As a server’s ability to be moved between hypervisors, cloud providers or even between public, private and hybrid deployments. Another way to think about it is in terms of cloning servers and spinning up new instances based on the trusted ‘gold standard’ image.

Putting the effort into creating a secure server baseline enables organizations to deploy trusted servers at a moments notice. The bottom line is that we should all be creating servers with a minimal attack surface area exposed to potential attackers or other malicious entities.

Check yourself, before you wreck yourself

This is certainly not a new concept. The basic strategies of attack surface reduction are to reduce the amount of code running, reduce entry points available to untrusted users, and eliminate services requested by relatively few users (source: http://en.wikipedia.org/wiki/Attack_surface). Another way to think about it is to consider why football players wear a helmet, shoulder pads, gloves, shoes, thigh pads, knee pads, neck rolls, elbow pads, mouth guards, hip pads, tailbone pads, rib pads, and other equipment? That’s right…to reduce their attack surface area. A football player knows that if they don’t wear at least the basic padding, they leave themselves open to attack from other players and even exploitation (e.g. targeting a weak knee, exposed hand or unprotected thigh muscle).

Here are 5 easy steps to help organizations start on their creation of a secure server baseline:

  1. Disable unnecessary services
  2. Remove unneeded packages
  3. Restrict access to sensitive files & directories
  4. Remove insecure/default configurations
  5. Allow administrative access ONLY from trusted servers/clients

You might notice that the above suggestions are all configuration-related items and not related to the installation of security or other mitigating tools. That’s because I believe that systems administrators and DevOps teams need to get back to protecting their servers by first eliminating the potential avenues for exploitation or compromise before even starting to think about third-party tools to protect their servers. That’s not to say that security tools aren’t required. All I’m saying is that you’ll have a far easier time securing your servers if you eliminate services and configurations that don’t explicitly map to the operational requirements of your server.

Related Posts