Docker Security Analysis

This repository is to contain my work for a Technical Report (ENGR 411) for 1 credit at Concordia University during the Fall 2018 Semester

Context

Currently, a set of Docker containers are deployed on clusters like Compute Canada for the scientific analysis of neuroscience data gathered from research.

What are the risks of running older out of date software images with vulnerabilities? What potential or unknown exploits can negatively affect the research being done by the 1000s of researchers across Canada?

Mandate

I am merely an aide in this endeavor. My role within this project is limited to the duration of my stay. I'll be working to help better understand the current tool set available for container security. This will be used to identify any short comings as well as guide where future research may be required. Analysis will focus on real images being used in the research done by neuroscience.

Goals

• Establish methodologies for a secure environment.
  • Docker platform (--read-only and --network none)
  • Physical separation ( hardware and network settings )
• Produce an analysis of the various tools available (static vs dynamic scanning)
  • How does each type of tool work
  • Intended purpose (application specific)
  • How well do they identify vulnerabilities
  • Degree of usability; are they user friendly (easy to install and use)
  • Are they "production safe"?
• Benchmark the various tools for scanning time.
• Case study: Where do the vulnerabilities come from?

Executive Summary

Security Consideration

If one were to test for the presence of more harmful or dangerous software such as a computer worm or cryptocurrency minner, what options are avaiable to do safe as safely as possible? Usually malware analysis falls into to broad categories, being either a containment strategy or a muting approach. The most common novice idea is creating a virtual machine with no network access, this is a containment style strategy. In contrast, one might want to look at the source code from a reversed engineered binary.

In the context of docker image there were two main options considered for the analysis:

1. Physical network seperation on a protected host (Private LAN)
2. Container isolation (read only with no network)

Ultimately neighter was utilized as the images selected and the tools for the analysis were not related to maleware of their detection.

There are however serval advantages or disadvanteges between the two choices. Container isolation requires little additional knowledge and can be done with minimal hardware, it does make it more difficult to alanysis since most tools produce logs or require network analysis. This is also the disatvange of containers may not work on a read-only filesystem and also pose a risk since the loopback adapter between the host and container are exposed. Physical seperation allows for the malware to run which inheriantly comes with the risk of exposure, any hole in the seperation could be dangerous and is possible with the added setup complexity.

Analysis of Tools

There are three categories of tools:

1. Engine audit
2. Static vulnerability analysis
3. Dynamic vulnerability analysis

Use Case Container Images

For arguement sake these could have been randomly choosen, but these are somehow related to research projects underway within educational institution(s)

• Neuro Data
• Q EEG
• ICA-AROMA
• FSL image processing
• Boutique Example
• HPC Surfer:fsl-centos5
• HPC Surfer:surfer-centos4
• BIDS Example

Benchmark Time

There we can see the almost linear growth in scan times by Anchore as images size increases. In constrat we can see that Vuls scan times remained constant.

Neither method's scan time has any correlation to the number of packages.

Note: Image size based on docker image ls with 1GB = 1000MB

Vulnerability Detection

Note: coverage based on combined total, it is very likely undetected vulnerabilities are not included in this data set.

The graph highlighs excellently how the various tools utilize different database and produce drstically different results. In the case of CentOS, Anchore relies solely on RedHat Security Adviseries whereas Vuls leverages the RedHat CVE database along with OVAL data.

Notes

Can be found in the blog to describe what I've done such that I can produce a 20 page technical report on the subject at the end. There will be more technical details within the blog than the summary. As of 19/11/2018 I have not decide wether my technical report will be publically available...

TO DOs

• [x] Setup EXSI host for new VLAN 192.168.10.X ------- Just set it to DCHP with VGA so i can check if i need
• [x] Give Router ability to route status
• [x] Turn jekyll on for this repo and make a blog // see result here
• [ ] Give Router ability to route AGAIN
• [x] Test the following tool looks promissing // results
• [x] Try out vuls
• [x] Setup web API to catch Anchore updates
• [x] Bench mark anchore and vuls on base test of containers
• [x] improve description of tools
• [ ] detection of manullly installed tools