Центр Диагностики & База Системных Ошибок

Решения для Windows Server, Active Directory, 1С, СУБД, Linux, Cisco, MikroTik и IP-телефонии.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, баз данных и сетевого оборудования. Перед выполнением действий обязательно создайте резервную копию. При отсутствии необходимой квалификации обратитесь к ИТ-специалистам.

Защита от спуфинга с помощью Unicast RPF (Strict и Loose) на Cisco

Обновлено: 25.08.2026  ·  Официальная база знаний
  • Сеть используется в качестве источника или промежуточного узла для DDoS-атак с поддельными адресами отправителя (IP Spoofing).
  • Входящий спуфинговый трафик не блокируется стандартными списками ACL.
  • Легитимный асимметричный трафик отбрасывается маршрутизатором после включения защиты uRPF.
  • Рост счетчиков отброшенных пакетов в выводе команды show ip interface.

1. Архитектурные режимы работы Unicast RPF

uRPF проверяет IP-адрес отправителя (Source IP) каждого входящего пакета по таблице маршрутизации CEF (FIB):

  • Strict Mode (Строгий режим): маршрут к Source IP должен существовать в FIB, и лучший путь к нему должен указывать строго на тот же самый интерфейс, с которого пришел пакет. Применяется на интерфейсах доступа и симметричных аплинках.
  • Loose Mode (Свободный режим): маршрут к Source IP должен просто существовать в FIB (через любой интерфейс, кроме Null0). Идеально для многодомных сетей (Multihomed BGP) с асимметричной маршрутизацией.

2. Настройка uRPF в строгом режиме (Strict Mode)

Рекомендуется для клиентских интерфейсов, Single-Homed подключений и агрегации доступа:

interface GigabitEthernet0/0/1
 description Client_Access_VLAN
 ip verify unicast source reachable-via rx

3. Настройка uRPF в свободном режиме (Loose Mode)

Рекомендуется для аплинков с несколькими провайдерами (Dual-homed ISP):

interface TenGigabitEthernet0/1/0
 description Multihomed_ISP_Uplink
 ip verify unicast source reachable-via any

4. Настройка uRPF с исключением через ACL (Exception List)

Если часть специфичного трафика должна проходить проверку даже при отсутствии маршрута в FIB:

# Разрешить доверенную подсеть мониторинга в обход uRPF
ip access-list standard ACL_URPF_EXCEPTIONS
 permit 198.51.100.0 0.0.0.255

interface GigabitEthernet0/0/1
 ip verify unicast source reachable-via rx ACL_URPF_EXCEPTIONS

5. Диагностика и верификация отброшенных пакетов

# Просмотр глобальной статистики uRPF
show ip traffic | include RPF

# Детальная статистика дропов по конкретному интерфейсу
show ip interface GigabitEthernet0/0/1 | include verify

# Проверка наличия маршрута к адресу в CEF
show ip cef 203.0.113.50
Практический опыт инженера: Никогда не используйте опцию 'allow-default' в связке с 'reachable-via any' (Loose mode) на пограничных маршрутизаторах интернета — это полностью обесценит защиту uRPF, так как любой случайный IP-адрес будет считаться валидным из-за наличия дефолтного маршрута 0.0.0.0/0.

Частые вопросы (FAQ)

Почему включение uRPF в режиме Strict ломает трафик при наличии двух интернет-провайдеров?

В многодомных сетях (BGP Multihoming) часто возникает асимметричная маршрутизация: пакет уходит через ISP-1, а ответ возвращается через ISP-2. Strict uRPF на интерфейсе ISP-2 сбросит ответ, так как маршрут к источнику в FIB указывает на ISP-1. Для таких сценариев следует использовать Loose Mode (reachable-via any).

Защищает ли uRPF Loose от атак с использованием Bogon IP (серых сетей)?

Да, если на пограничном маршрутизаторе настроены маршруты в Null0 для диапазонов RFC 1918, RFC 5735 и нераспределенных блоков, Loose uRPF мгновенно отбросит такие пакеты, поскольку в CEF они указывают на интерфейс Null0.

Работает ли uRPF без включенного CEF?

Нет. Механизм uRPF фундаментально опирается на быстрый поиск по аппаратным таблицам Cisco Express Forwarding. При отключенном CEF команда активации uRPF будет отклонена.

Что означает опция 'allow-default' в настройке uRPF?

По умолчанию uRPF игнорирует шлюз по умолчанию (0.0.0.0/0) при проверке существования маршрута к источнику. Добавление флага 'allow-default' разрешает валидацию через Default Gateway.