Как насчет реализации чего-то вроде SO делает с CAPTCHA?

Если вы обычно используете сайт, вы, вероятно, никогда его не увидите. Если вы слишком часто загружаете одну и ту же страницу, слишком быстро отправляете последовательные комментарии или что-то еще, что вызывает тревогу, заставляют их доказать, что они люди. В вашем случае это, вероятно, будет постоянной перезагрузкой одной и той же страницы, быстро после каждой ссылки на странице или заполнением формы заказа слишком быстро, чтобы быть человеком.

Если они не выполняют проверку x раз подряд (скажем, 2 или 3), дайте этому IP тайм-аут или другую такую ​​меру. Затем в конце таймаута снова выгрузите их обратно в чек.

Поскольку у вас незарегистрированные пользователи, обращающиеся к сайту, у вас есть только IP-адреса. Если вы захотите, вы можете выпускать сеансы в каждом браузере и отслеживать их. И, разумеется, выкинуть человеческий чек, если слишком много сеансов (последовательно) создаются подряд (если бот продолжает удалять файл cookie).

Что касается ловли слишком большого количества невинных людей, вы можете наложить отказ на странице проверки человека: «Эта страница также может появиться, если слишком много анонимных пользователей просматривают наш сайт с того же места. Мы рекомендуем вам зарегистрироваться или войти, чтобы избежать это.” (Правильно отрегулируйте формулировку).

Кроме того, каковы шансы, что пользователи X одновременно загружают одни и те же страницы с одного IP-адреса? Если они высоки, возможно, вам нужен другой механизм запуска для вашего бот-сигнала.

Изменить: Еще один вариант – если они терпят неудачу слишком много раз, и вы уверены в спросе на продукт, чтобы заблокировать их и сделать их лично CALL, чтобы удалить блок.

Когда люди называют это, это похоже на меру асин, но это гарантирует, что за компьютером стоит человек . Ключ состоит в том, чтобы блок был только на месте для условия, которое должно почти никогда не происходить, если только он не является ботом (например, не выполняйте проверку несколько раз подряд). Затем он ПРИНИМАЕТ человеческое взаимодействие – забрать телефон.

В ответ на комментарий, когда они меня зовут, очевидно, что это компромисс. Вы достаточно обеспокоены тем, что ваши пользователи могут принять пару телефонных звонков, когда они поступят в продажу? Если бы я был так обеспокоен получением продукта для пользователей, я должен был бы принять это решение, возможно, пожертвовав небольшим количеством моего времени в этом процессе.

Поскольку кажется, что вы полны решимости не позволять ботам получить верх / сломать свой сайт, я считаю, что телефон может быть хорошим вариантом. Поскольку я не получаю прибыль от вашего продукта, я не заинтересован в получении этих звонков. Однако, если бы вы могли поделиться некоторой выгодой, я мог бы заинтересоваться. Поскольку это ваш продукт, вам нужно решить, насколько вы заботитесь и соответствующим образом реализуете.

Другие способы освобождения блока просто не так эффективны: тайм-аут (но они снова могут ударить ваш сайт после повторного прошивки), длительный тайм-аут (если это был действительно человек, пытающийся купить ваш продукт, они будут SOL и наказаны за провал проверки), электронная почта (легко делается ботами), факс (тот же) или уличная почта (занимает слишком много времени).

Разумеется, вы могли бы увеличить время ожидания для каждого IP-адреса для каждого таймаута. Просто убедитесь, что вы не наказываете истинных людей непреднамеренно.

Вам нужно понять, как заставить ботов покупать вещи, которые сильно завышены: 12-миллиметровое крыло: 20 долларов. Посмотрите, сколько ботов хватает, прежде чем сценаристы решают, что вы их играете.

Используйте прибыль, чтобы покупать больше серверов и платить за пропускную способность.

Мое решение состояло в том, чтобы сделать скриншоты экрана бесполезными, добавив примерно 10-минутную задержку для «ботов и скриптов».

Вот как я это сделаю:

• Запишите и определите любые повторные нападающие.

Вам не нужно регистрировать каждый IP-адрес при каждом попадании. Отслеживайте только один из каждых 20 ударов или около того. Повторный преступник все равно будет отображаться в рандомизированном случайном отслеживании.

• Храните кеш на своей странице примерно за 10 минут раньше.

• Когда на вашем сайте появляется повторный нападающий / бот, дайте им 10-минутную старую страницу в кеше.

Они не сразу узнают, что получают старый сайт. Они смогут очистить его и все, но больше не выиграют никакие гонки, потому что у «настоящих людей» будет 10-минутный старт.

Выгоды:

• Никаких хлопот или проблем для пользователей (например, CAPTCHA).
• Полностью реализован на стороне сервера. (не полагаться на Javascript / Flash)
• Обслуживание старой, кэшированной страницы должно быть менее интенсивным, чем текущая страница. Вы можете уменьшить нагрузку на свои серверы таким образом!

Недостатки

• Требуется отслеживание некоторых IP-адресов
• Требуется хранить и поддерживать кеш старых страниц.

Как вы думаете?

Взгляните на эту статью здесь . Его статья о прекращении спам-ботов, но те же самые методы могут легко примениться к вашему сайту.

Вместо того, чтобы останавливать ботов, когда люди идентифицируют себя, мы можем остановить ботов, затрудняя им успешную работу или непреднамеренно идентифицировать себя как ботов. Это снимает нагрузку с людей и оставляет форму комментария без видимых мер защиты от спама.

Этот метод – это то, как я предотвращаю спам-боты на этом сайте. Оно работает. Описанный здесь метод вообще не рассматривает содержимое.

Некоторые другие идеи:

• Создайте официальный механизм автоматического уведомления (RSS-канал? Twitter?), Который люди могут подписаться, когда ваш продукт поступит в продажу. Это уменьшает необходимость создания сценариев для людей.
• Измените свою технологию обфускации перед тем, как новый предмет поступит в продажу. Поэтому, даже если сценаристы могут эскалатировать гонку вооружений, они всегда на целый день отстают.

EDIT: Чтобы полностью понять, статья Ned выше описывает методы предотвращения автоматической покупки товаров, препятствуя BOT проходить через формы для отправки заказа. Его методы не будут полезны для предотвращения ботов с экрана, соскабливающих домашнюю страницу, чтобы определить, когда появляется Bandoleer of Carrots для продажи. Я не уверен, что это действительно возможно.

Что касается ваших комментариев об эффективности страtagsй Ned: Да, он обсуждает приманки, но я не думаю, что это его самая сильная страtagsя. Его обсуждение СПИННЕРА является изначальной причиной того, что я упомянул его статью. Извините, я не сделал это яснее в своем оригинальном посте:

Spinner – это скрытое поле, используемое для нескольких вещей: оно объединяет ряд значений, которые предотвращают подделку и повторы, и используются для затенения имен полей. Счетчик – это MD5-hash:

• Временная метка,
• IP-адрес клиента,
• Идентификатор записи в блоге, о котором комментируют, и
• Секрет.

Вот как вы могли бы реализовать это на WOOT.com:

Измените «секретное» значение, которое используется как часть hashа каждый раз, когда новый товар поступит в продажу. Это означает, что если кто-то собирается спроектировать BOT для автоматической покупки предметов, он будет работать только до тех пор, пока следующий товар не поступит в продажу !

Даже если кто-то сможет быстро перестроить своего бота, все другие фактические пользователи уже приобрели BOC, и ваша проблема будет решена!

Другая страtagsя, которую он обсуждает, заключается в том, чтобы время от времени менять технику honeypot (опять же, измените ее, когда новый предмет поступит в продажу):

• Используйте classы CSS (рандомизированные, конечно), чтобы установить поля или содержащий элемент для отображения: none.
• Пометьте поля одинаковыми (или очень похожими) на фоне страницы.
• Используйте позиционирование, чтобы вывести поле из видимой области страницы.
• Сделайте элемент слишком маленьким, чтобы отобразить содержащее поле honeypot.
• Оставьте поля видимыми, но используйте позиционирование, чтобы покрыть их темным элементом.
• Используйте Javascript для выполнения любых этих изменений, требуя, чтобы бот имел полный механизм Javascript.
• Оставьте приманки отображаться как другие поля, но говорите людям, чтобы они ничего не вводили в них.

Я предполагаю, что моя общая идея – ИЗМЕНИТЬ ФОРМА ДИЗАЙН, когда каждый новый предмет поступит в продажу. Или в LEAST, измените его, когда новый BOC поступит в продажу.

Это что, пару раз / месяц?

Если вы примете этот ответ, вы дадите мне хедз-ап, когда наступит следующий? 🙂

Вопрос: Как бы вы перестали писать сценарии со своего сайта сотни раз в секунду?
A: Вы этого не делаете. Невозможно предотвратить это поведение внешними агентами.

Вы можете использовать широкий спектр технологий для анализа входящих запросов и эвристической попытки определить, кто есть и не является человеком … но это провалится. В конце концов, если не сразу.

Единственное жизнеспособное долгосрочное решение – это изменить игру, чтобы сайт не был дружелюбным к боту или менее привлекателен для сценаристов.

Как ты это делаешь? Ну, это другой вопрос! 😉

…

ОК, некоторые параметры были даны (и отклонены) выше. Я не знаком с вашим сайтом, посмотрев на него только один раз, но поскольку люди могут читать текст на изображениях, и боты не могут легко сделать это, измените объявление как изображение. Не CAPTCHA , просто изображение –

• генерировать изображение (кэшируется, конечно), когда запрашивается страница
• сохраните имя источника изображения одинаково, чтобы не отвлекать игру
• большую часть времени изображение будет иметь обычный текст в нем и быть выровненным как часть встроенной HTML-страницы
• когда игра «включена», изображение меняется на текст объявления
• в тексте объявления отображается URL-адрес и / или код, который необходимо ввести вручную, чтобы получить приз. CAPTCHA код, если хотите, но это, вероятно, не нужно.
• для дополнительной безопасности код может быть одноразовым токеном, созданным специально для агента request / IP / agent, так что повторяющиеся запросы генерируют разные коды. Или вы можете предварительно создать кучу случайных кодов (одноразовый блокнот), если генерация по требованию слишком подвержена налогообложению.

Запускайте время-испытания реальных людей, отвечающих на это, и игнорируйте («oops, error, sorry, please again again») ответы быстрее, чем (скажем) половину этого времени. Это событие также должно инициировать оповещение разработчиков о том, что хотя бы один бот вычислил код / ​​игру, поэтому пришло время изменить код / ​​игру.

Продолжайте периодически менять игру, даже если никакие боты не запускают ее, просто чтобы тратить время сценаристов. В конце концов, сценаристы должны устать от игры и отправиться в другое место … мы надеемся 😉

Одно из последних предложений: когда приходит запрос на вашу основную страницу, помещайте ее в очередь и отвечаете на запросы в порядке отдельного процесса (вам может потребоваться взломать / расширить веб-сервер, чтобы это сделать, но, скорее всего, это будет стоит). Если другой запрос от того же IP / агента приходит, когда первый запрос находится в очереди, проигнорируйте его. Это должно автоматически сбросить нагрузку с ботов.

EDIT: другой вариант, помимо использования изображений, заключается в использовании javascript для заполнения текста buy / no-buy; боты редко интерпретируют javascript, поэтому они их не видели

Я не знаю, насколько это возможно: … переходите в наступление.

Выясните, какие данные сканируют боты. Подайте им данные, которые они ищут, когда вы НЕ продаете дерьмо. Сделайте это таким образом, чтобы не беспокоить или путать пользователей. Когда боты запускают вторую фазу, они войдут в систему и заполнят форму, чтобы купить за $ 100 комнат вместо BOC. Конечно, это предполагает, что боты не особенно надежны.

Другая идея – реализовать случайные падения цен в течение периода продажи сумки. Кто купит случайную сумку за 150 долларов, если вы ОЧЕНЬ СОСТОЯТЬ, что это всего лишь 20 долларов? Никто, кроме переутомленных ботов. Но затем через 9 минут это составляет 35 долларов США … затем через 17 минут это 9 долларов. Или что угодно.

Конечно, зомби-короли смогут реагировать. Дело в том, чтобы сделать их ошибки очень дорогими для них (и заставить их заплатить вам, чтобы сражаться с ними).

Все это предполагает, что вы хотите сокрушить некоторых бот-лордов, что не может быть на 100% целесообразным.

Таким образом, проблема действительно выглядит: боты хотят их «сумку», потому что она имеет высокую воспринимаемую ценность по низкой воспринимаемой цене. Иногда вы предлагаете этот предмет, и боты скрываются, ожидая, есть ли он, и затем они покупают предмет.

Поскольку кажется, что владельцы ботов получают прибыль (или потенциально получают прибыль), трюк заключается в том, чтобы сделать это невыгодным для них, поощряя их покупать дерьмо.

Во-первых, всегда предлагайте «сумку».

Во-вторых, убедитесь, что дерьмо обычно дерьмо.

В-третьих, часто вращайте дерьмо.

Просто, нет?

Вам понадобится постоянный «почему наше дерьмо иногда дерьмо?» ссылку рядом с предложением объяснить людям, что происходит.

Когда бот видит, что есть дерьмо, и дерьмо автоматически покупается, получатель будет ужасно расстроен тем, что заплатил 10 долларов за сломанную зубочистку. А потом пустой мусорный мешок. А потом грязь со дна вашей обуви.

Если они покупают достаточно этого дерьма за относительно короткий промежуток времени (и у вас есть большие оговорки повсюду, объясняющие, почему вы это делаете), они потеряют справедливую «сумку» наличных денег »на вашем” мешок «о дерьмо». Даже вмешательство человека с их стороны (проверка того, что дерьмо не является дерьмом) может потерпеть неудачу, если вы достаточно часто вращаете дерьмо. Черт возьми, возможно, боты заметят и не купят ничего, что было в ротации слишком короткое время, но это означает, что люди купят не-дерьмо.

Черт, ваши постоянные клиенты могут быть настолько удивлены, что вы можете превратить это в огромную маркетинговую победу. Начните публиковать, сколько продается «дерьмовый» карп. Люди вернутся, чтобы посмотреть, как сильно укушены боты.

Обновление: я ожидаю, что вы можете получить несколько звонков с людьми, жалующимися. Я не думаю, что вы можете полностью прекратить это. Однако, если это убивает ботов, вы всегда можете остановить его и перезапустить его позже.

1. Продайте товар людям, не использующим скрипты.

2. Держите сайт на скорости, не замедляемой ботами.

3. Не раздражайте «нормальных» пользователей любыми заданиями, чтобы доказать, что они люди.

Вы, вероятно, не хотите это слышать, но №1 и №3 являются взаимоисключающими.

Ну, никто не знает, что ты тоже бот. Нет никакого программного способа рассказать, есть ли человек на другом конце соединения, не требуя, чтобы человек что-то делал. Предотrotation скриптов / ботов от работы в Интернете – это целая причина, по которой CAPTCHA были изобретены. Не похоже, что это какая-то новая проблема, на которую не было потрачено много усилий. Если бы был лучший способ сделать это, тот, который не касался настоящих пользователей, которых делает CAPTCHA, все будут использовать его уже.

Я думаю, вам нужно столкнуться с тем, что, если вы хотите сохранить ботов с вашей страницы заказа, хороший CAPTCHA – это единственный способ сделать это. Если спрос на ваше случайное дерьмо достаточно высок, чтобы люди захотели пойти на эти длины, чтобы получить его, законные пользователи не будут отложены CAPTCHA.

Метод Woot, используемый для борьбы с этой проблемой, меняет игру – буквально. Когда они представляют необычайно желаемый предмет для продажи, они заставляют пользователей играть в видеоигру, чтобы заказать ее.

Это не только успешно сражается с ботами (они могут легко внести незначительные изменения в игру, чтобы избежать автоматических игроков, или даже обеспечить новую игру для каждой продажи), но также создает впечатление, что пользователи «выигрывают» желаемый элемент при замедлении процесс заказа.

Он по-прежнему продается очень быстро, но я считаю, что решение хорошее – переоценка проблемы и изменение параметров привели к успешной страtagsи, где строго технических решений просто не существовало.

Вся ваша бизнес-модель основана на «first come, first serve». Вы не можете делать то, что сделали радиостанции (они больше не делают первого победителя победителем, они делают победителя 5 или 20 или 13) – это не соответствует вашей основной функции.

Нет, нет никакого способа сделать это без изменения порядка заказа для реальных пользователей.

Предположим, вы реализуете все эти тактики. Если я решаю, что это важно, я просто попрошу 100 человек работать со мной, мы создадим программное обеспечение для работы на наших 100 отдельных компьютерах и на вашем сайте 20 раз в секунду (5 секунд между обращениями для каждого пользователя / cookie / аккаунт / IP-адрес).

У вас есть два этапа:

1. Просмотр главной страницы
2. заказ

Вы не можете помещать блокировку # 1 в капчу, это потеряет реальных клиентов («Что? Я должен решить капчу каждый раз, когда хочу увидеть последний woot?!?»).

Поэтому моя маленькая группа наблюдает за временем, поэтому мы получаем около 20 проверок в секунду, и каждый, кто видит это изменение, сначала предупреждает всех остальных (автоматически), кто снова загрузит главную страницу, выполнит ссылку заказа и выполнит транзакцию ( который также может произойти автоматически, если вы не реализуете капчу и не меняете его для каждого wootoff / boc).

Вы можете поставить captcha перед # 2, и, пока вы не можете этого сделать, это может быть единственным способом убедиться, что даже если боты наблюдают за главной страницей, реальные пользователи получают продукты.

Но даже с captcha моя маленькая группа из 100 будет по-прежнему иметь значительное преимущество перед первым движком – и вы не можете сказать, что мы не люди. Если вы начнете синхронизировать наши обращения, мы просто добавим некоторый джиттер. Мы могли бы случайно выбрать, какой компьютер должен обновляться, поэтому порядок доступа к изменениям постоянно – но все же выглядит достаточно похожим на человека.

Во-первых, избавиться от простых ботов

У вас должен быть адаптивный брандмауэр, который будет отслеживать запросы, и если кто-то делает очевидную глупую вещь – обновляясь не один раз в секунду на одном и том же IP-адресе, используйте тактику, чтобы замедлить их (отбрасывать пакеты, отправлять назад отказано или 500 ошибок и т. Д. ).

Это должно значительно снизить ваш трафик и изменить тактику, которую используют пользователи ботов.

Во-вторых, сделать сервер невероятно быстрым.

Вы действительно не хотите это слышать … но …

Я думаю, что вам нужно полностью настраиваемое решение снизу вверх.

Вам не нужно связываться с стеком TCP / IP, но вам может понадобиться разработать очень, очень и очень быстрый пользовательский сервер, который предназначен для корреляции пользовательских подключений и адекватного реагирования на различные атаки.

Apache, lighthttpd и т. Д. – все это отлично подходит для гибкости, но вы запускаете сайт с одной целью, и вам действительно нужно иметь возможность делать больше, чем могут выполнять текущие серверы (как для обработки трафика, так и для надлежащей борьбы с ботами ).

Предоставляя в основном статическую веб-страницу (обновления каждые 30 секунд или около того) на настраиваемом сервере, вы должны не только обрабатывать 10-кратное количество запросов и трафика (потому что сервер ничего не делает, кроме получения запроса, и считывает страница из памяти в буфер TCP / IP), но она также даст вам доступ к метрикам, которые могут помочь вам замедлить работу ботов. Например, путем сопоставления IP-адресов вы можете просто блокировать более одного соединения в секунду на каждый IP-адрес. Люди не могут двигаться быстрее, и даже люди, использующие один и тот же IP-адрес NAT, будут редко блокироваться. Вы хотите сделать медленный блок – оставьте связь в покое в течение полной секунды, прежде чем официально завершить сеанс. Это может быть включено в брандмауэр, чтобы предоставить более длительные блоки для особенно вопиющих правонарушителей.

Но реальность заключается в том, что независимо от того, что вы делаете, нет способа рассказать человеку отдельно от бота, когда бот настраивается человеком по одной цели. Бот – просто прокси для человека.

Вывод

В конце дня вы не можете рассказать человеку и компьютеру обособленно, глядя на первую страницу. Вы можете остановить ботов на шаге заказа, но у ботов-пользователей все еще есть преимущество первого движка, и у вас все еще есть огромная нагрузка для управления.

Вы можете добавлять блоки для простых ботов, что поднимет планку и меньше людей с ней. Этого может быть достаточно.

Но без изменения вашей базовой модели вам не повезло. Лучшее, что вы можете сделать, это позаботиться о простых случаях, сделать сервер настолько быстрым, что обычные пользователи не заметят, и продавать так много предметов, даже если у вас есть несколько миллионов ботов, так как многие обычные пользователи, как они хотят, получат их ,

Вы можете подумать о создании honeypot и маркировке учетных записей пользователей в качестве пользователей ботов, но это будет иметь негативный негативный резонанс сообщества.

Каждый раз, когда я думаю о «хорошо, как насчет этого …», я всегда могу противостоять ему с подходящей страtagsей ботов.

Даже если вы сделаете передовую страницу, чтобы перейти на страницу заказа («кнопка заказа этого элемента синяя с розовыми блестками, где-то на этой странице»), боты просто откроют все ссылки на странице и будут использовать то, что приходит назад с помощью страницы заказа. Это просто невозможно выиграть.

Сделайте серверы быстрыми, добавьте reCaptcha (только тот, который я нашел, который не может быть легко обманут, но это, вероятно, слишком медленно для вашего приложения) на странице заказа, и подумайте о том, как немного изменить модель у обычных пользователей такая же вероятность, как у ботов.

-Адам

Отказ от ответственности: этот ответ полностью не связан с программированием. Тем не менее, он пытается атаковать причину сценариев в первую очередь.

Другая идея заключается в том, что если у вас действительно есть ограниченное количество, чтобы продать, почему бы вам не изменить его из методологии с первым пришел первым? Если, конечно, реклама не является частью вашей маркетинговой схемы.

Есть много других вариантов, и я уверен, что другие могут подумать о некоторых других:

• очередь заказов (система предварительного заказа). Некоторые скрипты могут по-прежнему заканчиваться в передней части очереди, но, вероятно, быстрее просто ввести информацию вручную.

• система лотереи (каждый, кто пытается ее заказать, вводится в систему). Таким образом, люди со сценариями имеют такие же шансы, что и те, у кого нет.

• очередь приоритета пик – если есть действительно высокая воспринимаемая ценность, люди могут быть готовы заплатить больше. Реализуйте очередь заказов, но позвольте людям платить больше, чтобы быть размещенными выше в очереди.

• аукцион (кредит принадлежит Дэвиду Шмитту для этого, комментарии мои собственные). Люди могут все еще использовать скрипты для бекаса в последнюю минуту, но не только меняют структуру ценообразования, люди ожидают борьбы с другими , Вы также можете делать что-то, чтобы ограничить количество ставок за определенный период времени, заставлять людей заблаговременно звонить за код авторизации и т. Д.

Независимо от того, насколько надежны мысли нацистов их сообщения, союзники часто нарушали свои сообщения. Независимо от того, как вы пытаетесь остановить ботов от использования вашего сайта, владельцы ботов разработают путь вокруг него. Извините, если это делает вас нацистами 🙂

Я думаю, что требуется другое мышление

• Не пытайтесь запретить ботам использовать ваш сайт
• Не идите за исправление, которое работает немедленно, играйте в длинную игру

Вдумайтесь, что неважно, является ли клиент вашего сайта человеком или ботом, оба просто платят клиентам; но одно имеет несправедливое преимущество над другим. Некоторые пользователи без значительной социальной жизни (отшельники) могут быть столь же раздражающими для других пользователей вашего сайта, как боты.

Запишите время публикации предложения и время, когда учетная запись решит его купить.

Это дает вам отчет о том, как быстро клиент покупает материал.

Измените время, в которое вы публикуете предложения.

Например, у вас есть 3-часовое окно, начинающееся с некоторого неясного времени дня (полночь?). Только боты и отшельники будут постоянно обновлять страницу в течение 3 часов, чтобы получить заказ за считанные секунды. Никогда не изменяйте базовое время, только размер windows.

Со временем появится изображение.

01: Вы можете видеть, какие учетные записи регулярно покупают продукты в течение нескольких секунд после их выхода в эфир. Предложить, что они могут быть ботами.

02: Вы также можете посмотреть окно времени, используемое для предложений, если в окне 1 час, то некоторые ранние покупатели будут людьми. Человек редко будет обновляться в течение 4 часов. Если прошедшее время вполне согласуется между публикацией / покупкой, независимо от продолжительности windows, то это бот. Если время публикации / покупки сокращается для небольших окон и увеличивается дольше для больших окон, это отшельник!

Теперь вместо того, чтобы останавливать ботов от использования вашего сайта, у вас достаточно информации, чтобы рассказать вам, какие учетные записи, безусловно, используются ботами, и какие учетные записи, скорее всего, будут использоваться отшельниками. То, что вы делаете с этой информацией, зависит от вас, но вы, безусловно, можете использовать его, чтобы сделать ваш сайт более справедливым для людей, у которых есть жизнь.

Я думаю, что запретить бот-счета будет бессмысленно, это было бы похоже на звонок по Гитлеру и сказать «Спасибо за позиции ваших подводных лодок!». Как-то вам нужно использовать информацию таким образом, чтобы владельцы учетных записей не понимали. Посмотрим, смогу ли я что-нибудь увидеть …

Обработка заказов в очереди:

Когда клиент отправляет заказ, они сразу же получают электронное письмо с подтверждением о том, что их заказ помещается в очередь и будет уведомлен о его обработке. Я испытываю подобные вещи с заказом / отправкой на Amazon, и это меня совсем не беспокоит, я не возражаю, чтобы получить письмо через несколько дней, сообщив, что мой заказ был отправлен, пока я сразу получаю электронное письмо с сообщением о том, что Амазонка знает, что я хочу книгу. В вашем случае это будет электронное письмо для

1. Ваш заказ был помещен и находится в очереди.
2. Ваш заказ был обработан.
3. Ваш заказ был отправлен.

Пользователи считают, что они находятся в справедливой очереди. Обработайте свою очередь каждые 1 час, чтобы обычные пользователи также столкнулись с очередью, чтобы не вызывать подозрений. Только обрабатывать заказы с учетных записей ботов и отшельников, как только они попали в очередь для «среднего времени заказа человека + х часов». Эффективное сокращение ботов до людей.

Я говорю, выставлять информацию о ценах с помощью API. Это неинтуитивное решение, но оно помогает вам контролировать ситуацию. Добавьте некоторые ограничения API, чтобы сделать его несколько менее функциональным, чем веб-сайт.

Вы можете сделать то же самое для заказа. Вы можете экспериментировать с небольшими изменениями функциональности / производительности API, пока не получите желаемый эффект.

Для проверки IP-адресов есть прокси-серверы и бот-сети. Есть скрипты чтения captcha, которые очень хороши. Есть даже команды рабочих в Индии, которые побеждают капчу за небольшую цену. Любое решение, которое вы можете придумать, может быть разумно побеждено. Даже решения Ned Batchelder можно преодолеть с помощью элемента управления WebBrowser или другого имитируемого браузера в сочетании с списком ботнета или прокси.

В настоящее время мы используем последнее поколение балансировщиков BigIP от F5 для этого. BigIP имеет расширенные функции управления трафиком, которые могут определять скребки и боты на основе частоты и моделей использования даже из множества источников за одним IP. Затем он может дросселировать их, обслуживать их альтернативным контентом или просто пометить их заголовками или куки, чтобы вы могли идентифицировать их в своем коде приложения.

Как насчет введения задержки, которая требует взаимодействия с человеком, как своего рода «игра CAPTCHA». Например, это может быть небольшая флеш-игра, в которой за 30 секунд они должны расколоть клетчатые шарики и избежать разрыва твердых мячей (избегая проблем с цветной слепотой!). В игре будет дано случайное числовое семя, и то, что игра передает на сервер, будут координатами и отметками времени щелкнутых точек вместе с используемым семенем.

На сервере вы имитируете механику игры, используя это семя, чтобы увидеть, действительно ли щелчки разрывают шары. Если они это сделали, они не только были людьми, но и потребовали 30 секунд, чтобы утвердить себя. Дайте им идентификатор сеанса.

Вы позволяете этому идентификатору сеанса делать то, что ему нравится, но если он делает слишком много запросов, они не могут продолжить, не играя снова.

Во-первых, позвольте мне повторить, что нам нужно сделать здесь. Я понимаю, что просто перефразирую оригинальный вопрос, но важно, чтобы мы получили это на 100% прямо, потому что есть много замечательных предложений, которые получают 2 или 3 из 4 вправо, но, как я продемонстрирую, вам понадобится многогранный подход для охвата всех требований.

Требование 1: Избавление от «бот-хлопания»:

Быстрое «захлопывание» вашей главной страницы ухудшает производительность вашего сайта и лежит в основе проблемы. «Шлем» происходит как от ботов с одним IP-адресом, так и от предположительно – от бот-сетей. Мы хотим избавиться от обоих.

Требование 2: Не возитесь с пользовательским интерфейсом:

Мы могли бы исправить ситуацию с ботом довольно эффективно, применяя противную процедуру проверки, например, звоните человеку-человеку, решая кучу CAPTCHA или аналогичную, но это было бы похоже на то, чтобы заставить каждого невинного пассажира самолета проскользнуть через сумасшедшие обручи безопасности только для небольшого шанса улавливать самых глупых из террористов. О, подождите, мы действительно это сделаем. Но давайте посмотрим, не можем ли мы сделать это на woot.com.

Требование 3: Избегать «гонки вооружений»:

Как вы уже упоминаете, вы не хотите, чтобы вас схватили в гонке вооружений spambot. Таким образом, вы не можете использовать простые настройки, такие как скрытые или смешанные поля форм, математические вопросы и т. Д., Поскольку они представляют собой практически неясные меры, которые могут быть тривиально автоопределены и обойдены.

Требование 4: Тревожные «тревожные» боты:

Это может быть самым сложным из ваших требований. Даже если мы сможем сделать эффективную проверку прав человека, боты все равно смогут опросить вашу первую страницу и предупредить сценариста, когда появится новое предложение. Мы также хотим, чтобы эти боты были недопустимыми. Это более сильная версия первого требования, так как не только боты не могут требовать быстрых запросов на производительность – они не могут даже выдавать достаточно повторяющихся запросов для отправки «тревоги» скрипту вовремя, чтобы выиграть предложение.

Хорошо, давайте посмотрим, если мы сможем удовлетворить все четыре требования. Во-первых, как я уже упоминал, ни одна мера не собирается делать трюк. Вам нужно будет совместить пару трюков, чтобы достичь этого, и вам придется проглотить два досады:

1. Небольшое количество пользователей будет необходимо перепрыгнуть через обручи
2. Небольшое количество пользователей не сможет получить специальные предложения

Я понимаю, что это раздражает, но если мы сможем сделать «небольшое» число достаточно маленьким , я надеюсь, вы согласитесь, что позитивы перевешивают негативы.

Первая мера: Пользовательское дросселирование:

Это не проблема, и я уверен, что вы это делаете. Если пользователь вошел в систему и продолжает обновляться 600 раз в секунду (или что-то еще), вы перестаете отвечать и скажите ему, чтобы он охладил его. На самом деле, вы, вероятно, значительно замалчиваете свои просьбы, но вы получите эту идею. Таким образом, зарегистрированный бот получит запрет / дросселирование, как только он начнет опрос вашего сайта. Это легкая часть. Неаутентифицированные боты – наша настоящая проблема, поэтому к ним:

Вторая мера: некоторая форма регулирования IP, как это предлагают почти все:

Независимо от того, что вам нужно будет сделать с помощью дросселирования на основе IP, чтобы помешать «бот-хлопнуть». Поскольку для вас важно, чтобы пользователи, не прошедшие проверку подлинности (без входа), получали специальные предложения, у вас есть только IP-адреса, которые могут быть выполнены первоначально, и хотя они не идеальны, они работают против ботов с одним IP-адресом. Ботнеты – это другой зверь, но я вернусь к ним. На данный момент мы сделаем несколько простых дросселей, чтобы бить быстрых ботов с одним IP-адресом.

Снижение производительности является неоправданным, если вы запускаете проверку IP перед любой другой обработкой, используете прокси-сервер для логики дросселирования и сохраняете IP-адреса в структурной структуре, оптимизированной для memcached.

Третья мера: Сглаживание дроссельной заслонки с помощью кешированных ответов:

При использовании быстрых ботов с одним IP-адресом, мы все равно должны решать медленные боты с одним IP-адресом, то есть. боты, которые специально настроены для «летать под радаром», путем интервальных запросов немного дальше, чем предотrotation дросселирования.

Чтобы мгновенно сделать медленные однопользовательские боты бесполезными, просто используйте страtagsю, предложенную abelenky: обслуживайте 10-минутные кэшированные страницы для всех IP-адресов, которые были обнаружены за последние 24 часа (или так). Таким образом, каждый IP получает «шанс» в день / час / неделю (в зависимости от выбранного вами периода), и не будет никакого явного раздражения для реальных пользователей, которые просто нажимают «перезагрузить», за исключением того, что они не выигрывают предложение.

Красота этой меры заключается в том, что это также тревожные боты с трепетами, если они не происходят из ботнета.

(Я знаю, что вы, вероятно, предпочтете это, если реальным пользователям разрешат обновляться снова и снова, но не существует способа сказать человеку, обновляющему спам, от бота-спама, связанного с запросом, без CAPTCHA или подобного)

Четвертая мера: reCAPTCHA:

Вы правы, что CAPTCHA вредят пользователю, и его следует избегать. Однако в одной ситуации они могут быть вашим лучшим другом: если вы разработали очень ограничительную систему для предотвращения ботов, то – из-за ее ограничительности – также улавливает ряд ложных срабатываний; то CAPTCHA служил в качестве последнего средства , позволяя тем реальным пользователям, которые пойманы, чтобы ускользнуть от вашего дросселирования (таким образом, избегая раздражающих ситуаций DoS).

The sweet spot, of course, is when ALL the bots get caught in your net, while extremely few real users get bothered by the CAPTCHA.

If you, when serving up the 10-minute-old cached pages, also offer an alternative, optional , CAPTCHA-verified ‘front page refresher’, then humans who really want to keep refreshing, can still do so without getting the old cached page, but at the cost of having to solve a CAPTCHA for each refresh. That is an annoyance, but an optional one just for the die-hard users, who tend to be more forgiving because they know they’re gaming the system to improve their chances, and that improved chances don’t come free.

Fifth measure: Decoy crap:

Christopher Mahan had an idea that I rather liked, but I would put a different spin on it. Every time you are preparing a new offer, prepare two other ‘offers’ as well, that no human would pick, like a 12mm wingnut for $20. When the offer appears on the front page, put all three ‘offers’ in the same picture, with numbers corresponding to each offer. When the user/bot actually goes on to order the item, they will have to pick (a radio button) which offer they want, and since most bots would merely be guessing, in two out of three cases, the bots would be buying worthless junk.

Naturally, this doesn’t address ‘alarm bots’, and there is a (slim) chance that someone could build a bot that was able to pick the correct item. However, the risk of accidentally buying junk should make scripters turn entirely from the fully automated bots.

Sixth measure: Botnet Throttling:

[deleted]

Okay………… I’ve now spent most of my evening thinking about this, trying different approaches…. global delays…. cookie-based tokens.. queued serving… ‘stranger throttling’…. And it just doesn’t work. Это не так. I realized the main reason why you hadn’t accepted any answer yet was that noone had proposed a way to thwart a distributed/zombie net/botnet attack…. so I really wanted to crack it. I believe I cracked the botnet problem for authentication in a different thread , so I had high hopes for your problem as well. But my approach doesn’t translate to this. You only have IPs to go by, and a large enough botnet doesn’t reveal itself in any analysis based on IP addresses.

So there you have it : My sixth measure is naught. Ничего. Zip. Unless the botnet is small and/or fast enough to get caught in the usual IP throttle, I don’t see any effective measure against botnets that doesn’t involve explicit human-verification such as CAPTHAs. I’m sorry, but I think combining the above five measures is your best bet. And you could probably do just fine with just abelenky’s 10-minute-caching trick alone.

There are a few other / better solutions already posted, but for completeness, I figured I’d mention this:

If your main concern is performance degradation, and you’re looking at true hammering , then you’re actually dealing with a DoS attack, and you should probably try to handle it accordingly. One common approach is to simply drop packets from an IP in the firewall after a number of connections per second/minute/etc. For example, the standard Linux firewall, iptables, has a standard operation matching function ‘hashlimit’, which could be used to correlate connection requests per time unit to an IP-address.

Although, this question would probably be more apt for the next SO-derivate mentioned on the last SO-podcast, it hasn’t launched yet, so I guess it’s ok to answer 🙂

РЕДАКТИРОВАТЬ:
As pointed out by novatrust, there are still ISPs actually NOT assigning IPs to their customers, so effectively, a script-customer of such an ISP would disable all-customers from that ISP.

Write a reverse-proxy on an apache server in front of your application which implements a Tarpit (Wikipedia Article) to punish bots. It would simply manage a list of IP addresses that connected in the last few seconds. You detect a burst of requests from a single IP address and then exponentially delay those requests before responding.

Of course, multiple humans can come from the same IP address if they’re on a NAT’d network connection but it’s unlikely that a human would mind your response time going for 2mS to 4mS (or even 400mS) whereas a bot will be hampered by the increasing delay pretty quickly.

1. Provide an RSS feed so they don’t eat up your bandwidth.
2. When buying, make everyone wait a random amount of time of up to 45 seconds or something, depending on what you’re looking for exactly. Exactly what are your timing constraints?
3. Give everyone 1 minute to put their name in for the drawing and then randomly select people. I think this is the fairest way.
4. Monitor the accounts (include some times in the session and store it?) and add delays to accounts that seem like they’re below the human speed threshold. That will at least make the bots be programmed to slow down and compete with humans.

First of all, by definition, it is impossible to support stateless, ie truly anonymous, transactions while also being able to separate the bots from legitimate users.

If we can accept a premise that we can impose some cost on a brand-spanking-new woot visitor on his first page hit(s), I think I have a possible solution. For lack of a better name, I’m going to loosely call this solution “A visit to the DMV.”

Let’s say that there’s a car dealership that offers a different new car each day, and that on some days, you can buy an exotic sports car for $5 each (limit 3), plus a $5 destination charge.

The catch is, the dealership requires you to visit the dealership and show a valid driver’s license before you’re allowed in through the door to see what car is on sale. Moreover, you must have said valid driver’s license in order to make the purchase.

So, the first-time visitor (let’s call him Bob) to this car dealer is refused entry, and is referred to the DMV office (which is conveniently located right next door) to obtain a driver’s license.

Other visitors with a valid driver’s license is allowed in, after showing his driver’s license. A person who makes a nuisance of himself by loitering around all day, pestering the salesmen, grabbing brochures, and emptying the complimentary coffee and cookies will eventually be turned away.

Now, back to Bob without the license — all he has to do is endure the visit to the DMV once. After that, he can visit the dealership and buy cars anytime he likes, unless he accidentally left his wallet at home, or his license is otherwised destroyed or revoked.

The driver’s license in this world is nearly impossible to forge.

The visit to the DMV involves first getting the application form at the “Start Here” queue. Bob has to take the completed application to window #1, where the first of many surly civil servants will take his application, process it, and if everything is in order, stamp the application for the window and send him to the next window. And so, Bob goes from windows to window, waiting for each step of his application to go through, until he finally gets to the end and receives his drivere’s license.

There’s no point in trying to “short circuit” the DMV. If the forms are not filled out correctly in triplicate, or any wrong answers given at any window, the application is torn up, and the hapless customer is sent back to the start.

Interestingly, no matter how full or empty the office is, it takes about the same amount of time to get serviced at each successive window. Even when you’re the only person in line, it seems that the personnel likes to make you wait a minute behind the yellow line before uttering, “Next!”

Things aren’t quite so terrible at the DMV, however. While all the waiting and processing to get the license is going on, you can watch a very entertaining and informative infomercial for the car dealership while you’re in the DMV lobby. In fact, the infomerical runs just long enough to cover the amount of time you spend getting your license.

The slightly more technical explanation:

As I said at the very top, it becomes necessary to have some statefulness on the client-server relationship which allows you to separate humans from bots. You want to do it in a way that doesn’t overly penalize the anonymous (non-authenticated) human visitor.

This approach probably requires an AJAX-y client-side processing. A brand-spanking-new visitor to woot is given the “Welcome New User!” page full of text and graphics which (by appropriate server-side throttling) takes a few seconds to load completely. While this is happening (and the visitor is presumably busy reading the welcome page(s)), his identifying token is slowly being assembled.

Let’s say, for discussion, the token (aka “driver’s license) consists of 20 chunks. In order to get each successive chunk, the client-side code must submit a valid request to the server. The server incorporates a deliberate delay (let’s say 200 millisecond), before sending the next chunk along with the ‘stamp’ needed to make the next chunk request (ie, the stamps needed to go from one DMV window to the next). All told, about 4 seconds must elapse to finish the chunk-challenge-response-chunk-challenge-response-…-chunk-challenge-response-completion process.

At the end of this process, the visitor has a token which allows him to go to the product description page and, in turn, go to the purchasing page. The token is a unique ID to each visitor, and can be used to throttle his activities.

On the server side, you only accept page views from clients that have a valid token. Or, if it’s important that everyone can ultimately see the page, put a time penalty on requests that is missing a valid token.

Now, for this to be relatiely benign to the legitimate human visitor,t make the token issuing process happen relatively non-intrusively in the background. Hence the need for the welcome page with entertaining copy and graphics that is deliberately slowed down slightly.

This approach forces a throttle-down of bots to either use an existing token, or take the minimum setup time to get a new token. Of course, this doesn’t help as much against sophisticated attacks using a distributed network of faux visitors.

You can’t totally prevent bots, even with a captcha. However you can make it a pain to write and maintain a bot and therefore reduce the number. Particularly by forcing them to update their bots daily you’ll be causing most to lose interest.

Here are a some ideas to make it harder to write bots:

• Require running a javascript function. Javascript makes it much more of a pain to write a bot. Maybe require a captcha if they aren’t running javascript to still allow actual non-javascript users (minimal).

• Time the keystrokes when typing into the form (again via javascript). If it’s not human-like then reject it. It’s a pain to mimic human typing in a bot.

• Write your code to update your field ID’s daily with a new random value. This will force them to update their bot daily which is a pain.

• Write your code to re-order your fields on a daily basis (obviously in some way that’s not random to your users). If they’re relying on the field order, this will trip them up and again force daily maintenance to their bot code.

• You could go even further and use Flash content. Flash is totally a pain to write a bot against.

Generally if you start taking a mindset of not preventing them, but making it more work for them, you can probably achieve the goal you’re looking for.

Stick a 5 minute delay on all product announcements for unregistered users. Casual users won’t really notice this and noncasual users will be registered anyhow.

I’m not seeing the great burden that you claim from checking incoming IPs. On the contrary, I’ve done a project for one of my clients which analyzes the HTTP access logs every five minutes (it could have been real-time, but he didn’t want that for some reason that I never fully understood) and creates firewall rules to block connections from any IP addresses that generate an excessive number of requests unless the address can be confirmed as belonging to a legitimate search engine (google, yahoo, etc.).

This client runs a web hosting service and is running this application on three servers which handle a total of 800-900 domains. Peak activity is in the thousand-hits-per-second range and there has never been a performance issue – firewalls are very efficient at dropping packets from blacklisted addresses.

And, yes, DDOS technology definitely does exist which would defeat this scheme, but he’s not seeing that happen in the real world. On the contrary, he says it’s vastly reduced the load on his servers.

My approach would be to focus on non-technological solutions (otherwise you’re entering an arms race you’ll lose, or at least spend a great deal of time and money on). I’d focus on the billing/shipment parts – you can find bots by either finding multiple deliveries to same address or by multiple charges to a single payment method. You can even do this across items over several weeks, so if a user got a previous item (by responding really really fast) he may be assigned some sort of “handicap” this time around.

This would also have a side effect (beneficial, I would think, but I could be wrong marketing-wise for your case) of perhaps widening the circle of people who get lucky and get to purchase woot.

Most purely technical solutions have already been offered. I’ll therefore suggest another view of the problem.

As I understand it, the bots are set up by people genuinely trying to buy the bags you’re selling. The problem is –

1. Other people, who don’t operate bots, deserve a chance to buy, and you’re offering a limited amount of bags.
2. You want to attract humans to your site and just sell the bags.

Instead of trying to avoid the bots, you can enable potential bag-buyers to subscribe to an email, or even SMS update, to get notified when a sell will take place. You can even give them a minute or two head start (a special URL where the sell starts, randomly generated, and sent with the mail/SMS).

When these buyers go to buy they’re in you’re site, you can show them whatever you want in side banners or whatever. Those running the bots will prefer to simply register to your notification service.

The bots runners might still run bots on your notification to finish the buy faster. Some solutions to that can be offering a one-click buy.

By the way, you mentioned your users are not registered, but it sounds like those buying these bags are not random buyers, but people who look forward to these sales. As such, they might be willing to register to get an advantage in trying to “win” a bag.

In essence what I’m suggesting is try and look at the problem as a social one, rather than a technical one.

Asaf

Time-block user agents that make so-many requests per minute. Eg if you’ve got somebody requesting a page exactly every 5 seconds for 10 minutes, they’re probably not a user… But it could be tricky to get this right.

If they trigger an alert, redirect every request to a static page with as little DB-IO as possible with a message letting them know they’ll be allowed back on in X minutes.

It’s important to add that you should probably only apply this on requests for pages and ignore all the requests for media (js, images, etc).

Preventing DoS would defeat #2 of @davebug’s goals he outlined above, “Keep the site at a speed not slowed by bots” but wouldn’t necessary solve #1, “Sell the item to non-scripting humans”

I’m sure a scripter could write something to skate just under the excessive limit that would still be faster than a human could go through the ordering forms.

All right so the spammers are out competing regular people to win the “bog of crap” auction? Why not make the next auction be a literal “bag of crap”? The spammers get to pay good money for a bag full of doggy do, and we all laugh at them.

The important thing here is to change the system to remove load from your server, prevent bots from winning the bag of crap WITHOUT letting the botlords know you are gaming them or they will revise their strategy. I don’t think there is any way to do this without some processing at your end.

So you record hits on your home page. Whenever someone hits the page that connection is compared to its last hit, and if it was too quick then it is sent a version of the page without the offer. This can be done by some sort of load balancing mechanism that sends bots (the hits that are too fast) to a server that simply serves cached versions of your home page; real people get sent to the good server. This takes the load off the main server and makes the bots think that they are still being served the pages correctly.

Even better if the offer can be declined in some way. Then you can still make the offers on the faux server but when the bot fills out the form say “Sorry, you weren’t quick enough” 🙂 Then they will definitely think they are still in the game.

How do you know there are scripters placing orders?

The crux of your problem is that you can’t separate the scripters from the legitimate users and therefore can’t block them, so how is it that you know there are scripters at all?

If you have a way to answer this question, then you have a set of characteristics you can use to filter the scripters.

Let’s turn the problem on its head – you have bots buying stuff that you want real people to buy, how about making a real chance that the bots will buy stuff that you don’t want the real people to buy.

Have a random chance for some non displayed html that the scraping bots will think is the real situation, but real people won’t see (and don’t forget that real people includes the blind, so consider screen readers etc as well), and this travels through to purchase something exorbitantly expensive (or doesn’t make the actual purchase, but gets payment details for you to put on a banlist).

Even if the bots switch to ‘alert the user’ rather than ‘make the purchase’, if you can get enough false alarms, you may be able to make it sufficiently worthless for people (maybe not everyone, but some reduction in the scamming is better than none at all) not to bother.