Detectar y bloquear el tráfico de VPN, Tor y proxy durante el registro de usuarios, el inicio de sesión y/o globalmente utilizando la API de ProxyTracer.
Este plugin utiliza la API de ProxyTracer para detectar y bloquear el tráfico de VPN, Tor y proxy en Discourse.
Características
Ofrece un control preciso sobre el bloqueo de usuarios de VPN, Tor y proxy durante el registro de nuevos usuarios, la autenticación de usuarios existentes o globalmente para todos los visitantes del sitio. Si estás de acuerdo con que los usuarios de VPN, Tor y proxy tengan acceso de lectura a tu foro, puedes ahorrar solicitudes a la API y habilitarla solo para el registro y la autenticación de usuarios.
Utiliza almacenamiento en caché para guardar las evaluaciones recientes de direcciones IP, lo que reduce las solicitudes a la API y disminuye la latencia. Puedes controlar cuánto tiempo se recuerda una evaluación de dirección IP en la configuración.
En caso de tiempo de espera de la API o fallo de red, el plugin prioriza el acceso de los usuarios para evitar bloqueos generalizados. Este comportamiento se puede modificar mediante las opciones.
Soporte integrado para listas blancas de direcciones IP exactas y subredes CIDR.
Navega al panel de administración de tu Discourse: Admin → Plugins → ProxyTracer para encontrar la configuración de ProxyTracer.
Ingresa tu clave de API en el campo Clave de API de ProxyTracer.
Habilita los parámetros de protección activando Habilitado durante el registro, Habilitado durante el inicio de sesión y/o Habilitado para todos los visitantes.
Agrega cualquier IP de confianza o rangos CIDR a la lista IPs en lista blanca.
(Opcional) Ajusta el tiempo de espera de la API y los límites de duración de la caché Redis según los requisitos específicos de tráfico de tu servidor.
(Opcional) Personaliza el mensaje de bloqueo que aparece para los usuarios bloqueados. Por ejemplo, puedes agregar instrucciones para contactar a la administración del sitio en caso de que crean que el bloqueo no está justificado y que no están accediendo al sitio a través de un proxy, Tor o VPN.
Incluye una tabla de configuraciones y descripciones de ajustes
Nombre
Descripción
Tiempo de espera de la API (ms)
Tiempo de espera para que la API responda antes de agotarse.
Duración de la caché (horas)
Tiempo para recordar una dirección IP antes de consultar nuevamente la API.
Abrir en caso de error
Si la API falla o se agota el tiempo, permitir que el usuario se registre/inicie sesión de todos modos para evitar bloquear a todos.
Habilitado durante el registro
Bloquear proxies y VPNs cuando un nuevo usuario intenta registrarse.
Habilitado durante el inicio de sesión
Bloquear proxies y VPNs cuando un usuario existente intenta iniciar sesión.
Habilitado para todos los visitantes
Bloquear proxies y VPNs para acceder o ver cualquier página del foro. (Advertencia: Esto verifica a todos los visitantes y utiliza intensivamente tu cuota de API).
Mensaje de bloqueo
El mensaje de error exacto mostrado al usuario cuando es bloqueado.
IPs en lista blanca
Direcciones IP o rangos CIDR (por ejemplo, 192.168.1.0/24) que están estrictamente permitidos para omitir el bloqueo.
Configuración de red: Cloudflare y proxies inversos
Para que ProxyTracer funcione correctamente, la aplicación de Discourse debe recibir la dirección IP real del cliente.
Para garantizar el reenvío correcto de la dirección IP, puedes seguir estas instrucciones detalladas.
Acceso de emergencia
Si te has bloqueado a ti mismo, puedes recuperar el acceso siguiendo estos pasos sencillos.
Si deseas probar las funcionalidades, puedes registrarte en ProxyTracer y obtener créditos de API gratuitos para pruebas.
Depende. Hay una configuración del sitio que permite desactivar el modo seguro, lo cual es útil para el componente de temas restringidos y otros componentes o complementos que los usuarios no deberían poder desactivar tan fácilmente (publicidad, puerta para invitados, etc.). Sin embargo, mientras no hayas iniciado sesión, eso también dificultaría que los administradores usen el modo seguro. Creo que aún pueden activarlo mediante inicio de sesión como administrador.
En cuanto a este complemento, dudo que el modo seguro ayude. El modo seguro solo desactiva la parte del lado del cliente de los complementos, y este complemento está escrito 100% en Ruby. Por lo tanto, no creo que desactivar las personalizaciones de JavaScript sea de mucha ayuda. Este hecho me hace un poco escéptico sobre el complemento, al igual que el hecho de que incluya un archivo about.json como si fuera un componente de tema. Pero al final, cada uno es responsable del código que instala en su foro.
Tienes toda la razón en esto; puedo confirmarlo con mis propias pruebas en una instancia de Discourse recién creada. Procedí a actualizar la documentación con instrucciones que realmente funcionan, las cuales consisten en iniciar sesión en el servidor y desactivar manualmente el complemento:
cd /var/discourse
./launcher enter app
rails c
SiteSetting.proxytracer_enabled = false
exit
exit
Puedo confirmar que el modo seguro es inaccesible cuando la configuración “Habilitado para todos los visitantes” está activada y alguien intenta acceder al modo seguro mientras se conecta mediante una VPN/proxy.
Efectivamente, un about.json es redundante para los plugins estándar, así que procedí a eliminarlo del repositorio.
Gracias por todos tus comentarios, @Moin. Si tienes otras observaciones o sugerencias, siéntete libre de dejarlas aquí. El código es completamente de código abierto y cualquier contribución es bienvenida: GitHub - ProxyTracer/discourse-proxytracer.
Estoy probando su servicio y me gustaría saber si existe algún conflicto con ‘templates/cloudflare.template.yml’ y si el plugin tendrá soporte para posibles actualizaciones en el núcleo de Discourse.
¡Gracias por probarlo! La documentación en README.md sobre la integración con Cloudflare recomienda claramente incluir "templates/cloudflare.template.yml", ya que es necesario para garantizar que Discourse extraiga la IP real del usuario cuando el foro está detrás de Cloudflare. Por lo tanto, no hay ningún conflicto con esa plantilla; de hecho, su inclusión es imprescindible.
Y sí, estamos comprometidos a seguir las actualizaciones del núcleo de Discourse para garantizar la plena compatibilidad con las versiones más recientes.
Me preguntaba si la inclusión de una opción que, en lugar de bloquear a los usuarios, simplemente les exigiera pasar un hCaptcha, y si hacer que dicha opción sea la predeterminada constituiría un buen compromiso, ya que añade justo la cantidad de fricción necesaria para dificultar las cosas a los spammers y a quienes evaden las suspensiones, mientras que aún permite a los usuarios legítimos que desean proteger su privacidad en línea mediante VPN, Tor y similares. Por supuesto, los administradores que aún quisieran mantener bloqueos completos en esas redes seguirían teniendo esa opción. ¿Qué opinan?
¡Muchas gracias! Acabo de hacer una prueba en un entorno de pruebas (sandbox) y funciona perfectamente.
¿Tienen pensado añadir alguna funcionalidad relacionada con las IPs/ASNs de redes móviles? Una situación que ocurre bastante en mi foro es que el usuario sale de la red de banda ancha y pasa a una red 4G/5G de su operadora para obtener una IP diferente y, con ello, intentar eludir las restricciones de registro o inicio de sesión en Discourse.
Sería interesante poder identificar cuándo la IP pertenece a un ASN de una operadora móvil y, opcionalmente, permitir que estas IPs se traten de manera diferente durante el registro/inicio de sesión.
Quizás esto sea un poco fuera del alcance de ProxyTracer, ya que no necesariamente tiene relación con VPN/proxy, pero sería útil para un problema específico de cómo Discourse gestiona los límites de cuentas por IP.
En el caso de hCaptcha, ya lo uso en mi instalación y ¡ha funcionado muy bien! Tal vez una combinación del plugin que aparentemente ya está en el núcleo de Discourse con tu plugin, ¿quién sabe, una función extra?
Me gusta la idea de mantener el bloqueo total, ya que ese es el objetivo, pero con respecto a las IPv4 e IPv6 de las redes fijas y móviles, parece muy útil dificultar este acceso mediante desafíos, dado que la IA adora crear cuentas en los foros.
Hola, gracias por tener en cuenta mi respuesta. Es algo que me interesa mucho y lo considero una implementación particularmente delicada para todos, tanto para los usuarios como para los administradores.
Sinceramente, me siento como un robot completando CAPTCHAs para demostrar que soy humano, actuando deliberadamente como un bot. He mencionado en temas relacionados que la implementación de Anubis (POW) me resulta mucho más agradable y funcional.
Entiendo que esto está fuera del alcance de este proyecto, pero según lo que puedo analizar desde mi posición, el uso del CAPTCHA que mencionaste sería viable y podría, literalmente, no bloquear a los usuarios que valoran su privacidad y desean contribuir sin ser excluidos.
Es un caso de uso interesante y veo el valor en ofrecer a los usuarios un control más granular como ese. Esto requeriría un nuevo punto de acceso (endpoint) de API completamente nuevo, ya que el endpoint v1 tiene un alcance bastante limitado y solo proporciona un valor booleano sobre si una IP determinada es un proxy/VPN o no.
Tengo algunas preocupaciones en cuanto a la precisión de los datos al intentar implementar algo así, ya que la precisión para determinar si una IP se utiliza en una red 4G/5G está lejos de ser ideal, y existen aplicaciones donde algunos usuarios inocentes podrían ser penalizados injustamente, como aquellos que utilizan el servicio de banda ancha inalámbrica doméstica 4G/5G.
Dicho esto, por ahora el enfoque está en mejorar el endpoint v1 de la API para ampliar la cobertura.
Estamos trabajando en una nueva versión de prueba de la extensión con la opción de captcha y también estamos considerando esta función. ¿Considerarías suficiente una pestaña como esta o crees que podemos añadir más columnas a ella?
@ProxyTracer Tengo una duda sobre el uso de las solicitudes. He notado que se descuenta una solicitud cada vez que hay un nuevo inicio de sesión, incluso si la red no es de VPN/proxies. ¿Es lo esperado?
Sé que en el registro hay que verificar de todas formas y probablemente se descuenta una solicitud del panel. ¿Es así? Porque si configuro para bloquear todos los sitios de esos accesos, se descontará una cantidad mucho mayor de las de mi paquete, ¿verdad?
Pensé en aumentar la ‘Cache Duration hours’ a algo cercano a 30 días, pero parece que no es lo ideal. ¿Me equivoco?
Sí, para determinar si una dirección IP entrante pertenece o no a una VPN/proxy, el plugin debe consultar la API de ProxyTracer.
Sin embargo, el resultado (ya sea limpio o VPN/proxy) se almacena en caché inmediatamente en la base de datos Redis de tu foro. Si esa misma IP vuelve a iniciar sesión dentro de la ventana de horas configurada para la Duración de la caché, Discourse sirve la respuesta directamente desde Redis. Por lo tanto, no se descuenta ninguna solicitud a la API. Lo mismo aplica si activas la opción de bloquear VPNs/proxies desde todas las páginas del sitio.
El bloqueo a nivel de visitante consume más solicitudes que la protección solo para inicio de sesión debido al tráfico anónimo; sin embargo, la caché de Redis garantiza que las vistas repetidas de páginas por parte de visitantes recurrentes nunca generen descuentos innecesarios de la API.
Las IPs dinámicas residenciales/móviles rotan ocasionalmente, y nuevos nodos de salida de VPN se activan con el tiempo. Por lo tanto, con una caché de 30 días, es posible que una IP dinámica previamente limpia que se reasigne a un proveedor de VPN no se vuelva a verificar hasta que expire la caché. Por esta razón, algo como 4 días sería mucho mejor que 30 días.
Para que ProxyTracer funcione correctamente, la aplicación de Discourse debe recibir la dirección IP real del cliente.
