информационная безопасность
без паники и всерьез
 подробно о проекте
Rambler's Top100Сетевые кракеры и правда о деле ЛевинаСтрашный баг в WindowsВсе любят мед
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
БСК
Закон есть закон




5. Комментарии к написанию кода, генерирующего STP пакеты

Глава 8.3.2 в [1] содержит следующую фразу: "A MAC frame conveyng a BPDU". Это значит, что BPDU это пакет, а не фрейм. Таким образом, нет необходимости конструировать фреймы самостоятельно, поскольку они стандартны для данной физической среды - мы можем конструировать BPDU пакеты выше, чем самый нижний подуровень 2-го уровня OSI. Иначе говоря, можно отвязать программу конструктор BPDU от конструктора фреймов, оставив функцию инкапсуляции соответствующему драйверу. Однако, авторы выбрали для своих исследований создание программного модуля, конструирующего BPDU напрямую. Исходный текст модуля на языке C и сценарий на языке bash для более удобного манипулирования параметрами командной строки приведены в приложениях.
Авторы долго не могли прийти к единому мнению: стоит ли делать эти тексты общедоступными. Без понимания принципов работы STP и выбора параметров эти тексты ничем не помогут личностям с деструктивными наклонностями, а человек, который разобрался в сути уязвимости, может воспользоваться любым конструктором пакетов. В связи с этим, тексты решено было включить в открытую публикацию.

Чем хорошо создание фреймов напрямую:

  1. Можно ставить произвольный MAC-адрес источника, что значительно осложняет определение реального источника атаки. До тех пор покуда не применяется насильственный line-jamming (заявка коллизий в их отсутствие в CSMA/CD сетях
  2. Если конструировать фреймы самостоятельно, можно добиться ситуации при которой атака идет как бы параллельно с нормальной работой, маскируя таким образом атакующего за счет передачи пакетов с "фальшивого" MAC адреса одновременно с нормальной работой в сети со "своего" MAC адреса.
  3. По мнению авторов, пока не существует стандартного (одинакового для всех систем) способа формировать BPDU иначе, чем конструируя фреймы полностью. Это говорит о том, что реализации алгоритмов таким методом для FreeBSD, OpenBSD, Linux и других OS будут существенно различны, в результате чего лучшим способом будет все же посылка BPDU в полностью самостоятельно сконструированных фреймах.

Чем плохо создание фреймов, а не пакетов Spanning Tree:

  1. Поскольку Spanning Tree протокол определен для различных типов MAC.
Media Access Control (управление доступом к среде передачи данных). Например, Ethernet, Token Ring и т.п., код получится непереносимым между ними.

Ethernet был выбран авторами из-за наибольшей распространенности, по сравнению со всеми остальными типами сетей.

Помимо написания собственных программ есть возможность использовать готовые программные средства, обернув их в скрипты на любом подходящем языке, например, perl или языках shell - bash, zsh, ksh, csh (см. раздел 9), что значительно упрощает работу с параметрами Spanning Tree. Однако при этом появляется дополнительное условие - Linux с ядром, настроенным для поддержки bridging плюс соответствующий комплект утилит. Еще одним отрицательным моментом выбора такого пути будет необходимость накладывания патчей на исходный код Linux bridging project в случае, если потребуется сконструировать атаку с модификацией алгоритма работы, выходящей за рамки стандарта, например, изменить значения таймеров на меньшие или большие, чем описано в стандарте.

Стоит также сказать несколько слов на тему особенностей программирования под разные операционные системы и выбора языка:

Windows-подобные системы.
В этих системах, исключая Windows XP, нет поддержки raw sockets, что не позволяет без специального драйвера (VxD) конструировать фреймы напрямую - как обычно гибкость windows систем "из коробки" оставляет желать лучшего. Поэтому под windows системы и unix системы это будут совсем разные реализации. Ну, разве что, писать на perl, который, однако установлен не на каждой windows системе. Еще вариант - использовать java, приложения на которой можно запускать автономно при помощи jre.
Unix-подобные системы.
В качестве языка лучше всего выбрать C-компиляторы - они есть во всех unix-подобных системах практически под любую платформу. Впрочем, можно было выбрать и perl - там тоже есть raw-sockets. Возможны проблемы портирования на другие unix-подобные системы с linux, т.к. отличаются названия интерфейсов. Но это можно легко решить при помощи Makefile. А вот если различаются API -- придется потрудиться побольше.




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



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


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