Яким чином у середовищі Cisco (ISR-G2) я можу запобігти або пом’якшити неправильні повідомлення про RA?
Я бачу, що у Cisco є " IPv6 RA Guard " ... Але це просто працює на маршрутизаторі і "відбивається" з правильними RA Чи не було б більше сенсу вимикачі, що фільтрують фіктивні РР з мережі? (Або я занадто параноїчний щодо фальшивих РА?)
Відповіді:
Це з посібника з налаштування для IOS 15.2T. Особливість називається охоронцем RA. В основному ви створюєте політику і визначаєте, чи порт, до якого буде застосовано, веде до хоста або маршрутизатора. Тоді ви можете бути більш конкретними і співставляти на хоп-ліміті, керованому-конфігураційному прапорі та збігатися на ACL з діапазоном, звідки повинні надходити надійні джерела. Ви також можете зробити порт надійним і не робити додаткових перевірок.
У чомусь це дуже схоже на прослуховування DHCP. Основні етапи:
ipv6 nd raguard policy RA-PROTECT
device-role host
interface x/x
ipv6 nd raguard attach-policy RA-PROTECT
Потім ви можете використовувати цю команду для перевірки:
show ipv6 nd raguard policy
Якщо ваші комутатори підтримують цю функцію, то є сенс ловити RA на якомога раніше. Я не думаю, що це параноїк. Те саме можна сказати і для DHCP. Іноді це навіть не зловмисні користувачі, це лише випадки, коли люди не знають краще або підключають хитрі пристрої до мережі.
З RFC 6105 : "RA-Guard застосовується до середовища, коли всі повідомлення між кінцевими пристроями IPv6 проходять через керовані мережеві пристрої L2." Тобто це робить те, що, як ви кажете, повинно робити; відфільтрувати негідних РА при вході в комутаційний порт. Він працює за принципом блокування проти прийняття, а не просто кричить голосніше, ніж інший хлопець.
Cisco пропонує RA-охорону як засіб для захисту від непривілейованих портів, що надсилають несанкціоновані RA.
Однак увімкнення цього лише не гарантує захист, оскільки існує декілька інструментів атаки (THC сприймається на увазі), які розділять рекламу маршрутизаторів на фрагменти, тим самим переможивши охорону RA.
Найкращим захистом від цього є скидання фрагментованих пакетів ICMPv6, оскільки, загалом кажучи, шанси легально потребувати фрагментації дейтаграми ICMPv6 (окрім дуже великого пінг-коду) невеликі.