Защита от DDOS атак средствами BGP

    Сервера, размещенные в сети администрируемой мной AS, часто подвергаются различным DDOS атакам. Целью атакующих могут быть, как отдельные ресурсы размещенные на серверах, сами сервера и вся площадка в целом. С каждым месяцем количество, сложность и мощность атак возрастает. Атаки в 300-400Мб/с выросли до 70-80Гб/с. В этой ситуации не все атаки могут быть отражены тюнингом серверов, а крупные атаки могут помешать работе и всей площадки в целом. Бороться с такими атаками необходимо силами всей команды хостинга. Сетевые администраторы также должны иметь средства борьбы с такими атаками на сетевом уровне. О таких средствах и пойдет речь под катом.

    В статье будет рассматриваться основной метод защиты от DDOS атак средствами динамической маршрутизации: — метод Blackhole («черной дыры»).
    Этот метод позволяет полностью прекратить поток трафика на атакуемый сервер и снять нагрузку с каналов AS и провайдера. В условиях предоставления услуг виртуального хостинга высокой доступности этот метод является крайней мерой, но остается эффективным средством для борьбы с крупными DDOS атаками, когда другими средствами справиться не удается.

    Поясним несколько терминов, которые будут встречаться в статье:
    BGP (Border Gateway Protocol) — основной протокол динамической маршрутизации в глобальной сети интернет. Позволяет маршрутизаторам обмениваться таблицами маршрутизации. Предоставляет гибкие средства для управления трафиком.
    BGP community — атрибут протокола динамической маршрутизации BGP, позволяющий устанавливать определенные метки на передаваемые маршруты. Атрибут позволяет создавать и устанавливать пользовательские значения (установлен только рекомендуемый формат community) и на их основании гибко настраивать фильтры маршрутизатора.
    peering — установленная сессия BGP для обмена маршрутами.
    Анонсирование сети — в терминологии протоколов динамической маршрутизации, отправка маршрутов из локальной таблицы маршрутизации соседнему маршрутизатору.
    AS (Autonomous System) — набор IP-сетей, управляемых одним оператором по установленным правилам глобальной сети Интернет.
    eBGP (External Border Gateway Protocol) — тип обмена маршрутами по протоколу BGP между маршрутизаторами разных AS.
    iBGP (Internal Border Gateway Protocol) — тип обмена маршрутами по протоколу BGP между маршрутизаторами внутри AS.
    policy-statement — в рамках конфигурации маршрутизаторов Juniper представляет собой набор правил, определяющих условия фильтрации маршрутов, получаемых или передаваемых по протоколам динамической маршрутизации.
    DDOS (Distributed Denial of Service) — распределённая атака типа «отказ в обслуживании». Атака, для которой используется сеть компьютеров по всему миру зараженных вредоносным программным обеспечением (ботнет), осуществляющих генерацию трафика или атаку на жертву.
    UDP Amplification — разновидность DDOS атаки, для реализации которой используются сторонние сервера с открытыми UDP портами и службами SNMP, NTP, DNS. Как правило этот вид атаки направлен на пропускную способность канала жертвы.
    ISP (Internet Service Provider) — организация, предоставляющая услуги доступа к сети Интернет, попросту — провайдер.

    BGP blackhole


    Blackhole позволяет управлять трафиком на уровне провайдера, до попадания в нашу AS. Он эффективен для борьбы с крупными атаками на пропускную способность канала (чаще всего DNS Amplification). В классической схеме метод предполагает выставление next-hop для анонсируемого маршрута на ip адрес из приватной сети. Так как у магистральных провайдеров маршруты до приватных сетей, по большей части, должны быть направлены в Null0 (Cisco терминология, в Juniper — discard) пакеты с адресом назначения из этой сети буду автоматически отбрасываться — попадать в «черную дыру» еще в сети провайдера. К сожалению, в реальных сетях магистральных провайдеров не всегда установлены маршруты приватных сетей в Null0, так как сами провайдеры используют эти адреса для маршрутизации или попросту не следуют рекомендациям RFC. Для установки blackhole, чаще всего, используются расширенные возможности управления маршрутами BGP — BGP community. Метод реализуется путем создания специальной группы (community) для маршрутов, трафик которых необходимо направить в «черную дыру». В момент начала атаки у сетевого администратора атакуемой AS будет возможность передать маршрут с длинной маски /32 подкрепив его этим community, тем самым сообщив маршрутизаторам ISP о том, что пакеты до этого ip адреса должны отбрасываться. Фильтрация пакетов на стороне ISP может осуществляться как с помощью ACL так и с помощью Null интерфейса, но наиболее правильных подход предполагает рекурсивный blackhole. Схематически метод рекурсивного blackhole показан ниже:

    Атакующие из AS3 и AS4 производят атаку на веб-сервер с ip адресом 1.1.1.1 который находится в AS2. Сетевой администратор AS2 устанавливает в blackhole адрес сервера передавая маршрут к его ip адресу с community 666. Маршрутизатор ISP получая маршрут /32 с установленным blackhole community начинает отбрасывать все пакеты направленные на адрес ip 1.1.1.1. Кроме того, чтобы снять нагрузку с собственных каналов, ISP (AS1) передает этот маршрут далее своим провайдерам устанавливая на него blackhole community предоставленные ими (на схеме это community 3:666 и 4:666). Такой метод защиты гораздо эффективнее простой фильтрации пакетов на маршрутизаторе AS2, так как снимает нагрузку с каналов между AS1 и AS2, а также eBGP каналов провайдера AS1. Отбрасывание пакетов направленных на ip адрес 1.1.1.1 происходит на маршрутизаторах провайдеров к которым непосредственно подключены атакующие. Если атакующий подключен к другой AS (не принадлежит AS провайдера), то каждый из провайдеров AS3 и AS4 может анонсировать маршрут с blackhole community дальше своим провайдерам, а те в свою очередь своим и т.д. Таким образом все сети магистральных провайдеров будут разгружены от DDOS трафика.

    практика BGP blackhole


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

    Настройка провайдерской стороны

    Сначала необходимо создать определенный community для обозначения префиксов установленных в blackhole:
     set policy-options community TEST_blackhole members 1:666
    

    где 1 — это номер AS провайдера (позволяет community оставаться уникальным даже при передаче по сетям других ISP), 666 — уникальный номер community (может быть любым, но рекомендуется использовать 666). Далее создаем Policy для импорта префиксов от нашего пира, выбираем из них префиксы с community blackhole и заворачиваем их в Null (в Juniper это discard):
    [edit policy-options policy-statement Blackhole-import]
      term to-blackhole {
          from community TEST_blackhole;
          then {
              community add ISP-community; # Добавляем blackhole community вышестоящего ISP чтобы пакеты отбрасывались еще выше  
              next-hop discard;
              accept;
          }
      }
    

    Назначаем этот policy-statement на eBGP сессию для импортируемых (получаемых) префиксов от клиентов.

    Настройка клиентской стороны

    Аналогичным образом, сначала, создается community для обозначения префиксов установленных в blackhole:
     set policy-options community TEST_blackhole members 1:666
    

    Значения те же самые как и на стороне провайдера, с той лишь разницей, что номер AS должен соответствовать AS провайдера, то есть, кто выдает community тот и устанавливает его обозначение. Далее создаем policy-statement для добавления community к префиксам которые надо передавать маршрутизатору ISP.
    policy-statement Blackhole-export {
          term blackhole {
              from {
                  protocol static;
                  tag 666;
              }
              then {
                  community set TEST_blackhole;
                  accept;
              }
          }
          then reject;
      }
    

    Префиксы выбираются из static маршрутов. Так как маршрутизатор изначально знает только о сетях больше /32, специфичный префикс нужно создавать отдельно. Как видно из правила from, этот policy-statement будет выбирать все статические маршруты с тегом 666 (номер тега может быть любым). Назначаем этот policy-statement в качестве фильтра export на eBGP сессию к нашему провайдеру. Теперь, если есть необходимость поставить адрес сервера в blackhole создаем статический маршрут /32 на нашем маршрутизаторе.
    Например, для установки в blackhole адреса указанного на схеме надо выполнить команду:
    set routing-options static route 1.1.1.1/32 discard tag 666
    

    где 1.1.1.1 — это ip адрес устанавливаемый в blackhole.

    Заключение


    Описанный метод позволяет бороться с атаками, которые мешают корректной работе всей площадки. Такие атаки могут достигать сотен Гигабит/сек и с ними не всегда может справиться даже магистральный провайдер. Атрибут BGP community широко используется магистральными провайдерами для классификации трафика и оперативного управления. Многие ISP предоставляют целый набор community, которые позволяют не только устанавливать определенные адреса в blackhole, но и управлять трафиком поступающим в их AS, то есть управлять трафиком еще на каналах провайдера. Анализ community провайдеров позволяет сетевому администратору разработать схему борьбы с DDOS атаками, а иногда и автоматизировать процесс ликвидации атак.
    Поделиться публикацией
    Похожие публикации
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 13
    • 0
      А через сколько минут\часов новые маршруты начнут применяться? Ведь вряд ли это всё произойдёт мгновенно.
      • +2
        Время установки префикса в такой (рекурсивный) Blackhole как правило 1-3 минуты, пока все провайдеры примут community. Blackhole у первого провайдера срабатывает через ~5-10 секунд, то есть трафик в Вашу AS уже перестанет попадать.
        • 0
          Спасибо за ответ!
      • 0
        Но добавляя в blackhole какую-то AS мы таким образом отсекаем трафик на заданный ip не только от злоумышленников, но и от легитимных пользователей? Получается, что это применимо не для всех AS. Например для AS какого-нибудь российского провайдера (если у нас сайт ориентирован на русскоязычный сегмент) таким образом отсекать может оказаться нецелесообразно.
        • 0
          Ищите аплинка, который умеет flow rules и наслаждайтесь.
          • 0
            Да, Вы отчасти правы, но в статье говорится про атаки с которыми не удается справится иными средствами и из-за которых может страдать вся сеть. Если недоступна вся сеть, то лучше «пожертвовать» одним сервером и разгрузить канал, а потом искать цель атаки (если это сервер с клиентами, например) и заниматься анализом атаки. Кроме того существует возможность более продвинутого blackhole, например, если контент Вашего сервера для России, то в момент атаки можно установить Blackhole только на зарубежный пиринг. Это позволит снизить уровень атаки (по статистике 80% трафика DDOS льется из-за границы) и оставить сервер доступным для Российского сегмента. Многие Российские провайдеры предоставляют расширенные community, которые позволяют такое делать. Существует также метод «сливного туннеля», который позволяет не ограничивая доступ к серверу фильтровать трафик, о нем Вы можете почитать в rfc3882.
          • 0
            Спасибо, полезная статья. Жаль, что в интернете нет никакого стандарта на эту тему (кто-то сказал про BGP flowspec?) и каждый провайдер делает коммьюнити для RTBH, какую захочет, а не xx:666, если делает вообще. К тому же /32 префиксы обычно никто не примет в анонс, для этого надо отдельно договариваться.

            Кстати, на cisco в route-map нельзя поставить next-hop discard, приходится использовать специальный серый IP, который потом заворачивается в Null. И действительно нужен tag, с которым маршруты потом редистрибьютятся в BGP с применением community. На Juniper можно статический маршрут сразу написать с community, без промежуточной прослойки route-tag. У меня как раз подобная схема между бордерами Cisco и Juniper.
            • 0
              Да, к сожалению есть только рекомендации по составлению community.

              Спасибо, не знал про привязку community к static маршрутам. По привычке использовал cisco-way. На самом деле я еще обычно выставляю no-install для static маршрута, чтобы пакеты до этого хоста внутри моей AS не дропались на маршрутизаторе. Это очень полезная функция Juniper, которой к сожалению нет в Cisco.
              • 0
                У Juniper вообще своеобразный взгляд на многие вещи. Чего только стоят LSP с inet.3 таблицей или концепция rib-groups.
            • 0
              «Целью атакующих могут быть, как отдельные ресурсы размещенные на серверах, сами сервера и вся площадка в целом»
              Если вся площадка в целом то blackhole плохой метод. Все подсети в blackhole посылать не вариант.
              • 0
                Согласен, но атаки такого масштаба редко ведутся на целую подсеть, как правило льется все на один хост, но забивает канал всей площадки. Борьба с атакой на несколько серверов сразу, думаю, будет начинаться со снятия зарубежного пиринга, дабы отсечь источник.
              • 0
                Спасибо за статью. Сегодня пришлось настраивать похожий blackhole для BGP пиринга с LEVEL3. Кстати у них используется 3356:9999 community, для этих целей.

                • 0
                  В примере policy не хватает правила, которое ограничивает маску сети
                  from {
                  community TEST_blackhole;
                  route-filter 0.0.0.0/0 prefix-length-range /32-/32;
                  }


                  иначе в один прекрасный момент вам проанонсируют 0/0 и всё отправится в null.
                  Так же считаю целесообразно свои сети вынести из данного правила. (сети серверов, сети связности маршрутизаторов, в том числе и самого маршрутизатора juniper ASBR, на котором поднимается BGP), явно, что тут атаки не должно быть, или её предотвращать уже другими механизмами.

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

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