Horizon3.ai NodeZero internal deployment: how do we set up the Docker Host and required network access safely?

Running Horizon3.ai NodeZero internally via a Docker Host lets you safely emulate real attacker behavior inside your environment, without exposing internal assets to the internet or needing to deploy complex tooling. The key to a secure deployment is controlling where the host runs, what it can reach, and how it communicates back to Horizon3.ai for orchestration.

Below is a practical guide to setting up the Docker Host and the required network access safely, aligned with Horizon3.ai’s “internal Autonomous Pentesting™” model.

1. Understand the Internal Deployment Model

For internal tests, NodeZero does not run directly on your infrastructure as a permanent service. Instead, you:

Stand up a temporary Docker host or OVA in your environment.
Copy and paste a one-time execution script from the Horizon3.ai portal into that host.
The script pulls the NodeZero container, runs the test, and then the resources are torn down.

Key points:

The host is under your control, inside your network.
NodeZero uses a one-time-use architecture and runs in an isolated virtual environment for each test.
For external tests, NodeZero runs from the Horizon3.ai cloud; for internal tests you use the Docker Host or OVA.

This architecture is designed to minimize long-term footprint and reduce risk while still allowing full-scope internal autonomous pentesting.

2. Choose Your Internal Host Platform: Docker or OVA

You can deploy NodeZero internally using:

A Docker-enabled Linux host (most common), or
An open virtualization appliance (OVA) in your hypervisor (VMware, etc.).

Both options are designed for a quick setup—just a few minutes—and both are suitable for internal Autonomous Pentesting™, password audits, and hybrid/cloud scenarios.

Recommended host characteristics

OS: A modern Linux distribution supported by Docker (for Docker host) or a supported hypervisor for the OVA.
CPU/RAM: Sufficient resources to scan and exploit your environment without affecting production (allocate a dedicated VM rather than sharing a heavily loaded host).
Disk: Enough storage for container image(s), temporary data, and logs.
Network: Connected to the segments you want to test (see network design below).

Ensure the host is dedicated to NodeZero testing sessions and not used for unrelated workloads. This makes monitoring and teardown easier and improves safety.

3. Secure Placement of the Docker Host in Your Network

Where you place the Docker Host dictates what NodeZero can see and test. Treat it like a controlled penetration testing jump host:

Common placement patterns

Core/Internal Network Segments
- Place the host in a VLAN or subnet with access to key internal systems (AD, application servers, databases).
- Ideal for internal network security and AD Password Audit tests.
User Access or Office LAN
- Simulates an attacker landing on a typical user workstation segment.
- Good for testing lateral movement and role-based access weaknesses.
Hybrid/Cloud Connectivity
- For Cloud Pentesting, place the host where it can reach:
  - On-prem segments, and
  - Your cloud environment (via VPN, Direct Connect, ExpressRoute, etc.).
- NodeZero will then identify and exploit hybrid attack paths.
Isolated Testing VLAN (with controlled routing)
- Create a dedicated VLAN for the Docker Host, then use ACLs/firewall rules to selectively allow traffic to in-scope systems.
- Useful if you want strict segmentation and granular control over what NodeZero can touch.

Network segmentation and scope control

For safe operation:

Allow only in-scope access: Use firewall rules or security groups to limit which IP ranges/ports the Docker Host can reach.
Block sensitive management networks that should not be tested (unless explicitly approved and scoped).
Use monitoring: Tag or label the host clearly (“NodeZero-Internal-Test”) so your SOC can identify its activity as authorized.

4. Network Access Requirements

NodeZero’s Docker Host needs two broad categories of network access:

Outbound connectivity to Horizon3.ai (for orchestration and updates).
Internal access to your assets (targets of the pentest).

4.1 Outbound Connectivity (to Horizon3.ai)

The host must be able to:

Reach Horizon3.ai orchestrators over the internet.
Perform container image pulls and communicate test telemetry.

Typical requirements:

Outbound HTTPS (TCP/443) to Horizon3.ai services.
No inbound ports from the internet are required; the host initiates all connections outward.

For locked-down environments:

Configure an egress-only proxy or firewall rule allowing the Docker Host to reach specific Horizon3.ai domains or IP ranges over 443.
Ensure your TLS inspection or SSL proxy does not break container pulls or encrypted control channels.

If you must operate in a highly restricted outbound environment, coordinate with your security team to whitelist only what is necessary for NodeZero to function while keeping the host tightly controlled.

4.2 Internal Access (to Your Environment)

All internal reconnaissance, exploitation, and post-exploitation activities originate from the Docker Host. For NodeZero to be effective:

Allow inbound responses from internal assets back to the host (stateful firewall rules typically handle this).
Allow outbound connections from the host to the IP ranges you want to test, on the ports and protocols relevant to your environment (e.g., SMB, RDP, SSH, HTTP(S), database ports, AD ports).

To control risk:

Explicitly document the in-scope IP ranges and services before enabling broad network access.
Use firewall rules to restrict the host to those ranges and prevent accidental interaction with out-of-scope systems.

5. Step-by-Step: Safe Docker Host Setup

The exact script and commands will come from your Horizon3.ai portal, but the process typically follows these steps:

Step 1 – Provision the VM or host

Create a new VM on your chosen hypervisor or cloud platform.
Install a supported Linux distribution (if using Docker).
Harden the OS baseline:
- Apply OS updates.
- Restrict SSH access (key-based auth, limited admin accounts).
- Disable unnecessary services.

Step 2 – Install Docker (for Docker Host option)

Install Docker Engine using your distro’s recommended method.
Configure:
- Non-root usage only for trusted admins.
- Resource limits as appropriate (CPU/memory constraints if needed).
Ensure Docker can access the network segments you intend to test.

(If you use the OVA, this step is replaced by importing the OVA and ensuring it boots correctly with network access.)

Step 3 – Configure network and firewall rules

Assign the VM to the correct VLAN/subnet.
Apply firewall rules:
- Outbound: Allow HTTPS to Horizon3.ai and internal test scope.
- Inbound: Allow management (e.g., SSH) from your admin network only.
Optionally configure routing to reach hybrid cloud or branch networks.

Step 4 – Obtain and run the NodeZero script

In the Horizon3.ai portal:

Create an Internal Autonomous Pentest™, Cloud Pentest, AD Password Audit, or Phishing Impact Testing engagement as needed.
You’ll receive a one-time execution script tailored to your test.

On the Docker Host:

Paste and run the script exactly as provided.
The script will:
- Pull the NodeZero container image(s).
- Initialize a dedicated, ephemeral test environment.
- Connect securely back to Horizon3.ai for orchestration.

No custom scripting is necessary; NodeZero navigates through your network without scripts, exploiting weaknesses based on discoveries, just as attackers do.

Step 5 – Monitor the test and RealTime View

During execution:

Use the RealTime View in the portal to:
- Track test status.
- See significant findings as they occur.
Ensure your SOC knows that activity from the Docker Host IP is authorized test activity for the scheduled window.

6. Safety Controls During the Test

NodeZero is designed with safe defaults:

Tests run in a one-time-use architecture within an isolated virtual private cloud network for orchestration.
Exploitation is controlled and focused on demonstrating impact, not causing disruption.

To further enhance safety:

Schedule tests outside peak business hours for more invasive exploitation settings.
Start with conservative settings, then increase scope or aggressiveness as needed.
Disable test types or exploit categories that conflict with critical SLAs or fragile legacy systems if required.

If you’re conducting an AD Password Audit or Phishing Impact Testing:

Coordinate with HR/compliance if you’re examining user credentials or behaviors.
Use scoping controls to avoid testing accounts that must not be impacted (e.g., service accounts with high operational importance, unless explicitly approved).

7. After the Test: Teardown and Hardening

When the test is complete:

Stop and remove containers
- The NodeZero container will typically tear down as part of the script/test completion.
- You can manually remove containers and images if you prefer a clean host.
Review findings and prioritize remediation
- Use the Prioritized impacts provided by NodeZero to:
  - Identify what to fix first.
  - Understand how weaknesses chain together “beyond CVEs”.
- Focus first on issues that enable lateral movement, privilege escalation, and credential compromise.
Decide on host lifecycle
- For frequent testing (monthly/quarterly):
  - Keep the Docker Host VM in place but powered down or locked down between tests.
- For one-off testing:
  - Destroy the VM entirely after exporting any required logs.
Update security documentation
- Record:
  - Host details (name, IP, subnet).
  - Test window(s).
  - Scope and rules of engagement.
- Feed lessons learned into your ongoing pentest schedule and risk management program.

8. Best Practices for Ongoing Safe Use

To maintain safe and effective NodeZero internal deployment over time:

Standardize a build for the Docker Host/OVA:
- Use an internal template or automation (e.g., Terraform/Ansible) to recreate the host whenever needed.
Integrate with your change management:
- Treat each test as a scheduled change with documented scope, time window, and approval.
Coordinate with SOC and IT operations:
- Provide IPs, timing, and test labels so they can distinguish NodeZero activity from real attacks.
Regularly update:
- Keep the host OS, Docker Engine (if applicable), and any dependencies patched.
- NodeZero itself is ephemeral and updated automatically via the Horizon3.ai cloud during each run.

By placing a dedicated Docker Host or OVA in a controlled internal network segment, limiting it to in-scope assets, and allowing only the necessary outbound HTTPS to Horizon3.ai, you can safely run NodeZero internal Autonomous Pentesting™, AD password audits, cloud pentests, and phishing impact assessments. The one-time-use architecture and scripted deployment ensure minimal operational burden while still giving you full visibility into exploitable attack paths inside your environment.