¿Cómo detectar solicitudes HTTP entrantes enviadas anónimamente a través de Tor?

Question

Estoy desarrollando un sitio web y soy sensible a la pantalla de personas raspando mis datos. No me preocupa raspar una o dos páginas. Me preocupa más que alguien robe miles de páginas, ya que la suma de esos datos es mucho más valiosa de lo que sería un porcentaje pequeño.

me puedo imaginar estrategias para bloquear a los usuarios basados ​​en el tráfico pesado desde una sola dirección IP, pero los conjuntos Tor network hasta muchos circuitos que significan esencialmente el tráfico de un solo usuario que parece provenir de diferentes direcciones IP a través del tiempo.

Sé que es posible detectar el tráfico Tor ya que cuando instalé Vidalia con su extensión de Firefox, google.com me presentó un captcha.

Entonces, ¿cómo puedo detectar tales solicitudes?

(de mi sitio web en ASP.NET MVC 2, pero yo creo que ningún enfoque utilizado en este caso sería independiente del idioma)

Answer 1

Estoy desarrollando un sitio web y estoy sensible a la gente pantalla de raspado mis datos

Olvídalo. Si está en la web y alguien lo quiere, será imposible para evitar que lo reciba. Cuantas más restricciones ponga en práctica, más arriesgará arruinar la experiencia del usuario para usuarios legítimos, que esperamos sean la mayoría de su público. También hace que el código sea más difícil de mantener.

Voy a publicar contramedidas a cualquier idea que propongan las respuestas futuras.

Answer 2

Por diseño de los componentes de la red tor no es posible que el receptor descubra si el solicitante es la fuente original o si solo se trata de una solicitud retransmitida.

El comportamiento que vio con Google probablemente fue causado por una medida de seguridad diferente. Google detecta si un usuario conectado cambia su ip y presenta un captcha por si acaso para evitar la intercepción dañina y también permite la continuación de la sesión si un usuario autenticado realmente cambió su IP (al volver a iniciar sesión en el ISP, etc.).

Answer 3

Puede verificar su dirección IP con una lista de Tor Exit Nodes. Sé con certeza que esto ni siquiera va a frenar a alguien que está interesado en robar su sitio. Tor es demasiado lento, la mayoría de los raspadores ni siquiera lo considerarán. Hay decenas de miles de servidores proxy abiertos que se pueden escanear fácilmente o se puede comprar una lista. Los servidores proxy son agradables porque puede enhebrarlos o rotar si se golpea el límite de su solicitud.

Google ha sido abusado por los usuarios de tor y la mayoría de los nodos de salida están en la lista negra de Google y es por eso que está obteniendo un captcha.

Déjame estar perfectamente claro: NO HAY NADA QUE PUEDAS HACER PARA IMPEDIR QUE ALGUIEN NO SE RASGUE TU SITIO.

Answer 4

Sé que esto es antiguo, pero llegué aquí de una búsqueda en Google, así que pensé que llegaría a los problemas de raíz en la pregunta aquí. Desarrollo aplicaciones web, pero también abuso mucho y exploto a otras personas. Probablemente soy el tipo que intentas evitar.

La detección del tráfico tor realmente no es la ruta que desea ir aquí.Puede detectar una buena cantidad de servidores proxy abiertos mediante el análisis de encabezados de solicitud, pero tiene tor, proxy de alto anonimato, proxy de calcetines, VPNs baratas comercializadas directamente a spammers, botnets e innumerables otras maneras de romper los límites de velocidad. También

Si su principal preocupación es un efecto DDoS, no se preocupe. Los ataques reales de DDoS toman cualquier músculo o alguna vulnerabilidad que pone tensión en su servidor. No importa qué tipo de sitio tengas, estarás inundado de éxitos de arañas y personas malintencionadas buscando exploits. Solo un hecho de la vida. De hecho, este tipo de lógica en el servidor casi nunca se adapta bien y puede ser el único punto de falla que lo deje expuesto a un verdadero ataque DDoS.

Esto también puede ser un único punto de falla para los usuarios finales (incluidos los bots amigables). Si un usuario o cliente legítimo es bloqueado, tiene una pesadilla de servicio al cliente y si el rastreador incorrecto se bloquea, se está despidiendo del tráfico de búsqueda.

Si realmente no quieres que nadie tome tus datos, hay algunas cosas que puedes hacer. Si se trata de un contenido de blog o algo así, generalmente digo que no te preocupes o que solo tengas un resumen RSS si necesitas algún tipo de alimentación. El peligro con el contenido de blog raspado es que en realidad es bastante fácil tomar una copia exacta de un artículo, enlaces de correo no deseado a él y clasificarlo mientras se elimina el original de los resultados de búsqueda. Al mismo tiempo, debido a que es tan fácil, las personas no se esforzarán en llegar a sitios específicos cuando pueden rastrear los canales RSS de forma masiva.

Si su sitio es más un servicio con contenido dinámico que es otra historia. De hecho, robo una gran cantidad de sitios como este para "robar" grandes cantidades de datos propietarios estructurados, pero hay opciones para hacerlo más difícil. Puede limitar la solicitud por IP, pero eso es fácil de usar con los proxies. Para una protección real, la ofuscación relativamente simple es muy útil. Si intenta hacer algo como eliminar los resultados de Google o descargar videos de YouTube, descubrirá que hay mucho para realizar ingeniería inversa. Hago ambas cosas, pero el 99% de las personas que intentan fracasan porque no tienen el conocimiento para hacerlo. Pueden robar proxies para superar los límites de IP, pero no están rompiendo ningún cifrado.

Como ejemplo, por lo que recuerdo, una página de resultados de Google viene con un javscript ofuscado que se inyecta en el DOM al cargar la página, luego se configuran algunos tokens, por lo que hay que analizarlos. Luego hay una solicitud de ajax con esos tokens que devuelve JS o JSON ofuscado que se decodifica para generar los resultados y así sucesivamente. Esto no es difícil de hacer por su parte como desarrollador, pero la gran mayoría de los ladrones potenciales no pueden manejarlo. La mayoría de los que pueden no pondrán esfuerzo. Hago esto para envolver los servicios realmente valiosos de Google, pero para la mayoría de los otros servicios simplemente paso a algunas frutas que cuelgan más bajo en diferentes proveedores.

Espero que esto sea útil para cualquier persona que lo encuentre.

Answer 5

Creo que el enfoque en cómo es "imposible" evitar que un usuario determinado y conocedor de la técnica robe un sitio web tiene demasiada importancia. @Drew Noakes afirma que el sitio web contiene información que, cuando se toma en conjunto, tiene algún 'valor'. Si un sitio web tiene datos agregados que son fácilmente accesibles para usuarios anónimos no restringidos, entonces sí, evitar rasparlos puede ser casi imposible.

Sugeriría que el problema que hay que resolver no es cómo evitar que los usuarios raspen los datos agregados, sino qué enfoques podrían utilizarse para eliminar los datos agregados del acceso público; eliminando así el objetivo de los raspadores sin la necesidad de hacer lo "imposible", evitar el desguace.

Los datos agregados se deben tratar como información de la empresa propietaria. La información de la compañía propietaria en general no está disponible públicamente para los usuarios anónimos en forma agregada o cruda.Yo argumentaría que la solución para evitar la toma de datos valiosos sería restringir y restringir el acceso a los datos, no para evitar el desguace cuando se presenta al usuario.

1] Cuentas de usuario/acceso: nadie debería tener acceso a todos los datos en un plazo determinado (datos/dominio específico). Los usuarios deben poder acceder a los datos que les son relevantes, pero claramente a partir de la pregunta, ningún usuario tendría un propósito legítimo para consultar todos los datos agregados. Sin conocer los detalles del sitio, sospecho que un usuario legítimo puede necesitar solo un pequeño subconjunto de los datos dentro de un período de tiempo. La solicitud que excede significativamente las necesidades típicas del usuario debe bloquearse o, alternativamente, estrangularse, a fin de que el raspado consuma mucho tiempo y los datos desechados se vuelvan obsoletos.

2] Los equipos de operaciones a menudo controlan las métricas para garantizar que los grandes sistemas distribuidos y complejos sean saludables. Desafortunadamente, resulta muy difícil identificar las causas de los problemas esporádicos e intermitentes, y con frecuencia es incluso difícil identificar que existe un problema en comparación con las fluctuaciones operacionales normales. Los equipos de operaciones a menudo tratan datos estadísticos analizados tomados de muchas mediciones numerosas y las comparan con valores actuales para ayudar a identificar desviaciones significativas en el estado del sistema, ya sea el tiempo de actividad del sistema, carga, utilización de CPU, etc.

De forma similar, las solicitudes de los usuarios para datos en cantidades que son significativamente mayores que la norma podría ayudar a identificar individuos que probablemente estén eliminando datos; Tal enfoque puede incluso automatizarse e incluso extenderse más para buscar patrones que indiquen desguace en múltiples cuentas. Usuario 1 raspa 10%, usuario 2 raspa el siguiente 10%, usuario 3 raspa el siguiente 10%, etc ... Patrones como ese (y otros) podrían proporcionar indicadores fuertes de uso malicioso del sistema por un solo individuo o grupo utilizando cuentas múltiples

3] No haga que los datos agregados sin procesar sean accesibles directamente para los usuarios finales. Las especificaciones importan aquí, pero en pocas palabras, los datos deberían residir en servidores back-end y recuperarse utilizando alguna API específica del dominio. De nuevo, supongo que no solo está sirviendo datos brutos, sino que responde a las solicitudes de los usuarios de algunos subconjuntos de datos. Por ejemplo, si los datos que posee son datos demográficos detallados de la población de una región en particular, un usuario final legítimo solo estaría interesado en un subconjunto de esos datos. Por ejemplo, un usuario final puede querer conocer direcciones de hogares con adolescentes que residen con ambos padres en viviendas de unidades múltiples o datos en una ciudad o condado específico. Tal solicitud requeriría el procesamiento de los datos agregados para producir un conjunto de datos resultante que sea de interés para el usuario final. Sería prohibitivamente difícil eliminar todos los conjuntos de datos resultantes obtenidos de numerosas permutaciones potenciales de la consulta de entrada y reconstruir los datos agregados en su totalidad. Un raspador también estaría restringido por la seguridad de los sitios web, teniendo en cuenta el número de solicitudes/tiempo, el tamaño total de los datos del conjunto de datos resultante y otros posibles marcadores. Una API bien desarrollada que incorpore conocimiento específico del dominio sería fundamental para garantizar que la API sea lo suficientemente exhaustiva como para cumplir su propósito, pero no demasiado general para devolver volcados de datos brutos grandes.

Incorporación de cuentas de usuario en el sitio, establecimiento de líneas base de uso para usuarios, identificación y regulación de usuarios (u otros enfoques de mitigación) que se desvían significativamente de los patrones de uso típicos y creación de una interfaz para solicitar los conjuntos de resultados procesados ​​/ digeridos (frente a los datos agregados sin procesar) crearían complejidades significativas para las personas malintencionadas que intentan robar sus datos. Puede ser imposible evitar el desguace de los datos del sitio web, pero la 'imposibilidad' se basa en que los datos agregados sean fácilmente accesibles para el raspador. No puedes raspar lo que no puedes ver. Por lo tanto, a menos que los datos agregados sean texto no procesado sin formato (por ejemplo, libros electrónicos de biblioteca), los usuarios finales no deberían tener acceso a los datos agregados sin formato. Incluso en el ejemplo del libro electrónico de la biblioteca, la desviación significativa de los patrones de uso aceptables, como la solicitud de un gran número de libros en su totalidad, debe bloquearse o acelerarse.