Unicast RPF на межі


10

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

Моє запитання: якби маршрут пройшов за замовчуванням, чи не дозволятимуться всі адреси джерел? Яку користь отримав би УРПФ в цей момент?

Я впевнений, що мені чогось не вистачає, тому мені дуже сподобається точка в правильному напрямку.

Відповіді:


15

Функція "Unicast Reverse Path Forwarding" (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)

Крім того, ви можете вказати список контролю доступу (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-адресу вихідного пакета для IP-таблиці, налаштованої для сусіда eBGP.


Посилання:
Біла книга Cisco URPF
Розуміння посібника по конфігурації URPF для переадресації зворотного шляху Unicast


А як щодо практичного застосування? Це насправді навіть має сенс / різниця, щоб розмістити його на своїй висхідній лінії зв'язку?
кодеї

3
@codey Я б не запускав uRPF по висхідній лінії зв'язку, лише на інтерфейсах, що стоять перед клієнтом. one.time, +1, хороша робота, ґрунтовні відповіді, я хотів би зазначити, що статичний шлях до null0 на деяких платформах, які не є cisco, не призведе до виходу з ладу режиму "вільний". Можливо, замість "відповів", ви повинні використовувати "Отримати", тобто пакети з помилкою RPF не будуть отримані. Також можливо "проти таблиці маршрутизації" (RIB) слід змінити на "проти таблиці переадресації" (FIB). Оскільки є аромат uRPF, який називається "можливим неприйнятним / суворим", який перевіряє RIB (Cisco не підтримує його, вони перевіряють лише FIB).
ytti

@ytti Коли я подивився на документи Cisco, він просто сказав проти таблиці маршрутизації. Я не кажу, що це правильно, але дивно, що вони сказали б, щоби це був лише ПІБ.
кодеї

Уявіть собі випадок, коли клієнт оголосив префікс BGP 192.0.2.0/24, у вас також є статичний маршрут для цього вказування на ядро. Якщо інтерфейс клієнта має uRPF / строгий, ви скинете пакети з клієнтом, що має адресу джерела 192.0.2.42, навіть якщо в RIB (таблиця маршрутизації) ця запис існує, це просто не / найкраще / запис, а отже, це не у FIB. Однак якщо ви запустили пакет "uRPF / strict feasible", пакет не буде скинутий (JunOS підтримує можливі, тому його документи дадуть додаткову інформацію).
ytti
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.