Спасибо за минусовую карму, теперь статью не отредактировать. Хотел дописать «Описанное в статье решение является экспериментальным. Используйте на свой страх и риск»
Цель всего, что делаете Вы — получить клиента, который заплатит деньги за Ваши тайные методы защиты.
Может уже хватит делать из мух слонов, т.е. из дятловидных атак — нечто непостижимое и сложное?
Почему-то от Вас нет ни одной хорошей статьи по защите от HTTP DDoS. Только наброски на полях.
Примерно 17-20 сентября мы выложим на хабр подробное руководство, как сделать защиту от 100% HTTP DDoS атак (не через ddoshook, эту фичу мы только на днях придумали).
И Вы то уж в курсе, что мы 3 года в яндексе на первых позициях и представление, какие сейчас ботнеты у нас очень хорошее.
Так что минусуйте нам карму, пока не поздно :)
'LOAD DATA CONCURRENT INFILE "'.$tmp.'" IGNORE INTO TABLE '.$table.' FIELDS TERMINATED BY \'\t\' (`remote_addr`, `time_local`, `status`) SET `remote_addr` = INET_ATON(`remote_addr`)'
давайте по пунктам:
pre: данное решение и не позиционируется как коммерческое предложение и не рассматривается как фронтенд-защита, это простое решение непростых проблем для конечного держателя сайта.
1) habrahabr.ru/post/151420/#comment_5135474 — пункт 1, при этом я не открещиваюсь от mysql как от способа хранения логов в более глобальном масштабе. Если одни и те же логи используются для дерганья различных статистических данных вне работы данного скрипта, то mysql скорее ведро чем бутылка.
1б) в контексте MySQL(если не уходим от него) чем не угодил LOAD DATA?
2) об этом сказано в 1-м предложении статьи )
2б) если задаться целью написать ботнет под конкретный сайт, то можно обойти любой способ защиты, по крайней мере на несколько часов… это уже холивар ни о чём…
3) да, не универсален. Об этом также уже сказано — не надо использовать защиту постоянно, включайте только по событию.
4) а что мешает повесить скрипт на фронтенде? Зачем собирать логи на бакенде, чтобы банить ботов на фронетндах?
1) самое популярное и уже далеко не самое лучшее решение, от которого, естественно, я не призываю отказываться
2) хороший метод, но не годится только для сайта который заблаговременно собрал информацию.
3 и перспектива) Мы не отвергаем другие способы, мы лишь предложили простейшее приложение к другим способам защиты для владельцев сайтов.
1. Подобные методы защиты НЕ должны действовать постоянно. Они включаются при превышении определённых лимитов, т.е. доступ будет несколько ограничен лишь на время DDoS'a.
2. Вам было бы легче если бы Вы не скачали жабу от того что сервер лёг по DDoS'ом и доступа бы не было у всех?
Всё это лишь один из методов определения бота и отчленения его на время ддоса, а не предложение постоянно отсеивать links :)
1) Возможно, mysql — это лишь способ хранения, удобный для понимания в данном коде.
2) Предполагается, что данные вносятся через LOAD DATA с преобразованием. Насколько я понимаю bigint здесь не подойдёт.
4) Их не сложно занести в «белые»
5) На практике нет необходимости держать банилку постоянно, достаточно отслеживать начало ддоса и включать её только на его время. Но «потери», безусловно могут быть как и при большинстве других способах анализа.
Может уже хватит делать из мух слонов, т.е. из дятловидных атак — нечто непостижимое и сложное?
Примерно 17-20 сентября мы выложим на хабр подробное руководство, как сделать защиту от 100% HTTP DDoS атак (не через ddoshook, эту фичу мы только на днях придумали).
И Вы то уж в курсе, что мы 3 года в яндексе на первых позициях и представление, какие сейчас ботнеты у нас очень хорошее.
Так что минусуйте нам карму, пока не поздно :)
pre: данное решение и не позиционируется как коммерческое предложение и не рассматривается как фронтенд-защита, это простое решение непростых проблем для конечного держателя сайта.
1) habrahabr.ru/post/151420/#comment_5135474 — пункт 1, при этом я не открещиваюсь от mysql как от способа хранения логов в более глобальном масштабе. Если одни и те же логи используются для дерганья различных статистических данных вне работы данного скрипта, то mysql скорее ведро чем бутылка.
1б) в контексте MySQL(если не уходим от него) чем не угодил LOAD DATA?
2) об этом сказано в 1-м предложении статьи )
2б) если задаться целью написать ботнет под конкретный сайт, то можно обойти любой способ защиты, по крайней мере на несколько часов… это уже холивар ни о чём…
3) да, не универсален. Об этом также уже сказано — не надо использовать защиту постоянно, включайте только по событию.
4) а что мешает повесить скрипт на фронтенде? Зачем собирать логи на бакенде, чтобы банить ботов на фронетндах?
1) самое популярное и уже далеко не самое лучшее решение, от которого, естественно, я не призываю отказываться
2) хороший метод, но не годится только для сайта который заблаговременно собрал информацию.
3 и перспектива) Мы не отвергаем другие способы, мы лишь предложили простейшее приложение к другим способам защиты для владельцев сайтов.
2. Вам было бы легче если бы Вы не скачали жабу от того что сервер лёг по DDoS'ом и доступа бы не было у всех?
Всё это лишь один из методов определения бота и отчленения его на время ддоса, а не предложение постоянно отсеивать links :)
2) Предполагается, что данные вносятся через LOAD DATA с преобразованием. Насколько я понимаю bigint здесь не подойдёт.
4) Их не сложно занести в «белые»
5) На практике нет необходимости держать банилку постоянно, достаточно отслеживать начало ддоса и включать её только на его время. Но «потери», безусловно могут быть как и при большинстве других способах анализа.