информационная безопасность
без паники и всерьез
 подробно о проекте
Rambler's Top100Страшный баг в WindowsГде водятся OGRыВсе любят мед
BugTraq.Ru
Русский BugTraq
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Модель надежности отказоустойчивой... 
 Google по-тихому включила изоляцию... 
 25 лет FreeBSD 
 Microsoft покупает GitHub 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / библиотека / книги / spanning tree / что делать производителям
SPANNING TREE
титул
содержание
введение в spanning tree протокол
STP & VLANs
STP в гетерогенных средах
замечания, вытекающие из анализа RFC 2878
комментарии к написанию кода
возможные схемы атак
получение дополнительной информации о сети
особенности реализации у различных производителей
замечания по поводу Linux bridging project
замечания по поводу GARP и GVRP
обзор атак на 2 уровне OSI
уязвимые продукты
примеры уязвимых сетей
как администраторы могут противостоять атакам
как IDS могут обнаружить STP атаки
корни проблемы, или "откуда ноги растут"
что делать производителям
эпилог
благодарности
ссылки
список литературы
глоссарий
программа формирования ST пакетов
сценарий для запуска программы




Подписка:
BuqTraq: Обзор
RSN
БСК
Закон есть закон




17. Как производители могли бы отреагировать на появление в публичном доступе информации по STP-атакам
  1. До тех пор, пока не будут найдены лучшие пути, устройства "из коробки" должны игнорировать STP протокол, как сделано, например, в коммутаторах Hewlett Packard HP212M и 224M (в них поддержка STP "из коробки" выключена). Это позволит избежать атак в тех ситуациях, когда STP не является жизненно необходимым элементом сети (например, в сети с единственным коммутатором).
  2. Следует отказаться от принципа plug&play по отношению к сети: например, выпустив новую версию стандарта, которая будет требовать переконфигурации администратором некоего STP пароля (желательно нетранслируемого напрямую в сеть), который требовался бы для участия в изменении топологии по новому STP-протоколу, и без ввода которого поддержка STP была бы выключена. Так можно было бы значительно усложнить воспроизведение атаки на топологию сети. Ничего особенно страшного в том, что устройство перед вводом в полнофункциональную работу с сетью надо будет чуть-чуть отконфигурировать нет: обычно устройства все же конфигурируют, перед тем, как задействовать в сложных сетях, а сети, в которых STP работает не просто так, а с пользой, явно сложнее остальных, которых, кстати, большинство.:) Конкретная реализация может быть выполнена с использованием известных криптографических методов, например, при помощи Кодов Подтверждения Достоверности (Message Authentication Code, MAC). Для этого в пределах группы оборудования, которое должно образовать stp-дерево, выбирается "общий секрет" (пароль, ключ), заносимый в каждое устройство (лучше с помощью dip-switches на панели, т.е. аппаратно)
Такой подход позволит автоматически выполнить и предыдущую рекомендацию, если положение переключателей по умолчанию ("все в 0") будет означать для устройства отключение поддержки STP.. После этого перед посылкой BPDU-пакета к нему добавляется секрет, для всего массива (пакет вместе с "общим секретом") рассчитывается значение хеш-функции (например, SHA-1) и прибавляется к отправляемому BPDU-пакету ("общий секрет", естественно, при этом не передается). На принимающей стороне к принятому пакету также добавляется секрет и рассчитывается значение хеш-функции, которое сравнивается с полученным в пакете. В результате получатель уверен, что пакет послал кто-то из "своих" (обладающих знанием секрета), при этом сам секрет по сети не передается и не может быть перехвачен злоумышленником для последующего использования.
  1. Каждое устройство, поддерживающее STP, должно иметь возможность отключить обработку STP на каждом порту по отдельности, это реализуется переписыванием управляющего софта. Без выполнения этого условия применение такого устройства в сети становится небезопасным. Разумеется, в момент выключения STP на порту администратор должен понимать, что он лишается возможности использовать преимущества STP и ставит себе потенциальную ловушку. Однако есть масса случаев, когда это оправдано. Например, предоставление клиентам ISP сервиса по Ethernet сети - в этом случае сети всегда будут разделены и STP на клиентских портах никогда не принесет пользы. С точки зрения реализации, порты с выключенной поддержкой STP должны просто отбрасывать любые STP-BPDU и не должны посылать никаких STP-BPDU.
  2. Крайне желательно, чтобы каждое STP-совместимое устройство поддерживало команду, аналогичную командам Сisco STP portfast и BPDU-guard. Это позволило бы избежать некоторых типов DoS (STP portfast), а также (BPDU-guard) локализовать сегмент с атакующим.
  3. Каждое устройство, поддерживающее и STP, и VLANы, должно поддерживать отдельное STP-дерево на каждый VLAN, в противном случае атака в одном VLAN может привести к отказу работы всей сети (например, в случае использования intel 460T с включенным STP).
  4. Алгоритм работы STP должен быть пересмотрен: на используемые алгоритмом таймауты должны быть наложены более жесткие ограничения, такие, чтобы стала невозможной постоянная реконфигурация устройств, при которой время, проводимое в состояниях с запрещенной трансляцией фреймов, не может быть больше времени устаревания информации.
  5. Протокол STP требует доработки в части внесения в него функций обеспечения аутентичности и целостности передаваемой информации (пакетов BPDU), например, с применением криптографических методов. Это позволило бы избежать ситуации когда конфигурация изменяется атакующим в любой момент времени посредством посылки bpdu от имени другого устройства.
  6. Спецификация алгоритма STP (как и прочих административных протоколов, работающих на 2-м уровне OSI), а также спецификация канального уровня всех LAN могут быть расширены таким образом, чтобы NIC'и физически не могли общаться с устройствами, обслуживающими сеть (маршрутизаторы, мосты, концентраторы и т.п.) с использованием административных протоколов. Иными словами, административные протоколы, используемые коммутаторами для определения топологии, могли бы работать с использованием отдельной схемы электрической сигнализации (другой вольтаж или метод кодирования сигнала). Поскольку сетевые адаптеры конечных устройств не будут иметь такой схемы, они физически не смогут вмешаться в работу административных протоколов. Этот вариант изменения протокола представляется мало перспективным. Во-первых, он достаточно сложен в реализации (необходимо перепроектировать аппаратную часть). Во-вторых, аппаратная несовместимость остановит лишь часть личностей с деструктивными наклонностями (не умеющих держать в руках паяльник). В-третьих, сразу же встает вопрос обратной совместимости с ранее выпущенным оборудованием. Таким образом, несмотря на серьезные затраты, он не является панацеей.
  7. Возможно, следует изменить STP протокол таким образом, чтобы пользовательские фреймы передавались всегда, предусмотрев при этом дополнительную маркировку фреймов, переданных в период реконфигурации маркером, который помогал бы уничтожать их по прошествии некоторого таймаута - в конце концов не так уж и много урона сети нанесут продублированные по разным каналам фреймы, в отличие от описанных в этой статье DoS атак.
  8. Возможно, стоит создавать более сложные административные протоколы - с установлением соединения (подобно tcp). Это может серьезно усложнить спуфинг конфигурационных сообщений.
  9. Также, возможно, стоит расширить STP таким образом, чтобы устройства запрашивали подтверждения происходящего поверх заблокированных каналов в тех случаях, когда это возможно. Такая модификация отбросит возможность определенных подвидов атак (в частности, MitM).




Rambler's Top100
Рейтинг@Mail.ru



назад «     » вперед


  Copyright © 2001-2018 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach