Pull to refresh

Comments 116

Очень интересно, но хотелось бы видеть отформатированные правила.
Вы правы, сейчас исправимся.
Все хорошо и интересно, правда по своему опыту борьбы с атаками пришел к выводу что все же бороться с ддосом нужно начинать не на уровне nginx, а раньше, на уровне iptables. Темболее что там есть весь необходимый для этого инструментарий. Тюнинг же nginx и php должен делаться просто под большую нагрузку и возможность держать как можно большее число прорвавшихся запросов.
Вышеперечисленный в статье функционал по отбитию аттак можно также реализовать при помощи таких инструментов как: limit, connlimit, ipset, geoip…
Я например как-то делал нечто похожее описанному в статье, только подозреваемых ботов я не наглухо блокировал а заносил в определенный ipset список, по которому ставилось ограничение по числу коннектов 1 в сек (серый список). В случае если он продолжал свою бурную деятельность, заносил уже в черный.
Все лимиты настраивал в обычных условиях с запасом в 20-30%, обычно жалоб небыло.
Статья отличная! Но скажу с другой колокольни и не холивара ради — как владелец бизнеса для себя выяснил, что пока идет DDoS и компания теряет деньги, в итоге эксперименты с самостоятельной настройкой защиты обходятся дороже, чем сразу обратиться к профильным компаниям по защите от DDoS.

Потратив время+нервы из-за лежащего сайта, и научившись защищаться от школьных атак своими силами, потом при серьезных атаках долго думали, что и их победим. В итоге — неделя нестабильно работающего сайта, потеря позиций в поисковиках, потеря сервера в Hetzner из-за того, что они отказались дальше его обслуживать.

Потом уже, с набитыми шишками, обратились в швейцарскую компанию по защите от DDoS. В отличие от нас, ситуацию исправили за 10 минут раз и навсегда. Дороговато, но это контролируемые и прогнозируемые расходы.
Не могли бы вы привести свой шортлист компаний, которым вы бы доверили такую работу? Занесу в избранное.
Сначала пытался обращаться к русским, но они грубили, тормозили с ответами, что никак не устраивало за ту цену, которую они выставляли.
Начал писать иностранцам, остановился на dragonara.net
Совершенно верно говорите. Подобный тюнинг сайтов нужен только для того, чтобы не отвлекаться на всякую мелочевку. Хотя, порой, можно добиться вполне неплохих результатов и своими силами.
При любом ддосе главное правило «устоять в начале любой ценой». Пусть сайт открывается через раз, тормозит, главное он должен работать. Эдакий психологический эффект, он демотивирует ддосеров.
Посему идеальный вариант своя защита рассчитанная на n коннектов + какой-то балансировщик, который переключает нагрузку на антиддос тоннель.
Безусловно, специализированные компании предоставляют за те деньги, что они просят, значительно более продвинутые методики защиты от DDoS, чем то, что описано в статье. Однако, статья все равно может быть полезна если DDoS не очень сильный, либо даже если приличный, чтобы что-то сделать на время пока Вы договариваетесь о защите сайта со специализированной компанией и перенаправляете на них свои А-записи в DNS. А это может занять несколько часов.
Манникс эту статью позаимствовал 6 марта (дата видна сверху), а UWDC-2012 прошла в конце февраля.
Устроим DDoS атаку на сервер mannix.ru в виде хабрэффекта, и узнаем читает ли администрация сайта материал который тырит ))
Тогда никаких претензий. Интересные товарищи, однако.
UFO just landed and posted this here
Спасибо, очень неплохая подборка методов. В мемориз, однозначно.
Статья ниочём! Бред полный, это не защита от DDOS атак, а самоубийство своего сайта/сервера. Не дай бог кому-то так свой сервер настроить и использовать всё что здесь понаписано! Одно net.core.somaxconn = 4096 чего стоит, а если сделать как нам говорит автор: limit_req_zone $host zone=hostreqlimit:20m rate=1500r/m;, то я вообще смогу положить его сайт с одного компьютера в вечный DDOS и все посетители будут получать ошибку 503, пока он не удалит это идиотское правило.

Если как тут пишут, это не статья, а стыренный чей-то доклад, то могу поздравить докладчиков — ваш доклад полная лажа!

Видимо на Хабре проблема с реальными качественными статьями на эту тему, надо будет на днях выложить качественные рекомендации используемые на боевых серверах.
UFO just landed and posted this here
Если Вы так считаете, то, вероятно, у Вас есть и обоснование? Поделитесь с общественностью чем именно Вас не устраивает приведенная методика, кроме того что она «ниочём»? Дело в том, что в реальном мире эта методика работает и спасла уже не один сайт, но возможно это была случайность?
Кхм, всё что написано в статье по определению не может «устраивать» и вообще хоть как-то использоваться на серверах под DDOS атакой. Мне нечего даже перечислять, здесь всё в корне неправильно. Спасти множество сайтов ваши методики ну никак не могли, они могли только наоборот побыстрее «прибить» несчастные сайты, поскольку предложенные решения только усугубляют действие DDOS атаки, а не борются с ней.

Статью надо бы срочно убрать в черновики подальше с глаз долой и больше никому не показывать. Вы даёте вредные рекомендации которые убивают сайты при любой мало-мальской DDOS атаке, а народ бездумно копирует всё это в свои конфиги и ставит плюсы (вижу уже более 30 несчастных). Не знаю почему статья в плюсах, видимо все грамотные сисадмины в отпусках.

Если вам так хочется увидеть реальные методики, которые работают на боевых серверах, которые по настоящему защищают сайты и позволяют бороться с DDOS, то думаю вы их увидите через несколько дней, когда я подготовлю и выложу статью.

Если кто из администрации Хабра упрочитает — уберите пожалуйста статью, она даёт вредные рекомендации читателям. Не знаю как-кому, но я рискну предположить что автор занимается DDOS атаками и пустил эту дезу в массы для хомячков. Хомячки не глядя вносят эти настройки на свои дедики, хостинги, сайты и как результат их можно с лёгкостью ддосить. Учитывая посещаемость Хабра, эффект от такой липовой борьбы с DDOS может быть большим, конечно в пользу ддосеров :-)
То есть аргументов у Вас нет? Отлично.
Аргументы? Т.е. вы предлагаете чтобы я вам сейчас перечислял каждую вашу рекомендацию и описывал почему она вредная? Боже упаси меня в комментариях целую статью переписывать с пояснениями и опровержениями… Хватает уже того, что вы поисковики блокируете, даете возможность положить сайт с одного компьютера и делаете так, чтобы машина захлебнулась своим же файерволом.
Где-то пол года назад здесь же на Хабре была статья от highloadlab, они советовали аналогичную методику, но несколько иную. Они тоже не умеют с ddos бороться?
Не верю что они такой бред могли насоветовать, дайте ссылку. Уверен они давали верное направление. Вы решили видимо переплюнуть ребят из highload, а случился фэйл. Да, надо тюнить ядро, нужно использовать limit_conn (про который вы даже не упомянули), limit_req и т.д. но не так как вы, а совершенно иначе.
У нас иное мнение, но Вы, к сожалению, даже не попытались понять почему.
Для наглядности было бы все же красиво обпровергнуть парочку тезисов автора…
Жду вашей статьи.
Раз вам так уж нужно парочку, то пожалуйста, начнем с начала:

1) Он говорит не нужно банить по $binary_remote_addr и правильно говорит, только вместо того чтобы банить по динамической perl_set переменной $host.md5($uri+аргументы).$binary_remote_addr, он банит тупо по адресу сайта $host. Т.е. если к сайту во время ddos за минуту отправили больше 1500 запросов (конечно больше отправят) — сайт висит. Автор не понимает что это за правило вообще или специально хочет сайт убить.

2) Дальше идём по статье, следующее у него — бан после 200 запросов за 15 минут. Т.е. он банит все поисковики (900 запросов / 15 минут), оставляя только Яндекс и может быть Google, путем добавления в белый лист мифических подсетей этих поисковых систем (где он взял такие списки, а если и взял, с чего решил что они полные?). На остальные поисковики ему плевать. А если атака не 2 дня, а 2 недели — все равно плевать. Можно вылетать из индекса, закрывать бизнес и вешаться.

Ну и далее по статье можно описывать в том же духе… ниже в комментах уже отметили предложенный «супертюнинг ядра».
В (1) под «сайт висит» подразумевается, что если с одного IP на сайт пришло больше 1500 запросов за минуту, IP попадет в бан?

Спасибо, жду вашу статью.
Нет, 1500 запросов с любого адреса. Причем это мегаограничение установлено даже не на отдельный специальный location/ который ведет к Apache, а на весь сервер. Т.е. если сайт со множеством картинок, CSS и JS скриптов + высокая посещаемость, то он даже без DDOS просто напросто ляжет от этого правила. В статье приведены правила «как отключить свой сайт», а не как его защитить.

Свою статью постараюсь написать, надо только время найти. Не собирался, но видя такое понимаю что надо…
Вы зря его спрашиваете, он не понял сути. Ниже я написал все подробно.
Спасибо за комментарий! Наконец-то я понял, зачем вели учет по $host, хотя я и не считаю, что это хорошая затея. Однако если использовать $host.md5($uri+аргументы).$binary_remote_addr, то почему тогда ботам не посылать каждый раз разный uri+аргументы?

По поводу (2). Из текста статьи мне показалось, что в бан попадет только тот, кто будет 100 раз отфильтрован за 15 минут. А для каждого «отфильтровывания» нужно подать более 1500 запросов в минуту (допустим, учет ведем всё-таки по $binary_remote_addr). Поисковик не подает запросы так часто, поэтому он не должен «отфильтроваться» nginx'ом ни разу. Кажется, суть тут в том, что бот, в отличие от пользователя, не успокоится после отфильтровывания nginx'ом и быстро наберет необходимые 100 отфильтрованных запросов. Хотя бота можно сделать и умного. Как, к примеру, отличить пользователя от бота, имитирующего неторопливое хождение по ссылкам, заполнение форм и нажатие кнопок?
1) Это как пример было показано конечно. Я бы предложил такую комбинированную переменную:

$combined
perl_set $combined '
sub {
use Digest::MD5 qw(md5_hex);
my $r = shift;
my $uri = $r->uri;
return md5_hex($r->remote_addr.$r->header_in("Host").$uri);
}';


т.е. по сути это md5($ip$host$uri).

2) Сколько раз будет отфильтрован бот там вообще не имеет значения н и к а к о г о. Само правило не даёт сделать более 1500 запросов к сайту за минуту (вообще любых запросов и к статике и к динамике и с любого ip). Т.е. сайт будет лежать.
1) То есть разные uri дают разные значения переменной. Тогда приходим к той же проблеме: что, если бот посылает каждый раз новый uri?

2) Допустим, от этого отказались. То есть считают не для $host, а для $binary_remote_addr, например. Пусть статику считают отдельно, с более мягкими ограничениями. Мне кажется, при таких условиях имеет смысл считать, сколько раз «попался» потенциальный бот. Если 100 раз за 5 минут, это явный бот, так как человек не будет тыкаться, если его временно заблокировали. Но опять же это спасет только от простых ботов. Стоит им добавить капельку «интеллекта», и они смогут это обходить. Если Вы напишете статью, было бы интересно узнать про способы борьбы с «умными» ботами.
Зачем обсуждать вымышленные вами ситуации? При определённых обстоятельствах всё имеет смысл, а мы же обсуждаем ту ересь, которая нам предлагается в этой статье.

Что касается фильтрации, то описанная мною переменная предназначена для фильтрации ботов долбящихся по одинаковому адресу. Если боты долбятся по разным URL, то для этого делается отдельный счётчик md5($host$ip), но никак не $host!
Похоже вся проблема сводится к тому, что Вы ничего не поняли, а сразу бросились критиковать. Методика, на которой строится статья, сводится к следующему:

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%. Кроме того, понятно же что роботы ходят с одних и тех же сетей. Соберите статистику по этим сетям заранее и обновляйте списки сетей поисковиков. Что тут сложного? Ничего.
А если один атакующий сделает 1500 запросов за 50 секунд и перестанет атаковать? Сайт будет недоступен какое-то время и часть хороших пользователей может попасть в «вечный» бан, а он не попадет, так как не будет заходить следующую минуту. Выждав минуту, он сделает то же самое и т.д. Это можно делать в одиночку, без ботнета. Мне кажется, что загонять всех под один счетчик опасно.
Почему же часть хороших пользователей попадет в вечный бан? Во-первых, для того, чтобы воспользоваться Вашим методом атакующему нужно точно знать методику защиты. Очевидно что заранее он ее знать не будет никаким образом. Во-вторых, даже в такой ситуации «хорошие» пользователи в бан не попадут. В-третьих, на то у сервера и должен быть админ, чтобы такие ситуации мог вычислить по логам, если методика защиты от атаки не работает.

Никто же не говорит что здесь описана серебрянная пуля. Это всего лишь одна из методик. Она не безгрешна, но она реально работает.
1. У любого сайта есть порог посещаемости, свыше которой он не тянет. В данном случае он установлен в 1500 хитов в минуту, хотя это индивидуально и понятно как настраивается. Когда на сайт налетает постоянная высокая посещаемость, то очевидно выше этого порога сайт начинает всем выдавать ошибки. Здесь, установив в nginx порог по посещаемости, те, кто создаст первые 1500 хитов, увидят именно сайт, а не ошибки. Далее все, кто пришел после 1500 хитов, начинают получать ошибку от nginx и их ip пишется в логи. Пока что всё просто: пока сайт тянет, он работает, дальше мы принудительно отключаем поток входящих запросов.

image

Вы правда верите в то, что сайт будет более или менее сносно работать, с таким вот limit_req_zone $host zone=hostreqlimit:20m rate=1500r/m; правилом? Первая же серия из 3000 одновременных запросов от одного бота положит ваш сайт намертво в первую же секунду. Кому он будет открываться? Господу богу? Будет открываться не сайт, а ошибка 503 всегда, всем и постоянно. Вы просто отключаете свой сайт этим правилом. Устанавливать порог посещаемости по $host это бред! Фух… ну простите, не могу я больше что-либо писать в этом топике, пусть хомячки дальше плюсуют вашу статью, а вы будете их новым проповедником своих заповедей, правил и т.д. :-)

На сим откланиваюсь и снимаю шляпу :/
Первая же серия из 3000 запросов от бота положит сайт на 1 минуту. Через 5 минут этот бот будет навечно забанен на firewall. Вот если вся атака будет строиться на том, что каждый бот (и только один одновременно) будет делать 3000 запросов и замолкать на минуту, тогда да, тогда эта методика не сработает. Но вот я не видел атак с таким паттерном ни разу, а всего разных атак мы видели множество.
И против такого паттерна можно еще проще написать защиту, тут даже nginx не понадобится. Достаточно в firewall считать кол-во коннектов в минуту с ip и банить тех, кто в минуту делает больше 120 коннектов, например.
Кстати, установка порога посещаемости по $host всего лишь ограничивает кол-во хитов в минуту на один сайт. Это в принципе полезно делать, когда сайтов на сервере несколько, чтобы атака на один из сайтов не положила вообще всё.
«все картинки я буду заливать только через хабрасторедж». «все картинки я буду заливать только через хабрасторедж». «все картинки я буду заливать только через хабрасторедж». «все картинки я буду заливать только через хабрасторедж». «все картинки я буду заливать только через хабрасторедж». «все картинки я буду заливать только через хабрасторедж». «все картинки я буду заливать только через хабрасторедж». «все картинки я буду заливать только через хабрасторедж». «все картинки я буду заливать только через хабрасторедж». «все картинки я буду заливать только через хабрасторедж».
Скажите, вы хоть понимаете, что ваши правила даже поисковики банят??? Поисковый робот делает 1 запрос в секунду, т.е. за 15 минут он сделает 900 запросов, а вы баните всех кто обратился к хосту более 200 раз! Этоже ж ппц, простите меня за такое слово. Скройте статью если уважаете себя и читателей.
Простите, а Вы статью читали? Там и про whitelist было, и методика-то вами понята не правильно совершенно.
whitelist? Для поисковиков? Ух ты… это как? Методом поглаживания магического шара? Или может быть у вас есть список всех IP адресов гугла, с которых он может придти? Или вы заносите googlebot в whitelist по строке с user agent? Ну тогда я дам команду ботам прикинуться googlebot и ваш фильтр успешно занесет весь мой ботнет в белый лист.

Или я может опять чего-то не так понял? Тогда расскажите, растолкуйте…
Очень не сложно найти список сетей, откуда ходят роботы Гугла и/или Яндекса. Буквально за 5 минут гуглится.

Никто не говорит, что все описанные в статье действия нужно делать в момент, когда атака уже началась. Все whitelist и прочее надо готовить заранее
Кем составлены эти списки и откуда они? Сомневаюсь что поисковики список своих сетей выкладывают (хотя конечно было бы полезно). Что насчет WebAlta, Rambler, Yahoo, Bing, Alexa, Mailru и прочих пауков, у вас тоже есть полные списки их сетей? Подумайте, зачем вам вообще эти списки… они же абсолютно не нужны, надо просто грамотно и правильно фильтрацию настраивать, а не так, как сделали вы.

Не подумайте что я злой и наезжаю на вас, просто статься реально вредна, я опасаюсь за неопытных хабровчан, ну а вы защищаете свою стаью ибо уверены в её правильности. Эх, это уже философия…
Лично я, как частное лицо, считаю что достаточно пускать на сайт роботов Яндекса и, может еще Гугля. Сети Я. и Г. выделить очень просто. Остальных на время ddos, а это обычно пара дней, можно просто не пускать, ничего страшного не случится. Ну это в общем случае.

Наша идея в том, чтобы предоставить инструмент для защиты, а не комплексное решение. Комплексные решения на рынке много кто предлагает за деньги, welcome.
RIPE вам в помощь. Не сложно написать скрип, парсящий периодически базу RIPE выковыривая подсети, анонсирующиеся на AS поисковиков и других заведомо благоверных компаний.
>Очень не сложно найти список сетей, откуда ходят роботы Гугла и/или Яндекса. Буквально за 5 >минут гуглится.

Дело в том, что достоверный список сетей поисковиков на блек сео форумах стоит денег.
Вы слышали что-то про клоакинг сайтов?
Поисковики борются с этим, и списки своих сетей выкладывать в паблик им нету никакого резона.

То что вы гуглите за 5 минут, давно не актуальное старье, выложенное «бывшими сеошниками».
Ну и где статья?
Самдоельный анализатор логов… мне кажется лучше использовать уже готовые решения.

Для себя решил проблему со школьным ддосом вполне штатными средствами:

fail2ban смотрит лог nginx, слишком часто обращающихся отправляет в blackhole (iptables даже не задействуется, можно держать огромный список ипшников в черном списке)

конфиги fail2ban:

filter: pastebin.com/NiR1E0qj
action: pastebin.com/k4BxrAeG
jail.conf: pastebin.com/n7eAhbxD

за 5 мин такая защита настраивается на любом сервере :)
UFO just landed and posted this here
1. ставим fail2ban (например yum install fail2ban)
2. создаем файл nginxaccess.conf в /etc/fail2ban/filter.d (содержимое из pastebin.com/NiR1E0qj)
3. создаем файл blackhole.conf в /etc/fail2ban/action.d (содержимое из pastebin.com/k4BxrAeG)
4. редактируем файл /etc/fail2ban/jail.conf в самый конец записываем содержимое из pastebin.com/n7eAhbxD, редактируем параметр logpath — должен указывать путь к access логу nginx, нормально обрабатывает ситуации с ротацией логов.
Ну и смотрим вначале файла jail.con строчку ignoreip = 127.0.0.1 — добавляем в нее свои ip адреса на всякий случай.

Последним пунктом перезапускаем fail2ban: service fail2ban restart

И идем пить чай ,) и через некоторое время смотрим в /var/log/fail2ban.log — сообщения о банах или смотрим список командой: ip route show | grep blackhole

Можно поиграться параметрами findtime и maxretry — задают жесткость критериев по которым определяются ддосеры (150 запросов к бэкендну на протяжении 60 секунд — критерий в примерах)

fail2ban демон достаточно гуманно потребляет ресурсы CPU и памяти даже на высокопосещаемых проектах. (в отличие от awk/grep/скриптов) А бан через blackhole работает хорошо с большим списокм ip в бане (в отличие от бана по iptables, который начинает есть много CPU на больших таблицах)
Если Вы с awk не на «Вы», то написать на awk скрипт проще, чем конфиги к fail2ban или еще чему-то узкоспециализированному.
UFO just landed and posted this here
Не могу согласиться с Вами. У нас есть примеры как эта методика отлично отрабатывала защищая от DDoS интернет-магазины на vds с 768 мб памяти. sort/uniq/awk не так много ресурсов потребляют, тем более запускаясь раз в 5 минут, а не постоянно.
UFO just landed and posted this here
Вы, конечно, сэкономите так какое-то количество ресурсов, но полноценных логов иметь не будете. И речь ведь не о том, что если нашу методику заменить на Вашу, то нагрузка на сервере упадет в 2 раза. Мы говорим о разнице в несколько процентов, не более.
UFO just landed and posted this here
На основании чего Вы делаете вывод, что я «не в теме»? Я говорю глядя на предлагаемый Вами конфиг, в нем упоминания другого лога нет, только одного.

Несколько процентов я называю исходя из того, что запуск раз в 5 минут связки awk/sort/uniq никак не может по потреблению ресурсов быть сопоставим с работой движка сайта. Возможно Ваш метод в 10 раз меньше ресурсов потребит, но в целом это будет 1% или 0,1%. А идея заключается в том, чтобы сервер не тащил на себе нагрузку от ddos, а очень быстро с ней справился.
UFO just landed and posted this here
Я думаю Вы достаточно хамоваты, чтобы продолжать эту дискуссию, к сожалению. Она могла бы быть интересной, если бы Вы не переходили на личности.
JFYI:

ls -l /bin/sh
lrwxrwxrwx 1 root root 4 авг. 1 14:32 /bin/sh -> dash
UFO just landed and posted this here
Похвастайтесь своим максимальным достижением.

Интернет-магазин на vds с 768M оперативы наверное кто-то у себя на телефоне его хостит =) Даже любопытно, кому вздумалось такое DDoS'ить — или у вас DDoS — забытый siege или ab в фоне? Что означает первая «D» в «DDoS» надеюсь вы знаете?
Давайте уж Вы тогда первый похвастайтесь, чтобы было с чем сравнивать.
Если вы зануляете маршруты к ботам, то это надо делать через BGP blackhole.
В вашем случае, сервер будет принимать запросы от ботов, обрабатывать их, а потом еще тратить ресурсы на отсылку пакетов в никуда.
Дело в том, что эта статья не о том, как бороться с ddos на провайдерском уровне, а о том, как бороться с ddos для vds/dedicated. У таких людей нет возможности использовать такие методы как bgp blackhole
А вы не боретесь.
У вас как была высокая нагрузка, так она и остается, даже немного растет.
Если атакующий больше не может соединиться с сервером, то почему от него останется какая-то нагрузка? Максимум — несколько пакетов по сети. Любой ботнет имеет конечный размер и за вполне конкретное время весь ботнет попадет в -j DROP
Атакующий знает маршрут к вашему ip и продолжает слать запросы.
Обработкой ответов занимается только командный центр, а не рядовые ячейки бот-нета.
Вы посмотрите свои action. Где там -j DROP?
-A INPUT -m set --match-set ddos src -j DROP
ipset, кстати, уже почти с год как в ядре.
В Debian Squeeze — нет. В wheezy тоже.
Он идет в составе пакета с ядром или все так же через module-assistant устанавливается?
Видимо, с ядром.

ii ipset 6.12.1-1
ii libipset2:amd64 6.12.1-

lsmod:
ip_set 26700 0
nfnetlink 12906 1 ip_set
Наверное несовсем в тему вопрос, но все-таки озвучу.
Имеется VDS с 2Гб, lighttpd,fcgi-php,mysql.
Если просто даю нагрузку на сайт, то все нормально. А если начинаю сканировать чем-то типа Acunetix Web Vulnerability, то, насколько я понимаю, у mysql заканчиваются сокеты и он на пару минут впадает в ступор.
В какую сторону лучше копать кроме игры с timeout'ом сессий mysql?
Интересно, но у меня просьба — не советуйте тюнить другим те параметры TCP, которые сами не понимаете.

Вот, например, зачем вы это предложили?

net.ipv4.tcp_rmem = 4096 8192 87380
net.ipv4.tcp_wmem = 4096 8192 65536

Для тех, кто не знает, что это такое: это параметры настройки буфферов TCP (на чтение и запись соотв): min, default, max.

Значение по-умолчанию — 4к, 16к, 64к/4M.

Вы зачем-то взяли и порезали размер буфера по-умолчанию. Меньше буфер — меньше максимальная скорость WAN сети (где RTT, то бишь пинг, большой).

Меньше скорость — больше коннектов (если вам нужно обслужить 100 запросов по 100кб в секунду, то если вы будете отдавать их со скоростью 1Мб/с каждому, то будете иметь 10 одновременных коннектов, если со скоростью 5Мб/с, то всего 2).

И вы взяли зачем-то и уменьшили буфер. Нафига? И нафига было так сурово резать максимум?
UFO just landed and posted this here
Я думаю, что если каждый напишет про область своего знания, итогом будет увеличение общего знания у всех читающих/обсуждающих.

Я вот не сильно гуру в веб-сервисах, мне написанное показалось вполне разумным.

В чём тут проблемы?
UFO just landed and posted this here
Я представляю что он напишет, с учетом того, что он даже не понял о чем идет речь тут. Он своими словами попытался описать суть и написал полную ахинею, не имеющую ничего общего с методикой, описанной в статье.
UFO just landed and posted this here
В алгоритме построения защиты ошибки есть только если строить атаку очень специализированным образом, атакуя именно слабые места алгоритма. Для этого нужно знать какой именно алгоритм применяется, а атакующий этого не знает. Против типового http flood ddos эта методика работает и глупо отрицать очевидное.
Выпады в адрес того, что fail2ban быстрее чем awk, либо что можно писать отдельно логи — это, знаете те ли, не ошибки. Ошибки — это когда что-то делается не правильно. А когда что-то делается и в результате все работает, это не может быть ошибкой, это может быть лишь не эффективной реализацией. Но и это спорно, потому что никто не привел цифр, которые бы с разгромным счетом показали растрату ресурсов сервера нашим методом против какого-то иного, все голосновно.
UFO just landed and posted this here
Вот с одной стороны Ваш комментарий, с другой успешная практика использования этой и других методик в течение нескольких последних лет. По Вашему, я должен поверить что Вы — мега-спец (кстати, а где пруф? Ваш коллега так и вовсе программист на php, а Вы даже ни одной статьи не написали), и тогда я должен признать что весь наш опыт борьбы с ddos — это результат случайного везения. Но очевидно, что на одном везении с ddos не поборешься, отсюда возникают вопросы в Ваш адрес, уж извините.
> «только представьте»

Вот и вся аргументация: только представьте что на Землю упадет Луна… В статье явно написано что это борьба с http flood. Откуда возьмется то, что Вы предлагаете представлять? Почему обычно не берется? Может потому что Вы сами реально с атаками только на картинках знакомы?
UFO just landed and posted this here
Смотрите, вот несколько цитат из последней статьи highloadlab:

> Преступники отдают предпочтение высокоуровневым атакам транспортного и прикладного уровня (82%)
> Не менее 50% атак Layer 7 – это «долбежка» в один URI

Думаю процент чисто http flood атак Вы сможете посчитать сами. Отсюда Ваше высказывание «А потом только представьте себе, что все те адреса, которые вы «успешно» забанили, чихать хотели на все ваши -j DROP и входящий канал будут забивать аж по самое не балуйся ;)» уже под боооольшим вопросом, точнее его актуальность. Причем HLL считают статистику по атакам, с которыми обращаются к ним, а у нас есть статистика по атакам, с которыми обращаются к нам. У нас расклад иной и еще больше не в пользу Вашей точки зрения. Из последних 4 десятков атак кроме http flood другой трафик мы наблюдали только в одном (!) случае.

Теперь прикиньте каков реальный процент атак, против которых эта методика будет эффективна и Вам поплохеет.
> И количеством статей не меряюсь (кстати, качественный показатель важнее, IMHO)…

конечно, Вы правы. Только когда показатель, любой причем, умножается на ноль, он все равно равен нулю. Что такое «ноль»? Ноль — это количество Ваших статей.
Кажется, это первая обоснованная критика. Спасибо
Про $host в limit_req_zone вам уже много написали. Я считаю, что это имеет смысл, особенно на слабых VPS. Но значение burst должно быть в разы больше, и без nodelay.

Для равномерного ограничения нагрузки на железо можно было бы и $pid использовать (речь ведь о VPS, а не о кластере).

Кстати, зачем мы резервируете под такую маленькую зону целых 20 Мб?

Ёще надо иметь в виду, что без $binary_remote_addr под нагрузкой часть клиентов могут получать 503 на часть запросов (например, им не отдастся css), что вообще-то еще хуже чем лежащий сайт.
Основная идея сводится к тому, чтобы в достаточно короткое время выделить ботнет и зафильтровать его. Понятно что при этом будут какие-то потери для нормальных посетителей. Но если речь о том, что они не допустимы, то лучше сразу идти договариваться с профильными компаниями о защите.
Срач разгорелся нешуточный. А давайте кто-нибудь поднимет тестовый сайт, прикрутит к нему описанную выше защиту, а затем проверит ее DDOS'ом? И увидим все плюсы и минусы предлагаемого решения.
А самый умный — платит. На самом деле, если наберется пара десятков желающих — возьмем в аренду хетцнер и заDDOSим его до кровавых соплей. На хабре же есть способные превратить всю эту экзекуцию в вебинар. Вон, тут на днях за 50000 с лица предлагали балаган по сетевым технологическим новинкам провести и ничего, кто-то купил себе знаний.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
По сути требуется не мега-защита, а что-то любительского уровня (иначе проще нанять конторы которые занимаются такими проблемами и потратиться на железо). Т.е. общедоступное. А следовательно, и дистрибутив должен быть массовый. Например Linux (Ubuntu Server, Debian, Fedora, etc.).
UFO just landed and posted this here
UFO just landed and posted this here
Считайте что я вам написал в личку, что бы «ответить за базар» деньгой.
Интересует LAMP-стэк на Debian/CentOS 64 и KVM/Xen виртуализация.
UFO just landed and posted this here
Хабр как он есть, все хотят показать себя большими молодцами по сравнению с остальными))

Большинство комментирующих почему-то никак не хотят принимать во внимание тот факт, что алгоритм из топика предназначен для простых vds/dedicated server, где по определению мощность всей системы не столь высока. Раз мощность не столь высока, то и сайт не настолько популярен (тем более, что автор пишет о нескольких сайтах на одном vps/ds). А раз сайт не настолько популярен, то и алгоритмы ddos-атак будут на них весьма примитивные (не будут платить большие деньги за качественный ddos, а если и будут, то скорее всего и много других защит захлебнется, остальные ddos-атаки проводят всякие школьники). Для защиты именно от таких атак и написан конфиг. Алгоритм не так плох в плане скорости работы/эффективности/сложности/etc для своих нужд, хоть и не без недостатков. Имхо)
Спасибо :) Именно это мы и пытались донести.
Холивар, хорошо с утра почитать.
Копошатся и петушаться друг перед другом…
А давайте просто затестим этот скрипт на указанном автором сервере, желателньо чтобы он был не продакшн — чтобы никому не навредить. :)

потом почитаем логи и посчитаем uptime сервиса.

Автор ты ЗА?
И в чем, простите, глубокий смысл этой затеи? Описанная методика опробована на нескольких десятках реальных ddos-атак. Она не идеальна, но она работает. Разумеется, завалить защищаемый ею сайт можно, но в большинстве случаев реальным атакующим это не удается.
Это против? — Голос принят.

Я в реальной жизни полагаюсь на аппаратные решения, согласен что они дороже — но надежнее.

Мысли у вас изложены может и верные — а админов гоните в шею за реализацию и не знание предметной области.
Интересная статья, про ipset и tarpit не знал.
Хотелось бы подробнее про sysctl, поскольку почти нигде не объясняется, на что конкретно влияют параметры и какие причины ставить большие или меньшие значения, но статья вроде не об этом :)
С реальными ддос-атаками не сталкивался, поведения ботов не знаю, но общая идея мне нравится, я бы тоже пытался думать в таком направлении, если бы возникли проблемы с маленьким сервером с сотней малобюджетных сайтов.
Конечно, это не подойдет для толстых java-rich сайтов, которые не поднимаются сами при пропадании нагрузки.
Еще можно прикрутить proxy_cache, если специфика сайта это позволяет.
Я думаю параметры sysctl стоит начать изучать с документации по ядру.
Sign up to leave a comment.