Comments 59
Ну или нужно вынести генерацию капч на отдельный сервер (VPS)
Может не помочь, если досить сервер генерации капч — основной сервер не получит капчи и не выполнит своего назначения (пользователи не войдут, оплаты не пойдут, что-то еще, итого тоже отказ)…
Согласитесь, это не так страшно, как полный отказ сервера. Да и на этот случай капчу вообще можно отключить. Или иметь два сервера.
Пожалуй вы правы.
А тот случай, когда при ошибке ввода пароля для входа нужна капча, и чтобы забрутфорсить пароли, параллельно запустили DoS, чтобы убрать капчу?
Как вариант, делать очередь генерации капчи и кэш. Если очередь переполнена — возвращать случайную из кэша. Это не слишком хороший вариант, но позволит избежать отказа в использовании.
ddd
Всего лишь нужно больше запросов, и направить их на второй сервер. Соревнование пушки и брони — решение вида «а они пока не достаточно круты».
У атакующих, разумеется, свои методы увеличить интенсивность запросов — так что итерация «кто-кого» имеет шанс повториться еще не раз и не два…
У атакующих, разумеется, свои методы увеличить интенсивность запросов — так что итерация «кто-кого» имеет шанс повториться еще не раз и не два…
reCaptcha не такое уж добро, вводить в два раза больше текста, да и не читается иногда…
Исключая конечно тот замечательный факт что уже не ваш сервер ее генерит
Исключая конечно тот замечательный факт что уже не ваш сервер ее генерит
Я лично угадываю reCaptcha раза с 5го.
Зачем в два-то? В рекапче можно только одно слово вводить.
reCaptcha внешний сервис и так-же может быть недоступным. Все мы помним, как на яндексе была авария и все резко начали звонить операторам с фразами не работает инет… Доверяй только себе! надо иметь кеш. в банке хранить название картинки и текст и по базе проверять. Кеш перегенерировать раз в сутки например.
В рекапче есть кнопка refresh, если есть сомнения в читаемости.
Блокировать таких умников надо. Если с нескольких IP всего стучатся, то что-то на основе
nginx limit_zone $arg_PHPSESSID + limit_conn
может помочь.
nginx limit_zone $arg_PHPSESSID + limit_conn
может помочь.
В модуле для Коханы есть возможность делать проверку на кол-во неверных ответов, как еще один из способов предотвращения атаки:
if ($captcha->invalid_count() >= Kohana::config('captcha.max_invalid_count'))
{
throw new HTTP_Exception_403;
}
Дело не доходит до ресурсоемкой генерации картинки-капчи.
Так ответ то никто и не вводит. Количество неверных ответов равно 0. Или там как то по другому считается?
Так и картинку никто не генерит. На запрос получения картинки быстренько генерится HTTP 403.
Давайте по порядку.
Я хочу ввести каптчу
для этого делаю запрос к картинке, получаю, ничего не ввожу
делаю запрос к картинке, получаю и т.д.
в какой момент мне 403 вернётся?
Я хочу ввести каптчу
для этого делаю запрос к картинке, получаю, ничего не ввожу
делаю запрос к картинке, получаю и т.д.
в какой момент мне 403 вернётся?
Не вникая в подробности счисления количества неверных попыток ввода каптчи, рискну предположить, что запрос к картинке считается за попытку, что совершенно нормально, если человек пытается подобрать ту, которую сможет понять. Установка лимита, скажем, в 10 попыток должна будет отсеять атакующих и умственно отсталых.
Nginx перед индейцем и
И пусть хоть задолбется…
limit_conn one 5;И пусть хоть задолбется…
Предлагаю вернутся к истоку вопроса о капче. То что сервис посещают боты и обходят механизмы защиты — проблема программиста, а не пользователя.
Капча была придумана как защита от ботов. В статье же мы видим, как капча может убить сервис. Так ли нужна она на самом деле? Может просто стоит полностью отказатся от капчи?
Давайте попробуем решить вопрос.
Чем больше посещаемость сервиса, тем меньше капча на нашем сервере будет спасать от ботов. Потому что найдутся и кто просто хочет все поломать, со временем найдутся и специально заточенные антикапчи — ресурс то популярный.
В этой ситуации спасет свой велосипед. Учитывая специфику сервиса, можно подготовить умное решение, которое не будет затрагивать интересы пользователя, не будет перекладывать на него обязанности программиста. Хитрых решений много на хабре: флеш, Js, анализ активности и прочие, и прочие.
Но изобретать свой веловипед дорого. Дорого, потому что это время программиста, которое должно оплачиватся. И на начальном этапе, когда сервис только запустился, просто нет денег, чтобы делать свою умную защиту.
Тут нам на помощь приходит reCaptcha или решение программиста чистить базу данных ручками и не ставить вообще никакой защиты.
Так что вот мои выводы:
Для новых версисов или рекапча, или ничего
Для популярных сервисов — свое решение, которое не заставляет пользователей делать лишние движения.
И вот еще одна мысль пришла. Например, мы используем решение на флеше или JS. А ведь не у всех пользователей есть JS и флеш. Может мы начнем терять пользователей? Никак нет. Ведь никто не измерял, сколько пользователей мы теряли на том, что они не могут ввести капчу, потому что она дурная и настройки выкручены по максимому. Может активность наоборот станет больше? А может и не станет.
Вывод: пока не попробуешь — не узнаешь.
Капча была придумана как защита от ботов. В статье же мы видим, как капча может убить сервис. Так ли нужна она на самом деле? Может просто стоит полностью отказатся от капчи?
Давайте попробуем решить вопрос.
Чем больше посещаемость сервиса, тем меньше капча на нашем сервере будет спасать от ботов. Потому что найдутся и кто просто хочет все поломать, со временем найдутся и специально заточенные антикапчи — ресурс то популярный.
В этой ситуации спасет свой велосипед. Учитывая специфику сервиса, можно подготовить умное решение, которое не будет затрагивать интересы пользователя, не будет перекладывать на него обязанности программиста. Хитрых решений много на хабре: флеш, Js, анализ активности и прочие, и прочие.
Но изобретать свой веловипед дорого. Дорого, потому что это время программиста, которое должно оплачиватся. И на начальном этапе, когда сервис только запустился, просто нет денег, чтобы делать свою умную защиту.
Тут нам на помощь приходит reCaptcha или решение программиста чистить базу данных ручками и не ставить вообще никакой защиты.
Так что вот мои выводы:
Для новых версисов или рекапча, или ничего
Для популярных сервисов — свое решение, которое не заставляет пользователей делать лишние движения.
И вот еще одна мысль пришла. Например, мы используем решение на флеше или JS. А ведь не у всех пользователей есть JS и флеш. Может мы начнем терять пользователей? Никак нет. Ведь никто не измерял, сколько пользователей мы теряли на том, что они не могут ввести капчу, потому что она дурная и настройки выкручены по максимому. Может активность наоборот станет больше? А может и не станет.
Вывод: пока не попробуешь — не узнаешь.
Я тут вспомнил, как пытался на сервер без иксов скачать Java7 с сайта Oracle. Кастрировать надо за такие решения, фильтрация запросов — это дело веб-сервера, а не клиентского JS/Flash.
А джаву пришлось через друга перекачивать туда, ибо ничто консольное без JS не смогло скачать.
А джаву пришлось через друга перекачивать туда, ибо ничто консольное без JS не смогло скачать.
Может мы начнем терять пользователей? Никак нет. Ведь никто не измерял, сколько пользователей мы теряли на том, что они не могут ввести капчу, потому что она дурная и настройки выкручены по максимому.Как минимум, поисковые боты будут обходить такой сайт стороной, ибо он ничего им не возвращает
Сами способы защиты — это всегда выбор разработчика. Если он сможет настроить веб сервер для фильтрации запросов — это круто. А если не сможет?
И при чем здесь поисковые боты? Мы же говорили про защиту от спам ботов и защиту от отказа в обслуживании.
И при чем здесь поисковые боты? Мы же говорили про защиту от спам ботов и защиту от отказа в обслуживании.
Я для своего скрипта написал более простое решение: вопрос — ответ.
Админ создает в админке список вопросов и ответов на них, в таком случаи нагрузка минимальная на сервер и защита, на мой взгляд, довольно надежная, т.к. список у каждого будет уникален, если конечно не будет вопросов типо 2+2 =?
А насчёт рекапчи — защита может и хорошая, но она отсеивает не только ботов, но и людей ) Иногда приходится раз по 10 обновлять капчу, чтобы наконец-то зарегистрироваться на сайте, что уж говорить про людей с плохим зрением…
Админ создает в админке список вопросов и ответов на них, в таком случаи нагрузка минимальная на сервер и защита, на мой взгляд, довольно надежная, т.к. список у каждого будет уникален, если конечно не будет вопросов типо 2+2 =?
А насчёт рекапчи — защита может и хорошая, но она отсеивает не только ботов, но и людей ) Иногда приходится раз по 10 обновлять капчу, чтобы наконец-то зарегистрироваться на сайте, что уж говорить про людей с плохим зрением…
Сделав предварительную выборку вариантов, можно получить большинство ответов и заранее добавить в бота ответы на них.
Если число вопросов не стремится к бесконечности, то это совсем несерьезная капча.
Если число вопросов не стремится к бесконечности, то это совсем несерьезная капча.
База должна быть очень большой, т.к. варианты ответов могут быть не такими банальными и глобальными как «кто президент РФ», а направлены на конкретную тематику сайта, например вопрос о сериале или аниме героях и т.п.
Наполнять руками тысячи варианов — не благодарный труд. А ведь их еще и обновлять надо регулярно.
Зачем тысяча? Если, как я сказал, будет сайт по определенной тематике, например, аниме, то достаточно указать 10-20 вопросов связанных с данной тематикой и обновлять раз в несколько месяцев, а то и год (всё зависит от ботов).
Так я о том, что автору бота достаточно в таком случае до 100 раз обратиться к капче, чтобы получить большинство вопросов. И в боте сохранить словарик «вопрос» => «ответ». Еще и сохранять ненайденные вопросы.
Корректировка бота под такую капчу будет занимать меньше времени, чем наполнение вопросами, особенно если этот зловред «в теме» тематики сайта.
Корректировка бота под такую капчу будет занимать меньше времени, чем наполнение вопросами, особенно если этот зловред «в теме» тематики сайта.
Он получит только вопросы, ответы нужно будет самому составлять и атака уже будет нацеленной, а против такого практически любую капчу можно обойти.
Но суть вопроса-ответа именно в том, чтобы избежать попадания сайта под ботов нацеленных на различные сайты с теми же рекапчами или Kcaptcha.
Но суть вопроса-ответа именно в том, чтобы избежать попадания сайта под ботов нацеленных на различные сайты с теми же рекапчами или Kcaptcha.
Сложнее реализовать распознавание произвольной капчи, нежели самому ответить на несколько понятных вопросов.
Имхо, капча должна поддерживать максимально большое число вариантов ответов. Понятно, что если бот ожидает recaptcha, а ему подсовывают текстовый вопрос, он офигеет. А при настройке бота толку от вопросов не будет никакого.
Имхо, капча должна поддерживать максимально большое число вариантов ответов. Понятно, что если бот ожидает recaptcha, а ему подсовывают текстовый вопрос, он офигеет. А при настройке бота толку от вопросов не будет никакого.
Собсно как раньше предлагаю положиться на асиметричные задачки можно предварительно посчитанные т.е. отдаем клиенту яваскрипт который пару секунд считаться будет, результатом будет адрес капчи, при неправильном подсчете капчу не отдаем тоже.
Например даем клиенту массив цифирек-ключей, и предлагаем их собрать чтоб получилась еще одна цифирька, ключи привязанные к правильным цифирькам и будут искомым адресом, ну это конечно совсем упрощенно можно еще каждую цифрь в квадрате отдать, а если еще и дробную так вобще красота, или ответ задачки является вопросом к следующей и так в цикле от 1 до 10000…
Давайте устроим ддос на сайт rubet (тот самый который типо «как обыграть казино») у них капча генерируется по ссылке rubet.com/antibot.aspx?t=tak_vam-I-nado
ну честное слово достала их реклама, ну ладно бы просто открывалась, так она и ещё и говорить начинает «вас приветствует сайт рубет»…
(за мной уже выехали?)
ну честное слово достала их реклама, ну ладно бы просто открывалась, так она и ещё и говорить начинает «вас приветствует сайт рубет»…
(за мной уже выехали?)
И чем это отличается от запросов к любому другому «тяжёлому» скрипту — например, поиску? Зато какой громкий заголовок)
По-моему, капча выделяется среди других тяжелых запросов тем, что:
Поэтому отдельно про капчу.
А заголовок — самый обычный, это действительно DoS, действительно возможность атаки. Просто хотелось обратить внимание на эту потенциальную опасность.
- она сразу бросается в глаза — легко обнаружить (в отличие от долго выполняющегося SQL, например, который можно принять за сетевой лаг)
- она гарантировано ресурсоемкая (MySQL, как правило, кеширует запросы)
- очень легко использовать уязвимость (нет необходимости писать что-то сложное)
- это не занимает много ресурсов (в отличие от 1000 iframe'ов для POST запросов)
Поэтому отдельно про капчу.
А заголовок — самый обычный, это действительно DoS, действительно возможность атаки. Просто хотелось обратить внимание на эту потенциальную опасность.
а почему капчи нельзя нагенерить программкой на плюсах + хранить некоторый пул, скажем пару миллионов уже сгенеренных каптч (да, несколько гигов займет — но это много?), и использовать его, если генерация новой не укладывается в определенное время?
Скрытая реклама piratepay.ru?
Мне тут подсказали, что можно сгенерировать картинки капчи заранее и хранить названия файлов + соответствующий текст в БД.
Мой вариант: не используйте капчу вообще.
Sign up to leave a comment.
DoS-атака на сайты с собственными капчами