Net Ward

Eine User-Space-Täuschungsschicht, die DDoS- und Bot-Missbrauch in vergeudeten Aufwand verwandelt.

Net Ward sitzt als Reverse Proxy vor Ihrem HTTP-Dienst. Echter Datenverkehr läuft unverändert durch. Bekannte Sonden und Floods erhalten harmlose Spiegelantworten, die Bot-Aufwand verbrennen und niemals Ihre Anwendung erreichen — keine Kernel-Hooks, keine Payloads, keine Vergeltung, Fail-Open by Design.

Warum Net Ward

Lenkt ab, schlägt nicht zurück. Bots verschwenden Zeit mit überzeugenden, aber harmlosen Spiegeln; Ihr Upstream sieht die Anfrage nie.
User-Space und Fail-Open. Keine Kernel-Module, keine Paketmanipulation. Wenn Klassifizierung, ein Speicher-Lesevorgang oder das Rendering fehlschlägt, läuft der Datenverkehr direkt zum Upstream durch (oder zum Standard-Spiegel, falls der Upstream ausgefallen ist).
Lässt sich überall einbinden. Ein Python-Prozess vor jedem HTTP-Dienst. Richten Sie Ihren Load Balancer darauf und los.
Ehrlich by Design. Keine Telemetrie, keine abgegriffenen Zugangsdaten, der Betreiber besitzt jedes Byte lokaler Daten. Apache-2.0.

Entwickelt und gepflegt von Dragon Lady — github.com/Dragon-Lady · X: @answerislove2 Unabhängige Sicherheitsforscherin, die Live-Kampagnen zu Supply-Chain- und Bot-Missbrauch in freier Wildbahn verfolgt.

Website: dragon-lady.github.io/netward-standalone

Schnellstart

python -m pip install --upgrade "netward>=0.4.12"
python -m netward --config example_config.json

Version 0.4.12 oder neuer ist die empfohlene Basis für Neuinstallationen und Upgrades. Ältere Releases bleiben für die Reproduzierbarkeit verfügbar; neue Deployments sollten die aktuelle Version verwenden.

Oder aus dem Quellcode:

git clone https://github.com/Dragon-Lady/netward-standalone
cd netward-standalone
pip install -e .

Net Ward lauscht auf listen_address und leitet sauberen Datenverkehr an upstream_target weiter.

Konfiguration

Kopieren Sie die Beispielkonfiguration und bearbeiten Sie das Upstream-Ziel:

cp example_config.json config.json

Richte upstream_target auf einen echten HTTP-Dienst, bevor du Net Ward startest. Wenn das Upstream nicht erreichbar ist, geben nicht zugeordnete Anfragen eine Standard-Spiegelantwort zurück, anstatt einen rohen Proxy-Fehler offenzulegen.

Erforderliche Felder:

Feld	Bedeutung
`node_id`	Stabiler Name für diese Net-Ward-Instanz
`upstream_target`	Der geschützte HTTP-Dienst
`listen_address`	Host und Port, an die Net Ward bindet

Optionale Felder steuern die Spiegelintensität, den lokalen Speicher, Mesh-Platzhalter, Alarmkanäle, Upstream-Timeouts und die Aufbewahrung des Probe-Protokolls. Eine Musterübereinstimmung oder der Beginn einer Anfrageflut zeichnet einen Alarm in SQLite auf. Alarme werden nach Art, Quelle und Muster für fünf Minuten dedupliziert. Eine leere alert_channels-Liste sendet an stdout; wähle eine beliebige Kombination aus stdout, email, slack und ntfy für die explizite Zustellung. Die ausgehende Zustellung läuft im Hintergrund und wiederholt fehlgeschlagene Kanäle. Kürzlich nicht zugestellte Alarme werden beim Start erneut versucht.

E-Mail erfordert alert_email, alert_smtp_host und alert_smtp_from. Setze alert_smtp_port und alert_smtp_security (starttls, ssl oder none); none ist nur für einen Loopback-SMTP-Server zulässig. Wenn eine Authentifizierung erforderlich ist, setze alert_smtp_username und alert_smtp_password_env auf den Namen einer Umgebungsvariable, die das Passwort enthält. Slack erfordert alert_slack_webhook. ntfy erfordert alert_ntfy_topic (ein Topic auf ntfy.sh oder eine vollständige selbst gehostete Topic-URL); für ein geschütztes Topic setze alert_ntfy_token_env auf den Namen einer Umgebungsvariable, die dessen Bearer-Token enthält. HTTP-Ziele müssen HTTPS verwenden, außer bei Loopback. alert_timeout_secs ist standardmäßig fünf Sekunden. Net Ward prüft die angeforderten Ziele beim Start und speichert erfolgreiche Zustellungsbelege in der Alerts-Tabelle. Alarmmeldungen enthalten die Quell-IP, die Muster-ID und die Klassifizierung; sie enthalten keine rohen Anfrage-Bodys oder Header.

Optionales Feld	Standard	Bedeutung
`upstream_timeout_total`	`10`	Gesamtbudget für die Upstream-Anfrage, in Sekunden
`upstream_timeout_connect`	`3`	Verbindungs-Timeout (DNS + TCP + TLS), in Sekunden
`upstream_timeout_sock_read`	`5`	Leerlaufzeit zwischen Upstream-Socket-Lesevorgängen, in Sekunden
`upstream_max_concurrency`	`64`	Laufende Upstream-Anfragen
`upstream_max_body_bytes`	`8388608`	Maximal gepufferter Upstream-Antwort-Body (8 MiB). Größere Bodys fallen auf den Standard-Spiegel zurück (fail-open)
`probe_retention_secs`	`604800`	TTL des Probe-Protokolls (7 Tage)
`probe_max_rows`	`10000`	Maximale Zeilen im Probe-Protokoll nach Purge-on-Write
`alert_timeout_secs`	`5`	Timeout pro Kanal für die ausgehende Alarmzustellung, in Sekunden

Ausführen

python -m netward --config config.json

Beispieltopologie:

Komponente	Adresse
Net Ward	`127.0.0.1:8080`
Upstream-App	`http://127.0.0.1:9000`
Speicher	`netward.db`

Richten Sie Ihren Load Balancer oder Webserver auf Net Ward aus. Halten Sie die Upstream-App nach Möglichkeit nur vom Host oder aus dem vertrauenswürdigen Netzwerk erreichbar. Setzen Sie listen_address nur dann auf 0.0.0.0:<port>, wenn Sie beabsichtigen, dass Net Ward über localhost hinaus erreichbar ist. Unter Linux/macOS sollte storage_path nicht für alle schreibbar sein. Beispiel: chmod 600 netward.db oder chmod 644 netward.db nur, wenn Sie absichtlich Lesezugriff für die Überwachung benötigen.

Ressourcenüberwachung

Net Ward hält seine dokumentierte Kapazität pro Box kontinuierlich aufrecht, aber die Speicherpools der Python-Laufzeit können nach anhaltender hoher Last den Zustand des Working Sets beibehalten. Betreiber, die Net Ward unter kontinuierlichem hohem Datenverkehr ausführen, sollten die Ressourcennutzung des Prozesses überwachen und den Daemon regelmäßig neu starten, zum Beispiel wöchentlich oder wenn der RSS-Wert das 2-fache des Basiswerts überschreitet. v0.5 wird diese Empfehlung auf Grundlage von Betreiberfeedback und lokalen Testbeobachtungen verfeinern, nicht auf Grundlage automatischer Telemetrie.

Überprüfen

Eine saubere Anfrage sollte das Upstream erreichen:

curl -i http://127.0.0.1:8080/

Bekannte Probe sollte gespiegelt werden:

curl -i http://127.0.0.1:8080/wp-admin/

Die WordPress-Sonde liefert eine gefälschte Login-Seite zurück. Der Upstream-Dienst erhält die Anfrage nicht.

Happy-Path-Beispiel

Mit der obigen Beispiel-Topologie sollte ein fehlerfreier erster Lauf so aussehen:

Starten Sie einen kleinen Upstream-Dienst auf 127.0.0.1:9000.
Starten Sie Net Ward auf 127.0.0.1:8080.
Fordern Sie / über Net Ward an und bestätigen Sie, dass die Upstream-Antwort zurückkommt.
Fordern Sie /wp-admin/ über Net Ward an und bestätigen Sie, dass stattdessen eine Mirror-Antwort zurückkommt.

Erwartetes Ergebnis: Normaler Traffic erreicht die Upstream-App, während die bekannte Sonde von der Mirror-Schicht von Net Ward behandelt wird. Dies ist das einfachste Signal dafür, dass der Proxy-Pfad, der Pattern-Match und die Mirror-Antwort alle funktionieren.

netward-standalone

Beliebteste