Node Security

Scanning nodes execute external scripts and containers. To prevent malicious tasks from compromising the host or pivoting into internal networks, nodes implement multi-layer security defenses.

---

1. Core Security Defense Mechanisms

1.1 Binary Whitelist (Always Enforced)

For PROCESS or SHELL type tasks, only whitelisted executables are allowed.

• Default Whitelist: 90 built-in, commonly used security tools and system commands (e.g., nmap, nuclei, httpx, curl, python3).
• Interception: Non-whitelisted commands are blocked, and the task is marked FAILED.

NOTE

The binary whitelist is a client-side execution-layer sandbox. The platform also provides a Node Tool Whitelist (dispatch layer) that controls which tools' tasks a node pulls from the server. The two complement each other; see Node Management → Node Tool Whitelist.

1.2 Environment Variable Filtering

Before executing commands, the node automatically filters sensitive environment variables, including system variables, dynamic link hijacking variables, cloud provider credentials, and container management sockets, preventing credential leakage or shared library hijacking.

1.3 Container Volume Mount Restrictions

The Docker executor enforces strict mount limits:

• Allowed Paths: Only /tmp/, /private/tmp/, /var/tmp/, and /opt/testnet/.
• Blocked Paths: /etc/, /var/run/docker.sock, /root/ and other sensitive paths are blocked.

1.4 SSRF Protection (Allowed by Default — Harden Explicitly)

By default the node allows HTTP/DNS/TCP probing of internal network ranges (allow_ssrf defaults to true) to support scanning isolated internal segments. If the node runs on an untrusted network, enable protection explicitly:

• Once allow_ssrf is set to false, all private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, etc.), loopback addresses, and link-local addresses are blocked to prevent scanning internal services.
• With protection enabled, domain probes use dual verification (before and after DNS resolution) to prevent DNS rebinding bypasses.

1.5 Privileged Container Defense (Allowed by Default — Harden Explicitly)

By default the node allows privileged containers (allow_privileged defaults to true). Once allow_privileged is set to false, any Docker scanning task declaring --privileged mode is rejected outright, preventing container escapes.

WARNING

Both allow_ssrf and allow_privileged ship as true (allowed). For nodes exposed to untrusted targets or running on office/production networks, always set them to false explicitly via the config file or environment variables — see the next section.

---

2. Node Security Hardening Configuration

Customize security parameters via the client's config.yaml (or TESTNET_ prefixed environment variables):

# testnet-client config.yaml
server:
  url: "https://your-server:3100"
  secret: "your-node-secret"

node:
  name: "hardened-node-01"

security:
  # Allow SSRF probing of internal ranges (default: true).
  # Set to false in production/office networks to block internal probing.
  allow_ssrf: false

  # Allow privileged containers (default: true).
  # Set to false in production to block privileged containers.
  allow_privileged: false

  # Custom allowed mount directories (REPLACES the built-in default list
  # /tmp/, /private/tmp/, /var/tmp/, /opt/testnet/ — not appended to it)
  allowed_volume_paths:
    - "/tmp/"
    - "/opt/testnet/"

Equivalent environment variables:

export TESTNET_ALLOW_SSRF="false"
export TESTNET_ALLOW_PRIVILEGED="false"
export TESTNET_ALLOWED_VOLUME_PATHS="/tmp/,/opt/testnet/"

---

3. Spec Validation

Before deploying new tool DSLs, run the client's validate command for a local format check:

# Validate the spec's static format (required fields, types, timeouts, file fields, etc.)
./testnet-client validate --spec my-tool-spec.yaml

NOTE

validate performs static format validation only. Security enforcement — volume paths, SSRF, privileged mode — happens at task execution time on the node, inside the security sandbox.