dragon-lady/netward-standaloneBot de espacio de usuario y desvío de DDoS para servicios HTTP pequeños
Una capa de engaño en espacio de usuario que convierte el DDoS y el abuso de bots en esfuerzo desperdiciado.
Net Ward se sitúa frente a tu servicio HTTP como un proxy inverso. El tráfico real pasa sin alteraciones. Los sondeos e inundaciones conocidos reciben respuestas espejo inofensivas que consumen el esfuerzo de los bots y nunca llegan a tu aplicación — sin hooks del kernel, sin payloads, sin represalias, fail-open por diseño.
Creado y mantenido por Dragon Lady — github.com/Dragon-Lady · X: @answerislove2 Investigadora de seguridad independiente que rastrea campañas activas de cadena de suministro y abuso de bots en el mundo real.
Sitio web: dragon-lady.github.io/netward-standalone
python -m pip install --upgrade "netward>=0.4.12"
python -m netward --config example_config.json
La versión 0.4.12 o posterior es la base recomendada para nuevas instalaciones y actualizaciones. Las versiones anteriores siguen disponibles para fines de reproducibilidad; las nuevas implementaciones deberían usar la versión actual.
O desde el código fuente:
git clone https://github.com/Dragon-Lady/netward-standalone
cd netward-standalone
pip install -e .
Net Ward escucha en listen_address y reenvía el tráfico limpio a upstream_target.
Copia la configuración de ejemplo y edita el destino upstream:
cp example_config.json config.json
Dirige upstream_target a un servicio HTTP real antes de iniciar Net Ward. Si el upstream no es accesible, las solicitudes no coincidentes devuelven una respuesta de espejo predeterminada en lugar de exponer un error de proxy sin procesar.
Campos obligatorios:
| Campo | Significado |
|---|---|
node_id | Nombre estable para esta instancia de Net Ward |
upstream_target | Servicio HTTP que se está protegiendo |
listen_address | Host y puerto a los que Net Ward se vincula |
Los campos opcionales controlan la intensidad del espejo, el almacenamiento local, los marcadores de malla, los canales de alerta, los tiempos de espera del upstream y la retención del registro de sondeos. Una coincidencia de patrón o el inicio de una avalancha de solicitudes registra una alerta en SQLite. Las alertas se deduplican por tipo, origen y patrón durante cinco minutos. Una lista alert_channels vacía envía a stdout; seleccione cualquier combinación de stdout, email, slack y ntfy para una entrega explícita. La entrega saliente se ejecuta en segundo plano y reintenta los canales fallidos. Las alertas recientes no entregadas se reintentan al iniciar.
El correo electrónico requiere alert_email, alert_smtp_host y alert_smtp_from. Establezca alert_smtp_port y alert_smtp_security (starttls, ssl o none); none solo se permite para un servidor SMTP de loopback. Si se necesita autenticación, establezca alert_smtp_username y alert_smtp_password_env con el nombre de una variable de entorno que contenga la contraseña. Slack requiere alert_slack_webhook. ntfy requiere alert_ntfy_topic (un tema en ntfy.sh o una URL completa de tema autoalojado); para un tema protegido, establezca alert_ntfy_token_env con el nombre de una variable de entorno que contenga su token de portador. Los destinos HTTP deben usar HTTPS excepto en loopback. alert_timeout_secs tiene un valor predeterminado de cinco segundos. Net Ward comprueba los destinos solicitados al iniciar y almacena los recibos de entrega exitosos en la tabla de alertas. Los mensajes de alerta contienen la IP de origen, el ID de patrón y la clasificación; no incluyen cuerpos de solicitud ni encabezados sin procesar.
| Campo opcional | Predeterminado | Significado |
|---|---|---|
upstream_timeout_total | 10 | Presupuesto para toda la solicitud de la llamada al upstream, en segundos |
upstream_timeout_connect | 3 | Tiempo de espera de conexión (DNS + TCP + TLS), en segundos |
upstream_timeout_sock_read | 5 | Tiempo de inactividad entre lecturas del socket del upstream, en segundos |
upstream_max_concurrency | 64 | Solicitudes al upstream en curso |
upstream_max_body_bytes | 8388608 | Tamaño máximo del cuerpo de respuesta del upstream almacenado en búfer (8 MiB). Los cuerpos más grandes fallan de forma abierta hacia el espejo predeterminado |
probe_retention_secs | 604800 | TTL del registro de sondeos (7 días) |
probe_max_rows | 10000 | Número máximo de filas del registro de sondeos tras la purga al escribir |
alert_timeout_secs | 5 | Tiempo de espera por canal para la entrega de alertas salientes, en segundos |
python -m netward --config config.json
Ejemplo de topología:
| Componente | Dirección |
|---|---|
| Net Ward | 127.0.0.1:8080 |
| Aplicación upstream | http://127.0.0.1:9000 |
| Almacenamiento | netward.db |
Apunta tu balanceador de carga o servidor web a Net Ward. Mantén la aplicación upstream accesible solo desde el host o la red de confianza cuando sea posible.
Establece listen_address en 0.0.0.0:<port> solo cuando quieras intencionadamente que Net Ward sea accesible más allá de localhost.
En Linux/macOS, mantén storage_path sin permisos de escritura para todos. Ejemplo: chmod 600 netward.db, o chmod 644 netward.db solo si necesitas intencionadamente acceso de lectura para monitorización.
Net Ward mantiene su capacidad documentada por máquina de forma continua, pero los pools de memoria del runtime de Python pueden retener el estado del working-set tras una carga pesada sostenida. Los operadores que ejecutan Net Ward bajo tráfico pesado continuo deberían monitorizar el uso de recursos del proceso y reiniciar el daemon periódicamente, por ejemplo semanalmente o cuando el RSS supere 2x la línea base. La v0.5 refinará esta guía basándose en los comentarios de los operadores y las observaciones de las pruebas locales, no en telemetría automática.
Una solicitud limpia debería llegar al upstream:
curl -i http://127.0.0.1:8080/
La sonda conocida debe reflejarse:
curl -i http://127.0.0.1:8080/wp-admin/
La sonda de WordPress devuelve una página de inicio de sesión falsa. El servicio upstream no recibe la solicitud.
Con la topología de ejemplo anterior, una primera ejecución saludable debería verse así:
127.0.0.1:9000.127.0.0.1:8080./ a través de Net Ward y confirmar que se devuelve la respuesta del upstream./wp-admin/ a través de Net Ward y confirmar que en su lugar se devuelve una respuesta espejo.