На сбор, систематизацию и толковое описание всей информации по делу потребуется немалое время, но могу в процессе подготовить примерно такой материал:
1) Оптимальное содержимое sysctl.conf для защиты от ddos да и в целом для оптимальной работы сети. Но это без формул (для типового мощного сервера с ОЗУ более 8 гигов), надо чтобы кто-то составил правильную формулу рассчёта для каждого параметра (форума зависимости значения параметра от ОЗУ у машины).
2) Файервол — встроенный, установка стороннего и т.д., как настраивать.
3) Некоторые настройки Apache и PHP для защиты сервера, оптимальной работы и т.д. В частности про Apache mpm-itk, про обновления безопасности и исправления для старых версий PHP (для PHP 2.5.17 патчи всё еще штампуются, но не разработчиками, а умельцами с гуглокода) и т.д.
4) Защита от DDOS с помощью Nginx, настройка, анализ логов, блокирование, как не потерять полезные коннекты при ddos и т.д.
5) Как не нужно использовать php, почему не стоит использовать оптимизаторы (eaccelerator, apc, xcache и прочие)
6) Как обновлять ПО сервера, как установить из исходников apache/php/mysql и т.д.
7) Вынос MySQL, Почты, DNS на отдельные сервера для shared хостинга
8) Что лучше для сайта: sqlite или mysql, для каких задач что выбирать, скорость и т.д.
9) Оптимизация CSS и JS кода, почему не стоит выносить графику, js и css на отдельный поддомен…
10) Отказ от счетчиков и большинства рекламы и почему они могут отключить ваш сайт / уменьшить количество аудитории, сбор статистики по логам с красивыми графиками и отчётами.
и другие рекомендации… Но на всё это надо много времени которого у меня почти нет. А идея хорошая и мне нравится. Как найду время — присоединюсь к группе habratest :-)
К сожалению, моему большому сожалению, видимо правка оригинального Twitter Bootstrap прошла неудачно и вы поломали CSS. Ничего не утверждаю, может и не вы виноваты, но часть когда не рабочая. Сейчас проверил в IE9 к примеру те же Javascript plugins — Buttons, но только в Twitter Bootstrap, там всё работает хорошо.
Тут в комментах прочитал, что вы переделывали старую ветку, может быть в этом проблема…
Пару часов поюзал и к сожалению радость пропала. Тестировал в разных версиях IE. Часть функций работает не до конца (один из примеров: demo Modal диалог просто отображается, а не выплывает красиво как в Firefox), а часть вообще не работает. Каково было мое удивление увидеть неработающим целый раздел
Javascript plugins — Buttons ни где-то, а в современном IE9. Заменить фон у кнопки дело нехитрое, так что проблемы явно не в браузере.
В общем идея просто превосходная, но работает далеко не всё, а то что работает — отображается по разному в разных браузерах. Есть над чем работать. Желаю успехов в развитии, спасибо за работу!
1. У любого сайта есть порог посещаемости, свыше которой он не тянет. В данном случае он установлен в 1500 хитов в минуту, хотя это индивидуально и понятно как настраивается. Когда на сайт налетает постоянная высокая посещаемость, то очевидно выше этого порога сайт начинает всем выдавать ошибки. Здесь, установив в nginx порог по посещаемости, те, кто создаст первые 1500 хитов, увидят именно сайт, а не ошибки. Далее все, кто пришел после 1500 хитов, начинают получать ошибку от nginx и их ip пишется в логи. Пока что всё просто: пока сайт тянет, он работает, дальше мы принудительно отключаем поток входящих запросов.
Вы правда верите в то, что сайт будет более или менее сносно работать, с таким вот limit_req_zone $host zone=hostreqlimit:20m rate=1500r/m; правилом? Первая же серия из 3000 одновременных запросов от одного бота положит ваш сайт намертво в первую же секунду. Кому он будет открываться? Господу богу? Будет открываться не сайт, а ошибка 503 всегда, всем и постоянно. Вы просто отключаете свой сайт этим правилом. Устанавливать порог посещаемости по $host это бред! Фух… ну простите, не могу я больше что-либо писать в этом топике, пусть хомячки дальше плюсуют вашу статью, а вы будете их новым проповедником своих заповедей, правил и т.д. :-)
Зачем обсуждать вымышленные вами ситуации? При определённых обстоятельствах всё имеет смысл, а мы же обсуждаем ту ересь, которая нам предлагается в этой статье.
Что касается фильтрации, то описанная мною переменная предназначена для фильтрации ботов долбящихся по одинаковому адресу. Если боты долбятся по разным URL, то для этого делается отдельный счётчик md5($host$ip), но никак не $host!
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). Т.е. сайт будет лежать.
Нет, 1500 запросов с любого адреса. Причем это мегаограничение установлено даже не на отдельный специальный location/ который ведет к Apache, а на весь сервер. Т.е. если сайт со множеством картинок, CSS и JS скриптов + высокая посещаемость, то он даже без DDOS просто напросто ляжет от этого правила. В статье приведены правила «как отключить свой сайт», а не как его защитить.
Свою статью постараюсь написать, надо только время найти. Не собирался, но видя такое понимаю что надо…
Раз вам так уж нужно парочку, то пожалуйста, начнем с начала:
1) Он говорит не нужно банить по $binary_remote_addr и правильно говорит, только вместо того чтобы банить по динамической perl_set переменной $host.md5($uri+аргументы).$binary_remote_addr, он банит тупо по адресу сайта $host. Т.е. если к сайту во время ddos за минуту отправили больше 1500 запросов (конечно больше отправят) — сайт висит. Автор не понимает что это за правило вообще или специально хочет сайт убить.
2) Дальше идём по статье, следующее у него — бан после 200 запросов за 15 минут. Т.е. он банит все поисковики (900 запросов / 15 минут), оставляя только Яндекс и может быть Google, путем добавления в белый лист мифических подсетей этих поисковых систем (где он взял такие списки, а если и взял, с чего решил что они полные?). На остальные поисковики ему плевать. А если атака не 2 дня, а 2 недели — все равно плевать. Можно вылетать из индекса, закрывать бизнес и вешаться.
Ну и далее по статье можно описывать в том же духе… ниже в комментах уже отметили предложенный «супертюнинг ядра».
Кем составлены эти списки и откуда они? Сомневаюсь что поисковики список своих сетей выкладывают (хотя конечно было бы полезно). Что насчет WebAlta, Rambler, Yahoo, Bing, Alexa, Mailru и прочих пауков, у вас тоже есть полные списки их сетей? Подумайте, зачем вам вообще эти списки… они же абсолютно не нужны, надо просто грамотно и правильно фильтрацию настраивать, а не так, как сделали вы.
Не подумайте что я злой и наезжаю на вас, просто статься реально вредна, я опасаюсь за неопытных хабровчан, ну а вы защищаете свою стаью ибо уверены в её правильности. Эх, это уже философия…
whitelist? Для поисковиков? Ух ты… это как? Методом поглаживания магического шара? Или может быть у вас есть список всех IP адресов гугла, с которых он может придти? Или вы заносите googlebot в whitelist по строке с user agent? Ну тогда я дам команду ботам прикинуться googlebot и ваш фильтр успешно занесет весь мой ботнет в белый лист.
Или я может опять чего-то не так понял? Тогда расскажите, растолкуйте…
Не верю что они такой бред могли насоветовать, дайте ссылку. Уверен они давали верное направление. Вы решили видимо переплюнуть ребят из highload, а случился фэйл. Да, надо тюнить ядро, нужно использовать limit_conn (про который вы даже не упомянули), limit_req и т.д. но не так как вы, а совершенно иначе.
Аргументы? Т.е. вы предлагаете чтобы я вам сейчас перечислял каждую вашу рекомендацию и описывал почему она вредная? Боже упаси меня в комментариях целую статью переписывать с пояснениями и опровержениями… Хватает уже того, что вы поисковики блокируете, даете возможность положить сайт с одного компьютера и делаете так, чтобы машина захлебнулась своим же файерволом.
Скажите, вы хоть понимаете, что ваши правила даже поисковики банят??? Поисковый робот делает 1 запрос в секунду, т.е. за 15 минут он сделает 900 запросов, а вы баните всех кто обратился к хосту более 200 раз! Этоже ж ппц, простите меня за такое слово. Скройте статью если уважаете себя и читателей.
Кхм, всё что написано в статье по определению не может «устраивать» и вообще хоть как-то использоваться на серверах под DDOS атакой. Мне нечего даже перечислять, здесь всё в корне неправильно. Спасти множество сайтов ваши методики ну никак не могли, они могли только наоборот побыстрее «прибить» несчастные сайты, поскольку предложенные решения только усугубляют действие DDOS атаки, а не борются с ней.
Статью надо бы срочно убрать в черновики подальше с глаз долой и больше никому не показывать. Вы даёте вредные рекомендации которые убивают сайты при любой мало-мальской DDOS атаке, а народ бездумно копирует всё это в свои конфиги и ставит плюсы (вижу уже более 30 несчастных). Не знаю почему статья в плюсах, видимо все грамотные сисадмины в отпусках.
Если вам так хочется увидеть реальные методики, которые работают на боевых серверах, которые по настоящему защищают сайты и позволяют бороться с DDOS, то думаю вы их увидите через несколько дней, когда я подготовлю и выложу статью.
Если кто из администрации Хабра упрочитает — уберите пожалуйста статью, она даёт вредные рекомендации читателям. Не знаю как-кому, но я рискну предположить что автор занимается DDOS атаками и пустил эту дезу в массы для хомячков. Хомячки не глядя вносят эти настройки на свои дедики, хостинги, сайты и как результат их можно с лёгкостью ддосить. Учитывая посещаемость Хабра, эффект от такой липовой борьбы с DDOS может быть большим, конечно в пользу ддосеров :-)
Статья ниочём! Бред полный, это не защита от DDOS атак, а самоубийство своего сайта/сервера. Не дай бог кому-то так свой сервер настроить и использовать всё что здесь понаписано! Одно net.core.somaxconn = 4096 чего стоит, а если сделать как нам говорит автор: limit_req_zone $host zone=hostreqlimit:20m rate=1500r/m;, то я вообще смогу положить его сайт с одного компьютера в вечный DDOS и все посетители будут получать ошибку 503, пока он не удалит это идиотское правило.
Если как тут пишут, это не статья, а стыренный чей-то доклад, то могу поздравить докладчиков — ваш доклад полная лажа!
Видимо на Хабре проблема с реальными качественными статьями на эту тему, надо будет на днях выложить качественные рекомендации используемые на боевых серверах.
Получайте — 8181 иконок 16x16 в одном архиве.
Собраны из:
1) webhostingw.com/icon-window/ (3460 штук вышло, а не 3000)
2) Fugue Icons последней версии
3) мои собранные по сайтам за пару лет
Есть немного дублей + икноки без назнавания (только цифры)
Закачать: open-server.ru/SuperIcons.rar
1) Оптимальное содержимое sysctl.conf для защиты от ddos да и в целом для оптимальной работы сети. Но это без формул (для типового мощного сервера с ОЗУ более 8 гигов), надо чтобы кто-то составил правильную формулу рассчёта для каждого параметра (форума зависимости значения параметра от ОЗУ у машины).
2) Файервол — встроенный, установка стороннего и т.д., как настраивать.
3) Некоторые настройки Apache и PHP для защиты сервера, оптимальной работы и т.д. В частности про Apache mpm-itk, про обновления безопасности и исправления для старых версий PHP (для PHP 2.5.17 патчи всё еще штампуются, но не разработчиками, а умельцами с гуглокода) и т.д.
4) Защита от DDOS с помощью Nginx, настройка, анализ логов, блокирование, как не потерять полезные коннекты при ddos и т.д.
5) Как не нужно использовать php, почему не стоит использовать оптимизаторы (eaccelerator, apc, xcache и прочие)
6) Как обновлять ПО сервера, как установить из исходников apache/php/mysql и т.д.
7) Вынос MySQL, Почты, DNS на отдельные сервера для shared хостинга
8) Что лучше для сайта: sqlite или mysql, для каких задач что выбирать, скорость и т.д.
9) Оптимизация CSS и JS кода, почему не стоит выносить графику, js и css на отдельный поддомен…
10) Отказ от счетчиков и большинства рекламы и почему они могут отключить ваш сайт / уменьшить количество аудитории, сбор статистики по логам с красивыми графиками и отчётами.
и другие рекомендации… Но на всё это надо много времени которого у меня почти нет. А идея хорошая и мне нравится. Как найду время — присоединюсь к группе habratest :-)
Тут в комментах прочитал, что вы переделывали старую ветку, может быть в этом проблема…
Javascript plugins — Buttons ни где-то, а в современном IE9. Заменить фон у кнопки дело нехитрое, так что проблемы явно не в браузере.
В общем идея просто превосходная, но работает далеко не всё, а то что работает — отображается по разному в разных браузерах. Есть над чем работать. Желаю успехов в развитии, спасибо за работу!
Вы правда верите в то, что сайт будет более или менее сносно работать, с таким вот limit_req_zone $host zone=hostreqlimit:20m rate=1500r/m; правилом? Первая же серия из 3000 одновременных запросов от одного бота положит ваш сайт намертво в первую же секунду. Кому он будет открываться? Господу богу? Будет открываться не сайт, а ошибка 503 всегда, всем и постоянно. Вы просто отключаете свой сайт этим правилом. Устанавливать порог посещаемости по $host это бред! Фух… ну простите, не могу я больше что-либо писать в этом топике, пусть хомячки дальше плюсуют вашу статью, а вы будете их новым проповедником своих заповедей, правил и т.д. :-)
На сим откланиваюсь и снимаю шляпу :/
Что касается фильтрации, то описанная мною переменная предназначена для фильтрации ботов долбящихся по одинаковому адресу. Если боты долбятся по разным URL, то для этого делается отдельный счётчик md5($host$ip), но никак не $host!
т.е. по сути это md5($ip$host$uri).
2) Сколько раз будет отфильтрован бот там вообще не имеет значения н и к а к о г о. Само правило не даёт сделать более 1500 запросов к сайту за минуту (вообще любых запросов и к статике и к динамике и с любого ip). Т.е. сайт будет лежать.
Свою статью постараюсь написать, надо только время найти. Не собирался, но видя такое понимаю что надо…
1) Он говорит не нужно банить по $binary_remote_addr и правильно говорит, только вместо того чтобы банить по динамической perl_set переменной $host.md5($uri+аргументы).$binary_remote_addr, он банит тупо по адресу сайта $host. Т.е. если к сайту во время ddos за минуту отправили больше 1500 запросов (конечно больше отправят) — сайт висит. Автор не понимает что это за правило вообще или специально хочет сайт убить.
2) Дальше идём по статье, следующее у него — бан после 200 запросов за 15 минут. Т.е. он банит все поисковики (900 запросов / 15 минут), оставляя только Яндекс и может быть Google, путем добавления в белый лист мифических подсетей этих поисковых систем (где он взял такие списки, а если и взял, с чего решил что они полные?). На остальные поисковики ему плевать. А если атака не 2 дня, а 2 недели — все равно плевать. Можно вылетать из индекса, закрывать бизнес и вешаться.
Ну и далее по статье можно описывать в том же духе… ниже в комментах уже отметили предложенный «супертюнинг ядра».
Не подумайте что я злой и наезжаю на вас, просто статься реально вредна, я опасаюсь за неопытных хабровчан, ну а вы защищаете свою стаью ибо уверены в её правильности. Эх, это уже философия…
Или я может опять чего-то не так понял? Тогда расскажите, растолкуйте…
Статью надо бы срочно убрать в черновики подальше с глаз долой и больше никому не показывать. Вы даёте вредные рекомендации которые убивают сайты при любой мало-мальской DDOS атаке, а народ бездумно копирует всё это в свои конфиги и ставит плюсы (вижу уже более 30 несчастных). Не знаю почему статья в плюсах, видимо все грамотные сисадмины в отпусках.
Если вам так хочется увидеть реальные методики, которые работают на боевых серверах, которые по настоящему защищают сайты и позволяют бороться с DDOS, то думаю вы их увидите через несколько дней, когда я подготовлю и выложу статью.
Если кто из администрации Хабра упрочитает — уберите пожалуйста статью, она даёт вредные рекомендации читателям. Не знаю как-кому, но я рискну предположить что автор занимается DDOS атаками и пустил эту дезу в массы для хомячков. Хомячки не глядя вносят эти настройки на свои дедики, хостинги, сайты и как результат их можно с лёгкостью ддосить. Учитывая посещаемость Хабра, эффект от такой липовой борьбы с DDOS может быть большим, конечно в пользу ддосеров :-)
Если как тут пишут, это не статья, а стыренный чей-то доклад, то могу поздравить докладчиков — ваш доклад полная лажа!
Видимо на Хабре проблема с реальными качественными статьями на эту тему, надо будет на днях выложить качественные рекомендации используемые на боевых серверах.
Собраны из:
1) webhostingw.com/icon-window/ (3460 штук вышло, а не 3000)
2) Fugue Icons последней версии
3) мои собранные по сайтам за пару лет
Есть немного дублей + икноки без назнавания (только цифры)
Закачать: open-server.ru/SuperIcons.rar