Just a quick update to tell about a new Docker based on the phocean/msf image.
It provides an image for the BeEF framework for XSS browser exploitation (http://beefproject.com/).
I pushed the image on Docker Hub, so that deploying it is now as easy as:
docker pull phocean/msf
It is an automatic build based on the Github repository.
It means that the image is built by Docker, not by me. For this task, they simply have a read access to the Dockerfile on Github.
Thus, you may place in this image the same level of trust than the one you have in Docker (I cannot interfere in the process and mess with the image).
I say it because I am myself reluctant of installing third-party images. While I prefer to rebuild everything from Dockerfiles, I am fine with automatically built images if I am in a hurry and for non sensitive data.
Just a quick note to say that I am very happy about this Metasploit docker image being useful to some people, according to the feedback I got.
And Lenny was kind enough to integrate it into his Linux distro, REMnux, well known among reversing people. He also came up with very good suggestions and helped me to bring some improvements, so many thanks to him.
Don’t miss reading his blog article on how to use the image in REMnux : “Run Metasploit Framework as a Docker Container Without Installation Pains”.
Stay tuned ;-)
I made a few improvements (at least, I think they are) to the metasploit-frameword Dockerfile :
- A volume from the container /root/.msf4 to $HOME/.msf4, so that you can benefit from your customized prompt, scripts and modules anytime and have persistence on them. In other words, just manage them on your host and they will be readily available to the msf container.
- A volume from the container /tmp/data to the host /tmp/msf, so that you can get access to dump files and stuff like that.
- Tmux window manager tool, so that you can easily navigate between msfconsole, bash and other sessions.
- nmap network scanner, just because sometimes it may be useful (along with its ncat).
- nasm, to support your custom encoders.
It is all up-to-date in its github repo. I will keep adjusting it, if I feel something is missing.
I hope I did it the right way, let me know what you think!
Managing updates and dependencies of a Metasploit installation have definitely been too much trouble and repetitive.
Instead of keeping reproducing boring installation steps every x months, I decided to build a Dockerfile for once.
I chose Debian for its good compromise between features, stability and lightness. I am aware of the Kali Dockerfile, that I could have used as a base. But:
- It is a definitely over-killing image (more than 1 GB) and, at this cost, it does not come with a fully-featured Metasploit (no database connection, for instance).
- I like keeping minimal and controlled stuff. In other words, I like doing things on my own.
So, this Debian-based Metasploit container comes with:
- all dependencies installed,
- automatic updates at startup,
- a connection with the local Postgres database,
- an improved prompt with timestamping and sessions/jobs status.
You can find it on my github.
If you have any trouble or suggestion on how to improve it, please let me know. Enjoy it and go ahead if you want to fork it!
I just put on my github a few dockerfiles for virtual machines that I frequently use to get some quick work done or to temporary share some data.
Here they are:
I used to use VirtualBox guests, but maintaining them was a hassle (updates, snapshots, disk defragmation and shrinking, etc.).
It makes perfect sense to use Docker just for that, and on top of that it consumes much fewer resources. Starting with the disk usage : all these containers along with their image stands below 1 GB!
The fact that I am using Btrfs as the underlying storage driver is not for nothing: compression is extremely efficient on images!
Note that my Dockerfiles have nothing special, you can actually find others on the Internet (and I was inspired by some).
There are a few differences, however:
- I care much about security, so at least I try to make Web services not running as root, even if it is inside a container (the root user is still the same as on the host, so let’s make a compromise as unlikely as possible).
- I like simple things, so I tried to keep everything straightforward and simplified some stuff.
- I don’t like to waste disk space. So when I some Dockerfiles based on Ubuntu, Debian Wheezy, Debian Jessie, Fedora, etc., I try to unify all of them under Debian “stable” (so as of today, Jessie). Why bother with useless images? I chose a versatile and common server distribution and I am trying to stick with it.
While I was playing, I had two things bothering me:
- No quota support: for a Samba sharing guest that I have, I would have liked to implement quotas from within the container. There is no support for that at the moment, and the global limitation by container is not nice (and once you choose a big size, you can’t go backward for existing containers…). I have a dedicated partition for Docker, so, while not perfect, it is okay for now.
- The devicemapper storage driver totally sucks at this time: free space is never reclaimed after you delete images or containers! So the more you use Docker, the more your partition gets full.