Acepté una respuesta, pero lamentablemente, creo que estamos atrapados en nuestro peor escenario original: CAPTCHA a todos los intentos de compra de la basura . Breve explicación: el almacenamiento en caché / granjas web hace que sea imposible rastrear los éxitos, y cualquier solución alternativa (enviar una baliza web no almacenada en caché, escribir en una tabla unificada, etc.) ralentiza el sitio peor de lo que lo harían los bots. Es probable que haya un 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, así como limpiar esto para futuros buscadores (aunque otros son bienvenidos a intentarlo, ya que es el wiki de la comunidad).

Situación

Se trata de las ventas de bolsas de basura 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 en estrecha colaboración con los desarrolladores y he discutido todas las respuestas aquí (y muchas otras ideas que hemos tenido).

La usabilidad es una parte enorme de mi trabajo, y hacer que el sitio sea emocionante y divertido es la mayor parte del resto. Ahí es donde derivan los tres objetivos a continuación. CAPTCHA perjudica la usabilidad, y los bots roban la diversión y la emoción de nuestras ventas de basura.

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

Evaluación

lc : En stackoverflow y otros sitios que usan este método, casi siempre se trata de usuarios autenticados (conectados), porque la tarea que se intenta requiere eso.

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

Así que volvemos a escanear en busca de IP, que a) es bastante inútil en esta era de redes en la nube y zombies spambot yb) atrapa demasiados inocentes dada la cantidad de empresas que provienen de una dirección IP (sin mencionar los problemas con ISP IP no estáticos y posibles resultados de rendimiento para tratar de rastrear 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 bots creados para una red de sitios. Nuestro problema es que los bots 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 scripters desarrollen sus bots para ignorar el honeypot, raspar la pantalla para nombres de etiquetas cercanos en lugar de identificadores de formulario y usar un control de navegador compatible con javascript.

Una vez más, "a menos que, por supuesto, la exageración sea parte de su esquema de marketing". Sí, definitivamente lo es. La sorpresa de cuándo aparece el artículo, así como la emoción si logras obtener uno, es probablemente tanto o más importante que la basura que realmente obtienes. Cualquier cosa que elimine el orden de llegada es perjudicial para la emoción de "ganar" la porquería.

Novatrust : Y yo, por mi parte, doy la bienvenida a nuestros nuevos señores bot. En realidad, ofrecemos RSSfeeds para permitir que aplicaciones de terceros escaneen nuestro sitio en busca de información del producto, pero no antes del HTML del sitio principal. Si lo estoy interpretando bien, su solución ayuda al objetivo 2 (problemas de rendimiento) al sacrificar completamente el objetivo 1 y simplemente renunciar al hecho de que los bots comprarán la mayor parte de la basura. He votado a favor su respuesta, porque su pesimismo del último párrafo me parece exacto. Parece que no hay bala de plata aquí.

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

¿Algún otro enfoque / idea? Mis desarrolladores siguen diciendo "hagamos CAPTCHA", pero espero que haya métodos menos intrusivos para todos los humanos reales que desean 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á este artículo. Y más de un millón de personas vienen regularmente para ver lo que estás vendiendo.

Terminas con scripters y bots que intentan programáticamente [a] descubrir cuándo estás vendiendo dicho artículo, y [b] asegurarte de que estén entre los primeros en comprarlo. Esto apesta por dos razones:

1. Su sitio está cerrado por personas no humanas, lo que ralentiza todo para todos.
2. Los scripters 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 salten 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 al gato o resolver un problema matemático.
• Si el beneficio percibido es lo suficientemente alto, y la multitud lo suficientemente grande, algún grupo encontrará su camino alrededor de cualquier ajuste, lo que conducirá a una carrera armamentista. (Esto es especialmente cierto cuanto más simple es el ajuste; el formulario oculto de 'comentarios', la reorganización de los elementos del formulario, el etiquetado erróneo, el texto oculto 'gotcha' todo funcionará una vez y luego deberá cambiarse para luchar contra este formulario específico .)
• Incluso si los scripters no pueden 'resolver' su ajuste, no les impide cerrar su página principal y luego hacer sonar una alarma para que el scripter complete el pedido, manualmente. Dado que obtienen la ventaja de resolver [a], probablemente seguirán ganando [b] ya que serán los primeros humanos en llegar a la página de pedido. Además, 1. todavía ocurre, causando errores en el servidor y una disminución del rendimiento para todos.

Otra solución es vigilar las IP que golpean con demasiada frecuencia, bloquearlas del firewall o evitar que ordenen. Esto podría resolver 2. y prevenir [b], pero el impacto en el rendimiento de la exploración de IP es masivo y probablemente causaría más problemas como 1. que los que los scripters estaban causando por sí mismos. Además, la posibilidad de redes en la nube y zombies spambot hace que la comprobación de IP sea bastante inútil.

Una tercera idea, obligar a que el formulario de pedido se cargue durante un tiempo (por ejemplo, medio segundo) potencialmente retrasaría el progreso de los pedidos rápidos, pero nuevamente, los scripters seguirían siendo las primeras personas en entrar, a cualquier velocidad no perjudicial para usuarios reales

Metas

1. Vende el artículo a humanos que no escriban guiones.
2. Mantenga el sitio funcionando a una velocidad no ralentizada por los bots.
3. No moleste a los usuarios 'normales' con ninguna tarea que completar para demostrar que son humanos.

¿Qué tal implementar algo como SO hace con los CAPTCHA?

Si usa el sitio normalmente, probablemente nunca verá uno. Si vuelve a cargar la misma página con demasiada frecuencia, publique comentarios sucesivos demasiado rápido u otra cosa que active una alarma, haga que demuestren que son humanos. En su caso, esto probablemente sería recargas constantes de la misma página, seguir cada enlace de una página rápidamente o completar un formulario de pedido demasiado rápido para ser humano.

Si fallan la verificación x veces seguidas (digamos, 2 o 3), dele a esa IP un tiempo de espera u otra medida similar. Luego, al final del tiempo de espera, vuélvalos a la cuenta nuevamente.

Como 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 seguidas (en caso de que un bot siga eliminando la cookie).

En cuanto a la captura de demasiados inocentes, puede poner un descargo de responsabilidad en la página de verificación humana: "Esta página también puede aparecer si demasiados usuarios anónimos están viendo nuestro sitio desde la misma ubicación. Le recomendamos que se registre o inicie sesión para evitar esta." (Ajuste la redacción adecuadamente).

Además, ¿cuáles son las probabilidades de que X personas carguen las mismas páginas al mismo tiempo desde una IP? Si son altos, tal vez necesite un mecanismo de activación diferente para su alarma de bot.

Editar: Otra opción es si fallan demasiadas veces, y usted está seguro de la demanda del producto, para bloquearlos y hacer que le LLAME personalmente para que elimine el bloqueo.

Hacer que la gente llame parece una medida tonta, pero se asegura de que haya un humano en algún lugar detrás de la computadora . La clave es tener el bloque solo en su lugar para una condición que casi nunca debería ocurrir a menos que sea un bot (por ejemplo, fallar la verificación varias veces seguidas). Luego obliga a la interacción humana: levantar el teléfono.

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

Dado que parece que está decidido a no dejar que los bots se hagan con el control de su sitio, creo que el teléfono puede ser una buena opción. Como no obtengo ganancias de su producto, no tengo interés en recibir estas llamadas. Si compartiera parte de esa ganancia, sin embargo, podría interesarme. Como este es su producto, debe decidir cuánto le importa e implementarlo en consecuencia.

Las otras formas de liberar el bloqueo simplemente no son tan efectivas: un tiempo de espera (pero podrían volver a cerrar su sitio después, enjuagar y repetir), un tiempo de espera prolongado (si realmente fuera un humano tratando de comprar su producto, serían SOL y castigados por no pasar el cheque), correo electrónico (fácil de hacer por bots), fax (igual) o correo postal (lleva demasiado tiempo).

Por supuesto, podría aumentar el período de tiempo de espera por IP cada vez que obtengan un tiempo de espera. Solo asegúrate de no castigar a los verdaderos humanos sin darse cuenta.

Necesitas encontrar una manera de hacer que los bots compren cosas que son demasiado caras: almendra de 12 mm: $ 20. Vea cuántos bots aparecen antes de que los guionistas decidan que los está jugando.

Use las ganancias para comprar más servidores y pagar por el ancho de banda.

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

Así es como lo haría:

• Registre e identifique cualquier bateador repetido.

No necesita registrar cada dirección IP en cada hit. Solo rastrea uno de cada 20 golpes más o menos. Un delincuente reincidente todavía aparecerá en un seguimiento aleatorio ocasionalmente.

• Mantenga un caché de su página de aproximadamente 10 minutos antes.

• Cuando un jugador repetidor / bot llegue a su sitio, dele la página en caché de 10 minutos de antigüedad.

No sabrán de inmediato que están obteniendo un sitio antiguo. 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 molestias para los usuarios (como CAPTCHA).
• Implementado completamente en el lado del servidor. (sin depender de Javascript / Flash)
• Servir una página anterior en caché debería ser menos intensiva en rendimiento que una página en vivo. ¡De hecho, puede disminuir la carga en sus servidores de esta manera!

Inconvenientes

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

¿Qué piensas?

Echa un vistazo a este artículo de ned Batchelder aquí . Su artículo trata sobre detener los robots de spam, 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, podemos detenerlos haciendo que sea difícil para ellos hacer una publicación exitosa, o haciendo que se identifiquen inadvertidamente como bots. Esto elimina la carga de las personas y deja el formulario de comentarios libre de medidas visibles contra el correo no deseado.

Esta técnica es cómo evito los robots de spam 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 (fuente RSS? Twitter?) Al que las personas puedan suscribirse cuando su producto salga a la venta. Esto reduce la necesidad de que las personas hagan scripts.
• Cambie su técnica de ofuscación justo antes de que un nuevo artículo salga a la venta. Entonces, incluso si los scripters pueden escalar la carrera armamentista, siempre están un día atrás.

EDITAR: Para ser totalmente claro, el artículo anterior de Ned describe métodos para evitar la COMPRA automatizada de artículos al evitar que un BOT revise los formularios para enviar un pedido. Sus técnicas no serían útiles para evitar que los bots raspen la pantalla de la página de inicio para determinar cuándo sale a la venta una bandolera de zanahorias. No estoy seguro de prevenir ESO es realmente posible.

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

El control giratorio es un campo oculto que se utiliza para algunas cosas: agrupa varios 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 del blog que se está comentando, y
• Un secreto.

Así es como 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 comprar artículos automáticamente, solo funcionará hasta que salga a la venta el siguiente artículo !

Incluso si alguien puede reconstruir rápidamente su bot, todos los demás usuarios reales ya habrán comprado un BOC, ¡y su problema está resuelto!

La otra estrategia que analiza es cambiar la técnica honeypot de vez en cuando (de nuevo, cámbiela cuando salga a la venta un nuevo artículo):

• Utilice las clases CSS (aleatorias, por supuesto) para establecer los campos o un elemento contenedor para mostrar: ninguno.
• Colorea los campos de la misma manera (o muy similar) al fondo de la página.
• Use el posicionamiento 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 el posicionamiento para cubrirlos con un elemento oculto.
• Use Javascript para realizar cualquiera de estos cambios, lo que requiere que un bot tenga un motor Javascript completo.
• Deje los honeypots mostrados como los otros campos, pero diga a las personas que no ingresen nada en ellos.

Supongo que mi idea general es CAMBIAR EL DISEÑO DE LA FORMA cuando cada nuevo artículo salga a la venta. O al MENOS, cámbielo cuando salga a la venta un nuevo BOC.

¿Cuál es qué, un par de veces al mes?

Si acepta esta respuesta, ¿me avisará cuando llegue la próxima? :)

P: ¿Cómo evitarías que los scripters golpeen tu sitio cientos de veces por segundo?
A: no lo haces. No hay forma de evitar este comportamiento por parte de agentes externos.

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

La única solución viable a largo plazo es cambiar el juego para que el sitio no sea compatible con bots o sea menos atractivo para los scripters.

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

...

OK, algunas opciones se han dado (y rechazado) arriba. No estoy íntimamente familiarizado con su sitio, ya que lo he visto solo una vez, pero dado que las personas pueden leer texto en imágenes y los robots no pueden hacerlo fácilmente, cambie el anuncio para que sea una imagen. No es un CAPTCHA , solo una imagen.

• generar la imagen (en caché, por supuesto) cuando se solicita la página
• mantenga el nombre de la fuente de la imagen igual, para que eso no revele el juego
• la mayoría de las veces la imagen tendrá texto ordinario y estará alineada para que parezca ser parte de la página HTML en línea
• cuando el juego está "encendido", la imagen cambia al texto del anuncio
• el texto del anuncio revela una url y / o código que debe ingresarse manualmente para adquirir el premio. CAPTCHA el código si lo desea, pero probablemente no sea necesario.
• Para mayor seguridad, el código puede ser un token único generado específicamente para la solicitud / IP / agente, de modo que las solicitudes repetidas generan códigos diferentes. O bien, puede generar previamente un montón de códigos aleatorios (una plataforma única) si la generación bajo demanda es demasiado exigente.

Ejecute pruebas de tiempo de personas reales que responden a esto, e ignore ('¡Uy, se produjo un error, lo siento! Intente de nuevo') respuestas más rápido que (digamos) la mitad de este tiempo. Este evento también debería activar una alerta a 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 bot lo activa, solo para perder el tiempo de los scripters. Finalmente, los guionistas deberían cansarse del juego e ir a otro lado ... 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 hacerlo, pero probablemente será vale la pena). Si entra otra solicitud del mismo IP / agente mientras la primera solicitud está en la cola, ignórela. Esto debería eliminar automáticamente la carga de los bots.

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

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

Averigua qué datos están buscando los bots. Aliméntelos con los datos que están buscando cuando NO está vendiendo basura. Haga esto de una manera que no moleste o confunda a los usuarios humanos. Cuando los bots activen la fase dos, iniciarán sesión y completarán el formulario para comprar $ 100 roombas en lugar de BOC. Por supuesto, esto supone que los bots 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 o basura al azar por $ 150 cuando declaras CLARAMENTE que solo vale $ 20? Nadie más que bots demasiado entusiastas. Pero luego 9 minutos después son $ 35 dólares ... luego 17 minutos después son $ 9. O lo que sea.

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

Todo esto supone que quieres cabrear a algunos señores bot, lo que puede no ser 100% aconsejable.

Entonces, el problema realmente parece ser: los bots quieren su "bolsa de basura" porque tiene un alto valor percibido a un precio percibido bajo. A veces ofreces este artículo y los bots acechan, 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 obteniendo ganancias), el truco es hacer que esto no sea rentable para ellos al alentarlos a comprar la basura.

Primero, siempre ofrezca la "bolsa de basura".

En segundo lugar, asegúrese de que la basura es generalmente basura.

Tercero, gire la basura con frecuencia.

Simple, no?

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

Cuando el bot ve que hay basura y la basura se compra automáticamente, el destinatario se va a enojar mucho porque ha pagado $ 10 por un palillo roto. Y luego una bolsa de basura vacía. Y luego un poco de suciedad de la parte inferior de tu zapato.

Si compran suficiente de esta basura en un período de tiempo relativamente corto (y tiene grandes renuncias en todo el lugar que explican por qué está haciendo esto), van a perder una "bolsa 'o dinero en efectivo justo en su" bolsa de basura ". Incluso la intervención humana por su parte (verificar que la basura no sea basura) puede fallar si gira la basura con la frecuencia suficiente. Demonios, tal vez los bots lo noten y no compren nada que haya estado en la rotación durante demasiado tiempo, pero eso significa que los humanos comprarán la basura.

Diablos, tus clientes habituales pueden estar tan divertidos que puedes convertir esto en una gran victoria de marketing. Comience a publicar la cantidad de carpa "basura" que se vende. La gente volverá solo para ver cuán duro han sido mordidos los bots.

Actualización: espero que pueda recibir algunas llamadas por adelantado con personas que se quejan. No creo que puedas detener eso por completo. Sin embargo, si esto mata a los bots, siempre puede detenerlo y reiniciarlo más tarde.

1. Vende el artículo a humanos que no escriban guiones.

2. Mantenga el sitio funcionando a una velocidad no ralentizada por los bots.

3. No moleste a los usuarios 'normales' con ninguna tarea que completar para demostrar que son humanos.

Probablemente no quieras escuchar esto, pero el n. ° 1 y el n. ° 3 son mutuamente excluyentes.

Bueno, nadie sabe que eres un bot tampoco. No hay una forma programática para saber si hay 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 por la cual se inventaron los CAPTCHA. No es que este sea un problema nuevo que no haya visto un gran esfuerzo en él. Si hubiera una mejor manera de hacerlo, una que no implicara la molestia para los usuarios reales de un CAPTCHA, todos lo estarían utilizando.

Creo que debes enfrentar el hecho de que si quieres mantener a los bots fuera de tu página de pedidos, un buen CAPTCHA es la única forma de hacerlo. Si la demanda de su basura aleatoria es lo suficientemente alta como para que las personas estén dispuestas a hacer todo lo posible para obtenerla, un CAPTCHA no desanimará a los usuarios legítimos.

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

Esto no solo combate con éxito los bots (pueden hacer fácilmente 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ápido, 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, primer servido". No puede hacer lo que hicieron las estaciones de radio (ya no hacen que la primera persona que llama sea la ganadora, hacen que la quinta o la vigésima o la decimotercera persona sea la ganadora), 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, crearemos un software para trabajar en nuestras 100 computadoras separadas y visitaremos su sitio 20 veces por segundo (5 segundos entre accesos para cada usuario / cookie / cuenta / dirección IP).

Tienes dos etapas:

1. Viendo la portada
2. Ordenar

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

Entonces mi pequeño grupo observa, cronometrados juntos para que obtengamos aproximadamente 20 cheques por segundo, y quien vea el cambio primero alerta a todos los demás (automáticamente), quienes cargarán la página principal una vez más, seguirán el enlace del pedido y realizarán la transacción ( que también puede suceder automáticamente, a menos que implemente captcha y lo cambie para cada wootoff / boc).

Puedes poner un captcha delante del # 2, y aunque detestas hacerlo, esa puede ser la única forma de asegurarte de que incluso si los bots miran la página principal, los usuarios reales obtienen los productos.

Pero incluso con el captcha, mi pequeña banda de 100 aún tendría una ventaja significativa en el primer movimiento, y no hay forma de que puedas decir que no somos humanos. Si comienza a cronometrar nuestros accesos, simplemente agregaremos algo de jitter. Podríamos seleccionar aleatoriamente qué computadora debía actualizar para que el orden de acceso cambie constantemente, pero aún se parece lo suficiente a un humano.

Primero, deshazte de los bots simples

Debe tener un firewall adaptable que vigile las solicitudes y si alguien está haciendo lo obvio estúpido: actualizar más de una vez por segundo a la misma IP y luego emplear tácticas para ralentizarlas (descartar 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.

En segundo lugar, haga 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 de abajo hacia arriba.

No necesita meterse con la pila TCP / IP, pero es posible que necesite desarrollar un servidor personalizado 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 flexible, pero tiene un sitio web con un solo propósito y realmente necesita poder hacer más de lo que los servidores actuales son capaces de hacer (tanto en el manejo del tráfico como en la lucha adecuada contra los bots). )

Al servir una página web en gran parte estática (actualizaciones cada 30 segundos más o menos) en un servidor personalizado, no solo debería poder manejar 10 veces la cantidad de solicitudes y tráfico (porque el servidor no está haciendo nada más que recibir la solicitud y leer la página desde la memoria al búfer TCP / IP), pero también le dará acceso a métricas que podrían ayudarlo a ralentizar los bots. Por ejemplo, al correlacionar 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 se bloquean con poca frecuencia. Desea realizar un bloqueo lento: deje la conexión sola por un segundo completo antes de finalizar oficialmente la sesión. Esto puede alimentar a un firewall para dar bloqueos a más largo plazo a los infractores especialmente atroces.

Pero la realidad es que no importa lo que hagas, no hay forma de distinguir a un humano aparte de un bot cuando el robot es personalizado 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 puedes distinguir a un humano y una computadora por mirar la portada. Puede detener los bots en el paso de pedido, pero los usuarios de bot todavía tienen la ventaja de ser el primero en moverse, y todavía tiene una gran carga que administrar.

Puede agregar bloques para los bots simples, lo que elevará el listón y menos personas se molestarán con él. Eso puede ser suficiente.

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

Puede considerar configurar un honeypot y marcar cuentas de usuario como usuarios de bot, pero eso tendrá una gran 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 convierte la página principal en un captcha para llegar a la página de pedido ("El botón de pedido de este artículo es azul con destellos rosados, en algún lugar de esta página"), los bots simplemente abrirán todos los enlaces de la página y usarán el que venga de vuelta con una página de pedidos. Esa no es forma 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 que probablemente sea demasiado lento para su aplicación) en la página de pedidos, y piense en formas de cambiar el modelo ligeramente Los usuarios habituales tienen tantas posibilidades como los usuarios de bot.

-Adán

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

Otra idea es si realmente tiene una cantidad limitada para vender, ¿por qué no la cambia de una metodología por orden de llegada? A menos que, por supuesto, la exageración sea parte de su esquema de marketing.

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

• una cola de pedidos (sistema de pedidos por adelantado): algunos scripts pueden terminar en la parte delantera de la cola, pero probablemente sea más rápido ingresar la información manualmente.

• un sistema de rifa (todos los que intentan ordenar 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 colocarse más arriba en la cola.

• subasta (el crédito es para David Schmitt por este, los comentarios son míos) - La gente todavía puede usar guiones para atacar en el último minuto, pero no solo cambia la estructura de precios, sino que la gente espera pelear con otros . También puede hacer cosas para restringir la cantidad de ofertas en un período de tiempo determinado, hacer que las personas se comuniquen con anticipación para obtener un código de autorización, etc.

No importa cuán seguros pensaran los nazis que eran sus comunicaciones, los aliados a menudo rompían sus mensajes. No importa cómo intentes evitar que los bots usen tu sitio, los propietarios de bots lo solucionarán. Lo siento si eso te convierte en nazi :-)

Creo que se requiere una mentalidad diferente

• No intentes evitar que los bots usen tu sitio
• No busques una solución que funcione de inmediato, juega el juego largo

Tenga en cuenta que no importa si el cliente de su sitio es un humano o un bot, ambos son solo clientes que pagan; pero uno tiene una ventaja injusta sobre el otro. Algunos usuarios sin mucha vida social (ermitaños) pueden ser tan molestos para los otros usuarios de su sitio como los bots.

Registre el momento en que publica una oferta y el momento en que una cuenta opta por comprarla.

Esto le da un registro de la rapidez con que el cliente compra cosas.

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

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

Con el tiempo surgirá una imagen.

01: Puede ver qué cuentas compran regularmente productos en cuestión de segundos después de que se activen. 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 de los primeros compradores serán humanos. Sin embargo, un humano rara vez se actualizará durante 4 horas. Si el tiempo transcurrido es bastante consistente entre la publicación / compra, independientemente de la duración de la ventana, entonces es un bot. Si el tiempo de publicación / compra es corto para ventanas pequeñas y se alarga para ventanas grandes, ¡eso es un ermitaño!

Ahora, en lugar de evitar que los bots usen su sitio, tiene suficiente información para decirle qué cuentas ciertamente usan los bots, y qué cuentas es probable que los ermitaños usen. Lo que haga con esa información depende de usted, pero ciertamente puede usarla 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 similar a llamar a Hitler y decir "¡Gracias por las posiciones de sus submarinos!" De alguna manera, necesita usar la información de una manera que los propietarios de la cuenta no se darán cuenta. A ver si puedo soñar algo .....

Procesar pedidos en una cola:

Cuando el cliente realiza un pedido, recibe de inmediato un correo electrónico de confirmación informándole 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 después diciéndome que mi pedido ha sido enviado siempre que reciba un correo electrónico que me diga que Amazon sabe que quiero el libro. En su caso, sería un correo electrónico para

1. Su pedido ha sido realizado y está en una cola.
2. Su orden ha sido procesada.
3. 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 procese pedidos de cuentas de bot y ermitaño una vez que hayan estado en la cola por el "tiempo promedio de pedido humano + x horas". Reducción efectiva de bots a humanos.

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.

Podrías hacer lo mismo para ordenar. Puede experimentar con pequeños cambios en la funcionalidad / rendimiento de la API hasta que obtenga el efecto deseado.

Hay servidores proxy y botnets para vencer las comprobaciones de IP. Hay captcha que lee scripts que son extremadamente buenos. Incluso hay equipos de trabajadores en India que derrotan a los captchas por un pequeño precio. Cualquier solución que se te ocurra puede ser razonablemente derrotada. Incluso las soluciones de Ned Batchelder se pueden superar mediante el uso de un control WebBrowser u otro navegador simulado combinado con una botnet o una lista de proxy.

Actualmente estamos utilizando la última generación de equilibradores de carga BigIP de F5 para hacer esto. BigIP tiene características avanzadas de administración de tráfico que pueden identificar scrapers y bots en función de la frecuencia y los patrones de uso, incluso entre un conjunto de fuentes detrás de una sola IP. Luego puede limitarlos, servirles contenido alternativo o simplemente etiquetarlos con encabezados o cookies para que pueda identificarlos en el código de su aplicación.

Primero, permítanme recapitular lo que necesitamos hacer aquí. Me doy cuenta de que solo estoy parafraseando la pregunta original, pero es importante que entendamos esto al 100%, porque hay muchas sugerencias excelentes que obtienen 2 o 3 de 4 correctamente, pero como demostraré, necesitará un Enfoque multifacético para cubrir todos los requisitos.

Requisito 1: deshacerse del 'bot slamming':

El rápido 'portazo' de su página principal está perjudicando el rendimiento de su sitio y es el núcleo del problema. El 'slamming' proviene tanto de bots de IP única como, supuestamente, de botnets también. Queremos deshacernos de ambos.

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

Podríamos solucionar la situación del bot de manera bastante efectiva implementando un procedimiento de verificación desagradable como llamar a un operador humano, resolver un montón de CAPTCHA, o similar, pero eso sería como obligar a todos los pasajeros inocentes de los aviones a saltar a través de locos aros de seguridad solo por la pequeña posibilidad de atrapar a los terroristas más estúpidos. Oh, espera, de hecho hacemos eso. Pero vamos a ver si podemos no hacer eso en woot.com.

Requisito 3: Evitar la 'carrera armamentista':

Como mencionas, no quieres quedar atrapado en la carrera armamentista de spambot. Por lo tanto, no puede usar ajustes simples como campos de formulario ocultos o confusos, preguntas de matemáticas, etc., ya que son esencialmente medidas de oscuridad que pueden ser automáticamente autodetectadas y eludidas.

Requisito 4: frustrar los bots de 'alarma':

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

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

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

Me doy cuenta de que son molestos, pero si podemos hacer que el número 'pequeño' sea lo suficientemente pequeño , espero que aceptes que los positivos superan a los negativos.

Primera medida: aceleración basada en el usuario:

Este es obvio, 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 aceleres sus solicitudes significativamente antes de eso, pero entiendes la idea. De esta manera, un bot con sesión iniciada será bloqueado / estrangulado tan pronto como comience a sondear su sitio. Esta es la parte facil. Los bots no autenticados son nuestro verdadero problema, y ​​así sucesivamente:

Segunda medida: alguna forma de limitación de IP, como lo sugieren casi todos:

No importa qué, tendrás que hacer un poco de aceleración basada en IP para frustrar el 'golpe de bot'. Puesto que parece importante para usted para permitir que los visitantes no autenticado (no registra-in) para obtener las ofertas especiales, es suficiente con IPs Para ir en el principio, y aunque no son perfectos, que hace el trabajo contra los robots de una sola IP. Las botnets son una bestia diferente, pero volveré sobre ellas. Por ahora, haremos una aceleración simple para vencer a los bots de IP única de disparo rápido.

El impacto en el rendimiento es insignificante si ejecuta la comprobación de IP antes de todos los demás procesos, utiliza un servidor proxy para la lógica de limitación y almacena las IP en una estructura de árbol optimizada para la búsqueda en memoria caché.

Tercera medida: Encubrir el acelerador con respuestas en caché:

Con la aceleración de los bots de una sola IP de disparo rápido, todavía tenemos que abordar los bots lentos de una sola IP, es decir. los bots que se ajustan específicamente para "volar por debajo del radar" espaciando las solicitudes un poco más separadas de lo que impide la aceleración.

Para que los bots lentos de una sola IP se vuelvan instantáneamente inútiles, simplemente use la estrategia sugerida por abelenky: sirva las páginas 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 'oportunidad' 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 frustra los 'bots de alarma', siempre que no se originen en una botnet.

(Sé que probablemente preferiría que a los usuarios reales se les permitiera actualizar una y otra vez, pero no hay forma de distinguir a un humano de actualización de spam de un robot 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 situación, pueden ser su mejor amigo: si ha diseñado un sistema muy restrictivo para frustrar a los bots, eso, debido a su restricción, también atrapa una serie de falsos positivos; entonces un CAPTCHA servido como último recurso permitirá a aquellos usuarios reales que sean atrapados por su estrangulamiento (evitando así situaciones molestas de DoS).

El punto óptimo, por supuesto, es cuando TODOS los bots quedan atrapados en su red, mientras que muy pocos usuarios reales se molestan por el CAPTCHA.

Si, al publicar las páginas almacenadas en caché de 10 minutos de antigüedad, también ofrece una alternativa, opcional , "actualización de la página principal" verificada por CAPTCHA, entonces los humanos que realmente quieren seguir actualizando, aún pueden hacerlo sin obtener la página almacenada en caché anterior , pero a costa de tener que resolver un CAPTCHA para cada actualización. Que es una molestia, pero uno opcional sólo para los usuarios empedernidos, que tienden a ser más tolerantes, ya que saben que están jugar con el sistema para mejorar sus posibilidades, y que las posibilidades mejoradas no son gratuitos.

Quinta medida: Mierda de señuelo:

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 también otras dos 'ofertas', que ningún humano elegiría, como una almendra de 12 mm por $ 20. Cuando la oferta aparezca en la página principal, coloque las tres 'ofertas' en la misma imagen, con los números correspondientes a cada oferta. Cuando el usuario / bot realmente ordena el artículo, tendrá que elegir (un botón de radio) la oferta que desea, y dado que la mayoría de los bots simplemente estarían adivinando, en dos de tres casos, los bots comprarían sin valor. basura.

Naturalmente, esto no aborda los 'bots de alarma', y existe una posibilidad (escasa) de que alguien pueda construir un bot que pueda elegir el elemento correcto. Sin embargo, el riesgo de comprar basura accidentalmente debería hacer que los scripters se vuelvan completamente de los bots totalmente automatizados.

Sexta medida: estrangulamiento de botnet:

[eliminado]

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

Así que ahí lo tienes : mi sexta medida es nada. Nada. Código Postal. A menos que la botnet 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 botnets que no implique una verificación humana explícita como CAPTHAs. Lo siento, pero creo que combinar las cinco medidas anteriores es tu mejor opción. Y probablemente podría hacerlo bien solo con el truco de almacenamiento en caché de 10 minutos de abelenky solo.

¿Qué tal introducir un retraso que requiere la 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 reventar bolas a cuadros y evitar explotar bolas sólidas (¡evitando problemas de daltonismo!). El juego recibiría una semilla de número aleatorio y lo que el juego transmite al servidor serían las coordenadas y 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 realmente habrían reventado las bolas. Si lo hicieran, no solo eran humanos, sino que tardaron 30 segundos en validarse. Dales una identificación de sesión.

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

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á buscando 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 descartar paquetes de una IP en el firewall después de varias conexiones por segundo / minuto / etc. Por ejemplo, el firewall estándar de Linux, iptables, tiene una función de coincidencia de operación estándar 'hashlimit', que podría usarse para correlacionar las solicitudes de conexión por unidad de tiempo con una dirección IP.

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

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

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 bots. Simplemente administraría una lista de direcciones IP que se conectaron en los últimos segundos. Detecta una ráfaga de solicitudes de una sola dirección IP y luego demora 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 su tiempo de respuesta de 2mS a 4mS (o incluso 400mS) mientras que un bot se verá obstaculizado por la demora creciente con bastante rapidez.

1. Proporcione una fuente RSS para que no consuman su ancho de banda.
2. Al comprar, haga que todos esperen una cantidad aleatoria de tiempo de hasta 45 segundos o algo, dependiendo de lo que esté buscando exactamente. ¿Cuáles son exactamente sus limitaciones de tiempo?
3. Dé a todos 1 minuto para poner su nombre en el sorteo y luego seleccione personas al azar. Creo que esta es la forma más justa.
4. Monitoree las cuentas (¿algunas veces en la sesión y almacénelas?) Y agregue demoras a las cuentas que parecen estar por debajo del umbral de velocidad humana. Eso al menos hará que los bots se programen para reducir la velocidad y competir con los humanos.

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

Si podemos aceptar la premisa de que podemos imponer algún costo a un visitante woot completamente nuevo en sus primeros hits de página, creo que tengo una posible solución. Por falta de un nombre mejor, voy a llamar a esta solución "visita al DMV".

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

El problema es que el concesionario requiere que visite el concesionario y muestre una licencia de conducir válida antes de que pueda ingresar 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.

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

Se permiten otros visitantes con una licencia de conducir válida, después de mostrar su licencia de conducir. Una persona que se molesta a sí misma merodeando todo el día, molestando a los vendedores, agarrando folletos y vaciando el café y las galletas de cortesía eventualmente será rechazada.

Ahora, de vuelta 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 autos en cualquier momento que desee, a menos que accidentalmente deje su billetera en casa, o su licencia sea destruida o revocada de otra manera.

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 "Comenzar aquí". Bob tiene que llevar la solicitud completada a la ventana n. ° 1, donde el primero de muchos servidores públicos maleducados tomará su solicitud, la procesará y, si todo está en orden, sellará la solicitud para la ventana y la enviará a la siguiente ventana. Y así, Bob pasa de una ventana a otra, esperando que se complete cada paso de su solicitud, hasta que finalmente llega al final y recibe su licencia de conducir.

No tiene sentido tratar de "cortocircuitar" el DMV. Si los formularios no se completan correctamente por triplicado, o se dan respuestas incorrectas en cualquier ventana, la solicitud se desgarra y el desafortunado cliente es enviado de regreso al inicio.

Curiosamente, no importa cuán llena o vacía esté la oficina, se necesita aproximadamente la misma cantidad de tiempo para recibir servicio en cada ventana sucesiva. Incluso cuando eres la única persona en la fila, 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 vestíbulo del DMV. De hecho, el infomerical se ejecuta el tiempo suficiente para cubrir la cantidad de tiempo que pasa obteniendo su licencia.

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

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

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

Digamos, para discusión, el token (también conocido como "licencia de conducir") consta de 20 fragmentos. Para obtener cada fragmento sucesivo, 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 la siguiente solicitud de fragmento (es decir, los sellos deben pasar de una ventana del DMV a la 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 usar para limitar sus actividades.

En el lado del servidor, solo acepta vistas de página de clientes que tienen un token válido. O, si es importante que todos puedan ver la página, 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, no haga que el proceso de emisión de tokens suceda de manera relativamente no intrusiva en el fondo. De ahí la necesidad de una página de bienvenida con una copia entretenida y gráficos que se reduzcan un poco deliberadamente.

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

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

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

• Requiere ejecutar una función de 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 usuarios reales que no sean javascript (mínimo).

• Mida el tiempo de las pulsaciones de teclas al escribir en el formulario (nuevamente a través de javascript). Si no es humano, rechazarlo. Es un dolor imitar la escritura humana en un bot.

• Escriba su código para actualizar diariamente sus ID de campo 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 a su código de bot.

• Podría ir aún más lejos y usar contenido Flash. Flash es totalmente una molestia contra la que escribir un bot.

En general, si comienza a pensar en no prevenirlos, pero haciendo que funcione más para ellos, probablemente pueda lograr el objetivo que está buscando.

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

No veo la gran carga que reclamas al verificar las IP entrantes. Por el contrario, hice 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 él no quería eso por alguna razón que nunca entendí completamente) y crea reglas de firewall para bloquear conexiones desde cualquier dirección IP que genere un número excesivo de solicitudes a menos que se pueda confirmar que la dirección pertenece 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 las mil visitas por segundo y nunca ha habido un problema de rendimiento: los cortafuegos son muy eficientes para descartar paquetes de direcciones en la lista negra.

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

Mi enfoque sería centrarme en soluciones no tecnológicas (de lo contrario, estará entrando en una carrera armamentista que perderá, o al menos gastará una gran cantidad de tiempo y dinero). Me centraría en las partes de facturación / envío: puede encontrar bots ya sea encontrando entregas múltiples a la misma dirección o mediante múltiples cargos a un solo método de pago. Incluso puede hacer esto en varios artículos durante varias semanas, por lo que si un usuario obtuvo un artículo anterior (respondiendo muy, muy rápido), esta vez se le puede asignar algún tipo de "discapacidad".

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

La mayoría de las soluciones puramente técnicas ya se han ofrecido. Por lo tanto, sugeriré otra visión del problema.

Según tengo entendido, los bots son creados por personas que realmente intentan comprar las bolsas que estás vendiendo. El problema es -

1. Otras personas, que no operan bots, merecen la oportunidad de comprar, y usted ofrece una cantidad limitada de bolsas.
2. Desea atraer humanos a su sitio y simplemente vender las bolsas.

En lugar de tratar de evitar los bots, puede permitir que los compradores potenciales de bolsas se suscriban a un correo electrónico, o incluso a una actualización por SMS, para recibir una notificación cuando se realice una venta. Incluso puede darles uno o dos minutos de ventaja (una URL especial donde comienza la venta, generada aleatoriamente y enviada con el correo / SMS).

Cuando estos compradores van a comprar están en su sitio, puede mostrarles lo que quiera en pancartas laterales o lo que sea. Aquellos que ejecutan los bots preferirán simplemente registrarse en su servicio de notificación.

Los corredores de bots aún pueden ejecutar bots en su notificación para finalizar la compra más rápido. Algunas soluciones pueden ofrecer una compra con un solo clic.

Por cierto, mencionó que sus usuarios no están registrados, pero parece que quienes 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 estoy sugiriendo es tratar de ver el problema como social, en lugar de técnico.

Asaf

Agentes de usuario con bloqueo de tiempo que realizan tantas solicitudes por minuto. Por ejemplo, si alguien solicita una página exactamente cada 5 segundos durante 10 minutos, probablemente no sea un usuario ... Pero podría ser complicado hacerlo bien.

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

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

La prevención de DoS derrotaría el # 2 de los objetivos de @ davebug que describió anteriormente, "Mantener el sitio a una velocidad no ralentizada por los bots" pero no necesariamente resolvería el # 1, "Vende el artículo a humanos que no escriban guiones"

Estoy seguro de que un scripter podría escribir algo para patinar justo por 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.

Está bien, ¿entonces los spammers están compitiendo con gente común y corriente para ganar la subasta de "bog of crap"? ¿Por qué no hacer que la próxima subasta sea literalmente una "bolsa de basura"? Los spammers pueden pagar un buen dinero por una bolsa llena de perritos, y todos nos reímos de ellos.

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

Así que grabas éxitos en tu página de inicio. Cada vez que alguien llega a la página, esa conexión se compara con su último acceso, y si fue demasiado rápido, se le envía una versión de la página sin la oferta. Esto puede hacerse mediante algún tipo de mecanismo de equilibrio de carga que envía bots (los golpes que son 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 bots piensen que todavía se les está sirviendo las páginas correctamente.

Aún mejor si la oferta se puede rechazar de alguna manera. Entonces aún puede hacer las ofertas en el servidor falso pero cuando el bot complete el formulario diga "Lo siento, no fuiste lo suficientemente rápido" :) Entonces definitivamente pensarán que todavía están en el juego.

¿Cómo sabes que hay scripters haciendo pedidos?

El quid de su problema es que no puede separar los scripters de los usuarios legítimos y, por lo tanto, no puede bloquearlos, entonces, ¿cómo es que sabe que hay scripters?

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

Veamos el problema: tienes bots que compran cosas que quieres que compren personas reales, ¿ qué tal si tienes la posibilidad real de que los bots compren cosas que no quieres que compren las personas reales?

Tenga una oportunidad aleatoria para algunos html no mostrados de que los robots de scraping pensarán que es la situación real, pero las personas reales no verán (y no olviden que las personas reales incluyen a los ciegos, así que considere también los lectores de pantalla, etc.), y esto viaja para comprar algo exorbitantemente caro (o no hace la compra real, pero obtiene detalles de pago para que usted los ponga en una lista de prohibición).

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