Files
DECNET/development/FUTURE.md

3.6 KiB

DECNET — Future Concepts & Architecture

This document tracks long-term, visionary architectural concepts and ideas that are outside the scope of the 1.0 roadmap, but represent the ultimate end-state of the DECNET framework.

The Honeymaze: Spider Network Topology

Concept Overview

As attackers breach the perimeter, instead of just lateral movement on a flat /24 or massive VXLAN, DECNET can dynamically generate an infinite "daisy-chain" of isolated Docker networks. This forces the attacker to establish deep, nested C2 proxy chains (SOCKS, chisel, SSH tunnels) to pivot from machine to machine.

For example:

  • decky-01 sits on the main LAN via eth0 (MACVLAN). It also has eth1, which belongs to docker-bridge-1.
  • decky-02 sits exclusively on docker-bridge-1 as its eth0. It also has eth1, belonging to docker-bridge-2.
  • decky-03 sits exclusively on docker-bridge-2.

Strategic Value

  1. High-Fidelity TTP Telemetry: By forcing the attacker into a corner where they must deploy pivot infrastructure, we capture extremely high-value indicators of compromise regarding their proxy tooling and network tradecraft.
  2. Infinite Time Sinks: An attacker can spend weeks navigating simulated air-gaps and deep corporate enclaves feeling a false sense of progression.

Execution & Realism Restrictions

To prevent the topology from feeling artificial or obviously simulated:

  1. Asymmetric Nesting: A strict 1:1 nested daisy chain is a dead giveaway. Real corporate networks branch organically.
    • Some machines should be terminal endpoints (no nested subnets).
    • Some machines acts as jump hosts bridging two large local arrays.
    • The depth and horizontal fan-out per subnet must be randomized to emulate realistic DMZ \rightarrow Internal \rightarrow OT enclave architectures.
  2. Variable Sizing: Subnets must contain a random number of containers. An internal enclave might have 50 flat machines, and only one of them acts as the bridge to the next isolated segment.

The Logging Paradox Solved

Deeply nested, air-gapped machines present a logging challenge: if decky-50 has no route to the internet or the logging network, how can it forward telemetry stealthily?

Solution: DECNET completely bypasses the container networking stack by relying purely on Docker's native stdout and daemon-level logging drivers. Because the host daemon handles the extraction, the attacker can completely destroy the container's virtual interfaces or be 50 layers deep in an air-gap without ever noticing a magic route, and the telemetry will still perfectly reach the SIEM out-of-band.

Simulated Topographical Latency

If an attacker proxies 5 subnets deep into what is supposed to be a secure, physically segmented enclave, and ping returns a flat 0.05ms response time, they will instantly realize it's a local simulation on a single host.

To maintain the illusion of depth, DECNET can utilize the Linux Traffic Control (tc) subsystem and its Network Emulator (netem) module on the virtual bridge interfaces (veth pairs).

By procedurally generating tc rules as the network scales, we can inject mathematical latency penalties per hop:

# Example: Add 45ms latency, +/- 10ms jitter on a normal curve, with 0.1% packet loss
tc qdisc add dev eth1 root netem delay 45ms 10ms distribution normal loss 0.1%

As an attacker pivots deeper into the "Spider Network," this injected latency compounds automatically. A proxy chain going 4 levels deep would realistically suffer from 150ms+ of latency and erratic jitter, perfectly mimicking the experience of routing over slow, multi-site corporate VPNs.