BGP Communities и Blackhole

BGP Communities

BGP Communities является опциональным транзитивным (optional transitive) атрибутом маршрутов BGP, т.е. маршрутизатор, не поддерживающий данный атрибут, просто передаст его другому маршрутизатору без изменений. Атрибут BGP Communities может передаваться как внутри одной AS, так и между разными AS. С помощью BGP Communities «помечаются» (можно ещё сказать теггируются) маршруты BGP, с которыми в дальнейшем возможно выполнить те или иные действия на основании данного Community (например поменять Local Preference, ). Т.о. данный атрибут «приклеивается» к определённому маршруту/префиксу, передаваемому в update’ах через BGP. Атрибут BGP Communities в чём-то напоминает теггирование маршрутов (route tag) в классическом варианте. BGP Communities — это 32-ух битное значение от 0 до 4 294 967 200, записываемые, как правило, в формате AS_NUMBER:VALUE, где AS_NUMBER — номер AS, установившей данный community (значения «все нули» и «все единицы» зарезервированы), VALUE — произвольное числовое значение. Для представления BGP Communities в таком виде на оборудовании Cisco необходимо добавить команду:

ip bgp-community new-format

в режиме глобального конфигурирования.

Существуют так называемые well known communities, и имеют они не числовое значение:

  • no-advertise — update с таким community не будет передан ни одному пиру
  • no-export — update с таким community не будет передан ни одному внешнему пиру, кроме внешних пиров внутри конфедерации. Является одним из наиболее распространённых community
  • local-as — update с таким community будет передан только внутри локальной AS или в AS — члене конфедерации
  • internet — update с таким community будет передан повсюду

Следует отметить, что на оборудовании Cisco, атрибут BGP Communities по-умолчанию не отправляется ни EBGP-, ни IBGP-пирам. Чтобы это исправить, необходима команда в конфигурации BGP:

neighbor x.x.x.x send-community


Для более понятного представления о BGP Communities лучше рассмотреть их применение на практике. Разберём следующий пример применения BGP Communities, в котором на один из принадлежавших нам серверов производится DDoS-атака, и нам необходимо изъять внешний IP-адрес этого сервера из обновлений BGP. Топология будет представлять такой маленький-маленький Интернет:

BGP-1-1

«Красные» компьютеры справа на рисунке производят DDoS атаку «синего» сервера слева на картинке. Каждый из «красных» подключен к своему провайдеру, у которого в свою очередь имеется маршрут через интернет в сеть 172.16.1.0/24 нашей автономной системы 65001. Полностью отключаться от Интернета при DDoS атаке не хотелось бы, т.к. в нашей сети могут быть ещё сервера, к которым необходим доступ из Интернета.

Одним из способов «убрать» из под DDoS атаки только атакуемый сервер — анонсировать провайдерам IP адрес сервера (по маске /32) как недоступный. Провайдеры в свою очередь так же станут анонсировать своим BGP-пирам этот IP адрес как недоступный. В итоге во всём нашем маленьком-маленьком Интернете не станет маршрута до IP адреса атакуемого сервера и DDoS-трафик от атакующих машин будет доходить только до провайдера, к которому подключены атакующие компьютеры. Плюсом здесь ещё будет то, что мы разгрузим канал до наших провайдеров от DDoS-трафика, который может препятствовать или затруднять прохождение легитимного трафика.

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

Показать »

R1#show ip route bgp
172.16.0.0/16 is variably subnetted, 8 subnets, 2 masks
B 172.16.12.0/24 [20/0] via 172.16.10.0, 2d18h
B 172.16.13.0/24 [20/0] via 172.16.9.0, 2d17h
B 172.16.9.0/24 [20/0] via 172.16.9.0, 2d18h
B 172.16.10.0/24 [20/0] via 172.16.10.0, 2d18h
B 172.16.11.0/24 [20/0] via 172.16.9.0, 2d18h

R11#show ip route bgp
172.16.0.0/16 is variably subnetted, 8 subnets, 2 masks
B 172.16.12.0/24 [20/0] via 172.16.13.0, 2d18h
B 172.16.13.0/24 [20/0] via 172.16.13.0, 2d18h
B 172.16.9.0/24 [20/0] via 172.16.11.1, 2d18h
B 172.16.10.0/24 [20/0] via 172.16.11.1, 2d18h
B 172.16.1.0/24 [20/0] via 172.16.11.1, 2d17h

R12#show ip route bgp
172.16.0.0/16 is variably subnetted, 8 subnets, 2 masks
B 172.16.13.0/24 [20/0] via 172.16.13.2, 2d18h
B 172.16.9.0/24 [20/0] via 172.16.12.1, 2d18h
B 172.16.10.0/24 [20/0] via 172.16.12.1, 2d18h
B 172.16.11.0/24 [20/0] via 172.16.13.2, 2d18h
B 172.16.1.0/24 [20/0] via 172.16.12.1, 2d17h

R13#show ip route bgp
172.16.0.0/16 is variably subnetted, 8 subnets, 2 masks
B 172.16.12.0/24 [20/0] via 172.16.13.3, 2d18h
B 172.16.9.0/24 [20/0] via 172.16.13.1, 2d18h
B 172.16.10.0/24 [20/0] via 172.16.13.3, 2d18h
B 172.16.11.0/24 [20/0] via 172.16.13.1, 2d18h
B 172.16.1.0/24 [20/0] via 172.16.13.3, 2d17h

Видим, что на каждом маршрутизаторе, к которым подключены атакующие компьютеры есть маршрут в сеть атакуемого сервера 172.16.1.0/24. Проверить доступность сервера 172.16.1.50 можно командой ping с любого из маршрутизаторов R11, R12, R13 — пример с R13:

Показать »

R13#ping 172.16.1.50

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.50, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/85/172 ms

При этом маршрутизатор R1 анонсирует BGP-пирам следующие префиксы:

Показать »

R1# sh ip bgp neighbors 172.16.9.0 advertised-routes
BGP table version is 10, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i — internal,
r RIB-failure, S Stale
Origin codes: i — IGP, e — EGP, ? — incomplete

Network Next Hop Metric LocPrf Weight Path
*> 172.16.1.0/24 0.0.0.0 0 32768 i
*> 172.16.9.0/24 172.16.9.0 0 0 65009 i
*> 172.16.10.0/24 172.16.10.0 0 0 65010 i
*> 172.16.11.0/24 172.16.9.0 0 65009 65011 i
*> 172.16.12.0/24 172.16.10.0 0 65010 65012 i
*> 172.16.13.0/24 172.16.9.0 0 65009 65011 65013 i

Total number of prefixes 7

и

R1# sh ip bgp neighbors 172.16.10.0 advertised-routes
BGP table version is 10, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i — internal,
r RIB-failure, S Stale
Origin codes: i — IGP, e — EGP, ? — incomplete

Network Next Hop Metric LocPrf Weight Path
*> 172.16.1.0/24 0.0.0.0 0 32768 i
*> 172.16.9.0/24 172.16.9.0 0 0 65009 i
*> 172.16.10.0/24 172.16.10.0 0 0 65010 i
*> 172.16.11.0/24 172.16.9.0 0 65009 65011 i
*> 172.16.12.0/24 172.16.10.0 0 65010 65012 i
*> 172.16.13.0/24 172.16.9.0 0 65009 65011 65013 i

Total number of prefixes 7


Метод, с помощью которого будем «выводить» сервер из под DDoS атаки называется BGP Blackhole. Суть этого метода — объявить BGP-пиру с помощью BGP Communities о недоступности определённого IP-адреса или префикса, для чего необходимо согласовать с BGP-пиром тот самый BGP Community, с помощью которого будет происходить данный процесс. Существует негласная договорённость использовать для BGP Blackhole community в формате AS_NUMBER:666, где AS_NUMBER — номер нашей AS, однако не у всех ISP используется именно этот community для BGP Blackhole.

Начнём настройку со стороны AS клиента, т.е. с AS65001 топологии, на маршрутизаторе R1.

1). Создаём на маршрутизаторе R1 маршрут в Null0 на атакуемый IP-адрес (чтобы в последующем анонсировать данный маршрут через BGP):

R1(config)#ip route 172.16.1.50 255.255.255.255 Null 0

2). Создаём ACL, в котором указываем IP-адрес атакуемого сервера:

R1(config)#access-list 66 permit host 172.16.1.50

3). Далее этот ACL используем в Route-map’е:

R1(config)#route-map BLACKHOLE-BGP permit 10
R1(config-route-map)#match ip address 66
R1(config-route-map)#set community 65001:666

R1(config)#route-map BLACKHOLE-BGP permit 20

т.е. маршруту 172.16.1.50/32 присваиваем community 65001:666, остальные префиксы анонсируются без изменений

4). «Вешаем» созданный route-map на BGP-пиров в «исходящем» направлении:

R1(config)#router bgp 65001
R1(config-router)#neighbor 172.16.9.0 route-map BLACKHOLE-BGP out
R1(config-router)#neighbor 172.16.10.0 route-map BLACKHOLE-BGP out

5). Включаем редистрибьюцию статических маршрутов в BGP (для того, чтобы префикс 172.16.1.50/32 анонсировался через BGP):

R1(config)#router bgp 65001
R1(config-router)#redistribute static

Если на маршрутизаторе только один статический маршрут, то такой подход при редистрибьюции подходит, в противном случае целесообразнее выполнять редистрибьюцию статических маршрутов в BGP на основании Route-map.

Настройка на стороне «клиентского» маршрутизатора R1 закончена; перечень анонсируемых маршрутизатором R1 через BGP префиксов изменился:

Показать »

R1# sh ip bgp neighbors 172.16.9.0 advertised-routes
BGP table version is 10, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i — internal,
r RIB-failure, S Stale
Origin codes: i — IGP, e — EGP, ? — incomplete

Network Next Hop Metric LocPrf Weight Path
*> 172.16.1.0/24 0.0.0.0 0 32768 i
*> 172.16.1.50/32 0.0.0.0 0 32768 ?
*> 172.16.9.0/24 172.16.9.0 0 0 65009 i
*> 172.16.10.0/24 172.16.10.0 0 0 65010 i
*> 172.16.11.0/24 172.16.9.0 0 65009 65011 i
*> 172.16.12.0/24 172.16.10.0 0 65010 65012 i
*> 172.16.13.0/24 172.16.9.0 0 65009 65011 65013 i

Total number of prefixes 7

и

R1# sh ip bgp neighbors 172.16.10.0 advertised-routes
BGP table version is 10, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i — internal,
r RIB-failure, S Stale
Origin codes: i — IGP, e — EGP, ? — incomplete

Network Next Hop Metric LocPrf Weight Path
*> 172.16.1.0/24 0.0.0.0 0 32768 i
*> 172.16.1.50/32 0.0.0.0 0 32768 ?
*> 172.16.9.0/24 172.16.9.0 0 0 65009 i
*> 172.16.10.0/24 172.16.10.0 0 0 65010 i
*> 172.16.11.0/24 172.16.9.0 0 65009 65011 i
*> 172.16.12.0/24 172.16.10.0 0 65010 65012 i
*> 172.16.13.0/24 172.16.9.0 0 65009 65011 65013 i

Total number of prefixes 7

т.е. добавился префикс на атакуемый сервер

*> 172.16.1.50/32 0.0.0.0 0 32768 ?

и этот префикс распространится через BGP по всей топологии.


На стороне BGP-пиров R9 и R10 видим, что префикс 172.16.1.50/32 «прилетел» с community 65001:666

Показать »

R9#show ip bgp 172.16.1.50
BGP routing table entry for 172.16.1.50/32, version 18
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
2
65001
172.16.9.1 from 172.16.9.1 (1.1.1.1)
Origin incomplete, metric 0, localpref 100, valid, external, best
Community: 65001:666

и

R10#show ip bgp 172.16.1.50
BGP routing table entry for 172.16.1.50/32, version 15
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
2
65001
172.16.10.1 from 172.16.10.1 (1.1.1.1)
Origin incomplete, metric 0, localpref 100, valid, external, best
Community: 65001:666


Теперь настроим маршрутизатор R9 на определённые действия, основываясь на полученном community.

1). Создаём community-list, которым маршрутизатор будет отслеживать community 65001:666

R9(config)#ip community-list 66 permit 65001:666

2). Далее этот community-list используем в Route-map’е:

R9(config)#route-map BLACKHOLE-BGP permit 10
R9(config-route-map)#match community 66
R9(config-route-map)#set ip next-hop 10.0.0.1

R9(config)#route-map BLACKHOLE-BGP permit 20

т.е. при получении из update’ов префиксов с установленным community 65001:666, маршрутам этих префиксов будет установлен hext-hop в Null0 (или в интерфейс Loopback666 (созданный на следующем шаге) в данном примере, т.к. установка в качестве hext-hop’а интерфейса Null0 не добавляет данный маршрут в таблицу BGP — причина не понятна).

3). Создаём маршрут в Null0 и интерфейс Loopback666:

R9(config)#interface loopback 666
R9(config-if)#ip address 10.0.0.1 255.255.255.255
R9(config-if)#exit

R9(config)#ip route 10.0.0.1 255.255.255.255 null 0

4). «Вешаем» созданный route-map на BGP-пира R1 во «входящем» направлении:

R9(config)#router bgp 65009
R9(config-router)#neighbor 172.16.9.1 route-map BLACKHOLE-BGP in

5). Сбрасываем BGP сессию с BGP-пиром R1:

R9#clear ip bgp 172.16.9.1

6). После установления BGP-соседства между R1 и R9 проверяем таблицу маршрутизации на R9 в сеть 172.16.1.50/32:

R9#show ip route 172.16.1.50 255.255.255.255
Routing entry for 172.16.1.50/32
Known via «bgp 65009», distance 20, metric 0
Tag 65001, type external
Last update from 10.0.0.1 00:03:26 ago
Routing Descriptor Blocks:
* 10.0.0.1, from 172.16.9.1, 00:03:26 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 65001

Видно, что теперь next-hop’ом для сети 172.16.1.50/32 является локальный интерфейс Loopback 666 (у которого IP-адрес 10.0.0.1)

Повторяем пункты 1-6 на маршрутизаторе R10.

Теперь проверим трассировку до атакуемого сервера с одного из маршрутизаторов, к которым подключены атакующие компьютеры, например с R13:

R13#traceroute 172.16.1.50

Type escape sequence to abort.
Tracing the route to 172.16.1.50

1 172.16.13.1 56 msec 48 msec 8 msec
2 172.16.11.1 [AS 65011] 12 msec 16 msec 28 msec
3 172.16.11.1 [AS 65011] 20 msec 36 msec 16 msec

Теперь с этого же маршрутизатора ping до атакуемого сервера:

R13#ping 172.16.1.50

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.50, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

Т.е. пакеты, отсылаемые на атакуемый сервер 172.16.1.50, отправляются с R13, но до «адресата» не доходят, а заворачиваются на R9 и R10 в Loopback 666.

Если произвести настройку крайних 6-ти пунктов на каждом маршрутизаторе топологии, то на всех маршрутизаторах маршрут в сеть 172.16.1.50/32 будет выглядеть так (на примере R13):

R13#show ip route 172.16.1.50 255.255.255.255
Routing entry for 172.16.1.50/32
Known via «bgp 65013», distance 20, metric 0
Tag 65011, type external
Last update from 10.0.0.1 00:04:02 ago
Routing Descriptor Blocks:
* 10.0.0.1, from 172.16.13.1, 00:04:02 ago
Route metric is 0, traffic share count is 1
AS Hops 3
Route tag 65011

и трафик, отправляемый на IP адрес 172.16.1.50/32 с данного конкретного маршрутизатора, не выйдет за его «пределы». Таким образом, трафик от атакующих компьютеров будет отбрасываться так сказать «у истока».


После окончания DDoS атаки, просто удаляем первую запись Route-map на маршрутизаторе, расположенном ближе всех к атакуемому серверу, т.е. на R1 для того, чтобы к префиксу 172.16.1.50/32 не добавлялось community:

R1(config)#no route-map BLACKHOLE-BGP permit 10

и маршрут в Null0 на этом же маршрутизаторе:

R1(config)#no ip route 172.16.1.50 255.255.255.255 Null0

Проверяем доступность сервера 172.16.1.50/32 с маршрутизатора R13:

R13#ping 172.16.1.50

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.50, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/42/60 ms

трассировку:

R13#traceroute 172.16.1.50

Type escape sequence to abort.
Tracing the route to 172.16.1.50

1 172.16.13.1 32 msec 12 msec 8 msec
2 172.16.11.1 [AS 65011] 12 msec 16 msec 28 msec
3 172.16.9.1 [AS 65009] 16 msec 32 msec 36 msec
4 172.16.1.50 [AS 65001] 64 msec 68 msec 36 msec

таблицу маршрутизации:

R13#sh ip route 172.16.1.50
Routing entry for 172.16.1.0/24
Known via «bgp 65013», distance 20, metric 0
Tag 65011, type external
Last update from 172.16.13.1 00:06:53 ago
Routing Descriptor Blocks:
* 172.16.13.1, from 172.16.13.1, 00:06:53 ago
Route metric is 0, traffic share count is 1
AS Hops 3
Route tag 65011

Добавить комментарий