dragon-lady/netward-standaloneBot in user-space e deviazione DDoS per piccoli servizi HTTP
Un livello di inganno in user-space che trasforma DDoS e abusi da bot in sforzi sprecati.
Net Ward si colloca davanti al tuo servizio HTTP come reverse proxy. Il traffico reale passa inalterato. Le sonde e i flood noti ricevono innocue risposte speculari che consumano lo sforzo dei bot e non raggiungono mai la tua applicazione — nessun hook nel kernel, nessun payload, nessuna ritorsione, fail-open per progettazione.
Creato e mantenuto da Dragon Lady — github.com/Dragon-Lady · X: @answerislove2 Ricercatrice indipendente di sicurezza che monitora campagne attive di supply-chain e abuso da bot nel mondo reale.
Sito web: dragon-lady.github.io/netward-standalone
python -m pip install --upgrade "netward>=0.4.12"
python -m netward --config example_config.json
La versione 0.4.12 o successiva è la base raccomandata per nuove installazioni e aggiornamenti. Le versioni precedenti restano disponibili per la riproducibilità; i nuovi deployment dovrebbero utilizzare la release corrente.
Oppure dai sorgenti:
git clone https://github.com/Dragon-Lady/netward-standalone
cd netward-standalone
pip install -e .
Net Ward resta in ascolto su listen_address e inoltra il traffico pulito a upstream_target.
Copia la configurazione di esempio e modifica il target upstream:
cp example_config.json config.json
Prima di avviare Net Ward, punta upstream_target verso un servizio HTTP reale. Se
l'upstream non è raggiungibile, le richieste non corrispondenti restituiscono una risposta mirror predefinita
invece di esporre un errore grezzo del proxy.
Campi obbligatori:
| Campo | Significato |
|---|---|
node_id | Nome stabile per questa istanza di Net Ward |
upstream_target | Servizio HTTP da proteggere |
listen_address | Host e porta su cui Net Ward si mette in ascolto |
I campi opzionali controllano l'intensità del mirror, l'archiviazione locale, i segnaposto della mesh, i canali di avviso, i timeout dell'upstream e la conservazione del registro delle sonde. Una corrispondenza di pattern o l'inizio di un flood di richieste registra un avviso in SQLite. Gli avvisi vengono deduplicati per tipo, origine e pattern per cinque minuti. Una lista alert_channels vuota invia a stdout; seleziona qualsiasi combinazione di stdout, email, slack e ntfy per una consegna esplicita. La consegna in uscita viene eseguita in background e ritenta i canali non riusciti. Gli avvisi recenti non consegnati vengono ritentati all'avvio.
L'email richiede alert_email, alert_smtp_host e alert_smtp_from. Imposta alert_smtp_port e alert_smtp_security (starttls, ssl o none); none è consentito solo per un server SMTP su loopback. Se è necessaria l'autenticazione, imposta alert_smtp_username e alert_smtp_password_env con il nome di una variabile d'ambiente contenente la password. Slack richiede alert_slack_webhook. ntfy richiede alert_ntfy_topic (un topic su ntfy.sh o un URL completo di un topic self-hosted); per un topic protetto, imposta alert_ntfy_token_env con il nome di una variabile d'ambiente contenente il suo bearer token. Le destinazioni HTTP devono usare HTTPS tranne che su loopback. alert_timeout_secs è impostato per impostazione predefinita a cinque secondi. Net Ward verifica le destinazioni richieste all'avvio e memorizza le ricevute di consegna riuscite nella tabella degli avvisi. I messaggi di avviso contengono l'IP di origine, l'ID del pattern e la classificazione; non includono corpi o header delle richieste grezzi.
| Campo opzionale | Predefinito | Significato |
|---|---|---|
upstream_timeout_total | 10 | Budget per l'intera richiesta verso l'upstream, in secondi |
upstream_timeout_connect | 3 | Timeout di connessione (DNS + TCP + TLS), in secondi |
upstream_timeout_sock_read | 5 | Tempo di inattività tra le letture del socket upstream, in secondi |
upstream_max_concurrency | 64 | Richieste upstream in corso |
upstream_max_body_bytes | 8388608 | Dimensione massima del corpo della risposta upstream memorizzato nel buffer (8 MiB). I corpi più grandi passano in fail-open al mirror predefinito |
probe_retention_secs | 604800 | TTL del registro delle sonde (7 giorni) |
probe_max_rows | 10000 | Numero massimo di righe del registro delle sonde dopo la pulizia in scrittura |
alert_timeout_secs | 5 | Timeout per canale per la consegna degli avvisi in uscita, in secondi |
python -m netward --config config.json
Esempio di topologia:
| Componente | Indirizzo |
|---|---|
| Net Ward | 127.0.0.1:8080 |
| App upstream | http://127.0.0.1:9000 |
| Storage | netward.db |
Punta il tuo load balancer o web server su Net Ward. Mantieni l'app upstream raggiungibile solo dall'host o dalla rete fidata quando possibile.
Imposta listen_address su 0.0.0.0:<port> solo quando vuoi intenzionalmente che Net Ward sia raggiungibile oltre localhost.
Su Linux/macOS, mantieni storage_path non scrivibile da tutti. Esempio: chmod 600 netward.db, oppure chmod 644 netward.db solo se hai intenzionalmente bisogno dell'accesso in lettura per il monitoraggio.
Net Ward sostiene continuamente la capacità documentata per box, ma i pool di memoria del runtime Python possono trattenere lo stato del working-set dopo un carico pesante prolungato. Gli operatori che eseguono Net Ward sotto traffico pesante continuo dovrebbero monitorare l'utilizzo delle risorse del processo e riavviare periodicamente il daemon, ad esempio settimanalmente o quando l'RSS supera il doppio del valore di base. La v0.5 affinerà queste indicazioni in base al feedback degli operatori e alle osservazioni dei test locali, non a telemetria automatica.
Una richiesta pulita dovrebbe raggiungere l'upstream:
curl -i http://127.0.0.1:8080/
Il probe noto dovrebbe essere replicato:
curl -i http://127.0.0.1:8080/wp-admin/
La sonda WordPress restituisce una pagina di login falsa. Il servizio upstream non riceve la richiesta.
Con la topologia di esempio sopra, una prima esecuzione corretta dovrebbe apparire così:
127.0.0.1:9000.127.0.0.1:8080./ tramite Net Ward e confermare che arrivi la risposta dell'upstream./wp-admin/ tramite Net Ward e confermare che arrivi invece una risposta mirror.Risultato atteso: il traffico normale raggiunge l'app upstream, mentre la sonda nota viene gestita dal livello mirror di Net Ward. Questo è il segnale più semplice che il percorso proxy, la corrispondenza dei pattern e la risposta mirror funzionano tutti.