Защита от 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:
где 1 — это номер AS провайдера (позволяет community оставаться уникальным даже при передаче по сетям других ISP), 666 — уникальный номер community (может быть любым, но рекомендуется использовать 666). Далее создаем Policy для импорта префиксов от нашего пира, выбираем из них префиксы с community blackhole и заворачиваем их в Null (в Juniper это discard):
Назначаем этот policy-statement на eBGP сессию для импортируемых (получаемых) префиксов от клиентов.
Настройка клиентской стороны
Аналогичным образом, сначала, создается community для обозначения префиксов установленных в blackhole:
Значения те же самые как и на стороне провайдера, с той лишь разницей, что номер AS должен соответствовать AS провайдера, то есть, кто выдает community тот и устанавливает его обозначение. Далее создаем policy-statement для добавления community к префиксам которые надо передавать маршрутизатору ISP.
Префиксы выбираются из static маршрутов. Так как маршрутизатор изначально знает только о сетях больше /32, специфичный префикс нужно создавать отдельно. Как видно из правила from, этот policy-statement будет выбирать все статические маршруты с тегом 666 (номер тега может быть любым). Назначаем этот policy-statement в качестве фильтра export на eBGP сессию к нашему провайдеру. Теперь, если есть необходимость поставить адрес сервера в blackhole создаем статический маршрут /32 на нашем маршрутизаторе.
Например, для установки в blackhole адреса указанного на схеме надо выполнить команду:
где 1.1.1.1 — это ip адрес устанавливаемый в blackhole.
Что стало причиной сбоя 30 августа, в ходе которого мировой трафик упал на 3,5%
Глобальный сбой работоспособности интернета произошел по вине американского провайдера CenturyLink. Из-за некорректной настройки межсетевого экрана у пользователей по всему миру наблюдались проблемы с доступом к Google, службам Microsoft, облачным сервисам Amazon, сервису микроблогов Twitter, Discord, сервисам Electronic Arts, Blizzard, Steam, веб-сайту Reddit и многим другим.
Причиной сбоя стало то, что CenturyLink, являясь Level3-провайдером, некорректно сформулировал правило BGP Flowspec в протоколе безопасности. BGP Flowspec используется для перенаправления трафика, так что эта ошибка привела к серьезным проблемам с маршрутизацией внутри сети провайдера, что сказалось и на стабильности глобального интернета. Конечно, сильнее всего пострадали пользователи в США, но отголоски проблем ощущались по всему миру.
Важно отметить, что CenturyLink является третьей про размерам телекоммуникационной компанией Америки, сразу после AT&T и Verizon.
BGP Flowspec по IETF имеет код спецификации RFC 5575 и описан как многопротокольное расширение BGP MP-BGP, которое содержит информацию о доступности сетевого уровня Network Layer Reachability Information (NLRI). BGP FlowSpec — это альтернативный метод сброса атакующего DDoS-трафика с маршрута, который считается более тонким способом уклониться от атаки, нежели RTBH (Remote Triggered Black Hole Filtering), когда блокируется весь трафик с адреса атаки, либо трафик до адреса назначения. Вообще, RTBH — «оружие судного дня» и является крайним средством для прекращения атаки, так как его применение зачастую позволяет атакующему добиться желаемого, то есть изоляции одного из адресов.
BGP FlowSpec действует более тонко и, по сути, является фильтром межсетевого экрана, который вводится в BGP для фильтрации определенных портов и протоколов и определяет, какой трафик по какому маршруту пропускать. Таким образом, «белый» трафик проходит до адреса назначения, а определенный как DDoS — сбрасывается с маршрута. Трафик анализируется минимум по 12 параметрам NLRI:
Каких-то полноценных отчетов о сбое от самих CenturyLink нет, они только упоминают свой дата-центр недалеко от Онтарио. Однако сбой маршрутизации был достаточно серьезным, чтобы на него обратили внимание не только рядовые пользователи, но и инженеры CloudFlare, которые тоже пользуются услугами CenturyLink как крупного провайдера.
Согласно отчету CloudFlare, все началось с резкого роста 522 ошибки в 10:03 по Гринвичу 30 августа.
Так, автоматической системе ре-машрутизации на случай сбоев удалось сократить количество ошибок и снизить их до 25% от пикового значения, но проблемы со связностью сети и доступностью ресурсов все еще сохранялись и имели глобальный характер. Все это было сделано в окне между 10:03 на начало сбоя и до 10:11 по UTC. За эти восемь минут автоматика и инженеры отключили свою инфраструктуру от CenturyLink в 48 (!) городах Северной Америки и перебросили трафик на резервные каналы других провайдеров.
Очевидно, что так поступали не только в CloudFlare. Однако это не позволило полностью решить проблему. Для наглядности, какое влияние проблемный провайдер имеет на телеком-рынок США и Канады, инженеры компании привели официальную карту доступности услуг CenturyLink:
В США провайдером пользуется 49 миллионов человек, а это означает, что для некоторых клиентов, если говорить об отчете CloudFlare, и даже целых дата-центров CenturyLink является единственным доступным провайдером.
В итоге, из-за почти полного падения CenturyLink специалисты CloudFlare зафиксировали сокращение мирового интернет-трафика на 3,5%. Вот как это выглядело на графике по шести основным провайдерам, с которыми работает компания. CenturyLink на нем — красный.
О том, что сбой был глобальным, а не просто «проблемой в дата-центре под Онтарио», как заявил сам провайдер, свидетельствует и размер обновлений правил Flowspec. Обычно размер обновления конфигураций BGP Flowspec составляет около 2 мегабайт, но специалисты CloudFlare зафиксировали обновления конфигураций BGP размером до 26 Мб (!).
Эти обновления, которые распространяются раз в 15 минут, делятся с узлами сети информацией об изменениях в работоспособности маршрутов. Это позволяет гибко реагировать на какие-то локальные проблемы. Обновления размером в 10-15 раз выше обычных говорят о том, что практически вся сеть провайдера легла или наблюдались крайне серьезные проблемы со связностью.
В CloudFlare считают, что причиной сбоя стало некорректное глобальное правило BGP Flowspec, которое получило подавляющее большинство маршрутизаторов, ушедших потом в реверсивную перезагрузку в попытках восстановить соединение. Это укладывается в картину сбоя, который продолжался более 4 часов. Именно при перегрузке памяти и ЦП маршрутизаторов инженеры могли потерять удаленный доступ к ряду узлов и управляющих интерфейсов.
К слову, подобная история далеко не уникальна. Чуть более года назад интернет по всему миру «прилег» по вине самих CloudFlare и сбоя в работе их DNS, плюс эта же компания честно упоминает о похожих проблемах с Flowspec еще семь лет назад, после которых они отказались от его использования.
Защита от DDoS-атак с точки зрения оператора связи. Часть 1
Мы активно следим за всеми статьями по теме DDoS, которые публикуются на Хабрахабре, и несмотря на то, что поиск по всем потокам на момент написания статьи показывал 820 публикаций, решили, что было бы неплохо от лица оператора связи поделиться видением проблематики выявления и борьбы с DDoS-атаками.
В первой статье попробуем познакомить читателей с базовыми понятиями. Статья рассчитана скорее на новичков, которые в базе понимают сетевые технологии, но никогда не сталкивались с промышленными решениями по защите от DDoS, и если данный материал вызовет интерес, то в следующем цикле статей начнем подробно раскрывать технические детали.
Чем характерно решение по защите от DDoS-атак для операторов связи?
Особенность построения решений по анализу трафика и выявления DDoS-атак для оператора связи неразрывно связана с архитектурой построения его сетей, а также с возможностями сетевого оборудования. Давайте рассмотрим это на примере: упрощенно архитектура магистральной IP/MPLS сети Ростелеком (AS12389) выглядит следующим образом.
Здесь upstream — вышестоящий оператор связи, peer — равноправный оператор связи или также крупный контент-генератор, а customer — клиент AS12389
А теперь давайте мысленно переложим дизайн сети на географию:
И, наконец, в цифрах представим количество взаимосвязей с upstream/peer/customer (https://radar.qrator.net)
Таким образом, даже никогда не имевшему дело с проектированием или эксплуатацией операторской сети легко понять: сеть имеет множество стыков и подключений, а природа маршрутизации трафика асимметрична, т. е. трафик в направлении к какому-либо IP-префиксу и от него идет по разным маршрутам. В отличии от дата-центров или корпоративных сетей у операторов связи нет границы в классическом понимании, и поставить средства анализа в одной или нескольких точках на границе не представляется возможным. Поэтому архитектурно эффективно строить AntiDDoS систему, состоящую из двух подсистем:
Как происходит детектирование DDoS-атак?
На данный момент AS12389 — это более 300 маршрутизаторов, поэтому для сбора NetFlow развернута инфраструктура коллекторов, которые позволяют на высокой скорости принимать, обрабатывать и писать в базу данных. С учетом того, что по сети передаются терабиты в секунду, то даже при использовании механизма сэмплирования с высоким коэффициентом (>4k) маршрутизаторы генерируют более 300 тыс NetFlow записей в секунду. Сэмплинг позволяет анализировать не каждый прошедший через маршрутизатор пакет, а выборочно в соответствии с проприетарным алгоритмом, который реализуют вендоры в своем оборудовании, что снижает нагрузку на Control Plane или на сервисную карту маршрутизатора.
На коллекторах создаются так называемые Binning Table, в которые мапится NetFlow и собирается статистика по объектам защиты. Под объектом защиты мы понимаем сущность в системе, которая описывается каким-либо из следующих признаков:
Список доступных полей:
В зависимости от процента превышения порога аномалии разделяются на три типа по уровню критичности: low, medium и high. Чаще всего low-аномалии характеризуются всплеском легитимного трафика, например, запущенная маркетинговая компания, в ходе которой пользователей на защищаемый веб-сайт пришло больше, чем обычно. Поэтому специалисты дежурной смены более пристально следят за medium и high аномалиями.
Как происходит фильтрация DDoS-атак?
После того, как система выявила аномалию в отношении защищаемого ресурса, его трафик можно перенаправить на фильтрацию в ручном, либо автоматическом режиме.
Существует несколько методов фильтрации:
Перенаправление осуществляется путем анонсирования внутри AS12389 more-specific маршрута к защищаемому объекту через ЦОТ. Тем самым весь трафик, включая паразитный, стягивается в ЦОТ, где происходит его фильтрация, затем «чистый» трафик доставляется в сеть клиента. Для того чтобы избежать петель маршрутизации, мы используем механизм доставки трафика через MPLS, передавая маршрутные метки через BGP Labeled-Unicast (механизмам доставки очищенного трафика будет посвящена отдельная статья). Выбрав данный метод, а также единожды настроив свое оборудование, мы исключаем необходимость дополнительных настроек на стороне клиента. Таким образом, любой, кто имеет подключение к AS12389, может быть защищен. Ответный трафик от клиента маршрутизируется по best-path, т.е. без изменения в маршрутизации, и тем самым не попадает в ЦОТ. Поэтому образуется безусловная асимметрия, у которой есть как свои недостатки (возможность в применении определенных контрмер и анализе ответов приложения), так и преимущества (не увеличивает задержку для ответного трафика).
Асимметрия в способе доставке трафика влияет на набор возможных контрмер (правил фильтрации), что заставляет разработчиков системы искать такие варианты определения паразитного трафика и ботов, которые бы основывались только на входящем трафике.
Несмотря на то, что детектирование атак не включает в себя прикладной уровень, фильтрация трафика происходит вплоть до уровня L7 модели OSI, с применением как сигнатурных, так и поведенческих методов.
ЦОТ построен на специализированном оборудовании на базе ATCA-платформ, что позволяет получать высокую производительность фильтрации (включая прикладной уровень) на одно шасси. В последние годы, с появлением таких технологий, как Intel DPDK, HyperScan, сетевых карт 10G и 40G, а также увеличением количества ядер CPU, появилась возможность достаточно эффективно распараллеливать обработку сетевых потоков, поэтому в ближайшее время мы планируем уходить с ATCA на сервера x86 архитектуры.
Для чего тогда нужен Flow Specification и как его использовать?
Все современные маршрутизаторы операторского класса имеют встроенные механизмы фильтрации вплоть до L4 OSI, которые могут называться у разных производителей по-своему, но в общем случае принято называть Access Control List (ACL). ACL реализован аппаратно в линейных картах и способен фильтровать как транзитные пакеты, так и те, что предназначены самому маршрутизатору на скорости канала или на близкой к ней (line-rate), что делает эту технологию достаточно полезной в случае, если нам нужно срезать паразитный трафик как можно ближе к источнику атаки, т.е. на границе нашей сети. Но т.к. ACL конфигурируется локально на каждом маршрутизаторе, а как мы говорили, у нас их больше 300, то в случае атаки оперативное применение фильтров становиться невозможным. С целью централизованного управления (создание, удаление) ACL был разработан протокол BGP Flow Specification (RFC 5575).
Некоторые операторы предоставляют FlowSpec как сервис своим клиентам, Ростелеком пока это не делает, т.к. активно использует его в собственных целях, а количество правил, поддерживаемых маршрутизаторами, пока еще недостаточно велико. Мы рекомендуем вам обратиться к своему оператору и узнать о наличие подобного сервиса, т.к. FlowSpec реализован в таких проектах, как ExaBGP, что позволяет получить доступный инструмент для установки фильтров на сети оператора и защищаться от атак, направленных на канал, не покупая дорогостоящий сервис. Этот вариант защиты устроит далеко не всех, но может оказаться достаточной и недорогой альтернативой полноценного AntiDDoS сервиса.
Система, которую используем мы, позволяет распространять эти фильтры напрямую из web-интерфейса. Таким образом мы можем настроить тригеры и создавать задания фильтрации из задетектированной системой аномалии автоматически.
Разные производители сетевого оборудования, а также разные версии операционных систем этих производителей могут применять данные фильтры либо ко всем интерфейсам, либо к выборочным, таким образом снижая нагрузку на оборудование, не прогоняя каждый пакет из каждого интерфейса через цепочку правил.
В основном FlowSpec мы используем как первый эшелон фильтрации для тех атак, которые хорошо поддаются шаблонизации до L4: сюда отлично укладываются почти все UDP-based Amplification атаки. Это позволяет не гнать паразитный трафик до ЦОТ, а срезать его как можно раньше, и уже для оставшегося трафика выполнять «тонкую» очистку.
Есть ли место для Blackhole?
В самом базовом случае, в том числе, когда паразитный трафик направлен в сторону ресурса, на котором ничего не опубликовано (а такое тоже бывает), в распоряжении оператора есть возможность отправить весь трафик к этому ресурсу в Blackhole. Для этого на каждом маршрутизаторе задается маршрут, next-hop которого смотрит в discard, т.е. трафик попросту сбрасывается. При необходимости централизованного распространения Blackhole используют систему route-reflector’ов, трафик к префиксу прописывают на одном из них, и в результате данный маршрут получают все маршрутизаторы.
А что насчет Blackhole community?
Хорошим тоном для оператора является использование различных BGP CommunitiesAttribute для возможности клиента управлять своим трафиком. Одним из таких community является Blackhole Community. Обычно данную информацию операторы публикуют в ремарках базы данных маршрутной информации к своей автономной системе, например, RIPE. Для «Ростелекома» данным community является 12389:55555. Префиксы с данным community принимаются вплоть до /32, при этом с другими – не специфичнее, чем /24.
Взаимодействуют ли операторы между собой в части защиты от DDoS-атак?
В каких-то вопросах — да, в основном это касается включения BGP FlowSpec на своих стыках, но делают это довольно осторожно, т.к. периодически выявляются баги в реализации протокола на оборудовании того или иного вендора. В остальных случаях, т.к. услуга защиты от DDoS атак все-таки является коммерческой, то в силу конкуренции отсутствуют технические и организационные методы взаимодействия обмена информацией об атаках (такие как IoC).
На базе каких решений строятся операторские системы выявления и защиты от DDoS-атак?
В России наибольшую популярность снискали следующие решения:
Чем отличаются операторы от облачных сервисов?
Оператор связи предоставляет сервис только тем клиентам, которые физически подключены к его сети, потому что, как вы уже поняли, собирать статистику по трафику и перенаправить на фильтрацию в ЦОТ оператор может только внутри своей сети. Подключение к услуге по защите от DDoS-атак не требует каких-либо действий со стороны клиента (в нашем случае). Также оператор защищает весь канал, а не отдельно взятые приложения и сервисы, что позволяет получить полноценную защиту для всей IT-инфраструктуры.
На начальном этапе своего развития облачные сервисы брали под защиту только web-сайты. Перенаправление трафика происходило путем изменения А-записи в DNS на IP адрес из IP-пула облака. Очищенный трафик до клиентов доставлялся методом reverse-proxy. Этот метод перенаправления и доставки до сих пор актуален и является наиболее популярным. Но в случае, если у заказчика помимо web-сайта имелись и другие критичные ресурсы (DNS, почтовые сервера и т.д.), которые необходимо было защищать, данный метод не позволял перенаправить в облако весь трафик. Тогда облачные сервисы начали подключать сети заказчиков по VPN, что по сути сделало их оверлейными интернет-провайдерами, которые начали фильтровать не отдельно взятое приложение, а весь канал.
В последнее время операторы также начинают разворачивать на своей сети кластеры с reverse-proxy и WAF, что позволяет брать под защиту клиентов, расположенных вне их сети. Тем самым мы видим, что условная граница между операторами и облачными сервисами начинает стираться.
Пожалуй, не имеет большого смысла сравнивать сферического оператора со сферическим облаком, т.к. даже последние могут значительно отличаться между собой. Например, одни разрабатывают систему самостоятельно, вторые строят на базе готовых промышленных решений различных вендоров, третьи имеют распределенную по миру сеть ЦОТ, подключенных к разным upstream операторам, четвертые имеют один или несколько ЦОТ на территории одной страны с подключением к одному из местных операторов связи, пятые требуют обязательной установки сенсоров на площадке заказчика, шестые специализируются только на web-трафике. Данную тему мы постараемся раскрыть в своих будущих статьях.
Подводя итоги, как мы увидели выше, для оператора связи характерны следующие черты:
