“It worked in Dev, it works in Dev. Don’t know why it’s not working in production. It’s an Ops problem now.”
Many of us have lived through a failed production deployment of an application at least once. And unfortunately for some, the memories from such failed deployments can haunt for the rest of our lives. But thanks to a relatively old technology (but gaining traction recently), such things could quickly become a thing of the past. Welcome containerization—or as most people know it—Docker containers.
Why Docker?
Developers have long sought a system with which they could build a piece of software once, package it, and then run it anywhere—without having to worry about dependencies, library versions, host OS, underlying hardware etc. Docker containers are the perfect solution.
And on the other hand, Operations folks have sought a system for setting up dev/lab environments in a consistent and repeatable way (ideally in a scripted fashion) in an environment that closely resembles the production environment. So when the code gets deployed into production, they can be assured it won’t blow up; and even if it does, developers can quickly reproduce the issue and issue patches. Docker containers address that need as well.
But that’s not all. Docker containers are built from stripped down versions of the base operating systems, and contain only a bare minimum of system libraries and supporting programs. That means that they are a lot more efficient than virtual machines (VMs), without the overhead associated with VMs. Therefore, it’s possible to pack more containers than virtual machines on the same physical host.
Plus, Docker supports UnionFS file system, which enables the combination of multiple file systems into a single file system. So remember that dream of a LAMP base image you always wanted to build? Yeah, that’s a breeze now.
Given the benefits of using Docker, it’s easy to see why developers are flocking towards “dockerizing” their applications. But before they get too far ahead, there is one pesky little thing to take care of—security.
Securing Docker
By leveraging some kernel-level features such as namespaces and cgroups, Docker containers already provide some basic level of security right out the box. But that’s not sufficient. Users need to take additional steps to lock down the kernel, reduce the attack surface of the docker daemon and harden the container configuration to have a truly secure setup.
How can Tenable help?
Along with Nessus 6.6, Tenable released several updates in the Nessus plugin feed to audit Docker host(s) and containers. Here are some simple steps you can take to secure Docker installs.
Docker service detection and container enumeration
The first step towards securing Docker installs is to actually find them in your organization. Tenable recently released a Docker Service Detection plugin (#89110), which detects Docker installs and, if available, enumerates all the active containers on that host. Here’s a sample result:
Patch Docker host vulnerabilities
Docker containers share the kernel with the host OS, which means that kernel-level vulnerabilities now gain a whole new level of significance on Docker hosts.
It is therefore important to run a comprehensive credentialed patch audit against Docker hosts to ensure they are up to date with the latest patches and aren’t missing any security fixes. Nessus supports local security checks for a variety of Linux distributions. So regardless of which base OS you pick for a Docker host, there is a good chance Nessus already has support for it.
CIS audit for Docker
The next step is to harden the Docker host itself. For example, have strict file and directory permissions, limit the number of services running other than the docker daemon, limit user access to the docker daemon, keep an eye on container sprawl, etc.
CIS released an excellent benchmark for Docker v1.6+, which covers everything I just referred to and a lot more. Tenable added support for a CIS Docker v1.6 audit in Nessus 6.6. Here’s a sample result:
Audit Docker containers
Nessus can audit the configuration of the Docker containers as well. Just select an audit and run a scan against the Docker host, and Nessus will automatically identify applicable containers and audit the configuration of those containers. For example if you ran a scan with application audit such as Apache or MySQL, Nessus will automatically identify containers running Apache or MySQL and only audit those.
Keep in mind, though, that containers are stripped down versions of the base OS. So if you ran a scan against a container with an audit that was meant for the complete base OS, you may find some results that are not applicable. For example, files or binaries that don’t exist. So we encourage you to customize your audits for Docker containers and strip out irrelevant pieces.
Once the scan finishes, Nessus will list containers under the Hosts tab in a special format: container-name.docker.container. Here’s an example:
Wrap-up
In our world, new technologies come and go all the time. Yesterday it was virtualization, today it is containerization, and tomorrow it will be something else. Tenable will adapt, evolve and align with your needs as new technologies come online. Support for auditing Docker is just one more new technology that we have added to your arsenal.