информационная безопасность
без паники и всерьез
 подробно о проекте
Rambler's Top100Страшный баг в WindowsГде водятся OGRыСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Ядро Linux избавляется от российских... 
 20 лет Ubuntu 
 Tailscale окончательно забанила... 
главная обзор 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
БСК
Закон есть закон




14. Как администраторы сетей могут противостоять атакам

Если обеспечение безопасности сети стоит не на последнем месте, лучше отключать поддержку Spaning Tree всегда, когда это возможно, и пытаться заменить STP другими технологиями там, где требуются решения с дублированием каналов, но все же можно обойтись без особенностей STP. Например, можно использовать технологию Link Agregation (поддерживается многими устройствами, в том числе произведенными Intel, Avaya и др.).

Если же безопасность важна, но выключить STP по тем или иным неутешительным причинам для всей сети неприемлемо, придется использовать расширения Spaning Tree доступные, в частности, в решениях, предоставляемых cisco,
Которые, однако, не решают всех проблем.
либо просто расслабиться и надеятся на то, что ваша сеть не попадет в поле интереса различных личностей с деструктивными наклонностями, например "кракеров",
Наиболее удачное описание различий терминов "кракер" и "хакер" см. в [3]
или просто на то, что производители когда-нибудь исправят имеющуюся печальную ситуацию. Правда, здесь не совсем все так печально, как может показаться - помогут следующие административно-технические шаги:

  1. Если у Вас менее 2-х WAN-линков между офисами, STP-домены следует разделить (то есть отключить поддержку STP на WAN-линке). См. раздел 4.
  2. Если оборудование позволяет, следует выключить STP вовсе или оставить его только на тех портах, которые являются транковыми (тегированными) - такие порты смотрят обычно на другие сетевые устройства, но не на пользователей. Следовательно, если в рамках сети нет портов, на которых подключены рабочие станции и сервера, то это будет одним из вариантов достаточно устойчивой и (возможно, если я не пропустил чего ;) ) безопасной картины. =)
  3. Можно попробовать выставить минимально возможный bridge id и прочая (тут надо вписать подробности выбора корня), что сделает приоритет свитча максимально возможным, тогда он всегда будет root'ом и реконфигурация может разве что затронуть часть сети (ближайшие к атакующему свитчи, если атакующий использует подделку bpdu), за исключением установленного раз и навсегда STP-корня. Мы можем это сделать, поскольку STP корень выполняет всего лишь навсего роль точки отсчета, от которой строится топология без колец. Но вот незадача - последний параметр выбора (если все одинаковое) - MAC-адрес порта, что собственно считается гарантированно разным. Но если нужен DoS, то злоумышленник может создать некорректную с точки зрения стандарта ситуацию, когда MAСи совершенно идентичны. При этом вопрос "как поведет себя коммутатор?" остается открытым. Результат требует проверки, поскольку нигде не документировано (насколько нам известно) как ведет себя мост в случае получения сообщения с собственным MAC.




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



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


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