Вот с одной стороны Ваш комментарий, с другой успешная практика использования этой и других методик в течение нескольких последних лет. По Вашему, я должен поверить что Вы — мега-спец (кстати, а где пруф? Ваш коллега так и вовсе программист на php, а Вы даже ни одной статьи не написали), и тогда я должен признать что весь наш опыт борьбы с ddos — это результат случайного везения. Но очевидно, что на одном везении с ddos не поборешься, отсюда возникают вопросы в Ваш адрес, уж извините.
В алгоритме построения защиты ошибки есть только если строить атаку очень специализированным образом, атакуя именно слабые места алгоритма. Для этого нужно знать какой именно алгоритм применяется, а атакующий этого не знает. Против типового http flood ddos эта методика работает и глупо отрицать очевидное.
Выпады в адрес того, что fail2ban быстрее чем awk, либо что можно писать отдельно логи — это, знаете те ли, не ошибки. Ошибки — это когда что-то делается не правильно. А когда что-то делается и в результате все работает, это не может быть ошибкой, это может быть лишь не эффективной реализацией. Но и это спорно, потому что никто не привел цифр, которые бы с разгромным счетом показали растрату ресурсов сервера нашим методом против какого-то иного, все голосновно.
Кстати, установка порога посещаемости по $host всего лишь ограничивает кол-во хитов в минуту на один сайт. Это в принципе полезно делать, когда сайтов на сервере несколько, чтобы атака на один из сайтов не положила вообще всё.
Первая же серия из 3000 запросов от бота положит сайт на 1 минуту. Через 5 минут этот бот будет навечно забанен на firewall. Вот если вся атака будет строиться на том, что каждый бот (и только один одновременно) будет делать 3000 запросов и замолкать на минуту, тогда да, тогда эта методика не сработает. Но вот я не видел атак с таким паттерном ни разу, а всего разных атак мы видели множество.
И против такого паттерна можно еще проще написать защиту, тут даже nginx не понадобится. Достаточно в firewall считать кол-во коннектов в минуту с ip и банить тех, кто в минуту делает больше 120 коннектов, например.
Почему же часть хороших пользователей попадет в вечный бан? Во-первых, для того, чтобы воспользоваться Вашим методом атакующему нужно точно знать методику защиты. Очевидно что заранее он ее знать не будет никаким образом. Во-вторых, даже в такой ситуации «хорошие» пользователи в бан не попадут. В-третьих, на то у сервера и должен быть админ, чтобы такие ситуации мог вычислить по логам, если методика защиты от атаки не работает.
Никто же не говорит что здесь описана серебрянная пуля. Это всего лишь одна из методик. Она не безгрешна, но она реально работает.
Я представляю что он напишет, с учетом того, что он даже не понял о чем идет речь тут. Он своими словами попытался описать суть и написал полную ахинею, не имеющую ничего общего с методикой, описанной в статье.
Похоже вся проблема сводится к тому, что Вы ничего не поняли, а сразу бросились критиковать. Методика, на которой строится статья, сводится к следующему:
1. У любого сайта есть порог посещаемости, свыше которой он не тянет. В данном случае он установлен в 1500 хитов в минуту, хотя это индивидуально и понятно как настраивается. Когда на сайт налетает постоянная высокая посещаемость, то очевидно выше этого порога сайт начинает всем выдавать ошибки. Здесь, установив в nginx порог по посещаемости, те, кто создаст первые 1500 хитов, увидят именно сайт, а не ошибки. Далее все, кто пришел после 1500 хитов, начинают получать ошибку от nginx и их ip пишется в логи. Пока что всё просто: пока сайт тянет, он работает, дальше мы принудительно отключаем поток входящих запросов.
2. По прошествии 5-15 минут у нас уже есть пачка записей в логах о том, что кто-то был зафильтрован nginx'ом. Боты, в отличие от людей, долбятся постоянно, поэтому всегда можно найти тот самый THRESHOLD, выше которого кол-во банов в логе nginx будет означать, что это постоянно долбящийся бот, а ниже которого — человек.
3. Всех, кого мы идентифицировали как ботов, мы баним на firewall и с этого момента запросы от них поступать перестают. Ботнет в пару тысяч адресов вычисляется и попадает в бан менее чем за час при этой методике. При этом весь час сайт продолжает работать, но какая-то часть посетителей сайта не увидит, а увидит ошибку, увы.
На случай ложных срабатываний введен whitelist
Поэтому Ваши выпады в адрес статьи строятся на том, что Вы методику просто не поняли, Вы докапываетесь до деталей не понимая сути того, зачем они здесь.
В пункте (1) Вы ошибаетесь. Во-первых, сайт «висит» только до конца этой минуты, а потом работает снова. Во-вторых, в любом случае более 1500 (подставьте свое значение) хитов в минуту сайт все равно упадет, но только не до конца минуты, а вообще.
В пункте (2) Вы ошибаетесь еще больше. Допустим, поисковый робот делает 900 запросов за 15 минут. Кто сказал, что все 900 запросов попадут в отлуп на nginx? 900 запросов за 15 минут это 60 запросов в минуту (1 запрос в секунду). Сколько из них получат ошибку зависит от интенсивности атаки, но точно не 100%. Кроме того, понятно же что роботы ходят с одних и тех же сетей. Соберите статистику по этим сетям заранее и обновляйте списки сетей поисковиков. Что тут сложного? Ничего.
Лично я, как частное лицо, считаю что достаточно пускать на сайт роботов Яндекса и, может еще Гугля. Сети Я. и Г. выделить очень просто. Остальных на время ddos, а это обычно пара дней, можно просто не пускать, ничего страшного не случится. Ну это в общем случае.
Наша идея в том, чтобы предоставить инструмент для защиты, а не комплексное решение. Комплексные решения на рынке много кто предлагает за деньги, welcome.
На основании чего Вы делаете вывод, что я «не в теме»? Я говорю глядя на предлагаемый Вами конфиг, в нем упоминания другого лога нет, только одного.
Несколько процентов я называю исходя из того, что запуск раз в 5 минут связки awk/sort/uniq никак не может по потреблению ресурсов быть сопоставим с работой движка сайта. Возможно Ваш метод в 10 раз меньше ресурсов потребит, но в целом это будет 1% или 0,1%. А идея заключается в том, чтобы сервер не тащил на себе нагрузку от ddos, а очень быстро с ней справился.
Где-то пол года назад здесь же на Хабре была статья от highloadlab, они советовали аналогичную методику, но несколько иную. Они тоже не умеют с ddos бороться?
Выпады в адрес того, что fail2ban быстрее чем awk, либо что можно писать отдельно логи — это, знаете те ли, не ошибки. Ошибки — это когда что-то делается не правильно. А когда что-то делается и в результате все работает, это не может быть ошибкой, это может быть лишь не эффективной реализацией. Но и это спорно, потому что никто не привел цифр, которые бы с разгромным счетом показали растрату ресурсов сервера нашим методом против какого-то иного, все голосновно.
И против такого паттерна можно еще проще написать защиту, тут даже nginx не понадобится. Достаточно в firewall считать кол-во коннектов в минуту с ip и банить тех, кто в минуту делает больше 120 коннектов, например.
Никто же не говорит что здесь описана серебрянная пуля. Это всего лишь одна из методик. Она не безгрешна, но она реально работает.
1. У любого сайта есть порог посещаемости, свыше которой он не тянет. В данном случае он установлен в 1500 хитов в минуту, хотя это индивидуально и понятно как настраивается. Когда на сайт налетает постоянная высокая посещаемость, то очевидно выше этого порога сайт начинает всем выдавать ошибки. Здесь, установив в nginx порог по посещаемости, те, кто создаст первые 1500 хитов, увидят именно сайт, а не ошибки. Далее все, кто пришел после 1500 хитов, начинают получать ошибку от nginx и их ip пишется в логи. Пока что всё просто: пока сайт тянет, он работает, дальше мы принудительно отключаем поток входящих запросов.
2. По прошествии 5-15 минут у нас уже есть пачка записей в логах о том, что кто-то был зафильтрован nginx'ом. Боты, в отличие от людей, долбятся постоянно, поэтому всегда можно найти тот самый THRESHOLD, выше которого кол-во банов в логе nginx будет означать, что это постоянно долбящийся бот, а ниже которого — человек.
3. Всех, кого мы идентифицировали как ботов, мы баним на firewall и с этого момента запросы от них поступать перестают. Ботнет в пару тысяч адресов вычисляется и попадает в бан менее чем за час при этой методике. При этом весь час сайт продолжает работать, но какая-то часть посетителей сайта не увидит, а увидит ошибку, увы.
На случай ложных срабатываний введен whitelist
Поэтому Ваши выпады в адрес статьи строятся на том, что Вы методику просто не поняли, Вы докапываетесь до деталей не понимая сути того, зачем они здесь.
В пункте (1) Вы ошибаетесь. Во-первых, сайт «висит» только до конца этой минуты, а потом работает снова. Во-вторых, в любом случае более 1500 (подставьте свое значение) хитов в минуту сайт все равно упадет, но только не до конца минуты, а вообще.
В пункте (2) Вы ошибаетесь еще больше. Допустим, поисковый робот делает 900 запросов за 15 минут. Кто сказал, что все 900 запросов попадут в отлуп на nginx? 900 запросов за 15 минут это 60 запросов в минуту (1 запрос в секунду). Сколько из них получат ошибку зависит от интенсивности атаки, но точно не 100%. Кроме того, понятно же что роботы ходят с одних и тех же сетей. Соберите статистику по этим сетям заранее и обновляйте списки сетей поисковиков. Что тут сложного? Ничего.
Наша идея в том, чтобы предоставить инструмент для защиты, а не комплексное решение. Комплексные решения на рынке много кто предлагает за деньги, welcome.
Никто не говорит, что все описанные в статье действия нужно делать в момент, когда атака уже началась. Все whitelist и прочее надо готовить заранее
-A INPUT -m set --match-set ddos src -j DROPНесколько процентов я называю исходя из того, что запуск раз в 5 минут связки awk/sort/uniq никак не может по потреблению ресурсов быть сопоставим с работой движка сайта. Возможно Ваш метод в 10 раз меньше ресурсов потребит, но в целом это будет 1% или 0,1%. А идея заключается в том, чтобы сервер не тащил на себе нагрузку от ddos, а очень быстро с ней справился.