Одноадресный RPF на грани

10

Предполагается, что одноадресный RPF предотвращает использование адресов источников, которые отличаются от тех, которые должны быть разрешены. Читая документацию Cisco для URPF, я заметил, что есть варианты, позволяющие использовать его на интерфейсе восходящей линии, пропуская его по таблице маршрутизации.

Мой вопрос: если он идет по маршруту по умолчанию, не разрешены ли все исходные адреса? Какую пользу принесет URPF в этот момент?

Я уверен, что что-то упустил, поэтому мне бы очень хотелось, чтобы точка в правильном направлении.

Codey
источник

Ответы:

15

Одноадресная переадресация по обратному пути (RPF) работает в трех разных режимах и потенциально может помочь уменьшить вектор атаки маршрутизатора, особенно с поддельных IP-адресов.

Строгий режим

(config-if)#ip verify unicast source reachable-via rx

В строгом режиме маршрутизатор проверит и проверит исходный IP-адрес входящего пакета по его таблице пересылочной информационной базы (FIB) на предмет соответствия маршрута. Если маршрут к этому IP-адресу источника доступен через интерфейс, на котором он был получен , пакет будет принят. По умолчанию маршрут по умолчанию не рассматривается в строгом режиме (как настроено выше).

Параметры строгого режима:

После настройки строгого режима Unicast RPF на данном интерфейсе маршрутизатор больше не может пропинговать себя на этом интерфейсе:

#sh ip int bri | ex unas|Int
FastEthernet0/0            11.0.11.1

#ping 11.0.11.1                                    
.....
Success rate is 0 percent (0/5)

Проверка URPF отброшенных пакетов:

#show ip int fa0/0 | i ^  [1-9]+ verification drops
     5 verification drops
#show ip traffic | i unicast
     0 no route, 5 unicast RPF, 0 forced drop

Это поведение можно изменить, добавив allow-self-pingсинтаксис:

(config-if)#ip verify unicast source reachable-via rx allow-self-ping

Кроме того, как уже упоминалось в вашем вопросе, строгий режим позволяет проверять исходные IP-адреса входящего пакета на маршруте по умолчанию. Это включается синтаксисом allow-default:

В строгом режиме добавление синтаксиса allow-defaultсамо по себе предотвратит получение только от IP-адреса источника входящего пакета, у которого маршрут через другой интерфейс отличается от полученного. Это при условии, что на маршрутизаторе не настроены списки доступа или нулевые маршруты. Все маршрутизируемые исходные адреса, которые доступны через интерфейс, который они получили, будут совпадать с конкретными маршрутами или маршрутом по умолчанию.

Однако, если вы должны использовать нулевые маршруты, сначала будет оценен наиболее конкретный маршрут, прежде чем проверка URPF попадет на маршрут по умолчанию, и он будет действовать как черный список (списки) для известных вредоносных диапазонов IP-адресов.

Пример - весь трафик, полученный из 3.0.0.0/8, будет отброшен проверкой URPF:

(config-if)#ip verify unicast source reachable-via rx allow-default
(config)#ip route 3.0.0.0 255.0.0.0 null 0

Bad-Source-RTR#ping 11.0.11.1 so l1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 11.0.11.1, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3 
.....
Success rate is 0 percent (0/5)

Кроме того, вы можете указать Access-Control List (ACL) вместо добавления allow-defaultсинтаксиса для создания структурированного списка разрешенных и запрещенных адресов. Адреса, которые доступны из интерфейса, на котором они были получены, и сопоставляются в определенном ACL, либо удаляются, либо разрешаются соответствующим образом.

!
access-list 23 permit 3.0.0.0 0.255.255.255
access-list 23 deny   4.0.0.0 0.255.255.255 log
access-list 23 permit any
!
(config)#int fa0/0                                 
(config-if)#ip verify unicast source reachable-via rx 23

Наконец, вы можете указать ACL с allow-defaultсинтаксисом, но это не будет иметь никакого эффекта. Пакеты не будут проверяться по спискам ACL, указанным в allow-defaultопции.

#ip verify unicast source reachable-via rx allow-default ? 
  <1-199>          A standard IP access list number
  <1300-2699>      A standard IP expanded access list number

Свободный режим

R1(config-if)#ip verify unicast source reachable-via any

В свободном режиме маршрутизатор проверит исходный IP-адрес входящего пакета и проверит его по таблице FIB на предмет соответствия маршрута. Если маршрут к этому IP-адресу источника доступен, пакет может быть получен независимо от интерфейса, на котором он был получен. По умолчанию маршрут по умолчанию не рассматривается в свободном режиме (как настроено выше).

Свободный режим и строгий режим имеют похожие параметры конфигурации; Основное различие заключается в используемом синтаксисе ( anyпротив rx) и в том, доступен ли исходный IP-адрес входящего пакета через интерфейс, на котором он был получен.

(config-if)#ip verify unicast source reachable-via any ?
  <1-199>          A standard IP access list number
  <1300-2699>      A standard IP expanded access list number
  allow-default    Allow default route to match when checking source address
  allow-self-ping  Allow router to ping itself (opens vulnerability in
                   verification)

Режим VRF

Режим VRF может использовать либо свободный, либо строгий режим в данном VRF и будет оценивать исходный IP-адрес входящего пакета по таблице VRF, настроенной для соседа eBGP.


Ссылки:
Техническое описание Cisco URPF. Руководство по настройке URPF для
переадресации одноадресного обратного пути.

один раз
источник
А как насчет практического применения? Есть ли смысл в том, чтобы поместить это в свой канал связи?
Коди
3
@ codey Я бы не запускал uRPF на линии вверх, только на интерфейсах, обращенных к клиенту. one.time, +1, хорошая работа, твердые ответы, я хотел бы отметить, что статический маршрут к null0 на некоторых платформах, не входящих в cisco, не приведет к сбою в режиме «Свободный». Может быть, вместо «ответил» вы должны использовать «получать», то есть пакеты с ошибками RPF не будут получены. Также, возможно, «против таблицы маршрутизации» (RIB) следует изменить на «против таблицы пересылки» (FIB). Поскольку существует разновидность uRPF, называемая «выполнимо свободная / строгая», которая проверяет RIB (Cisco не поддерживает его, они проверяют только FIB).
2013 г.
@ytti Когда я смотрел на документы Cisco, он просто говорил против таблицы маршрутизации. Я не говорю, что это правильно, но странно, что они сказали бы это, если бы это был просто ФИБ.
Коди
Представьте себе случай, когда клиент объявил префикс BGP 192.0.2.0/24, у вас также есть статический маршрут для указания на ядро. Если пользовательский интерфейс имеет uRPF / strict, вы будете отбрасывать пакеты от клиента с исходным адресом 192.0.2.42, даже если в RIB (таблица маршрутизации) эта запись существует, она просто не / best / entry, и, следовательно, ее нет в FIB. Однако, если вы запустите пакет 'uRPF / строгий выполнимый', он не будет отброшен (JunOS поддерживает выполнимый, поэтому его документы предоставят дополнительную информацию).
ytti