Со временем обрывки знаний и умений становится все труднее удержать в голове. Они расползаются по уголкам памяти заполняя все свободное место. Извлекать необходимое на свет становится все сложнее. Этот блог - рабочая записная книжка.

Tuesday, November 6, 2007

Unicast Reverse Path Forwarding

Зачастую можно увидеть как сетевые администраторы используют традиционные списки доступа для предотвращения подделки адресов (spoofing).
Видимо сказывается привычка выработаная с годами. :)

Тем не менее многие знают или слышали о такой штуке как Unicast Reverse Path Forwarding.

Как это работает

Для работы Unicast Reverse Path Forwarding должен быть включен cef.
При получении пакета uRPF проверяет соответствует ли адрес источника и интерфейс через который получен пакет значениям в таблице FIB.
По сути выполняется обратный резолвинг адреса источника используя базу (reverse lookup) FIB

Решение конечно не универсальное. Его нельзя применять в случае ассиметричного рутинга (вход по одному интерфейсу, а выход по другому).

Подробнее можно почитать в RFC 2267.

Настройка

Cisco IOS

В конфигурацию интерфейса необходимо добавить строку

routerA(conf-if)# ip verify unicast reverse-path

PIX/ASA
В режиме глобальной конфигурации необходимо выполнить команду

myasa# ip verify reverse-path interface e0



Проверка состояния rpf

В случае Cisco IOS проверить можно поискав строку относящуюся с rpf в выводе команды:

RouterA# show cef interface FastEthernet 0/0

IP unicast RPF check is enabled

В случае PIX/ASA всё выглядит похоже:
myasa# show ip verify statistics
interface outside: 21 unicast rpf drops
interface inside: 2738 unicast rpf drops
interface vpn: 0 unicast rpf drops

3 comments:

Anonymous said...

В случае с асой я вот не понимаю на каком интерфейсе нужно прописать этот самый реверс пас .. на инсайде или аутсайде? . . тем более если она(аса) выполняет роль шлюза, т.е. роутера нет :)

pablo said...

Зависит от целей.
Например при схеме:

интернет - outside-ASA-inside - 2.2.2.0/24

Пописывание ip verify reverse-path interface outside будет блокировать все пакеты с src 2.2.2.0/24 если они появяться на интерфейсе outside. Если же указать это на inside то внутренние хосты не смогут посылать наружу пакеты с поддельными адресами.

Anonymous said...

Огромное спасибо, я догадывался что оно как-то так работает . . но до конца не понимал . . еще раз спасибо за разъяснение!