Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 109
вы проверяли данное решение на реальных данных?
Да.
А тесты, бенчмарки, результаты, этих проверок можно посмотреть?
Насколько крупные сайты? Просто есть сомнения…
+ еще один уровень защиты: поисковые боты тоже идут лесом, так что те, кто мог бы заDDoSить ваш сайт, его даже не найдут :)
Поисковики уже неплохо ходят по js, css я думаю умеют еще раньше — как минимум для борьбы с «сеошниками».
для того и существует "Таблица, куда занесем ip поисковых ботов"
Интересное решение. А вы эти IP знаете? А то я могу не то что IP поисковых ботов, даже поисковики-то перечислить — ну может 1% самых популярных назову, а уж знать адреса спайдеров каждого, да при том что они еще и меняются со временем.
Мне кажется, это лукавое решение — с одной стороны оно вроде как и есть, и решает проблему, а с другой, в реальности, нормально им воспользоваться невозможно, потому что невозможно правильно заполнить эту табличку. Но это уже «тактический вопрос, а не стратегия».
Мне кажется, это лукавое решение — с одной стороны оно вроде как и есть, и решает проблему, а с другой, в реальности, нормально им воспользоваться невозможно, потому что невозможно правильно заполнить эту табличку. Но это уже «тактический вопрос, а не стратегия».
Поддерживать эту таблицу в актуальном состоянии не так-то просто, а цена ошибки высока.
Я у себя дополнительно проверяю hostname всех кандидатов на забан. Казалось бы, кто будет менять домен у имен хостов ботов? Но этим летом Яндекс, например, стал ходить с yandex.net и yandex.com, а до этого всю жизнь ходил только с yandex.ru. В итоге сайт почти полностью вылетел из индекса и обратно заходил почти месяц.
Я у себя дополнительно проверяю hostname всех кандидатов на забан. Казалось бы, кто будет менять домен у имен хостов ботов? Но этим летом Яндекс, например, стал ходить с yandex.net и yandex.com, а до этого всю жизнь ходил только с yandex.ru. В итоге сайт почти полностью вылетел из индекса и обратно заходил почти месяц.
Поисковые боты, зайдя на страницу поиска, получат её.
Блокируется (а можно и заменять заглушкой с пустым списком результатов) дальнейший переход — дорогостоящая операция поиска, если со страницы с формой поискового запроса не подгружен файл.
Маловероятно, что поисковик будет пользоваться формой поиска на сайте
Блокируется (а можно и заменять заглушкой с пустым списком результатов) дальнейший переход — дорогостоящая операция поиска, если со страницы с формой поискового запроса не подгружен файл.
Маловероятно, что поисковик будет пользоваться формой поиска на сайте
Пара замечаний
1) mysql тут избыточен, время на эстеблишь коннекта лишнее.
2) Для чего `remote_addr` varchar(20) NOT NULL DEFAULT '0', неясно, при том что Вы знаете что надо `remote_addr` bigint(20) NOT NULL,
3) Очень часто боты идут из одной подсети, лучше иметь возможность отсекать по маске если таковая образуется, чем по ИП отдельно, будет быстрее и понятнее.
4) Яндекс и гугл не жалко? Они конечно тоже боты, но полезные.
5) Что случится если траффик идет через какой-нибудь промежуточный сервер кэширования (как модно у сотовых операторов и прочих), в котором картинка эта закэшироваться может несмотря на параметры?
1) mysql тут избыточен, время на эстеблишь коннекта лишнее.
2) Для чего `remote_addr` varchar(20) NOT NULL DEFAULT '0', неясно, при том что Вы знаете что надо `remote_addr` bigint(20) NOT NULL,
3) Очень часто боты идут из одной подсети, лучше иметь возможность отсекать по маске если таковая образуется, чем по ИП отдельно, будет быстрее и понятнее.
4) Яндекс и гугл не жалко? Они конечно тоже боты, но полезные.
5) Что случится если траффик идет через какой-нибудь промежуточный сервер кэширования (как модно у сотовых операторов и прочих), в котором картинка эта закэшироваться может несмотря на параметры?
еще можно добавить что memory engine сильно подвержен фрагментации, и что использовать ram_drive не обязательно, т.к. в большинстве случаев часто используемые файлы и так переползут в оперативку. Ну и отбивать бы я не стал ботов через файрвол, а использую связку nginx+memcached, в таком случае бот долбится только статическую страницу с комментариями что он в бане и как исправить это.
А можно подробней про связку nginx+memcached? Я так понимаю, что PHP в отдаче странице для бота не участвует. Как?
Ну в качестве примера, отдача статики по ключу-URL запроса:
Взято, вырвав из контекста, но суть ясна.
location ~ ^/(.+)$ {
set $memcached_key "$1";
default_type "text/html; charset=utf-8";
memcached_pass 127.0.0.1:11211;
error_page 404 502 504 = @backend;
}
Взято, вырвав из контекста, но суть ясна.
1) Возможно, mysql — это лишь способ хранения, удобный для понимания в данном коде.
2) Предполагается, что данные вносятся через LOAD DATA с преобразованием. Насколько я понимаю bigint здесь не подойдёт.
4) Их не сложно занести в «белые»
5) На практике нет необходимости держать банилку постоянно, достаточно отслеживать начало ддоса и включать её только на его время. Но «потери», безусловно могут быть как и при большинстве других способах анализа.
2) Предполагается, что данные вносятся через LOAD DATA с преобразованием. Насколько я понимаю bigint здесь не подойдёт.
4) Их не сложно занести в «белые»
5) На практике нет необходимости держать банилку постоянно, достаточно отслеживать начало ддоса и включать её только на его время. Но «потери», безусловно могут быть как и при большинстве других способах анализа.
Для хранения IP адресов в mysql существуют 2 функции INET_ATON и INET_NTOA
А насколько распространены такие простые боты?
довольно распространены.
Кейс.
Сервер запущен в июле. все это время сайт крутился только Адвордсах.
В конце августа:
1. Попытки подобрать пароли по ssh из Китая.
2. Попытки определить движок Wordpress из США.
2.1. Попытки простучать файлы Wordpress на запись из США.
3. Попытки подставлять запросы к почтовым формам из США.
Кейс.
Сервер запущен в июле. все это время сайт крутился только Адвордсах.
В конце августа:
1. Попытки подобрать пароли по ssh из Китая.
2. Попытки определить движок Wordpress из США.
2.1. Попытки простучать файлы Wordpress на запись из США.
3. Попытки подставлять запросы к почтовым формам из США.
бот пытается спрашивать дюжину страничек или делает пару дюжин попыток логина.
никакой нагрузки подобное не создает и повторно, судя по всему, не возвращается.
в общем, подобной трафик есть практически у всех, но никто борьбой с ним не заморачивается ввиду бессмысленности занятия — такая «атака» ест ресурсов меньше, чем вы потратили бы на борьбу с ней.
никакой нагрузки подобное не создает и повторно, судя по всему, не возвращается.
в общем, подобной трафик есть практически у всех, но никто борьбой с ним не заморачивается ввиду бессмысленности занятия — такая «атака» ест ресурсов меньше, чем вы потратили бы на борьбу с ней.
На крупных сайтах довольно редки. Особенно если ддосят на заказ, а не просто ради шантажа — хотя и последние тоже на глазах «умнеют». Равернутый комент здесь.
на сегодняшний день таких ботов большинство, но прогрессируют они быстро, и всё больше походят на «честного» пользователя.
Думаю, что вполне.
Но, насколько я знаю, поисковый робот Google использует нечто вроде phantomjs.org/
К тому же в современных реалиях написать бота который будет использовать нечто реальное, типа Chromium или XUL Runner — дело пары дней, это со всеми тестами и GUI конфигуратором.
Но, насколько я знаю, поисковый робот Google использует нечто вроде phantomjs.org/
К тому же в современных реалиях написать бота который будет использовать нечто реальное, типа Chromium или XUL Runner — дело пары дней, это со всеми тестами и GUI конфигуратором.
Ничего не надо писать в принципе.
Мы так вирусы на сайтах декомпостируем.
Пишем прелоадер для spidermonkey или v8 с описаловом document/window и т.п. И пускаем на просто js файл, выдает все ошибки или результат.
Во вторых, хттп-боты если честно css не будут трогать. Их интересует главный сайт. А так кому хитрее надо поднимет ботов — автоматизацию браузера (такие давно уже есть), которые впустую будут нагружать систему и их никак не перебороть, кроме как увеличением мощности или интерактивности защиты.
Мы так вирусы на сайтах декомпостируем.
Пишем прелоадер для spidermonkey или v8 с описаловом document/window и т.п. И пускаем на просто js файл, выдает все ошибки или результат.
Во вторых, хттп-боты если честно css не будут трогать. Их интересует главный сайт. А так кому хитрее надо поднимет ботов — автоматизацию браузера (такие давно уже есть), которые впустую будут нагружать систему и их никак не перебороть, кроме как увеличением мощности или интерактивности защиты.
>Бот не умеет загружать вместе со страницей картинки, скрипты, css и пр.
Научить бота это делать — дело 10-ти строк кода
Научить бота это делать — дело 10-ти строк кода
И десятикратного увеличения трафика.
тем лучше для злоумышленника
А. Ему не обязательно получать к себе обратно.
Б. В наше время гигабит за 300 евро не чудь, поверьте Гигабит легитимного хттп траффика свалит что угодно.
Б. В наше время гигабит за 300 евро не чудь, поверьте Гигабит легитимного хттп траффика свалит что угодно.
поверьте Гигабит легитимного хттп траффика свалит что угодно
10 Гигабит в пике вчера, что я делаю не так? :)
отписываетесь о нестандартном решении?
А что такое стандартное решение? Это случаем не «пехапе + апач + муэскуэль»?
Обычные сайты для которых и подготовлен этот пост (явно).
К тому же 10 гигабит http запросов и 10 гигабит http закачек несколько разные вещи, согласитесь.
В первом случае мы говорим о миллионах rps, во втором может даже и 1 файл качает один клиент на хорошем канале.
К тому же 10 гигабит http запросов и 10 гигабит http закачек несколько разные вещи, согласитесь.
В первом случае мы говорим о миллионах rps, во втором может даже и 1 файл качает один клиент на хорошем канале.
Что такое обычные сайты? Это случаем не «пехапе + апач + муэскуэль»?
Про 10 гигабит запросов соглашусь, но только частично. Распарсить их конечно несколько сложнее, но загрузка CPU в таких случаях не является узким местом. А дальше зависит, что вебсервер будет делать с результатом парсинга, в случае «пехапэ» действительно будет не все красиво, да и скорость парсинга запросов уже мало на что влияет в таком случае. Если же вебсервер сам сформировал ответ в своем буфере и тут же начал отсылать ответ — не вижу большой разницы с раздачей статики. Конечно, с «большим файлом» не сравнить, тут как минимум будет просрано MTU и множество других нюансов, но разница не велика.
Про 10 гигабит запросов соглашусь, но только частично. Распарсить их конечно несколько сложнее, но загрузка CPU в таких случаях не является узким местом. А дальше зависит, что вебсервер будет делать с результатом парсинга, в случае «пехапэ» действительно будет не все красиво, да и скорость парсинга запросов уже мало на что влияет в таком случае. Если же вебсервер сам сформировал ответ в своем буфере и тут же начал отсылать ответ — не вижу большой разницы с раздачей статики. Конечно, с «большим файлом» не сравнить, тут как минимум будет просрано MTU и множество других нюансов, но разница не велика.
Погодите-погодите. Давайте разберемся с терминологией и смыслом.
Напомню, что разговор идет об этой вот интересной фразе:
Тоесть пока мы говорим о трафике.
Однако, чуть ниже вы пишете.
Вы каким-то образом разделяете закачки, которые происходят по http протоколу и сами запросы.
Тоесть вот такая-вот штука:
Это http запрос. но вот http ответ, который идет на этот запрос уже не учавствует в нашем обсуждении, верно?
Или это не http траффик? Почему по-вашему в http траффик входят только заголовки клиента?
Вы имели ввиду ситуацию, когда у меня одних хедеров от клиентов 10 гигабит?
По-поводу решений, всё в общем-то просто. Не упираться в IO, балансировать нагрузку между серверами, мониторить, масштабировать по мере необходимости.
Напомню, что разговор идет об этой вот интересной фразе:
Гигабит легитимного хттп траффика свалит что угодно
Тоесть пока мы говорим о трафике.
Однако, чуть ниже вы пишете.
К тому же 10 гигабит http запросов и 10 гигабит http закачек несколько разные вещи, согласитесь.
Вы каким-то образом разделяете закачки, которые происходят по http протоколу и сами запросы.
Тоесть вот такая-вот штука:
GET /testFile.pngi HTTP/1.0
Host: test.com
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98)
Referer: http://habrahabr.ru/
Это http запрос. но вот http ответ, который идет на этот запрос уже не учавствует в нашем обсуждении, верно?
Или это не http траффик? Почему по-вашему в http траффик входят только заголовки клиента?
Вы имели ввиду ситуацию, когда у меня одних хедеров от клиентов 10 гигабит?
По-поводу решений, всё в общем-то просто. Не упираться в IO, балансировать нагрузку между серверами, мониторить, масштабировать по мере необходимости.
А зачем вы логгируете загрузку статики?
Ваш сервис быстрее ляжет от копирования логов туда-сюда вашим скриптом, нежели от чего бы то ни было другого.
А если я зайду на ваш сайт с elinks, меня забанят?
Или если я скачаю файл с вашего сайта при помощи wget?
Или если я скачаю файл с вашего сайта при помощи wget?
Думаю всё же ддос подразумевает частоту одинаковых по маске запросов.
Ваш сайт имеет тьму посетителей предпочитающих пользоваться links? На войне приходится чем-то жертвовать.
Пытался я однажды скачать свежую жабу на боевой сервер. Канал у меня никакой, так что качать можно было только сервера, а там, знаете ли, браузеров с Js'ами и css'ами нету.
И что вы думаете? Так и не получилось скачать из-за этих новомодных защит от ботов-ддосов и от тех, кто не принял лицензионное соглашение. Маразм? Маразм.
Вывод: чем проще и надежнее, тем лучше, тем меньше возникает неудобных ситуаций. Не сколько тут проблема в консольных браузерах и качалках, сколько в других малоочевидных последствиях.
И что вы думаете? Так и не получилось скачать из-за этих новомодных защит от ботов-ддосов и от тех, кто не принял лицензионное соглашение. Маразм? Маразм.
Вывод: чем проще и надежнее, тем лучше, тем меньше возникает неудобных ситуаций. Не сколько тут проблема в консольных браузерах и качалках, сколько в других малоочевидных последствиях.
1. Подобные методы защиты НЕ должны действовать постоянно. Они включаются при превышении определённых лимитов, т.е. доступ будет несколько ограничен лишь на время DDoS'a.
2. Вам было бы легче если бы Вы не скачали жабу от того что сервер лёг по DDoS'ом и доступа бы не было у всех?
Всё это лишь один из методов определения бота и отчленения его на время ддоса, а не предложение постоянно отсеивать links :)
2. Вам было бы легче если бы Вы не скачали жабу от того что сервер лёг по DDoS'ом и доступа бы не было у всех?
Всё это лишь один из методов определения бота и отчленения его на время ддоса, а не предложение постоянно отсеивать links :)
За что минусуем то — тут человек прав: ддос защиту включают в боевом режиме как правило только когда мониторинг системы словил server down, как раз чтобы избежать таких ситуаций, когда невинные посетители страдают.
И второе — если канал забит наглухо, никакой самый супер-пупер анализатор на сайте не поможет, только провайдер+железо.
И второе — если канал забит наглухо, никакой самый супер-пупер анализатор на сайте не поможет, только провайдер+железо.
А вы помните то как Вконтакте ботил фирму по разгадыванию капчи? Через ваш браузер.
А вы знаете, что есть боты работающие на браузерных движках?
А как насчёт бота на ядре node.js?
А вы знаете, что есть боты работающие на браузерных движках?
А как насчёт бота на ядре node.js?
причем здесь node.js? :)
На node.js можно симулировать работу javascriptа также, как и в браузере. Вы можете получить точно такой-же код, как и браузер.
ой ли? phantomjs слышал, caperjs слышал, но вот чтобы взять nodejs и на нем сэмулировать работу JS «также, как и в браузере» — не слышал.
Я рад, что вы знаете больше решений чем я. Расскажите нам о них, может я чем-то не прав, да с удовольствием послушаю.
а я не рад, что вы(как и топикстартер) с умным видном рассуждаете о том, о чем имеете лишь удаленное представление.
А я не рад, что вы стебётесь уходя от вопроса.
Чем github.com/tmpvar/jsdom плох?
Чем github.com/tmpvar/jsdom плох?
Бот не умеет загружать вместе со страницей картинки, скрипты, css и пр. Значит в логе будет отображен запрос к /search/ и всё.«Расследуя» множество ддос-атак, могу с уверенностью заявить, что вы здесь не правы! По многим причинам:
1а) Современные боты — это почти парзеры-спайдеры, т.е. используя движок браузера (свой или IE аля Com, неважно) страница парзится полностью как бы это сделал сам браузер, выдергиваются ссылки (которые потом тоже посещаются) и т.д.
1б) XSS и подобные ддосы (тоже бывают) ведут себя как браузер — потому что браузер и есть. Т.е. на многопосещаемом взломаном сайте, в hidden frame где-то бегают запросы к ддосируемому сайту. Правда иногда такое ловится по referer — но к сожалению далеко не всегда.
2) Вы забыли про cache браузера. Он тоже не полезет за всем этим барахлом, в лучшем случае 304, IfModifiedSince только при первой сессии и т.д.
Короче, у нас есть свой DDosAnalyser — так для него, как раз признаком доса будет то, что картинка, css, js, короче одинаковая кешируемая статика, забирается многократно (допущение — мы исключаем идиотов, во время ддоса постоянно тыкающих Ctrl+F5).
3)… Нет это тема отдельной статьи — если интересно накропаю, как это делают большие мальчики.
, у нас есть свой DDosAnalyser — так для него, как раз признаком доса будет то, что картинка, css, js, короче одинаковая кешируемая статика, забирается
Вот это супер критерий!
PS: Только зря сюда написали — они (боты) и кэшировать начнут :(
Хорошо — одним из признаков… :)
Большинство критериев легки для определения. Просто нынче автоматизация браузеров достаточно проста.
Ботописателям проще поднять впску на 100 мбитных каналах и врубить браузеры в нескольких x сессиях для открытия страниц с рефрешем каждые 2 минуты. Хотя с впсок не досят.
Скорее у пользователей скрытый процесс браузера подгружает сайт в бэке (или в каждую страницу скрытым прокси на хттп подставляется img/iframe с сурсом на сайт, такие очень распространены сейчас и режутся удалением левых рефераллов).
И Ботописатели в основном тупы и не знают ни протокола, ни способа работы с конкретным сайтом.
По сути им бы записать проксей несколько запросов с нормального браузера и наваять за пять минут бота тупо флудя сервер такими запросами. И это уже сложнее отбивать.
Когда вот такое надо отбивать, приходите к нам :).
Ботописателям проще поднять впску на 100 мбитных каналах и врубить браузеры в нескольких x сессиях для открытия страниц с рефрешем каждые 2 минуты. Хотя с впсок не досят.
Скорее у пользователей скрытый процесс браузера подгружает сайт в бэке (или в каждую страницу скрытым прокси на хттп подставляется img/iframe с сурсом на сайт, такие очень распространены сейчас и режутся удалением левых рефераллов).
И Ботописатели в основном тупы и не знают ни протокола, ни способа работы с конкретным сайтом.
По сути им бы записать проксей несколько запросов с нормального браузера и наваять за пять минут бота тупо флудя сервер такими запросами. И это уже сложнее отбивать.
Когда вот такое надо отбивать, приходите к нам :).
3) Накропайте пожалуйста, очень интересна тема
Всего три дня назад (10 сентября 2012 года) блоггер Skaurus опубликовал блогозапись «Улучшение субъективной скорости работы сайта при помощи подсказок браузеру», в которой, в частности, рекомендовал указывать Файерфоксу на необходимость заблаговременной подкачки страниц, по которым читатель с большою вероятностью перейдёт (а Firefox подкачивает такие страницы без изображений).
Похоже, что Вы забаните Firefox такого своего читателя, который придёт с другого сайта, использующего предзагрузку гиперссылок. (Например, с сайта поиска Google.)
Похоже, что Вы забаните Firefox такого своего читателя, который придёт с другого сайта, использующего предзагрузку гиперссылок. (Например, с сайта поиска Google.)
очередной костыль :(
Ох, меня не только заминусуют, но теперь еще и забанят за использование браузера без CSS и картинок.
странная защита от DDoS с помощью MySQL…
Выскажу свое мнение. Я бы побоялся пользоваться вашими услугами после такой статьи, позвольте объяснить почему:
1) Использование MySQL(!), которая часто и так является бутылочным горлышком производительности веб приложений.
1b) LOAD DATA для логов, парсинг этого дела… да еще и при DDoS (при парсинге по интервалам, лог будет больше обычного)? Какой перерасход ресурсов, не находите?
2) Абсолютная неподготовленность к ботам, которые работают на браузерных движках.
2b) Если такие боты слишком круты для этой статьи, то мне ничего не мешает написать скрипт который будет дергать все данные на странице, получать 5 байт и отваливаться, в лог запишется, защита пройдена.
3) Плохой сценарий работы с реальными клиентами, не учтены кеширующие прокси, кеши браузера (всех браузеров), итд.
4) К сожалению, в случае использования мултифронтендов логи придется собирать по ним, что также не учтено.
Что я бы предпочел вместо всего этого огорода, да и работающее на фронтенд серверах, без баз данных и прочего — это простые счетчики запросов, и несколько основных критериев подозрения:
1) Слишком много запросов (Abnormal)
2) уникальные счетчики запросов для каждого IP со списками лимитов на действия за период времени, таким образом в случае повторного поиска, пользователя случайно не забанят.
3) чтобы счетчики работали лучше и не были подвержены атаке на несуществующие URL — брать только элементы URL через компилированный regex для скорости.
Как-то так, но всеже мне это видится более перспективным.
1) Использование MySQL(!), которая часто и так является бутылочным горлышком производительности веб приложений.
1b) LOAD DATA для логов, парсинг этого дела… да еще и при DDoS (при парсинге по интервалам, лог будет больше обычного)? Какой перерасход ресурсов, не находите?
2) Абсолютная неподготовленность к ботам, которые работают на браузерных движках.
2b) Если такие боты слишком круты для этой статьи, то мне ничего не мешает написать скрипт который будет дергать все данные на странице, получать 5 байт и отваливаться, в лог запишется, защита пройдена.
3) Плохой сценарий работы с реальными клиентами, не учтены кеширующие прокси, кеши браузера (всех браузеров), итд.
4) К сожалению, в случае использования мултифронтендов логи придется собирать по ним, что также не учтено.
Что я бы предпочел вместо всего этого огорода, да и работающее на фронтенд серверах, без баз данных и прочего — это простые счетчики запросов, и несколько основных критериев подозрения:
1) Слишком много запросов (Abnormal)
2) уникальные счетчики запросов для каждого IP со списками лимитов на действия за период времени, таким образом в случае повторного поиска, пользователя случайно не забанят.
3) чтобы счетчики работали лучше и не были подвержены атаке на несуществующие URL — брать только элементы URL через компилированный regex для скорости.
Как-то так, но всеже мне это видится более перспективным.
давайте по пунктам:
pre: данное решение и не позиционируется как коммерческое предложение и не рассматривается как фронтенд-защита, это простое решение непростых проблем для конечного держателя сайта.
1) habrahabr.ru/post/151420/#comment_5135474 — пункт 1, при этом я не открещиваюсь от mysql как от способа хранения логов в более глобальном масштабе. Если одни и те же логи используются для дерганья различных статистических данных вне работы данного скрипта, то mysql скорее ведро чем бутылка.
1б) в контексте MySQL(если не уходим от него) чем не угодил LOAD DATA?
2) об этом сказано в 1-м предложении статьи )
2б) если задаться целью написать ботнет под конкретный сайт, то можно обойти любой способ защиты, по крайней мере на несколько часов… это уже холивар ни о чём…
3) да, не универсален. Об этом также уже сказано — не надо использовать защиту постоянно, включайте только по событию.
4) а что мешает повесить скрипт на фронтенде? Зачем собирать логи на бакенде, чтобы банить ботов на фронетндах?
1) самое популярное и уже далеко не самое лучшее решение, от которого, естественно, я не призываю отказываться
2) хороший метод, но не годится только для сайта который заблаговременно собрал информацию.
3 и перспектива) Мы не отвергаем другие способы, мы лишь предложили простейшее приложение к другим способам защиты для владельцев сайтов.
pre: данное решение и не позиционируется как коммерческое предложение и не рассматривается как фронтенд-защита, это простое решение непростых проблем для конечного держателя сайта.
1) habrahabr.ru/post/151420/#comment_5135474 — пункт 1, при этом я не открещиваюсь от mysql как от способа хранения логов в более глобальном масштабе. Если одни и те же логи используются для дерганья различных статистических данных вне работы данного скрипта, то mysql скорее ведро чем бутылка.
1б) в контексте MySQL(если не уходим от него) чем не угодил LOAD DATA?
2) об этом сказано в 1-м предложении статьи )
2б) если задаться целью написать ботнет под конкретный сайт, то можно обойти любой способ защиты, по крайней мере на несколько часов… это уже холивар ни о чём…
3) да, не универсален. Об этом также уже сказано — не надо использовать защиту постоянно, включайте только по событию.
4) а что мешает повесить скрипт на фронтенде? Зачем собирать логи на бакенде, чтобы банить ботов на фронетндах?
1) самое популярное и уже далеко не самое лучшее решение, от которого, естественно, я не призываю отказываться
2) хороший метод, но не годится только для сайта который заблаговременно собрал информацию.
3 и перспектива) Мы не отвергаем другие способы, мы лишь предложили простейшее приложение к другим способам защиты для владельцев сайтов.
Моё мнение, что будучи на профильном сайте, где столько хороших и сильных IT специалистов можно не стесняться в терминах и сразу использовать то, что считаете нужным, дабы потом не оправдывать свои действия фразами в стиле «Использовал чтобы на простом (и не очень эффективном) примере показать». Я не притесняю тех, кто только начал свой путь в IT, но в данном вопросе я и не думаю что это удел новичков бороться с DDoS атаками.
Да и если на то пошло, это как раз те, кто изучают и хотят научиться должны расти, а не мы — называющие себя «профессионалами» упрощать контент в угоду массам, если нет задачи распиариться.
Да и если на то пошло, это как раз те, кто изучают и хотят научиться должны расти, а не мы — называющие себя «профессионалами» упрощать контент в угоду массам, если нет задачи распиариться.
Борьба с ботами, подобна борьбе с ветряными мельницами. Думаю что самая лучшая защита, это кеширование контента.
Я так понимаю судя по сайту кто-то решил протестировать ваши защиты и сайт по ддосом? DDoSExpert.ru
nginx+lua+redis, например, быстрее раз в ~20-40 работает, чем такая связка.
кстати, если уж зашла речь про подобные штуки, удобней varnish, плюс в конфиг написать фукнцию бана с использованием redis или memcached. Почему варниш? В нём конфиг компилируется, а не интерпретируется. Итоговый вариант может работать достаточно резво, если у вас хороший программист. (кроме того, варниш пишет логи в память в кольцевой буфер, что освобождает от необходимости делать tmpfs).
Учитывая размер ботнета зашедшего «на огонек» к Habrahabr.
А так-же интенсивность запров: на графике любой отброшенный SYN пакет пришедший с ip принадлежащего к ботнету можно классифицировать как неудавшийся запрос.
В такой ситуации перспективы использования предлагаемой конструкции на php/mysql выглядят весьма прохладными.
А наивность авторов вызывает широченную улыбку.
Ну и следующий вопрос — а зачем так сложно, если схожих результатов можно добиться просто используя nginx с набором локаций, директивой limit_req и shell script? Без php/mysql/блэкджека/этихсамых?
Ну и чтобы не критиканствовать пустословно не предлагая альтернатив заметки на полях как сваривать правильно:
1. Linux kernel 3.3
2. Вменяемая сетевая карта с несколькими очередями и обработчики очередей развешенные по разным ядрам.
3. ipset в -t RAW
4. включенные syncookies
5. выключенный коннтрэк.
6. наколеночный классификатор на модуле от Kyprizel
7. ????
8. Fortius, altius, citius!
P.S. И эти люди запрещают ковыряться нам в носу! ;)
1. Linux kernel 3.3
2. Вменяемая сетевая карта с несколькими очередями и обработчики очередей развешенные по разным ядрам.
3. ipset в -t RAW
4. включенные syncookies
5. выключенный коннтрэк.
6. наколеночный классификатор на модуле от Kyprizel
7. ????
8. Fortius, altius, citius!
P.S. И эти люди запрещают ковыряться нам в носу! ;)
Почему-то от Вас нет ни одной хорошей статьи по защите от HTTP DDoS. Только наброски на полях.
Примерно 17-20 сентября мы выложим на хабр подробное руководство, как сделать защиту от 100% HTTP DDoS атак (не через ddoshook, эту фичу мы только на днях придумали).
И Вы то уж в курсе, что мы 3 года в яндексе на первых позициях и представление, какие сейчас ботнеты у нас очень хорошее.
Так что минусуйте нам карму, пока не поздно :)
Примерно 17-20 сентября мы выложим на хабр подробное руководство, как сделать защиту от 100% HTTP DDoS атак (не через ddoshook, эту фичу мы только на днях придумали).
И Вы то уж в курсе, что мы 3 года в яндексе на первых позициях и представление, какие сейчас ботнеты у нас очень хорошее.
Так что минусуйте нам карму, пока не поздно :)
Я понятия не имею на каких мы позициях в Яндексе, и нас не интересует где там вы. Мы занимаемся не SEO, а своим узко специальным делом. «Как святой Франциск, мотыжим свой участок.»
Статьи писать это хорошо и полезно. Полезней статей только мастерклассы и презентации.
Вы видимо плохо изучали предмет.
В отличие от Вас, Мы пишем и выступаем достаточно часто.
Любая статья должна иметь какую-то Цель. В 2009м когда мы писали о наколенке мы хотели предоставить инструмент для противодействия простым атакам, четко указав верхнее ограничение для предлагаемого решения и возможные негативные эффекты. С Целью отсечь обращения с тривиальными случаями и сконцентрироваться на наиболее интересных случаях.
Какие цели преследуете вы?
Cобрать с людей по 5$ за ничего?
Ну и «качество» ваших советов просто фантасмагорическое.
P.S. Я просто оставлю эту картинку здесь, знающие люди поймут.
Статьи писать это хорошо и полезно. Полезней статей только мастерклассы и презентации.
Вы видимо плохо изучали предмет.
В отличие от Вас, Мы пишем и выступаем достаточно часто.
Любая статья должна иметь какую-то Цель. В 2009м когда мы писали о наколенке мы хотели предоставить инструмент для противодействия простым атакам, четко указав верхнее ограничение для предлагаемого решения и возможные негативные эффекты. С Целью отсечь обращения с тривиальными случаями и сконцентрироваться на наиболее интересных случаях.
Какие цели преследуете вы?
Cобрать с людей по 5$ за ничего?
Ну и «качество» ваших советов просто фантасмагорическое.
P.S. Я просто оставлю эту картинку здесь, знающие люди поймут.
Цель всего, что делаете Вы — получить клиента, который заплатит деньги за Ваши тайные методы защиты.
Может уже хватит делать из мух слонов, т.е. из дятловидных атак — нечто непостижимое и сложное?
Может уже хватит делать из мух слонов, т.е. из дятловидных атак — нечто непостижимое и сложное?
HTTP DDoS — это ботнеты от школьников на пехапе? Я не хочу никого обижать, но гораздо интереснее когда тебе прилетает более гигабита udp-мусора на интерфейс. Особенно интересно посмотреть, как логить такие запросы на пехапе и муэскуэл.
Про UDP они написали в соседней теме habrahabr.ru/post/151411/
449 человек добавило этот пост в избранное.
А-бал-деть.
А-бал-деть.
от ботов за 5$ только и защитит…
Спасибо за минусовую карму, теперь статью не отредактировать. Хотел дописать «Описанное в статье решение является экспериментальным. Используйте на свой страх и риск»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Простой способ защиты от классического HTTP DDoS