0,0
рейтинг
14 февраля 2010 в 09:16

Разработка → Простой и эффективный метод отразить http DDoS от 50мбит с помощью nginx и iptables

Здравствуй, Хабр!
Предлагаю твоему вниманию простой и в то же время эффективный метод борьбы с http DDoS. На основе сервера Xeon 2.5GHz / 4Gb RAM / SAS можно отражать атаку примерно до 300 Мбит/с (значение получено методом экстраполяции).

Способ реализация

Производится тонкая настройка параметров системы. Так что север будет способен выдерживать больше подключений от ботнета, чем канал до сервера сможет пропустить.

Область применения

Борьба с Http DDoS на выделенном сервере или ВПС. Максимальная возможная мощность сдерживания DDoS атаки ограничивается физическими возможностями сервера и пропускной способностью канала.

SEO под DDoS-ом

Ваш сайт будет правильно индексироваться во время атаки, что позволит сохранить позиции в выдаче поисковых систем. Особенно актуально для сайтов с большими SEO бюджетами.

Стоимость и эффективность

На время атаки придется отказаться от некоторых сервисов вашего сайта. Возможно, придется расширить полосу канала, перенести сайт на более мощный сервер. Эффективность достигается максимизацией коэффициента масштабируемости системы. Обеспечивается быстрое наращивание аппаратных ресурсов при увеличении мощности атаки.

Описание метода

Я буду рассказывать о применение метода и достигнутых результатах, на основе реального случай борьбы с http DDoS атакой.

В моем распоряжении было два сервера Xeon 2.5GHz / 4Gb RAM / SAS, первый под PHP, второй под БД. Все настройки производились на первом сервере.ОС – Debian 4, сайт был с посещаемостью ~ 60к. Фронтендом являлся nginx. Ядро системы было настроено по умолчанию. Стандартное средство бана по ip – iptables в конкретном случае справилось с атакой ботнета размером до 7К.
В случае более мощной атаки придется установить ipset.

История борьбы с DDoS


День первый. Переполнение сетевого стека

IP адрес выделенный под ДОСом перестанет отвечать на какие-либо запросы (ping,http,ssh), при том что остальные IP сервера продолжат исправно работать. Если у сервера несколько IP то сайт под ДОСом ляжет, работа других сайтов на сервере и ssh нарушена не будет.
По умолчанию ОС Debian и другие ОС не в состоянии поддерживать огромное количество соединений создаваемое ботнетом. Необходимо внести изменения в настройки ядра, чтобы укрепить стек TCP/IP. Я не буду подробно останавливается на настройке ядра, приведу лишь пример такой конфигурации.

net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.eth0.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.core.rmem_max = 996777216
net.core.wmem_max = 996777216
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4.tcp_mem= 786432 1048576 996777216
net.ipv4.tcp_wmem = 4096 87380 4194304
net.ipv4.tcp_max_orphans = 2255360
net.core.netdev_max_backlog = 10000
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 494967295
kernel.shmall = 268435456
net.core.somaxconn= 16096


Подобнее о параметрах можно прочитать в документации, например debian.telenet.ru/doc/sysctl.conf, а лучше поиск через google.com свежих статей по данной теме.
Аккуратно меняем конфигурацию ядра и перезагружаем сервер…
И так. Наша система способна выдержать натиск ботов. Но праздновать победу еще очень рано. Из-за огромного количества соединений процессы PHP и БД полностью «съедают» ресурсы памяти и процессора, так что значение load average превышает 100 пунктов.
Необходимо отсечь паразитные соединения

Недостатки поиска ботов командой netstat

Анти-дос администратор, к которому я обратился с проблемой, предложил метод поиска ботов командой netstat. В процессе применения данного метода я заметил несколько существенных недостатков. Рассмотрим их подробно:
1. Создание blacklist-а занимает много времени, что не позволяет нам часто обновлять blacklist
2. Эффективный поиск ботов возможен только при остановленном вебсервере. В это время сайт не доступен для клиентов и появляется угроза неправильной индексации сайта поисковыми системами
3. В blacklist могут попасть IP поисковых роботов, что недопустимо

Осознав неэффективность предложенного метода, я приступил к созданию своего метода поиска и бана ботов который должен
1. обеспечить постоянную стабильную работу вебсервера (сайта)
2. гарантирует наименьшую вероятность в blacklist поисковых роботов

День второй. Возможности железа сервера + nginx

Сервер Xeon 2.5GHz / 4Gb RAM / SAS DoS-ят запросами GET / HTTP/1.1.
  1. Эксперимент А. Веб сервер (в данном случае nginx) остановлен
    Входящий трафик 6085.2 kbits/sec
    Исходящий трафик 5342.1 kbits/sec
  2. Эксперимент Б. Nginx отдает пустой HTML (return 444;)
    Входящий трафик 56 Мбит/с
    Исходящий трафик 54 Мбит/с
  3. Эксперимент В. Nginx отдает HTML размером около 2 Кб – это страничка с небольшим сообщением вроде «приносим свои извинения за перебои в работе сайта»
    Входящий трафик 57 Мбит/с
    Исходящий трафик 353 Мбит/с

<… >*

На основе эксперимента можно сделать следующие выводы:

а) Можно полностью отказаться от фильтрации при наличии достаточной емкости канала и отсутствием соотношений входящий/исходящий трафик.
Ваш сайт будет доступен клиентам ценой огромного паразитного трафика.
Легкомысленное решение полностью отказаться от фильтрации. Злоумышленники могу увеличить мощность DoS так что «ляжет» гигабитный канал.

б) Когда мы забаним абсолютно всех ботов то паразитный трафик от ботнета составит всего лишь 5 Мбит/с. Забанить всех ботов также невозможно, на это потребуется слишком много ресурсов. Кроме того, высока вероятность бана поисковых роботов.

Также необходимо обратить внимание на то, что исходящий трафик с последнем случаем превысил 100 Мбит/с. Значит, сервер подключенный к порту 100 Мбит/с станет очень трудно доступен по ssh в силу полной загруженности канала. Во избежание подобной неприятности, я рекомендую настроить отдачу пустого HTML или return 444 в nginx до завершения настройки фильтрации ботов.

Поиск ботов средствами nginx

В данном случае сервер атакуют запросами request: «GET / HTTP/1.1».
Делаем предположение о том, что хорошие клиенты делают не более 2х одновременных запросов к главной странице сайта. Считаем клиентов открывших более 3х одновременных соединений атакующими ботами и баним их IP адресы на фаерволе.

Предположение было подтверждено экспериментально. На основе анализа лога http запросов за сутки из 120 000 IP адресов, только с 19ти IP было сделано более 2х одновременных запросов.

Для реализации поиска ботов создаем специальную обработку запросов
request: «GET / HTTP/1.1» в nginx.
error_log /var/log/nginx/error.log;
<…>
location =/ {
limit_conn one 3;
root /home/www/site.ru;
}

IP адреса с которых было открыто более 3х одновременных подключений буду записаны в error.log с сообщением limiting connections by zone. На основе лога ошибок мы сможем построить blacklist ip атакующего ботнета.

Фильтрация ботов в iptables

Важно заметить. IPtables не пригодны для фильтрации большого количества адресов. При количестве цепочек >2К iptables процесс ksoftirqd начинает потреблять 100% CPU, что приводит к запредельной загрузке сервера. Проблема решается установкой ipset или уменьшением количество правил в iptables.
В данном случае установка ipset была отложена на случай крайней необходимости. У сервера не было встроенного KVM и пересобрать ядро было рискованно.

Приступим к созданию blacklist-а. В бан мы помеcтим только самых агрессивных ботов, дабы не перегружать iptables.

# ищем ботов
cat /var/log/nginx/error.log | grep "limiting connections by zone" | grep "request: \"GET / HTTP/1.1"| awk '{print $12}'| awk -F"," '{print $
1}'| sort | uniq -c | sort -nr > /tmp/botnet.blacklist
# очищаем скрипт бана
cat /dev/null > /tmp/iptables_ban.sh
# создаем DROP правила для 50 самых агрессивных ботов
awk '{print "iptables -A INPUT -p tcp --dport 80 -s " $2 " -j DROP" }' botnet.blacklist | head -n 50 >> /tmp/iptables_ban.sh
# загружаем blacklist
bash /tmp/iptables_ban.sh
# делаем ротацию лога
cat /dev/null > /home/www/nginx_log/error.log
[ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`


Добавляем скрипт в крон с частотой несколько минут. Частоту подбираем опытным путем. Я сделал раз в 5 минут.

*/5 * * * * /root/script/ban.sh

В результате iptables будет пополнятся новыми ботами.

Схема фильтрации
ddos nginx iptables

День третий. Итог


Данный метод обеспечил стабильный доступ клиентов к сайту. Правильная индексация в ПС была подтверждена тем, что сайт сохранил свои позиции в выдаче. Загрузка сервера не выходила за разумные пределы la неболее 6-7 пунктов. Исходящий трафик с сервера не превышал 100 Мбит/с. Для отражения атаки >7К ботнета вполне достаточно возможностей iptables.

DDoS как стихийное бедствие и избежать ущерба невозможно.
Часть клиентов, за время сбоя вашего сервиса, перейдет к конкурентам.
Вам придется понести некоторые расходы на переработки программистов, администраторов или приобретение дополнительного оборудования.
Ваш ресурс активно продвигается в ПС (yandex, google) значит, критичен риск неправильной индексации и как результат провал позиций в выдаче.
Главная задача минимизировать ущерб от DDoS.

В моем случае DDoS атака прекратилась на следующий день после запуска фильтрации. Заказчик DoS не был готов тратить больше денег на увеличение атаки.

В большинстве случаев DDoS является оружием конкурентной борьбы в сети. Клиенты практически мгновенно способны перейти к вашим конкурентам, если ваш ресурс будет работать со сбоями.

Я считаю, что борьба с DDoS заключается не в бане ботов, а в создании условий в которых ваш суммарный ущерб от атаки сопоставим с затратами ее инициаторов. Заказчик должен потрать, например, 50 000 руб. чтобы нанести вам ущерб в 50 000руб., конкурентам экономически не выгодно организовывать такие атаки.

Метод описанный в этой статье не является панацеей, это лишь часть комплекса мер по отражению DoS. План развития крупного сервиса должен учитывать риски и предлагать меры по уменьшению негативных последствий атак.

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

___
* Я убрал из текста абзац про 300Мбит, т.к. он обоснованно вызывает нарекания.

«Свыше 300Мбит/с мы «упремся» в предел...» — справедливо для HDD отдающего видео/аудио, т.е. «тяжелые» файлы. Для HTML файлов это утверждение несправедливо.

Текст удаленного абзаца:
«По результатам проведенного эксперимента ясно, что сервер способен выдержать увеличение атаки примерно до 300Мбит/с. Свыше 300Мбит/с мы «упремся» в предел рандомного чтения SAS дисков. Значит, мы имеем хороший запас прочности и высока вероятность эффективного отражения атаки с сохранением доступности клиентам наших вебсервисов.»
Алексей Кузьмин @AlekseyKuzmin
карма
103,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (78)

  • НЛО прилетело и опубликовало эту надпись здесь
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      и тогда исходящий трафик превысит все ваши самые смелые ожидания)
  • НЛО прилетело и опубликовало эту надпись здесь
  • +4
    В принципе похожие методы уже обсуждались на Хабре, но у вас так развернуто вышло. Спасибо.

    И перенесите наверное пост в тематику.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    IPtables не пригодны для фильтрации большого количества адресов.

    Зато у IPtables есть отличное расширение ipset (из patch-o-matic)
    Легко собирается в виде модуля и заворачивается в rpm. Без пересборки ядра.
    Кроме того сразу получаете автоматическую очистку старых правил через заданное при добавлении количество времени.
    • 0
      В данном случае установка ipset была отложена на случай крайней необходимости. У сервера не было встроенного KVM и пересобрать ядро было рискованно.
  • +11
    Во-первых боты уже давно не делают тупой GET / и ходят по сайту с активностью человека, не чаще одного запроса в минуту
    Во-вторых тупых ботов-дятлов можно легко банить без логов и их анализа, чисто iptables подробности на hostinghelp.biz/content/ddos-что-делать-если-сервер-только-один-linux-с-apache
    И да, если долбят главную — то можно отдавать редирект через хедеры, тупоботы его не делают

    P.S. Цена ботнета сейчас — копейки, их часто воруют у создателей.
    • 0
      + cookies, js проверки
    • 0
      С точки зрения SEO редиректы приведут в неправильной индексации сайта в Яндексе, Гугле и др ПС.
      Я стремился обеспечить неизменную структуру сайта как для людей, так и для поисковиков.

      С ботами которые маскируются под ПС будет очень сложно бороться.

  • –4
    Эх, ещё бы придумать, как с такими ублюдками бороться методом пробития печени…

    Ведь мы знаем, кто заказчик? Ближайшие конкуренты!

    Далее — уже дело техники и оперативных товарищей.

    И здесь даже как-то больше удовлетворения, когда ты осознаешь, что с другой стороны товарища прикладывают головой в пол и он «я больше так не бууудуу!».

    Кароче надо управление «К» развивать — бюджеты ему подгонять и спецов.
    • НЛО прилетело и опубликовало эту надпись здесь
      • НЛО прилетело и опубликовало эту надпись здесь
      • –5
        А Вы (обратите внимание на регистр букв в «Вы») одобряете DDOS-атаки? Тогда Вас за сочувствие злу можно привлечь.

        Конечно я садист! Только по отношению к злу. Вы ведь в курсе, что добро всегда побеждает зло, ставит его на колени и мерзко насилует?

        А вот про безопасность — это как раз то, что мне мало нравится. Проблемы я обычно предпочитаю решать в корне — именно этим государство и хорошо. Если у нас школу захватили терористы, то это не значит, что нам надо в брониках всем ходить и конючить о разрешении оружия (хотя я за оружие и здесь бы тоже поканючил)? Если такое случается, то надо проблему в корне решать, методом уничтожения опасных товарищей.

        В госудуме сидят вааще андроиды, так что здесь я бы попросил не обобщать :)

        // Да забейте Вы на орфографии :)

        Кароче суть и непонимание в Вашей интравертности и моей экстравертности — я предпочитаю корень проблемы и социальный подход, а Вы — последствия проблемы и технический. Вот и весь холивар.
      • –3
        Спасибо за минус в писькометр :)

        Это подтверждение моей правоты, которая Вам аж глаза режет.
        • НЛО прилетело и опубликовало эту надпись здесь
          • +1
            О, простите, тогда поставьте мне плюс :)

            Корень просто в месте решения — я предлагаю в начале, т.е. в эпицентре, а Вы — в конце, т.е. уже ближе к бункеру.

            А вообще-то в этой системе Ваши слова не доказуемы (да как и мои тоже :), так что беседа становится пацанячьей :)
            • НЛО прилетело и опубликовало эту надпись здесь
              • 0
                Блин, занятная штука!

                Я что-то подобное подозревал и аксиомы мне как-то никогда не нравились.
  • +3
    Сейчас уже хорошие ддосы направлены не на то, чтобы завалить сервак, а на то, чтобы:

    1. Забить канал.
    2. Опустить хозяина сайта на бабки за паразитный трафик.
    • 0
      да, верно. И забивается канал на счет раз:(
      это сейчас стои копейки… Дает прекрасный шанс провайдерам заработать на услуге фильтрации ДДоСа забивающего канал
  • 0
    # создаем DROP правила для 50 самых агрессивных ботов
    # загружаем blacklist

    Я сделал раз в 5 минут.


    Ну-ну. Ошибка #1 при использовании больших набором правил в iptables. Через сутки в одной цепочке будет уже 24*60/5 * 50 ~ 14K правил. И каждых 5 минут сервер будет бешено тормозить где-то минуту. Почему? Потому что ядро умеет обновлять только таблицы целиком (в атомарной тразакции). Скрипт с 50 вызовами iptables сделает 50 транзакций, во время каждой из которых таблица с тысячами записей сначала будет перекачана из ядра в юзерспейс, а затем обратно.

    man iptables-restore
    • 0
      тут все зависит величины от ботнета.
      Если ботнет будет более 10К, то придется чистить таблицы iptables, агрегировать правила и ставить ipsec
      • 0
        s/ipsec/ipset/
        • 0
          спасибо — правильно ipset
  • 0
    Спасибо за интересную статью! Она неплохо описывает базовые проблемы сервера под ДДоСом

    Мне, как сетевику, очень интересны методы борьбы с ДДоСом ибо толь вместе можно минимизировать потери

    хочу спросить: какие атаки можно таким образом отразить? Например, часто атаки ДДоС по опыту проводятся часто с одни обращением с хоста. Несколько обращений нужно если ботнет махонький ;)

    и еще: наверно надо готовиться к следующей волне гибрида ДоС-ДДоС
    Атаку тут пытался отразить — фиг получилось!
    А идея проста: засылается массово запросы SYN и сразу с того же хоста ACK и FIN
    Сервер начинает сходить с ума
    • 0
      То есть nginx не может блокировать потому что нет зоны и http-запроса как такового?
      Что-то подобное было. Взял tcpdump, выбрал фильтром только syn-пакеты, соорудил сенсор и блокировщик.
      • 0
        Запросов было реально много, т.к. можно делать спуфинг адреса источника.(сотни миллионов в секунду)
        И фильтр по SYN наверняка можно сделать, только он же и забьет проц до смерти…

        Впрочем, спасибо за идею: подготовлюсь теоретически.
        • 0
          А в цисках как-будто процессора нет?
          Вообще, опасения ваши имеют почву, но прогресс на месте не стоит. Сетевые карты стали поддерживать несколько очередей, линуксоиды вот тут доковырялись до фильтров прямо на карте и в драйвере карты: luca.ntop.org/IM2009_Tutorial.pdf
          Про карты с FPGA мы уже как-то с вами обсуждали — они доступны и для PC-платформы.
          • 0
            Я понимаю, что разговаривая со мной сзади ввиде нимба отсвечивает значок рутера :)

            Я пытаюсь смотреть шире одного производителя, ибо моя главная задача помогать людям делать правильные решения, оптимизированные более чем по одному параметру :)

            Но всего знать невозможно, поэтому спрашиваю абсолютно без иронии, в рамках самообразования, ибо можно ужаснуться, насколько я ещё мало знаю :(
            • 0
              Ok.
              Насчет спуфинга: вот уже лет 5 исполнилось древним рекомендация от cisco про включение Reverce Path Forwarding максимально ближе к клиенту.
              Что там происходит сейчас на практике? Неужели их все игнорируют?
              Я просто не видел массового трафика с успешно подменяемым IP, кроме как фокус с DNS-серверами ( habrahabr.ru/blogs/linux/83202/)
              • 0
                Рекомендации в нашей стране всем глубоко по… RPF довольно жручий при большом объеме трафика да и не все знают о несимметричном RPF, а симметричный очень строг к топологии.

                Мало того, обязали же провайдеров делать фильтрацию по RFC2827! Уж куда проще! Один ACL в 2 строки… Так нет же — постоянно сталкиваюсь, что даже это не сделано…
    • 0
      Хм… против массовых запросов SYN по идее должны помогать syn cookies.
  • 0
    Возник вопрос относительно экономической эффективности атаки и её отражения:
    Сколько стоит один запрос от ботнета? (На сколько я должен удешевить ответ, чтобы атака стала убыточной?).
    Сколько стоит мегабайт паразитного трафика у DDoS'еров?
    • 0
      хороший пассиврый ботнет почти ничего не стоит атакующему. Но есть плюс: такая атака мощная, но одноразовая.
      А активный ботнет при нынешней дешевизне инета и компов тоже стоит копейки
      • 0
        «Почти ничего» и «копейки» — это сколько точно?
        • +3
          (палюсь)
          50000р за 3 дня 7гбит/сек 300000 хостов

          ЗЫ есличо, ботнет не мой. Я такую атаку отражал и мы производили анализ затрат. В прошлом году в феврале

          Положить канал 100мбит/сек на день будет стоить наверно 5круб
          • 0
            Вот спасибо, это ценная информация.
            Кстати, сколько запросов делали эти 300к хостов? Эта атака была нацелена на то, чтобы положить канал? Если так, то ещё интересно, сколько тратят атакующие при атаке, нацеленной на DoS из-за высокой нагрузки на сервер.
            Пойду посчитаю, во сколько мне обходятся мегабайты трафика. =)
          • 0
            Вам удалось сжать трафик помощью фильтрации? каково было значение?

            Как я понимаю, фильтрация может позволить снизить паразитный трафик в 5 и более раз.
            Достаточно сжать 7Гбит до 1Гбит/с и победа наша. Другой вопрос сколько нужно ресурсов для такой фильтрации.

            1 Гбит/с в Москве стоит около 40т.р. в месяц — небольшая сумма для крупного проекта.
            • 0
              У атакуемого клиента было 2 гигабитных канала.
              Оба лежали. А также «зацепило» ещё кучку клиентов поменьше

              Трафик был: http GET, DNS, ICMP, мусор

              с http перешли на https (это была первая, слабенькая волна), остальное сильно урезали силами провайдера (за что было ему уплочено). ДДоС был на забивание канала, а не на убивание сервисов.

              Паразитный трафик силами провадера и выкаченного Cisco GUARD был урезан в 15 раз
  • 0
    >По результатам проведенного эксперимента ясно, что сервер способен выдержать увеличение атаки примерно до 300Мбит/с. Свыше 300Мбит/с мы «упремся» в предел рандомного чтения SAS дисков.
    Откуда вывод, что это именно SAS? И откуда «рандомное» чтение, если страница одна и та же?
    • 0
      Год назад столкнулся с тем, что SAS диск не мог считывать более 50К блоков. В munin график IOstat на этом значении переходил в насыщение. Исходящий трафик был неболее 350 Мбит/с. Распределение нагрузки на второй SAS диск привело к увеличению исх. трафика.

      Из этого я сделал вывод что SAS сможет гарантированно обеспечить 300 Мбит/с.
      Но я не уточнил, к сожалению, что это примерное значение, и при отдачи только одной INDEX HTML оно может быть выше.
      • 0
        если это будет такая часто запрашиваемая страница то не осядет ли она в ОЗУ?
      • 0
        Прошу прощения, но куда девался дисковый кеш? Если страница одна и та же, то диск вообще работать не должен. Что-то у вас с этим не то…
        • 0
          тогда с диска отдавалось видео + mp3 — файлы большие, чтение рандомное — SAS max = 300 мбит/с
  • 0
    Автора Cтатья очень хорошая отправная точка, на тему отражения дос атак.

    При умелой сноровке атакующий будет дергать страницы с логикой, которая к примеру будет дергать базу данных (поиск, и т.д).

    В расчет нужно брать особенности атаки, если боты еще будут по ssh долбить.
  • +4
    на время атаки в iptables на канал можно было бы добавить delay 10-20ms, для пользователей это было бы не сильно заметно, но разгрузило бы процессор не думаю, что ботов натравили на статику :)
  • +1
    Подраздел «Недостатки поиска ботов командой netstat». Замените nestat => netstat
    • +1
      исправил
  • 0
    Ну и скрипты у вас. Вот тут:
    cat /var/log/nginx/error.log | grep «limiting connections by zone» | grep «request: \»GET / HTTP/1.1"| awk '{print $12}'| awk -F"," '{print $
    1}'| sort | uniq -c | sort -nr > /tmp/botnet.blacklist
    Можно выкинуть cat, фильтрацию засунуть в awk и так далее.
    • 0
      можно все сделать в awk, но для лучшего понимания я написал grep.
      Так универсальный скрипт получается. Если прядок полей в логе чуть другой поиск в awk придется править.
  • 0
    Нечто подобное делал на своём 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 не страшен. Ну почти =)
    • 0
      Кстати интересно, а что будет если бота редирекнуть на кластер серваков, на которых чтонить такое крутиться, что друг на друга редиректит? У них сработает счётчик редиректов?
  • 0
    По моему гораздо проще и эффективнее переключить на время трафик на специализированный антиддос сервис.
    • 0
      Для небольших проектов, наверное, это выход. Но будут большие задержки — что затронет лояльность клиентов и SEO будет не в восторге.
      • 0
        Задержки как раз будут гораздо меньше чем в случае самостоятельного решения. Свой сервер будет разгружен, так как к нему не будет поступать паразитный трафик, а только отфильтрованный. И фильтровать профессионально и _заранее_ настроенная система антиддоса будет куда качественнее и с меньшим количеством ложных срабатываний.
        • 0
          очень большую роль играет географическое расположение вашего сервера и анти-ддос фильтра, верно?
          Если они в пределах одного ДЦ — результат будет потрясающий.

          А вот если между ними несколько стран или океан? Не получите ли вы высокий процент 502х ошибок?

          • 0
            Не верно.
            Даже если сервер или фильтр находятся в США и к пингам относительно российских прибавляется 200мс, то пользователи обычных сайтов ничего не замечают. Проверено практикой.
            Вот если какие-нибудь игровые сервере, тогда да.
  • 0
    А можно пример блок листа? Хочу маленько переделать :)
    • 0
      уже не надо. подправил скрипты и запилил себе в вики. надеюсь автор не против :)
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    А как быть, если атака ведётся с целью забить входящий канал UDP-флудом? Я так понимаю, что UDP-пакет в любом случае доходит до сервера, даже если на нём порт никто не слушает, а это значит, что весь UDP-траффик, отправленный ботнетом, дойдёт до сервера.
    Может ли помочь в фильтрации траффика сам ДЦ? Или ему тоже неохота работать с длинными списками правил?
    • 0
      Насколько я помню, никак. Разве что выяснить на какой айпишник идет атака, а потом прозвониться как можно дальше по пути к этому айпишнику из Интернет и попросить там прописать фильтр на запрет к айпишнику UDP-трафика. У провайдеров, сидящих на разных концах спутникового канала, иногда бывает между собой договор на такие случаи.
  • 0
    А почему провайдеры и хостеры не борются с ДДОСом? Ведь проще на уровне дата-центра банить ботов?
  • +5
    Извините, пожалуйста, за критику. Вы потратили силы на написание этой статьи, вложили в нее много усилий, но… но в вашей статье какое-то совершенно сказочное количество неточностей. :(

    «На основе сервера Xeon 2.5GHz / 4Gb RAM / SAS можно отражать атаку примерно до 300 Мб»

    Полоса трафика не имеет никакого значения для измерения мощности ДОС-атаки. Это же очевидно: заполнить и гигабит можно без малейшей нагрузки на сервер.

    «Максимальная возможная мощность сдерживания DDoS атаки ограничивается физическими возможностями сервера и пропускной способностью канала.»

    Капитан Очевидность?

    «Если у сервера несколько IP то сайт под ДОСом ляжет, работа других сайтов на сервере и ssh нарушена не будет. „

    Да ну? Неужели?

    “По умолчанию ОС Debian и другие ОС не в состоянии поддерживать огромное количество соединений создаваемое ботнетом.»

    Что такое «ОС» в данном случае? Это не вопрос операционной системы (набора прикладных программ), это уровень ядра (как вы дальше правильно заметили), фронтенда и бекенда.

    «Аккуратно меняем конфигурацию ядра и перезагружаем сервер…»

    После смены sysctl не нужно перегружаться.

    «И так. Наша система способна выдержать натиск ботов.»

    Да? уже?

    «процессы PHP и БД полностью «съедают» ресурсы памяти и процессора, так что значение load average превышает 100 пунктов.»

    LA не зависит напрямую ни от памяти, ни от процессора. По большому счету, это бессмысленный показатель.

    «Эффективный поиск ботов возможен только при остановленном вебсервере»

    Да? Вы видите в нетстате соединения на незапущенный сервис, не слушающий нужный порт? :)

    «Свыше 300Мбит/с мы «упремся» в предел рандомного чтения SAS дисков.»

    Вы действительно думаете:
    a) что чтение одной странички сайта — это рандомное чтение?
    b) что одна страничка каждый раз читается с диска?

    Ну и дальше уже не читал…
    • 0
      согласен — аффтар профан
      • 0
        И тем не менее он учится, делает, экспериментирует и скорее всего с таким подходом довольно скоро обгонит «умников_почивающих_на_лаврах_прошлого_опыта». Я не вас имею ввиду.

        И не боится сюда написать, под стрелы критиков, которые пишу «КГ/АМ», а не развернуто описывают свои возражения. Неужто так сложно указать явно на неточности/ошибки? Или сами не знаете?

        В любом случае автор заслуживает уважения, ИМХО.
    • 0
      спасибо за комментарий
      Постараюсь ответить также подробно.

      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. «Ну и дальше уже не читал…»
      — прочитайте до конца, пожалуйста, возможно у вас появятся другие конструктивные замечания
      • 0
        (от блин, ответил тут, а ответ опубликовался тредом выше)
  • 0
    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. :)

    • 0
      4. Считаем всех у кого более одного подключения ботами.

      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. Все зависит от возможностей сторон атакующей и отражающей. В войнах же побеждали, и не всегда самые «грамотно организованные».
  • 0
    Верно ли я сделал, что исправил строчку:
    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
    как от нее избавиться?
    • 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» но результат тот же
      • 0
        Сам нашел причину неработоспособности скрипта (
        1) ддосят так, что /var/log/nginx/error.log у меня на несколько сотен гигов (сам в шоке), причем у меня он создается ежедневно новый, а старый архивируется… И соответственно, нужно много времени на сканирование этого файла…
        2) ддосят так, что система виснет и скрипт тупо сам висит (

        возможно целесообразнее не логи читать каждый раз, а смотреть какие соединения вообще есть? Например:
        netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
        


        Подскажите, если этот способ лучше, то как его применить к данному скрипту?
        • 0
          настрой ротацию лога /var/log/nginx/error.log каждые 5-10 мин. Так чтобы поддерживать небольшой размер лога. Не архивируй старые — нет смысла.
          • 0
            у меня в /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
            

  • 0
    Вложу свою копейку.
    Собираю из 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 самых агрессивных.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.