Este plugin usa a API ProxyTracer para detectar e bloquear tráfego de VPN, Tor e proxy no Discourse.
Recursos
Oferece controle fino sobre o bloqueio de usuários de VPN, Tor e Proxy durante novos registros de usuários, autenticação de usuários existentes ou globalmente para todos os visitantes do site. Se você permitir que usuários de VPN, Tor e Proxy tenham acesso de leitura ao seu fórum, poderá economizar solicitações à API e habilitá-la apenas para registro e autenticação de usuários.
Utiliza cache para armazenar avaliações recentes de endereços IP, reduzindo assim solicitações à API e diminuindo a latência. Você pode controlar por quanto tempo uma avaliação de endereço IP deve ser mantida nas configurações.
Em caso de tempo limite da API ou falha de rede, o plugin prioriza o acesso do usuário para evitar bloqueios em larga escala. Esse comportamento pode ser alterado nas opções.
Suporte integrado para listas de permissões de IPs exatos e sub-redes CIDR.
Acesse o painel de administração do seu Discourse: Admin → Plugins → ProxyTracer para encontrar as configurações do ProxyTracer.
Insira sua chave de API no campo Chave da API ProxyTracer.
Ative os parâmetros de proteção alternando Ativado durante o Cadastro, Ativado durante o Login e/ou Ativado para Todos os Visitantes.
Adicione IPs confiáveis ou intervalos CIDR à lista IPs na Lista de Permissões.
(Opcional) Ajuste o tempo limite da API e os limites de duração do cache Redis conforme as necessidades específicas de tráfego do seu servidor.
(Opcional) Personalize a Mensagem de Bloqueio exibida aos usuários bloqueados. Por exemplo, você pode adicionar instruções para entrar em contato com a administração do caso acreditem que o bloqueio não é justificado e que não estão acessando o site por meio de proxy, Tor ou VPN.
Inclua uma tabela com as configurações e suas descrições
Nome
Descrição
Tempo Limite da API (ms)
Tempo de espera pela resposta da API antes de ocorrer um tempo limite.
Duração do Cache (horas)
Tempo para lembrar um endereço IP antes de verificar novamente a API.
Falha Aberta em Erro
Se a API falhar ou ocorrer tempo limite, permita que o usuário se registre/entre de qualquer forma para evitar bloquear todos.
Ativado durante o Cadastro
Bloqueie proxies e VPNs quando um novo usuário tentar se registrar.
Ativado durante o Login
Bloqueie proxies e VPNs quando um usuário existente tentar fazer login.
Ativado para Todos os Visitantes
Bloqueie proxies e VPNs de acessar ou visualizar qualquer página no fórum. (Aviso: Isso verifica todos os visitantes e utiliza intensamente sua cota de API).
Mensagem de Bloqueio
A mensagem de erro exata exibida ao usuário quando ele é bloqueado.
IPs na Lista de Permissões
Endereços IP ou intervalos CIDR (por exemplo, 192.168.1.0/24) que são estritamente permitidos para contornar o bloqueio.
Configuração de Rede: Cloudflare & Proxies Reversos
Para que o ProxyTracer funcione efetivamente, a aplicação Discourse deve receber o verdadeiro endereço IP do cliente.
Para garantir o encaminhamento correto do endereço IP, siga estas instruções detalhadas.
Acesso de Emergência
Se você se trancar fora, poderá recuperar o acesso seguindo estas etapas simples.
Se quiser testar, você pode se cadastrar no ProxyTracer e obter créditos de API gratuitos para testes.
Depende. Existe uma configuração do site que permite desativar o modo seguro, o que é útil para o componente de tópico restrito e outros componentes/plugins que os usuários não deveriam poder desativar facilmente (publicidade, gate para convidados, …). Mas, enquanto você estiver desconectado, isso também tornaria mais difícil para os administradores usar o modo seguro. Acredito que eles ainda possam ativá-lo usando admin-login.
Para este plugin, duvido que o modo seguro ajude. O modo seguro desativa apenas a parte front-end dos plugins, e este plugin é 100% Ruby. Portanto, não acho que desativar customizações de JavaScript seja de alguma ajuda. Esse fato me deixa um pouco cético em relação ao plugin, assim como o fato de ele incluir um arquivo about.json como se fosse um componente de tema. Mas, no final, cada um é responsável pelo código que instala em seu fórum.
Você está absolutamente correto sobre isso; posso confirmar isso através dos meus próprios testes com uma instância do Discourse recém-criada. Procedi e atualizei a documentação com instruções que realmente funcionam, que consistem em fazer login no servidor e desativar manualmente o addon:
cd /var/discourse
./launcher enter app
rails c
SiteSetting.proxytracer_enabled = false
exit
exit
Posso confirmar que o modo seguro é inacessível quando a configuração “Habilitado para todos os visitantes” está ativada e alguém tenta acessar o modo seguro enquanto se conecta usando uma VPN/proxy.
De fato, um about.json é redundante para plugins padrão; procedi e removi-o do repositório.
Obrigado por todo o seu feedback, @Moin. Se tiver mais comentários ou sugestões, sinta-se à vontade para deixá-los aqui. O código é totalmente de código aberto e qualquer contribuição é bem-vinda: GitHub - ProxyTracer/discourse-proxytracer.
Eu estou testando o serviço de vocês, gostaria de saber se há algum conflito com o ‘templates/cloudflare.template.yml’ e se o plugin terá suporte para eventuais atualizações no core do Discourse
Obrigado por testar! A documentação no README.md sobre a integração com o Cloudflare recomenda claramente a inclusão de "templates/cloudflare.template.yml", pois é necessário para garantir que o Discourse extraia o IP real do usuário quando o fórum estiver atrás do Cloudflare. Portanto, não há conflito com esse template; na verdade, incluí-lo é necessário.
E sim, estamos comprometidos em acompanhar as atualizações principais do Discourse para garantir a compatibilidade total com as novas versões.
Estava pensando se a inclusão de uma opção que, em vez de bloquear usuários, exigisse apenas a resolução de um hCaptcha, e se tornar essa opção o padrão, constituiria um bom compromisso, pois adiciona apenas o suficiente de atrito para dificultar a vida de spammers e de quem tenta burlar banimentos, ao mesmo tempo em que permite que usuários legítimos que desejam proteger sua privacidade online por meio de VPNs, Tor e afins continuem acessando. Claro que os administradores que ainda quiserem manter o bloqueio total dessas redes ainda teriam essa opção. O que vocês acham?
Muito obrigado! Acabei de fazer um teste em um sandbox e está funcionando perfeitamente.
Vocês pensam em adicionar alguma funcionalidade relacionada a IPs/ASNs de redes móveis? Uma situação que acontece bastante no meu fórum é o usuário sair da rede de banda larga e passar para uma rede 4G/5G da operadora para obter um IP diferente e, com isso, tentar contornar restrições de cadastro ou login no Discourse.
Seria interessante poder identificar quando o IP pertence a um ASN de uma operadora móvel e, opcionalmente, permitir que esses IPs fossem tratados de forma diferente durante o cadastro/login.
Talvez isso seja um pouco fora do escopo do ProxyTracer, já que não necessariamente tem relação com VPN/proxy, mas seria útil para um problema específico de como o Discourse lida com limites de contas por IP.
No caso do hCapatcha, eu já uso na minha instalação e tem funcionado muito bem! Talvez uma união do plugin que aparentemente já está no core do Discourse com o seu plugin, uma funcionalidade extra quem sabe?
Gosto da ideia de manter o bloqueio total, afinal esse é o objetivo, mas com relação ao IPV4 e IPV6 das redes fixas e moveis parece ser bem útil dificultar este acesso por meio de desafios visto que IA adora criar conta em fóruns.
Olá, obrigado por considerar minha resposta. É algo que realmente me interessa e considero uma implementação particularmente sensível para todos, tanto para usuários quanto para administradores.
Sinceramente, me sinto como um robô completando CAPTCHAs para provar que sou humano, agindo deliberadamente como um bot. Já mencionei em tópicos relacionados que a implementação do Anubis (POW) me parece muito mais agradável e funcional.
Entendo que isso está fora do escopo deste projeto, mas, pelo que posso analisar a partir da minha posição, o uso do CAPTCHA que você mencionou seria viável e poderia literalmente não bloquear usuários que valorizam sua privacidade e desejam contribuir sem serem mantidos de fora.