0,0
рейтинг
26 сентября 2011 в 17:40

Разработка → Методы борьбы с DDoS-атаками

Хотелось бы поговорить с вами на актуальную нынче тему, а именно — про DDoS и методы борьбы с ним. Рядовые администраторы знают, что это такое, а вот для большинства вебмастеров это аббревиатура остается загадкой до того момента пока они на личном опыте не столкнуться с этой неприятностью. Итак, DDoS — это сокращение от Distributed Denial of Service (распределенный отказ в обслуживании), когда тысячи зараженных компьютеров отправляют на сервер множество запросов, с которыми он, в последствии, не может справиться. Целью DDoS атаки является нарушение нормальной работы сервера, а в дальнейшем — «падение» сайта или сервера целиком.

Как же от этого защититься? К сожалению, универсальных мер защиты от DDoS-атак до сих пор не существует. Тут необходим комплексный подход, который будет включать меры аппаратного, программного и даже организационного характера.



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

Для защиты IIS серверов можно воспользоваться (программным) решением от компании Microsoft, но, зная щедрость этой компании, можно догадаться, что они тоже далеко не бесплатные.

В настоящее время, заказные DDoS-атаки превратились в выгодную и активно развивающуюся нишу сетевой преступности. Поискав в Google, можно найти десятки предложений от «специалистов» по устранению сайта конкурентов.

Какие же основные принципы по защите от DDoS? В первую очередь, не нужно привлекать к себе (своему сайту) лишнее внимание радикально настроенной общественности, публикуя контент, способный задеть расовые, национальные или религиозные чувства каких либо индивидов.

Если же вас «заказали», или вы не послушались предыдущего совета, будьте начеку — аппаратные ресурсы веб-сервера обязательно должны иметь некоторый резерв производительности, а распределенные и дублирующие системы — построены максимально эффективно. Без понимания принципов работы DDoS, эффективную защиту построить просто невозможно. Для осуществления DDoS-атак используется большое количество компьютеров, зараженных вредоносным кодом. Эти компьютеры объединяются в ботнеты (“bot-net” — сети зомби-машин), которые по приказу злоумышленника осуществляют DDoS-атаки, причем владельцы компьютеров зачастую даже не подозревают об этом.

Мы, как хостинг-компания, сталкиваемся с DDoS-атаками на сайты наших клиентов ежедневно и имеем некоторый опыт в борьбе с ними. Как было сказано выше, универсальных мер защиты попросту нет, но атаку все же можно отразить. Предположим, что на некий сайт (пусть это будет domain.ru) идет DDoS атака. По логам видно, что большое количество GET запросов идет на главную страницу. В большинстве таких случаев, ботов можно обмануть воспользовавшись javascript-редиректом. К примеру:

<script type="text/javascript">
window.location = "domain.ru/index.php"
</script>


Как результат — с каждым разделом, который атакован GET запросом прямо в корень, размер файла получится всего несколько байт, что гораздо лучше, чем когда бот соприкасается c ~50-100кб страницей и при этом подтягивает ~5-10 SQL запросов. Легитимные же пользователи, у которых не отключен javascript в браузере, перенаправляются на index.php.

Но есть одно большое НО – поисковые-боты тоже не оборудованы js-интерпретаторами и точно так же, как и атакующие боты, будут утопать в js редиректе. Можно, воспользовавшись такими UNIX утилитами как tcpdump или netstat, написать небольшой скрипт, который будет считать кол-во коннектов с определенного IP адреса, и банить его.

Определить бота можно, например, проверив его host. Небольшой пример элементарного скрипта по блокировке IP, которые создают много коннектов к серверу (данный вариант проверялся на Centos 5.6):

Запись в crond

*/1 * * * * netstat -an | grep tcp | awk '{print $5}' | cut -d: -f1 | sort -n | uniq -c > /var/log/ip.list

Данная команда создает список с кол-вом подключений и самим IP, пример:

10 209.232.223.117
1 209.85.161.191
2 212.113.39.162
1 212.78.78.78
61 213.142.213.19
5 213.151.240.177
1 210.169.67.225
1 216.179.59.97

Сам скрипт, который можно запустить в screen-е или сделать демоном:

#!/bin/bash
connects=150 <- лимит подключений с одного IP
while read name
do
// здесь передаем переменной кол-во подключений с одного IP
count=`echo $name | awk '{print $1 }'`
// здесь передаем сам IP
ip=`echo $name | awk '{print $2 }'`
//проверка имени хоста
hostname=`host $ip`;
//если кол-во подключений превышает лимит
if [ "$count" -gt "$connects" ]
then
//проверяем, нет ли в белом списке нашего IP
if grep $ip /etc/white.list > /dev/null 2>&1
then
// если в имени хоста есть слово google (у гугло-ботов это слово присутствует)
if echo $hostname | grep "google" > /dev/null 2>&1
then
// то добавляем его в белый список и делаем запись в лог
echo "$ip" >> /etc/white.list
echo `date +%H:%M_%d-%m-%Y` $ip "- ADDED TO WHITE LIST AS $hostname SEARCH BOT IP" >> /var/log/ddos_log
else
// если не гугл - блочим
route add $hostname reject
fi
fi
fi
done < /var/log/ip.list


Давайте также посмотрим и на настройки параметров Apache, которые помогут избежать некоторых проблем вызванных DDoS атакой.

TimeOut – указывайте как можно меньшее значение для данной директивы (веб сервера, который подвержен DDoS атаке).

KeepAliveTimeout директива – также нужно снизить ее значение или полностью выключить.

Стоит обязательно проверить значения различных тайм-аут директив представленные другими модулями.

Директивы LimitRequestBody, LimitRequestFields, LimitRequestFieldSize, LimitRequestLine, LimitXMLRequestBody должны быть тщательно настроены на ограничение потребления ресурсов вызванных запросами клиентов.

Убедитесь, что вы используете директиву AcceptFilter (на ОС которые поддерживают ее). По умолчанию она включена в конфигурации Apache httpd, но для своей работы может потребовать пересборку с новыми настройками ядра вашей ОС (*nix, *bsd).

Используйте директиву MaxClients, чтобы указать максимальное количество клиентов, которые смогут быть одновременно подключены к серверу — уменьшив значение директивы вы сможете снизить нагрузку на web-сервер.

Защитится от DDoS можно и на программном уровне. В этом вам поможет бесплатный скрипт – DDoS Deflate. С его помощью можно легко избавится от детского флуда и DDoS. Скрипт использует команду «netstat» для обнаружения DDoS и флуда, после чего блокирует IP адреса вредителей с помощью фаервола iptables или apf. Но не стоит расслабляться и считать, что слабый DDoS не сможет нанести ущерб вашему серверу. Возьмем, к примеру, что атакующих зомби-машин всего 10-50, но все они с толстыми каналами, а Вы, как назло, уехали в командировку, или у вас десятки (а то и сотни) серверов, и Вы не успеваете физически “мониторить” их все. В таком случае, даже небольшое количество машин сможет “зафлудить” канал или заставить выйти из строя вебсервер apache, mysql, etc. Другое дело, когда администратор круглосуточно “мониторит” сервер и с легкостью обнаруживает атаки. Но такое бывает крайне редко, поэтому нужно подключить систему сигнализации, а процесс блокировки атакующих зомби-машин — автоматизировать.

P.S. Статья была прислана мне юзером offic. Вопросы по статье, рекомендации по следующим статьям и интересующим темам и вопросам просьба присылать ему.

Спасибо за внимание!
Краковецкий Александр @sashaeve
карма
435,2
рейтинг 0,0
CEO DevRain Solutions
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

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

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

  • +7
    Так немного меньше сил потратит веб на подсчет коннекшнов (конечно если соединений будет 100500 — то больше памяти)
    netstat -ant | awk '/^tcp/ { split($5,IP,":") ; CNT[IP[1]]++ }; END { OFS="\t" ; for (ip in CNT) { print CNT[ip],ip } ;} '
  • –1
    Вариантов куча, можно задать порт, тип подключений и т.д., смотря какие цели приследуем…
  • +25
    Если ддосят корень сайта, то я просто делаю вот так:

    iptables -A INPUT -p tcp -m tcp --dport 80 -m string --string "GET / HTTP" --algo kmp --to 1024 -m recent --set --name httpddos --rsource
    iptables -A INPUT -p tcp -m tcp --dport 80 -m string --string "GET / HTTP" --algo kmp --to 1024 -m recent --update --seconds 10 --hitcount 2 --name httpddos --rsource -j DROP


    Второй запрос на корень, в течении 10 секунд, и ты попал в бан(-j DROP) на десять секунд, если за время (10 сек) еще раз обратился, то опять (-j DROP). И все. Серверу моментально легчает. ДаДа, знаю не хорошо «стрингами» пакеты сканить, но на время атаки на заданный урл это отличный способ, также я довольно много описывал у себя в блоге способов о защите. Конечно там не все что я знаю, но большая часть. И я не уверен что я использую оптимальные варианты, но мне хватает.
    Всем удачи в борьбе с ддосерами!
    • +1
      > также я довольно много описывал у себя в блоге способов о защите

      # Enables source route verification
      net.ipv4.conf.all.rp_filter = 1


      — Скажите, зачем вы пишите вещи, в которых не разбираетесь?
  • НЛО прилетело и опубликовало эту надпись здесь
    • –3
      А помойму это все есть в гугле. Да простит меня юзер, если это его авторский текст.
      Но все же добавил в избранное, чтобы все было при себе.
  • +2
    Спасибо за пост, как раз актуально для меня. В избранном.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +6
      +

      iptables -A INPUT -m geoip --source-country PK,KZ,IN,CN,BR,EG,PL,TH,VN,ID,AR,MX,KR,TR,RO -j REJECT
      iptables -A INPUT -m geoip --source-country PH,DZ,IR,MA,MY,PE,RS,SA,HK,JP,SG,IL,CL,NG,TW -j REJECT
      iptables -A INPUT -m geoip --source-country CO,AR,JO,SN,NP,IN,UG,LA,SA,LY,MG,JM,SD,DO,TO -j REJECT
      iptables -A INPUT -m geoip --source-country CR,KW,FJ,SN,NI,HN,EC,PS,CL,ZA,VN,BO -j REJECT

      Как раз азия + африка.
      • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      А те обычные пользователи вроде меня, что живут в Азии, как попадут на ваш сайт?
      Из-за таких «умников» регулярно приходится использовать прокси.
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Конечно лучше хоть как-то, чем никак, но не такими методами как вы там выше советуете: REJECT для всех кроме RU и UA.
          • НЛО прилетело и опубликовало эту надпись здесь
            • НЛО прилетело и опубликовало эту надпись здесь
    • +3
      Да, видел я такие сайты: из Азии меня не пускают, при попытке перезагрузить страницу банят на сутки, если страница медленно загружается — отваливается коннект, и т. п.

      Если уж делаете такие радикальные меры, отсекающие реальных пользователей, то потом хотя бы отключайте их, когда атака закончится.
      • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Можно еще apache за nginx спрятать.
    • НЛО прилетело и опубликовало эту надпись здесь
      • +1
        Но как инструмент, потом проще будет отбиваться
        • +3
          правильно настроенный nginx со своими скриптами-плюшками — одно из самых важных средств защиты от ддос'а.
      • 0
        Что за чушь? Еще как поможет.

        return 444;

        поможет нашему брату
    • +1
      Вроде это должно быть у всех сразу, без этого никуда сейчас =)
  • +11
    Честно говоря, статья ни о чем. Если поток превышает емкость канала (до сервера, до роутера, до ДЦ), то никакие тюнинги ОС и прятанье apache за nginx не помогут.
    • 0
      Согласен, но это уже малость другой и особый случай. Который не такт часто возникает, в сравнении с HTTP Flood
      • +7
        По нашему опыту, как раз HTTP flood — это «детский» и нечасто возникающий DDoS, с которым бороться-то дело добровольное. В большинстве случаев нормально настроенный сервер сам справится.

        А вот когда идет поток в 300-400 мегабит и 20-30к пакетов в секунду — тут только аппаратные решения в виде пропускания трафика через тот же Cisco Guard.
        • 0
          С детским флудом и sslswamp'ом можно без особых напрягов полжить и нормально настроенный сервер, если на нём есть https без железного ssl ускорителя.
  • 0
    Зачем нужен "/1" в cron?
    • +2
      Привычка. Результат ни на что не влияет все равно.
  • 0
    собираем кол-во подключений каждую минуту
    • –1
      Если вы отвечали мне, то спрошу по другому: почему не "* * * * *", а "*/1 * * * *"?
      • 0
        можно и так, можно и раз в 5 минут.
  • –4
    очередная статья на тему самоделкина-защитника от ддос. таких статей в интернетах уже тысячи. обычно ещё любят писать про ipset, но тут, похоже, автор поленился/ниасилил…
    • +8
      Так напишите же толковую статью!
      • –9
        та я как бы не писатель, да и местные ограничения типа кармы не позволяют
        • 0
          и, похоже, так будет и дальше :)
  • +2
    Дизайн у сайта из статьи вырви глаз.*

    *offtop
  • +1
    --string «GET / HTTP» отнюдь не бесплатен хоть и работает в контексте ядра.
  • +8
    Какое-то слабенькое описание. И DDoS'ы какие-то тоже слабые (в смысле, если у вас сервер способен что-то из крона запустить, значит DDoS не настоящий, или каналы слабые).
  • +4
    забавляет, когда пишут про Cisco Guard, считая этот девайс панацеей от DDoS, при этом ни разу не видев его… молчу, что он уже как год end of sale.
    Последний релиз софта был выпущен 13/NOV/2009… нужно ли говорить, что с тех пор много воды утекло?
    • +3
      А вы что предложите?
      • 0
        TippingPoint не вариант?
      • 0
        Программно-аппаратный комплекс Kaspersky DDoS Prevention, например. На редкость эффективная штука…
      • +4
        Широкие каналы, хороший бордер рутер способный фильтрануть UDP флуд в 17 гбит, дроп на UDP/ICMP в случае атаки.
        Что еще?
        Если больше 17 гбит — don't bother just nullroute. Больше трех дней канальщики не позволят лить такой траффик к Вам.
        • 0
          Если больше 17Gbps — добро пожаловать к нам. Именно поэтому построили распределенную сеть, не завязанную на одного оператора.
          • 0
            Да это и самому можно с anycast сделать, если уж так надо. РАЙП без проблем выделит IP под цели мультипиринга, что в anycast необходимо.
            • 0
              попробуйте и сделайте. откроете для себя много нового и интересного: например про петли в bgp.
              • 0
                path cost для лохов? :)
                • 0
                  они решают вопрос статических петель, но не динамических.
                  пара удачно проставленных localpref могут неизбывно доставить…
            • 0
              ну и потом, если все так просто и чудесно — делайте. нам будет интересно.
              • 0
                В планах, если кто закажет услугу. Ясно что это не стоит 500 евро в месяц, а как минимум 15к евро в месяц, чтобы 3-4 локации очистить от левого траффика, грубо говоря 30-40 гбит без проблем снять.
                • 0
                  ну а вот теперь представьте себе качество услуги если первый клиент — он-же бета тестер.
                  да еще не за 500 евро а за 100500.
                  считаете нормальная практика когда он и услугу и R&D оплачивает, да еще и тестировщик?

                  знаю отличный пример создания такой услуги в «укртелекоме». где-то в архиве хабра лежит статейка как они за 100500M евро ЦОТ строили.
                  какая здесь экономическая целесообразность?

                  а ведь ЦОТ не только построить надо, он должен еще и развиваться и масштабироваться.
                  а это сколько стоить будет? и пойдет-ли заказчик-ангел на такие расходы?

                  есть некоторая разница в «knowing the way» и «walking the way». и это замечательно.
                  P.S. июнем прошли марку в 56Gbps. выстояли, пусть и с 5 минутной заминкой.
                  • 0
                    Почему бета-тестер? Локальная система готова фильтровать 17 гбит, можно либо локально ее размножить либо через anycast в мире, что логичнее, чем переплачивать за международный траффик дома.
                    Поставить в 5-10 IX по миру и фильтровать нужно будет уже в пределах 10 гбит, что дешевле.
                    А насчет 15000 евро — имхо это реальная стоимость услуги защиты от любой угрозы, меньше — это просто несерьезно (ну разве что посадить десяток проблемников и молиться чтобы 3-4 ботнета-миллионника разом не ударили).
  • –1
    Отдать на откуп специалистам: услуга у оператора/хостера или специализированного сервиса.

    Если ознакомиться с прайсом многих сервисов, то окажется, что цена вопроса минимальна (в контекте того ddos который вы описали).

    Промышленное решение на стороне клиента — бессмысленно! Поэтому и рассматривать их не стоит.
    Как совет, вне зависимости от того существует ли потенциальная опасность быть атакованным или нет, на этапе выбора хостера или оператора смотрите на тех, кто предоставляет услуги по фильтрации трафика, как минимум вам не нужно будет переезжать в другой ДЦ и это позволит сократить вам время подключения к услуге.

    А все что вы описали выше + еще 1001 метод защиты неплохо знать в качестве общеобразовательной программы от совсем легкого флуда.

    • 0
      ну да, около 650 тысяч рублей за действительно эффективную защиту:
      soft.softline.ru/kaspersky/kaspersky-ddos-prevention/
      • +2
        инцидент с ассистом продемонстрировал «эффективную» защиту)). цены у касперского самые высокие на рынке. защиты от описанного в статье флуда будет стоить не дороже 5тыс руб.
        • 0
          у касперского достаточно примитивный классификатор который пройдет атака уровня приложения с хорошо распределением и джиттером в запросах.
  • 0
    От легкого флуда также неплох CSF + LFD.
  • +4
    Был такой широко известный в узких кругах персонаж, Николай Федотов. Так вот он любил говорить, что лучший способ защиты от DDoS-атак — не хамить в чатах. Не такой уж плохой совет, если подумать.
  • +3
    «или у вас десятки (а то и сотни) серверов, и Вы не успеваете физически “мониторить” их все» — а автоматизировать мониторинг нельзя?
  • +1
    Такой способ хорош для DoS, а не DDoS.
  • +1
    Если у злоумышленника тыква вместо головы, как показано на рисунке, то да, эти методы помогут.

    «Используйте директиву MaxClients» — вы сделаете так, что ваш сайт будет недоступен. что и хотят злоумышленники.

    fail2ban забыт, вместо него используются дибильные велосипеды.

    habrahabr.ru/blogs/personal/71694/ здесь умнее и больше. :)
    • +1
      apache не имеет ни единого шанса. by design.
      1. нет возможности ограничить размер принимаемых от клиента данных
      2. недостаточно хорошо настраиваются таймауты.
      3. выделение воркера происходит в момент accept() на соединение.
      • 0
        Осталось выяснить, при чем здесь апач? Здесь вообще бредняк написан.
        В той статье которую я привел, там при прочих равных ipconfig правится, плюс как бы название доставляет.
  • –1
    1. mod_evasive — (mod_dosevasive)
    дальше можно не читать.
  • 0
    > //проверка имени хоста
    > hostname=`host $ip`;

    ИМХО делать такую проверку — это зло. в реальности детский ДДоС (>=100Мбит) довольно хорошо отбивается путем фильтрования однотипных запросов, например:

    tail -n 5000 /path/to/apache.log|awk '/"GET \/ HTTP\/1.0"/{print $1}'|sort|uniq -c|sort -n|awk '{if ($1 > 20) print $2}'|xargs -n1 -IXXX ipfw -q table 1 add XXX

    при этом нужно контролировать забивание сокетов апача:
    netstat -Lanptcp

    список самых активных пользователей/соединений ([к-во] [IP]):
    netstat -nptcp | egrep -v 'Active|Address' | awk '{print $5}' | cut -d. -f 1-4 | sort | uniq -c | sort -n | tail -n 10

    при необходимости соединения можно сбросить вручную:
    netstat -nptcp | egrep 'IPADDR' | awk '{print $4" "$5}' | sed 's/\./ /4;s/\./ /7' | xargs -n 4 tcpdrop

    З.Ы.
    OS: FreeBSD

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