IP фильтрация (BGP Remote Triggered Blackhole)

Skip to end of metadata
Go to start of metadata
Вы просматриваете старую версию данной страницы. Смотрите текущую версию. Сравнить с текущим  |   просмотр истории страницы

ЧЕРНОВИК

В Carbon Reductor 8.00.07 появилась возможность настроить BGP RTBH надёжнее и с меньшим числом усилий.

Настройка на Carbon Reductor

Всё можно сделать через меню:

Подключитесь по ssh, затем запустите команду меню:

menu

Выберите BGP Blackhole

Настройка

Пути до шаблонов менять не нужно, это редкий случай, когда техническая поддержка подтвердит, что другого способа настроить что-то специфичное нет.

Пароли установите свои и безопасные.

Router ID как правило совпадает с IP адресом Carbon Reductor.

Список маршрутизаторов имеет формат:

ip1:as1 ip2:as2

разделитель между маршрутизаторами - пробел.

Нажимаем назад, применяем настройки:

zebra и bgpd должны перезапуститься без ошибок:

 

Настройка роутера (самого роутера, не редуктора)

Ещё раз - самого роутера, не редуктора!

Конфигурация роутеров может отличаться. В качестве примера - Linux с Quagga.

bgpd.conf

Здесь:

  • router bgp 65002 - номер AS маршрутизатора.
  • bgp router-id 10.0.0.1 - его IP, с которым он доступен Carbon Reductor'у
  • 10.0.0.2 - IP адрес Carbon Reductor
  • 192.168.255.255 - вообще любой левый IP адрес
hostname border
password password
log file /var/log/quagga/bgpd.log
!
router bgp 65002
 bgp router-id 10.0.0.1
 redistribute static route-map BLACKHOLE
 neighbor 10.0.0.2 remote-as 65001
 neighbor 10.0.0.2 description ROUTER
 neighbor 10.0.0.2 ebgp-multihop 8
 neighbor 10.0.0.2 update-source 10.0.0.1
 neighbor 10.0.0.2 soft-reconfiguration inbound
!
ip as-path access-list 1 deny .*
!
route-map BLACKHOLE permit 10
 description blackhole
 match ip address prefix-list BLACKHOLE
 set ip next-hop 192.168.255.255
 set local-preference 10
 set community 65002:666 additive
!
line vty
!

zebra.conf

hostname border

Подводные камни и как их обходить

20.09.2017. Настройка BGP RTBH приводит к появлению Null-маршрутов до запрещённых IP на самом редукторе. Это приводит к тому, что пришедшие в зеркало трафика пакеты, идущие на эти IP адреса не анализируются. В принципе в полностью рабочей схеме это не страшно - пакеты всё равно будут DROP'нуты на стороне бордера. Тем не менее, если что-то пойдёт не так (разорвётся соединение с роутером, не проверили настройки итд) то бордер пакеты отбрасывать не будет, а редуктор не будет их анализировать и в итоге получим пропуск.

Сейчас мы ищем решение, которое позволит обойти эту проблему. Временным решением может быть разворачивание отдельного редуктора на виртуальной машине (мы дадим бесплатную лицензию), которая занимается тем, что скачивает и обрабатывает списки, к трафику не имеет никакого отношения, а основное её предназначение - это контейнер BGP Blackhole. Таким образом получаем двойную фильтрацию и повышение надёжности: роутер дропает пакеты, а основной редуктор посылает ресеты на все запрещённые IP адреса (в итоге пользователю не надо будет дожидаться таймаута установки соединения). Можно это развернуть не на виртуальной машине, а не резервном сервере с Carbon Reductor, который также занимается обработкой того же зеркала трафика.

Введите метки, чтобы добавить к этой странице:
Please wait 
Ищите метку? просто начните печатать.