## Containers for Pentesters --- ### About Me - Ex-Pentester/IT Security person - Senior Security Advocate at Datadog - CIS Benchmark author, Docker and Kubernetes - Member of Kubernetes SIG-Security & CNCF TAG-Security --- ### What's a container then?  Note: Here we'll discuss how containers are literally just Linux processes --- # Demo Note: The goal of this demo is to show that containers are just processes. ps -fC nginx docker run --name webserver -d nginx ps -fC nginx docker exec webserver touch /my_new_file sudo ls /proc/PID/root --- ### What Does Docker do?  --- # Demo Note: sudo socat -v UNIX-LISTEN:/tmp/tempdock.sock,fork UNIX-CONNECT:/var/run/docker.sock sudo docker -H unix:///tmp/tempdock.sock images --- ### Docker Desktop  Note: This is to talk about Docker for Windows/Mac and how it complicates matters. --- ### An important Aside : Docker Security model ```bash= docker run -ti --privileged --net=host --pid=host --ipc=host --volume /:/host busybox chroot /host ``` --- ### Demo Note: docker run -ti --privileged --net=host --pid=host --ipc=host --volume /:/host busybox chroot /host --- #### Why do we need these things as pentesters? Note: We can talk about a load of things here - keeping clean laptops, to avoid tool contamination - Use legacy tools that don't work with modern distros - Updating tools - Making it easy to send tools to clients for on-sites --- ### VM vs Container Note: We're looking here at contrasting VMs and containers. The major difference is in likely size. It's kind of difficult to get smaller VM images, to roughly the size of container images. Also if you need old obscure pentest tools, you can containerize them so they can get all the old libs they rely on. Also you can avoid splatting one set of python/php/node/ruby libs with another. --- ### Docker Hub  Note: Images from Docker Hub Generally you should not use people's images directly from Docker hub, instead you can get inspiration from Dockerfiles and build your own. Outside of the base images. Important point is that a) there could be malware and b) more likely it just hasn't been patched in years. ---  Note: These are some of my images, the point here is to talk about the fact that other people are using them. This is basically not a good idea, as apart from me, no-one has any idea that these images are maintained, secure and not actively malicious. --- ### Make your own Images Note: Before we go on to talk about approaches, the point of the last two slides has essentially been about the dangers of using someone else's images. --- ### Tool specific ### vs ### Kitchen Sink Note: There are two approaches we can take to using Containers for pentesting, one is image per tool, the other is kitchen sink containers. Whilst purists will say that the Tool specific option is the only correct one, in reality it's a lot easier to maintain a couple of kitchen sink images. --- ### Choosing a base distro - Scratch - Alpine - Debian/Ubuntu - Red Hat - Not CentOS* Note: This is an important choice. - One of the main things is picking something consistent. This helps a lot with build size - Alpine is small but has some compatibility issues - Generally pick a base that is what you're used to. - CentOS is bad because the CentOS images on Docker hub are all deprecated/unmtaintained --- ### Dockerfile Basics - Single command image ```Dockerfile= FROM ubuntu:22.04 RUN apt update && apt install -y nmap && apt-get clean ENTRYPOINT ["nmap"] ``` Note: Here we're showing a very simple example of a single tool container image. --- ### Demo - Using the Basic image ```bash= docker build -t nmap -f Dockerfile.nmap . ``` ```bash= docker run --net=host nmap -v -n -sT 127.0.0.1 ``` Note: the point of this demonstration is to show how to use a single command container. --- ### Root vs Non-Root Note: an important determination is whether to run as root or non-root inside the cotainer. root is easier (obviously) but non-root might be needed for customer requirements. --- ### Trick - Getting root back in non-root envs Note: It's possible to have an image that can still do root things even if it's not root, using file capabilities --- ```dockerfile FROM ubuntu:22.04 RUN cp /bin/bash /bin/setuidbash && chmod 4755 /bin/setuidbash RUN adduser tester USER tester CMD ["/bin/bash"] ``` Note: This works in Ubuntu but does not work in Alpine?! --- ### Getting Data in and out of containers ```bash= docker run -it -v ~/testdata:/testdata [image] /bin/bash ``` Note: This is an important point about how you get data in and out of your containers. We should also mention that permissions are important. If you're root (or sudo root) locally it's fine, if you're running as a standard user, some finagling might be needed. --- ## Conclusion - Containers are quite easy to use once you understand what they do. - Very helpful for keeping tool envs clean - Very helpful for jobs that use Kubernetes --- ### Resources and Links - https://github.com/raesene/alpine-containertools - Example kitchen sink image! - https://github.com/raesene/dockerized-security-tools - Example Tool specific images (old) - https://securitylabs.datadoghq.com - Blog series on container security fundamentals - https://container-security.site - General container security resources - https://talks.container-security.site - Archive of Container/Cloud Native security talks --- ### Thanks - E-Mail: rory.mccune@datadoghq.com - Mastodon: @raesene@infosec.exchange - Twitter: @raesene