The idea comes from a couple of handy blog posts (1, 2), which suggested to share the X11 socket of the host with the container and use it directly.
You can now try your setup by, for example, running Firefox from a container:
Run Burp Pro from Docker
Here is the idea:
we want to run Burp Pro from a container;
we want the container to be able to maintain the state (so not to have to re-enter the licence after every restart)
all automagically managed by docker-compose.
Let’s start by dissecting the docker-compose file:
We define a burp service, based on the Dockerfile defined in the burp/ folder (and shown below).
We then expose port 8080 to be able to intercept traffic from Burp.
We also specify 2 volumes: /tmp/.X11-unix to share the X11 socket, and _data that will map to our home directory in the container so to provide persistent storage that can survive the container.
Finally, we run Burp from its JAR executable.
Before proceeding, just remember to place the Burp Professional JAR file and the licence key
in the _data/sources folder:
Now that we have everything ready, let’s start by bootstrapping our setup with docker-compose up:
Burp should now be up and running, accept the terms and conditions
and you will be prompted to provide a licence key (which should be available to Burp since we
placed it in the _data volume, mapped to the user’s home directory):
To start intercepting, just configure your local browser to point to 127.0.0.1:8080 (the port we exposed in the docker-compose file).
Once done, we can use docker-compose down to stop the service,
while all files (like projects, extensions, etc.) will be stored in the _data/ folder:
Next time docker-compose is started, Burp will already be activated,
and all the data files are still gonna be present.