Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 78
Хорошая статья, limit_conn one 3; не кажется ли вам слишком жостко, просто лог разрестется до безобразия, я на 10 пока остановился в похожей конфигураци.
В принципе похожие методы уже обсуждались на Хабре, но у вас так развернуто вышло. Спасибо.
И перенесите наверное пост в тематику.
И перенесите наверное пост в тематику.
IPtables не пригодны для фильтрации большого количества адресов.
Зато у IPtables есть отличное расширение ipset (из patch-o-matic)
Легко собирается в виде модуля и заворачивается в rpm. Без пересборки ядра.
Кроме того сразу получаете автоматическую очистку старых правил через заданное при добавлении количество времени.
Во-первых боты уже давно не делают тупой GET / и ходят по сайту с активностью человека, не чаще одного запроса в минуту
Во-вторых тупых ботов-дятлов можно легко банить без логов и их анализа, чисто iptables подробности на hostinghelp.biz/content/ddos-что-делать-если-сервер-только-один-linux-с-apache
И да, если долбят главную — то можно отдавать редирект через хедеры, тупоботы его не делают
P.S. Цена ботнета сейчас — копейки, их часто воруют у создателей.
Во-вторых тупых ботов-дятлов можно легко банить без логов и их анализа, чисто iptables подробности на hostinghelp.biz/content/ddos-что-делать-если-сервер-только-один-linux-с-apache
И да, если долбят главную — то можно отдавать редирект через хедеры, тупоботы его не делают
P.S. Цена ботнета сейчас — копейки, их часто воруют у создателей.
Эх, ещё бы придумать, как с такими ублюдками бороться методом пробития печени…
Ведь мы знаем, кто заказчик? Ближайшие конкуренты!
Далее — уже дело техники и оперативных товарищей.
И здесь даже как-то больше удовлетворения, когда ты осознаешь, что с другой стороны товарища прикладывают головой в пол и он «я больше так не бууудуу!».
Кароче надо управление «К» развивать — бюджеты ему подгонять и спецов.
Ведь мы знаем, кто заказчик? Ближайшие конкуренты!
Далее — уже дело техники и оперативных товарищей.
И здесь даже как-то больше удовлетворения, когда ты осознаешь, что с другой стороны товарища прикладывают головой в пол и он «я больше так не бууудуу!».
Кароче надо управление «К» развивать — бюджеты ему подгонять и спецов.
А Вы (обратите внимание на регистр букв в «Вы») одобряете DDOS-атаки? Тогда Вас за сочувствие злу можно привлечь.
Конечно я садист! Только по отношению к злу. Вы ведь в курсе, что добро всегда побеждает зло, ставит его на колени и мерзко насилует?
А вот про безопасность — это как раз то, что мне мало нравится. Проблемы я обычно предпочитаю решать в корне — именно этим государство и хорошо. Если у нас школу захватили терористы, то это не значит, что нам надо в брониках всем ходить и конючить о разрешении оружия (хотя я за оружие и здесь бы тоже поканючил)? Если такое случается, то надо проблему в корне решать, методом уничтожения опасных товарищей.
В госудуме сидят вааще андроиды, так что здесь я бы попросил не обобщать :)
// Да забейте Вы на орфографии :)
Кароче суть и непонимание в Вашей интравертности и моей экстравертности — я предпочитаю корень проблемы и социальный подход, а Вы — последствия проблемы и технический. Вот и весь холивар.
Конечно я садист! Только по отношению к злу. Вы ведь в курсе, что добро всегда побеждает зло, ставит его на колени и мерзко насилует?
А вот про безопасность — это как раз то, что мне мало нравится. Проблемы я обычно предпочитаю решать в корне — именно этим государство и хорошо. Если у нас школу захватили терористы, то это не значит, что нам надо в брониках всем ходить и конючить о разрешении оружия (хотя я за оружие и здесь бы тоже поканючил)? Если такое случается, то надо проблему в корне решать, методом уничтожения опасных товарищей.
В госудуме сидят вааще андроиды, так что здесь я бы попросил не обобщать :)
// Да забейте Вы на орфографии :)
Кароче суть и непонимание в Вашей интравертности и моей экстравертности — я предпочитаю корень проблемы и социальный подход, а Вы — последствия проблемы и технический. Вот и весь холивар.
Спасибо за минус в писькометр :)
Это подтверждение моей правоты, которая Вам аж глаза режет.
Это подтверждение моей правоты, которая Вам аж глаза режет.
Сейчас уже хорошие ддосы направлены не на то, чтобы завалить сервак, а на то, чтобы:
1. Забить канал.
2. Опустить хозяина сайта на бабки за паразитный трафик.
1. Забить канал.
2. Опустить хозяина сайта на бабки за паразитный трафик.
# создаем DROP правила для 50 самых агрессивных ботов
# загружаем blacklist
Я сделал раз в 5 минут.
Ну-ну. Ошибка #1 при использовании больших набором правил в iptables. Через сутки в одной цепочке будет уже 24*60/5 * 50 ~ 14K правил. И каждых 5 минут сервер будет бешено тормозить где-то минуту. Почему? Потому что ядро умеет обновлять только таблицы целиком (в атомарной тразакции). Скрипт с 50 вызовами iptables сделает 50 транзакций, во время каждой из которых таблица с тысячами записей сначала будет перекачана из ядра в юзерспейс, а затем обратно.
man iptables-restore
Спасибо за интересную статью! Она неплохо описывает базовые проблемы сервера под ДДоСом
Мне, как сетевику, очень интересны методы борьбы с ДДоСом ибо толь вместе можно минимизировать потери
хочу спросить: какие атаки можно таким образом отразить? Например, часто атаки ДДоС по опыту проводятся часто с одни обращением с хоста. Несколько обращений нужно если ботнет махонький ;)
и еще: наверно надо готовиться к следующей волне гибрида ДоС-ДДоС
Атаку тут пытался отразить — фиг получилось!
А идея проста: засылается массово запросы SYN и сразу с того же хоста ACK и FIN
Сервер начинает сходить с ума
Мне, как сетевику, очень интересны методы борьбы с ДДоСом ибо толь вместе можно минимизировать потери
хочу спросить: какие атаки можно таким образом отразить? Например, часто атаки ДДоС по опыту проводятся часто с одни обращением с хоста. Несколько обращений нужно если ботнет махонький ;)
и еще: наверно надо готовиться к следующей волне гибрида ДоС-ДДоС
Атаку тут пытался отразить — фиг получилось!
А идея проста: засылается массово запросы SYN и сразу с того же хоста ACK и FIN
Сервер начинает сходить с ума
То есть nginx не может блокировать потому что нет зоны и http-запроса как такового?
Что-то подобное было. Взял tcpdump, выбрал фильтром только syn-пакеты, соорудил сенсор и блокировщик.
Что-то подобное было. Взял tcpdump, выбрал фильтром только syn-пакеты, соорудил сенсор и блокировщик.
Запросов было реально много, т.к. можно делать спуфинг адреса источника.(сотни миллионов в секунду)
И фильтр по SYN наверняка можно сделать, только он же и забьет проц до смерти…
Впрочем, спасибо за идею: подготовлюсь теоретически.
И фильтр по SYN наверняка можно сделать, только он же и забьет проц до смерти…
Впрочем, спасибо за идею: подготовлюсь теоретически.
А в цисках как-будто процессора нет?
Вообще, опасения ваши имеют почву, но прогресс на месте не стоит. Сетевые карты стали поддерживать несколько очередей, линуксоиды вот тут доковырялись до фильтров прямо на карте и в драйвере карты: luca.ntop.org/IM2009_Tutorial.pdf
Про карты с FPGA мы уже как-то с вами обсуждали — они доступны и для PC-платформы.
Вообще, опасения ваши имеют почву, но прогресс на месте не стоит. Сетевые карты стали поддерживать несколько очередей, линуксоиды вот тут доковырялись до фильтров прямо на карте и в драйвере карты: luca.ntop.org/IM2009_Tutorial.pdf
Про карты с FPGA мы уже как-то с вами обсуждали — они доступны и для PC-платформы.
Я понимаю, что разговаривая со мной сзади ввиде нимба отсвечивает значок рутера :)
Я пытаюсь смотреть шире одного производителя, ибо моя главная задача помогать людям делать правильные решения, оптимизированные более чем по одному параметру :)
Но всего знать невозможно, поэтому спрашиваю абсолютно без иронии, в рамках самообразования, ибо можно ужаснуться, насколько я ещё мало знаю :(
Я пытаюсь смотреть шире одного производителя, ибо моя главная задача помогать людям делать правильные решения, оптимизированные более чем по одному параметру :)
Но всего знать невозможно, поэтому спрашиваю абсолютно без иронии, в рамках самообразования, ибо можно ужаснуться, насколько я ещё мало знаю :(
Ok.
Насчет спуфинга: вот уже лет 5 исполнилось древним рекомендация от cisco про включение Reverce Path Forwarding максимально ближе к клиенту.
Что там происходит сейчас на практике? Неужели их все игнорируют?
Я просто не видел массового трафика с успешно подменяемым IP, кроме как фокус с DNS-серверами ( habrahabr.ru/blogs/linux/83202/)
Насчет спуфинга: вот уже лет 5 исполнилось древним рекомендация от cisco про включение Reverce Path Forwarding максимально ближе к клиенту.
Что там происходит сейчас на практике? Неужели их все игнорируют?
Я просто не видел массового трафика с успешно подменяемым IP, кроме как фокус с DNS-серверами ( habrahabr.ru/blogs/linux/83202/)
Рекомендации в нашей стране всем глубоко по… RPF довольно жручий при большом объеме трафика да и не все знают о несимметричном RPF, а симметричный очень строг к топологии.
Мало того, обязали же провайдеров делать фильтрацию по RFC2827! Уж куда проще! Один ACL в 2 строки… Так нет же — постоянно сталкиваюсь, что даже это не сделано…
Мало того, обязали же провайдеров делать фильтрацию по RFC2827! Уж куда проще! Один ACL в 2 строки… Так нет же — постоянно сталкиваюсь, что даже это не сделано…
Хм… против массовых запросов SYN по идее должны помогать syn cookies.
Возник вопрос относительно экономической эффективности атаки и её отражения:
Сколько стоит один запрос от ботнета? (На сколько я должен удешевить ответ, чтобы атака стала убыточной?).
Сколько стоит мегабайт паразитного трафика у DDoS'еров?
Сколько стоит один запрос от ботнета? (На сколько я должен удешевить ответ, чтобы атака стала убыточной?).
Сколько стоит мегабайт паразитного трафика у DDoS'еров?
хороший пассиврый ботнет почти ничего не стоит атакующему. Но есть плюс: такая атака мощная, но одноразовая.
А активный ботнет при нынешней дешевизне инета и компов тоже стоит копейки
А активный ботнет при нынешней дешевизне инета и компов тоже стоит копейки
«Почти ничего» и «копейки» — это сколько точно?
(палюсь)
50000р за 3 дня 7гбит/сек 300000 хостов
ЗЫ есличо, ботнет не мой. Я такую атаку отражал и мы производили анализ затрат. В прошлом году в феврале
Положить канал 100мбит/сек на день будет стоить наверно 5круб
50000р за 3 дня 7гбит/сек 300000 хостов
ЗЫ есличо, ботнет не мой. Я такую атаку отражал и мы производили анализ затрат. В прошлом году в феврале
Положить канал 100мбит/сек на день будет стоить наверно 5круб
Вот спасибо, это ценная информация.
Кстати, сколько запросов делали эти 300к хостов? Эта атака была нацелена на то, чтобы положить канал? Если так, то ещё интересно, сколько тратят атакующие при атаке, нацеленной на DoS из-за высокой нагрузки на сервер.
Пойду посчитаю, во сколько мне обходятся мегабайты трафика. =)
Кстати, сколько запросов делали эти 300к хостов? Эта атака была нацелена на то, чтобы положить канал? Если так, то ещё интересно, сколько тратят атакующие при атаке, нацеленной на DoS из-за высокой нагрузки на сервер.
Пойду посчитаю, во сколько мне обходятся мегабайты трафика. =)
Вам удалось сжать трафик помощью фильтрации? каково было значение?
Как я понимаю, фильтрация может позволить снизить паразитный трафик в 5 и более раз.
Достаточно сжать 7Гбит до 1Гбит/с и победа наша. Другой вопрос сколько нужно ресурсов для такой фильтрации.
1 Гбит/с в Москве стоит около 40т.р. в месяц — небольшая сумма для крупного проекта.
Как я понимаю, фильтрация может позволить снизить паразитный трафик в 5 и более раз.
Достаточно сжать 7Гбит до 1Гбит/с и победа наша. Другой вопрос сколько нужно ресурсов для такой фильтрации.
1 Гбит/с в Москве стоит около 40т.р. в месяц — небольшая сумма для крупного проекта.
У атакуемого клиента было 2 гигабитных канала.
Оба лежали. А также «зацепило» ещё кучку клиентов поменьше
Трафик был: http GET, DNS, ICMP, мусор
с http перешли на https (это была первая, слабенькая волна), остальное сильно урезали силами провайдера (за что было ему уплочено). ДДоС был на забивание канала, а не на убивание сервисов.
Паразитный трафик силами провадера и выкаченного Cisco GUARD был урезан в 15 раз
Оба лежали. А также «зацепило» ещё кучку клиентов поменьше
Трафик был: http GET, DNS, ICMP, мусор
с http перешли на https (это была первая, слабенькая волна), остальное сильно урезали силами провайдера (за что было ему уплочено). ДДоС был на забивание канала, а не на убивание сервисов.
Паразитный трафик силами провадера и выкаченного Cisco GUARD был урезан в 15 раз
>По результатам проведенного эксперимента ясно, что сервер способен выдержать увеличение атаки примерно до 300Мбит/с. Свыше 300Мбит/с мы «упремся» в предел рандомного чтения SAS дисков.
Откуда вывод, что это именно SAS? И откуда «рандомное» чтение, если страница одна и та же?
Откуда вывод, что это именно SAS? И откуда «рандомное» чтение, если страница одна и та же?
Год назад столкнулся с тем, что SAS диск не мог считывать более 50К блоков. В munin график IOstat на этом значении переходил в насыщение. Исходящий трафик был неболее 350 Мбит/с. Распределение нагрузки на второй SAS диск привело к увеличению исх. трафика.
Из этого я сделал вывод что SAS сможет гарантированно обеспечить 300 Мбит/с.
Но я не уточнил, к сожалению, что это примерное значение, и при отдачи только одной INDEX HTML оно может быть выше.
Из этого я сделал вывод что SAS сможет гарантированно обеспечить 300 Мбит/с.
Но я не уточнил, к сожалению, что это примерное значение, и при отдачи только одной INDEX HTML оно может быть выше.
Автора Cтатья очень хорошая отправная точка, на тему отражения дос атак.
При умелой сноровке атакующий будет дергать страницы с логикой, которая к примеру будет дергать базу данных (поиск, и т.д).
В расчет нужно брать особенности атаки, если боты еще будут по ssh долбить.
При умелой сноровке атакующий будет дергать страницы с логикой, которая к примеру будет дергать базу данных (поиск, и т.д).
В расчет нужно брать особенности атаки, если боты еще будут по ssh долбить.
на время атаки в iptables на канал можно было бы добавить delay 10-20ms, для пользователей это было бы не сильно заметно, но разгрузило бы процессор не думаю, что ботов натравили на статику :)
Подраздел «Недостатки поиска ботов командой netstat». Замените nestat => netstat
Ну и скрипты у вас. Вот тут:
cat /var/log/nginx/error.log | grep «limiting connections by zone» | grep «request: \»GET / HTTP/1.1"| awk '{print $12}'| awk -F"," '{print $Можно выкинуть cat, фильтрацию засунуть в awk и так далее.
1}'| sort | uniq -c | sort -nr > /tmp/botnet.blacklist
Нечто подобное делал на своём icecast сервере, чтоб никто не смог ретранслировать мой поток. Для этого просто банил всех с юзерагентом icecast. Самое простое решение, но сложность в том, что юзерагент можно увидеть только в логах (хотя потом я подправил код, но сейчас не об этом).
Долго думал как сделать, в итоге сделал нечто типа:
tail -F $icelog --pid=$workpid 2>/dev/null| $killscript
где в скрипте $killscript было:
while read line; do
ip=`echo -n "$line"|grep -v ".m3u" | grep -E «GET (/sourc......`
…
done < /dev/stdin
Не надо парсить каждый раз лог — всё делается на лету. В итоге с найденным ip-ом можно делать всё что угодно =)
зы. Кстати, интересная особенность была замечена моим знакомым в ботнетах — они как правило поддерживают редирект =) Можно редиректить ботов…
— зызы. кстати насчёт дисков — имхо надо стараться делать сайты, работающие по максимому в оперативке, тогда — оптимизация защиты от Ddos + неплохой канал в сочетании с сайтом в оперативке и любой ddos не страшен. Ну почти =)
Долго думал как сделать, в итоге сделал нечто типа:
tail -F $icelog --pid=$workpid 2>/dev/null| $killscript
где в скрипте $killscript было:
while read line; do
ip=`echo -n "$line"|grep -v ".m3u" | grep -E «GET (/sourc......`
…
done < /dev/stdin
Не надо парсить каждый раз лог — всё делается на лету. В итоге с найденным ip-ом можно делать всё что угодно =)
зы. Кстати, интересная особенность была замечена моим знакомым в ботнетах — они как правило поддерживают редирект =) Можно редиректить ботов…
— зызы. кстати насчёт дисков — имхо надо стараться делать сайты, работающие по максимому в оперативке, тогда — оптимизация защиты от Ddos + неплохой канал в сочетании с сайтом в оперативке и любой ddos не страшен. Ну почти =)
По моему гораздо проще и эффективнее переключить на время трафик на специализированный антиддос сервис.
Для небольших проектов, наверное, это выход. Но будут большие задержки — что затронет лояльность клиентов и SEO будет не в восторге.
Задержки как раз будут гораздо меньше чем в случае самостоятельного решения. Свой сервер будет разгружен, так как к нему не будет поступать паразитный трафик, а только отфильтрованный. И фильтровать профессионально и _заранее_ настроенная система антиддоса будет куда качественнее и с меньшим количеством ложных срабатываний.
А можно пример блок листа? Хочу маленько переделать :)
А как быть, если атака ведётся с целью забить входящий канал UDP-флудом? Я так понимаю, что UDP-пакет в любом случае доходит до сервера, даже если на нём порт никто не слушает, а это значит, что весь UDP-траффик, отправленный ботнетом, дойдёт до сервера.
Может ли помочь в фильтрации траффика сам ДЦ? Или ему тоже неохота работать с длинными списками правил?
Может ли помочь в фильтрации траффика сам ДЦ? Или ему тоже неохота работать с длинными списками правил?
Насколько я помню, никак. Разве что выяснить на какой айпишник идет атака, а потом прозвониться как можно дальше по пути к этому айпишнику из Интернет и попросить там прописать фильтр на запрет к айпишнику UDP-трафика. У провайдеров, сидящих на разных концах спутникового канала, иногда бывает между собой договор на такие случаи.
А почему провайдеры и хостеры не борются с ДДОСом? Ведь проще на уровне дата-центра банить ботов?
Извините, пожалуйста, за критику. Вы потратили силы на написание этой статьи, вложили в нее много усилий, но… но в вашей статье какое-то совершенно сказочное количество неточностей. :(
«На основе сервера Xeon 2.5GHz / 4Gb RAM / SAS можно отражать атаку примерно до 300 Мб»
Полоса трафика не имеет никакого значения для измерения мощности ДОС-атаки. Это же очевидно: заполнить и гигабит можно без малейшей нагрузки на сервер.
«Максимальная возможная мощность сдерживания DDoS атаки ограничивается физическими возможностями сервера и пропускной способностью канала.»
Капитан Очевидность?
«Если у сервера несколько IP то сайт под ДОСом ляжет, работа других сайтов на сервере и ssh нарушена не будет. „
Да ну? Неужели?
“По умолчанию ОС Debian и другие ОС не в состоянии поддерживать огромное количество соединений создаваемое ботнетом.»
Что такое «ОС» в данном случае? Это не вопрос операционной системы (набора прикладных программ), это уровень ядра (как вы дальше правильно заметили), фронтенда и бекенда.
«Аккуратно меняем конфигурацию ядра и перезагружаем сервер…»
После смены sysctl не нужно перегружаться.
«И так. Наша система способна выдержать натиск ботов.»
Да? уже?
«процессы PHP и БД полностью «съедают» ресурсы памяти и процессора, так что значение load average превышает 100 пунктов.»
LA не зависит напрямую ни от памяти, ни от процессора. По большому счету, это бессмысленный показатель.
«Эффективный поиск ботов возможен только при остановленном вебсервере»
Да? Вы видите в нетстате соединения на незапущенный сервис, не слушающий нужный порт? :)
«Свыше 300Мбит/с мы «упремся» в предел рандомного чтения SAS дисков.»
Вы действительно думаете:
a) что чтение одной странички сайта — это рандомное чтение?
b) что одна страничка каждый раз читается с диска?
Ну и дальше уже не читал…
«На основе сервера Xeon 2.5GHz / 4Gb RAM / SAS можно отражать атаку примерно до 300 Мб»
Полоса трафика не имеет никакого значения для измерения мощности ДОС-атаки. Это же очевидно: заполнить и гигабит можно без малейшей нагрузки на сервер.
«Максимальная возможная мощность сдерживания DDoS атаки ограничивается физическими возможностями сервера и пропускной способностью канала.»
Капитан Очевидность?
«Если у сервера несколько IP то сайт под ДОСом ляжет, работа других сайтов на сервере и ssh нарушена не будет. „
Да ну? Неужели?
“По умолчанию ОС Debian и другие ОС не в состоянии поддерживать огромное количество соединений создаваемое ботнетом.»
Что такое «ОС» в данном случае? Это не вопрос операционной системы (набора прикладных программ), это уровень ядра (как вы дальше правильно заметили), фронтенда и бекенда.
«Аккуратно меняем конфигурацию ядра и перезагружаем сервер…»
После смены sysctl не нужно перегружаться.
«И так. Наша система способна выдержать натиск ботов.»
Да? уже?
«процессы PHP и БД полностью «съедают» ресурсы памяти и процессора, так что значение load average превышает 100 пунктов.»
LA не зависит напрямую ни от памяти, ни от процессора. По большому счету, это бессмысленный показатель.
«Эффективный поиск ботов возможен только при остановленном вебсервере»
Да? Вы видите в нетстате соединения на незапущенный сервис, не слушающий нужный порт? :)
«Свыше 300Мбит/с мы «упремся» в предел рандомного чтения SAS дисков.»
Вы действительно думаете:
a) что чтение одной странички сайта — это рандомное чтение?
b) что одна страничка каждый раз читается с диска?
Ну и дальше уже не читал…
согласен — аффтар профан
И тем не менее он учится, делает, экспериментирует и скорее всего с таким подходом довольно скоро обгонит «умников_почивающих_на_лаврах_прошлого_опыта». Я не вас имею ввиду.
И не боится сюда написать, под стрелы критиков, которые пишу «КГ/АМ», а не развернуто описывают свои возражения. Неужто так сложно указать явно на неточности/ошибки? Или сами не знаете?
В любом случае автор заслуживает уважения, ИМХО.
И не боится сюда написать, под стрелы критиков, которые пишу «КГ/АМ», а не развернуто описывают свои возражения. Неужто так сложно указать явно на неточности/ошибки? Или сами не знаете?
В любом случае автор заслуживает уважения, ИМХО.
спасибо за комментарий
Постараюсь ответить также подробно.
1. "“По умолчанию ОС Debian и другие ОС не в состоянии поддерживать " —
по умолчанию ядро не предназначено работать в условиях большого кол-ва паразитных соединений и при DoS множество не закрытых сокетов создаст дефицит свободной ОЗУ. И прежде всего нужно настроить ядро и потом перейти к фронтэнду, бекэнду.
2. «После смены sysctl не нужно перегружаться» — верно! Исправлю соотв. абзац.
3. «LA не зависит напрямую ни от памяти, ни от процессора. По большому счету, это бессмысленный показатель.»
— я не согласен с вами. LA — это результирующий показатель состояния ЦП, ОЗУ, Дисков.
4. " Вы видите в нетстате соединения на незапущенный сервис, не слушающий нужный порт? :) "
— остановил nginx и выполнил netstat
5. «Свыше 300Мбит/с мы «упремся» в предел рандомного чтения SAS дисков.» — справедливо для HDD отдающего видео/аудио, т.е. «тяжелые» файлы. Для HTML файлов это утверждение несправедливо.
убрал из текста это абзац.
6. «Ну и дальше уже не читал…»
— прочитайте до конца, пожалуйста, возможно у вас появятся другие конструктивные замечания
Постараюсь ответить также подробно.
1. "“По умолчанию ОС Debian и другие ОС не в состоянии поддерживать " —
по умолчанию ядро не предназначено работать в условиях большого кол-ва паразитных соединений и при DoS множество не закрытых сокетов создаст дефицит свободной ОЗУ. И прежде всего нужно настроить ядро и потом перейти к фронтэнду, бекэнду.
2. «После смены sysctl не нужно перегружаться» — верно! Исправлю соотв. абзац.
3. «LA не зависит напрямую ни от памяти, ни от процессора. По большому счету, это бессмысленный показатель.»
— я не согласен с вами. LA — это результирующий показатель состояния ЦП, ОЗУ, Дисков.
4. " Вы видите в нетстате соединения на незапущенный сервис, не слушающий нужный порт? :) "
— остановил nginx и выполнил netstat
tcp 0 0 77.21.155.100:80 91.77.35.87:1674 TIME_WAIT tcp 0 0 77.21.155.100:80 79.139.231.33:52911 TIME_WAIT tcp 0 0 77.21.155.101:80 94.41.251.59:1365 TIME_WAIT
5. «Свыше 300Мбит/с мы «упремся» в предел рандомного чтения SAS дисков.» — справедливо для HDD отдающего видео/аудио, т.е. «тяжелые» файлы. Для HTML файлов это утверждение несправедливо.
убрал из текста это абзац.
6. «Ну и дальше уже не читал…»
— прочитайте до конца, пожалуйста, возможно у вас появятся другие конструктивные замечания
1. Верно, и ОС тут непричем. Я об этом и говорю.
3. Это не дискуссионный вопрос, чтобы быть согласным или не согласным. LA — это среднее количество процессов, готовых к исполнению в данный период диспетчеризации процессов. Это число нужно только теоретикам-строителям ОС и разработчиками диспетчеризации и больше никому. Я могу вам нарисовать LA 800, но машинка при этом будет фактически простаивать, ничего не делая. И обратное верно — я могу вам при LA 0.10 сделать машину совершенно неживой, полностью загруженной.
4. И?
5. И все равно там не будет рандомного чтения. RTFM sendfile, aio.
…
7. " У сервера не было встроенного KVM и пересобрать ядро было рискованно."
Это не причина и следствие. Тот факт, что у сервера нет KVM (встроенного или внешнего, что совершенно неважно) не является источником риска для пересборки (а на самом деле — для перезагрузки нового) ядра. Источник риска при пересборке ядра — это недостаток знания. Умный человек знает, как правильно пересобрать ядро, а очень умный человек знает, как перезагрузить машинку в новое ядро так, чтобы в случае любых неприятностей она сама снова перезагрузилась в старое, проверенное ядро.
8. kill -USR1 `cat /var/run/nginx.pid`
Чрезвычайно опасная конструкция. Надо делать хотябы что-то типа ps ax | grep `cat /var/run/nginx.pid` | grep «nginx: master» && kill -1 `cat /var/run/nginx.pid`
9. Добавляем скрипт в крон с частотой несколько минут
Ага, и на фоне дико засранной машины каждые пять минут будем порождать новый процесс. Это не то чтобы принципиально важно, но такие вещи лучше делать в цикле:
while (:)
do
код
sleep 60
done
10. «Заказчик должен потрать, например, 50 000 руб. чтобы нанести вам ущерб в 50 000руб»
Пошуршите по инету в поисках стоимости организации DDoS атак. Результаты вас удивят.
11. «исходящий трафик с последнем случаем превысил 100 Мбит/с. Значит, сервер подключенный к порту 100 Мбит/с станет очень трудно доступен по ssh в силу полной загруженности канала»
Мне однажды удалось заполнить стомегабитный канал так, чтобы туда даже ssh не пролазил. Это было около 20000 (тысяч!) одновременно открытых входящих соединений на веб, это был веб-сканер кое-чего. Одним, десятью, сотней одновременных tcp-соединений канал так убить нельзя в силу специфики работы tcp. ssh всегда пролезет. Если ssh не пролазит, то это не сеть, это другой ресурс занят. Реально обычно это диски.
12. «Считаем клиентов открывших более 3х одновременных соединений атакующими ботами и баним их IP адресы на фаерволе.»
Ага. Проще говоря, всех пользователей, да. Вы имели в виду не одновременно открытые соединения (их практически всегда 4+), а одновременных соеднений, запрашивающих один и тот же ресурс (/).
13. «При количестве цепочек >2К iptables»… «Для отражения атаки >7К ботнета вполне достаточно возможностей iptables»
14. «DDoS как стихийное бедствие и избежать ущерба невозможно.»
And that's the point! Грамотно организованный DDoS практически невозможно отразить. 120K ip адресов, из которых 19 одновременно держали открытые соединения — это детский сад а не DDoS. :)
3. Это не дискуссионный вопрос, чтобы быть согласным или не согласным. LA — это среднее количество процессов, готовых к исполнению в данный период диспетчеризации процессов. Это число нужно только теоретикам-строителям ОС и разработчиками диспетчеризации и больше никому. Я могу вам нарисовать LA 800, но машинка при этом будет фактически простаивать, ничего не делая. И обратное верно — я могу вам при LA 0.10 сделать машину совершенно неживой, полностью загруженной.
4. И?
5. И все равно там не будет рандомного чтения. RTFM sendfile, aio.
…
7. " У сервера не было встроенного KVM и пересобрать ядро было рискованно."
Это не причина и следствие. Тот факт, что у сервера нет KVM (встроенного или внешнего, что совершенно неважно) не является источником риска для пересборки (а на самом деле — для перезагрузки нового) ядра. Источник риска при пересборке ядра — это недостаток знания. Умный человек знает, как правильно пересобрать ядро, а очень умный человек знает, как перезагрузить машинку в новое ядро так, чтобы в случае любых неприятностей она сама снова перезагрузилась в старое, проверенное ядро.
8. kill -USR1 `cat /var/run/nginx.pid`
Чрезвычайно опасная конструкция. Надо делать хотябы что-то типа ps ax | grep `cat /var/run/nginx.pid` | grep «nginx: master» && kill -1 `cat /var/run/nginx.pid`
9. Добавляем скрипт в крон с частотой несколько минут
Ага, и на фоне дико засранной машины каждые пять минут будем порождать новый процесс. Это не то чтобы принципиально важно, но такие вещи лучше делать в цикле:
while (:)
do
код
sleep 60
done
10. «Заказчик должен потрать, например, 50 000 руб. чтобы нанести вам ущерб в 50 000руб»
Пошуршите по инету в поисках стоимости организации DDoS атак. Результаты вас удивят.
11. «исходящий трафик с последнем случаем превысил 100 Мбит/с. Значит, сервер подключенный к порту 100 Мбит/с станет очень трудно доступен по ssh в силу полной загруженности канала»
Мне однажды удалось заполнить стомегабитный канал так, чтобы туда даже ssh не пролазил. Это было около 20000 (тысяч!) одновременно открытых входящих соединений на веб, это был веб-сканер кое-чего. Одним, десятью, сотней одновременных tcp-соединений канал так убить нельзя в силу специфики работы tcp. ssh всегда пролезет. Если ssh не пролазит, то это не сеть, это другой ресурс занят. Реально обычно это диски.
12. «Считаем клиентов открывших более 3х одновременных соединений атакующими ботами и баним их IP адресы на фаерволе.»
Ага. Проще говоря, всех пользователей, да. Вы имели в виду не одновременно открытые соединения (их практически всегда 4+), а одновременных соеднений, запрашивающих один и тот же ресурс (/).
13. «При количестве цепочек >2К iptables»… «Для отражения атаки >7К ботнета вполне достаточно возможностей iptables»
14. «DDoS как стихийное бедствие и избежать ущерба невозможно.»
And that's the point! Грамотно организованный DDoS практически невозможно отразить. 120K ip адресов, из которых 19 одновременно держали открытые соединения — это детский сад а не DDoS. :)
4. Считаем всех у кого более одного подключения ботами.
5. Как назвать чтение с диска одновременно 2К файлов?
7. Верно. Я скажу так «Отсутствовал опыт остановки ipset. Без КВМ пересобирать ядро было слишком рисковано.»
8.
взял из
9. согласен. Доработаю скрипт.
10. DoS за 5 т.р. должен нестрашен изначально.
11. тут не экспериментировал. сделал предположение.
12. над этим предложением приведен кусок конфига где
14. Все зависит от возможностей сторон атакующей и отражающей. В войнах же побеждали, и не всегда самые «грамотно организованные».
5. Как назвать чтение с диска одновременно 2К файлов?
7. Верно. Я скажу так «Отсутствовал опыт остановки ipset. Без КВМ пересобирать ядро было слишком рисковано.»
8.
[ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`
взял из
/etc/logrotate.d/nginxстандартный скрипт ротации логов Debian.
9. согласен. Доработаю скрипт.
10. DoS за 5 т.р. должен нестрашен изначально.
11. тут не экспериментировал. сделал предположение.
12. над этим предложением приведен кусок конфига где
location =/
14. Все зависит от возможностей сторон атакующей и отражающей. В войнах же побеждали, и не всегда самые «грамотно организованные».
Верно ли я сделал, что исправил строчку:
на
т.к. писалось "
но у меня еще одна ошибка:
как от нее избавиться?
awk '{print "iptables -A INPUT -p tcp --dport 80 -s " $2 " -j DROP" }' botnet.blacklist | head -n 50 >> /tmp/iptables_ban.shна
awk '{print "iptables -A INPUT -p tcp --dport 80 -s " $2 " -j DROP" }' /tmp/botnet.blacklist | head -n 50 >> /tmp/iptables_ban.shт.к. писалось "
awk: cannot open botnet.blacklist (No such file or directory)"но у меня еще одна ошибка:
awk: line 1: syntax error at or near end of lineкак от нее избавиться?
походу ошибка из-за пустого
видимо скрипт как-то не правильно берет лог ошибок ((
может кто подскажет, как его подправить, если лог выглядит так:
в первой строке скрипта я уже поменял на «GET / HTTP/1.0» но результат тот же
botnet.blacklistвидимо скрипт как-то не правильно берет лог ошибок ((
может кто подскажет, как его подправить, если лог выглядит так:
2013/11/26 13:58:15 [error] 737#0: *16080 limiting connections by zone "perip", client: 91.191.234.194, server: mysite.ru, request: "GET / HTTP/1.0", host: "mysite.ru", referrer: "http://mysite.ru/"
2013/11/26 13:58:15 [error] 737#0: *16077 limiting connections by zone "perip", client: 91.191.234.194, server: mysite.ru, request: "GET / HTTP/1.0", host: "mysite.ru", referrer: "http://mysite.ru/"
2013/11/26 13:58:15 [error] 737#0: *16081 limiting connections by zone "perip", client: 91.191.234.194, server: mysite.ru, request: "GET / HTTP/1.0", host: "mysite.ru", referrer: "http://mysite.ru/"
2013/11/26 13:58:15 [error] 737#0: *16038 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 91.191.234.194, server: mysite.ru, request: "GET / HTTP/1.0", upstream: "http://127.0.0.1:3000/", host: "mysite.ru", referrer: "http://mysite.ru/"
2013/11/26 13:58:15 [error] 737#0: *16035 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 91.191.234.194, server: mysite.ru, request: "GET / HTTP/1.0", upstream: "http://127.0.0.1:3000/", host: "mysite.ru", referrer: "http://mysite.ru/"
2013/11/26 13:58:15 [error] 737#0: *16023 connect() failed (110: Connection timed out) while connecting to upstream, client: 91.191.234.194, server: mysite.ru, request: "GET / HTTP/1.0", upstream: "http://127.0.0.1:3000/", host: "mysite.ru", referrer: "http://mysite.ru/"
2013/11/26 13:58:17 [error] 737#0: *16082 limiting connections by zone "perip", client: 91.191.234.194, server: mysite.ru, request: "GET / HTTP/1.0", host: "mysite.ru", referrer: "http://mysite.ru/"
2013/11/26 13:58:19 [error] 737#0: *16051 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 91.191.234.194, server: mysite.ru, request: "GET / HTTP/1.0", upstream: "http://127.0.0.1:3000/", host: "mysite.ru", referrer: "http://mysite.ru/"
2013/11/26 13:58:19 [error] 737#0: *16090 limiting connections by zone "perip", client: 91.191.234.194, server: mysite.ru, request: "GET / HTTP/1.0", host: "mysite.ru", referrer: "http://mysite.ru/"
в первой строке скрипта я уже поменял на «GET / HTTP/1.0» но результат тот же
Сам нашел причину неработоспособности скрипта (
1) ддосят так, что /var/log/nginx/error.log у меня на несколько сотен гигов (сам в шоке), причем у меня он создается ежедневно новый, а старый архивируется… И соответственно, нужно много времени на сканирование этого файла…
2) ддосят так, что система виснет и скрипт тупо сам висит (
возможно целесообразнее не логи читать каждый раз, а смотреть какие соединения вообще есть? Например:
Подскажите, если этот способ лучше, то как его применить к данному скрипту?
1) ддосят так, что /var/log/nginx/error.log у меня на несколько сотен гигов (сам в шоке), причем у меня он создается ежедневно новый, а старый архивируется… И соответственно, нужно много времени на сканирование этого файла…
2) ддосят так, что система виснет и скрипт тупо сам висит (
возможно целесообразнее не логи читать каждый раз, а смотреть какие соединения вообще есть? Например:
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
Подскажите, если этот способ лучше, то как его применить к данному скрипту?
настрой ротацию лога /var/log/nginx/error.log каждые 5-10 мин. Так чтобы поддерживать небольшой размер лога. Не архивируй старые — нет смысла.
у меня в /etc/logrotate.d/nginx:
как его еще настроить можно?
Сайт все равно вешается (( Поработает полчасика и все…
пришлось даже ставить каждые полчаса перезагрузку сервака (
может все-таки как-нить так сделать? лучше будет ли?
/var/log/nginx/*.log {
daily
missingok
rotate 9
compress
delaycompress
notifempty
create 640 root adm
sharedscripts
postrotate
[ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`
endscript
}
как его еще настроить можно?
Сайт все равно вешается (( Поработает полчасика и все…
пришлось даже ставить каждые полчаса перезагрузку сервака (
может все-таки как-нить так сделать? лучше будет ли?
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr
Вложу свою копейку.
Собираю из nginx access.log ошибки
потом тех кто сгенерил больше 10 ошибок
вариант с количеством ошибок мне кажется интереснее, чем 50 самых агрессивных.
Собираю из nginx access.log ошибки
grep -E ' 499 [0-9]| 500 [0-9]| 502 [0-9]| 503 [0-9]| 504 [0-9]' $LOGFILEпотом тех кто сгенерил больше 10 ошибок
awk '{if ($1>10)print "iptables -A INPUT -p tcp --dport 80 -s " $2 " -j DROP";}' $BOTSLIST > $SHвариант с количеством ошибок мне кажется интереснее, чем 50 самых агрессивных.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Простой и эффективный метод отразить http DDoS от 50мбит с помощью nginx и iptables