В этом посте я хотел собрать воедино всю информацию по системе сертификации RPKI, но тема оказалась достаточно обширной, кроме того наткнулся на несколько статей в русскоязычной части интернета в которых подробно описывается принцип работы RPKI (ссылки на эти статьи в конце поста). С примерами настройки и применения RPKI на живом железе все хуже. Поэтому решил сделать статью в стиле HOW-TO. Информация, представленная в статье, может помочь провайдерам автоматизировать процесс проверки получаемых префиксов от клиентов и исключить ошибки в фильтрах. Всех кому интересна защита динамической маршрутизации средствelfkами RPKI и настройка RPKI кэш-сервера на Linux прошу под кат.
Теория
Для начала несколько терминов:
RPKI (Resource Public Key Infrastructure) — иерархическая система открытых ключей (PKI) разработанная для обеспечения безопасности глобальной маршрутизации в сети Интернет. RPKI использует архитектуру сертификатов X.509 PKI (RFC5280) с дополнительным расширением позволяющим использовать IP адреса и номера AS (RFC3779). Структура сертификата позволяет определить порядок распределения интернет-ресурсов (IP адреса и номера автономных систем). Интернет-ресурсы изначально распространяются IANA через Региональные Интернет-Регистратуры (RIR), которые в свою очередь распределяют их Локальным Интернет-Регистратурам (LIR), а те в свою очередь производят распределение интернет-ресурсов между своими клиентами. Таким же образом строится и система RPKI. Каждое последующее распределение интернет-ресурсов сопровождается созданием сертификата, который подписан ключом «родителя», то есть той организации, которая изначально предоставила эти интернет-ресурсы. Совокупность таких сертификатов привязанных к каждому интернет-ресурсу составляют базу данных, по которой можно проверять достоверность информации. Такие базы данных расположены на публичных RPKI репозиториях у всех RIR.
ROA (Route Origin Authorisation) — разрешение на создание маршрута. В соответствии со спецификацией ROA содержит номер авторизованной AS, список IP префиксов, которые эта AS имеет разрешение анонсировать и сертификат, описывающий соответствующие информационные-ресурсы. Подробнее прочитать про систему сертификации можно в статье «Сертификация Адресных Интернет-Ресурсов» ссылку на которую вы найдете в конце поста.
Хотя проверка префиксов может осуществляться каждым маршрутизатором по отдельности по прямой сессии RPKI, такой подход не рекомендован, так как требует большой траты ресурсов маршрутизатора (ресурсоемкие криптографические операции при получении данных RPKI). Для использования этих данных лучшей практикой считается поддержка своего локального кэш-сервера RPKI, который будет синхронизировать свою базу с публичными RPKI репозиториями. Полученные данные обрабатываются и проверяются на кэш-сервере. Далее кэш-сервер генерирует prefix-to-AS записи. Сформированная база данных загружается на маршрутизатор через защищенное TCP соединение по протоколу RPKI-RTR. Таким образом маршрутизатору не требуется обрабатывать криптографическую информацию и оперировать данными RPKI. В последствии маршрутизатор использует готовую таблицу для проверки префиксов.
На маршрутизаторе база данных представлена в формате RV (route validation) записей. RV база данных содержит коллекцию RV записей, доступных для скачивания маршрутизатором с кэш-сервера RPKI. RV запись состоит из: префикса, максимальной длины префикса и AS источника. Эта запись используется для проверки каждого маршрута с которым совпадает поле префикс RV записи. Также выполняется проверка максимальной длинны указанной в RV записи и соответствие номера AS. RV запись является упрощенной формой ROA записи. Так как сами ROA записи не используются для проверки маршрутов, кэш-сервер экспортирует маршрутизатору уже сформированные записи RV.
Этапы проверки маршрута по RV записи:
- Максимальная длина префикса в RV записе должна быть больше или равна длине маски маршрута для которого создана запись.
- Первая (справа) AS префикса представленная в AS_PATH должна совпадать с номером AS в записи RV.
Проверка всех префиксов выполняется маршрутизатором независимо от состояния локальной базы данных RV записей. Если в момент проверки база пуста, на все префиксы будет установлен статус unknown, так как информация об этом префиксе в базе отсутствует. При каждом обновлении базы данных маршрутизатор сбрасывает таймер на кэш-сервере таким образом устанавливая точку отсчета изменений в базе и сохраняет у себя в памяти версию базы данных. При повторном подключении маршрутизатор отправляет версию базы данных, которая у него в памяти, на кэш-сервер и если версия не актуальна произойдет обновление.
Префикс полученный по eBGP на основании проверки может принять три состояния:
- Valid — указывает, что префикс и номер AS находятся в базе данных
- Invalid — указывает что префикс был найден в базе, но номер AS источника префикса не совпадает с номером AS указанным в базе, либо длина префикса в сообщении BGP превышает максимально допустимую длину указанную в базе данных
- Unknown — указывает, что префикс не найден в базе данных и не входит ни в одну сеть в базе данных
Практика
Сначала нам необходимо настроить RPKI кэш-сервер, с которым будет общаться наш маршрутизатор. Для этих целей RIPE NCC разработали свое приложение RPKI validator запускаемое на UNIX-like ОС и состоящее из двух частей:
- Веб-интерфейс для работы с базой данных RPKI
- Демон для работы с маршрутизатором
Для его установки требуется Java 7. Все дальнейшие действия по установке RPKI validator будут производиться на Ubuntu 12.04.
Устанавливаем Java 7:
sudo apt-get remove openjdk*
sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update
sudo apt-get install oracle-java7-installer
export JAVA_HOME=/usr/lib/jvm/java-7-oracle
# Добавляем переменную в bashrc
echo "export JAVA_HOME=/usr/lib/jvm/java-7-oracle" >> /etc/bash.bashrc
Устанавливаем сам validator со страницы RIPE:
cd /tmp
wget https://certification.ripe.net/content/static/validator/rpki-validator-app-2.15-dist.tar.gz
tar -xzvf /tmp/rpki-validator-app-2.15-dist.tar.gz -O <каталог_установки>
Запускаем validator:
cd <каталог_установки>
./rpki-validator.sh start
В ответ увидим:
[ info ] Starting rpki-validator...
[ info ] writing logs under log directory
[ info ] Web user interface is available on port 8080
[ info ] Routers can connect on port 8282
[ info ] Writing PID 15860 to validator.pid
Как видно из сообщения демон validator занимает два порта:
- 8080 — веб-интерфейс управления RPKI validator
- 8282 — интерфейс для подключения роутера
Проверить работу RPKI validator можно с помощью curl используя API:
curl http://localhost:8080/api/v1/validity/AS174/89.207.56.0/21
где AS174 — номер AS, 89.207.56.0/21 — префикс AS требующий проверки. В ответ получим:
{
"validated_route":{
"route":{
"origin_asn":"AS174",
"prefix":"89.207.56.0/21"
},
"validity":{
"state":"Valid",
"description":"At least one VRP Matches the Route Prefix",
"VRPs":{
"matched":[{
"asn":"AS174",
"prefix":"89.207.56.0/21",
"max_length":21
}],
"unmatched_as":[{
"asn":"AS3257",
"prefix":"89.207.56.0/21",
"max_length":21
},{
"asn":"AS41073",
"prefix":"89.207.56.0/21",
"max_length":21
}],
"unmatched_length":[]
}
}
}
}
Зайдя по адресу <ip_адрес_сервера>:8080 в браузере, увидим интерфейс управления.
На вкладке «Trust Anchors» список всех root RPKI серверов.
На вкладке «ROAs» список всех префиксов с установленными RPKI подписями (все известные ROA). Интерфейс позволяет производить поиск по любому параметру, например по номеру AS (AS174 — провайдер Cogent).
На вкладке «BGP Preview» список всех префиксов как с ROA так и без. Эта вкладка удобна для проверки всех префиксов любой AS.
Также интерфейс предоставляет API для удаленного получения данных.
Далее настраиваем сам маршрутизатор Juniper для работы с RPKI кэш-сервером.
Настраиваем сессию с RPKI кэш-сервером для проверки префиксов. В примере RPKI validator запущен на сервере 192.168.0.10:8282 а маршрутизатор обращается к нему с адреса 192.168.0.1:
{master}[edit]
user@router# show | compare
[edit routing-options]
+ validation {
+ group RPKI-validator {
+ session 192.168.0.10 {
+ refresh-time 120;
+ hold-time 180;
+ port 8282;
+ local-address 192.168.0.1;
+ }
+ }
+ }
Если у Вас на роутере Juniper используется защита RE, то также необходимо добавить правила разрешающие трафик с RPKI кэш-сервера:
{master}[edit]
user@router# show | compare | display omit
[edit policy-options]
+ prefix-list RPKI-servers {
+ apply-path "routing-options validation group <*> session <*>";
+ }
+ prefix-list RPKI-locals {
+ apply-path "routing-options validation group <*> session <*> local-address <*>";
+ }
[edit firewall family inet]
+ filter accept-rpki {
+ apply-flags omit;
+ interface-specific;
+ term accept-rpki {
+ from {
+ source-prefix-list {
+ RPKI-servers;
+ }
+ destination-prefix-list {
+ RPKI-locals;
+ }
+ protocol tcp;
+ }
+ then {
+ count accept-rpki;
+ accept;
+ }
+ }
+ }
[edit interfaces lo0 unit 0 family inet filter]
- input-list [ accept-bgp accept-common-services discard-all ];
+ input-list [ accept-rpki accept-bgp accept-common-services discard-all ];
После применения конфигурации сессия будет установлена:
{master}[edit]
user@router# run show validation session detail
Session 192.168.0.10, State: up, Session index: 2
Group: RPKI-validator, Preference: 100
Local IPv4 address: 192.168.0.1, Port: 8282
Refresh time: 120s
Hold time: 180s
Record Life time: 3600s
Serial (Full Update): 16
Serial (Incremental Update): 16
Session flaps: 0
Session uptime: 00:00:16
Last PDU received: 00:00:14
IPv4 prefix count: 7061
IPv6 prefix count: 1109
RV база данных роутера обновится:
user@router> show validation database | last 20
2a04:71c0::/29-32 200086 192.168.0.10 valid
2a04:81c0::/29-48 48526 192.168.0.10 valid
2a04:8400::/32-64 41887 192.168.0.10 valid
2a04:8d40::/29-32 50304 192.168.0.10 valid
2a04:8f00::/29-29 49531 192.168.0.10 valid
2a04:92c0::/29-29 62240 192.168.0.10 valid
2a04:93c0::/32-48 60251 192.168.0.10 valid
2a04:9fc0::/29-32 24904 192.168.0.10 valid
2a04:a5c0::/29-29 199789 192.168.0.10 valid
2c0f:f668::/32-32 37519 192.168.0.10 valid
2c0f:f970::/32-32 37596 192.168.0.10 valid
2c0f:f9b0::/32-32 37390 192.168.0.10 valid
2c0f:f9b8:a::/48-48 37674 192.168.0.10 valid
2c0f:f9b8:f::/48-48 16265 192.168.0.10 valid
2c0f:faf8::/32-32 37403 192.168.0.10 valid
2c0f:fbf0::/28-28 32653 192.168.0.10 valid
2c0f:fc00::/27-27 3741 192.168.0.10 valid
2c0f:feb0::/32-32 37100 192.168.0.10 valid
IPv4 records: 7061
IPv6 records: 1109
Установленную сессию можно также увидеть в веб-интерфейсе управления RPKI validator.
Настраиваем policy-statement для проверки префиксов на маршрутизаторе. Для построения гибких фильтров префиксов Juniper рекомендует создавать специальные BGP community:
- origin-validation-state-valid
- origin-validation-state-invalid
- origin-validation-state-unknown
которые позволяют маршрутизатору помечать префиксы по результатам проверки. Этот механизм удобно использовать на пограничных маршрутизаторах, которые занимаются разбором префиксов полученных по eBGP. Например, такой пограничный маршрутизатор может помечать все префиксы такими community, а далее все маршрутизаторы AS подключенные к нему по iBGP, без дополнительной проверки через RPKI кэш-сервер, будут строить свои таблицы маршрутизации, доверяя этим community. Этот метод позволяет настраивать RPKI-RTR сессию только на некоторых маршрутизаторах и тем самым снижать нагрузку на RPKI кэш-сервер. Также policy будет выставлять различные local-preference для префиксов по результатам проверки. Это позволит построить таблицу маршрутизации с учетом рекомендаций IETF, выставляя наименьший приоритет тем префиксам которые не прошли проверку.
Создаем policy:
{master}[edit]
user@router# show | compare
[edit policy-options]
+ policy-statement RPKI-validation {
+ term valid {
+ from {
+ protocol bgp;
+ validation-database valid;
+ }
+ then {
+ local-preference 110;
+ validation-state valid;
+ community add origin-validation-state-valid;
+ next policy;
+ }
+ }
+ term invalid {
+ from {
+ protocol bgp;
+ validation-database invalid;
+ }
+ then {
+ local-preference 90;
+ validation-state invalid;
+ community add origin-validation-state-invalid;
+ next policy;
+ }
+ }
+ term unknown {
+ from protocol bgp;
+ then {
+ local-preference 100;
+ validation-state unknown;
+ community add origin-validation-state-unknown;
+ next policy;
+ }
+ }
+ }
[edit policy-options]
+ community origin-validation-state-invalid members 0x43:100:2;
+ community origin-validation-state-unknown members 0x43:100:1;
+ community origin-validation-state-valid members 0x43:100:0;
В конфигурации community используется номер AS равный 100, его необходимо заменить на номер Вашей AS.
Просмотрим таблицу маршрутизации роутера:
{master}
user@router> show route protocol bgp validation-state valid | last 12
2c0f:faf8::/32 *[BGP/170] 2d 01:27:30, localpref 110
AS path: 174 30844 37105 37403 37403 I, validation-state: valid
> to 2001:978:2:b4::1:1 via ae0.12
2c0f:fbf0::/28 *[BGP/170] 2d 01:27:30, localpref 110
AS path: 174 6939 3741 32653 I, validation-state: valid
> to 2001:978:2:b4::1:1 via ae0.12
2c0f:fc00::/27 *[BGP/170] 2d 01:27:30, localpref 110
AS path: 174 3356 3741 I, validation-state: valid
> to 2001:978:2:b4::1:1 via ae0.12
2c0f:feb0::/32 *[BGP/170] 2d 01:27:30, localpref 110
AS path: 174 37100 ?, validation-state: valid
> to 2001:978:2:b4::1:1 via ae0.12
{master}
user@router> show route protocol bgp validation-state invalid | last 12
2a03:f85:1::/48 *[BGP/170] 2d 01:27:36, localpref 90
AS path: 174 34305 I, validation-state: invalid
> to 2001:978:2:b4::1:1 via ae0.12
2a03:f86:4::/48 *[BGP/170] 2d 01:27:36, localpref 90
AS path: 174 174 54020 59692 I, validation-state: invalid
> to 2001:978:2:b4::1:1 via ae0.12
2a03:f87:ffff::/48 *[BGP/170] 2d 01:27:36, localpref 90
AS path: 174 9002 57169 I, validation-state: invalid
> to 2001:978:2:b4::1:1 via ae0.12
2a03:bb40::/32 *[BGP/170] 2d 01:27:36, localpref 90
AS path: 174 174 I, validation-state: invalid
> to 2001:978:2:b4::1:1 via ae0.12
{master}
user@router> show route protocol bgp validation-state unknown | last 12
2c0f:ff40::/26 *[BGP/170] 2d 01:29:56, localpref 100
AS path: 174 6939 10474 I, validation-state: unknown
> to 2001:978:2:b4::1:1 via ae0.12
2c0f:ff90::/32 *[BGP/170] 2d 01:29:56, localpref 100
AS path: 174 174 6453 15808 I, validation-state: unknown
> to 2001:978:2:b4::1:1 via ae0.12
2c0f:ffa0::/32 *[BGP/170] 01:39:27, localpref 100
AS path: 174 9498 37273 I, validation-state: unknown
> to 2001:978:2:b4::1:1 via ae0.12
2c0f:ffd8::/32 *[BGP/170] 2d 01:29:56, localpref 100
AS path: 174 174 33762 I, validation-state: unknown
> to 2001:978:2:b4::1:1 via ae0.12
По результатам выполнения этих команд видно, что в таблице маршрутизации приоритет отдается маршрутам valid.
Реальность
К сожалению, в настоящий момент многие провайдеры избегают схемы с использованием RPKI, так как только малая часть префиксов из мировой таблицы маршрутизации full-view имеют сертификаты. Кроме того, далеко не все клиенты имеют желание возможность настроить ROA записи для своих сетей. Провайдеры чаще всего используют, зарекомендовавшую себя, схему автоматического обновления фильтров префиксов на основании данных whois, запуская некий скрипт раз-два в сутки. Такая схема предполагает полное доверие базе whois, которая в свою очередь актуализируется самими клиентами и может отличаться у различных RIR. Мелкие региональные провайдеры могут вообще не заботиться о фильтрах полагаясь на авось фильтры пира и таким образом быть источниками атак на "Притягивание трафика". Ситуация также усугубляется необходимостью дополнительных затрат на установку и поддержку RPKI кэш-сервера. Вероятно, до достижения значительной критической массы, эта технология так и останется в «бумажном» виде, ведь затраты на внедрение, по мнению многих, не окупаются результатом.
Ссылки
Автор: velizarx
