Comments 24
UFO just landed and posted this here
Если говорить о массовости и доступности, то почему бы и нет
UFO just landed and posted this here
Тот же CloudFlare организует защиту от DDoS в том числе с помощью этой самой reCAPTCHA.
Так что предлагаю в теме разобраться всё-таки вам ;)
Скриншот, сделанный лично мной
Так что предлагаю в теме разобраться всё-таки вам ;)
UFO just landed and posted this here
Кто-то в этом топике писал, что капча это единственный способ защиты от DDoS, что ли? Всё ещё предлагаю вам разобраться в теме нормально, а не хватая рандомные абзацы из нетехнических текстов.
UFO just landed and posted this here
Ладно, пока я в хорошем настроении, специально для вас проведу мини-лекцию, хоть комментарии для этого и не очень подходят.
Спрятал под спойлер, длинно получилось
Что такое DDoS? В общем случае это когда клиентов настолько много, что сервис начинает не успевать их обслуживать («DDoS-атака на автобус — куча народу с пятисотками»).
Один из частных случаев DDoS-атаки — отправка множественных HTTP-запросов веб-серверу, которые сервер не успевает обрабатывать по причине занятости всех ресурсов другими запросами и отвечает каким-нибудь таймаутом (если вообще отвечает, хех). (Капитан Очевидность замечает, что большое количество запросов отправляют именно боты. А в посте как раз упоминается, что капча это защита от ботов ;)
Как защититься от этого? В общем случае — никак: достаточно мощная атака способна валить что угодно сколь угодно долго. Но для средних и слабых DDoS-атак вполне эффективным оказывается отфильтровывание подозрительных запросов какими-нибудь высокопроизводительными фильтрами (может, даже с помощью fail2ban, хоть это и не совсем по назначению) или на стороннем мощном прокси-сервере.
Именно так и работает CloudFlare: на домен сайта вешается IP-адрес сервера CF, а уже этот сервер перенаправляет запрос к сайту на настоящий сервер, IP-адрес которого не знает никто, кроме админов сервера и самого CF (иначе можно было бы просто атаковать этот IP-адрес напрямую в обход CF). Если CF не понравился какой-то HTTP-запрос, он просто отвечает ошибкой, и до настоящего сервера этот запрос не доходит вообще.
А теперь самая мякотка: как CF должен отличать хорошие запросы от плохих, какие запросы к серверу пускать, а какие не пускать? Один из способов — ВНЕЗАПНО — разгадывание капчи! Капча разгадана — значит запрос отправил человек, всё хорошо, перенаправляем на настоящий сервер. Не разгадана — значит бот. И пусть этот бот отправляет хоть сто тыщ мильёнов запросов — если он не разгадает капчу, до сервера не дойдёт ни один, и защита от DDoS таким образом обеспечена. (Правда, на мильёне мильёнов запросов может упасть уже сам CloudFlare, но сейчас не об этом.)
На скриншоте, который я выложил выше, CloudFlare включил режим параноика и счёл подозрительным HTTP POST-запрос с очень большим телом, в связи с чем и выдал мне капчу.
Очевидно, что есть и другие способы защиты, и капча лишь один из них. Не менее очевидно, что не-HTTP запросы капчей защитить невозможно.
Один из частных случаев DDoS-атаки — отправка множественных HTTP-запросов веб-серверу, которые сервер не успевает обрабатывать по причине занятости всех ресурсов другими запросами и отвечает каким-нибудь таймаутом (если вообще отвечает, хех). (Капитан Очевидность замечает, что большое количество запросов отправляют именно боты. А в посте как раз упоминается, что капча это защита от ботов ;)
Как защититься от этого? В общем случае — никак: достаточно мощная атака способна валить что угодно сколь угодно долго. Но для средних и слабых DDoS-атак вполне эффективным оказывается отфильтровывание подозрительных запросов какими-нибудь высокопроизводительными фильтрами (может, даже с помощью fail2ban, хоть это и не совсем по назначению) или на стороннем мощном прокси-сервере.
Именно так и работает CloudFlare: на домен сайта вешается IP-адрес сервера CF, а уже этот сервер перенаправляет запрос к сайту на настоящий сервер, IP-адрес которого не знает никто, кроме админов сервера и самого CF (иначе можно было бы просто атаковать этот IP-адрес напрямую в обход CF). Если CF не понравился какой-то HTTP-запрос, он просто отвечает ошибкой, и до настоящего сервера этот запрос не доходит вообще.
А теперь самая мякотка: как CF должен отличать хорошие запросы от плохих, какие запросы к серверу пускать, а какие не пускать? Один из способов — ВНЕЗАПНО — разгадывание капчи! Капча разгадана — значит запрос отправил человек, всё хорошо, перенаправляем на настоящий сервер. Не разгадана — значит бот. И пусть этот бот отправляет хоть сто тыщ мильёнов запросов — если он не разгадает капчу, до сервера не дойдёт ни один, и защита от DDoS таким образом обеспечена. (Правда, на мильёне мильёнов запросов может упасть уже сам CloudFlare, но сейчас не об этом.)
На скриншоте, который я выложил выше, CloudFlare включил режим параноика и счёл подозрительным HTTP POST-запрос с очень большим телом, в связи с чем и выдал мне капчу.
Очевидно, что есть и другие способы защиты, и капча лишь один из них. Не менее очевидно, что не-HTTP запросы капчей защитить невозможно.
UFO just landed and posted this here
Этот ваш «перевод трафика на проксирующий пул» и есть один из способов защиты от DDoS, лол. А уж то, защищает он с использованием рекапчи или не рекапчи, от бедности или не от бедности, уже не важно, важен сам факт: защита от DDoS вот она и вполне работает) Боты капчу не проходят — запросы до сервера не доходят — защита работает, никаких разводов)
UFO just landed and posted this here
Глупости опять пишете. Почему увеличим-то? Десяток запросов с одного айпишника и CF, и рекапча вполне выдержат, а если бот не решит капчу и на одиннадцатом запросе, то можно отправить его в бан на сутки-другие, начать резать вообще весь трафик и таким образом ничего не увеличивать.
Если же решить капчу вручную и уже потом запустить бота, то при частых запросах CF запросит капчу опять, а дальше уже как вариант по приведённой выше схеме. А если решать капчу вручную каждые несколько (десятков) секунд, то никакого DDoS из этого уже не выйдет)
Я не знаю, как это реализовано у CF на самом деле (благо в бан не попадал и капчи послушно проходил), но не надо понимать всё слишком прямолинейно и городить глупости)
Если же решить капчу вручную и уже потом запустить бота, то при частых запросах CF запросит капчу опять, а дальше уже как вариант по приведённой выше схеме. А если решать капчу вручную каждые несколько (десятков) секунд, то никакого DDoS из этого уже не выйдет)
Я не знаю, как это реализовано у CF на самом деле (благо в бан не попадал и капчи послушно проходил), но не надо понимать всё слишком прямолинейно и городить глупости)
UFO just landed and posted this here
Прочитав про «поиграть в небольшую игру» вспомнил про: https://www.youtube.com/watch?v=WqnXp6Saa8Y
Помимо стандартных функций защиты от ботов, такое решение добавляет в достаточно рутинную операцию немного весельяКакое счастье, что мне ещё такая капча не попадалась...))
Сервис сам «говорит», какие слова нужно ввести. И хотя это решение в теории выглядит эффективным, на практике все упирается в качество колонок компьютера пользователя.
На практике произнесение даже, вроде-бы, одинаковых букв носителями разных языков — различается.
Так, что русскоязычные пользователи опознают «шизгаду» — но вряд-ли её сумеют правильно вбить в поле.
А если речь пойдёт не о столь известной фразе…
В первой половине нулевых я пытался зарегится на ЖЖ. Поскольку тогда единственным доступом был диалап, то я как и все работал с отключенными картинками. С капчей просто какая-то засада была — показывал картинку, вводил с нее текст и облом. Наверное из-за фрагментарной загрузки где-то ломалась логика. А еще там был альтернативный вариант с аудиокапчей. Не смотря на то, что английский я тогда вообще не знал, я с первой же попытки вбил правильный ответ и прошел регистрацию. Я к тому, что создатели аудиокапч делают свои аудио-задания короткими и на слова из первых сотен частотного словаря.
Но думаю, что сейчас такая «защита» не актуально. Аудио-трек капчи направляем на распознавание и текстовый ответ назад в поле ввода — боты взламывать смогут проще, чем люди вбивать на слух.
Но думаю, что сейчас такая «защита» не актуально. Аудио-трек капчи направляем на распознавание и текстовый ответ назад в поле ввода — боты взламывать смогут проще, чем люди вбивать на слух.
reCaptcha распознается также распознается при помощи вышеупомянутых сервисов ручного ввода: rucaptcha, anti-captcha и другие. Правда, немного дороже обычной капчи.
Ботов, работающих на базе http клиента, т.е. без browser less технологий, также можно отсеять множеством методов.
Ботов, работающих на базе http клиента, т.е. без browser less технологий, также можно отсеять множеством методов.
Объясните мне, как можно было использовать капчу для распознавания старых газет?
Капча подразумевает на стороне сервера проверку правильности введенных данных? Если газета не распознана правильно изначально, как сервер убедится, что пользователь ввел правильно?
Капча подразумевает на стороне сервера проверку правильности введенных данных? Если газета не распознана правильно изначально, как сервер убедится, что пользователь ввел правильно?
Sign up to leave a comment.
Немного об истории CAPTCHA