---
title: Containers for Pentesters
description: description
tags: talks, container_security
type: slide
slideOptions:
theme: blood
allottedMinutes: 30
---

## 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

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

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

docker build -t nmap -f Dockerfile.nmap .

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

---

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

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: [e-mail]
- Mastodon: @[e-mail]
- Twitter: @raesene