Deploying Secure Containers for Training and Development
Download 4.47 Mb. View original pdf
|
| Cost per hour (in $USD) 0 0 20 40 60 ISLET Virtual Machine Number of training environments 80 100 120 140 160 We did a cost comparison where there ’s a one user per VM alloca- tion on Amazon AWS vs. one host with one container per user. You can see a linear growth with the cost of virtual machines where the cost per hour rises as there are more users. Whereas, in the case of ISLET where there ’s one user per container it grows in steps. Remember that there is one user per training environment and a training environment is either a container or virtual machine. For ISLET you can see that we have step-like growth where you can actually have multiple training environments grow at less cost than it would be if you were using one virtual machine per user. Platform • Designed for Linux (currently), 64-bit only (because of Docker) • Debian family is preferred but will work on others that support Docker. I do nearly all of my testing on Ubuntu so I recommend using that for the best experience. • Update : should work with OSX (boot2docker) and FreeBSD with unofficial docker port Now we are going to talk about deploying and configuring ISLET. Remember that ISLET was designed to be very simple for the admin 24 Deploying Secure Containers for Training and Development and the user. Let ’s look at the requirements. It was designed for the GNU/Linux operating system and that ’s because we heavily rely on Docker Engine which at this time only runs on Linux. Docker also only runs as a 64 bit binary so a 64 bit system is required to use it. I recommend using a Debian family distribution for the training system because it ’s mostly what I’ve tested on. I specifically used Ubuntu the most - it ’s the easiest to work with. Also, recently there was some work done on FreeBSD with an unofficial docker port which utilizes ZFS for the storage backend and jails for isolation. You can probably get ISLET to work with that with little effort. To obtain ISLET you can find it at https://github.com/jonschipp/islet Architecture Maintenance Container Cleanup Account Management Training Image A Container Container Container Training Image B Training Image C ISLET Doc k er Host System User Interface Configuration Account Cleanup The architecture of ISLET is outlined below. You have the host sys- tem which is the machine it ’s running on, then the next largest box shows ISLET ’s components. It has an account manager, cleanup, con- tainer configuration, and user interface. It includes a number of scripts to clean up and maintain the accounts in the containers. For example, there are training events that span 3 days and all containers and user information can automatically be cleaned up after the event ends. The middle and lower box is where ISLET utilizes Docker to launch con- tainers from Docker images. These Docker images contain the pre- packaged tools used for training. 25 Using Containers in Training Configuration & Workflow • Global: configuration file i.e. /etc/islet/islet.conf • Per-image: configuration files per image /etc/islet/*.conf • Creating a new training environment (3 steps) 1. Build Docker image with the software for training 2. Create configuration file and point to new image 3. Place in /etc/islet/ e.g. new_image.conf Creating and deploying new training environments is a simple 3 step process. The first step is to build the Docker image with the soft- ware for training. The second step is to create an ISLET configuration file that points to this new Docker image and the final step is to drop the file in the /etc/islet directory. Once this is complete the next time a user connects to the ISLET software they can immediately utilize that new image. It ’s a very fast and basic 3 step process. Roadmap: • Support other container runtimes (lxc, openvz, jails, etc.) • Auditing, pen testing • Improve build system • Rewrite in Go Lang or Python using container API’s • Export containers and exercises 1) Users can save their work or continue at home like they can with VM training • Scalability testing beyond 1000+ containers, distributed setup The roadmap for ISLET is to support other container runtime such as LXC, Rocket, Jails etc. as well as improve the build system for dif- ferent operating systems and a complete rewrite to take advantage of the Docker API ’s. In addition exploring the realm of horizontal scaling to open the possibility of teaching Massive Open Online Courses 26 Deploying Secure Containers for Training and Development (MOOC) where you have thousands and thousands of users would be incredible. This can be achieved through a distributed architecture. Easy Contributing $ git clone https://github.com/jonschipp/vagrant $ cd vagrant/islet && vagrant up $ ssh -p 2222 demo@127.0.0.1 -o UserKnownHostsFile=/dev/null If you would like to contribute to ISLET it ’s fairly simple, all you have to do is either clone the repository and submit a patch or pull request. In addition a Vagrantfile is available to setup a development environment for ISLET. 27 Using Containers in Training CHAPTER 3 3 Experimentation Problem 2. Experimentation Comparison and research Our next section discusses another use for containers, for develop- ment and research. We want to be able experiment in a particular domain. NSM (Network Security Monitoring) is a field that I ’ve been very interested in and is primarily focused on analyzing the results of tools. There are many NSM tools available on GNU/Linux systems. An issue that arises is there are no standards for how a tool should pro- cess the results of network traffic for forensic investigation. For exam- ple, processing trace file through Httpry or PassiveDNS vs Bro will yield different results for the HTTP and DNS protocols. The former tools will parse application information from a single packet but not across multiple packets where pieces of data can reside and then joined at the receiving host. Bro does this because it keeps state and under- stands the protocols. Bro would have more accurate information then tools parsing on a single packet. Being able to quickly test and experi- ment with many tools and on different inputs is very useful in finding the right tool for the job as well as finding areas for improvement. The OpenNSM (Open Network Security Monitoring Group) has an on going project to package up NSM tools at various versions major and minor releases and make them easily usable. Being able to run a network trace file of attack traffic against 3 versions of one tool and 4 of another for comparison and validation of results in an automated fashion is timely. One can have multiple points of reference and achieve second or third opinions over a sample. The project can also be used to analyze performance and experiment with the tools. There was not an easy way to organize and do this until now. You could have 1000 Debian packages or RPM ’s on a system for the different tools and Deploying Secure Containers for Training and Development. DOI: http://dx.doi.org/10.1016/B978-0-12-804717-0.00003-X © 2016 Elsevier Inc. All rights reserved. versions which would be an organization and dependency nightmare. It seems to be very efficient and better for organization to have them all contained and isolated in an environment where they have their own file system and their own libraries etc. This allows us to use and repro- duce the software without interference. Types of Useful Experimentation 1. Comparison of software and its versions 2. Debugging and development 3. Performance analysis 4. Research One can figure out how these tools work and how to improve them by having all of them ready to go in containers. When you enter the container, you run your tools, analyze the results, and can make changes, repeat, and the results are contained and reproducible. Users no longer need to hunt down, compile, install, and package the tools, we do the hard work ahead of time. Goals Download 4.47 Mb. Share with your friends:
|