Aceitei uma resposta, mas, infelizmente, acredito que estamos presos ao nosso pior cenário original: CAPTCHA todo mundo nas tentativas de compra da porcaria . Breve explicação: o armazenamento em cache / web farms torna impossível rastrear hits, e qualquer solução alternativa (enviar um web beacon não armazenado em cache, gravar em uma tabela unificada etc.) torna o site mais lento do que os bots. É provável que haja algum hardware caro da Cisco ou algo semelhante que possa ajudar em um nível alto, mas é difícil justificar o custo se o CAPTCHA de todo mundo for uma alternativa. Tentarei uma explicação mais completa mais tarde, bem como a limpeza para futuros pesquisadores (embora outros sejam bem-vindos, como é o wiki da comunidade).

Situação

Trata-se das vendas de porcaria no woot.com. Sou o presidente do Woot Workshop, a subsidiária da Woot que faz o design, escreve as descrições dos produtos, podcasts, posts do blog e modera os fóruns. Eu trabalho com CSS / HTML e só estou familiarizado com outras tecnologias. Eu trabalho em estreita colaboração com os desenvolvedores e conversamos sobre todas as respostas aqui (e muitas outras idéias que tivemos).

A usabilidade é uma parte enorme do meu trabalho, e tornar o site emocionante e divertido é a maior parte do resto. É aí que os três objetivos abaixo derivam. O CAPTCHA prejudica a usabilidade e os bots roubam a diversão e a emoção de nossas vendas ruins.

Bots estão batendo a nossa página principal dezenas de vezes por uma segunda tela raspando (e / ou escaneando nosso RSS) pela venda Random Crap. No momento em que veem isso, ele aciona um segundo estágio do programa que efetua login, clica em Quero um, preenche o formulário e compra a porcaria.

Avaliação

lc : No stackoverflow e em outros sites que usam esse método, eles quase sempre lidam com usuários autenticados (conectados), porque a tarefa que está sendo executada exige isso.

No Woot, usuários anônimos (não registrados) podem visualizar nossa página inicial. Em outras palavras, os bots slamming podem não ser autenticados (e essencialmente não rastreáveis, exceto pelo endereço IP).

Portanto, voltamos à varredura de IPs, que: a) é bastante inútil nessa era de redes em nuvem e zumbis spambot eb) captura muitos inocentes, dado o número de empresas provenientes de um endereço IP (sem mencionar os problemas com ISPs IP não estáticos e possíveis resultados de desempenho para tentar rastrear isso).

Ah, e ter pessoas nos ligando seria o pior cenário possível. Podemos que eles liguem para você?

BradC : Os métodos de Ned Batchelder parecem bem legais, mas são bem projetados para derrotar os bots criados para uma rede de sites. Nosso problema é que os bots são criados especificamente para derrotar nosso site. É possível que alguns desses métodos funcionem por um curto período de tempo até que os scripts desenvolvam seus bots para ignorar o honeypot, raspar a tela para nomes de rótulos próximos, em vez de identificações de formulário, e usar um controle de navegador compatível com javascript.

lc novamente : "A menos, claro, que o hype faça parte do seu esquema de marketing". Sim, definitivamente é. A surpresa de quando o item aparece, bem como a emoção de conseguir um, é provavelmente tão ou mais importante quanto a porcaria que você realmente acaba recebendo. Qualquer coisa que elimine o primeiro a chegar / primeiro a servir é prejudicial à emoção de 'vencer' a porcaria.

novatruste : E eu, por exemplo, dou as boas-vindas aos nossos novos senhores de bots. Na verdade, oferecemos feeds RSS para permitir que aplicativos de terceiros analisem nosso site em busca de informações sobre o produto, mas não antes do HTML do site principal. Se estou interpretando corretamente, sua solução ajuda a meta 2 (problemas de desempenho) sacrificando completamente a meta 1 e renunciando apenas ao fato de que os bots estarão comprando a maior parte do lixo. Votei positivamente sua resposta, porque seu pessimismo no último parágrafo parece exato para mim. Parece não haver bala de prata aqui.

O restante das respostas geralmente depende do rastreamento de IP, que novamente parece inútil (com redes de bots / zumbis / nuvem) e prejudicial (capturando muitos inocentes que vêm de destinos com o mesmo IP).

Alguma outra abordagem / idéia? Meus desenvolvedores continuam dizendo "vamos fazer o CAPTCHA", mas espero que haja métodos menos invasivos para todos os humanos de verdade que desejam um pouco da nossa porcaria.

Pergunta original

Digamos que você esteja vendendo algo barato que tenha um valor percebido muito alto e que tenha um valor muito limitado. Ninguém sabe exatamente quando você venderá este item. E mais de um milhão de pessoas vêm regularmente para ver o que você está vendendo.

Você acaba com scripts e bots tentando descobrir programaticamente quando você está vendendo o item mencionado, e [b] verifique se eles estão entre os primeiros a comprá-lo. Isso é péssimo por dois motivos:

1. Seu site é atacado por não-humanos, tornando tudo lento para todos.
2. Os roteiristas acabam 'ganhando' o produto, fazendo com que os frequentadores se sintam enganados.

Uma solução aparentemente óbvia é criar alguns obstáculos para que os usuários passem antes de fazer o pedido, mas há pelo menos três problemas com isso:

• A experiência do usuário é péssima para os seres humanos, pois eles precisam decifrar o CAPTCHA, escolher o gato ou resolver um problema de matemática.
• Se o benefício percebido for alto o suficiente e a multidão for grande o suficiente, alguns grupos encontrarão o caminho para qualquer ajuste, levando a uma corrida armamentista. (Isso é especialmente verdade quanto mais simples for o ajuste; o formulário 'comentários' ocultos, reorganizando os elementos do formulário, rotulando-os incorretamente, texto 'pegadinha' oculto, tudo funcionará uma vez e precisará ser alterado para combater a segmentação desse formulário específico .)
• Mesmo que os roteiristas não consigam 'resolver' o seu ajuste, isso não os impede de bater na sua primeira página e, em seguida, soar um alarme para o roteirista preencher o pedido manualmente. Dado que eles obtêm a vantagem de resolver [a], provavelmente ainda vencerão [b], pois serão os primeiros humanos a alcançar a página de pedidos. Além disso, 1. ainda acontece, causando erros no servidor e um desempenho reduzido para todos.

Outra solução é verificar se os IPs atingem com muita frequência, bloqueá-los do firewall ou impedi-los de fazer pedidos. Isso poderia resolver 2. e impedir [b], mas o desempenho atingido pela verificação de IPs é enorme e provavelmente causaria mais problemas como 1. do que os scripts estavam causando por conta própria. Além disso, a possibilidade de rede em nuvem e zumbis spambot torna a verificação de IP bastante inútil.

Uma terceira idéia, forçar o carregamento do formulário de pedidos por algum tempo (digamos, meio segundo) potencialmente retardaria o andamento dos pedidos rápidos, mas, novamente, os roteiristas ainda seriam as primeiras pessoas a qualquer velocidade não prejudicial para usuários reais.

Metas

1. Venda o item para humanos que não são scripts.
2. Mantenha o site funcionando a uma velocidade que não diminui a velocidade dos bots.
3. Não incomode os usuários "normais" com nenhuma tarefa a concluir para provar que é humano.

Que tal implementar algo como o SO faz com os CAPTCHAs?

Se você estiver usando o site normalmente, provavelmente nunca verá um. Se você recarregar a mesma página com muita frequência, poste comentários sucessivos com muita rapidez ou outra coisa que dispara um alarme, faça com que eles provem que são humanos. No seu caso, isso provavelmente seria recarregamentos constantes da mesma página, seguindo todos os links de uma página rapidamente ou preenchendo um formulário de pedido rápido demais para ser humano.

Se eles falharem na verificação x vezes seguidas (por exemplo, 2 ou 3), dê a esse IP um tempo limite ou outra medida desse tipo. Em seguida, no final do tempo limite, despeje-os novamente na verificação.

Como você tem usuários não registrados acessando o site, você tem apenas IPs para continuar. Você pode emitir sessões para cada navegador e acompanhar dessa maneira, se desejar. E, é claro, faça uma verificação humana se muitas sessões estiverem sendo (re) criadas em sucessão (caso um bot continue excluindo o cookie).

No que diz respeito a capturar muitos inocentes, você pode colocar um aviso na página de verificação humana: "Esta página também pode aparecer se muitos usuários anônimos estiverem visualizando nosso site no mesmo local. Recomendamos que você se registre ou faça login para evitar isto." (Ajuste as palavras adequadamente.)

Além disso, quais são as chances de as pessoas X estarem carregando as mesmas páginas ao mesmo tempo em um IP? Se eles estiverem altos, talvez você precise de um mecanismo de acionamento diferente para o seu alarme de bot.

Editar: Outra opção é se eles falharem muitas vezes, e você estiver confiante sobre a demanda do produto, para bloqueá-los e fazê-los pessoalmente CHAMAR para remover o bloco.

Chamar as pessoas parece uma medida estúpida, mas garante que haja um humano em algum lugar atrás do computador . A chave é ter o bloco apenas no lugar de uma condição que quase nunca deve acontecer, a menos que seja um bot (por exemplo, falha na verificação várias vezes seguidas). Em seguida, força a interação humana - para atender o telefone.

Em resposta ao comentário de que eles me liguem, obviamente há essa troca aqui. Você está preocupado o suficiente em garantir que seus usuários sejam humanos para aceitar algumas ligações telefônicas quando estiverem à venda? Se eu estivesse tão preocupado com um produto que chegasse a usuários humanos, teria que tomar essa decisão, talvez sacrificando um pouco (pequeno) do meu tempo no processo.

Como parece que você está determinado a não permitir que os bots atinjam o seu site, acredito que o telefone pode ser uma boa opção. Como não lucro com seu produto, não tenho interesse em receber essas ligações. No entanto, se você compartilhar parte desse lucro, posso me interessar. Como este é o seu produto, você deve decidir quanto se importa e implementar de acordo.

As outras maneiras de liberar o bloqueio simplesmente não são tão eficazes: um tempo limite (mas eles atingem seu site novamente após uma repetição de enxágüe), um longo tempo (se realmente era um humano tentando comprar seu produto, eles seriam SOL e punidos por falharem na verificação), e-mail (feito com facilidade por bots), fax (o mesmo) ou correio tradicional (leva muito tempo).

Você poderia, é claro, aumentar o período de tempo limite por IP para cada vez que eles receberem um tempo limite. Apenas certifique-se de não punir humanos verdadeiros inadvertidamente.

Você precisa descobrir uma maneira de fazer com que os bots comprem coisas muito caras: 12mm wingnut: $ 20. Veja quantos bots são necessários antes que os roteiristas decidam que você está jogando com eles.

Use os lucros para comprar mais servidores e pagar pela largura de banda.

Minha solução seria tornar a raspagem de tela inútil, colocando um atraso de aproximadamente 10 minutos para 'bots e scripts.

Aqui está como eu faria isso:

• Registre e identifique quaisquer rebatedores repetidos.

Você não precisa registrar todos os endereços IP em cada ocorrência. Acompanhe apenas uma em cada 20 ocorrências. Um reincidente ainda aparecerá em um rastreamento ocasional aleatório.

• Mantenha um cache da sua página cerca de 10 minutos antes.

• Quando um batedor / repetidor atingir o seu site, forneça a página em cache de 10 minutos.

Eles não saberão imediatamente que estão recebendo um site antigo. Eles serão capazes de eliminá-lo e tudo mais, mas não vencerão mais nenhuma corrida, porque "pessoas reais" terão 10 minutos de vantagem.

Benefícios:

• Sem problemas ou problemas para os usuários (como CAPTCHAs).
• Implementado totalmente no lado do servidor. (sem dependência de Javascript / Flash)
• A veiculação de uma página em cache mais antiga deve ter menos desempenho do que uma página ativa. Você pode realmente diminuir a carga nos seus servidores dessa maneira!

Desvantagens

• Requer rastreamento de alguns endereços IP
• Requer manter e manter um cache de páginas mais antigas.

O que você acha?

Dê uma olhada neste artigo de ned Batchelder aqui . O artigo dele é sobre como parar spambots, mas as mesmas técnicas podem ser facilmente aplicadas ao seu site.

Em vez de interromper os bots fazendo com que as pessoas se identifiquem, podemos pará-los, dificultando a publicação bem-sucedida ou fazendo com que eles se identifiquem inadvertidamente como bots. Isso elimina o ônus das pessoas e deixa o formulário de comentários livre de medidas anti-spam visíveis.

Esta técnica é como evito spambots neste site. Funciona. O método descrito aqui não analisa o conteúdo.

Algumas outras idéias:

• Crie um mecanismo oficial de notificação automática (feed RSS? Twitter?) No qual as pessoas possam assinar quando o seu produto estiver à venda. Isso reduz a necessidade de as pessoas criarem scripts.
• Mude sua técnica de ofuscação antes de um novo item ser colocado à venda. Portanto, mesmo que os roteiristas possam escalar a corrida armamentista, eles estão sempre um dia atrasados.

EDIT: Para ser totalmente claro, o artigo de Ned acima descreve métodos para impedir a COMPRA automatizada de itens, impedindo que um BOT passe pelos formulários para enviar um pedido. Suas técnicas não seriam úteis para impedir que os robôs rasparem a página inicial para determinar quando um Bandoleer of Carrots será vendido. Não tenho certeza de impedir que isso seja realmente possível.

Com relação aos seus comentários sobre a eficácia das estratégias de Ned: Sim, ele discute honeypots, mas não acho que essa seja a estratégia mais forte dele. Sua discussão sobre o SPINNER é a razão original pela qual mencionei seu artigo. Desculpe, eu não deixei isso mais claro no meu post original:

O botão giratório é um campo oculto usado para algumas coisas: ele reúne vários valores que impedem adulterações e repetições e é usado para ocultar nomes de campos. O botão giratório é um hash MD5 de:

• O timestamp,
• O endereço IP do cliente,
• O ID da entrada do blog que está sendo comentada e
• Um segredo.

Aqui está como você pode implementar isso no WOOT.com:

Altere o valor "secreto" usado como parte do hash sempre que um novo item for colocado à venda. Isso significa que, se alguém for projetar um BOT para comprar itens automaticamente, ele só funcionará até que o próximo item seja colocado à venda !

Mesmo que alguém consiga reconstruir rapidamente seu bot, todos os outros usuários reais já terão comprado um BOC e seu problema será resolvido!

A outra estratégia que ele discute é alterar a técnica do honeypot de tempos em tempos (novamente, altere-a quando um novo item for colocado à venda):

• Use classes CSS (aleatoriamente, é claro) para definir os campos ou um elemento contendo para exibir: none.
• Colora os campos da mesma forma (ou muito semelhantes) ao plano de fundo da página.
• Use o posicionamento para mover um campo para fora da área visível da página.
• Torne um elemento muito pequeno para mostrar o campo de honeypot contido.
• Deixe os campos visíveis, mas use o posicionamento para cobri-los com um elemento obscurecedor.
• Use Javascript para efetuar qualquer uma dessas alterações, exigindo que um bot tenha um mecanismo Javascript completo.
• Deixe os honeypots exibidos como os outros campos, mas peça às pessoas para não inserirem nada neles.

Acho que minha idéia geral é ALTERAR O FORMULÁRIO DE FORMA quando cada novo item for colocado à venda. Ou, pelo menos, altere-o quando um novo BOC for colocado à venda.

Qual é o quê, algumas vezes / mês?

Se você aceitar esta resposta, me avisará quando a próxima deve chegar? :)

P: Como você impediria que os roteiristas batessem no seu site centenas de vezes por segundo?
A: você não. Não há como impedir esse comportamento por agentes externos.

Você pode empregar uma vasta gama de tecnologia para analisar solicitações recebidas e tentar heuristicamente determinar quem é e não é humano ... mas isso falharia. Eventualmente, se não imediatamente.

A única solução viável a longo prazo é mudar o jogo para que o site não seja compatível com bot ou seja menos atraente para os roteiristas.

Como você faz isso? Bem, essa é uma pergunta diferente! ;-)

...

OK, algumas opções foram dadas (e rejeitadas) acima. Eu não estou intimamente familiarizado com o seu site, já que o observei apenas uma vez, mas como as pessoas podem ler texto em imagens e bots não podem fazer isso facilmente, altere o anúncio para ser uma imagem. Não é um CAPTCHA , apenas uma imagem -

• gerar a imagem (em cache, é claro) quando a página for solicitada
• mantenha o nome da fonte da imagem o mesmo, para não revelar o jogo
• na maioria das vezes a imagem terá texto comum e será alinhada para parecer fazer parte da página HTML embutida
• quando o jogo está ligado, a imagem muda para o texto do anúncio
• o texto do anúncio revela um URL e / ou código que deve ser inserido manualmente para adquirir o prêmio. CAPTCHA o código, se quiser, mas isso provavelmente não é necessário.
• para segurança adicional, o código pode ser um token único gerado especificamente para a solicitação / IP / agente, para que solicitações repetidas gerem códigos diferentes. Ou você pode pré-gerar vários códigos aleatórios (um teclado único) se a geração sob demanda for muito exigente.

Execute testes de tempo de pessoas reais respondendo a isso e ignore ('opa, ocorreu um erro, desculpe! Tente novamente') as respostas mais rapidamente do que (digamos) metade desse tempo. Este evento também deve acionar um alerta para os desenvolvedores de que pelo menos um bot descobriu o código / jogo, então é hora de mudar o código / jogo.

Continue alterando o jogo periodicamente de qualquer maneira, mesmo que nenhum robô o ative, apenas para perder o tempo dos roteiristas. Eventualmente, os roteiristas devem se cansar do jogo e ir para outro lugar ... esperamos ;-)

Uma sugestão final: quando uma solicitação para sua página principal chegar, coloque-a em uma fila e responda às solicitações em ordem em um processo separado (talvez você precise hackear / estender o servidor da Web para fazer isso, mas provavelmente será que vale a pena). Se outra solicitação do mesmo IP / agente chegar enquanto a primeira solicitação estiver na fila, ignore-a. Isso deve eliminar automaticamente a carga dos bots.

EDIT: outra opção, além do uso de imagens, é usar o javascript para preencher o texto de compra / não compra; robôs raramente interpretam javascript, para que não o vejam

Não sei como isso é viável: ... entre na ofensiva.

Descubra quais dados os bots estão pesquisando. Alimente-os com os dados que eles estão procurando quando você NÃO está vendendo o lixo. Faça isso de uma maneira que não incomode ou confunda usuários humanos. Quando os bots acionarem a fase dois, eles entrarão e preencherão o formulário para comprar US $ 100 por quarto em vez de BOC. Obviamente, isso pressupõe que os robôs não sejam particularmente robustos.

Outra idéia é implementar quedas aleatórias de preços ao longo do período de venda de bolsas ou porcarias. Quem compraria uma porcaria aleatória por US $ 150 quando você declara claramente que vale apenas US $ 20? Ninguém além de bots superzelosos. Mas, 9 minutos depois, custa $ 35 dólares ... então, 17 minutos depois, custa $ 9. Como queiras.

Claro, os reis zumbis seriam capazes de reagir. O objetivo é fazer com que seus erros se tornem muito caros para eles (e fazê-los pagar para combatê-los).

Tudo isso pressupõe que você queira irritar alguns chefes de bot, o que pode não ser 100% recomendável.

Então, o problema realmente parece ser: os robôs querem seu "saco de merda" porque tem um alto valor percebido a um preço baixo. Às vezes, você oferece esse item e os bots espreitam, esperando para ver se ele está disponível e eles compram o item.

Como parece que os proprietários de bot estão lucrando (ou potencialmente lucrando), o truque é tornar isso não lucrativo para eles, incentivando- os a comprar a porcaria.

Primeiro, sempre ofereça o "saco de merda".

Segundo, verifique se essa porcaria é geralmente uma porcaria.

Terceiro, gire a porcaria com frequência.

Simples, não?

Você precisará de um permanente "por que nossa porcaria às vezes é uma porcaria?" ao lado da oferta para explicar aos seres humanos o que está acontecendo.

Quando o bot vê que há porcaria e a porcaria é comprada automaticamente, o destinatário fica muito chateado por pagar 10 dólares por um palito de dente quebrado. E então um saco de lixo vazio. E então um pouco de sujeira na parte inferior do seu sapato.

Se eles comprarem o suficiente dessa porcaria em um período de tempo relativamente curto (e você tiver grandes isenções de responsabilidade em todo o lugar explicando por que está fazendo isso), eles perderão uma justa "sacola de dinheiro" no seu " bag 'o crap ". Mesmo a intervenção humana da parte deles (verificar para garantir que a porcaria não é porcaria) pode falhar se você girar a porcaria com frequência suficiente. Caramba, talvez os robôs notem e não comprem nada que esteja em rotação por um período muito curto, mas isso significa que os humanos comprarão a não-merda.

Caramba, seus clientes regulares podem se divertir tanto que você pode transformar isso em uma grande vitória de marketing. Comece a postar quanto da carpa "porcaria" está sendo vendida. As pessoas vão voltar apenas para ver o quão duro os bots foram mordidos.

Atualização: Espero que você receba algumas ligações com pessoas reclamando. Eu não acho que você pode parar com isso completamente. No entanto, se isso acabar com os bots, você sempre poderá pará-lo e reiniciá-lo mais tarde.

1. Venda o item para humanos que não são scripts.

2. Mantenha o site funcionando a uma velocidade que não diminui a velocidade dos bots.

3. Não incomode os usuários "normais" com nenhuma tarefa a concluir para provar que é humano.

Você provavelmente não quer ouvir isso, mas os números 1 e 3 são mutuamente exclusivos.

Bem, ninguém sabe que você também é um bot. Não há maneira programática de dizer se existe ou não um ser humano na outra extremidade da conexão sem exigir que a pessoa faça alguma coisa. Impedir que scripts / bots façam coisas na Web é o motivo pelo qual os CAPTCHAs foram inventados. Não é que esse seja um problema novo que não tenha visto muito esforço nele. Se houvesse uma maneira melhor de fazê-lo, que não envolvesse problemas para usuários reais que um CAPTCHA, todos já o usariam.

Eu acho que você precisa encarar o fato de que, se você quiser manter os bots longe da sua página de pedidos, um bom CAPTCHA é a única maneira de fazê-lo. Se a demanda por sua porcaria aleatória for alta o suficiente para que as pessoas estejam dispostas a fazer o possível para obtê-la, usuários legítimos não serão adiados por um CAPTCHA.

O método que o Woot usa para combater esse problema está mudando o jogo - literalmente. Quando apresentam um item extraordinariamente desejável para venda, eles fazem com que os usuários joguem um videogame para fazer o pedido.

Isso não apenas combate bots com sucesso (eles podem facilmente fazer pequenas alterações no jogo para evitar jogadores automáticos ou até mesmo fornecer um novo jogo para cada venda), mas também dá a impressão aos usuários de "ganhar" o item desejado enquanto diminuem a velocidade o processo de pedido.

Ele ainda se esgota muito rapidamente, mas acho que a solução é boa - reavaliar o problema e alterar os parâmetros levou a uma estratégia bem-sucedida em que simplesmente não existiam soluções estritamente técnicas.

Todo o seu modelo de negócios é baseado no "primeiro a chegar, primeiro a ser servido". Você não pode fazer o que as estações de rádio fizeram (elas não tornam mais o primeiro interlocutor o vencedor, fazem o 5º, o 20º ou o 13º ou o 13º interlocutor o vencedor) - ele não corresponde ao seu recurso principal.

Não, não há como fazer isso sem alterar a experiência de pedidos dos usuários reais.

Digamos que você implemente todas essas táticas. Se eu decidir que isso é importante, terei apenas 100 pessoas para trabalhar comigo, criaremos software para trabalhar em nossos 100 computadores separados e acessaremos seu site 20 vezes por segundo (5 segundos entre acessos para cada usuário / cookie / conta / endereço IP).

Você tem dois estágios:

1. Assistindo a primeira página
2. Encomenda

Você não pode colocar um captcha bloqueando o número 1 - isso vai perder clientes reais ("O quê? Eu tenho que resolver um captcha toda vez que quiser ver o último woot?!?").

Então, meu pequeno grupo observa, cronometrado juntos para que recebamos cerca de 20 verificações por segundo e quem vê a alteração primeiro alerta todos os outros (automaticamente), que carregam a primeira página novamente, seguem o link do pedido e realizam a transação ( o que também pode acontecer automaticamente, a menos que você implemente o captcha e o altere para cada wootoff / boc).

Você pode colocar um captcha na frente do número 2 e, embora não queira fazê-lo, essa pode ser a única maneira de garantir que, mesmo que os bots assistam à página inicial, usuários reais estejam recebendo os produtos.

Mas mesmo com o captcha, minha pequena faixa de 100 ainda teria uma vantagem significativa em relação ao primeiro motor - e não há como você dizer que não somos humanos. Se você começar a cronometrar nossos acessos, adicionaríamos alguma instabilidade. Poderíamos selecionar aleatoriamente qual computador seria atualizado, para que a ordem dos acessos mudasse constantemente - mas ainda assim pareça um ser humano.

Primeiro, livre-se dos bots simples

Você precisa de um firewall adaptável que observe as solicitações e se alguém estiver fazendo a coisa estúpida óbvia - atualizando mais de uma vez por segundo no mesmo IP, use táticas para desacelerá-las (descartar pacotes, enviar de volta recusados ​​ou 500 erros, etc. )

Isso deve reduzir significativamente seu tráfego e alterar as táticas que os usuários de bot empregam.

Segundo, torne o servidor incrivelmente rápido.

Você realmente não quer ouvir isso ... mas ...

Acho que você precisa de uma solução totalmente personalizada de baixo para cima.

Você não precisa mexer com a pilha TCP / IP, mas pode ser necessário desenvolver um servidor personalizado muito, muito, muito rápido, criado especificamente para correlacionar as conexões do usuário e reagir adequadamente a vários ataques.

O Apache, lighthttpd, etc, são ótimos por serem flexíveis, mas você administra um site de finalidade única e precisa realmente fazer mais do que os servidores atuais são capazes de fazer (tanto no gerenciamento de tráfego quanto no combate apropriado de bots )

Ao exibir uma página da Web em grande parte estática (atualizações a cada 30 segundos ou mais) em um servidor personalizado, você não deve apenas administrar 10x o número de solicitações e tráfego (porque o servidor não está fazendo nada além de receber a solicitação e ler a página da memória para o buffer TCP / IP), mas também fornece acesso a métricas que podem ajudar a diminuir a velocidade dos bots. Por exemplo, correlacionando endereços IP, você pode simplesmente bloquear mais de uma conexão por segundo por IP. Os humanos não podem ir mais rápido que isso, e mesmo as pessoas que usam o mesmo endereço IP NAT são bloqueadas com pouca frequência. Você deseja fazer um bloqueio lento - deixe a conexão em paz por um segundo inteiro antes de encerrar oficialmente a sessão. Isso pode alimentar um firewall para oferecer bloqueios de longo prazo a criminosos especialmente flagrantes.

Mas a realidade é que, não importa o que você faça, não há como diferenciar um humano de um bot quando o bot é personalizado por um humano para um único propósito. O bot é apenas um proxy para o humano.

Conclusão

No final do dia, você não pode distinguir um humano e um computador para assistir a primeira página. Você pode interromper os bots na etapa de pedido, mas os usuários do bot ainda têm uma vantagem no primeiro mecanismo, e você ainda tem uma carga enorme para gerenciar.

Você pode adicionar blocos para os bots simples, o que elevará a fasquia e menos pessoas se incomodarão com isso. Isso pode ser o suficiente.

Mas sem alterar seu modelo básico, você está sem sorte. O melhor que você pode fazer é cuidar de casos simples, tornar o servidor tão rápido que os usuários comuns não notam e vender tantos itens que, mesmo que você tenha alguns milhões de bots, o número de usuários regulares que eles quiserem os conseguirá. .

Você pode configurar um honeypot e marcar contas de usuários como usuários de bot, mas isso terá uma enorme reação negativa da comunidade.

Toda vez que penso em um "bem, que tal fazer isso ...", sempre posso combatê-lo com uma estratégia de bot adequada.

Mesmo se você tornar a primeira página um captcha para acessar a página de pedidos ("O botão de pedidos deste item é azul com brilhos rosa, em algum lugar desta página"), os bots simplesmente abrirão todos os links da página e usarão o que vier de volta com uma página de pedidos. Isso não é maneira de ganhar isso.

Torne os servidores rápidos, coloque um reCaptcha (o único que eu achei que não pode ser facilmente enganado, mas provavelmente é muito lento para o seu aplicativo) na página de pedidos e pense em maneiras de mudar um pouco o modelo para usuários regulares têm uma chance tão boa quanto os usuários de bot.

-Adão

Isenção de responsabilidade: Esta resposta é totalmente não relacionada à programação. No entanto, ele tenta atacar o motivo dos scripts.

Outra idéia é se você realmente tem uma quantidade limitada para vender, por que não a altera de uma metodologia de primeiro a chegar, primeiro a ser servido? A menos, é claro, que o hype faça parte do seu esquema de marketing.

Existem muitas outras opções, e tenho certeza que outras pessoas podem pensar em algumas diferentes:

• uma fila de pedidos (sistema de pré-encomenda) - Alguns scripts ainda podem acabar na frente da fila, mas provavelmente é mais rápido inserir as informações manualmente.

• um sistema de sorteio (todos que tentam solicitar um são inscritos no sistema) - Dessa forma, as pessoas com os scripts têm exatamente as mesmas chances que aquelas sem.

• uma fila de prioridade urgente - Se houver realmente um alto valor percebido, as pessoas podem estar dispostas a pagar mais. Implemente uma fila de pedidos, mas permita que as pessoas paguem mais para serem colocadas mais altas na fila.

• leilão (o crédito é para David Schmitt por este, os comentários são meus) - As pessoas ainda podem usar scripts para entrar no último minuto, mas não apenas isso altera a estrutura de preços, mas as pessoas esperam estar brigando com os outros . Você também pode restringir o número de lances em um determinado período, fazer com que as pessoas telefonem com antecedência para obter um código de autorização etc.

Por mais seguros que os nazistas pensassem que suas comunicações eram, os aliados costumavam quebrar suas mensagens. Não importa como você tente impedir que os bots usem seu site, os proprietários dos bots resolverão o problema. Me desculpe se isso faz de você o nazista :-)

Eu acho que é necessária uma mentalidade diferente

• Não tente impedir que os robôs usem seu site
• Não faça uma correção que funcione imediatamente, jogue o jogo longo

Entre na mentalidade de que não importa se o cliente do seu site é humano ou bot, ambos estão apenas pagando; mas um tem uma vantagem injusta sobre o outro. Alguns usuários sem muita vida social (eremitas) podem ser tão irritantes para os outros usuários do seu site quanto os bots.

Registre a hora em que você publica uma oferta e a hora em que uma conta opta por comprá-la.

Isso fornece um registro da rapidez com que o cliente está comprando coisas.

Varie a hora do dia em que você publica ofertas.

Por exemplo, tenha uma janela de 3 horas iniciando em uma hora obscura do dia (meia-noite?). Apenas bots e eremitas atualizam constantemente uma página por 3 horas apenas para fazer um pedido em segundos. Nunca varie o tempo base, apenas o tamanho da janela.

Com o tempo, uma imagem surgirá.

01: você pode ver quais contas estão comprando produtos regularmente alguns segundos depois de serem lançadas. Sugerindo que eles podem ser bots.

02: Você também pode olhar para a janela de tempo usada para as ofertas, se a janela for de 1 hora, alguns compradores iniciais serão humanos. Um humano raramente irá atualizar por 4 horas. Se o tempo decorrido for bastante consistente entre a publicação / compra, independentemente da duração da janela, isso é um bot. Se o tempo de publicação / compra é curto para janelas pequenas e fica mais longo para janelas grandes, isso é um eremita!

Agora, em vez de impedir que os robôs usem seu site, você tem informações suficientes para informar quais contas certamente são usadas por robôs e quais contas provavelmente serão usadas pelos eremitas. O que você faz com essas informações é com você, mas certamente você pode usá-las para tornar seu site mais justo para as pessoas que têm uma vida.

Eu acho que banir as contas de bot seria inútil, seria como telefonar para Hitler e dizer "Obrigado pelas posições dos seus submarinos!" De alguma forma, você precisa usar as informações de uma maneira que os proprietários da conta não percebam. Vamos ver se consigo sonhar com alguma coisa ...

Processar pedidos em uma fila:

Quando o cliente faz um pedido, ele recebe imediatamente um e-mail de confirmação informando que o pedido é feito em uma fila e será notificado quando for processado. Eu experimento esse tipo de coisa com pedido / despacho na Amazon e isso não me incomoda, não me importo de receber um e-mail dias depois dizendo que meu pedido foi despachado, desde que eu receba imediatamente um e-mail informando que A Amazon sabe que eu quero o livro. No seu caso, seria um email para

1. Seu pedido foi feito e está em uma fila.
2. Seu pedido foi processado.
3. Seu pedido foi enviado.

Os usuários pensam que estão em uma fila justa. Processe sua fila a cada 1 hora para que os usuários normais também passem por uma fila, para não despertar suspeitas. Somente processe pedidos de contas de bot e eremita quando estiverem na fila pelo "tempo médio de pedido humano + x horas". Reduzindo efetivamente os bots para humanos.

Eu digo expor as informações de preço usando uma API. Essa é a solução não intuitiva, mas funciona para fornecer controle sobre a situação. Adicione algumas limitações à API para torná-la um pouco menos funcional que o site.

Você pode fazer o mesmo para encomendar. Você pode experimentar pequenas alterações na funcionalidade / desempenho da API até obter o efeito desejado.

Existem proxies e botnets para anular as verificações de IP. Existem scripts de leitura de captcha extremamente bons. Existem até equipes de trabalhadores na Índia que derrotam os captchas por um pequeno preço. Qualquer solução que você possa encontrar pode ser razoavelmente derrotada. Até as soluções de Ned Batchelder podem ser superadas usando um controle WebBrowser ou outro navegador simulado combinado com uma lista de botnet ou proxy.

Atualmente, estamos usando a última geração de balanceadores de carga BigIP da F5 para fazer isso. O BigIP possui recursos avançados de gerenciamento de tráfego que podem identificar scrapers e bots com base na frequência e nos padrões de uso, mesmo dentre um conjunto de fontes atrás de um único IP. Em seguida, pode estrangulá-los, veiculá-los com conteúdo alternativo ou simplesmente marcá-los com cabeçalhos ou cookies para que você possa identificá-los no código do aplicativo.

Primeiro, deixe-me recapitular o que precisamos fazer aqui. Sei que estou apenas parafraseando a pergunta original, mas é importante esclarecermos tudo isso 100%, porque há muitas ótimas sugestões que acertam 2 ou 3 em 4, mas, como demonstrarei, você precisará de um abordagem multifacetada para cobrir todos os requisitos.

Requisito 1: Livrar-se do 'bot slamming':

O rápido ataque da sua primeira página está prejudicando o desempenho do seu site e está no centro do problema. O 'slamming' vem dos bots de IP único e - supostamente - das botnets também. Queremos nos livrar de ambos.

Requisito 2: não mexa com a experiência do usuário:

Poderíamos consertar a situação do bot de maneira bastante eficaz, implementando um procedimento desagradável de verificação, como telefonar para um operador humano, resolver um monte de CAPTCHAs ou similar, mas isso seria como forçar todo passageiro inocente de avião a saltar por aros de segurança malucos apenas por uma pequena chance de pegar o mais estúpido dos terroristas. Oh espere - nós realmente fazemos isso. Mas vamos ver se podemos não fazer isso em woot.com.

Requisito 3: Evitar a 'corrida armamentista':

Como você mencionou, você não quer ser pego na corrida de armas de spambot. Portanto, você não pode usar ajustes simples, como campos de formulário ocultos ou confusos, perguntas matemáticas etc., pois são essencialmente medidas de obscuridade que podem ser automaticamente detectadas e contornadas trivialmente.

Requisito 4: frustrar os bots de alarme:

Isso pode ser o mais difícil dos seus requisitos. Mesmo se pudermos fazer um desafio eficaz à verificação humana, os bots ainda poderão pesquisar sua primeira página e alertar o scripter quando houver uma nova oferta. Queremos tornar esses bots inviáveis ​​também. Esta é uma versão mais forte do primeiro requisito, já que os bots não podem apenas emitir solicitações de disparo rápido que prejudicam o desempenho - eles também não podem emitir solicitações repetidas o suficiente para enviar um 'alarme' ao scripter a tempo de vencer a oferta.

Ok, então vamos ver se podemos atender aos quatro requisitos. Primeiro, como mencionei, nenhuma medida vai dar conta do recado. Você terá que combinar alguns truques para alcançá-lo e terá que engolir dois aborrecimentos:

1. Será necessário um pequeno número de usuários para pular os bastidores
2. Um pequeno número de usuários não poderá receber as ofertas especiais

Sei que isso é irritante, mas se pudermos fazer com que o número "pequeno" seja pequeno o suficiente , espero que você concorde que os aspectos positivos superam os negativos.

Primeira medida: limitação baseada no usuário:

Este é um acéfalo, e tenho certeza que você já faz isso. Se um usuário estiver conectado e continuar atualizando 600 vezes por segundo (ou algo assim), você para de responder e pede para ele esfriar. Na verdade, você provavelmente restringe os pedidos dele muito antes, mas você entendeu. Dessa forma, um bot conectado será banido / regulado assim que começar a pesquisar seu site. Esta é a parte fácil. Os bots não autenticados são o nosso problema real, e assim por diante:

Segunda medida: alguma forma de otimização de IP, conforme sugerido por quase todos:

Não importa o que aconteça, você terá que fazer alguma otimização baseada em IP para impedir o 'bot slamming'. Uma vez que parece importante para você para permitir que não autenticado visitantes (não-logged-in) para obter as ofertas especiais, você só tem IPs para ir inicialmente, e embora eles não são perfeitos, eles fazem o trabalho contra bots single-IP. As redes de bots são um animal diferente, mas voltarei a elas. Por enquanto, faremos algumas regulações simples para vencer os bots de IP único de disparo rápido.

A ocorrência de desempenho é insignificante se você executar a verificação de IP antes de todo o outro processamento, usar um servidor proxy para a lógica de otimização e armazenar os IPs em uma estrutura de árvore otimizada para pesquisa com cache de memcached.

Terceira medida: camuflar o acelerador com respostas em cache:

Com os bots de IP único de disparo rápido acelerados, ainda precisamos lidar com bots de IP único lentos, ou seja. bots que são especificamente ajustados para "voar sob o radar" espaçando as solicitações um pouco mais afastadas do que a limitação impede.

Para inutilizar instantaneamente os bots de IP único lentos, basta usar a estratégia sugerida pela abelenky: servir páginas em cache com 10 minutos de idade a todos os IPs detectados nas últimas 24 horas (mais ou menos). Dessa forma, todo IP tem uma 'chance' por dia / hora / semana (dependendo do período escolhido) e não haverá aborrecimentos visíveis para usuários reais que estão apenas pressionando o botão 'recarregar', exceto que eles não vencem a oferta.

A vantagem dessa medida é que isso também impede os 'bots de alarme', desde que não sejam originários de uma botnet.

(Eu sei que você provavelmente preferiria se usuários reais pudessem atualizar repetidamente, mas não há como diferenciar um humano de atualização de spam de um bot de solicitação de spam sem um CAPTCHA ou similar)

Quarta medida: reCAPTCHA:

Você está certo de que os CAPTCHAs prejudicam a experiência do usuário e devem ser evitados. No entanto, em uma situação, eles podem ser seu melhor amigo: se você projetou um sistema muito restritivo para impedir bots, isso - por causa de sua restrição - também captura vários falsos positivos; então, um CAPTCHA que serve como último recurso permitirá que os usuários reais que são pegos escapem por sua limitação (evitando assim situações irritantes de DoS).

O ponto ideal, é claro, é quando TODOS os bots ficam presos na sua rede, enquanto pouquíssimos usuários reais ficam incomodados com o CAPTCHA.

Se você, ao exibir as páginas em cache de 10 minutos, também oferece uma 'atualização de página inicial' alternativa, opcional e verificada por CAPTCHA, os seres humanos que realmente desejam se atualizar, ainda podem fazê-lo sem obter a página em cache antiga , mas ao custo de ter que resolver um CAPTCHA para cada atualização. Isso é um aborrecimento, mas opcional apenas para os usuários obstinados, que tendem a perdoar mais porque sabem que estão usando o sistema para melhorar suas chances, e que as chances aumentadas não são gratuitas.

Quinta medida: porcaria de chamariz:

Christopher Mahan tinha uma idéia de que eu gostava, mas eu daria uma guinada diferente. Toda vez que você estiver preparando uma nova oferta, prepare duas outras 'ofertas', que nenhum humano escolheria, como uma porca de 12mm por US $ 20. Quando a oferta aparecer na primeira página, coloque todas as três 'ofertas' na mesma imagem, com os números correspondentes a cada oferta. Quando o usuário / bot realmente encomendar o item, ele terá que escolher (um botão de opção) o que deseja e, como a maioria dos bots estaria apenas adivinhando, em dois de três casos, os bots estariam comprando inúteis lixo.

Naturalmente, isso não trata dos 'bots de alarme' e há uma chance (pequena) de que alguém possa criar um bot capaz de escolher o item correto. No entanto, o risco de comprar lixo acidentalmente deve fazer com que os roteadores se desviem totalmente dos bots totalmente automatizados.

Sexta medida: Regulagem de botnet:

[excluído]

Ok ............ Agora passei a maior parte da minha noite pensando sobre isso, tentando abordagens diferentes .... atrasos globais ... tokens baseados em cookies .. servindo na fila ... 'estrangulação estrangeira' .... E isso simplesmente não funciona. Não faz. Percebi que a principal razão pela qual você ainda não havia aceitado nenhuma resposta era que ninguém havia proposto uma maneira de impedir um ataque de rede / zumbi / botnet distribuído / zumbi ... então eu realmente queria decifrá-lo. Acredito que decifrei o problema da botnet para autenticação em um thread diferente , por isso também tinha grandes esperanças. Mas minha abordagem não se traduz nisso. Você só tem IPs para executar, e uma botnet grande o suficiente não se revela em nenhuma análise baseada em endereços IP.

Então aí está : minha sexta medida não é nada. Nada. Fecho eclair. A menos que o botnet seja pequeno e / ou rápido o suficiente para ser pego no acelerador de IP habitual, não vejo nenhuma medida eficaz contra botnets que não envolva verificação humana explícita, como CAPTHAs. Sinto muito, mas acho que combinar as cinco medidas acima é sua melhor aposta. E você provavelmente poderia se sair bem apenas com o truque de 10 minutos de cache do abelenky sozinho.

Que tal introduzir um atraso que requer interação humana, como uma espécie de "jogo CAPTCHA". Por exemplo, pode ser um pequeno jogo em Flash, onde durante 30 segundos eles precisam estourar bolas quadriculadas e evitar estourar bolas sólidas (evitando problemas de daltonismo!). O jogo receberia uma semente numérica aleatória e o que o jogo transmite de volta para o servidor seriam as coordenadas e os carimbos de data e hora dos pontos clicados, juntamente com a semente usada.

No servidor, você simula a mecânica do jogo usando essa semente para ver se os cliques realmente estourariam as bolas. Se o fizeram, eles não apenas eram humanos, mas levaram 30 segundos para se validarem. Dê a eles um ID de sessão.

Você permite que a ID da sessão faça o que quiser, mas se fizer muitas solicitações, elas não poderão continuar sem jogar novamente.

Existem algumas outras / melhores soluções já postadas, mas, para completar, pensei em mencionar isso:

Se sua principal preocupação é a degradação do desempenho, e você está olhando para o verdadeiro martelo , então você está realmente lidando com um ataque de negação de serviço e provavelmente deve tentar lidar com isso de acordo. Uma abordagem comum é simplesmente descartar pacotes de um IP no firewall após várias conexões por segundo / minuto / etc. Por exemplo, o firewall padrão do Linux, iptables, possui uma função padrão correspondente à operação 'hashlimit', que pode ser usada para correlacionar solicitações de conexão por unidade de tempo a um endereço IP.

Embora essa pergunta provavelmente seja mais adequada para o próximo derivado de SO mencionado no último podcast de SO, ela ainda não foi lançada, então acho que não há problema em responder :)

EDIT:
Como indicado pela novatrust, ainda existem ISPs na verdade NÃO atribuindo IPs a seus clientes; portanto, efetivamente, um cliente de script de um ISP desativaria todos os clientes desse ISP.

Escreva um proxy reverso em um servidor apache na frente do seu aplicativo que implemente um Tarpit (artigo da Wikipedia) para punir bots. Simplesmente gerenciaria uma lista de endereços IP conectados nos últimos segundos. Você detecta uma explosão de solicitações de um único endereço IP e atrasa exponencialmente essas solicitações antes de responder.

É claro que vários humanos podem vir do mesmo endereço IP se estiverem em uma conexão de rede com NAT, mas é improvável que um humano se importe com o tempo de resposta de 2mS a 4mS (ou mesmo 400mS), enquanto um bot será prejudicado pelo atraso crescente muito rapidamente.

1. Forneça um feed RSS para que eles não consumam sua largura de banda.
2. Ao comprar, faça com que todos esperem um tempo aleatório de até 45 segundos ou algo assim, dependendo exatamente do que você está procurando. Exatamente quais são suas restrições de tempo?
3. Dê a todos 1 minuto para colocar seu nome no desenho e selecione aleatoriamente as pessoas. Eu acho que esse é o caminho mais justo.
4. Monitore as contas (inclua algumas vezes na sessão e armazene-as?) E adicione atrasos às contas que parecem estar abaixo do limite de velocidade humana. Isso fará com que os bots sejam programados para desacelerar e competir com os seres humanos.

Primeiro, por definição, é impossível oferecer suporte a transações sem estado, ou seja, verdadeiramente anônimas, além de poder separar os bots dos usuários legítimos.

Se pudermos aceitar uma premissa de que podemos impor algum custo a um visitante woot novinho em folha em seus primeiros acessos à página, acho que tenho uma solução possível. Por falta de um nome melhor, vou chamar livremente essa solução de "Uma visita ao DMV".

Digamos que exista uma concessionária de carros que ofereça um carro novo diferente a cada dia e que em alguns dias você possa comprar um carro esportivo exótico por US $ 5 cada (limite 3), mais uma taxa de destino de US $ 5.

O problema é que a concessionária exige que você a visite e mostre uma carteira de motorista válida antes de entrar pela porta para ver qual carro está à venda. Além disso, você deve ter uma carteira de motorista válida para fazer a compra.

Assim, o visitante pela primeira vez (vamos chamá-lo de Bob) a esse revendedor de carros é recusado a entrar e é encaminhado ao escritório da DMV (que está convenientemente localizado ao lado) para obter uma carteira de motorista.

Outros visitantes com uma carteira de motorista válida são permitidos, depois de mostrar sua carteira de motorista. Uma pessoa que se incomode vagando o dia inteiro, incomodando os vendedores, pegando folhetos e esvaziando o café e os biscoitos de cortesia será recusada.

Agora, de volta a Bob sem a licença - tudo o que ele precisa fazer é suportar a visita ao DMV uma vez. Depois disso, ele pode visitar a concessionária e comprar carros quando quiser, a menos que tenha deixado sua carteira acidentalmente em casa ou que sua licença seja destruída ou revogada.

A carteira de motorista neste mundo é quase impossível de falsificar.

A visita ao DMV envolve primeiro obter o formulário de inscrição na fila "Iniciar aqui". Bob precisa levar o aplicativo preenchido para a janela 1, onde o primeiro de muitos funcionários públicos grosseiros o solicita, processa e, se tudo estiver em ordem, carimbar o pedido da janela e enviá-lo para a próxima janela. E assim, Bob vai de janelas em janela, aguardando a execução de cada etapa de seu aplicativo, até que finalmente chega ao fim e recebe sua licença de motorista.

Não faz sentido tentar "curto-circuito" o DMV. Se os formulários não forem preenchidos corretamente em triplicata, ou se houver respostas erradas em qualquer janela, o aplicativo será dividido e o infeliz cliente será enviado de volta ao início.

Curiosamente, não importa quão cheio ou vazio o escritório esteja, leva aproximadamente a mesma quantidade de tempo para ser atendido em cada janela sucessiva. Mesmo quando você é a única pessoa na fila, parece que o pessoal gosta de fazer você esperar um minuto atrás da linha amarela antes de dizer "Próximo!"

As coisas não são tão terríveis no DMV, no entanto. Enquanto toda a espera e o processamento para obter a licença estão acontecendo, você pode assistir a um infomercial muito divertido e informativo para a concessionária enquanto estiver no lobby da DMV. De fato, o infomerical é executado apenas o tempo suficiente para cobrir a quantidade de tempo que você gasta recebendo sua licença.

A explicação um pouco mais técnica:

Como eu disse no começo, torna-se necessário ter um estado de estado no relacionamento cliente-servidor, o que permite separar humanos de bots. Você deseja fazer isso de uma maneira que não penalize excessivamente o visitante humano anônimo (não autenticado).

Essa abordagem provavelmente requer um processamento do lado do cliente AJAX-y. Um visitante novinho em folha recebe o "Bem-vindo, novo usuário!" página cheia de texto e gráficos que (pela otimização apropriada do servidor) levam alguns segundos para carregar completamente. Enquanto isso está acontecendo (e o visitante provavelmente está ocupado lendo as páginas de boas-vindas), seu token de identificação está sendo montado lentamente.

Digamos que, para discussão, o token (também conhecido como "carteira de motorista) consista em 20 blocos. Para obter cada bloco sucessivo, o código do lado do cliente deve enviar uma solicitação válida ao servidor. O servidor incorpora um atraso deliberado (digamos 200 milissegundos), antes de enviar o próximo pedaço juntamente com o 'carimbo' necessário para fazer a próxima solicitação do pedaço (ou seja, os carimbos precisavam ir de uma janela da DMV para a próxima) .Tudo dito, cerca de 4 segundos devem decorrer para terminar o chunk-desafio-resposta-chunk-desafio-resposta -...- chunk-desafio-resposta-conclusão processo.

No final desse processo, o visitante possui um token que permite acessar a página de descrição do produto e, por sua vez, a página de compras. O token é um ID exclusivo para cada visitante e pode ser usado para limitar suas atividades.

No lado do servidor, você aceita apenas visualizações de página de clientes que possuem um token válido. Ou, se for importante que todos possam finalmente ver a página, aplique uma penalidade de tempo às solicitações que estejam faltando um token válido.

Agora, para que isso seja relativamente benigno para o visitante humano legítimo, faça com que o processo de emissão de token ocorra de forma relativamente não invasiva em segundo plano. Daí a necessidade da página de boas-vindas com cópia e gráficos divertidos, que são deliberadamente mais lentos.

Essa abordagem força uma aceleração dos bots a usar um token existente ou a dedicar o tempo mínimo de configuração para obter um novo token. Obviamente, isso não ajuda muito contra ataques sofisticados usando uma rede distribuída de visitantes falsos.

Você não pode impedir totalmente os bots, mesmo com um captcha. No entanto, é difícil escrever e manter um bot e, portanto, reduzir o número. Forçando-os a atualizar seus bots diariamente, principalmente, você fará com que a maioria perca o interesse.

Aqui estão algumas idéias para tornar mais difícil escrever bots:

• Exija a execução de uma função javascript. Javascript torna muito mais difícil escrever um bot. Talvez exija um captcha se eles não estiverem executando o javascript para permitir ainda usuários não-javascript reais (mínimo).

• Cronometre as teclas pressionadas ao digitar no formulário (novamente via javascript). Se não for humano, rejeite-o. É uma dor imitar a digitação humana em um bot.

• Escreva seu código para atualizar diariamente os IDs de seu campo com um novo valor aleatório. Isso os forçará a atualizar seu bot diariamente, o que é uma dor.

• Escreva seu código para reordenar seus campos diariamente (obviamente, de alguma forma, isso não é aleatório para seus usuários). Se eles estão confiando na ordem de campo, isso fará com que eles desapareçam e forçam novamente a manutenção diária ao código bot.

• Você pode ir ainda mais longe e usar o conteúdo em Flash. Flash é totalmente uma dor de se escrever contra um bot.

Geralmente, se você começar a pensar em não impedi-los, mas torná-lo mais funcional para eles, provavelmente poderá atingir o objetivo que está procurando.

Mantenha um atraso de 5 minutos em todos os anúncios de produtos para usuários não registrados. Usuários casuais não perceberão isso e usuários não casuais serão registrados de qualquer maneira.

Não estou vendo o grande fardo que você reivindica ao verificar IPs recebidos. Pelo contrário, eu fiz um projeto para um dos meus clientes que analisa os logs de acesso HTTP a cada cinco minutos (poderia ter sido em tempo real, mas ele não queria isso por algum motivo que eu nunca entendi completamente) e cria regras de firewall para bloquear conexões de qualquer endereço IP que gere um número excessivo de solicitações, a menos que o endereço possa ser confirmado como pertencente a um mecanismo de pesquisa legítimo (google, yahoo etc.).

Esse cliente executa um serviço de hospedagem na web e está executando esse aplicativo em três servidores que lidam com um total de 800 a 900 domínios. O pico de atividade está na faixa de mil acessos por segundo e nunca houve um problema de desempenho - os firewalls são muito eficientes na remoção de pacotes dos endereços da lista negra.

E sim, definitivamente existe a tecnologia DDOS que derrotaria esse esquema, mas ele não está vendo isso acontecer no mundo real. Pelo contrário, ele diz que reduziu bastante a carga em seus servidores.

Minha abordagem seria focar em soluções não tecnológicas (caso contrário, você entrará em uma corrida armamentista, perderá ou, pelo menos, gastará muito tempo e dinheiro). Eu me concentraria nas peças de cobrança / remessa - você pode encontrar bots encontrando várias entregas no mesmo endereço ou várias cobranças em um único método de pagamento. Você pode até fazer isso nos itens ao longo de várias semanas; portanto, se um usuário obtiver um item anterior (respondendo muito rápido), ele poderá receber algum tipo de "desvantagem" dessa vez.

Isso também teria um efeito colateral (benéfico, eu acho, mas poderia ser errado em termos de marketing para o seu caso) de talvez ampliar o círculo de pessoas que têm sorte e conseguem comprar o woot.

A maioria das soluções puramente técnicas já foram oferecidas. Portanto, vou sugerir outra visão do problema.

Pelo que entendi, os bots são criados por pessoas realmente tentando comprar as sacolas que você está vendendo. O problema é -

1. Outras pessoas, que não operam bots, merecem a chance de comprar, e você está oferecendo uma quantidade limitada de sacolas.
2. Você quer atrair humanos para o seu site e apenas vender as sacolas.

Em vez de tentar evitar os bots, você pode permitir que os possíveis compradores de bolsas se inscrevam em um e-mail ou até mesmo na atualização por SMS para serem notificados quando uma venda ocorrer. Você pode até dar um minuto ou dois de vantagem (um URL especial onde a venda começa, gerada aleatoriamente e enviada com o correio / SMS).

Quando esses compradores comprarem o site, você poderá mostrar o que quiser em banners laterais ou o que for. Aqueles que executam os bots preferem simplesmente se registrar no seu serviço de notificação.

Os corredores de bots ainda podem executar bots na sua notificação para concluir a compra mais rapidamente. Algumas soluções para isso podem oferecer uma compra com um clique.

A propósito, você mencionou que seus usuários não estão registrados, mas parece que aqueles que compram essas malas não são compradores aleatórios, mas pessoas que esperam ansiosamente por essas vendas. Como tal, eles podem estar dispostos a se registrar para obter uma vantagem ao tentar "ganhar" uma bolsa.

Em essência, o que estou sugerindo é tentar encarar o problema como social, e não técnico.

Asaf

Agentes de usuário com bloqueio de tempo que fazem tantas solicitações por minuto. Por exemplo, se você tem alguém solicitando uma página exatamente a cada 5 segundos por 10 minutos, provavelmente não é um usuário ... Mas pode ser complicado fazer isso direito.

Se eles acionarem um alerta, redirecione todas as solicitações para uma página estática com o mínimo de DB-IO possível, com uma mensagem informando que serão permitidos novamente em X minutos.

É importante acrescentar que você provavelmente só deve aplicar isso em solicitações de páginas e ignorar todas as solicitações de mídia (js, imagens, etc.).

Impedir o DoS derrotaria o nº 2 dos objetivos do @ davebug que ele destacou acima: "Mantenha o site a uma velocidade que não diminui a velocidade dos bots", mas não seria necessário a solução nº 1, "Venda o item para humanos que não são scripts"

Tenho certeza de que um roteirista poderia escrever algo para andar de skate abaixo do limite excessivo que ainda seria mais rápido do que um humano poderia passar pelos formulários de pedidos.

Tudo bem, então os spammers estão competindo com pessoas comuns para ganhar o leilão "bog of crap"? Por que não fazer do próximo leilão um "saco de lixo" literal? Os remetentes de spam pagam um bom dinheiro por uma sacola cheia de cachorros, e todos rimos deles.

O importante aqui é mudar o sistema para remover a carga do seu servidor, impedir que os bots ganhem o saco de lixo SEM avisar os botlords que você está jogando com eles ou eles revisarão sua estratégia. Eu não acho que exista alguma maneira de fazer isso sem algum processamento no seu final.

Então você grava hits na sua página inicial. Sempre que alguém acessa a página, essa conexão é comparada ao seu último acesso e, se foi rápida demais, é enviada uma versão da página sem a oferta. Isso pode ser feito por algum tipo de mecanismo de balanceamento de carga que envia bots (as ocorrências que são muito rápidas) para um servidor que simplesmente serve versões em cache da sua página inicial; pessoas reais são enviadas para o bom servidor. Isso tira a carga do servidor principal e faz com que os bots pensem que ainda estão recebendo as páginas corretamente.

Ainda melhor se a oferta puder ser recusada de alguma forma. Então você ainda pode fazer as ofertas no servidor falso, mas quando o bot preencher o formulário, diga "Desculpe, você não foi rápido o suficiente" :) Então eles definitivamente acharão que ainda estão no jogo.

Como você sabe que existem scripts fazendo pedidos?

O ponto crucial do seu problema é que você não pode separar os scripts dos usuários legítimos e, portanto, não pode bloqueá-los. Como é que você sabe que existem scripts?

Se você tem uma maneira de responder a essa pergunta, possui um conjunto de características que pode usar para filtrar os scripts.

Vamos virar o problema de cabeça para baixo: você tem bots comprando coisas que você quer que pessoas reais comprem, que tal ter uma chance real de que os bots comprem coisas que você não quer que as pessoas reais comprem.

Tenha uma chance aleatória para alguns html não exibidos que os robôs de rascunho acharão a situação real, mas as pessoas reais não verão (e não esqueça que as pessoas reais incluem os cegos, então considere os leitores de tela etc.) e isso viaja para comprar algo exorbitante (ou não faz a compra real, mas obtém detalhes de pagamento para você colocar em uma lista de proibição).

Mesmo se os bots mudarem para 'alertar o usuário' em vez de 'efetuar a compra', se você receber alarmes falsos suficientes, poderá torná-lo suficientemente inútil para as pessoas (talvez nem todos, mas alguma redução na fraude é melhor do que nada) para não incomodar.