Back to Articles

Bento Toolkit: Running GUI Pentesting Tools in Fedora Containers with X11 Forwarding

[ View on GitHub ]

Bento Toolkit: Running GUI Pentesting Tools in Fedora Containers with X11 Forwarding

Hook

Most security professionals still dual-boot Kali Linux in 2024 because running GUI pentesting tools like Burp Suite in Docker containers is notoriously painful. Bento Toolkit attempts to solve this with X11 forwarding over SSH—but the solution reveals why containerizing security workstations remains an unsolved problem.

Context

The security community has a distribution problem. Kali Linux ships with over 600 tools, most of which you'll never use. Parrot Security isn't much better. These bloated environments are difficult to version control, impossible to reproduce consistently across teams, and overkill for focused engagements where you need 10-15 specific tools. Docker should be the obvious solution—lightweight, reproducible, disposable environments that you can spin up for specific CTF competitions or penetration tests.

Except Docker was designed for headless services, not GUI applications. Tools like Burp Suite, Ghidra, and various reverse engineering IDEs are essential for security work, and they all require graphical interfaces. The traditional workaround involves running VNC servers inside containers or mounting X11 sockets directly from the host, both of which introduce complexity and security concerns. Bento Toolkit takes a different approach: it uses SSH with reverse port forwarding to tunnel X11 traffic from your host's X server into a minimal Fedora container, creating a bridge between Docker's headless world and the GUI-heavy reality of security tooling.

Technical Insight

Bento's architecture centers on a carefully orchestrated SSH connection that establishes an X11 tunnel before you ever interact with security tools. When you start the container with docker-compose up, it launches an SSH daemon and waits for your connection. The magic happens in how you connect:

ssh -R 6000:localhost:6000 \
    -o StrictHostKeyChecking=no \
    -o UserKnownHostsFile=/dev/null \
    -p 2222 root@localhost

That -R 6000:localhost:6000 flag establishes reverse port forwarding, making your host's X server (typically running on port 6000) accessible from inside the container at localhost:6000. Once connected, Bento sets the DISPLAY=localhost:0 environment variable, and GUI applications inside the container render on your host's screen. This is architecturally cleaner than mounting /tmp/.X11-unix as a volume because it avoids permission issues with X authority files and works across different host operating systems, including Windows with VcXsrv or Cygwin/X.

The Dockerfile reveals deliberate minimalism. Instead of installing 600 tools, Bento includes a curated set focused on web application and infrastructure testing:

RUN dnf install -y \
    nmap sqlmap metasploit-framework \
    burpsuite john hydra nikto \
    wireshark gobuster dirb \
    && dnf clean all

This is roughly 30-40 tools compared to Kali's 600+, dramatically reducing the image size and attack surface. The Fedora base (rather than Debian/Ubuntu) is an interesting choice—Fedora's faster release cycle means more recent versions of Python, Go, and other language runtimes that modern security tools depend on. It's a bet that bleeding-edge tooling matters more than Debian's stability guarantees.

Where Bento differentiates itself for team scenarios is the optional CodiMD integration. The docker-compose configuration includes a collaborative markdown editor connected to a PostgreSQL database:

services:
  bento:
    build: .
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    ports:
      - "2222:22"
  
  codimd:
    image: nabo.codimd.dev/hackmdio/hackmd:2.4.2
    environment:
      - CMD_DB_URL=postgres://codimd:password@database/codimd
    ports:
      - "3000:3000"
    depends_on:
      - database

During CTF competitions or red team engagements, team members connect to the same CodiMD instance to document findings, share credentials, and coordinate attack paths in real-time. This addresses a genuine workflow gap—security practitioners spend as much time documenting and collaborating as they do exploiting vulnerabilities, yet most security distributions treat note-taking as an afterthought.

The cap_add: NET_ADMIN and /dev/net/tun device access deserve scrutiny. These privileges allow the container to create VPN connections, which is essential for CTF platforms like HackTheBox or TryHackMe that require OpenVPN connectivity to access target networks. However, this also means a compromised container could manipulate host networking, create arbitrary network interfaces, or intercept traffic. It's a calculated risk—you're trading container isolation for functionality that security work fundamentally requires.

Bento handles the X11 authentication challenge by generating SSH keys during initial setup and mounting them into the container. This is more secure than disabling X11 authentication entirely (which many quick tutorials recommend), but it assumes you trust the container with your SSH private key. For production use, you'd want to generate container-specific keys rather than reusing existing credentials.

Gotcha

The project's README prominently warns "experimental software," and that's not mere liability protection—there are real sharp edges. The most significant is that Burp Suite's embedded Chromium browser doesn't work correctly out of the box because it requires running as root with specific sandbox flags. The workaround involves manually modifying Burp's launcher script inside the container, which defeats the reproducibility benefits of containerization. If you rebuild the container, you lose those modifications.

The X11 forwarding approach also inherits all of X11's security limitations. X11 was designed in an era when workstations were single-user, and its security model reflects that—any application with access to your X server can keylog every keystroke, screenshot your entire display, or inject input to other windows. By forwarding your X server into a container filled with security tools (some of which you've downloaded from GitHub repositories of varying trustworthiness), you're creating an attack surface that's difficult to audit. Wayland compositors are becoming the default on modern Linux distributions precisely because of these X11 security issues, but Wayland doesn't support network transparency, making Bento's remote forwarding approach impossible without significant architectural changes.

The setup complexity is non-trivial. Before you can use Bento, you need to: install and configure an X server on your host (especially painful on Windows), generate SSH keys, understand reverse port forwarding, configure firewall rules to allow SSH on port 2222, and manually set the DISPLAY variable correctly for your operating system. This isn't beginner-friendly. Compare this to downloading a Kali VirtualBox OVA and clicking "Start"—the barrier to entry is substantially higher, which limits Bento's audience to practitioners who already understand Docker networking and X11 architecture.

Verdict

Use Bento if you're tired of bloated security distributions and want a minimal, version-controlled pentesting environment that you can reproduce identically across team members. It's particularly valuable for CTF teams who need the collaborative CodiMD integration and want to spin up multiple isolated instances for different competitions without the overhead of full VMs. The X11 forwarding over SSH approach works reliably once configured, and the Fedora base provides recent tool versions without waiting for Debian backports. Skip Bento if you're new to security work and need comprehensive tooling with better documentation—the experimental status and manual configuration overhead aren't worth the learning curve when you should be focusing on exploitation techniques, not Docker networking. Also skip it if you're in enterprise environments with strict security policies around privileged containers, or if you're on Wayland and can't easily fall back to X11. For most individual practitioners, a traditional Kali VM remains simpler and more reliable, even if it's philosophically less elegant than containers.

// ADD TO YOUR README
[![Featured on Starlog](https://starlog.is/api/badge/cybersecurity/himazawa-bento.svg)](https://starlog.is/api/badge-click/cybersecurity/himazawa-bento)