Come rilevare le richieste HTTP in ingresso inviati in forma anonima via Tor?

Question

sto sviluppando un sito web e sono sensibili alle persone screen scraping i miei dati. Io non sono preoccupato per raschiare una o due pagine -. Sono più preoccupato di qualcuno raschiare migliaia di pagine come l'aggregato di tali dati è molto più prezioso di una piccola percentuale sarebbe

posso immaginare le strategie per bloccare gli utenti in base al traffico pesante da un singolo indirizzo IP, ma il Tor rete set up molti circuiti che in sostanza significano appare traffico di un singolo utente per provengono da indirizzi IP diversi nel corso del tempo.

Lo so che è possibile rilevare il traffico Tor come quando ho installato Vidalia con la sua estensione di Firefox , google.com me presentato con un captcha.

Quindi, come posso rilevare tali richieste?

(del mio sito web in ASP.NET MVC 2, ma penso che qualsiasi approccio qui utilizzato sarebbe indipendente dalla lingua)

Answer 1

  

sto sviluppando un sito web e del mattino   sensibile alle persone screen scraping mia   Dati

Lascia perdere. Se è sul web e qualcuno lo vuole, sarà impossibile per impedire loro di ottenerlo. Le restrizioni più si mette in atto, tanto più si rischia di rovinare l'esperienza utente per gli utenti legittimi, che si spera essere la maggior parte del vostro pubblico. E 'anche il codice più difficile da mantenere.

vi posterò le contromisure a tutte le idee future risposte propongono.

Answer 2

È possibile verificare il proprio indirizzo IP con un elenco di Tor Exit nodi . So per certo che questo non sarà nemmeno rallentare giù qualcuno che è interessato a raschiare il vostro sito. Tor è troppo lento, la maggior parte dei raschietti non sarà nemmeno in considerazione. Ci sono decine di migliaia di server proxy aperti che possono essere facilmente analizzate per le o una lista può essere acquistato. I server proxy sono belli perché si possono infilare o ruotare se il tappo richiesta viene colpita.

Google è stato abusato dagli utenti Tor e la maggior parte dei nodi di uscita sono sulla lista nera di Google e questo è il motivo per cui si sta rilevando un captcha.

Mi permetta di essere perfettamente chiaro:. non c'è niente che possiamo fare per impedire a qualcuno di RASCHIAMENTO tuo sito

Answer 3

In base alla progettazione dei componenti di rete Tor non è possibile per il ricevitore per scoprire se il richiedente è la fonte originale o se è solo una richiesta inoltrata.

Il comportamento che avete visto con Google è stato probabilmente causato da una misura di sicurezza diverso. Google rileva se un utente connesso cambia IP e presenta un captcha nel caso in cui per evitare l'intercettazione nocive e anche permettere la continuazione della sessione, se un utente autenticato in realtà ha cambiato il suo IP (da ri-accesso a ISP, etc.).

Answer 4

So che questo è vecchio, ma ho ottenuto qui da una ricerca su Google così ho pensato che avrei avuto alle preoccupazioni radice nella domanda qui. I sviluppare applicazioni web, ma ho anche fare un sacco di abuso e lo sfruttamento di altri popoli. Sono probabilmente il ragazzo si sta cercando di tenere fuori.

Rilevazione traffico Tor non è davvero il percorso che si vuole andare qui. È possibile rilevare una buona quantità di server proxy aperti analizzando intestazioni di richiesta, ma hai avuto tor, proxy alti anonimato, proxy SOCKS, VPN a basso costo commercializzati direttamente agli spammer, botnet e innumerevoli altri modi per rompere i limiti della frequenza. È inoltre

Se la vostra preoccupazione principale è un effetto DDoS, non ti preoccupare. Veri attacchi DDoS prendono sia muscolare o qualche vulnerabilità che mette sforzo sul vostro server. Non importa quale tipo di sito che avete, si sta andando ad essere inondati di colpi da ragni così come le persone cattive la scansione per gli exploit. Solo un fatto di vita. In realtà, questo tipo di logica sul server quasi mai scala bene e può essere l'unico punto di guasto che le foglie si apre ad un vero e proprio attacco DDoS.

Questo può anche essere un singolo punto di errore per gli utenti finali (compresi i bot amichevoli). Se un utente legittimo o cliente viene bloccato hai un incubo servizio clienti e se crawler sbagliato si blocca stai dicendo addio al vostro traffico di ricerca.

Se davvero non voglio che nessuno afferrare i dati, ci sono alcune cose che puoi fare. Se si tratta di un contenuto del blog o qualcosa del genere, io in genere dico o non ti preoccupare o hanno riassunto solo i feed RSS se avete bisogno di alimentazioni a tutti. Il pericolo con il contenuto del blog raschiato è che in realtà è abbastanza facile da prendere una copia esatta di un articolo, link di spam ad esso e rango, mentre battendo il fuori originale dei risultati della ricerca. Allo stesso tempo, perché è così facile persone non stanno andando a mettere sforzo in siti specifici mira quando possono raschiare feed RSS alla rinfusa.

Se il tuo sito è più di un servizio con contenuto dinamico che è tutta un'altra storia. Io in realtà raschiare un sacco di siti come questo di "rubare" enormi quantità di dati proprietari strutturati, ma ci sono opzioni per rendere più difficile. È possibile limitare la richiesta per IP, ma che è facile andare in giro con i proxy. Per alcuni reale protezione relativamente semplice offuscamento va un lungo cammino. Se si tenta di fare qualcosa di simile raschiare risultati di Google o scaricare video da YouTube scoprirete che c'è un sacco di reverse engineering. Faccio entrambi, ma il 99% delle persone che cercano falliscono perché non hanno le conoscenze per farlo. Essi possono raschiare proxy per aggirare i limiti IP ma non sono rompere alcuna crittografia.

A titolo di esempio, per quanto mi ricordo di una pagina dei risultati di Google viene fornito con javscript offuscato che viene iniettato nel DOM al caricamento della pagina, quindi una sorta di gettoni sono impostati in modo da avere per analizzare fuori. Poi c'è una richiesta AJAX con quelle pedine che restituisce offuscati JS o JSON che è decodificati per costruire i risultati e così via e così via. Questo non è difficile da fare da parte vostra come lo sviluppatore, ma la stragrande maggioranza dei potenziali ladri non in grado di gestirlo. La maggior parte di quelli che possono non mettere nello sforzo. Faccio questo per avvolgere i servizi veramente di valore di Google, ma per la maggior parte degli altri servizi ho solo andare avanti per un po 'di frutta appeso più basso a diversi fornitori.

Spero che questo è utile per chi viene attraverso di esso.

Answer 5

Credo che l'attenzione su come sia 'impossibile' per evitare che un utente determinato e smaliziati da raschiare un sito web è data troppa importanza. @Drew Noakes afferma che il sito contiene informazioni che se assunto in aggregato ha un po 'di valore'. Se un sito ha dati aggregati che è facilmente accessibile dagli utenti anonimi non vincolati, allora sì, impedendo raschiando può essere vicino 'impossibile'.

vorrei suggerire il problema da risolvere non è come impedire agli utenti di raschiare i dati aggregati, ma piuttosto ciò che si avvicina potrebbe essere utilizzato per rimuovere i dati aggregati di accesso del pubblico; eliminando così l'obiettivo delle ruspe, senza la necessità di fare il 'impossibile', prevenire rottamazione.

I dati aggregati dovrebbe essere trattato come informazioni aziendali proprietarie. Le informazioni proprietarie società in generale, non è pubblicamente disponibile agli utenti anonimi in forma aggregata o crudo. Direi che la soluzione per evitare la presa di dati importanti sarebbe quello di limitare l'accesso e vincolo ai dati, non per impedire la demolizione di esso quando si è presentato per l'utente.

1] Gli account utente / accesso - nessuno dovrebbe mai avere accesso a tutti i dati in un entro un determinato periodo di tempo (dati / dominio specifico). Gli utenti dovrebbero essere in grado di accedere ai dati che è rilevante per loro, ma chiaramente dalla domanda, nessun utente avrebbe uno scopo legittimo per interrogare tutti i dati aggregati. Senza conoscere le specifiche del sito, ho il sospetto che un utente legittimo può essere necessario solo qualche piccolo sottoinsieme di dati entro un certo periodo di tempo. Richiesta che significativamente superiori tipiche esigenze degli utenti devono essere bloccate o alternativamente strozzato, in modo da rendere raschiando tempo proibitivamente consumando ei dati rottamati potenzialmente stantio.

2] team operativi controllano spesso metriche per garantire che i grandi sistemi distribuiti e complessi sono sani. Purtroppo, diventa molto difficile individuare le cause dei problemi sporadici e intermittenti, e spesso è anche difficile identificare che c'è un problema rispetto alle normali fluttuazioni operative. team operativi trattano spesso dati storici statistici analizzati presi da molti numerosi parametri, e confrontandoli con i valori attuali per aiutare a identificare deviazioni significative nella salute del sistema, siano essi del sistema il tempo, il carico, l'utilizzo della CPU, ecc.

Allo stesso modo, le richieste degli utenti per i dati in quantità che sono significativamente maggiori rispetto alla norma potrebbe aiutare a identificare gli individui che possono essere rottamazione dei dati; un tale approccio può anche essere automatizzato e anche ulteriormente esteso a guardare per più account per i modelli che indicano rottamazione. Utente 1 raschia il 10%, degli utenti 2 raschia il 10%, degli utenti 3 raschia il 10%, ecc ... Modelli del genere (e altri) potrebbero fornire forti indicatori di uso scorretto e malizioso del sistema da parte di un singolo individuo o gruppo che utilizza più account

3] Non fare l'dati aggregati grezzi direttamente accessibili agli utenti finali. Specifiche contano qui, ma in poche parole, i dati dovrebbero risiedere su server back-end, e recuperati utilizzando un po 'di dominio specifico API. Ancora una volta, partendo dal presupposto che non sono solo servendo i dati grezzi, ma piuttosto rispondere alle richieste degli utenti di alcuni sottoinsiemi di dati. Ad esempio, se i dati che hai è dettagliato demografia della popolazione per una particolare regione, un utente finale legittima sarebbe interessato a solo un sottoinsieme di tali dati. Ad esempio, un utente finale può essere utile sapere gli indirizzi delle famiglie con bambini che risiedono con entrambi i genitori in alloggi più unità o dati su una specifica città o contea. Tale richiesta una richiederebbe l'elaborazione dei dati aggregati per produrre un insieme di dati risultante che è di interesse per l'utente finale. Sarebbe proibitivo difficile raschiare ogni set di dati risultante recuperato da numerosi potenziali permutazioni della query di ingresso e di ricostruire i dati aggregati nella sua entirety. Un raschietto sarebbe anche limitata dalla sicurezza siti web, tenendo conto del numero di richieste / tempo, la dimensione dei dati totale del set di dati risultante, e altri marcatori potenziali. Una conoscenza specifica del dominio API che incorpora ben sviluppato sarebbe fondamentale nel garantire che l'API è abbastanza completo per servire il suo scopo, ma non eccessivamente generale, in modo da tornare grandi discariche di dati grezzi.

L'incorporazione di account utente al sito, la creazione di linee di base di utilizzo per gli utenti, l'identificazione e la limitazione di utenti (o altro di mitigazione si avvicina) che si discostano significativamente da modelli di utilizzo tipici, e la creazione di un'interfaccia per la richiesta elaborata / set di risultati digerito (vs dati aggregati grezzi) creerebbero complessità significativi per gli individui malintenzionati intenti a rubare i vostri dati. Può essere impossibile impedire la demolizione dei dati dei siti web, ma il 'impossibilità' si basa sui dati aggregati sono facilmente accessibili per il raschietto. Non si può raschiare quello che non si può vedere. Quindi, a meno che i dati aggregati è un testo non elaborato prima (per esempio di biblioteca e-book) gli utenti finali non dovrebbero avere accesso ai dati aggregati grezzi. Anche nell'esempio di e-book biblioteca, deviazione significativa dalla modalità di utilizzo accettabili come richiedente gran numero di libri nel loro complesso dovrebbe essere ostruito o strozzato.

Answer 6

È possibile rilevare gli utenti Tor usando TorDNSEL - https://www.torproject.org /projects/tordnsel.html.en .

Si può semplicemente utilizzare questa riga di comando / library - https://github.com/assafmo/IsTorExit .