Net Ward

Uma camada de decepção em espaço de usuário que transforma DDoS e abuso de bots em esforço desperdiçado.

O Net Ward fica à frente do seu serviço HTTP como um proxy reverso. O tráfego real passa intacto. Sondagens e floods conhecidos recebem respostas espelhadas inofensivas que consomem o esforço dos bots e nunca chegam à sua aplicação — sem hooks no kernel, sem payloads, sem retaliação, fail-open por design.

Por que o Net Ward

Desvia, não revida. Os bots perdem tempo com espelhos convincentes mas inofensivos; o seu upstream nunca vê o pedido.
Espaço de usuário e fail-open. Sem módulos de kernel, sem manipulação de pacotes. Se a classificação, uma leitura de armazenamento ou a renderização falhar, o tráfego passa diretamente para o upstream (ou para o espelho padrão se o upstream estiver em baixo).
Encaixa em qualquer lugar. Um único processo Python à frente de qualquer serviço HTTP. Aponte o seu balanceador de carga para ele e siga.
Honesto por design. Sem telemetria, sem credenciais recolhidas, o operador é dono de cada byte dos dados locais. Apache-2.0.

Criado e mantido por Dragon Lady — github.com/Dragon-Lady · X: @answerislove2 Investigadora de segurança independente que acompanha campanhas ativas de supply-chain e abuso de bots em ambiente real.

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

Início Rápido

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

A versão 0.4.12 ou mais recente é a base recomendada para novas instalações e atualizações. Versões mais antigas permanecem disponíveis para fins de reprodutibilidade; novas implantações devem usar a versão atual.

Ou a partir do código-fonte:

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

O Net Ward escuta em listen_address e encaminha o tráfego limpo para upstream_target.

Configuração

Copie o arquivo de configuração de exemplo e edite o destino upstream:

cp example_config.json config.json

Aponte upstream_target para um serviço HTTP real antes de iniciar o Net Ward. Se o upstream estiver inacessível, requisições não correspondidas retornam uma resposta de espelho padrão em vez de expor um erro de proxy bruto.

Campos obrigatórios:

Campo	Significado
`node_id`	Nome estável para esta instância do Net Ward
`upstream_target`	Serviço HTTP sendo protegido
`listen_address`	Host e porta em que o Net Ward escuta

Campos opcionais controlam a intensidade do espelho, armazenamento local, placeholders de mesh, canais de alerta, timeouts do upstream e retenção do log de sondagem. Uma correspondência de padrão ou o início de uma inundação de requisições registra um alerta no SQLite. Os alertas são deduplicados por tipo, origem e padrão durante cinco minutos. Uma lista alert_channels vazia envia para stdout; selecione qualquer combinação de stdout, email, slack e ntfy para entrega explícita. A entrega de saída é executada em segundo plano e repete tentativas para canais com falha. Alertas recentes não entregues são repetidos na inicialização.

O email requer alert_email, alert_smtp_host e alert_smtp_from. Defina alert_smtp_port e alert_smtp_security (starttls, ssl ou none); none é permitido apenas para um servidor SMTP de loopback. Se autenticação for necessária, defina alert_smtp_username e alert_smtp_password_env com o nome de uma variável de ambiente que contém a senha. O Slack requer alert_slack_webhook. O ntfy requer alert_ntfy_topic (um tópico em ntfy.sh ou uma URL completa de tópico auto-hospedado); para um tópico protegido, defina alert_ntfy_token_env com o nome de uma variável de ambiente que contém seu bearer token. Destinos HTTP devem usar HTTPS, exceto em loopback. alert_timeout_secs tem como padrão cinco segundos. O Net Ward verifica os destinos solicitados na inicialização e armazena recibos de entrega bem-sucedidos na tabela de alertas. As mensagens de alerta contêm o IP de origem, o ID do padrão e a classificação; elas não incluem corpos de requisição ou cabeçalhos brutos.

Campo opcional	Padrão	Significado
`upstream_timeout_total`	`10`	Orçamento total da requisição para a chamada ao upstream, em segundos
`upstream_timeout_connect`	`3`	Timeout de conexão (DNS + TCP + TLS), em segundos
`upstream_timeout_sock_read`	`5`	Tempo ocioso entre leituras do socket do upstream, em segundos
`upstream_max_concurrency`	`64`	Requisições ao upstream em andamento
`upstream_max_body_bytes`	`8388608`	Corpo máximo da resposta do upstream em buffer (8 MiB). Corpos maiores falham de forma aberta para o espelho padrão
`probe_retention_secs`	`604800`	TTL do log de sondagem (7 dias)
`probe_max_rows`	`10000`	Máximo de linhas do log de sondagem após purga na escrita
`alert_timeout_secs`	`5`	Timeout por canal para entrega de alertas de saída, em segundos

Executar

python -m netward --config config.json

Exemplo de topologia:

Componente	Endereço
Net Ward	`127.0.0.1:8080`
Aplicação upstream	`http://127.0.0.1:9000`
Armazenamento	`netward.db`

Aponte seu balanceador de carga ou servidor web para o Net Ward. Mantenha a aplicação upstream acessível apenas a partir do host ou de uma rede confiável quando possível. Defina listen_address como 0.0.0.0:<port> apenas quando você quiser intencionalmente que o Net Ward seja acessível além do localhost. No Linux/macOS, mantenha storage_path sem permissão de escrita para todos os usuários. Exemplo: chmod 600 netward.db, ou chmod 644 netward.db apenas se você precisar intencionalmente de acesso de leitura para monitoramento.

Monitoramento de Recursos

O Net Ward sustenta continuamente sua capacidade documentada por caixa, mas os pools de memória do runtime Python podem reter o estado do working-set após carga pesada sustentada. Operadores que executam o Net Ward sob tráfego pesado contínuo devem monitorar o uso de recursos do processo e reiniciar o daemon periodicamente, por exemplo semanalmente ou quando o RSS exceder 2x a linha de base. A v0.5 refinará esta orientação com base no feedback dos operadores e em observações de testes locais, não em telemetria automática.

Verificar

Uma requisição limpa deve chegar ao upstream:

curl -i http://127.0.0.1:8080/

Sonda conhecida deve ser espelhada:

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

A sonda do WordPress retorna uma página de login falsa. O serviço upstream não recebe a requisição.

Exemplo de caminho feliz

Com a topologia de exemplo acima, uma primeira execução saudável deve ser assim:

Inicie um pequeno serviço upstream em 127.0.0.1:9000.
Inicie o Net Ward em 127.0.0.1:8080.
Solicite / através do Net Ward e confirme que a resposta do upstream retorna.
Solicite /wp-admin/ através do Net Ward e confirme que uma resposta espelhada retorna em vez disso.

Resultado esperado: o tráfego normal chega ao aplicativo upstream, enquanto a sonda conhecida é tratada pela camada de espelhamento do Net Ward. Este é o sinal mais simples de que o caminho do proxy, a correspondência de padrões e a resposta espelhada estão todos funcionando.

Comandos do Operador

Instale ou atualize o conjunto de padrões de fornecedores incluído:

netward-standalone

Mais Populares