uRPF (антиспуфинг защита data plane)

Добрый день уважаемое сообщество.

В рамках подготовки к сдаче экзамена SECURE (642-637) хотелось бы поговорить о технологии uRPF (Unicast Reverse Path Forwarding).

Эта технология является средством антиспуфинга (antispoofing) на третьем уровне модели OSI, и используется как одна из технологий при защите data plane. Точнее, она позволяет бороться с подделкой IP адреса отправителя в пакетах, которые приходят на интерфейсы маршрутизатора. Ведь злоумышленник может использовать в отправляемых пакетах «похищенный с другой сети» IP адрес, либо некорректный IP адрес из отведённых для специфического использования диапазонов, например 127.0.0.0/8.

При внедрении комплексной антиспуфинг защиты рекомендуется использовать:

• IP Source Guard — эта технология разрешает отправку пакетов только с того IP адреса который был выдан устройству подключённому к порту коммутатора по DHCP.
• Также рекомендуется отключить на устройствах возможность маршрутизации от источника, с помощью команды «no ip source-route»
• На уровнях доступа и распределения использовать ACL которые будут фильтровать spoofed пакеты.
• Технологию uRPF рекомендуется использовать на уровнях доступа и распределения.

Теперь более подробно о технологии uRPF. Включив uRPF на интерфейсе, она будет автоматически сверять IP адрес отправителя пакета с данными из CEF FIB. Из этого следует, что использование CEF обязательно. При этом мы полагаемся, что RIB и соответственно FIB содержат только корректную маршрутную информацию.

Существует два типа uRPF: loose и strict.

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

Пример настройки, общая информация о топологии:

Сначала необходимо убедится, что CEF включен, либо включить его с помощью команды «ip cef».

Первичная конфигурация:

«ip verify unicast source reachable-via rx allow-default allow-self-ping», основная часть команды «ip verify unicast source reachable-via rx» включает strict uRPF на маршрутизируемом порте, то есть теперь пакет пришедший на Fa0/0 интерфейс будет проверен, если сеть которой принадлежит IP адрес отправителя действительно есть в FIB и она действительно доступна через тот интерфейс на который пришел данный пакет, то он будет перенаправлен, в противном случае будет удален. Аргумент «allow-default» уточняет, что через этот интерфейс доступен маршрут по умолчанию. Значит, входящие в этот интерфейс пакеты могут иметь любой IP адрес отправителя кроме тех сетей, которые по FIB доступны через другие интерфейсы. Аргумент «allow-self-ping» разрешает с этого же маршрутизатора пинговать этот интерфейс. И последним аргументом может быть номер ACL которая правилами “permit” позволит сделать исключение для каких-то адресов и/или логировать заблокированные пакеты.
Команда «ip verify unicast source reachable-via any» включает на интерфейса uRPF loose режим. В этом режиме будет пропущен любой пакет, информация о сети отправителя которого есть в FIB. В данном режиме аргумент «allow-default» не используется, так как он разрешит пересылку любых пакетов через интерфейс.

Пример логирования блокированных технологией uRPF пакетов с помощью ACL:

uRPF и асимметрическая маршрутизация

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

Пример настройки uRPF уведомлений:

Уведомления uRPF могут быть отосланы по протоколу snmp. «ip verify drop-rate compute window seconds» определяет период в течении которого вычисляется uRPF дроп рейт, тоесть только по истечению этого периода времени нам будет известен дроп рейт.
«ip verify drop-rate compute interval seconds» определяет интервал времени между процессами вычисления uRPF дроп рейта.
«ip verify drop-rate notify hold-down seconds » команда определяет минимальное время между отправкой uRPF дроп рейт уведомлений.
«ip verify unicast notification threshold packets-per-second » определяет пороговое значение пакетов в секунду которое определяет когда отсылать уведомление о превышении дроп рейта.
«snmp trap ip verify drop-rate» -последняя команда принуждает маршрутизатору отсылать уведомления когда превышен дроп рейт по протоколу snmp а не только в подсистему syslog.

Если хочется посмотреть статистику отброшенных пакетов на интерфейсе, можно использовать команду «show ip interface iface_name»:

Также хочется подчеркнуть, что ISR маршрутизаторы поддерживают как uRPF так и uRPF notifications начиная с версии IOS 12.4(20)T.

Автор: taaraora