dragon-lady/netward-standaloneBot en espace utilisateur et déviation DDoS pour les petits services HTTP
Une couche de tromperie en espace utilisateur qui transforme les DDoS et les abus de bots en efforts gaspillés.
Net Ward se place devant votre service HTTP en tant que proxy inverse. Le trafic réel passe sans être modifié. Les sondes et les floods connus reçoivent des réponses miroir inoffensives qui épuisent l'effort des bots et n'atteignent jamais votre application — aucun hook noyau, aucune charge utile, aucune représaille, fail-open par conception.
Créé et maintenu par Dragon Lady — github.com/Dragon-Lady · X : @answerislove2 Chercheuse indépendante en sécurité qui suit les campagnes actives de chaîne d'approvisionnement et d'abus de bots dans la nature.
Site web : dragon-lady.github.io/netward-standalone
python -m pip install --upgrade "netward>=0.4.12"
python -m netward --config example_config.json
La version 0.4.12 ou plus récente est la base recommandée pour les nouvelles installations et les mises à niveau. Les versions plus anciennes restent disponibles pour la reproductibilité ; les nouveaux déploiements doivent utiliser la version actuelle.
Ou depuis les sources :
git clone https://github.com/Dragon-Lady/netward-standalone
cd netward-standalone
pip install -e .
Net Ward écoute sur listen_address et transmet le trafic propre vers upstream_target.
Copiez la configuration d'exemple et modifiez la cible en amont :
cp example_config.json config.json
Avant de démarrer Net Ward, pointez upstream_target vers un véritable service HTTP. Si l'upstream est injoignable, les requêtes non appariées renvoient une réponse miroir par défaut au lieu d'exposer une erreur de proxy brute.
Champs obligatoires :
| Champ | Signification |
|---|---|
node_id | Nom stable de cette instance Net Ward |
upstream_target | Service HTTP protégé |
listen_address | Hôte et port sur lesquels Net Ward se lie |
Les champs facultatifs contrôlent l'intensité du miroir, le stockage local, les emplacements réservés du maillage, les canaux d'alerte, les délais d'attente de l'upstream et la rétention du journal des sondes. Une correspondance de motif ou le début d'une vague de requêtes enregistre une alerte dans SQLite. Les alertes sont dédupliquées par type, source et motif pendant cinq minutes. Une liste alert_channels vide envoie vers stdout ; sélectionnez n'importe quelle combinaison de stdout, email, slack et ntfy pour une livraison explicite. La livraison sortante s'exécute en arrière-plan et réessaie les canaux en échec. Les alertes récentes non livrées sont réessayées au démarrage.
L'e-mail nécessite alert_email, alert_smtp_host et alert_smtp_from. Définissez alert_smtp_port et alert_smtp_security (starttls, ssl ou none) ; none n'est autorisé que pour un serveur SMTP en boucle locale. Si une authentification est nécessaire, définissez alert_smtp_username et alert_smtp_password_env avec le nom d'une variable d'environnement contenant le mot de passe. Slack nécessite alert_slack_webhook. ntfy nécessite alert_ntfy_topic (un sujet sur ntfy.sh ou une URL complète de sujet auto-hébergé) ; pour un sujet protégé, définissez alert_ntfy_token_env avec le nom d'une variable d'environnement contenant son jeton bearer. Les destinations HTTP doivent utiliser HTTPS, sauf en boucle locale. alert_timeout_secs vaut cinq secondes par défaut. Net Ward vérifie les destinations demandées au démarrage et stocke les accusés de livraison réussis dans la table des alertes. Les messages d'alerte contiennent l'IP source, l'ID du motif et la classification ; ils n'incluent ni les corps ni les en-têtes bruts des requêtes.
| Champ facultatif | Valeur par défaut | Signification |
|---|---|---|
upstream_timeout_total | 10 | Budget total de la requête pour l'appel upstream, en secondes |
upstream_timeout_connect | 3 | Délai d'attente de connexion (DNS + TCP + TLS), en secondes |
upstream_timeout_sock_read | 5 | Temps d'inactivité entre les lectures de socket upstream, en secondes |
upstream_max_concurrency | 64 | Requêtes upstream en cours |
upstream_max_body_bytes | 8388608 | Taille maximale du corps de réponse upstream mis en tampon (8 MiB). Les corps plus volumineux basculent en fail-open vers le miroir par défaut |
probe_retention_secs | 604800 | TTL du journal des sondes (7 jours) |
probe_max_rows | 10000 | Nombre maximal de lignes du journal des sondes après purge à l'écriture |
alert_timeout_secs | 5 | Délai d'attente par canal pour la livraison sortante des alertes, en secondes |
python -m netward --config config.json
Exemple de topologie :
| Composant | Adresse |
|---|---|
| Net Ward | 127.0.0.1:8080 |
| Application en amont | http://127.0.0.1:9000 |
| Stockage | netward.db |
Pointez votre équilibreur de charge ou votre serveur web vers Net Ward. Gardez l'application en amont accessible uniquement depuis l'hôte ou un réseau de confiance lorsque c'est possible.
Définissez listen_address sur 0.0.0.0:<port> uniquement lorsque vous souhaitez intentionnellement que Net Ward soit accessible au-delà de localhost.
Sous Linux/macOS, gardez storage_path non accessible en écriture à tous. Exemple : chmod 600 netward.db, ou chmod 644 netward.db uniquement si vous avez intentionnellement besoin d'un accès en lecture pour la supervision.
Net Ward maintient en continu sa capacité documentée par machine, mais les pools de mémoire du runtime Python peuvent conserver l'état de l'ensemble de travail après une charge lourde prolongée. Les opérateurs exécutant Net Ward sous un trafic lourd continu devraient surveiller l'utilisation des ressources du processus et redémarrer le démon périodiquement, par exemple chaque semaine ou lorsque le RSS dépasse 2x la référence. La v0.5 affinera ces recommandations sur la base des retours des opérateurs et des observations de tests locaux, et non d'une télémétrie automatique.
Une requête propre doit atteindre l'amont :
curl -i http://127.0.0.1:8080/
La sonde connue doit être mise en miroir :
curl -i http://127.0.0.1:8080/wp-admin/
La sonde WordPress renvoie une fausse page de connexion. Le service en amont ne reçoit pas la requête.
Avec la topologie d'exemple ci-dessus, une première exécution saine devrait ressembler à ceci :
127.0.0.1:9000.127.0.0.1:8080./ via Net Ward et confirmer que la réponse de l'amont revient./wp-admin/ via Net Ward et confirmer qu'une réponse miroir revient à la place.