Строим кластерную систему защиты от DDoS

    Данная статья написана моим другом, который профессионально занимается созданием высоконагруженных сетевых решений, в том числе систем противостояния DDoS аткам.
    По его просьбе публикую ее на хабре. Если статья понравиться, он будет рад инвайту на адрес hl.squirrel@yahoo.com.


    Попытаюсь вкратце описать схему решения комплексной защиты от разных типов DDoS атак высокой интенсивности. Подобное решение успешно протестировано и функционирует на сервисе stop-ddos.net
    Схема основывается на отделении системы защиты (фронтенда) от сервера приложений (бэкенда).

    Существует 3 основных типа DDoS атак:


    • атака, направленная на переполнение ресурсов канала в интернет;
    • атака, направленная на превышение максимального количества одновременных соединений сервера (SYN флуд);
    • атака, направленная на исчерпание процессорных мощностей сервера (частое запрашивание страниц — HTTP флуд).

    Решение должно обеспечивать защиту от каждого типа атаки.



    Рисунок описываемой схемы находится в конце статьи.

    Сетевой флуд


    На сегодняшний день наиболее эффективным средством борьбы с обычным сетевым флудом является широкий канал. Канала в 10Gbps достаточно для отражения большинства атак этого типа.
    Для того чтобы лишний раз не нагружать оборудование во время такой атаки, отсеиваем лишние пакеты на наши адреса. Например, защищаемый нами сервис живет на 80-м порту TCP. В таком случае пакеты с destination port отличным от 80 можно смело stateless фильтровать. Для этого вполне подойдет роутер уровня CISCO 7600.
    Однако не забываем о резервном канале, шириной хотя бы 1Gbps.

    SYN-флуд


    От SYN флуда защищаемся с помощью statefull файрволов (SFFW).
    В идеале — аппаратный файрвол (например, Juniper SRX 5800). В зависимости от предполагаемой мощности атаки подбирается нужное количество файрволов. На роутере, стоящем на входе нашей защиты, создается маршрут защищаемой нами сети (на схеме это 2.1.1.0/24) с next-hop адресом каждого SFFW.
    Каждый SFFW имеет статический роут сети 1.1.1.0 на следующий роутер. На нем балансируется нагрузка между нодами последнего уровня защиты, являющие собой сервера с UNIX системой.
    В данном случае удобно использовать протокол динамической маршрутизации BGP (при выходе одной ноды из строя нагрузка автоматически распределится между рабочими нодами). Таким образом, каждый сервер анонсирует роутеру маршрут к сети 1.1.1.0 с next-hop self.

    HTTP-флуд


    Пакеты, дошедшие до данного уровня защиты, попадают на реверс-прокси. Это должен быть прокси-сервер, способный отличить бота от настоящего клиента. Например, nginx с анализатором логов, количества одновременных соединений с адреса в комбинации с любыми другими методами придуманными или найденными Вами. Примеры таких решений уже публиковались на хабре.
    На прокси-серверах настраиваем policy based routing как показано в примере. Это избавит запросы на бэкенд от вторичного прохождения через statefull firewall.
    Теперь о бэкенде. Адрес, на который приходят запросы от фронтенда, должен отличатся от адреса, через который осуществляется управление сервером. В случае засвечивания management адреса (к примеру, письмом сгенерированным приложением), всегда можно выбросить management адрес в блэкхол и это не повлияет на работу приложения.
    В реальности нет смысла в использовании такого количества роутеров как показано на схеме. Вместо этого рациональней использовать одно устройство в качестве роутера с несколькими таблицами маршрутизации (VRF, routing instances) или несколькими логическими роутерами.
    Аппаратные stateful файрволы также можно исключить из данной схемы, а вместо них на прокси-серверах использовать PF в режиме SYN Proxy (PF в этом режиме показывает наилучшую производительность на родной OpenBSD, в случае Linux лучше вообще отказаться от PF, и просто протюнинговать sysctl нужным образом). Однако, количество серверов в этом случае придется увеличить.

    Почта


    Входящую почту выгоднее всего направить на гугловые МХ (пусть кто-то попробует их заддосить :) ), а потом забирать фетчмейлом обратно на сервер. DNS тоже лучше всего держать не у себя — крупные зарубежные регистраторы предоставляют достаточно отказоустойчивые кластера в качестве NS для купленных доменов. Также, за отдельную плату, можно разместить свой домен на их NS серверах.

    DDoS protection scheme

    P.S. Прошу накинуть чуток кармы чтобы перенести в блог «Информационная безопасность».
    Спасибо, перенес!

    UPD. Ответы на комментарии дает автор статьи.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

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

    Комментарии 57

      0
      На какой бюджет рассчитано ваше решение?
      И зачем городить BGP? Не проще ли поставить несколько прокси за фаерволом(фаерволами) и за ними (логически) бэкенд?
      И что нового в вашей технологии? Или вы предлагаете geo-распределенную защиту?

      Пограничный роутер не нужен, достаточно VHRP или даже RR-DNS.
        +2
        Да уж, к сожалению, это далеко не всем подойдет — денег просто у многих не хватит на такое… :(
          –6
          Это решение не для одного сайта, а для хостинг-компании (либо очень крупного сервиса).

          Если надо защищать один сайт, то лучше не самостоятельно строить такие решения, а купить как сервис.
          К примеру, у нас на stop-ddos.net защита одного сайта будет стоить от 250 до 1000 $ в месяц.

          К тому-же, мы, в отличие от зарубежных компаний-хостеров, очень либерально относимся к контенту наших клиентов.
          –2
          В данном случае защита териториально находится в одном месте.
          BGP выбрана по той причине, что когда один из прокси станет недоступным, на него перестанут поступать запросы. BGP в данном случае используется только всередине кластера и может быть построен на серых адресах и серых ASN.
          Прокси нельзя поставить просто за файрволами, так как файрвол, в отличии от роутера, обычно не умеет Per Packet Load Balancing, необходимый для балансировки: грубо говоря, на всех серверах стоит один и тот же адрес (как показано на схеме); именно на этот адрес и направлен атакуемый домен, а если не использовать Per Packet, то могут рваться TCP сессии (да и разделение запросов будет неравномерным).
          Балансировка нужна только для того, чтоб равномерно распределить запросы между прокси, так как при серьезной атаке даже самый мощный сервер не справится.
            0
            «BGP выбрана по той причине, что когда один из прокси станет недоступным, на него перестанут поступать запросы.»
            Круто! А вы на дачу тоже на БелАЗе ездите?

            «так как при серьезной атаке даже самый мощный сервер не справится.»
            Серьезная атака это сколько одновременных запросов? И что в вашем понимании «самый мощный сервер»?
              +2
              Решение сделано для хостинг-компании, которая специализируется на защите от DDoS, и одновременно обслуживает многих клиентов. На некоторых клиентов атаки длятся неделями.

              Несколько примеров из личного опыта:
              Сайт по продаже авиабилетов, атака длилось 2 недели, 8Gbps обычного флуда.
              На другие сайты случалось и 500 000 pps SYN-флуда и 100 000 GET запросов в секунду.

              На вопрос о мощном сервере:
              Один 8-ядерный ксеон 55-ой серии держит, в среднем, 30 000 GET запросов в секунду.
              Использование более дорогих сервером нерационально, так как проще делать балансировку на несколько серверов с оптимальным соотношением производительность/цена.
                0
                Хм… а какой у вас по ширине канал в мир?
                  +1
                  2 канала по 10Gbps.
                  Однако, на один защищаемый сайт не более 10Gbps.
                +4
                За что минус? Что никто не слышал про WCCP, CARP, VHRP и пр.? BGP не для этих целей разрабатывался.
                  +1
                  VRRP вместо VHRP.
                  BGP вполне себе тут оправдан.
                  CARP и VRRP не получится так легко сделать балансировку. WCCP тут тоже неподходит т.к. им нельзя в этом месте подниматься до прикладного уровня — ресурсов нехватит. да и неудобно это — это же все-таки услуги связи.

                    0
                    Да действительно VRRP, ошибся, просто я его привык на цисках юзать где оно называется HSRP, вот и накосячил немного.
                    +1
                    для этих целей его тоже можно применять.
                    но, зачем забивать гвозди кувалдой, если есть молоток?
                  0
                  В этой ситуации разумнее было бы использовать LACP с балансировкой по ip-адесам, или CARP.
                    0
                    как связана аггрегация ethernet и ip?
                    вы думаете они bsd для маршрутизации используют?
                      0
                      LACP (а его в данной ситуациии только для агрегации линков использовать можно, так как при отказе сервера линк скорее всего не погаснет) тут вообще не к месту, одного гигабита вполне хватает, один сервер все-равно не выдержит больше гигабита HTTP флуда (в GET запросах это фантастическая цифра).

                      CARP тоже не совсем то — мы ведь балансировку делаем, а не failover.
                      В этой схеме BGP (хоть его и придумали для других целей) самое оптимальное средство.
                  +2
                  система бестолковая:
                  есть единая точка отказа
                  не предусмотрено различные правила для разных регионов
                  за ддосить могу обойдя защиту
                    0
                    В идеале несколько роутеров с BGP на границе (разумеется в разных ЦОДах), анонсирующие одну и ту-же сеть + несколько прокси за ними. На выходе получаем защиту от DDoS + CDN =) И можно продавать один и тот-же функционал как две разные услуги. А топик действительно «неочем». Если кто-то использует данную схему защиты в продакшене то мне его жаль.
                      –3
                      Смысла рамещения в разных ЦОД нет, если есть канал достаточной ширины в одном ЦОД.
                        0
                        А у вас есть какой-нибудь SLA с вашими клиентами, которых вы от DDoS защищаете?
                          +2
                          SLA высылается клиенту вместе со счетом на оплату (PayPal), после того как клиент был удоволетворен бесплатной защиты от первого случая DDoS.

                          В случае, если downtime превысит 4 часа в квартал, мы компенсируем затраты, из расчета
                          1 час downtime = 1 сутки бесплатного сервиса.
                            +1
                            Т.е. если за пол года на сайт будет кратковременная атака, которую вы не сможете отразить, все что получит клиент — еще 2-3 дня «бесплатного» сервиса?
                              0
                              Если на Ваш сайт за пол года всего одна кратковременная атака — Вас может и обычный хостер потерпеть (а если не хочет — меняйте хостера).
                              А еще рефаунд у пейпела никто не отменял.
                              0
                              Это как зубной врач даёт SLA «Если неправильно запломбированный зуб придётся вырвать, мы обещаем Вам бесплатно запломбировать ещё три зуба» :)
                        –1
                        не предусмотрено различные правила для разных регионов

                        Что Вы имеете ввиду?

                        за ддосить могу обойдя защиту

                        Каким образом, если Вы не сможете узнать реальный адреса бекенда?
                          0
                          Достаточно положить ваш фаерволл и/или пограничный роутер =)
                            0
                            Заддосить роутер с пропускной способностью 500 000 000 pps (типа Juniper MX 480) нереально :)

                            По поводу файрволов:
                            Заддосить один Juniper SRX 5800 возможно, но не кластер из нескольких такий файрволов.
                              +1
                              Вы тут говорите о 20 гигабитных каналах и о кластере из железок по 70к. Но сайт с дешевым дизайном у вас зарегистрирован на часное лицо да и сервер на котором оно крутится стоит в ЦОДе Укртелекома.

                              Забавно все это =)
                                –2
                                Оборудование взято в аренду. Система действительно размещена в датацентре Укртелекома — на текущий момент это провайдер с достаточно широкими аплинками (более 100Gbps) чтобы не быть уязвимым практически перед любой атакой.

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

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

                                Если Вам интересно, быдем рады пообщаться через ЛС, или по скайпу :)
                                  +1
                                  ИМХО, ДЦ Укртела — буээ не отличается особым качеством канала… Увез недавно оттуда свой сервер из-за жутких проблем с пингами в Россию :(
                                    +1
                                    Согласны, задержка в Россию большая (ходим в МСК через Франкфурт), но мы ведь говорим о ширине а не о задержках.
                                    А ширина действительно очень большая.
                                      0
                                      Про ширину ничего не могу сказать — что есть, то есть. И сапорт с менеджерами там адекватны :)
                                    +4
                                    <humor>
                                    у вас фамилия не Шахиджанян случайно?
                                    </humor>
                          0
                          Сегодня был топик про успешные топики. Кажется, там было что-то про доступный язык.
                            +3
                            По-моему всё в рамках обычного кругозора рядового ITшника.
                            –1
                            антивирус жалуется на яваскрипт инфекцию на сайте вашего друга и блокирует его
                              0
                              И какой же интересно у вас антивир?
                                –1
                                Хм, странно. А какой у вас антивирь?
                                Авира и Аваст молчат.
                                  0
                                  avg internet security 9 :)
                                0
                                Как я понимаю отсеканием хитроботов занимается реверс-прокси? Тогда мне кажется что при достаточно грамотном ддосе вся нагрузка пойдет на проки, а вот тут уже непонятно сколько их должно быть чтобы выдержать большой поток трафика.
                                  +1
                                  Выше в комментах я уже писал о способностях рядового ксеона — это можно использовать для расчета количества нод.
                                  0
                                  а вы что в качестве statefull firewall используете? SRX5800?
                                    +1
                                    В действующей схеме используются NS 5400.
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                      0
                                      Надо бы еще дать возможность анализатору ботов банить их по IP на уровне фаерволла где то снаружи, а то они все равно будут коннектиться (+ надо поддерживать лимит на число коннектов с 1 IP, а то одной машиной все зафлудят).

                                      А вообще, защитой от DDoS должен защищаться хостер, ему проще, всех сразу защищать.
                                        +1
                                        Число коннектов режется на statefull файрволе.
                                        Банить ботов снаружи не имеет смысла, так как при ботнете в несколько тысяч хостов мы процессом бана снаружи сильно нагрузим роутер (ведь процессор для апи не такой мощный как процессоры на routing engine и forwarding engine), да и сам процесс бана займет уймы времени.
                                        Проще это делать на файрволе самих прокси.

                                        По поводу хостеров:
                                        Большинство хостеров в наше время так демпингуют ценами, что на защиту у них просто не остается средств. А те что посерьезнее, хоть и защищают, но не будут терпеть клиентов на которых атака валится несколько недель (в таких случаях либо просто отказывают, либо ломят цены повыше чем у нас).
                                        +2
                                        Мне кажется стоит определиться в том, кого Вы собираетесь защищать таким оборудованием.
                                        Если говорить о себестоимости, то все эти вещи стоят не на одну сотню евро, каждая плата на 10ГБит в тех же Juniper кусается очень существенно.

                                        Если же говорить об уязвимостях, я по личному опыту порекомендую думать об уводе атаки в разные стороны на основе гео-кластеризации, тем самым снимая нагрузку по каналам и с ресурсов серверов. Если говорить о BGP, обычного банального prepend еще никто не отменял. Ставьте в нескольких местах детекторы/директоры нагрузки на дешевых машинах но где много памяти и хорошие перепрошитые сетевые карточки (да, существуют особые прошивки, увеличивающие pps на уровне железа, взять хотя бы опыт компании Crossbeam с их Х-серией), займитесь вопросами синхронизации данных между местами, где стоят «ноды» такого гео-кластера, и потом сядьте и посчитайте — Вы будете удивлены, но по расходам это все будет стоить примерно 1/10 часть того варианта, который описали выше.

                                        Если интересно более подробно, см. профиль и пишите в личку.
                                          +1
                                          Спасибо.

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

                                          Если атака ведется не с кучки хилых зомби-хостов :), а намеренно запущена на мощных серверах, тогда возможен вариант что 200 000 (а то и до 1 000 000, если хостер атакующего закроет глаза) pps SYN флуда пойдут на одну точку геораспределенного кластера, так как будут иметь одинаковую политику маршрутизации.
                                          Есть еще пачка мелких граблей которые вылазят при построении универсальной защиты, и эти грабли потребуют большого количества человекочасов работы и уменьшения качества сервиса.
                                            0
                                            SYN flood не пойдет на одну точку геораспределенного трафика, т.к. директор/детектор не даст этого сделать, он отслеживает количество пакетов на ту или иную ноду и сделает равномерную балансировку нагрузки между всеми нодами.

                                            Насчет человекочасов косвенно согласен, но они скорее имеют место быть при создании и тюнинге подобной системы, дальше все происходит полностью автоматически.
                                              0
                                              Не совсем понятно.
                                              К примеру, идет атака с одного сервера. На всех роутерах по пути пакетов не включен мултипас (то есть у них в таблице маршрутизации всего один активный маршрут к вашему адресу), соответственно все пакеты прийдут в одну точку. Этой точкой будет ваш роутер. Далее единственным способом перенаправить часть этих пакетов на территориально отдаленную ноду будет пробрасывать трафик через какой-нибудь GRE, тем самым лишний раз нагружать оборудование и канал. Вы именно это имели ввиду?
                                            0
                                            Извините за неосведомленность, а «гео-кластеризация» это принцип CDN — Content Delivery Network — когда сервера разнесены в разных точках мира поближе к предполагаемому клиенту?
                                              0
                                              Такое возможно теоретически, но мы не используем данную методику из-за проблем с рассинхронизацией в базах данных которая произойдет если директор/детектор видит все ноды кластера, но при этом ноды потеряли контакт между собой (т.е. фактически клиент в США записал что-то в ноду, которая ближе к нему, а клиент в России записал в ноду которая ближе к нему, в результате когда линк поднимается мы наступаем на грабли идентичных индексов в базе данных, и критериев какой из них более новый/верный здесь не хватает, особенно если записи сделаны одновременно). Посему вариант с детекцией по ближе-дальше мы отменили, и используем только лишь вариант доступен/недоступен и принудительно делаем распределение трафика исходя из нагрузки на трафик по каждой ноды а также по нагрузке по ресурсам на каждую ноду.
                                            0
                                            Стандартные инструменты разложии по полочкам с одной точкой входа. Для 90% сайтов самые актуальные аспекты защиты как раз в том сегменте, который автор сочно описал «прокси-сервер, способный отличить бота от настоящего клиента». Как по мне такая централизованная схема помимо высокой стоимости имеет ещё одну проблему — вся нагрузка от атаки концентрируется с точки зрения канала в одной точке, это значит что атакуемый будет либо очень много платить датацентру за канал (было бы весьма интересно услышать почём нынче 10G в приличном ДЦ) либо иметь массу проблем с площадкой. Если уже обсуждать решение с такой стоимостью владения хочется видеть каналы обратной связи — ведь атакующего иногда нельзя определить на фильтре а можно только на бекенде, соответсвенно сервер должен уметь оповещать фильтр о проблемах. Также не хватает на мой взгляд средства связи с канальными операторами — 10G полагаю подразумевает наличие нескольки кериеров и IP идентифицированные как реальные и атакующие нужно как-то им сообщать чтобы блокировть трафик ещё до того как вам за него надо платить. Ну и остаётся открытым вопрос HTTP флуда в режиме эмуляции клиента, когда нету сотен тысяч коннектов а есть скажем 20к ботов который честно лазит по сайту, редкий бекенд (если говорить о простых сайтах а не крупных сервисах) выдержит 20к одновременных клиентов — делает защиту совершенно бесполезной — если модули фильтрации сетей и есть то из схемы этого не видно, а фильтрация по гео- и сервис-кодам всё ещё очень эффективна для скрытых HTTP атак
                                              0
                                              По поводу флуда с эмуляцией клиента:
                                              Честно говоря, не встречал ни одного бота, который бы умел подгружать куки, js, css и картинки. На данный момент, признаков, по которым фронтенд может отличить бота от небота достаточно, была бы фантазия.

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

                                              Если кто-то сделает ботнет из 20 000 нод, которые смогут полностью эмулировать браузер, то жертве придется создавать собственный кластер для бекенда и оптимизировать код, генерить кучу статики — это будет уже скорее высоконагруженная, нежели DDoS устойчивая система.
                                                0
                                                Чтобы определять бота через CSS/JS/куки/картинки/невидимые формы/флеш и прочее нужны соответствующие модули на бекенде или Вы предлагаете набор стандартных ловушек которые можно имплементировать на Ваших реверс проксях фильтрующих? Что касается ботов то тут большой проблемы нет, используются настоящие браузеры, они только автоматизируются. Это не проблема антиддос системы, это просто способ атаки от которого она в виду отсутствия ряда интерфейсов не защищает, что жаль для системы с TCO в пару сотен тысяч USD

                                                Я верно понял что рабочая моджель описанной системы у Вас развёрнута и работает на мощностях УкрТелекома?
                                              0
                                              А это только теория?
                                              Есть ли «история успеха», подтверждающая эти идеи? Описание каких-то подводных камней?
                                                0
                                                Система рабочая, выше в комментах уже писал о том, атаки какого уровня она выдерживает.

                                                В самой схеме, если ее четко придерживаться, подводных камней нет. А вот в конфигах фронтендов их куча. Самый большой камень — проблемы с поисковиками. Поисковики — тоже боты (и очень глупые, умеют только посылать GET запрос), полный список их адресов все время обновляется и, практически, нигде не выкладывается (в интернете можно найти много списков, но поверьте, они далеко не полные).
                                                Отличать их по соответствию прямому проеобразованию бекрезолва адреса бота достаточно проблематично, когда на вас приходит 50 000 гуглботов. Приходится для ботов поисковиков вести отдельный набор правил (отличаем потенциальные поисковики по юзераджентам): например, если одновременно на ноде обнаруживаем больше 3 гуглботов, срабатывает правило, которое отменяет исключения для поисковиков и любые боты начинают баниться. Дальше, как только скрипт по крону увидит окончание атаки (из аксеслога на фронтенде), исключение для поисковиков возвращается обратно. Но вместе с данной схемой еще нужно использовать онлайн списки адресов поисковых ботов, и такие адреса сразу пропускать на бэкенд, даже не записывая в аксеслог. Мы сами активно работает над этим вопросом.
                                                +1
                                                Защита от атак становится серьезной головной болью провайдеров, надеюсь, они и будут предлагать в ближ будущем решения такого уровня

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

                                                Самое читаемое