scripting - español - Evitando que los guionistas cierren su sitio web

flow chatbot (30)

Vende el artículo a humanos sin scripts.
Mantener el sitio funcionando a una velocidad no disminuida por los robots.
No moleste a los usuarios "normales" con las tareas que deben completar para demostrar que son humanos.

Probablemente no quieras escuchar esto, pero los números 1 y 3 se excluyen mutuamente.

Bueno, nadie sabe que eres un bot tampoco. No hay una manera programática de saber si hay o no un humano en el otro extremo de la conexión sin requerir que la persona haga algo. Evitar que los scripts / bots hagan cosas en la web es la razón principal por la que se inventaron los CAPTCHA. No es como si se tratara de un problema nuevo en el que no se haya invertido mucho esfuerzo. Si hubiera una mejor manera de hacerlo, una que no implicara la molestia para los usuarios reales que tiene un CAPTCHA, todos lo estarían usando ya.

Creo que debes enfrentar el hecho de que si quieres mantener a los bots fuera de tu página de pedidos, una buena CAPTCHA es la única manera de hacerlo. Si la demanda de su basura aleatoria es lo suficientemente alta como para que la gente esté dispuesta a hacer todo lo posible para obtenerla, los CAPTCHA no van a dejar de lado a los usuarios legítimos.

He aceptado una respuesta, pero lamentablemente, creo que estamos atascados con nuestro peor escenario original: CAPTCHA a todos en los intentos de compra de la basura . Explicación breve: el almacenamiento en caché / las granjas de servidores web hacen imposible rastrear los resultados, y cualquier solución alternativa (el envío de un web-beacon sin almacenamiento en caché, la escritura en una tabla unificada, etc.) ralentiza el sitio más de lo que lo harían los robots. Es probable que haya algún hardware costoso de Cisco o similar que pueda ayudar a un alto nivel, pero es difícil justificar el costo si CAPTCHA es una alternativa para todos. Intentaré una explicación más completa más adelante, además de limpiar esto para futuros buscadores (aunque otros son bienvenidos a intentarlo, ya que es wiki de la comunidad).

Situación

Esto se trata de las ventas de maletas en woot.com. Soy el presidente de Woot Workshop, la subsidiaria de Woot que hace el diseño, escribe las descripciones de los productos, podcasts, publicaciones de blog y modera los foros. Trabajo con CSS / HTML y apenas estoy familiarizado con otras tecnologías. Trabajo estrechamente con los desarrolladores y he explicado todas las respuestas aquí (y muchas otras ideas que hemos tenido).

La usabilidad es una parte importante de mi trabajo, y hacer que el sitio sea emocionante y divertido es la mayor parte del resto. Ahí es donde se derivan los tres objetivos siguientes. CAPTCHA perjudica la facilidad de uso, y los robots roban la diversión y la emoción de nuestras ventas de basura.

Los bots están golpeando nuestra página principal decenas de veces por segundo raspado de pantalla (y / o escaneando nuestro RSS) para la venta de Random Crap. En el momento en que ven eso, se activa una segunda etapa del programa que inicia sesión, hace clic en el botón "Quiero", rellena el formulario y compra la basura.

Evaluación

lc : En stackoverflow y otros sitios que utilizan este método, casi siempre tratan con usuarios autenticados (registrados), porque la tarea que se intenta realizar requiere eso.

En Woot, los usuarios anónimos (no registrados) pueden ver nuestra página de inicio. En otras palabras, los robots de slamming pueden no estar autenticados (y esencialmente no rastreables, excepto por la dirección IP).

Así que volvemos a buscar IPs, que a) es bastante inútil en esta era de redes en la nube y zombies con spambot yb) captura demasiados inocentes dada la cantidad de empresas que provienen de una dirección IP (por no mencionar los problemas con Los ISP IP no estáticos y los posibles resultados de rendimiento al intentar realizar un seguimiento de esto).

Ah, y que la gente nos llame sería el peor escenario posible. ¿Podemos hacer que te llamen?

BradC : los métodos de Ned Batchelder se ven muy bien, pero están bastante bien diseñados para derrotar a los robots creados para una red de sitios. Nuestro problema es que los robots están diseñados específicamente para derrotar a nuestro sitio. Es probable que algunos de estos métodos funcionen por un corto tiempo hasta que los guionistas hayan desarrollado sus robots para ignorar el honeypot, rastrear los nombres de las etiquetas cercanas en lugar de los identificadores de formularios y usar un control de navegador con capacidad de javascript.

De nuevo, "a menos que, por supuesto, la exageración sea parte de su esquema de marketing". Sí, definitivamente lo es. La sorpresa de cuando aparece el artículo, así como la emoción de conseguir uno es probablemente más o más importante que la basura que realmente terminas recibiendo. Cualquier cosa que elimine el primer llegado / primer servicio es perjudicial para la emoción de "ganar" la basura.

novatrust : Y yo, por mi parte, doy la bienvenida a nuestros nuevos amos bot. En realidad, ofrecemos RSSfeeds para permitir que aplicaciones de terceros escaneen nuestro sitio para obtener información sobre el producto, pero no antes del HTML principal del sitio. Si lo interpreto correctamente, su solución ayuda al objetivo 2 (problemas de rendimiento) al sacrificar completamente el objetivo 1, y simplemente renunciando al hecho de que los robots comprarán la mayor parte de la basura. Yo voté a favor de su respuesta, porque el pesimismo de su último párrafo me parece exacto. Parece que no hay una bala de plata aquí.

El resto de las respuestas generalmente se basan en el seguimiento de IP, que, una vez más, parece ser inútil (con botnets / zombies / redes en la nube) y perjudicial (captura de muchos inocentes que provienen de destinos con la misma IP).

¿Algún otro enfoque / ideas? Mis desarrolladores siguen diciendo "solo hagamos CAPTCHA" pero espero que haya métodos menos intrusivos para todos los humanos que quieren algo de nuestra basura.

Pregunta original

Digamos que está vendiendo algo barato que tiene un valor percibido muy alto y tiene una cantidad muy limitada. Nadie sabe exactamente cuándo venderás este artículo. Y más de un millón de personas acuden regularmente para ver lo que estás vendiendo.

Terminas con scripters y robots que intentan descifrar programáticamente [a] cuando estás vendiendo dicho artículo, y [b] asegúrate de que estén entre los primeros en comprarlo. Esto apesta por dos razones:

Su sitio está bloqueado por personas que no son humanos, lo que ralentiza todo para todos.
Los guionistas terminan ''ganando'' el producto, haciendo que los clientes habituales se sientan engañados.

Una solución aparentemente obvia es crear algunos aros para que los usuarios puedan saltar antes de realizar su pedido, pero hay al menos tres problemas con esto:

La experiencia del usuario apesta para los humanos, ya que tienen que descifrar CAPTCHA, elegir el gato o resolver un problema de matemáticas.
Si el beneficio percibido es lo suficientemente alto, y la multitud es lo suficientemente grande, algún grupo encontrará su camino alrededor de cualquier pellizco, lo que lleva a una carrera de armamentos. (Esto es especialmente cierto cuanto más simple es el tweak; forma oculta de ''comentarios'', reorganización de los elementos del formulario, etiquetado incorrecto, texto ''gotcha'' oculto; todo funcionará una vez y luego deberá cambiarse para luchar contra esta forma específica. .)
Incluso si los guionistas no pueden "resolver" su ajuste, no les impide cerrar su página de inicio, y luego hacer sonar una alarma para que el guionista complete el pedido, manualmente. Dado que obtienen la ventaja de resolver [a], es probable que sigan ganando [b] ya que serán los primeros humanos en llegar a la página de pedidos. Además, 1. sigue ocurriendo, lo que provoca errores en el servidor y un menor rendimiento para todos.

Otra solución es vigilar que las direcciones IP lleguen demasiado a menudo, bloquearlas desde el firewall o evitar que hagan pedidos. Esto podría resolver 2. y prevenir [b] pero el impacto en el rendimiento del escaneo de IP es masivo y probablemente causaría más problemas como 1. que los scripters estaban causando por sí solos. Además, la posibilidad de redes en la nube y zombis de spambot hace que la verificación de IP sea bastante inútil.

Una tercera idea, forzar la carga del formulario de pedido durante algún tiempo (por ejemplo, medio segundo) podría ralentizar el progreso de las órdenes rápidas, pero, una vez más, los autores de guiones aún serían los primeros en ingresar, a cualquier velocidad que no sea perjudicial para usuarios reales

Metas

Vende el artículo a humanos sin scripts.
Mantener el sitio funcionando a una velocidad no disminuida por los robots.
No moleste a los usuarios "normales" con las tareas que deben completar para demostrar que son humanos.

Proporcione un feed RSS para que no consuman su ancho de banda.
Cuando compre, haga que todos esperen un tiempo aleatorio de hasta 45 segundos o algo, dependiendo de lo que esté buscando exactamente. Exactamente, ¿cuáles son sus limitaciones de tiempo?
Deles a todos un minuto para que pongan su nombre en el dibujo y luego seleccionen personas al azar. Creo que esta es la forma más justa.
Supervisar las cuentas (¿incluir algunas veces en la sesión y almacenarlas?) Y agregar retrasos a las cuentas que parecen estar por debajo del umbral de velocidad humana. Eso hará que al menos los bots estén programados para frenar y competir con los humanos.

¿Qué hay de implementar algo como SO con los CAPTCHA?

Si está utilizando el sitio normalmente, probablemente nunca verá uno. Si vuelves a cargar la misma página con demasiada frecuencia, publica comentarios sucesivos demasiado rápido, o alguna otra cosa que active una alarma, haz que demuestren que son humanos. En su caso, esto probablemente sea una recarga constante de la misma página, siguiendo rápidamente todos los enlaces de una página o rellenando un formulario de pedido demasiado rápido para ser humano.

Si no pasan la verificación x veces seguidas (por ejemplo, 2 o 3), dale a esa IP un tiempo de espera u otra medida similar. Luego, al final del tiempo de espera, vuelva a colocarlos en el cheque.

Ya que tiene usuarios no registrados que acceden al sitio, solo tiene IP para continuar. Puede emitir sesiones a cada navegador y realizar un seguimiento de esa manera si lo desea. Y, por supuesto, arroje un cheque humano si se están (re) creando demasiadas sesiones en sucesión (en caso de que un bot siga eliminando la cookie).

Con respecto a la captura de demasiados inocentes, puede poner un descargo de responsabilidad en la página de control humano: "Esta página también puede aparecer si hay demasiados usuarios anónimos viendo nuestro sitio desde la misma ubicación. Le recomendamos registrarse o iniciar sesión para evitar esta." (Ajuste la redacción de manera apropiada.)

Además, ¿cuáles son las probabilidades de que X personas estén cargando la misma página (s) al mismo tiempo desde una IP? Si son altos, quizás necesite un mecanismo de activación diferente para su alarma de bot.

Edición: Otra opción es si fallan muchas veces, y confía en la demanda del producto, para bloquearlos y hacer que lo llamen personalmente para eliminar el bloqueo.

Hacer que las personas llamen parece una medida estúpida, pero se asegura de que haya un humano detrás de la computadora . La clave es tener el bloque solo en su lugar para una condición que casi nunca debería suceder a menos que sea un bot (por ejemplo, reprobar la comprobación varias veces seguidas). Entonces FUERZA la interacción humana - para levantar el teléfono.

En respuesta al comentario de que me llamen, obviamente hay una compensación aquí. ¿Está lo suficientemente preocupado como para asegurarse de que sus usuarios sean humanos para aceptar un par de llamadas telefónicas cuando salgan a la venta? Si estuviera tan preocupado por un producto que llegara a los usuarios humanos, tendría que tomar esta decisión, tal vez sacrificando un poco de mi tiempo en el proceso.

Ya que parece que estás decidido a no permitir que los bots se pongan a la vanguardia de tu sitio, creo que el teléfono puede ser una buena opción. Como no obtengo ganancias de su producto, no tengo ningún interés en recibir estas llamadas. Sin embargo, si compartieras parte de ese beneficio, podría interesarme. Como este es su producto, usted tiene que decidir cuánto le importa e implementarlo en consecuencia.

Las otras formas de liberar el bloque simplemente no son tan efectivas: un tiempo de espera (pero luego volverán a cerrar su sitio, enjuague y repita), un tiempo de espera largo (si realmente fue un humano tratando de comprar su producto, serían SOL y castigados por fallar el cheque), correo electrónico (fácilmente hecho por bots), fax (mismo), o correo postal (toma demasiado tiempo).

Por supuesto, podría tener el aumento del período de espera por IP para cada vez que tengan un tiempo de espera. Solo asegúrate de no castigar inadvertidamente a los verdaderos humanos.

Descargo de responsabilidad: Esta respuesta es completamente no relacionada con la programación. Sin embargo, intenta atacar la razón de los scripts en primer lugar.

Otra idea es si realmente tienes una cantidad limitada para vender, ¿por qué no la cambias de una metodología por orden de llegada? A menos que, por supuesto, el bombo sea parte de su esquema de marketing.

Hay muchas otras opciones, y estoy seguro de que otras pueden pensar en algunas diferentes:

una cola de pedidos (sistema de pedido anticipado): algunas secuencias de comandos pueden terminar en la parte delantera de la cola, pero probablemente sea más rápido solo ingresar la información manualmente.
un sistema de rifa (todos los que intentan pedir uno ingresan al sistema): de esta manera, las personas con los scripts tienen las mismas oportunidades que los que no tienen.
una cola de prioridad rápida: si realmente hay un alto valor percibido, las personas pueden estar dispuestas a pagar más. Implemente una cola de pedidos, pero permita que las personas paguen más para que se coloquen más arriba en la cola.
Subasta (el crédito es de David Schmitt para este, los comentarios son míos): la gente todavía puede usar los scripts para atacar a último momento, pero no solo cambia la estructura de precios, sino que espera luchar contra otros. . También puede hacer cosas para restringir el número de ofertas en un período de tiempo determinado, hacer que las personas telefonen con anticipación para obtener un código de autorización, etc.

Echa un vistazo a este artículo de ned Batchelder aquí . Su artículo trata sobre detener spambots, pero las mismas técnicas podrían aplicarse fácilmente a su sitio.

En lugar de detener a los bots haciendo que las personas se identifiquen a sí mismas, podemos detener a los bots haciendo que sea difícil para ellos hacer una publicación exitosa, o hacer que se identifiquen inadvertidamente como bots. Esto elimina la carga de la gente y deja el formulario de comentarios libre de medidas antispam visibles.
Esta técnica es cómo prevengo los spambots en este sitio. Funciona. El método descrito aquí no mira el contenido en absoluto.

Algunas otras ideas:

Cree un mecanismo oficial de notificación automática (¿RSS? ¿Twitter?) Al que las personas puedan suscribirse cuando su producto salga a la venta. Esto reduce la necesidad de que las personas hagan guiones.
Cambie su técnica de ofuscación justo antes de que salga a la venta un nuevo artículo. Así que incluso si los guionistas pueden escalar la carrera de armamentos, siempre están un día atrás.

EDITAR: Para ser totalmente claro, el artículo de Ned anterior describe métodos para evitar la COMPRA automática de artículos al evitar que un BOT pase por los formularios para enviar un pedido. Sus técnicas no serían útiles para evitar que los robots rasguen la pantalla de la página de inicio para determinar cuándo sale a la venta un bandolero de zanahorias. No estoy seguro de que prevenir eso sea realmente posible.

Con respecto a sus comentarios sobre la efectividad de las estrategias de Ned: Sí, él discute los honeypots, pero no creo que esa sea su estrategia más fuerte. Su discusión del SPINNER es la razón original por la que mencioné su artículo. Lo siento, no puse eso en claro en mi publicación original:

El spinner es un campo oculto que se usa para algunas cosas: reúne una serie de valores que evitan la manipulación y las repeticiones, y se utiliza para ocultar los nombres de los campos. El spinner es un hash MD5 de:
La marca de tiempo,
La dirección IP del cliente,
El id de entrada de la entrada de blog que se está comentando, y
Un secreto.

Aquí es cómo podría implementar eso en WOOT.com:

Cambie el valor "secreto" que se usa como parte del hash cada vez que un nuevo artículo sale a la venta. Esto significa que si alguien va a diseñar un BOT para la compra automática de artículos, ¡ solo funcionará hasta que el siguiente artículo salga a la venta !

Incluso si alguien puede reconstruir rápidamente su bot, todos los demás usuarios reales ya habrán comprado un BOC, y su problema se resolverá.

La otra estrategia que discute es cambiar la técnica de honeypot de vez en cuando (nuevamente, cambiarla cuando un nuevo artículo salga a la venta):

Use clases CSS (aleatorias, por supuesto) para establecer los campos o un elemento contenedor para mostrar: ninguno.
Colorea los campos del mismo fondo (o muy similar al) de la página.
Utilice la posición para mover un campo fuera del área visible de la página.
Haga un elemento demasiado pequeño para mostrar el campo honeypot contenido.
Deje los campos visibles, pero use la posición para cubrirlos con un elemento oculto.
Use Javascript para realizar cualquiera de estos cambios, requiriendo que un bot tenga un motor Javascript completo.
Deje los honeypots mostrados como en los otros campos, pero dígales a las personas que no ingresen nada en ellos.

Supongo que mi idea general es CAMBIAR EL DISEÑO DEL FORMATO cuando cada nuevo artículo salga a la venta. O, por lo menos, cambiarlo cuando salga a la venta un nuevo BOC.

¿Qué es qué, un par de veces / mes?

Si acepta esta respuesta, ¿me avisará cuándo se debe entregar la próxima? :)

El método que usa Woot para combatir este problema es cambiar el juego, literalmente. Cuando presentan un artículo extraordinariamente deseable para la venta, hacen que los usuarios jueguen un videojuego para ordenarlo.

Eso no solo combate con éxito a los bots (pueden hacer cambios menores en el juego para evitar jugadores automáticos, o incluso proporcionar un nuevo juego para cada venta) sino que también da la impresión a los usuarios de "ganar" el elemento deseado mientras se ralentiza El proceso de pedido.

Todavía se vende muy rápidamente, pero creo que la solución es buena: reevaluar el problema y cambiar los parámetros condujo a una estrategia exitosa donde las soluciones estrictamente técnicas simplemente no existían.

Todo su modelo de negocio se basa en el "primer llegado, el primer servicio". No puede hacer lo que hicieron las emisoras de radio (ya no hacen ganadora a la primera persona que llama, hacen ganadora a la 5ª o 20ª o 13ª), no coincide con su función principal.

No, no hay forma de hacerlo sin cambiar la experiencia de pedido para los usuarios reales.

Digamos que implementas todas estas tácticas. Si decido que esto es importante, simplemente conseguiré que 100 personas trabajen conmigo, compilaremos el software para que funcione en nuestras 100 computadoras separadas y golpearemos su sitio 20 veces por segundo (5 segundos entre los accesos para cada usuario / cookie / cuenta / dirección IP).

Tienes dos etapas:

Viendo la portada
Ordenando

No puedes poner un bloqueo de captcha # 1, eso va a perder clientes reales ("¿Qué? Tengo que resolver un captcha cada vez que quiero ver el último woot?!?").

Así que mi pequeño grupo mira, sincronizado para que obtengamos alrededor de 20 cheques por segundo, y quien vea el cambio primero alerta a todos los demás (automáticamente), quién cargará la portada una vez más, seguirá el enlace del pedido y realizará la transacción ( lo que también puede suceder automáticamente, a menos que implemente captcha y lo cambie para cada wootoff / boc).

Puedes poner un captcha frente al # 2, y aunque detestes hacerlo, esa puede ser la única forma de asegurarte de que incluso si los robots miran la página principal, los usuarios reales obtengan los productos.

Pero incluso con captcha, mi pequeña banda de 100 aún tendría una ventaja significativa en el primer movimiento, y no hay manera de que puedas decir que no somos humanos. Si empiezas a cronometrar nuestros accesos, solo añadiríamos un poco de jitter. Podríamos seleccionar aleatoriamente qué computadora se iba a actualizar, por lo que el orden de los accesos cambia constantemente, pero aún parece lo suficientemente humano.

Primero, deshazte de los simples bots.

Debe tener un servidor de seguridad adaptable que vea las solicitudes y, si alguien está haciendo algo obvio y estúpido: actualizar más de una vez por segundo con la misma IP, emplear tácticas para reducir la velocidad (dejar paquetes, enviar rechazados o 500 errores, etc.) ).

Esto debería reducir significativamente su tráfico y alterar las tácticas que emplean los usuarios de bot.

Segundo, haz que el servidor sea increíblemente rápido.

Realmente no quieres escuchar esto ... pero ...

Creo que lo que necesita es una solución totalmente personalizada desde abajo hacia arriba.

No necesita meterse con la pila TCP / IP, pero es posible que necesite desarrollar un servidor personalizado muy, muy, muy rápido, diseñado específicamente para correlacionar las conexiones de los usuarios y reaccionar adecuadamente ante varios ataques.

Apache, lighthttpd, etc. son excelentes para ser flexibles, pero usted ejecuta un sitio web de un solo propósito, y realmente necesita poder hacer más de lo que los servidores actuales son capaces de hacer (tanto para manejar el tráfico como para combatir adecuadamente los bots). ).

Al servir una página web en gran parte estática (se actualiza cada 30 segundos aproximadamente) en un servidor personalizado, no solo debe ser capaz de manejar 10 veces el número de solicitudes y el tráfico (porque el servidor no hace nada más que recibir la solicitud y leer) la página de la memoria en el búfer TCP / IP) pero también le dará acceso a métricas que podrían ayudarlo a reducir la velocidad de los bots. Por ejemplo, al correlacionar las direcciones IP, simplemente puede bloquear más de una conexión por segundo por IP. Los humanos no pueden ir más rápido que eso, e incluso las personas que usan la misma dirección IP con NAT solo serán bloqueadas con poca frecuencia. Usted querría hacer un bloqueo lento: deje la conexión sola durante un segundo completo antes de finalizar oficialmente la sesión. Esto puede alimentar un firewall para proporcionar bloqueos a largo plazo a los infractores especialmente graves.

Pero la realidad es que no importa lo que hagas, no hay forma de diferenciar a un humano de un bot cuando el bot está hecho a la medida por un humano para un solo propósito. El bot es simplemente un proxy para el humano.

Conclusión

Al final del día, no se puede distinguir a un humano y una computadora para ver la página principal. Puede detener los bots en el paso de pedido, pero los usuarios del bot aún tienen la ventaja de ser los primeros en mover, y usted todavía tiene una gran carga que administrar.

Puede agregar bloques para los robots simples, lo que elevará el nivel y menos personas se molestarán con ello. Eso puede ser suficiente.

Pero sin cambiar tu modelo básico, estás fuera de suerte. Lo mejor que puede hacer es ocuparse de los casos simples, hacer que el servidor sea tan rápido que los usuarios regulares no se den cuenta, y vender tantos artículos que incluso si tiene unos pocos millones de bots, tantos usuarios regulares como los deseen los obtendrán. .

Podría considerar configurar un honeypot y marcar cuentas de usuario como usuarios de bot, pero eso tendrá una enorme reacción negativa de la comunidad.

Cada vez que pienso en un "bueno, qué hay de hacer esto ..." siempre puedo contrarrestarlo con una estrategia de bot adecuada.

Incluso si hace que la página principal sea un captcha para llegar a la página de pedido ("El botón de pedido de este artículo es azul con destellos rosas, en algún lugar de esta página") los robots simplemente abrirán todos los enlaces de la página y utilizarán el que sea que venga. Volver con una página de pedidos. Esa no es manera de ganar esto.

Haga que los servidores sean rápidos, coloque un reCaptcha (el único que he encontrado que no se puede engañar fácilmente, pero probablemente sea demasiado lento para su aplicación) en la página de pedidos, y piense en maneras de cambiar el modelo un poco. Los usuarios regulares tienen una buena oportunidad como los usuarios de bot.

-Adán

El problema parece ser que los bots quieren su "bolsa o basura" porque tiene un alto valor percibido a un bajo precio percibido. A veces se ofrece este artículo y los bots están al acecho, esperando ver si está disponible y luego compran el artículo.

Dado que parece que los propietarios de bot están obteniendo ganancias (o potencialmente están obteniendo ganancias), el truco es hacer que esto no sea rentable para ellos alentándolos a comprar la basura.

Primero, siempre ofrezca la "bolsa ''o basura".

Segundo, asegúrate de que la mierda sea usualmente basura.

Tercero, rota la mierda frecuentemente.

Simple, no?

Necesitarás un permanente "¿por qué nuestra mierda es a veces basura?" Enlace al lado de la oferta para explicar a los humanos lo que está pasando.

Cuando el robot vea que hay basura y la basura se compra automáticamente, el destinatario se va a enojar mucho porque pagó $ 10 por un palillo roto. Y luego una bolsa de basura vacía. Y luego un poco de suciedad del fondo de tu zapato.

Si compran suficiente cantidad de esta basura en un período de tiempo relativamente corto (y usted tiene grandes renuncias de responsabilidad por todas partes explicando por qué está haciendo esto), perderán una buena cantidad de dinero en efectivo en su cuenta. bolsa ''o basura ". Incluso la intervención humana de su parte (verificar que la mierda no sea una mierda) puede fallar si la rota con la suficiente frecuencia. Demonios, tal vez los bots se darán cuenta y no comprarán nada que haya estado en la rotación durante demasiado poco tiempo, pero eso significa que los humanos comprarán la no basura.

Diablos, sus clientes habituales podrían estar tan entretenidos que puede convertir esto en una gran ganancia de marketing. Comience a publicar cuánto de la "basura" se vende carpa. La gente regresará solo para ver cuán duro han sido mordidos los robots.

Actualización: espero que reciba algunas llamadas por adelantado con la gente quejándose. No creo que puedas detener eso por completo. Sin embargo, si esto mata a los robots, siempre puedes detenerlo y reiniciarlo más tarde.

Mi solución sería hacer que el raspado de la pantalla no valga la pena poniendo un retraso de aproximadamente 10 minutos para ''bots y scripts.

Así es como lo haría:

Registrar e identificar los bateadores de repetición.

No es necesario registrar cada dirección IP en cada golpe. Solo rastrea uno de cada 20 hits más o menos. Un infractor reincidente seguirá apareciendo en un seguimiento ocasional aleatorio.

Mantenga un caché de su página desde unos 10 minutos antes.
Cuando un bateador repetido / bot golpee su sitio, entrégueles la página almacenada en caché de 10 minutos.

No sabrán de inmediato que están obteniendo un sitio viejo. Podrán rasparlo, y todo, pero ya no ganarán ninguna carrera, porque las "personas reales" tendrán una ventaja de 10 minutos.

Beneficios:

Sin problemas ni problemas para los usuarios (como CAPTCHA).
Implementado completamente en el lado del servidor. (No dependa de Javascript / Flash)
Servir una página más antigua y en caché debería ser menos intensivo en rendimiento que una página en vivo. ¡De hecho, puede disminuir la carga en sus servidores de esta manera!

Inconvenientes

Requiere seguimiento de algunas direcciones IP
Requiere mantener y mantener un caché de páginas antiguas.

¿Qué piensas?

Necesitas encontrar una manera de hacer que los bots compren cosas que son excesivamente caras: 12mm wingnut: $ 20. Mira cuántos bots se activan antes de que los guionistas decidan que los estás jugando.

Utilice los beneficios para comprar más servidores y pagar por el ancho de banda.

No sé qué tan factible es esto ... ... pasar a la ofensiva.

Averigua qué datos están buscando los robots. Aliméntales los datos que están buscando cuando NO estás vendiendo la basura. Haga esto de una manera que no moleste ni confunda a los usuarios humanos. Cuando los bots activen la fase dos, iniciarán sesión y llenarán el formulario para comprar $ 100 roombas en lugar de BOC. Por supuesto, esto supone que los robots no son particularmente robustos.

Otra idea es implementar caídas de precios al azar en el transcurso del período de venta de bolsas o basura. ¿Quién compraría una bolsa de basura al azar por $ 150 cuando ESTAS CLARAMENTE que solo vale $ 20? Nadie más que los robots demasiado entusiastas. Pero luego 9 minutos más tarde es de $ 35 dólares ... luego 17 minutos más tarde es de $ 9. O lo que sea.

Claro, los reyes zombies podrían reaccionar. El punto es hacer que sus errores se vuelvan muy costosos para ellos (y hacer que te paguen para luchar contra ellos).

Todo esto supone que quieres molestar a algunos lores bot, lo que puede no ser 100% recomendable.

P: ¿Cómo detendrías a los scripters de cerrar tu sitio cientos de veces por segundo?
A: No lo haces. No hay forma de prevenir este comportamiento por agentes externos.

Podría emplear una amplia gama de tecnología para analizar las solicitudes entrantes e intentar de forma heurística determinar quién es y qué no es humano ... pero fallaría. Eventualmente, si no de inmediato.

La única solución viable a largo plazo es cambiar el juego para que el sitio no sea compatible con los robots, o sea menos atractivo para los creadores de scripts.

¿Cómo haces eso? Bueno, esa es una pregunta diferente! ;-)

...

OK, algunas opciones han sido dadas (y rechazadas) arriba. No estoy íntimamente familiarizado con su sitio, ya que lo he visto solo una vez, pero como la gente puede leer texto en imágenes y los robots no pueden hacer esto fácilmente, cambie el anuncio para que sea una imagen. No es un CAPTCHA , solo una imagen -

generar la imagen (por supuesto, en caché) cuando se solicita la página
Mantén el nombre de la fuente de la imagen igual, para que no regale el juego.
la mayoría de las veces, la imagen tendrá texto normal y se alineará para que parezca que forma parte de la página HTML en línea
cuando el juego está ''activado'', la imagen cambia al texto del anuncio
El texto del anuncio revela una URL y / o un código que debe ingresarse manualmente para obtener el premio. CAPTCHA el código si lo desea, pero probablemente no sea necesario.
Para mayor seguridad, el código puede ser un token de una sola vez generado específicamente para la solicitud / IP / agente, por lo que las solicitudes repetidas generan códigos diferentes. O puede generar previamente un grupo de códigos aleatorios (un pad de una sola vez) si la generación a pedido es demasiado exigente.

Ejecute las pruebas de tiempo de personas reales que responden a esto, e ignore (''oops, ocurrió un error, lo siento, por favor, inténtelo de nuevo'') las respuestas más rápido que (digamos) la mitad de este tiempo. Este evento también debe activar una alerta para los desarrolladores de que al menos un bot ha descubierto el código / juego, por lo que es hora de cambiar el código / juego.

Continúa cambiando el juego periódicamente de todos modos, incluso si ningún bots lo activa, solo para desperdiciar el tiempo de los guionistas. Eventualmente, los guionistas deberían cansarse del juego e ir a otro lugar ... esperamos ;-)

Una sugerencia final: cuando ingrese una solicitud para su página principal, póngala en una cola y responda a las solicitudes en orden en un proceso separado (es posible que tenga que hackear / extender el servidor web para hacer esto, pero es probable que sea vale la pena). Si llega otra solicitud del mismo IP / agente mientras la primera solicitud está en la cola, ignórela. Esto debería deshacerse automáticamente de la carga de los robots.

EDITAR: otra opción, aparte del uso de imágenes, es usar javascript para completar el texto de comprar / no comprar; los bots rara vez interpretan javascript, por lo que no lo verían

¿Cómo sabes que hay guionistas haciendo pedidos?

El quid de su problema es que no puede separar a los guionistas de los usuarios legítimos y, por lo tanto, no puede bloquearlos, así que, ¿cómo es posible que sepa que hay guionistas?

Si tiene una manera de responder a esta pregunta, entonces tiene un conjunto de características que puede usar para filtrar los scripters.

En primer lugar, por definición, es imposible admitir transacciones sin estado, es decir, realmente anónimas, al mismo tiempo que se pueden separar los robots de los usuarios legítimos.

Si podemos aceptar la premisa de que podemos imponer algún costo a un nuevo visitante de woot en su primera página, creo que tengo una posible solución. A falta de un nombre mejor, voy a llamar libremente a esta solución "Una visita al DMV".

Digamos que hay un concesionario de automóviles que ofrece un automóvil nuevo diferente cada día, y que en algunos días puede comprar un automóvil deportivo exótico por $ 5 cada uno (límite 3), más un cargo de destino de $ 5.

El problema es que el concesionario requiere que usted visite el concesionario y muestre una licencia de conducir válida antes de que se le permita entrar por la puerta para ver qué automóvil está en oferta. Además, debe tener dicha licencia de conducir válida para realizar la compra.

Entonces, al visitante que lo visita por primera vez (llamémosle Bob) a este concesionario de automóviles se le niega la entrada y se lo remite a la oficina del DMV (que está convenientemente ubicada justo al lado) para obtener una licencia de conducir.

Se permite el ingreso de otros visitantes con una licencia de conducir válida, después de mostrar su licencia de conducir. Una persona que se molesta al merodear por todo el día, acosar a los vendedores, tomar folletos y vaciar el café y las galletas de cortesía será rechazada.

Ahora, volviendo a Bob sin la licencia, todo lo que tiene que hacer es soportar la visita al DMV una vez. Después de eso, puede visitar el concesionario y comprar automóviles en cualquier momento que quiera, a menos que accidentalmente haya dejado su billetera en su casa o su licencia sea destruida o revocada.

La licencia de conducir en este mundo es casi imposible de falsificar.

La visita al DMV implica primero obtener el formulario de solicitud en la cola "Comience aquí". Bob tiene que llevar la solicitud completa a la ventana # 1, donde el primero de los muchos funcionarios maleducados tomará su solicitud, la procesará y, si todo está en orden, selle la solicitud de la ventana y envíela a la siguiente ventana. Y así, Bob va de una ventana a otra, esperando que cada paso de su aplicación pase, hasta que finalmente llega al final y recibe su licencia de conducir.

No tiene sentido intentar "cortocircuitar" el DMV. Si los formularios no se completan correctamente por triplicado, o si se da alguna respuesta incorrecta en cualquier ventana, la solicitud se rompe y el cliente desafortunado se envía de vuelta al inicio.

Curiosamente, sin importar qué tan llena o vacía esté la oficina, lleva aproximadamente la misma cantidad de tiempo para ser atendida en cada ventana sucesiva. Incluso cuando eres la única persona en la línea, parece que al personal le gusta hacerte esperar un minuto detrás de la línea amarilla antes de decir "¡Siguiente!"

Sin embargo, las cosas no son tan terribles en el DMV. Mientras se realiza toda la espera y el procesamiento para obtener la licencia, puede ver un infomercial muy entretenido e informativo para el concesionario de automóviles mientras se encuentra en el lobby del DMV. De hecho, el infomerical se ejecuta el tiempo suficiente para cubrir la cantidad de tiempo que dedica a obtener su licencia.

La explicación un poco más técnica:

Como dije en la parte superior, es necesario tener algo de estado de estado en la relación cliente-servidor que le permite separar a los humanos de los robots. Desea hacerlo de una manera que no penalice demasiado al visitante humano anónimo (no autenticado).

Este enfoque probablemente requiere un procesamiento del lado del cliente AJAX-y. Un "nuevo visitante" para woot recibe el mensaje "¡Bienvenido, nuevo usuario!" página llena de texto y gráficos que (según la regulación del servidor) tarda unos segundos en cargarse por completo. Mientras esto ocurre (y el visitante está probablemente ocupado leyendo las páginas de bienvenida), su token de identificación se está ensamblando lentamente.

Digamos, para discusión, el token (también conocido como "licencia de conducir") consta de 20 partes. Para obtener cada parte sucesiva, el código del lado del cliente debe enviar una solicitud válida al servidor. El servidor incorpora un retraso deliberado (digamos 200 milisegundos), antes de enviar el siguiente fragmento junto con el ''sello'' necesario para realizar el siguiente pedido (es decir, los sellos necesarios para pasar de una ventana del DMV al siguiente). En total, deben transcurrir unos 4 segundos para finalizar el chunk-challenge-response-chunk-challenge-response -...- chunk-challenge-response-complete proceso.

Al final de este proceso, el visitante tiene un token que le permite ir a la página de descripción del producto y, a su vez, ir a la página de compras. El token es una identificación única para cada visitante y se puede utilizar para estrangular sus actividades.

En el lado del servidor, solo acepta las vistas de página de los clientes que tienen un token válido. O, si es importante que todos puedan ver la página en última instancia, aplique una penalización de tiempo a las solicitudes a las que les falta un token válido.

Ahora, para que esto sea relativamente benigno para el visitante humano legítimo, haga que el proceso de emisión del token suceda de forma relativamente intrusiva en el fondo. De ahí la necesidad de una página de bienvenida con una copia entretenida y gráficos que se desaceleren deliberadamente un poco.

Este enfoque obliga a los robots a reducir el uso de un token existente o el tiempo de configuración mínimo para obtener un token nuevo. Por supuesto, esto no ayuda tanto contra ataques sofisticados que usan una red distribuida de visitantes falsos.

Hay algunas otras / mejores soluciones ya publicadas, pero para completar, pensé que mencionaría esto:

Si su principal preocupación es la degradación del rendimiento, y está considerando un verdadero martilleo , entonces realmente está lidiando con un ataque DoS, y probablemente debería tratar de manejarlo en consecuencia. Un enfoque común es simplemente eliminar paquetes de una IP en el firewall después de un número de conexiones por segundo / minuto / etc. Por ejemplo, el servidor de seguridad estándar de Linux, iptables, tiene una función de coincidencia de operación estándar ''hashlimit'', que se podría usar para correlacionar las solicitudes de conexión por unidad de tiempo con una dirección IP.

Aunque, esta pregunta probablemente sería más apta para el próximo SO-derivado mencionado en el último SO-podcast, aún no se ha lanzado, así que supongo que está bien responder :)

EDITAR:
Como lo señaló novatrust, todavía hay ISPs que NO asignan IP a sus clientes, por lo que efectivamente, un script-cliente de tal ISP deshabilitaría a todos los clientes de ese ISP.

Prevenir el DoS derrotaría al # 2 de los objetivos de @davebug que describió anteriormente, "Mantener el sitio a una velocidad que no se vea frenada por los robots", pero no resolvería necesariamente el # 1, "Vender el artículo a humanos sin scripts"

Estoy seguro de que un guionista podría escribir algo para patinar justo debajo del límite excesivo que aún sería más rápido de lo que un humano podría pasar por los formularios de pedido.

¿Qué hay de introducir un retraso que requiere interacción humana, como una especie de "juego CAPTCHA"? Por ejemplo, podría ser un pequeño juego Flash en el que durante 30 segundos tienen que explotar bolas a cuadros y evitar estallar bolas sólidas (¡evitando problemas de ceguera de color!). Al juego se le daría una semilla de números aleatorios y lo que el juego transmite al servidor serían las coordenadas y las marcas de tiempo de los puntos en los que se hizo clic, junto con la semilla utilizada.

En el servidor, simulas la mecánica del juego usando esa semilla para ver si los clics hubieran hecho estallar las bolas. Si lo hicieron, no solo eran humanos, sino que tardaron 30 segundos en validarse. Dales una identificación de sesión.

Deja que la identificación de la sesión haga lo que quiera, pero si hace demasiadas solicitudes, no pueden continuar sin volver a jugar.

Actualmente estamos utilizando la última generación de balanceadores de carga BigIP de F5 para hacer esto. El BigIP tiene funciones avanzadas de administración de tráfico que pueden identificar raspadores y robots según la frecuencia y los patrones de uso, incluso entre un conjunto de fuentes detrás de una única IP. Luego, puede regularlos, ofrecerles contenido alternativo o simplemente etiquetarlos con encabezados o cookies para que pueda identificarlos en el código de su aplicación.

Bloque de tiempo de los agentes de usuario que hacen tantas solicitudes por minuto. Por ejemplo, si tienes a alguien que solicita una página exactamente cada 5 segundos durante 10 minutos, es probable que no sea un usuario ... Pero podría ser difícil hacerlo bien.

Si activan una alerta, redirija cada solicitud a una página estática con la menor cantidad posible de DB-IO con un mensaje que les avise que podrán volver a activarlo en X minutos.

Es importante agregar que probablemente solo debe aplicar esto en las solicitudes de páginas e ignorar todas las solicitudes de medios (js, imágenes, etc.).

De acuerdo, ¿los spammers están compitiendo con gente normal para ganar la subasta de "bog of crap"? ¿Por qué no hacer que la próxima subasta sea una "bolsa de basura" literal? Los spammers pueden pagar una buena cantidad de dinero por una bolsa llena de doggy do, y todos nos reímos de ellos.

Escriba un proxy inverso en un servidor apache frente a su aplicación que implemente un Tarpit (Artículo de Wikipedia) para castigar a los robots. Simplemente administraría una lista de direcciones IP que se conectaron en los últimos segundos. Detecta una ráfaga de solicitudes desde una sola dirección IP y luego retrasa exponencialmente esas solicitudes antes de responder.

Por supuesto, varios humanos pueden provenir de la misma dirección IP si están en una conexión de red NAT, pero es poco probable que a un humano le importe que el tiempo de respuesta vaya de 2 ms a 4 ms (o incluso 400 ms), mientras que un robot se verá obstaculizado por el retraso cada vez mayor bastante rápido.

Lo importante aquí es cambiar el sistema para eliminar la carga de su servidor, evitar que los bots ganen la bolsa de basura SIN informarles a los botlords que están jugando o ellos revisarán su estrategia. No creo que haya ninguna manera de hacer esto sin un poco de procesamiento al final.

Así que grabas los hits en tu página de inicio. Cada vez que alguien golpea la página, esa conexión se compara con su último golpe, y si fue demasiado rápida, se envía una versión de la página sin la oferta. Esto se puede hacer mediante algún tipo de mecanismo de equilibrio de carga que envía bots (los resultados demasiado rápidos) a un servidor que simplemente sirve versiones en caché de su página de inicio; Personas reales son enviadas al buen servidor. Esto quita la carga del servidor principal y hace que los robots piensen que todavía se están sirviendo las páginas correctamente.

Aún mejor si la oferta puede ser rechazada de alguna manera. Entonces aún puedes hacer las ofertas en el servidor falso, pero cuando el robot complete el formulario, dice "Lo siento, no fuiste lo suficientemente rápido" :) Entonces, definitivamente, pensarán que aún están en el juego.

Mi enfoque sería centrarme en soluciones no tecnológicas (de lo contrario, está entrando en una carrera de armamentos que perderá, o al menos gastará una gran cantidad de tiempo y dinero). Me concentraría en las partes de facturación / envío: puede encontrar bots encontrando múltiples entregas a la misma dirección o mediante múltiples cargos a un solo método de pago. Incluso puede hacer esto en varios elementos durante varias semanas, por lo que si un usuario obtuvo un elemento anterior (respondiendo realmente rápido) puede que se le asigne algún tipo de "desventaja" en esta ocasión.

Esto también tendría un efecto secundario (sería beneficioso, creo, pero podría estar equivocado en cuanto a marketing para su caso) de tal vez ampliar el círculo de personas que tienen suerte y pueden comprar woot.

No importa cuán seguros fueran los pensamientos de los nazis sobre sus comunicaciones, los aliados a menudo rompían sus mensajes. Independientemente de cómo intente evitar que los bots utilicen su sitio, los propietarios de bots trabajarán en torno a él. Lo siento si eso te hace el nazi :-)

Creo que se requiere una mentalidad diferente

No intentes impedir que los bots utilicen tu sitio
No vayas por una solución que funcione de inmediato, juega el juego largo

Entra en la mente de que no importa si el cliente de tu sitio es un humano o un bot, ambos son solo clientes de pago; pero uno tiene una ventaja injusta sobre el otro. Algunos usuarios sin mucha vida social (ermitaños) pueden ser tan molestos para los demás usuarios de su sitio como los robots.

Registre la hora en que publica una oferta y la hora en que una cuenta opta por comprarla.

Esto le da un registro de la rapidez con la que el cliente está comprando cosas.

Varíe la hora del día en que publica las ofertas.

Por ejemplo, tener una ventana de 3 horas a partir de algún momento oscuro del día (¿medianoche?) Solo los bots y ermitaños actualizarán una página constantemente durante 3 horas solo para obtener un pedido en segundos. Nunca varíe el tiempo base, solo el tamaño de la ventana.

Con el tiempo surgirá una imagen.

01: Puedes ver qué cuentas están comprando productos regularmente en cuestión de segundos de su puesta en marcha. Sugiriendo que podrían ser bots.

02: También puede mirar la ventana de tiempo utilizada para las ofertas, si la ventana es de 1 hora, algunos compradores anticipados serán humanos. Sin embargo, un humano rara vez se refrescará durante 4 horas. Si el tiempo transcurrido es bastante consistente entre publicación / compra, independientemente de la duración de la ventana, eso es un bot. Si el tiempo de publicación / compra es corto para ventanas pequeñas y se alarga para ventanas grandes, ¡es un ermitaño!

Ahora, en lugar de evitar que los bots usen su sitio, tiene suficiente información para decirle qué cuentas son utilizadas por bots y cuáles son las cuentas que los ermitaños usen. Lo que haga con esa información depende de usted, pero ciertamente puede usarlo para hacer que su sitio sea más justo para las personas que tienen una vida.

Creo que prohibir las cuentas de bot no tendría sentido, sería como llamar por teléfono a Hitler y decir "¡Gracias por las posiciones de tus submarinos!" De alguna manera, debe usar la información de una manera que los propietarios de las cuentas no se den cuenta. A ver si puedo soñar algo ...

Procesar órdenes en una cola:

Cuando el cliente realiza un pedido, inmediatamente recibe un correo electrónico de confirmación que le informa que su pedido se ha colocado en una cola y se le notificará cuando se haya procesado. Experimento este tipo de cosas con el pedido / envío en Amazon y no me molesta en absoluto, no me importa recibir un correo electrónico días más tarde diciéndome que mi pedido ha sido enviado siempre y cuando reciba un correo electrónico que me diga eso Amazon sabe que quiero el libro. En tu caso sería un correo electrónico para

Su orden ha sido colocada y está en una cola.
Su orden ha sido procesada.
Su orden ha sido despachada.

Los usuarios piensan que están en una cola justa. Procese su cola cada 1 hora para que los usuarios normales también experimenten una cola, para no despertar sospechas. Solo se procesan pedidos de cuentas de bot y ermitaños una vez que han estado en la cola para el "tiempo promedio de pedido humano + x horas". Reduciendo efectivamente los bots a los humanos.

No puedes evitar totalmente los bots, incluso con un captcha. Sin embargo, puede hacer que sea difícil escribir y mantener un bot y, por lo tanto, reducir el número. Particularmente, al obligarlos a actualizar sus bots diariamente, harás que la mayoría pierda el interés.

Aquí hay algunas ideas para que sea más difícil escribir bots:

Requiere ejecutar una función javascript. Javascript hace que sea mucho más difícil escribir un bot. Tal vez requiera un captcha si no están ejecutando javascript para permitir que los usuarios reales sin javascript (mínimo).
Programe las pulsaciones al escribir en el formulario (nuevamente a través de javascript). Si no es humano, entonces recházalo. Es un dolor imitar a los humanos escribiendo en un bot.
Escriba su código para actualizar sus ID de campo diariamente con un nuevo valor aleatorio. Esto los obligará a actualizar su bot diariamente, lo cual es un dolor.
Escriba su código para reordenar sus campos diariamente (obviamente de alguna manera no es aleatorio para sus usuarios). Si confían en el orden de campo, esto los hará tropezar y nuevamente forzará el mantenimiento diario de su código bot.
Usted podría ir aún más lejos y utilizar el contenido de Flash. Flash es totalmente un dolor contra el que escribir un bot.

Generalmente, si empiezas a tener una mentalidad de no prevenirlos, pero hacer que funcione más para ellos, probablemente puedas lograr el objetivo que estás buscando.

No veo la gran carga que reclamas al comprobar las IP entrantes. Por el contrario, he realizado un proyecto para uno de mis clientes que analiza los registros de acceso HTTP cada cinco minutos (podría haber sido en tiempo real, pero no quería eso por alguna razón que nunca entendí) y crea reglas de firewall para bloquear las conexiones desde cualquier dirección IP que genere un número excesivo de solicitudes, a menos que la dirección pueda confirmarse como perteneciente a un motor de búsqueda legítimo (google, yahoo, etc.).

Este cliente ejecuta un servicio de alojamiento web y ejecuta esta aplicación en tres servidores que manejan un total de 800-900 dominios. La actividad máxima está en el rango de mil hits por segundo y nunca ha habido un problema de rendimiento: los firewalls son muy eficientes para eliminar paquetes de direcciones en listas negras.

Y, sí, definitivamente existe la tecnología DDOS que derrotaría este esquema, pero no está viendo que eso suceda en el mundo real. Por el contrario, dice que ha reducido enormemente la carga en sus servidores.

Pegue un retraso de 5 minutos en todos los anuncios de productos para usuarios no registrados. Los usuarios casuales realmente no notarán esto y los usuarios no casuales se registrarán de todos modos.

Primero, déjame resumir lo que necesitamos hacer aquí. Me doy cuenta de que solo estoy parafraseando la pregunta original, pero es importante que lo entendamos al 100%, porque hay muchas sugerencias geniales que responden a 2 o 3 de 4, pero como demostraré, necesitará una enfoque multifacético para cubrir todos los requisitos.

Requisito 1: deshacerse del ''bot slamming'':

El ''golpe'' rápido de su página de inicio está afectando el rendimiento de su sitio y está en el centro del problema. El ''slamming'' viene tanto de bots de IP única como, supuestamente, también de botnets. Queremos deshacernos de ambos.

Requisito 2: No te metas con la experiencia del usuario:

Podríamos solucionar la situación del bot con bastante eficacia implementando un procedimiento de verificación desagradable como llamar a un operador humano, resolver un grupo de CAPTCHAs o similares, pero eso sería como forzar a cada pasajero inocente de un avión a saltar a través de locos aros de seguridad solo por la pequeña posibilidad de atrapar a los más estupidos de los terroristas. Oh, espera, en realidad lo hacemos. Pero vamos a ver si podemos no hacer eso en woot.com.

Requisito 3: Evitar la ''carrera de armamentos'':

Como mencionas, no quieres quedar atrapado en la carrera de armamentos de spambot. Por lo tanto, no puede usar ajustes simples como campos de formulario ocultos o mezclados, preguntas de matemáticas, etc., ya que son esencialmente medidas de oscuridad que se pueden detectar y burlar de forma trivial.

Requisito 4: frustrar los robots de ''alarma'':

Este puede ser el más difícil de sus requerimientos. Incluso si podemos hacer un desafío efectivo de verificación humana, los robots aún podrían sondear su página de inicio y alertar al programador cuando haya una nueva oferta. También queremos que esos bots sean inviables. Esta es una versión más sólida del primer requisito, ya que no solo los bots no pueden emitir solicitudes de disparos rápidos que dañan el rendimiento, sino que tampoco pueden emitir suficientes solicitudes repetidas para enviar una "alarma" al scripter a tiempo para ganar la oferta.

Bien, entonces veamos si podemos cumplir con los cuatro requisitos. Primero, como mencioné, ninguna medida va a hacer el truco. Tendrá que combinar un par de trucos para lograrlo, y tendrá que tragar dos molestias:

Se requerirá un pequeño número de usuarios para saltar a través de aros
Un pequeño número de usuarios no podrán obtener las ofertas especiales

Me doy cuenta de que estos son molestos, pero si podemos hacer que el número "pequeño" sea lo suficientemente pequeño , espero que estén de acuerdo en que los aspectos positivos superan a los negativos.

Primera medida: limitación basada en el usuario:

Este es un pan comido, y estoy seguro de que ya lo haces. Si un usuario ha iniciado sesión y se actualiza 600 veces por segundo (o algo así), deja de responder y le dice que lo enfríe. De hecho, probablemente acelerará sus pedidos mucho antes que eso, pero se le ocurre la idea. De esta manera, un robot registrado se prohibirá / acelerará tan pronto como comience a sondear su sitio. Esta es la parte facil. Los bots no autenticados son nuestro verdadero problema, así que seguidamente:

Segunda medida: alguna forma de limitación de la propiedad intelectual, como lo sugieren casi todos:

No importa qué, tendrá que hacer un límite de IP para frustrar el ''bot slamming''. Puesto que parece importante para usted para permitir que los visitantes no autenticados (-registrado en los no) para obtener las ofertas especiales, es suficiente con IPs Para ir en el principio, y aunque no son perfectos, que no trabaja contra los robots de una sola IP. Las botnets son una bestia diferente, pero volveré a ellas. Por ahora, vamos a hacer algunos cambios simples para vencer a los bots de un solo IP de disparo rápido.
El impacto en el rendimiento es insignificante si ejecuta la verificación de IP antes de todo otro procesamiento, utiliza un servidor proxy para la lógica de regulación y almacena las IP en una estructura de árbol optimizada para búsqueda de memcached.

Tercera medida: encubrir el acelerador con respuestas almacenadas en caché:

Con los bots de un solo IP de disparo rápido acelerados, todavía tenemos que abordar los bots de un solo IP lento, es decir. los bots que están específicamente ajustados para ''volar bajo el radar'' espaciando las solicitudes un poco más separadas de lo que impide la regulación.
Para inutilizar instantáneamente los bots lentos de una sola IP, simplemente use la estrategia sugerida por abelenky: sirva páginas almacenadas en caché de 10 minutos de antigüedad a todas las IP que se hayan detectado en las últimas 24 horas (más o menos). De esa manera, cada IP tiene una "posibilidad" por día / hora / semana (dependiendo del período que elija), y no habrá molestias visibles para los usuarios reales que solo están presionando "recargar", excepto que no ganan la oferta.
La belleza de esta medida es que también es ''bots de alarma'', siempre que no se originen en una red de bots.
(Sé que probablemente preferirías si a los usuarios reales se les permitiera refrescarse una y otra vez, pero no hay manera de diferenciar a un humano de actualización de spam desde un bot de solicitud de spam, sin un CAPTCHA o similar)

Cuarta medida: reCAPTCHA:

Tiene razón en que los CAPTCHA perjudican la experiencia del usuario y deben evitarse. Sin embargo, en una sola situación, pueden ser su mejor amigo: si ha diseñado un sistema muy restrictivo para frustrar los robots, eso, debido a su carácter restrictivo, también detecta varios falsos positivos; luego, un CAPTCHA como último recurso permitirá a los usuarios reales que se quedan atrapados por su regulación (evitando así las molestas situaciones de DoS).
El punto dulce, por supuesto, es cuando TODOS los bots quedan atrapados en su red, mientras que muy pocos usuarios reales son molestados por el CAPTCHA.
Si usted, al entregar las páginas almacenadas en caché de 10 minutos de antigüedad, también ofrece una ''actualización de página inicial'' verificada por CAPTCHA , opcional , los seres humanos que realmente quieren seguir actualizándose pueden hacerlo sin obtener la página guardada en caché , pero al costo de tener que resolver un CAPTCHA para cada actualización. Eso es una molestia, pero es opcional solo para los usuarios más exigentes, que tienden a ser más tolerantes porque saben que están aprovechando el sistema para mejorar sus posibilidades, y que las posibilidades mejoradas no son gratis.

Quinta medida: Trampa de mierda:

Christopher Mahan tuvo una idea que me gustó bastante, pero le daría un giro diferente. Cada vez que esté preparando una nueva oferta, prepare otras dos "ofertas" también, que ningún ser humano elegiría, como un wingnut de 12 mm por $ 20. Cuando aparezca la oferta en la portada, coloque las tres ''ofertas'' en la misma imagen, con los números correspondientes a cada oferta. Cuando el usuario / bot continúe para ordenar el artículo, tendrá que elegir (un botón de opción) qué oferta quiere, y dado que la mayoría de los robots simplemente adivinarían, en dos de los tres casos, los robots no comprarían nada. basura.
Naturalmente, esto no se dirige a los ''bots de alarma'', y existe la posibilidad (pequeña) de que alguien pueda construir un bot que pueda elegir el elemento correcto. Sin embargo, el riesgo de comprar chatarra accidentalmente debería hacer que los guionistas se vuelvan completamente desde los bots totalmente automatizados.

Sexta medida: Limitación de Botnet:

[eliminado]

Bien ............ Ahora he pasado la mayor parte de mi tarde pensando en esto, probando diferentes enfoques ... retrasos globales ... tokens basados en cookies ... sirviendo en cola ... ''estrangulamiento de extraños'' ... Y simplemente no funciona. No lo haceMe di cuenta de que la razón principal por la que todavía no habías aceptado ninguna respuesta era que nadie había propuesto una manera de frustrar un ataque distribuido / zombie net / botnet ... así que realmente quería resolverlo. Creo que resolví el problema de la botnet para la autenticación en un subproceso diferente , así que también tenía muchas esperanzas para tu problema. Pero mi enfoque no se traduce en esto. Solo tiene IPs para pasar y una botnet lo suficientemente grande no se revela en ningún análisis basado en direcciones IP.

Así que ahí lo tienen : mi sexta medida no es nada. Nada.Cremallera. A menos que la red de bots sea pequeña y / o lo suficientemente rápida como para quedar atrapada en el acelerador de IP habitual, no veo ninguna medida efectiva contra las redes de bots que no implique una verificación humana explícita, como los CAPTHA. Lo siento, pero creo que combinar las cinco medidas anteriores es su mejor apuesta. Y probablemente podría hacerlo bien solo con el truco de 10 minutos de almacenamiento en caché de abelenky.

Volvamos al problema: tienes bots que compran cosas que quieres que compren las personas reales, ¿qué tal una posibilidad real de que los bots compren cosas que no quieres que compren las personas de verdad?

Tenga una oportunidad aleatoria para algunos html no mostrados que los robots raspadores considerarán que son la situación real, pero la gente real no verá (y no olvide que la gente real incluye a los ciegos, así que considere los lectores de pantalla, etc.), y este viaja para comprar algo exorbitantemente costoso (o no realiza la compra real, pero obtiene los detalles de pago para que usted los incluya en una lista de opciones).

Incluso si los bots cambian para "alertar al usuario" en lugar de "hacer la compra", si puede obtener suficientes falsas alarmas, puede hacer que sea lo suficientemente inútil para las personas (tal vez no todos, pero una cierta reducción en el fraude es Mejor que nada en absoluto) no molestar.

Ya se han ofrecido las soluciones más puramente técnicas. Por lo tanto, sugeriré otra visión del problema.

Según tengo entendido, los robots están configurados por personas que realmente intentan comprar las bolsas que usted está vendiendo. El problema es -

Otras personas, que no operan bots, merecen la oportunidad de comprar, y estás ofreciendo una cantidad limitada de bolsas.
Quieres atraer humanos a tu sitio y simplemente vender las bolsas.

En lugar de tratar de evitar los robots, puede permitir que los compradores potenciales de suscripciones se suscriban a un correo electrónico, o incluso a una actualización de SMS, para recibir una notificación cuando se realizará una venta. Incluso puede darles un minuto o dos de ventaja (una URL especial donde comienza la venta, se genera aleatoriamente y se envía con el correo / SMS).

Cuando estos compradores compran, están en tu sitio, puedes mostrarles lo que quieras en banners laterales o lo que sea. Quienes ejecuten los bots preferirán simplemente registrarse en su servicio de notificación.

Los corredores de bots aún podrían ejecutar bots en tu notificación para terminar la compra más rápido. Algunas soluciones pueden ser ofrecer una compra de un solo clic.

Por cierto, mencionó que sus usuarios no están registrados, pero parece que aquellos que compran estas bolsas no son compradores al azar, sino personas que esperan estas ventas. Como tal, podrían estar dispuestos a registrarse para obtener una ventaja al tratar de "ganar" una bolsa.

En esencia, lo que sugiero es tratar de ver el problema como un problema social, en lugar de uno técnico.

Asaf

Yo digo exponer la información de precios utilizando una API. Esta es la solución poco intuitiva, pero funciona para darle control sobre la situación. Agregue algunas limitaciones a la API para que sea un poco menos funcional que el sitio web.

Usted podría hacer lo mismo para ordenar. Podría experimentar pequeños cambios en la funcionalidad / rendimiento de la API hasta obtener el efecto deseado.

Hay proxies y botnets para anular los controles de IP. Hay scripts de lectura captcha que son extremadamente buenos. Incluso hay equipos de trabajadores en la India que derrotan a los captchas por un pequeño precio. Cualquier solución que puedas encontrar puede ser derrotada razonablemente. Incluso las soluciones de Ned Batchelder pueden dejarse de lado utilizando un control WebBrowser u otro navegador simulado combinado con una red de bots o una lista de proxy.