Metasploitable3 Ubuntu Docker Image (Feedback, not an issue)

[heywoodlh]

Issue Description

First off, thank you so much for making Metasploitable3 open source and so easy to re-use. Thank you thank you thank you thank you.

This isn't really an issue, rather a request for feedback/direction and an attempt to find if there is any interest in this. Also, this is just for the Ubuntu implementation of Metasploitable3 not Windows.

In preparation for a security conference I'm going to be creating some content for I'm going to be creating a Docker image and reusing the Metasploitable3 assets. I spent most of today writing the Dockerfile, testing, etc. The Dockerfile and copied assets are here if you'd like to look: https://github.com/heywoodlh/dockerfiles/tree/master/metasploitable3

(So far most of what I have ported is working, but there is a lot that isn't working or hasn't been added yet but I plan on fixing it by the time I need to use it.)

Anyway, what I need direction on is the following:

• First, would anyone even be interested in this? Looks like there may be some interest per https://github.com/rapid7/metasploitable3/issues/30
• Is it alright if I use the name Metasploitable3 or should I brand it as something else even though I'm re-using the same assets and trying to replicate the same setup? I've copied the LICENSE to that particular directory in my repository, so I'm hoping that meets the requirements of the original license.
• If the image works well enough would there be any interest in adding the Dockerfile to the official repository rather than my personal Dockerfiles repo?
• Any other feedback, criticisms, good-to-know things I should be aware of?

Thanks in advance for any feedback. I'm hoping to have the majority of the image completed by this weekend.

[deargle]

Could a dockerfile just run the chef recipes? That way it could still be one ground truth-- the recipes in this repo -- and any dockerfile could just fetch and run those.

On Mon, Jul 26, 2021, 10:09 PM Spencer Heywood @.***> wrote:

Issue Description

First off, thank you so much for making Metasploitable3 open source and so easy to re-use. Thank you thank you thank you thank you.

This isn't really an issue, rather a request for feedback/direction and an attempt to find if there is any interest in this. Also, this is just for the Ubuntu implementation of Metasploitable3 not Windows.

In preparation for a security conference I'm going to be creating some content for I'm going to be creating a Docker image and reusing the Metasploitable3 assets. I spent most of today writing the Dockerfile, testing, etc. The Dockerfile and copied assets are here if you'd like to look: https://github.com/heywoodlh/dockerfiles/tree/master/metasploitable3

(So far most of what I have ported is working, but there is a lot that isn't working or hasn't been added yet but I plan on fixing it by the time I need to use it.)

Anyway, what I need direction on is the following:

• First, would anyone even be interested in this? Looks like there may be some interest per #30 https://github.com/rapid7/metasploitable3/issues/30
• Is it alright if I use the name Metasploitable3 or should I brand it as something else even though I'm re-using the same assets and trying to replicate the same setup? [I've copied the LICENSE to that particular directory in my repository, so hopefully that meets
• If the image works well enough would there be any interest in adding the Dockerfile to the official repository rather than my personal Dockerfiles repo?
• Any other feedback, criticisms, good-to-know things I should be aware of?

Thanks in advance for any feedback. I'm hoping to have the majority of the image completed by this weekend.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rapid7/metasploitable3/issues/545, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAI6Y7O3UHLTEGWSJ55V3ETTZYWO3ANCNFSM5BBMJYDQ .

[heywoodlh]

I don't know Chef well enough so others may have feedback. If I'm given the commands to install Chef in Ubuntu 14.04 and run the Chef recipes in the container it would be pretty trivial for me to write a Dockerfile that runs the recipes against itself when building the image.

For now, I don't really mind porting everything to a Dockerfile for readability's sake because I never use Chef or Ruby. I've been using the recipes to figure out how most of it is setup but it has been a learning experience for me to learn how Chef does things.

[deargle]

Yeah, chef is beastly. I've worked on the chef side of the Ubuntu image before though. There's two paths to running the chef recipes -- either the packer build process, or the vagrant file. Both have chef "provisioners." iirc, they use chef-solo or chef-zero. They need the recipes to be mounted as a file share, and then a list of recipes to run. The vagrantfile in the dev directory has the list, and so does the packerfile.

The main downside I can think of to porting to regular bash (docker) commands is future-proofing. Sometimes the recipes change. Also, one big plus about chef is that it's idempotent -- during development, a chef recipe can be run again and again, and it should be fine. Because chef recipes describe a desired state -- not a series of commands. I use the vagrant flow for development, starting from one of peru's Ubuntu vagrant images.

And another minor benefit -- in theory, chef recipes can be picked-and-chosen. I don't think this repo's are quite set up that way. But that wouldn't be elegantly conceptually possible with docker's build steps. I use some of the recipes for a security class I teach. And different run lists can be specified to get different kinds of images.

On Mon, Jul 26, 2021, 10:21 PM Spencer Heywood @.***> wrote:

I don't know Chef well enough so others may have feedback. If I'm given the commands to install Chef in Ubuntu 14.04 and run the Chef recipes in the container it would be pretty trivial for me to write a Dockerfile that runs the recipes against itself when building the image.

For now, I don't really mind porting everything to a Dockerfile for readability's sake because I never use Chef or Ruby. I've been using the recipes to figure out how most of it is setup but it has been a learning experience for me to learn how Chef does things.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rapid7/metasploitable3/issues/545#issuecomment-887196808, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAI6Y7L3NDUESNLKSC2P43LTZYX53ANCNFSM5BBMJYDQ .

[heywoodlh]

Sure, the benefits of using Chef to bootstrap everything would be perfect.

I have zero experience with Chef (I'm a big Ansible user myself), though, and just trying to get the Chef client in a usable state was super painful for me on my Mac (it was complaining about setting up certs, keys, etc. -- which is annoying when I'm just running against localhost). But I'm also a complete noob with Chef and probably won't use it myself outside of this as Ansible fills that need for me.

So if you give me some snippets on how to install Chef on a fresh install of Ubuntu and run some of the Metasploitable recipes against localhost that would be awesome! There are probably certain recipes that won't make sense since it's a container and not a full-on VM but we can figure that out as we go.

[deargle]

I don't know the snippets, but I'm pretty sure the vagrant logs spit out with good verbosity what it does with looking for and installing the chef-solo and copying the recipes to /tmp something or other. That's where I'd look to replicate -- the vagrant logs on first provision. You could even comment out all the recipes in the dev run_list and just get it to install the chef-solo client, for fast testing. (Assuming you're somewhat familiar with vagrant.)

You mention chef keys -- that's not chef-solo, and I made the same mistake in not realizing that. Chef-proper infrastructure is massive client-server. Chef-solo is standalone. Vagrant (and packer) provisioners only use the standalone.

On Mon, Jul 26, 2021, 10:47 PM Spencer Heywood @.***> wrote:

Sure, the benefits of using Chef to bootstrap everything would be perfect.

I have zero experience with Chef (I'm a big Ansible user myself), though, and just trying to get the Chef client in a usable state was super painful for me on my Mac (it was complaining about setting up certs, keys, etc. -- which is annoying when I'm just running against localhost). But I'm also a complete noob with Chef and probably won't use it myself outside of this as Ansible fills that need for me.

So if you give me some snippets on how to install Chef on a fresh install of Ubuntu and run some of the Metasploitable recipes against localhost that would be awesome! There are probably certain recipes that won't make sense since it's a container and not a full-on VM but we can figure that out as we go.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rapid7/metasploitable3/issues/545#issuecomment-887205387, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAI6Y7NB7JFJ3A3R463J52TTZY26BANCNFSM5BBMJYDQ .

[heywoodlh]

The clarification is super helpful, thank you. I will see if I can get a POC working in a Dockerfile tomorrow.

[heywoodlh]

So it seems that Ubuntu 14.04's repositories use version of Chef (11.8.2) that isn't compatible with the Metasploitable3 cookbooks:

Chef Client failed. 0 resources updated
[2021-07-27T18:18:13+00:00] ERROR: undefined method `source_url' for #<Chef::Cookbook::Metadata:0x00000001fc7a28>
[2021-07-27T18:18:13+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

I can download a newer version for Ubuntu 14.04 x86_64 here: Download Infra Client

It seems that using Chef 12 + fixes the compatibility issues.

Unfortunately, due to Chef's licensing, I won't be able to store the Chef deb in a repository anywhere, which will require anyone who wants to build the Docker image using that deb to download the deb manually beforehand. This will restrict me from doing automated builds. This is further limiting by the fact that Chef doesn't supply any packaging that I could find for other architectures that can run on Ubuntu 14.04 so I will only be able to build a Docker image that runs on an x86_64 container.

Some help:

• I would love to know if there any Chef PPAs, or packaging that provides a newer version of Chef, is compatible with Ubuntu 14.04 and is cross-architecture?

[deargle]

What version does the vagrant chef provisioner download for ub 14.04? I think it fetches it via wget IIRC. Looking for the source code for the provisioner rn. There's also an accept-license parameter that a user needs to set in the vagrantfile in order to be able to build -- that would solve the license issue, I think.

Here: https://github.com/rapid7/metasploitable3/blob/98eef21cf9ab16dfce5af356a95d00f6a88e3cbf/chef/dev/ub1404/Vagrantfile#L17-L43

On Tue, Jul 27, 2021 at 12:30 PM Spencer Heywood @.***> wrote:

So it seems that Ubuntu 14.04's repositories use version of Chef (11.8.2) that isn't compatible with the Metasploitable3 cookbooks:

Chef Client failed. 0 resources updated [2021-07-27T18:18:13+00:00] ERROR: undefined method `source_url' for #[2021-07-27T18:18:13+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

I can download a newer version for Ubuntu 14.04 x86_64 here: Download Infra Client https://downloads.chef.io/tools/download/infra-client?download=https://packages.chef.io/files/stable/chef/14.13.11/ubuntu/14.04/chef_14.13.11-1_amd64.deb&os=Ubuntu%20Linux%2014.04&version=14.13.11

It seems that using Chef 12 + fixes the compatibility issues.

Unfortunately, due to Chef's licensing, I won't be able to store the Chef deb in a repository anywhere, which will require anyone who wants to build the Docker image using that deb to download the deb manually beforehand. This will restrict me from doing automated builds. This is further limiting by the fact that Chef doesn't supply any packaging that I could find for other architectures that can run on Ubuntu 14.04 so I will only be able to build a Docker image that runs on an x86_64 container.

Some help:

• I would love to know if there any Chef PPAs, or packaging that provides a newer version of Chef, is compatible with Ubuntu 14.04 and is cross-architecture?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rapid7/metasploitable3/issues/545#issuecomment-887736994, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAI6Y7IV66CIRFZ2HHTCF4DTZ33N3ANCNFSM5BBMJYDQ .

[deargle]

Here, looks like it uses chef_solo version 15.0: https://github.com/hashicorp/vagrant/blob/5b501a3fb05ed0ab16cf10991b3df9d231edb5cf/test/unit/plugins/provisioners/chef/cap/linux/chef_installed_test.rb

And the docs say it gets installed using "chef's omnibus installer", but I haven't heard of that before: https://www.vagrantup.com/docs/provisioning/chef_common#install

[heywoodlh]

I tried the Omnibus installer with an ARM64 container which failed, but it looks like it works just fine for an x86_64 container. That helps with not having to manually download chef and install the .deb! Thank you.

Command like so: curl --silent https://omnitruck.chef.io/install.sh | bash

Now, if you know of a way to get a newer version of Chef on Ubuntu 14.04 ARM that would be epic. It would be nice to run the container on a Pi, my M1 Macbook, etc.

[heywoodlh]

One thing I will add here is that if I can't find ARM packaging for Chef that is compatible with Ubuntu 14.04 you would still be able to run the container with the --platform linux/amd64 argument. Just in my experience, emulating another architecture will make the container much slower.

[heywoodlh]

I managed to get the Chef recipes to run in the image and most things are up and running!

I had to make some pretty ugly fixes to the Chef recipes and obviously certain recipes won't work in a container such as the docker recipe and so the flags associated with that won't really be present.

You can test the image with a command like the following:

docker run -it --rm --name metasploitable3 --net=host heywoodlh/metasploitable3

I'd love some feedback if anyone else is willing to try it out.

Here are all the assets for the image: https://github.com/heywoodlh/dockerfiles/tree/master/metasploitable3

Edit: It's a huge image, by the way. Any suggestions that could make it smaller would be appreciated.

[jmartin-tech]

Your project looks very interesting. Creating a vulnerable container is an interesting take on a testing target and likely a good compromise in resources required to aid in learning about exploitation processes.

The metasploitable3 project is meant to create a vulnerable VM and as such docker and a containerized enviornment is not the right technology for the project itself at this time. The added complexity of maintaining the docker build as well as the packer process is a bit more than the project should take on right now.

As far are reuse, the license is BSD3/MIT so you are welcome to use the assets as you see fit as long as the attribution of where content was obtained is retained. Your project should not use the Metasploitable brand.

I would consider it reasonable and even say preferred for documentation to reference that your project is built to utilize metasploitable3's assets to provide additional attribution to the original creators of the work.

[heywoodlh]

@jmartin-r7 thanks for the response. I have updated the image name to heywoodlh/vulnerable and have put in what I think is suitable attribution to Metasploitable3.

So for anyone interested they can use something similar to the following command:

docker run -it --rm --net host heywoodlh/vulnerable

Since that answers my original questions regarding branding, etc. I will be closing this issue. Please let me know if there are any problems with my attribution or the image.

Assets are here: https://github.com/heywoodlh/dockerfiles/tree/master/vulnerable Image on Docker Hub: https://hub.docker.com/r/heywoodlh/vulnerable