Evitar que los scripters golpeen tu sitio web

https://stackoverflow.com/questions/450835

19-08-2019
|

Pregunta

Acepté una respuesta, pero lamentablemente, creo que estamos atrapados en nuestro peor escenario original: CAPTCHA a todos en 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 que 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 pueden intentarlo, ya que es 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 de 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 de spambot yb) atrapa demasiados inocentes dada la cantidad de empresas que provienen de una dirección IP (sin mencionar los problemas con los ISP IP no estáticos y los posibles problemas de rendimiento al 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 diseñados con bastante firmeza 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 con capacidad de JavaScript.

& nbsp;

lc de nuevo : " A menos que, por supuesto, la exageración sea parte de su esquema de marketing. & Quot; Sí, definitivamente lo es. La sorpresa de cuándo aparece el artículo, así como la emoción si logras obtener uno, es probablemente mucho 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 basura.

& nbsp;

¿Fue útil?

Solución

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

Si está utilizando 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.

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

En cuanto a la captura de demasiados inocentes, puede colocar 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 esto. " (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 personalmente le LLAME para que elimine el bloqueo.

Hacer que la gente llame parece una medida tonta, 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 ocurrir a menos que sea un bot (por ejemplo, fallar la verificación varias veces seguidas). Luego obliga a 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 por asegurarse de que sus usuarios sean humanos para aceptar un par de llamadas telefónicas cuando salgan a la venta? Si me preocupara tanto que un producto llegara a usuarios humanos, tendría que tomar esta decisión, quizás sacrificando un poco (poco) de mi tiempo en el proceso.

Dado que parece que está decidido a no permitir 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 largo (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 (mismo) o correo postal (lleva demasiado tiempo).

Podría, por supuesto, 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 querer.

Otros consejos

Necesitas encontrar una manera de hacer que los bots compren cosas que son demasiado caras: almendra de 12 mm: $ 20. Vea cuántos bots se rompen 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 seguirá apareciendo en un seguimiento ocasional aleatorio.

Mantenga una memoria caché de su página de unos 10 minutos antes.
Cuando un repetidor / bot golpea su sitio, dele la página en caché de 10 minutos.

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 "personas reales". tendrá 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)
La publicación de 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!

Drawbacks

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

¿Qué opinas?

Eche 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 bots al tener   las personas se identifican, podemos   detener los bots haciéndolo difícil   para que hagan una publicación exitosa, o   haciendo que inadvertidamente se identifiquen   ellos mismos como bots. Esto elimina el   carga de la gente, y deja el   formulario de comentarios libre de antispam visible   medidas.

Esta técnica es cómo evito   spambots en este sitio. Funciona. los   método descrito aquí no mira   el contenido en absoluto.

Algunas otras ideas:

Cree un mecanismo de notificación automática oficial (¿RSS feed? ¿Twitter?) al que las personas puedan suscribirse cuando su producto salga a la venta. Esto reduce la necesidad de que las personas creen scripts.
Cambie su técnica de ofuscación justo antes de que salga a la venta un nuevo artículo. 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 pase por 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 evitar que ESO sea realmente posible.

Con respecto a sus comentarios sobre la efectividad de las estrategias de Ned: Sí, él habla sobre los honeypots, pero no creo que sea su estrategia más fuerte. Su discusión sobre el 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:

La ruleta es un campo oculto utilizado para   algunas cosas: junta un   cantidad de valores que impiden   manipulación y repeticiones, y se utiliza para   nombres de campo oscuros. La ruleta es un   Hash MD5 de:


La marca de tiempo,

La dirección IP del cliente,

La identificación de la entrada del blog que se está comentando, y

Un secreto.

Así es como podría implementar eso en WOOT.com:

Cambiar el "secreto" valor que se usa como parte del hash cada vez que sale un nuevo artículo a la venta. ¡Esto significa que si alguien va a diseñar un BOT para comprar artículos automáticamente, solo funcionará hasta que el próximo 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 está resuelto!

La otra estrategia que analiza es cambiar la técnica honeypot de vez en cuando (nuevamente, 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 que contiene 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.

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

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

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

P: ¿Cómo evitaría que los scripters golpeen su sitio cientos de veces por segundo?
A: no lo haces. No hay forma de prevenir 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 como las personas pueden 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 (en caché, por supuesto) cuando se solicita la página
mantén 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 se alineará para que parezca ser 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 código que debe ingresarse manualmente para adquirir el premio. CAPTCHA el código si lo desea, pero probablemente no sea necesario.
para seguridad adicional, el código puede ser un token de una sola vez 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 nuevamente') 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. Eventualmente, los scripters 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 (puede que tenga que hackear / extender la web servidor para hacer esto, pero probablemente valdrá 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 buscan 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 quiere molestar a algunos señores bot, lo que puede no ser 100% aconsejable.

Entonces, el problema realmente parece ser: los bots quieren su '' bolsa 'o basura' ' porque tiene un alto valor percibido a un precio percibido bajo. A veces ofreces este artículo y los bots acechan, esperando para 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 animarlos a comprar la basura.

Primero, siempre ofrece la " bag 'o crap " ;.

Segundo, asegúrate de que la basura es generalmente basura.

Tercero, gire la basura con frecuencia.

Simple, ¿no?

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

Cuando el bot ve que hay basura y la basura se compra automáticamente, el destinatario se va a enfadar terriblemente por haber pagado $ 10 por un palillo roto. Y luego una bolsa de basura vacía. Y luego algo de suciedad desde 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 efectivo" ; en tu '' bolsa 'o basura' '. Incluso la intervención humana por su parte (verificar para asegurarse de que la basura no sea basura) puede fallar si gira la basura con la frecuencia suficiente. Demonios, tal vez los bots se darán cuenta y no comprarán 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 cuánto de la "basura" Se está vendiendo la carpa. 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.

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



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



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

Probablemente no quieras escuchar esto, pero # 1 y # 3 son mutuamente excluyentes.

En Internet, nadie sabe que eres un perro

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, 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.

No solo eso 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 artículo 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 "primero llegado, primero 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:

Viendo la página principal
Pedidos

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 ocurrir 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 todavía tendría una ventaja importante en el primer movimiento, y no hay forma de que sepas 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 utilizar 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.

Segundo, 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 geniales por ser flexibles, pero 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 en el manejo del tráfico como en luchando adecuadamente contra los robots).

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 leyendo la página de mem

Descargo de responsabilidad: esta respuesta no está 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 de orden de llegada? A menos, por supuesto, que la publicidad 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 anticipados): 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 sorteo (todos los que intentan ordenar uno ingresan al sistema) - De esta manera, las personas con los scripts tienen las mismas posibilidades 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.
(el crédito es para David Schmitt por esta, los comentarios son míos) - La gente todavía puede usar scripts para atacar en el último minuto, pero no solo cambia la estructura de precios, sino que la gente espera estar luchando con los demás. 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 los nazis pensaran que eran sus comunicaciones, los aliados solían romper sus mensajes. No importa cómo intentes evitar que los bots usen tu sitio, los propietarios de bots lo resolverán. Lo siento si eso te convierte en el 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 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 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 el cliente está comprando cosas.

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

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

Con el tiempo, aparecerá 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 publicación / compra, independientemente de la duración de la ventana, entonces eso 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 está 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

Su pedido se ha realizado y está en una cola.
Su pedido ha sido procesado.
Su pedido ha sido enviado.

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 durante el "tiempo promedio de pedido humano + x horas". Reducción efectiva de bots para humanos.

Digo exponer la información del precio usando 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.

Puede 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.

¿Qué tal si introducimos 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. Darles una identificación de sesión.

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

Primero, permítanme recapitular lo que necesitamos hacer aquí. Me doy cuenta de que solo estoy parafraseando la pregunta original, pero es importante que la aclaremos 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 cada pasajero inocente a saltar a través de aros de seguridad locos por La pequeña posibilidad de atrapar a los más estúpidos terroristas. Oh, espera, de hecho hacemos eso. Pero veamos 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 burladas.

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 con 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:

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á 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 algo de aceleración basada en IP para frustrar el 'golpe de bot'. Dado que le parece importante permitir que los visitantes no autenticados (que no hayan iniciado sesión) reciban ofertas especiales, solo tiene que usar las IP inicialmente, y aunque no son perfectas, funcionan contra bots de IP única. 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, use un servidor proxy para la aceleraciónlógica y almacenar las IP en una estructura de árbol optimizada para la búsqueda de 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 están específicamente ajustados para 'volar por debajo del radar' al espaciar las solicitudes un poco más separadas de lo que impide la aceleración.

Para hacer instantáneamente inútiles los bots lentos de una sola IP, 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 han 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 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 la situación de _one_ 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 usted, al servir las páginas 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 desea seguir actualizando, aún puede hacerlo sin obtener la página en caché anterior, pero a costa de tener que resolver un CAPTCHA para cada actualización. Eso es una molestia, pero opcional solo para los usuarios acérrimos, que tienden a ser más indulgentes porque saben que son jugar el sistema para mejorar sus posibilidades, y esas posibilidades mejoradas no son gratuitas.

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 nuez de ala 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 como 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 accidentalmente basura debería hacer que los scripters se vuelvan completamente de los bots totalmente automatizados.

Sexta medida: limitación de botnet:

[eliminado]

Bien ............ Ahora he pasado la mayor parte de mi noche pensando en esto, probando diferentes enfoques ... retrasos globales ... tokens basados ??en cookies ... servicio 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 una red / zombie / bot distribuida

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á viendo un verdadero martilleo , entonces en realidad está lidiando con un ataque DoS, y probablemente debería tratar de manejarlo en consecuencia. Un enfoque común es simplemente soltar 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 sería 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 que su tiempo de respuesta vaya de 2 ms a 4 ms (o incluso 400 ms) mientras que un bot se verá obstaculizado por la creciente demora con bastante rapidez.

Proporcione una fuente RSS para que no come tu ancho de banda.
Al comprar, hacer que todos esperen al azar cantidad de tiempo de hasta 45 segundos o algo, dependiendo de qué Estás buscando exactamente. Exactamente ¿Cuáles son sus limitaciones de tiempo?
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.
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, y al mismo tiempo poder 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 primeras visitas a la página, creo que tengo una posible solución. Por 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 algunos días, usted 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 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 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 el " Comience aquí " cola. 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 aplicación, hasta que finalmente llega al final y recibe su licencia de conducir.

No tiene sentido tratar de "cortocircuito" 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 pronunciar, "¡Siguiente!"

Sin embargo, las cosas no son tan terribles en el DMV. Mientras se lleva a cabo 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 cierta capacidad 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 completamente 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 token de identificación es lento

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 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 forzará nuevamente 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.

Generalmente, si comienzas a pensar en no prevenirlos, pero haciendo que funcione más para ellos, probablemente puedas lograr el objetivo que estás 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 está viendo 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, entrará 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), se le puede asignar algún tipo de "discapacidad". esta vez.

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 vista del problema.

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

Otras personas, que no operan bots, merecen la oportunidad de comprar, y usted ofrece una cantidad limitada de bolsas.
Quiere 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 notificaciones 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 notificaciones.

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 sugiero es que intente 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 correctamente.

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 solicitudes de páginas e ignorar todas las solicitudes de medios (js, imágenes, etc.).

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

Estoy seguro de que un programador 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.

Muy bien, por lo que los spammers están compitiendo con personas normales y competitivas para ganar la "ciénaga de basura". ¿subasta? ¿Por qué no hacer que la próxima subasta sea una literal "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 elimina 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 todavía puede hacer las ofertas en el servidor falso, pero cuando el bot complete el formulario, diga "Lo siento, no fue 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 crees una posibilidad real de que los bots compren cosas que no quieres personas reales para comprar.

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 incluya 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, puede hacer que sea lo suficientemente inútil para las personas (tal vez no para todos, pero alguna reducción en la estafa es mejor que ninguna) para no molestarse.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow