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

Running Horizon3.ai NodeZero internally with a Docker Host is a safe, repeatable way to perform Autonomous Pentesting™ inside your network—provided you deploy it with the right controls and network access. This guide walks through how to set up the internal Docker Host, what network access it needs, and how to keep the entire deployment secure.

Understanding NodeZero Internal Deployment

NodeZero internal tests are executed from a local “host” you control:

• Docker Host or OVA: A free, lightweight virtual machine or Docker-capable system you set up in your environment.
• Execution script: You simply copy and paste the NodeZero-provided script into the host to start a test.
• Control plane in the cloud: External tests run fully from the Horizon3.ai cloud, but internal tests use your host as the execution point inside your network.

The design goal is to let you:

• Safely test from any network segment
• Run with or without domain/user credentials
• Maintain strict control over what parts of your environment are in scope

Prerequisites for the Docker Host

Before deployment, confirm the following prerequisites for your NodeZero internal Docker Host:

• Virtualization / container support

  • A hypervisor (VMware, Hyper-V, KVM, etc.) or any Linux/Windows host capable of running Docker
  • Alternatively, deploy the Horizon3.ai open virtualization appliance (OVA) directly

• System resources (typical guidance)

  • CPU: 2–4 vCPUs (more for large environments)
  • RAM: 8–16 GB
  • Storage: 40–80 GB free disk, SSD preferred

• Network placement

  • Connected to the network you want to test (internal LAN, data center, or a specific VLAN)
  • Ability to route to target systems in-scope for the pentest

• Administrative access

  • Local admin/ sudo on the host
  • Ability to copy/paste and execute the NodeZero script

Quick Setup: Host Installation Options

Horizon3.ai gives you two main options for internal deployment:

1. Docker Host on an Existing System

Use this if you already have a hardened server or VM and want to layer NodeZero on top.

High-level steps:

1. Provision the VM or server

   • Choose a supported OS (commonly a modern Linux distribution)
   • Apply your standard hardening baseline (CIS, corporate image, etc.)

2. Install Docker

   • Install Docker Engine per the OS vendor’s guidance
   • Ensure the Docker daemon starts automatically on boot

3. Lock down host access

   • Restrict SSH/RDP to trusted admins
   • Disable unused services and ports
   • Keep OS and Docker patched

4. Obtain the NodeZero execution script

   • In the NodeZero portal, define your internal test and generate the script
   • Copy the script to your Docker Host

5. Run the script

   • Paste and execute on the Docker Host
   • The script pulls the required containers and configures the one-time-use architecture for that test

2. Horizon3.ai Open Virtualization Appliance (OVA)

Use this if you want the quickest, most standardized setup with minimal configuration.

1. Download the OVA

   • Obtain the NodeZero OVA from the Horizon3.ai portal or support

2. Deploy to your hypervisor

   • Import the OVA into VMware, Hyper-V (via conversion), or your preferred virtual platform
   • Assign CPU, memory, and storage consistent with your environment’s size

3. Connect networking

   • Attach the VM NIC to the appropriate internal network or VLAN
   • Verify basic connectivity (can it ping internal resources?)

4. Run the provided script

   • Use the console or SSH to access the VM
   • Paste and execute the NodeZero script to initialize the test environment

Safe Network Placement for the Docker Host

Choosing where to place your Docker Host internally is critical for both safety and coverage.

Recommended Placement

• Inside the target network segment

  • Place the host where it can naturally see the systems you want to test
  • For broad internal assessments, a core LAN or data center segment is typical

• Behind your internal firewalls

  • Treat the host like any internal testing appliance
  • Maintain segmentation between sensitive zones; consider multiple tests from different segments if needed

• No inbound exposure from the internet

  • The Docker Host should not require inbound internet traffic
  • Outbound-only connectivity to Horizon3.ai for control/telemetry is sufficient

Consider Multiple Hosts for Segmentation

In highly segmented environments:

• Use one host per zone/VLAN where you want to test deeply
• Or schedule multiple tests, each using a host placed in a different segment

This preserves containment while still allowing NodeZero to chain weaknesses and show realistic attack paths within each zone.

Required Network Access and Ports

To function correctly and safely, your NodeZero internal Docker Host needs:

1. Outbound Access to Horizon3.ai Cloud

The host must reach the Horizon3.ai control plane to:

• Register the test
• Obtain instructions and test configuration
• Send back findings and RealTime View data

Typical requirements:

• Outbound HTTPS (TCP 443) to Horizon3.ai cloud endpoints
• No inbound ports from the internet required
• Optionally, allow DNS (UDP/TCP 53) if name resolution is needed

If you use a proxy:

• Configure the host to use your HTTP/HTTPS proxy
• Confirm that the proxy allows TLS traffic to Horizon3.ai domains

2. Internal Access to Target Systems

NodeZero discovers and exploits weaknesses the same way an attacker would, so the host needs:

• Reachability to in-scope IP ranges
  • The more direct the routing, the better the discovery accuracy
• Internal services it will test
  • Common ports for pentesting include:
    • 80/443 (web)
    • 22 (SSH)
    • 3389 (RDP)
    • 445 (SMB)
    • 389/636 (LDAP/LDAPS)
    • 1433, 3306, 5432, etc. (databases)
  • You may fine-tune scope via firewalls or NodeZero configuration

3. Optional Credentialed Access

NodeZero internal tests can run:

• Without credentials
  • Simulating an unauthenticated attacker who gains a foothold
• With credentials
  • Domain accounts, service accounts, or other user credentials
  • Used to assess what a real attacker could do with stolen or phished credentials

You control what credentials, if any, are provided. For AD Password Audits or Phishing Impact Testing, appropriate read-level access is required to evaluate password health and lateral movement.

One-Time-Use Architecture and Safety Controls

Horizon3.ai’s architecture is designed to minimize risk:

• Dedicated, ephemeral resources per test

  • Each pentest uses a one-time-use architecture in an isolated virtual private cloud network
  • Internal Docker Host ties into this ephemeral test infrastructure

• No persistent presence

  • Once the test completes, the active test environment is torn down
  • The host remains under your control; containers and temporary artifacts can be removed

• Safe defaults

  • NodeZero ships with default settings designed for safe execution
  • You can customize intensity, scope, and exploitation types as needed

Configuring Safe Test Scope and Impact

To keep internal tests controlled:

1. Define scope clearly

   • Specify which IP ranges, domains, and environments are in scope
   • Exclude sensitive systems if required (e.g., production OT, legacy systems)

2. Adjust exploitation level

   • Use the NodeZero portal to choose:
     • Discovery-only
     • Exploitation with safe checks
     • More aggressive options if explicitly allowed by policy

3. Use RealTime View

   • Monitor the state of the test and significant findings as they occur
   • Pause or stop the test if you see unexpected behavior

4. Communicate with stakeholders

   • Inform IT, SOC, and relevant teams about test windows
   • Coordinate change freezes or maintenance windows if needed

Monitoring and Operational Best Practices

To run NodeZero internal deployment safely over time:

• Log everything

  • Ensure host logs (OS, Docker, network) are forwarded to your SIEM
  • Correlate test activity with SOC alerts to improve detection

• Limit host credentials

  • Use least privilege for accounts that manage or access the Docker Host
  • Rotate any credentials used in tests per your standard security practice

• Review findings and prioritize

  • NodeZero surfaces prioritized impacts so you can see:
    • What to fix first
    • How weaknesses chain together beyond single CVEs
  • Use this to drive remediation, not just reporting

• Schedule recurring tests

  • Internal Docker Host can be reused for future tests
  • Use NodeZero scheduling to:
    • Run quarterly or monthly internal pentests
    • Re-test after major changes or remediation

Example Deployment Scenarios

Internal Network Pentest from the Core LAN

• Host placement: VM on core data center VLAN
• Access: Full routing to internal servers and user subnets
• Use case: Autonomous Pentesting™ of internal AD, application servers, and workstations
• Safety: Default safe settings + RealTime monitoring + clear scope definition

AD Password Audit

• Host placement: Same segment as domain controllers or with routed access
• Access: Read access to AD (as per your policy)
• Use case: NodeZero identifies weak, breached, and reused passwords
• Safety: No password changes performed; audit-only.

Phishing Impact Testing

• Host placement: Where it can reach typical user resources and AD
• Access: Phished or simulated credentials provided to NodeZero
• Use case: Understand what an attacker can do after a successful phish
• Safety: Scoped to specific accounts or parts of the environment as defined by you

When to Use Cloud-Only vs. Internal Docker Host

NodeZero gives you flexibility depending on what you’re testing:

• Internal Docker Host

  • Best for: Internal networks, on-prem data centers, and environments with no direct cloud exposure
  • You maintain full control over where and how tests execute

• Cloud Pentesting (no Docker Host)

  • Best for: Internet-facing assets and cloud workloads
  • NodeZero runs the pentest from the Horizon3.ai cloud; no internal host is required
  • NodeZero can connect to both cloud and on-prem to reveal hybrid attack paths

Many organizations use both approaches: cloud pentests from Horizon3.ai’s cloud plus internal testing from an on-prem Docker Host.

Key Takeaways for Safe Internal Deployment

To safely set up the Horizon3.ai NodeZero internal Docker Host and required network access:

• Use a dedicated Docker Host or OVA with your standard hardening
• Place it inside the network segments you want to test—never directly on the internet
• Allow outbound-only HTTPS to Horizon3.ai; no inbound internet exposure is needed
• Ensure routing and ports to in-scope internal systems are available
• Leverage NodeZero’s one-time-use architecture and safe defaults
• Use RealTime View and clearly defined scope to keep tests controlled
• Reuse the host for recurring Autonomous Pentesting™, AD Password Audits, and Phishing Impact Testing

With this deployment pattern, you can confidently run internal NodeZero tests that mirror real attacker behavior while maintaining strict control over safety, scope, and impact.