asy писал(а):Богдан писал(а):Методы аутентификаии text и md5 подвержены взлому методом последовательного перебора за разумное время. Грубо говоря - эти методы слабы против настойчивости взломщика.
Оно, конечно, несколько оффтопик наверное, но вопрос: а Вы OSPF в недоверенной сети используете? Откуда там взломщик возьмётся? Всегда интересовала область применения всего этого. Разве что multihop bgp, но и то IP фиксированный и известно, чей.
У меня такой случай:
- множество мелких сеток со своими админами объединены в одну большую физическую сеть (каждый подъезд - отдельная сеть);
- по админу в каждый подъезд - чисто для красоты в юридически значимых документах и изменению не подлежит (кто материально ответственен - тот админ - у того и ключи к коммутационному шкафу);
- главный админ итоговой сетки - фактический админ (админ в одном из подъездов), но юридически он - всего-лишь координатор и права голоса не имеет.
Необходимо обеспечить связность всех сеток на равноправных условиях при том, что права доступа к оборудованию выдаются только по запросу и будут отняты после первоначальной настройки.
Задачка банальная, правила игры просты, настройки элементарны - настрой один раз да разошли всем документ на несколько страниц с описанием и строками настроек... Ляпота!
А однажды прилетит нежданчик с подлогом маршрутов да взломами из такой подложной сетки - ищи потом крайнего из десятка "админов"... Вот только сейчас планируемое количество сеток - лишь пара десятков, а может вырасти до сотни.
В протоколах динамической маршрутизации ключи актентификации используются лишь как параметр для формирования строки подписи для пакета с маршрутной информацией. Была бы возможность в функции подписывания подсолить саму подпись - можно было бы успокоиться. Но ввиду простоты подбора ключа для подписи по методу plain-text/md5, в случае ЧП виновник может отделаться заявлением "это не я виноват - виноват слабый режим аутентификации, позволивший подобрать ключь, подключившись к аплинкам в разрыв".
Подбор ключа для подписи, сформированной с использованием hmac* - задача на целые порядки сложнее, поэтому в случае ЧП виновником окажется именно один из админов (он же - материально ответственный и одновременно держатель ключей к замкам коммутационного шкафа).
Итог: высокий уровень аутентификации в пакетах маршрутной информации позволяет исключить саму вероятность несанкционированного физического подключения к аплинкам и позволит перейти сразу к утверждению "Из предопределнного списка админов виновен товарищ Х, потому что именно он отвечает за источник проблемных маршрутов - железку Y (согласно логам по SNMP). В качестве наказания - отключение подъезда от общей сети на месяц путём смены ключей аутентификации. И пускай виновный админ сам обхясняет соседям по подъезду причину, по которой жители подъезда не могут смотреть видео с камеры видеонаблюдения на въезде во двор."
не работает.