Files
DECNET/development/docs/ARCHITECTURE.md
anti 49f3002c94
Some checks failed
CI / Lint (ruff) (push) Successful in 18s
CI / SAST (bandit) (push) Successful in 19s
CI / Dependency audit (pip-audit) (push) Successful in 40s
CI / Test (Standard) (3.11) (push) Successful in 2m38s
CI / Test (Standard) (3.12) (push) Successful in 2m56s
CI / Test (Live) (3.11) (push) Failing after 1m3s
CI / Test (Fuzz) (3.11) (push) Has been skipped
CI / Merge dev → testing (push) Has been skipped
CI / Prepare Merge to Main (push) Has been skipped
CI / Finalize Merge to Main (push) Has been skipped
added: docs; modified: .gitignore
2026-04-16 02:10:38 -04:00

154 lines
6.2 KiB
Markdown

# DECNET Technical Architecture: Deep Dive
This document provides a low-level technical decomposition of the DECNET (Deception Network) framework. It covers the internal orchestration logic, networking internals, reactive data pipelines, and the persistent intelligence schema.
---
## 1. System Topology & Micro-Services
DECNET is architected as a set of decoupled "engines" that interact via a persistent shared repository (SQLite/MySQL) and the Docker socket.
### Component Connectivity Graph
```mermaid
graph TD
subgraph "Infrastructure Layer"
DK[Docker Engine]
MV[MACVLAN / IPvlan Driver]
end
subgraph "Identity Layer (Deckies)"
B1[Base Container 01]
S1a[Service: SSH]
S1b[Service: HTTP]
B1 --- S1a
B1 --- S1b
end
subgraph "Telemetry Layer"
SNF[Sniffer Worker]
COL[Log Collector]
end
subgraph "Processing Layer"
ING[Log Ingester]
PROF[Attacker Profiler]
end
subgraph "Persistence Layer"
DB[(SQLModel Repository)]
ST[decnet-state.json]
end
DK --- MV
MV --- B1
S1a -- "stdout/stderr" --> COL
S1b -- "stdout/stderr" --> COL
SNF -- "PCAP Analysis" --> COL
COL -- "JSON Tail" --> ING
ING -- "Bounty Extraction" --> DB
ING -- "Log Commit" --> DB
DB -- "Log Cursor" --> PROF
PROF -- "Correlation Engine" --> DB
PROF -- "Behavior Rollup" --> DB
ING -- "Events" --> WS[Web Dashboard / SSE]
```
---
## 2. Core Orchestration: The "Decky" Lifecycle
A **Decky** is a logical entity represented by a shared network namespace.
### The Deployment Flow (`decnet deploy`)
1. **Configuration Parsing**: `DecnetConfig` (via `ini_loader.py`) validates the archetypes and service counts.
2. **IP Allocation**: `ips_to_range()` calculates the minimal CIDR covering all requested IPs to prevent exhaustion of the host's subnet.
3. **Network Setup**:
- Calls `docker network create -d macvlan --parent eth0`.
- Creates a host-side bridge (`decnet_macvlan0`) to fix the Linux bridge isolation issue (hairpin fix).
4. **Logging Injection**: Every service container has `decnet_logging.py` injected into its build context to ensure uniform RFC 5424 syslog output.
5. **Compose Generation**: `write_compose()` creates a dynamic `docker-compose.yml` where:
- Service containers use `network_mode: "service:<base_container_name>"`.
- Base containers use `sysctls` derived from `os_fingerprint.py`.
### Teardown & State
Runtime state is persisted in `decnet-state.json`. Upon `teardown`, DECNET:
1. Runs `docker compose down`.
2. Deletes the host-side macvlan interface and routes.
3. Removes the Docker network.
4. Clears the CLI state.
---
## 3. Networking Internals: Passive & Active Fidelity
### OS Fingerprinting (TCP/IP Spoofing)
DECNET tunes the networking behavior of each Decky within its own namespace. This is handled by the `os_fingerprint.py` module, which sets specific `sysctls` in the base container:
- `net.ipv4.tcp_window_scaling`: Enables/disables based on OS profile.
- `net.ipv4.tcp_timestamps`: Mimics specific OS tendencies (e.g., Windows vs. Linux).
- `net.ipv4.tcp_syncookies`: Prevents OS detection via SYN-flood response patterns.
### The Packet Flow
1. **Ingress**: Packet hits physical NIC -> MACVLAN Bridge -> Target Decky Namespace.
2. **Telemetry**: The `Sniffer` container attaches to the same MACVLAN bridge in promiscuous mode. It uses scapy-like logic (via `decnet.sniffer`) to extract:
- **JA3/JA4**: TLS ClientHello fingerprints.
- **HASSH**: SSH Key Exchange fingerprints.
- **JARM**: (Triggered actively) TLS server fingerprints.
---
## 4. Persistent Intelligence: Database Schema
DECNET uses an asynchronous SQLModel-based repository. The schema is optimized for both high-speed ingestion and complex behavioral correlation.
### Entity Relationship Model
| Table | Purpose | Key Fields |
| :--- | :--- | :--- |
| **logs** | Raw event stream | `id`, `timestamp`, `decky`, `service`, `event_type`, `attacker_ip`, `fields` |
| **bounty** | Harvested artifacts | `id`, `bounty_type`, `payload` (JSON), `attacker_ip` |
| **attackers** | Aggregated profiles | `uuid`, `ip`, `is_traversal`, `traversal_path`, `fingerprints` (JSON), `commands` (JSON) |
| **attacker_behavior** | behavioral profile | `attacker_uuid`, `os_guess`, `behavior_class`, `tool_guesses` (JSON), `timing_stats` (JSON) |
### JSON Logic
To maintain portability across SQLite/MySQL, DECNET uses the `JSON_EXTRACT` function for filtering logs by internal fields (e.g., searching for a specific HTTP User-Agent inside the `fields` column).
---
## 5. Reactive Processing: The Internal Pipeline
### Log Ingestion & Bounty Extraction
1. **Tailer**: `log_ingestion_worker` tails the JSON log stream.
2. **.JSON Parsing**: Every line is validated against the RFC 5424 mapping.
3. **Extraction Logic**:
- If `event_type == "credential"`, a row is added to the `bounty` table.
- If `ja3` field exists, a `fingerprint` bounty is created.
4. **Notification**: Logs are dispatched to active WebSocket/SSE clients for real-time visualization.
### Correlation & Traversal Logic
The `CorrelationEngine` processes logs in batches:
- **IP Grouping**: Logs are indexed by `attacker_ip`.
- **Hop Extraction**: The engine identifies distinct `deckies` touched by the same IP.
- **Path Calculation**: A chronological string (`decky-A -> decky-B`) is built to visualize the attack progression.
- **Attacker Profile Upsert**: The `Attacker` table is updated with the new counts, path, and consolidated bounty history.
---
## 6. Service Plugin Architecture
Adding a new honeypot service is zero-configuration. The `decnet/services/registry.py` uses `pkgutil.iter_modules` to auto-discover any file in the `services/` directory.
### `BaseService` Interface
Every service must implement:
- `name`: Unique identifier (e.g., "ssh").
- `ports`: Targeted ports (e.g., `22/tcp`).
- `dockerfile_context()`: Path to the template directory.
- `compose_service(name, base_name)`: Returns the Docker Compose fragment.
### Templates
Templates (found in `/templates/`) contain the Dockerfile and entrypoint. The `deployer` automatically syncs `decnet_logging.py` into these contexts during build time to ensure logs are streamed correctly to the host.