bgp flowspec что такое

Защита от 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 еще семь лет назад, после которых они отказались от его использования.

Источник

Перенаправление трафика на фильтрацию (URL, Layer 7, etc.) с применением BGP FlowSpec

Реализация на сети технологий MPLS и VPN позволяет реализовать гибкую схему управляемого перенаправления трафика на узлы фильтрации Layer7, URL, etc. Узлы фильтрации могут быть интегрированы в общую геораспределенную сеть ISP, оператора защиты от DDoS или, в зависимости от особенностей топологии сети, может быть реализована централизованная схема фильтрации.

Схема типового узла приведена ниже:

В схеме без фильтрации по L7 трафик из WAN поступает через форвардинг таблицы default.inet.0 на устройство фильтрации трафика по Layer 3 и Layer 4. Очищенный трафик направляется в сеть клиента через vrf protected.

Для перенаправления трафика на L7 фильтрацию создан новый routing-instances proxy c RD 65000:200, в котором маршрутная информация распространяется между всеми маршрутизаторами в сети, в iBGP включена кроме AFI inet-vpn-unicast дополнительно AFI inet-vpn-flow в MP-BGP, позволяющая передавать информацию FlowSpec в соответствующем vrf.

PE-1> show bgp neighbor 192.168.1.2 | match «NLRI for this session: |Table|Received prefixes:| Accepted prefixes:»
NLRI for this session: inet-unicast inet-vpn-unicast l2vpn inet6-labeled-unicast inet-vpn-flow

Table proxy.inet.0 Bit: b0000
Received prefixes: 4
Accepted prefixes: 4
Table protected.inetflow.0 Bit: c0000
Received prefixes: 1
Accepted prefixes: 1

Конфигурация routing-instances proxy приведена ниже:

PE-1>show configuration routing-instances proxy
instance-type vrf;
interface ae0.800;
interface ae0.801;
interface ae0.924;
route-distinguisher 65000:200;
vrf-target <
import target:65000:200;
export target:65000:200;
>
vrf-table-label;
routing-options <
static <
route 0.0.0.0/0 <
next-table protected.inet.0;
preference 200;
>
>
flow <
term-order standard;
>
>
protocols <
bgp <
import default-proxy;
export reject-all;
group Redirect <
type external;
passive;
peer-as 65501;
multipath;
neighbor 10.0.2.202 <
local-address 10.0.2.201;
>
neighbor 10.0.2.206 <
local-address 10.0.2.205;
>
>
>
>

В конфигурации протокола BGP routing-instances proxy указаны два neighbors устройств фильтрации по Layer7 для обеспечения избыточности одного узла.

Перенаправление трафика на L7 фильтрацию осуществляется следующим образом:
С Control Server (сервер управления), имеющего поднятую eBGP-сессию с family inet flow в routing-instances protected анонсируется по FlowSpec маршрут с соответствующими атрибутами для перенаправления трафика из routing-instances protected в routing-instances proxy. Пример ниже:

192.168.200.1*,proto=6,dstport=80,dscp=48/term:1
*[BGP/170] 4d 19:59:37, localpref 100, from 10.22.2.2
AS path: 65501 I, validation-state: unverified
Fictitious

Данный анонс распространяется по всем маршрутизаторам сети по inet-vpn-flow.

Конфигурация протокола BGP маршрутизатора для FlowSpec с Control Server приведена ниже:

PE-1> show configuration routing-instances protected protocols bgp group Servers neighbor 10.22.2.2
description «Proxy FlowSpec»;
passive;
import Import_proxy_flowspec;
family inet <
flow <
prefix-limit <
maximum 200;
teardown;
>
no-validate Redirect-to-proxy;
>
>
export reject-all;
peer-as 65501;

Параметр no-validate позволяет FlowSpec маршрутам быть активными без валидации данных анонсов в inet.0. Примененное к neighbor policy осуществляет match по передаваемому FlowSpec community и перенаправляет трафик в routing-instances proxy. Пример конфигурации policy и community приведен ниже:

PE-1> show configuration policy-options policy-statement Redirect-to-proxy
term 1 <
from community redirect;
to instance proxy;
then accept;
>
term 2 <
then accept;
>

PE-1> show configuration policy-options community redirect
members redirect:65000:200;

Далеко не положительной особенностью является общий forwarding для всех instances, участвующих во FlowSpec, что приводит к постоянному циклическому форвардингу пакетов между instances, где они «умирают» по ТТL. Решением данной проблемы стало раскраска трафика маркерами dscp на выходе устройств фильтрации Layer3,4 и сброс этих маркеров для трафика на выходе vrf proxy. Данное решение реализовано применением интерфейсных firewall filters и анонсом во FlowSpec match dscp, совпадающего с раскраской dscp на выходе устройств фильтрации Layer3,4. Примеры обоих фильтров приведены ниже:

PE-1> show configuration firewall filter mark_dscp_proxy
term 1 <
from <
protocol tcp;
destination-port [ 80 483 ];
>
then <
accept;
dscp cs6;
>
>
term 2 <
then accept;
>

PE-1> show configuration firewall filter clear_dscp
term 1 <
from <
protocol tcp;
destination-port [ 80 483 ];
>
then <
accept;
dscp cs0;
>
>
term 2 <
then accept;
>

Для маршрутизации трафика на фильтры Layer7 с каждым из них поднята BGP-сессия, в которой всеми фильтрами анонсируется маршрут 0.0.0.0/0, являющийся anycast и основным маршрутом в таблице:

Источник

BGP FlowSpec – DDoS Mitigation

Introduction to BGP FlowSpec

BGP FlowSpec feature permit implementation and propagation of filtering and policing configuration across the large number of BGP peer routers to mitigate the effects of a distributed denial-of-service (DDoS) attack in the network from internet. Another method to mitigate from DDOS attack is Remotely triggered black hole (RTBH) filtering, a technique that provides the ability to drop undesirable traffic before it enters a protected network.

DDoS Overview

Distributed denial-of‐service (DDoS) attacks target network infrastructures or computer services by sending a number of service requests towards the server from many sources.

Addressing DDoS attacks

Detection: Detect incoming fake requests.

Mitigation: Forward traffic to a FlowSpec router that removes the UDP DDOS packets from the traffic stream while retaining the legitimate packets and send back the clean traffic to the server.

Goals of DDoS Mitigation

FlowSpec is used to mitigate the DDoS attack, but its use cases are expanding to other areas such as BGP unequal cost load balancing. With BGP flow specification, it’s possible to identify groups of users based on source address and then use FlowSpec to traffic on all core nodes. FlowSpec NLRI Types are as:

BGP FlowSpec Components

Controller: Injects rules remotely in the clients via control plane. BGP FlowSpec Controllers hardware are as: Router (ASR9K, CRS, NCS6000, XR12000), Server (Arbor Peak BGP flow specification Collector Platform), Virtual router (XRv).

Client: Receives rules from Controller(s) and programs the match/action in hardware at both Control Plane and Data Plane. Examples of BGP flow specification Clients: Router (ASR9K, ASR1K).

Route-Reflector (optional): Receives rules from Controller(s) and distributes them to Clients. Examples of BGP flow specification Route-Reflectors: ASR9K; CRS; NCS6000 or XRv.

Download the command table here.

Conclusion

BGP Flow Specification is a new feature to assist in DDOS mitigation is a. Flowspec uses the BGP protocol extension to distribute flow specification filters to network routers. Expanding routing information with FlowSpec, the routing system can take advantage of class map and policy map filtering capabilities on the forwarding path to prevents from DDOS attack.

Источник