Honeypotting per l'enumerazione degli username: uno snippet Cloudflare per le scansioni su /u/*.json

Il mio forum Discourse riceve una valanga di questi scanner: un bot percorre una lista di parole contro /u/<nome>.json, raccoglie i 404 e identifica quali nomi utente esistono. Ogni sonde costa un worker Unicorn e fornisce allo scanner una risposta gratuita.

Ho creato un piccolo Snippet di Cloudflare che risponde a queste sonde all’edge con un profilo falso ma credibile: 200, un ID stabile derivato dal nome utente, data di iscrizione, livello di affidabilità, numero di post, persino un indirizzo email falso contenente una stringa canary. I visitatori reali passano senza essere toccati: un cookie di sessione, un referer same-site, Accept: text/html o una chiave API significano tutti “lascia perdere”. L’origine non vede mai le sonde, quindi l’impatto è un minore carico, non maggiore.

Gli hit vengono registrati in New Relic con IP, ASN e nome della rete, paese, città, colo dell’edge, versione HTTP/TLS, user agent e il nome utente sondato. C’è una dashboard con undici widget che puoi importare, e query NRQL per “chi continua a tornare”.

Uno slot snippet. Nessun KV, nessun Worker, nessuna modifica all’origine, nessun blocco.
Hai ancora 4 slot disponibili e puoi utilizzarli per altri siti nel tuo account.

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

La documentazione copre la regola Cloudflare (nota: l’operatore matches richiede il piano Business — usa wildcard), l’importazione in New Relic (due segnaposto devono essere sostituiti, altrimenti fallisce) e le avvertenze specifiche per Discourse — incluso il caso in cui l’impostazione integrata hide user profiles from public è semplicemente la soluzione migliore. Ma per me questa opzione non era possibile.

Spero che questo possa aiutare qualcuno. Il carico del nostro server è diminuito entro un’ora dalla distribuzione.