| title | xodbox | ||||
|---|---|---|---|---|---|
| linkTitle | Docs | ||||
| menu |
|
Quickly determine if an application reaches out to remote network based services. Easily create custom responses to test how applications consume data from network sources.
Multiple listening protocols:
- HTTP/HTTPS
- DNS (in dev)
- FTP (in dev)
- SMTP (in dev)
- SMB (in dev)
- IMAP
- POP3
- SSH (in dev)
- TCP (in dev)
Plus:
- An embedded admin web console (React SPA + JSON API) to browse the live
event feed, edit payloads, group interactions into sinks, and manage users
and API keys. Enable it with
ui_pathor an isolatedadmin_listener— see the HTTPX handler docs. - Pluggable notifiers (
app_log,slack,discord,webhook) that fire on matching interactions, so a callback shows up in chat the moment it lands.
Download a release from GitHub or use Go Install:
go install github.com/defektive/xodbox@latestSeveral handlers bind privileged ports (below 1024) by default — HTTP :80,
HTTPS :443, DNS :53, and SMB :445. Instead of running xodbox as root,
grant the binary the network capabilities it needs and run it as a normal user:
sudo setcap cap_net_raw,cap_net_admin,cap_net_bind_service+eip xodbox
./xodbox servecap_net_bind_service is what allows binding ports below 1024, and is the only
capability required for the current handlers; cap_net_raw and cap_net_admin
are included for forward compatibility and can be dropped if you don't need them.
Re-run setcap after upgrading — replacing the binary clears its capabilities.
./xodbox config -e > xodbox.yamlConfiguration information for each Handler is documented alongside it's code in the handlers directory.
Configuration information for each Notifier is documented alongside it's code in the notifiers directory.
Start the listeners with the serve subcommand:
./xodbox serveRunning ./xodbox with no subcommand prints the available commands (serve,
config, payload, sink, user, …). All the magic happens through the
configuration file — see the handlers and
notifiers docs for what you can configure.
When a client makes a connection to xodbox, the logic to respond will be processed by a Handler. Handlers are responsible for seeding their own default data.
This little snippet will:
- Download and extract latest release from GitHub.
- Generate a new config file.
- create the static and payload directories used by the config file.
wget -q $(wget -q -O - https://api.github.com/repos/defektive/xodbox/releases/latest | grep -o "https:.*Linux_x86_64\.tar\.gz")
tar -xzvf xodbox*.tar.gz
./xodbox config -e | sed 's/^#\(\s*\(payload\|static\)_dir\)/ \1/g' > xodbox.yaml
mkdir -p static payloads/httpx./xodbox serve Prebuilt, cosign-signed images are
published to GitHub Container Registry on every release. The image's entrypoint
is xodbox and its working directory is /workspace, so mount a directory
there to hold your config, database, and payloads, then pass a subcommand
(serve, config, user, …).
# 1. Generate a config into the current directory
docker run --rm -v "$PWD:/workspace" ghcr.io/defektive/xodbox:latest config -e > xodbox.yaml
# 2. Run the server (publish whatever ports your config listens on)
docker run --rm \
-v "$PWD:/workspace" \
--user "$(id -u):$(id -g)" \
-p 80:80 \
ghcr.io/defektive/xodbox:latest serveThe image runs as a non-root user. Passing --user "$(id -u):$(id -g)" makes it
read and write the mounted directory as you, so the config and SQLite database
stay owned by your host user. Pin a release tag (e.g.
ghcr.io/defektive/xodbox:v1.2.3) instead of :latest for reproducible deploys.
Prefer not to pull the prebuilt image? The release binary is statically linked,
so you can run an extracted release inside a stock Alpine container. Run this
from the directory containing the extracted xodbox binary:
docker run \
--rm \
-p 80:80 \
-v "$PWD:/app" \
--workdir /app \
alpine \
./xodbox serveSweet! Open an issue to start the conversation.
Really? ok we made a tag just for you.
https://github.com/defektive/xodbox/releases/tag/legacy-nodejs