Along with the new version of Docker Engine which came out recently there were some handy updates to Docker Compose. Back when I started looking at using compose and Docker containers for pen testing one of the drawbacks was that there was no great way to define a shared area for all the containers to save their data to as part of the compose setup.
One of the things I’ve been interested to look at with docker is the network setup. By default when you bring up a docker container you get a network interface with a private IP address which can communicate with other containers on that network and can make outbound connections to the wider world, but isn’t visible to the wider network.
So Docker 1.10 has just landed and with it a number of great new security enhancements. One of the main ones is the enabling of User Namespaces. This adds an extra level of protection as processes running in a container as root will not be running as root on the host Operating System, which makes it harder for a rogue process to break out of the container.
One of the perenial problems of being an infrequent blogger is of course, you forget exactly how you used to do things…
Following on from my last post on Using Docker for Security Testing, I thought it would be interesting to see if we can set-up an even more automated environment by using Docker Compose. Docker Compose is a means of creating a linked set of containers, which you can configure to be started up together, so useful where you want to make use of multiple systems at the same time.
Following on from my previous post about Docker, I’ve been giving some thoughts to how I could make use of this in my day-to-day work of security testing.
I’ve been spending some time this weekend looking more at docker and where I think it could be useful for my workflows, and along the way I’ve learned a couple of things which I didn’t know, so I thought it would be worth recording them, in case they’re useful to others. None of this is particularly earth shattering but hey could save someone some time :)
I realised the other day that I’ve been doing public speaking for quite a while now (started with doing internal training courses back in the 90’s, and graduated on to doing external speaking at seminars and conferences about 10 years back).
One of the perennial problems in security is the lack of hard data, so it’s been good to see over the last couple of years a growing number of reports coming out which seek to shed a bit more light on what’s happening in InfoSec. One of the more prominent of these reports is the Verizon Data Breach Investigation report and I always read it as it has some interesting insights into what’s happening in areas that I don’t get too much exposure too.
Last week I did a presentation for the Securi-Tay Conference. The title of the talk was “Security and ‘modern’ software development”, and the main theme of the talk was looking at library repositories like Rubygems, npm and NuGet and how an attacker could try and place malicous content into those locations.
