So it’s Verizon DBIR time of year again and as with last year there seems to be a little bit of debate around the Top 10 exploited CVEs. My twitter handle got copied in via some tweets from last year, so I thought I’d take the opportunity of providing a tester’s perspective on this. A more detailed and comprehensive look at this issue is available on the OSVDB Blog.
One of the things about Docker is that whilst it provides you with a sane set of defaults from a security persective, it’s still pretty easy to quickly reduce the level of security/isolation provided if you deviate from those defaults without understanding the consequences.
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).
