Honeypot para la enumeración de nombres de usuario: un snippet de Cloudflare para escaneos de /u/*.json

Mi foro de Discourse recibe esto a mansalva: un escáner. Un bot recorre una lista de palabras contra /u/<nombre>.json, recoge los 404 y averigua qué nombres de usuario existen. Cada sondeo consume un worker de Unicorn y le regala una respuesta al escáner.

He preparado un pequeño Fragmento de Cloudflare que responde a esos sondeos en el borde con un perfil falso pero creíble: 200, un id estable derivado del nombre de usuario, fecha de registro, nivel de confianza, número de publicaciones, e incluso una dirección de correo falsa que contiene una cadena canaria. Los visitantes reales pasan de largo sin ser tocados: una cookie de sesión, un referidor same-site, Accept: text/html o una clave API significan “no molestar”. El origen nunca ve un sondeo, por lo que el cambio supone menos carga, no más.

Los aciertos se registran en New Relic con IP, ASN y nombre de la red, país, ciudad, colo del borde, versión HTTP/TLS, agente de usuario y el nombre de usuario sondeado. Hay un panel con once widgets que puedes importar, y NRQL para “quién sigue volviendo”.

Un hueco para fragmento. Sin KV, sin Worker, sin cambios en el origen, sin bloqueos.
aún te quedan 4 y puedes utilizarlos con otros sitios de tu cuenta.

Repositorio: GitHub - hhftechnology/cloudflare-honeypot: Cloudflare Snippet honeypot for user-enumeration scans (/u/*.json): fake 200 profile, New Relic logging, zero origin load · GitHub

La documentación cubre la regla de Cloudflare (nota: el operador matches requiere el plan Business — usa wildcard), la importación en New Relic (hay que reemplazar dos marcadores de posición o fallará), y las peculiaridades de Discourse — incluido el caso en que la opción integrada ocultar perfiles de usuario al público es simplemente la mejor solución. pero en mi caso esto no era posible.

espero que esto ayude a alguien. la carga de nuestro servidor disminuyó dentro de la primera hora tras la implementación.