Skip to content
KitploitKITPLOIT
ToolsExploitsBlog
Einreichen
ToolsExploitsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
NetworkSandboxEngine — Ein deterministischer Netzwerk-Sandbox zum Testen von nftables-Regeln. Er verwendet ephemere Linux-Netzwerk-Namespaces (netns) und Scapy, um Firewall-Logik sicher zu validieren. | Kitploit
Tools/GitHubGitHub/onyks-os/networksandboxengine
DefensivwerkzeugePaket-Sniffing & AnalyseScripting & AutomatisierungKonfigurationsprüfungNetzwerksicherheitDevSecOps
GitHubonyks-os/networksandboxengine

NetworkSandboxEngine

Ein deterministischer Netzwerk-Sandbox zum Testen von nftables-Regeln. Er verwendet ephemere Linux-Netzwerk-Namespaces (netns) und Scapy, um Firewall-Logik sicher zu validieren.

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Repository anzeigenWebseite
25vor 20h 22mNoch nicht geprüft
Teilen

Network Sandbox Engine (NSE)

Eine Linux-Engine für deterministische nftables-Firewall-Tests in isolierten Netzwerk-Namespaces.

Linux Python CI Status Documentation PyPI

License

Warum NSE? • Funktionen • Voraussetzungen • Installation • Schnellstart • Funktionsweise • Projektstruktur


Network Sandbox Engine Interface


Warum NSE?

Das Testen von Firewall-Regelsätzen auf einem Live-Linux-System birgt erhebliche Risiken: Fehlerhafte Regeln können SSH-Management-Sitzungen unterbrechen, Klartextverkehr während des Tests preisgeben oder verwaiste Firewall-Tabellen auf dem Host aktiv zurücklassen.

Die Network Sandbox Engine (NSE) bietet eine sichere, reproduzierbare Testumgebung. Sie erstellt ephemere Linux-Netzwerk-Namespaces, verbindet virtuelle Ethernet-Paare, kompiliert nftables-Regelsätze und injiziert synthetische Layer-2- und Layer-3-Pakete mit Scapy. Die gesamte Auswertung findet innerhalb des Sandbox-Namespace statt: Der Firewall-Zustand des Hosts wird niemals verändert.

Wesentliche architektonische Eigenschaften:

  • Keine Host-Mutation: Regelsätze werden ausschließlich in ephemere Sandbox-Namespaces (nse_<uuid>) geladen und beim Abbau vollständig entfernt.
  • Selbstverifizierendes Orakel: Jeder Durchlauf injiziert ein Canary-Paket vor den Testpaketen und erneut danach und meldet nur dann ein Ergebnis, wenn der Kernel-Trace für beide beobachtet wurde. Siehe Der Orakel-Vertrag.
  • Dual-Stack und Topologien: Native Unterstützung für IPv4- und IPv6-Verkehr sowie Multi-Namespace-Gateway-Topologien zur Validierung von Router-, NAT- und Forwarding-Regelsätzen.
  • Kleine, prüfbare Angriffsfläche: Ein Paket, kein Webserver, kein JavaScript. nse/ umfasst ~1150 Anweisungen bei 98 % Testabdeckung.

Erfordert Root

NSE erstellt Netzwerk-Namespaces, lädt nftables-Regelsätze und liest Kernel-Trace-Ereignisse, daher läuft es als Root. Es öffnet keinen Socket, keinen Port und keinen RPC-Endpunkt jeglicher Art — es ist eine Bibliothek und ein CLI, das Sie aufrufen, und es besitzt Privilegien nur für die Dauer eines Durchlaufs.

Version 2.1.0 hat die FastAPI/Svelte-Weboberfläche entfernt, die frühere Releases mitbrachten. Diese Oberfläche lief ab 2.0.0 prozessintern als Root, was für ein Testwerkzeug eine große Angriffsfläche darstellte; der Code bleibt in der Git-Historie unter dem Tag v2.0.0 erhalten, falls Sie ihn benötigen.


Der Orakel-Vertrag

Ein Firewall-Test ist eine negative Aussage — „Dieses Paket kam nicht durch" — und eine negative Aussage ist wertlos, wenn nicht bekannt ist, dass das Messinstrument funktioniert. Ein Trace-Monitor, der sich nie an den Kernel angehängt hat, und eine Firewall, die alles blockiert hat, erzeugen byte-identische Ausgaben.

NSE weigert sich daher, ein Urteil zu melden, dessen Messung es nicht nachweisen kann:

GarantieMechanismus
Der Monitor war vor dem ersten Testpaket angehängtEin Bereitschafts-Canary wird injiziert und erneut injiziert, bis sein Kernel-Trace beobachtet wird. Keine Beobachtung, kein Durchlauf.
Der Monitor war danach noch angehängtEin Lebendigkeits-Canary läuft nach der Injektion. Wird er verpasst, wird der Urteilsstrom als abgeschnitten erklärt.
Der Parser hat verstanden, was der Kernel gesagt hatTrace-Zeilen, auf die kein Muster passt, werden gezählt, und jede Zählung über null ist ein Fehler statt eines Debug-Logs.
Der Monitor ist nicht still gestorbenDie Leseschleife zeichnet auf, warum sie endete — sauberer Stopp, unerwartetes EOF, Timeout oder Absturz — und nur ein sauberer Stopp ist akzeptabel.
Ein fehlendes Urteil ist kein BestehenDer CLI-Runner schlägt fehl, wenn die Anzahl der beobachteten Urteile von der erwarteten abweicht, in beide Richtungen.

Canary-Pakete werden anhand der Trace-ID von den Ergebnissen ausgeschlossen, sodass sie nie in Ihrem Urteilsstrom erscheinen.

Die Testsuite beweist, dass dies gilt, statt es zu behaupten: make test-blind zwingt den Parser, nichts zu verstehen, und der Build schlägt fehl, es sei denn, der Runner beendet sich mit einem von null verschiedenen Exit-Code. Dieser Job läuft bei jedem Push in der CI.


Funktionen

  • In-Process-Engine: Direkte Python-API (run_test_pipeline), die strukturierte Pydantic-Modelle (TestRequest, TraceEvent) zurückgibt.
  • Scapy-Paketinjektion: Erzeugen Sie beliebige TCP- (mit benutzerdefinierten SYN-, ACK-, FIN-, RST-Flags), UDP-, ICMP- und ICMPv6-Pakete.
  • Isolierte Topologien:
    • Simple: Ein einzelner Sandbox-Namespace (nse_<id>), direkt mit dem Host verbunden.
    • Gateway: Router- (nse_router_<id>) und Server- (nse_server_<id>) Kette für Forwarding- und NAT-Tests.
  • Automatisierte Bereinigung: Start-Sweeps erkennen und entfernen übrig gebliebene Namespaces und veth-Paare aus früheren abgebrochenen Durchläufen. Teardowns beinhalten Wiederholungsversuche mit exponentiellem Backoff.
  • CLI-YAML-Test-Runner: Führen Sie deklarative YAML-Testsuiten für automatisierte CI/CD-Pipelines aus (nse-runner). Beendet sich mit einem von null verschiedenen Exit-Code bei einem falschen Urteil und bei einem Urteil, das nicht beobachtet werden konnte.
  • Strikte Qualitätsstandards: Vollständige statische Typprüfung (mypy --strict), Durchsetzung architektonischer Grenzen (import-linter), ruff-Formatierung und eine Coverage-Ratsche (make test-cov, Untergrenze 98 %).

Voraussetzungen

  • Linux-Betriebssystem (Kernel 5.4 oder später mit Unterstützung für Netzwerk-Namespaces und nftables)
  • Python 3.10+
  • nftables (nft)
  • iproute2 (ip)
  • Root-Privilegien (erforderlich für ip netns und Kernel-Trace-Operationen)

Auf Debian- oder Ubuntu-Systemen:

root@kitploit:~
sudo apt update && sudo apt install -y nftables iproute2 conntrack

Installation

1. PyPI-Paket (empfohlen)

Installieren Sie die Kern-Engine mit CLI-Unterstützung:

root@kitploit:~
pip install "network-sandbox-engine[cli]"

2. Manuelle Installation aus dem Quellcode

Für die lokale Entwicklung:

root@kitploit:~
git clone https://github.com/onyks-os/NetworkSandboxEngine.git
cd NetworkSandboxEngine
make setup

Schnellstart

1. Headless-Python-Bibliothek

root@kitploit:~
import asyncio
from nse.core.netns_controller import NetnsController
from nse.core.pipeline import run_test_pipeline
from nse.models.test_request import TestRequest, PacketSpec

rules = """
table ip filter {
    chain input {
        type filter hook input priority 0; policy drop;
        tcp dport 80 accept
    }
}
"""

request = TestRequest(
    rules=rules,
    packets=[
        PacketSpec(protocol="tcp", src_ip="10.0.0.1", dst_ip="10.0.0.2", dst_port=80),
        PacketSpec(protocol="tcp", src_ip="10.0.0.1", dst_ip="10.0.0.2", dst_port=22),
    ],
)


async def main():
    controller = NetnsController()
    events = await run_test_pipeline(request=request, controller=controller)
    for evt in events:
        if evt.verdict:
            print(f"[{evt.chain}] Verdict: {evt.verdict}")


asyncio.run(main())

2. YAML-Testsuite-Runner (CLI)

Erstellen Sie eine Testdatei firewall_test.yaml:

root@kitploit:~
tests:
  - name: "Allow HTTP Port 80, Drop SSH Port 22"
    topology: simple
    rules: |
      table ip filter {
        chain input {
          type filter hook input priority 0; policy drop;
          tcp dport 80 accept
        }
      }
    packets:
      - protocol: tcp
        src_ip: 10.0.0.1
        dst_ip: 10.0.0.2
        dst_port: 80
        expected_verdict: ACCEPT
      - protocol: tcp
        src_ip: 10.0.0.1
        dst_ip: 10.0.0.2
        dst_port: 22
        expected_verdict: DROP

expected_verdict gilt pro Paket. Unbekannte Schlüssel werden abgelehnt statt mit Standardwerten belegt, sodass ein Tippfehler die Suite fehlschlagen lässt, anstatt stillschweigend zu einer Erwartung zu werden, die Sie nie geschrieben haben.

Führen Sie die Suite mit Root-Privilegien aus:

root@kitploit:~
sudo nse-runner --file firewall_test.yaml

Exit-Codes: 0 alle Pakete stimmten überein; 1 ein Urteil war falsch oder die Engine konnte keines beobachten. Orakel-Fehler werden getrennt von Firewall-Fehlern gemeldet, da sie bedeuten, dass die Messung kaputt ist, nicht der Regelsatz.

3. In einem Container

root@kitploit:~
podman build -t nse .
podman run --rm --cap-add=NET_ADMIN --cap-add=NET_RAW \
    -v "$PWD/firewall_test.yaml:/suite.yaml:ro" nse --file /suite.yaml

Nützlich, um die nftables-Version festzulegen, gegen die Ihre Regeln getestet werden.


Funktionsweise

NSE orchestriert Linux-Kernel-Netzwerksubsysteme und Trace-Schnittstellen durch eine strukturierte mehrstufige Ausführungspipeline:

root@kitploit:~
graph TD
    subgraph Step1["1. Test Specification"]
        Req["<b>TestRequest</b><br/>ruleset + packets + topology"]
    end

    subgraph Step2["2. Ephemeral Netns Sandbox"]
        direction TB
        Netns["<b>Netns Setup</b><br/>nse_&lt;id&gt; & veth links"]
        RuleEng["<b>Rule Engine</b><br/>validate & load nftables"]
        Inject["<b>Scapy Injector</b><br/>L2/L3 packet injection"]
        NFT["<b>Kernel nftables</b><br/>meta nftrace set 1"]

        Netns --> RuleEng
        RuleEng --> Inject
        Inject --> NFT
    end

    subgraph Step3["3. Trace Evaluation & Oracle"]
        direction TB
        Harvester["<b>Trace Harvester</b><br/>nft monitor trace stream"]
        Oracle["<b>Deterministic Oracle</b><br/>TraceEvents & verdicts"]

        Harvester --> Oracle
    end

    Step1 --> Step2
    Step2 --> Step3
  1. Regelsatz-Validierung: RuleEngine.validate() führt einen Probelauf des Regelsatzes mit nft --check -f durch.
  2. Sandbox-Bereitstellung: NetnsController erstellt den isolierten Netzwerk-Namespace und konfiguriert virtuelle Ethernet- (veth-) Schnittstellen.
  3. Trace-Initialisierung: Regelsätze werden mit aktiviertem Kernel-Tracing (meta nftrace set 1) in den Namespace geladen.
  4. Paketinjektion: ScapyInjector injiziert synthetische Frames über die veth-Verbindung.
  5. Urteils-Erfassung: TraceHarvester erfasst nft monitor trace-Ereignisse und gibt strukturierte TraceEvent-Objekte zurück.
  6. Abbau: Der Namespace und alle zugehörigen veth-Schnittstellen werden automatisch gelöscht.

Vollständige technische Spezifikationen finden Sie im Technical Architecture Guide.


Projektstruktur

root@kitploit:~
NetworkSandboxEngine/
├── nse/                        # Core PyPI package (network-sandbox-engine)
│   ├── core/                   # Kernel primitives, pipeline, and naming rules
│   ├── models/                 # Pydantic models (TestRequest, PacketSpec, TraceEvent)
│   └── cli/                    # Headless YAML runner entrypoint
├── docs/                       # Architecture specs and MkDocs web documentation
├── tests/                      # Unit, golden file, and privileged e2e tests
│   └── fixtures/nft_trace/     # Golden `nft monitor trace` corpus
├── pyproject.toml              # Build backend configuration
└── Makefile                    # Local automation and CI workflow

Veröffentlichung

Ein Tag. git push origin vX.Y.Z baut, signiert mit Sigstore, veröffentlicht das GitHub-Release, lädt zu TestPyPI hoch, installiert von TestPyPI und führt einen Smoke-Test durch und lädt erst dann zu PyPI hoch. Proben Sie mit make release-dry.

Siehe docs/RELEASING.md.

Dokumentation

Vollständige interaktive Webdokumentation ist verfügbar unter:
https://onyks-os.github.io/nse/

Erstellen Sie die Dokumentation lokal:

root@kitploit:~
make docs

Stellen Sie die Dokumentation mit Hot-Reload auf http://127.0.0.1:8000 bereit:

root@kitploit:~
make docs-serve

Tests & lokale CI

Führen Sie statisches Linting und Unit-Tests aus:

root@kitploit:~
make verify

Führen Sie die vollständige lokale CI-Verifikation aus (beinhaltet Linting, Unit-Tests, Frontend-Build, Docs-Build, PyPI-Smoke-Test und privilegierte Integrationstests):

root@kitploit:~
make ci-local

Lizenz

Dieses Projekt ist unter der MIT-Lizenz lizenziert.

Tool herunterladen