Введение в недокументированное применение протокола Spanning TreeО.К. Артемьев, В.В. МяснянкинЛицензионное соглашениеДанное исследование является интеллектуальной собственностью Олега Артемьева и Владислава Мяснянкина (здесь и далее - авторов). Оно может свободно использоваться для ссылок, но его текст - как полностью, так и частично - не может быть переведен на какой либо язык или включен в любую другую статью, книгу, журнал, а также иные электронные или бумажные издания без письменного разрешения обоих авторов. Кроме того, при ссылке на результаты этого исследования, или их использовании необходимо полностью приводить название, имена авторов и текст лицензии. Материалы исследования могут свободно распространяться в электронном виде, если и только если соблюдены следующие условия:
Материалы исследования содержат информацию, свободное распространение которой не противоречит законодательству большинства стран. Если же ваше локальное законодательство содержит ограничения на распространение информации об уязвимостях информационных систем (подобие DMCA в США), то публикация данных материалов в этой стране противоречит данной лицензии. Более того, будучи гражданином такой страны и читая эту статью, вы нарушаете и законодательство своей страны, и данную лицензию. Авторы не несут ответственности за любые последствия от использования (или не использования) изложенной в исследовании информации, включая повреждение данных, недополучение прибыли, а также любые другие косвенные или прямые потери. Авторы декларируют материалы этого исследования как исключительно образовательные. Вы не должны знакомиться с ними, если не согласны использовать их иначе как в образовательных целях. Данное лицензионное соглашение может быть изменено без предупреждения по согласию обоих авторов. Гарантии: это исследование распространяется без каких либо гарантий и ответственности.
ЗамечанияЭтот документ основан на анализе стандартов IEEE, относящихся к протоколу Spanning Tree [1], а так же на анализе стандарта RFC 2878 [5], и будет часто цитировать и ссылаться на них. Все копирайты и зарегистрированные торговые марки, упомянутые в нем, принадлежат их собственникам. Протокол и алгоритм Spanning Tree определены в главе 8 стандарта "MEDIA ACCESS CONTROL (MAC) BRIDGES ANSI/IEEE Std 802.1D" [1].
Этот документ предназначен для тех, кто, как минимум, знаком с моделью OSI [2]. Для тех, кто не имел возможности прочесть содержимое стандарта [1], написана краткое введение в работу протокола STP, которое, однако, не может заменить чтения этого стандарта, поскольку рассматривает подробно только те особенности его работы, которые необходимы для описания его недокументированного применения. Также предполагается, что читатель имеет хорошее представление о построении ЛВС и используемых в этой области сокращениях. В целях наиболее точной передачи смысла многие цитаты из оригинальной документации и текстов стандартов оставлены на английском языке. В связи с этим предполагается, что читатель владеет английским языком в степени, достаточной для понимания технического текста. Далее в тексте при описании атак, до тех пор, пока не сказано иного, рассматриваются атаки на устройства с использованием Spanning Tree Protocol
Идея и первичный текст принадлежат Олегу Артемьеву [olli@olli.digger.orgNOSPAM.ru], первичная концептуальная реализация в коде принадлежит Владиславу Мяснянкину [vlad@cybervlad.port5.NOSPAMcom]. Для связи с владельцем любого из указанных в статье email'ов надо убрать из него слово NOSPAM - для предотвращения авто-спама. Хотелось бы сказать несколько слов о причинах написания этой статьи авторами:
Ключевые словаУязвимости протокола Spanning Tree, уязвимости алгоритма Spanning Tree; безопасность 2-го уровня OSI; исследование безопасности стандарта IEEE 802.1D; безопасность мостов, маршрутизаторов и коммутаторов на 2-м уровне OSI; cisco, avaya, 3com, compex, cnet (и т.д. - все, кто делает stp-совместимые устройства); уязвимости интеллектуальных коммутаторов, поддерживающих протокол Spanning Tree; реализация отказа в обслуживании и навязывание ложного маршрута с использованием протокола Spanning Tree; STP design flaw; exploiting STP holes. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
Этой статьей авторы хотели бы не столько объяснить, что такое Spanning Tree Protocol, сколько рассказать о недокументированных возможностях его применения, которые, возможно, не принимались во внимание разработчиками протокола. Поэтому, несмотря на то, что в статье в общих чертах приводится описание протокола Spanning Tree и его назначения, она не претендует на статус материала, который следует использовать для изучения этого протокола с нуля - предполагается, что вы уже читали какие-либо материалы на эту тему, а это введение лишь освежит вашу память. Если же вы вообще не знакомы с этим протоколом и (или) это введение показалось вам недостаточно вразумительным - рекомендуем обратиться к многочисленным описаниям STP в литературе, на сайтах ведущих компаний производителей интеллектуальных LAN-устройств (например, поискать материалы на http://www.cisco.com) и, разумеется, к IEEE стандарту, описывающему этот протокол [1]. Также в разделе "ссылки" есть, возможно, достаточный для составления полной картины набор url. Основное назначение протокола Spanning Tree - построение топологии ЛВС без избыточного дублирования соединений или закольцовывания, недопустимых в силу логики построения ЛВС. STP позволяет организовать в сети, построенной при помощи мостов (bridges), отказоустойчивую архитектуру.
Используя STP, вы можете построить сеть, в которой существует несколькопараллельных путей, и гарантировать при этом, что:
Например, на рисунке 1 показана сеть, построенная на четырех коммутаторах, поддерживающих протокол STP. Это обстоятельство позволяет соединить их избыточным количеством линков, которые в обычных условиях создали бы петли и привели к неработоспособности сети. Однако, при инициализации сети STP обнаруживает дублирующие пути и оставляет на каждое направление только один, переводя остальные задействованные в линках порты в состояние "blocking" (на рисунке соответствующие линки зачеркнуты). При нарушении основного канала передачи (например, в следствие отключения одного из коммутаторов), STP обнаруживает этот факт и задействует запасной маршрут.
Протокол разработан в начале 90-х годов XX века (ANSI/IEEE 802.1D 1993 Edition) и дорабатывался в 1996 и 1998 годах. В качестве модели используется граф в виде дерева. Построение дерева сети начинается с корня (root) -- устройства, выигравшего выборы корневого (designated root). Designated root -- это просто отправная точка для построения активной незакольцованной топологии, в которой физические кольца не дают логических колец (см. главы 8 и 9 [1]). Иными словами, это логическое понятие. Важно заметить, что Spanning Tree Protocol определен для различных сред передачи данных (MAC, Media Access Control). Далее в тексте рассматриваются примеры сетей в основном на базе Ethernet, как наиболее распространенной. BPDU - это именно пакеты, а не фреймы. Это ясно из [1], 8.3.2, стр.61. BPDU пакеты инкапсулируются в используемый данной топологией тип фрейма с мультикастным MAC адресом в поле назначения, что обуславливает передачу этих пакетов через неинтеллектуальное оборудование, не знающее о существовании Spanning Tree. Работа STP подразумевает выполнение следующих условий:
Designated root присутствует всегда, даже когда топология не содержит физических колец. Если в сети только одно STP-совместимое устройство - до тех пор, пока STP не выключен, оно будет анонсировать себя. Каждое STP-совместимое устройство начинает работу, считая себя designated root, так что в сети с единственным STP-совместимым устройством оно и является Designated Root Bridge.
Если же в сети присутствует более устройства, поддерживающего STP, то Designated Root Bridge выбирается путем голосования (выборов) на основе значения параметра Bridge Identifier, обычно являющегося комбинацией уникального MAC-адреса моста и устанавливаемого для моста приоритета (см. [1], главы 8 и 9). На роль Designated Root Bridge назначается мост с наименьшим значением Bridge Identifier. Для всех остальных мостов в сети определяется Root Port, т.е. порт моста, ближайший к Root Bridge. От других портов, соединенных с root bridge непосредственно или через другие мосты, он отличается своим идентификатором, который содержит его номер и "вес", который может быть задан администратором. Другой величиной, влияющей на процесс выборов, является Root Path Cost. Она состоит из стоимости пути до Root Port данного моста плюс стоимость путей до Root Port мостов по всему маршруту до Root Bridge. Помимо Designated Root Bridge в STP вводится логическое понятие Designated Bridge. Владелец этого статуса считается главным в обслуживании данного сегмента ЛВС. Статус Designated Bridge также является выборным и может переходить от одного устройства к другому. Аналогичным образом вводится выборное логическое понятие Designated Port - порта, который обслуживает данный сегмент сети. Для Designated Port вводится понятие Designated cost, описывающее стоимость пути ([1], 8.5.5.5). В зависимости от содержимого получаемых от соседних устройств конфигурационных пакетов то или иное устройство перестает оспаривать статус Designated Root Bridge и начинает анонсировать устройство, выигравшее этот статус в процессе выборов. Так происходит до тех пор, пока ситуация не придет к завершающей стадии, которая характеризуется следующим образом:
Как уже говорилось, корень не несет на себе иных обязанностей, кроме анонса своих параметров согласно спецификации Spanning Tree протокола, а это, в частности, значит, что в сети, не содержащей физических колец или избыточных соединений, от изменения владельца статуса Designated Root Bridge пути пакетов, пересылаемых между двумя произвольными станциями не изменится. Спецификация протокола [1] не накладывает ограничений на время, в которое могут начаться выборы того или иного параметра, а лишь описывает необходимые для этого условия. К числу ситуаций, в которых возникают выборы как минимум одного из параметров, относятся:
В качестве параметров при выборах используются следующие величины:
Величины bridge identifier и port identifier являются составными и образуются из поля приоритета (может устанавливаться администратором) и поля, присваиваемого производителем (некоторые устройства могут поддерживать установку этих идентификаторов целиком). Согласно спецификации выборные величины, в зависимости от контекста, могут принимать участие в различных выборах, например, designated cost может принимать участие как в выборах назначенного моста, так и в выборах корневого моста.
Таблица 1. Структура C-BPDU
Таблица 2. Структура TCN-BPDU
Во время работы устройства анонсируют себя и параметры своих портов через Configuration BPDU (далее называемые c-bpdu). Формат c-bpdu приведен в таблице 1 (согласно [1], 9.3.1, рисунок 9-1) и на рисунке 2 (согласно [1], 8.9.1). Для сообщения об изменениях в топологии используются topology change notification BPDUs, формат которых приведен в таблице 2 и на рисунке 3 (согласно [1], параграф 8.3.5, стр. 63, последний абзац). Собственно информации передается совсем немного - только статус. По факту прихода такого BPDU любой коммутатор уменьшает время жизни записей в своей таблице коммутации до минимума, определенного стандартом [1]. В момент получения конфигурационного bpdu STP-совместимый мост может определить, что пришедшая информация должна обновить имеющуюся у него информацию. В этом случае устройство изменяет содержимое анонсируемых им bpdu так, чтобы анонсировать выигравшее устройство, а не себя. Обратите внимание, что BPDU не проходят сквозь устройства, которые поддерживают STP - они лишь, при определенных условиях, инициируют на "промежуточном" устройстве посылку собственных BPDU ([1], 8.3.2) и/или изменение содержимого BPDU посылаемых "промежуточным" устройством. В момент обновления конфигурации STP-совместимое устройство изменяет состояние своих портов - они поочередно принимают одно из следующих возможных значений ([1], 8.4):
Время, на которое порт попадает в то или иное состояние, определяется значениями пауз, которые передаются посредством C-BPDU вместе с остальными параметрами (см. раздел 6.4.7). Согласно стандарту, во время нахождения в состояниях Blocking, Listening и Learning пересылка не-STP пакетов не разрешена ([1], 8.4.1-8.4.3). В то же время, bpdu-пакеты не обрабатываются только в случае если порт выключен администратором ([1], 8.4.5). Это говорит о том, что если порты находятся в режимах Blocking, Listening или Learning - сеть работает только на STP протокол, но не на пользователя. Этим можно воспользоваться для организации атаки "отказ в обслуживании" (Denial of Service, DoS), в терминах [3]. Собственно, причина, по которой протокол работает именно таким образом ([1], 8.3.4), проста - все так организовано для того, чтобы избежать хаотичного дублирования и/или размножения пакетов в различные сегменты сети в момент перестройки ее топологии. Дублирование и/или размножение пакетов возможно, например, за счет возникновения временных колец, возникающих в процессе переключения состояния того или иного линка. Описание DoS атаки, а также величины параметров, необходимые для максимальной ее эффективности, см. в разделе 6. В силу того, что топология сети определяется при участии протокола STP возможна атака по схеме ложный объект РВС с навязыванием ложного пути (в терминологии [3]). Подробности см. в разделе 6.5. Следует отметить, что стандарт не уточняет термин LAN-сегмент в данном контексте, что еще раз указывает, что это вещь весьма относительная, так что состав соответствующих сетей будет меняться в зависимости от выбранной точки подключения. Вообще говоря, описываемые на примере Ethernet уязвимости протокола относятся (часть может быть применена практически без изменений алгоритма) к любым топологиям, на которых может работать STP. Как следствие, протокол и рассматриваемые атаки, требующие включенной поддержки STP, могут быть применены на любых сетевых топологиях, не допускающих логических колец). В [1] специально обращено внимание на то, что STP может ходить не только поверх Ethernet, но и поверх других сетей с другим принципом MAC. Для большей наглядности и лучшего понимания работы STP авторы включили примеры, изображенные на рисунках 1 и 4. Комментарии к рисунку 1 расположены в самом начале этой главы. Рассмотрим теперь работу STP более подробно, для чего обратимся к рисунку 2.
Каждый порт каждого моста имеет свою величину Path Cost, обозначенную как PC=XXX. Мост A является Root Bridge, т.к. имеет наименьшее значение Bridge Identifier. Для сети A (LAN A) Designated Bridge Port является порт 1 моста А. Один из портов каждого из четырех оставшихся мостов является Root Port (это порт, ближайший к Root Bridge). Мосты X и B предоставляют доступ к сети B с одинаковым параметром Path Cost. Однако, в данном случае, порт моста B выбран в качестве Designated Bridge Port, т.к. этот мост имеет меньшее значение Bridge Identifier. Порт моста C выбран в качестве Designated Bridge Port для сети C, т.к. он предоставляет более "дешевый" доступ к этой сети (стоимость пути через мосты C и B равна 200, а через мосты Y и B - 300).
В стабильном состоянии все мосты ожидают периодической посылки Root
Bridge специальных пакетов - Hello BPDU. Если в течение промежутка
времени, определяемого значением Max Age Time, таких пакетов от
Root Bridge не поступает, мост считает, что либо между ним и Root
Bridge нарушена связь, либо последний отключен. В этом случае мост
инициирует реконфигурацию топологии сети. Путем установки
соответствующих параметров можно регулировать, насколько быстро
мосты будут обнаруживать изменения в топологии и задействовать
запасные маршруты. На практике с регулировкой значений STP приходится
сталкиваться в основном в двух случаях - если в силу обстоятельств STP
переводит в режим "запасного" более быстрый линк и если сеть имеет
плохую сходимость на значениях по умолчанию из-за большого количества устройств.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
2.1. Краткое введение в технологию VLANЧто есть VLAN? Virtual LAN, некоторое средство логического деления сети на части. Основная идея заключается в том, чтобы выделить некую часть сети в независимую группу. В современной практике очень часто применяются для разделения доступа к той или иной части сети. Среди людей занимающихся администрированием ЛВС встречаются люди, считающие, что выделенные в VLAN сегменты сети полностью отделены друг от друга, чуть ли не на физическом уровне. Так ли это? Давайте посмотрим. Во первых, какие бывают VLAN'ы: VLAN'ы бывают MAC-based, port based и "тегированные" (определяются стандартом [4]). MAC based VLAN -- это группа рабочих станций, объединенных на основе физических адресов их сетевых адаптеров, в случае Ethernet - на основе MAC-адреса Ethernet адаптера компьютера (адреса его NIC). Port based VLAN'ы -- это VLAN'ы, создаваемые из портов коммутатора путем объединения их в группы. Наконец, 802.1q VLAN'ы (dot 1 q), или tag-based VLAN'ы появляются в средах передачи данных с модифицированными фреймами. Модификатор фрейма представляет собой некоторую добавку к стандартному типу фрейма. Согласно содержимому этой "добавки" устройство, обслуживающее сеть, может разделять трафик, в том числе по параметру "VLAN ID". В типичном случае, такие VLAN "ходят" внутри транковых (тегированных) каналов, или, перефразируя, между тегируемыми интерфейсами. В терминологии Cisco Systems такой порт называется "транковым" (trunk). Особенности .1q VLANов:
С точки зрения функционирования некоторого моста, сеть, в которой появляются VLAN, должна обслуживаться с иной таблицей коммутации, чем та, которая применяется для сети без VLAN. В сетях с использованием VLAN появляется еще один параметр в таблице коммутации - VLAN id и правила коммутации привязываются к этому параметру так, чтобы коммутация фреймов могла происходить только между портами, являющимися членами одной и той же VLAN. В случае, если часть портов коммутатора в одном VLAN'е, а другая часть - в другом VLAN, то тогда, с точки зрения нормального функционирования сети, можно рассматривать эту ситуацию как два независимых коммутатора. Это утверждение действительно справедливо для пользовательского трафика, однако оно не совсем верно для ситуации с STP и BPDU, обеспечивающих функциональность, требуемую алгоритмом Spanning Tree. 2.2. Миф о раздельном дереве STP в каждом VLANПрежде всего, следует заострить внимание на функционировании STP в системах с поддержкой VLAN. При этом надо отметить, что наиболее "продвинутые" устройства, поддерживающие VLAN (но не все), поддерживают отдельное STP дерево на каждый VLAN. Таким образом все STP атаки на такие устройства, на первый взгляд, будут эффективны только в пределах данного VLAN (по поводу VLAN см. [4]). C точки зрения STP внутри vlan мы имеем стандартную схему функционирования портов - каждый порт, согласно протоколу, получает и отправляет BPDU и, в зависимости от их содержимого, изменяет свое состояние. Тем не менее, часть устройств, поддерживающих VLAN, имеет единственное Spanning Tree дерево на весь коммутатор (например,модели Intel 460T), что делает всю сеть, построенную на таких устройствах, уязвимой ко всем STP атакам. С точки зрения обсуждаемых проблем, устройства второго типа с единственным на все устройство STP-деревом по части функционирования STP атак ничем не отличаются от рассматриваемого ниже случая без поддержки VLAN, так что мы не будем рассматривать отдельно этот вариант. Со вторым типом устройств, поддерживающих собственное STP-дерево на каждый VLAN, дела обстоят немного по-другому. Чтобы подойти поближе к заголовку этой главы, давайте обсудим пару практических примеров, которые могут встретиться в нормальной (рабочей) ситуации, а также к тому, как коммутатор может обеспечить работу именно по такому варианту. 2.3. Миф о физической раздельности VLAN'овИтак, как уже указывалось ранее, port based VLAN'ы можно объединить, просто воткнув патч-корд в соседние порты, подключенные в разные VLAN. После того, как это произойдет, порты, объединенные в VLAN'ы, с точки зрения коммутатора по-прежнему будут состоять в разных VLAN - до тех пор, пока не используется GVRP (см. раздел 10), принадлежность порта тому или иному vlan определяется исключительно администратором (и правилом по умолчанию, если администратор не соизволил определить данный порт в тот или иной VLAN). Однако для корректного функционирования STP описанная ситуация должна отслеживаться особенным образом, то есть, с точки зрения STP, если два изначально "независимых" дерева вдруг соединились, то появился повод для STP-выборов. Действительно, аналогичная ситуация возникала на практике и алгоритм STP срабатывал. С учетом возможности конвертации VLAN ID становится понятно, что на самом деле независимость STP дерева в пределах VLAN -- это миф. Возникает идея: что если сгенерировать STP BPDU с параметрами, аналогичными тем BPDU, которые распространяются в соседнем VLAN, можно заставить STP устройство устроить перевыборы с участием интерфейса, находящегося в соседнем VLAN. Правда есть еще один вариант передачи BPDU, который позволил бы отслеживать ситуацию с VLAN соединенными, через нетегируемый порт, а именно - передавать BPDU всегда в тегируемом фрейме и игнорировать нетегируемые порты. На момент написания этой главы авторы еще не завершили исследование стандарта [4], так что описание используемой в большинстве устройств реализации "отдельного" STP дерева на каждый VLAN пока за рамками данного исследования и будет включено лишь через некоторое, надеемся, небольшое время
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
Хочется остановиться на особенностях функционирования STP в сложных сетях, а особенно -- гетерогенных сетях. Расчет последствий работы атаки в таких сетях становится особенно сложным. Возьмем в качестве примера сеть, построенную с применением Ethernet технологий и ATM LANE. На рисунке 5 изображена логическая структура сети, а на рисунке 6 - ее физическая структура. До тех пор, пока мы смотрим на физическую топологию, все кажется достаточно простым. Однако, после рассмотрения логики картина значительно усложняется. Дело в том, что распространение информации о VLAN может идти и внутри одного тегируемого Ethernet линка (trunk), и внутри ATM через LANE (LAN Emulation), а маршрутизатор может играть роль моста, если на нем включена поддержка BVI (Bridging Virtual Interface). Это, кстати, является основной причиной, по которой имеет смысл поддержка STP на маршрутизаторах. Вся эта "каша" управляется, в том числе, по STP, причем количество возможных колец может исчисляться десятками за счет колец, которые могли бы образовать различные логические сущности. Основная сложность состоит в том, что STP может "разрубить" кольцо в любом месте, расчет которого в случае с сетями подобной сложности может оказаться делом нетривиальным. Очевидно, что если сети разделяются через BVI, то есть немалые шансы, что STP-DoS может распространяться поверх ATM. В любом случае ATM соединения с использованием LANE могут прозрачно передать атаку через LANE, поскольку LANE -- это своего рода прозрачная инкапсуляция фреймов Ethernet в ячейки АТМ.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
Согласно RFC 2878: Поскольку RFC доступны в виде ASCII-текстов, их цитирование гораздо удобнее, чем IEEE-стандартов, распространяемых в формате pdf (см. раздел 20). В этом разделе цитаты из RFC 2878 в связи с большим их количеством будут просто браться в кавычки и выделяться в отдельный абзац, без специального упоминания о том, какой именно цитируется документ - достаточно одного раза.
Таким образом, для систем, использующих "Source Route Bridging", STP-атаки из удаленного сегмента во многих случаях не страшны. Внутри таких систем, соединенных WAN-линком, существуют независимые STP-деревья, так что максимум, чего мог бы добиться атакующий - опустить WAN-link, передавая STP пакеты от имени удаленного designated root. Однако даже это может оказаться невозможным - смысл в поддержке STP пакетов для линка между двумя различными STP-сущностями не очевиден. Из главы 4.1.4. [5] "Separation of Spanning Tree Domains" То есть, во-первых, администратор может разделить STP в связанных WAN линком сетях посредством выключения STP на обоих концах. Во-вторых, если подцепить несовместимый с STP свитч, то согласно этому RFC он должен уничтожать STP-пакеты. Причем, после прочтения этой главы остается такое впечатление, что по умолчанию STP ходит и его надо специально выключать, чтобы это поведение отменить. Видимо в этом месте авторы RFC забыли обратить внимание на то, что это относится не к "Source Route Bridging" (иначе получается противоречие), а к "Transparent Bridging". Стоит сказать пару слов об RFC 1638, в котором описан старый алгоритм работы протокола BCP и прочие подробности, в том числе пересмотренные в [5]. Основной смысл (с точки зрения тематики этой статьи) сводится к тому, что в старых версиях PPP BCP некоторые параметры не использовались, однако устройства, работающие по спецификации RFC 1638, также способны передавать STP-BPDU. С точки зрения STP атак не важно, какой RFC определяет их хождение - главное, что они ходят. Собственно, формат фреймов проходящих по PPP WAN линку определяется в [5] в главах 4.2 и 4.3, а немного ниже в [5], в главе 4.4, говорится, что для определения корректной топологии, состояния VLAN, регистрации участия в мультикастовых группах мосты (или свитчи, а с точки зрения этой статьи - просто некие устройства поддерживающие данные протоколы) обмениваются BPDU по спецификации STP, GVRP, GMRP (и вообще GARP): Ну, и, наконец, в следующем абзаце определяется самое главное в контексте STP-атак: С оговоркой, о совместимости со старыми устройствами, но тем не менее обязательной поддержкой этих протоколов, а значит и STP:
Резюмируем: в принципе PPP WAN линки могут служить переносчиками STP атак. Теперь о деталях. В BCP методика действий сходна с PPP LCP: LCP, грубо говоря, служит для определения того, какие потенциально возможные опции устанавливаемого линка будут применены в данном конкретном соединении. В PPP LCP используется система обмена запрос/ответ. Аналогичный подход и в BCP: То есть могут использоваться какие-то значения по умолчанию. Какие же? Давайте посмотрим - ниже будут замечания по этим значениям, а пока стоит взглянуть на главу 5.6 в [5]. Эта глава описывает поведение устройств при работе с STP. Первым же абзацем идет определение совместимости со старым форматом (RFC 1638):
Далее определяется возможное поведение системы, в случае, если на другом конце стоит устройство, работающее по RFC 1638, и при этом выбирается совместимый с ним алгоритм работы: Здесь стоит сделать следующий комментарий - согласно RFC 2878 Spanning Tree протоколов несколько, каждый из которых пронумерован согласно RFC 1700 [7]:
Очевидно, все эти протоколы имеют некие общие свойства, позволяющие называть их Spanning Tree протоколами, что, кстати, наталкивает на мысль, что все они могут быть подвержены, как минимум части описываемых здесь атак на Spanning Tree Protocol, пронумерованный в [7] как 1. Поскольку часть сказанного в данной статье относится к Spanning Tree алгоритму вообще, то слабость этих протоколов очевидна.
Приложение A в [5] содержит аналогичную таблицу для значений передаваемых в поле идентификатора STP протокола, согласно [7]:
Далее декларируется возможность PPP WAN линков работать сразу с несколькими типами STP: А вот еще одно важное замечание: если устройства на обоих концах не могут прийти к согласию по поводу того, какой STP протокол использовать, то выигрывает протокол с меньшим номером, то есть, IEEE реализация, если STP вообще поддерживается, конечно: Выделенное заглавными буквами весьма важно - если с обоих сторон поддерживается STP, то он должен обязательно быть использован. Далее сказано, что по умолчанию либо STP поддерживает хотя бы IEEE реализацию, либо не поддерживается вовсе: Теперь рассмотрим эту ситуацию в следующем теоретическом случае, очень близком к повсеместной практике. Допустим, мы имеем ISP с dialup доступом, построенном на маршрутизаторе доступа. Если этот маршрутизатор доступа поддерживает STP (например, многие модели Cisco), то, вероятно, PPP линки, которые организуются между ISP и его клиентом, будут поддерживать STP со стороны ISP. В нормальной ситуации PPP клиенты не запрашивают поддержку STP просто за ненадобностью, однако, если вместо обычного пользователя PPP соединение с провайдером установит вредитель, он, вероятно, сможет, модифицировав процедуру установления PPP соединения, реализовать часть STP-атак на сеть провайдера. Стоит заметить, что согласно главе 5.7 [5], по WAN линкам может также передаваться информация о VLAN (и прочих опциях определяемых тегированными фреймами 802.1q [4]). При этом определено, что если удаленное устройство не заявило о поддержке 802.1q, то тегированные фреймы не должны ему посылаться. Однако ситуация, при которой злоумышленник будет посылать со своей стороны такие фреймы не определена, что позволяет предположить различную реакцию со стороны устройств различных производителей:
Не следует забывать, что помимо PPP существуют еще и другие WAN-линки,
например, ADSL based, на которые есть свои стандарты. Они также могут
допускать свободное хождение STP по умолчанию - это дотошный читатель
может выяснить самостоятельно.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
Глава 8.3.2 в [1] содержит следующую фразу: "A MAC frame conveyng a BPDU". Это значит, что BPDU это пакет, а не фрейм. Таким образом, нет необходимости конструировать фреймы самостоятельно, поскольку они стандартны для данной физической среды - мы можем конструировать BPDU пакеты выше, чем самый нижний подуровень 2-го уровня OSI. Иначе говоря, можно отвязать программу конструктор BPDU от конструктора фреймов, оставив функцию инкапсуляции соответствующему драйверу. Однако, авторы выбрали для своих исследований создание программного модуля, конструирующего BPDU напрямую. Исходный текст модуля на языке C и сценарий на языке bash для более удобного манипулирования параметрами командной строки приведены в приложениях.
Чем хорошо создание фреймов напрямую:
Чем плохо создание фреймов, а не пакетов Spanning Tree:
Ethernet был выбран авторами из-за наибольшей распространенности, по сравнению со всеми остальными типами сетей. Помимо написания собственных программ есть возможность использовать готовые программные средства, обернув их в скрипты на любом подходящем языке, например, perl или языках shell - bash, zsh, ksh, csh (см. раздел 9), что значительно упрощает работу с параметрами Spanning Tree. Однако при этом появляется дополнительное условие - Linux с ядром, настроенным для поддержки bridging плюс соответствующий комплект утилит. Еще одним отрицательным моментом выбора такого пути будет необходимость накладывания патчей на исходный код Linux bridging project в случае, если потребуется сконструировать атаку с модификацией алгоритма работы, выходящей за рамки стандарта, например, изменить значения таймеров на меньшие или большие, чем описано в стандарте. Стоит также сказать несколько слов на тему особенностей программирования под разные операционные системы и выбора языка:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
Идея этих атак лежит на самой поверхности. Поразительно, что потратив 3 часа на поиски я так и не наткнулся на полное описание атак возможных при помощи протокола Spanning Tree - одни лишь намеки и частные случаи. Возможно из-за лени администраторов? :-) Для того чтобы устроить Отказ в Обслуживании можно воспользоваться тем, что STP-совместимые устройства в момент реконфигурации работают не на пользователя, а лишь на создание Spanning Tree дерева. Поскольку реконфигурация может быть вызвана, в том числе, появлением нового STP-совместимого устройства, можно имитировать периодически появление нового устройства с параметрами, которые будут лучше установившихся, что вызовет реконфигурацию (перевыборы) одного из выборных параметров. Некоторые (глупые) устройства будут пытаться пересматривать состояние всех портов при появлении любого нового устройства даже с худшими (с точки зрения выигрыша в выборах) чем у них параметрами. На более умное железо эта атака может действовать исключительно в случае появления устройства с лучшими (с точки зрения STP) параметрами - в худшем случае может пройти состояние реконфигурации только один порт. Однако даже такая ситуация будет противоречить спецификации протокола [1], в котором не предусмотрена ситуация переконфигурации устройства, к которому подключают другое с худшими (с точки зрения STP) параметрами. Поскольку предметом атаки могут быть любые "выборные" значения, мы можем выделить несколько типов атак по используемым методам их проведения:
Как будет показано ниже в разделе 6.4.5, случай 3) часто сопутствует случаю 2). Здесь и далее под "лучшим" понимается такое значение параметра, содержащегося в BPDU, которое позволяет добиться рассматриваемой цели. Чаще всего под "лучшим" будет пониматься такое значение параметра, которое обеспечит победу в STP-выборах. В качестве побочных эффектов STP-атак могут образовываться "пакетные штормы" внутри сети (в большинстве случаев - недолговременные). 6.1. BPDU spooffingЭта часть статьи была добавлена уже примерно на середине разработки. Как вы сможете заметить далее, эта методика нужна для части описываемых здесь алгоритмов и изначально мы обошли ее вниманием, считая, что в ней нет ничего такого, что могло бы его заслужить. Тема c общим названием "spoofing" разжевана во многих источниках настолько хорошо, что, казалось, ничего нового сказать нельзя. Однако в применении к STP и с учетом уровня OSI, на котором работает Spanning Tree, у этой методики есть несколько принципиальных особенностей. Говоря кратко, spooffing -- это подмена. Наиболее типична подмена адреса отправителя - случай, в котором потребуется подменить адрес получателя, придумать трудно, хотя и можно, к тому же, почти все они будут относится исключительно к локальному для данной машины стеку TCP/IP, за исключением разве что методик отлова недостаточно хорошо спрятанных promiscuous интерфейсов. Типичные способы борьбы с этой атакой в Internet заключаются в:
Особенностями STP, важными с точки зрения детального рассмотрения BPDU spooffing, является следующее:
Из 1 и 4 следует, что граничные условия фильтрации ложных пакетов к нему не применимы.
Из 2 следует, что фильтрация пакетов по пути неким STP-совместимым устройством не имеет смысла, поскольку путь STP-пакета не может содержать промежуточное STP устройство. 3 говорит сам за себя. 6 указывает на то, что подделка соединения не потребуется, а между тем она затрудняет, например, TCP/IP spooffing. Впрочем, введение требования установки соединения в данном случае поможетмало, поскольку нельзя ограничивать возможность установки такового. В результате ситуация с BPDU spooffing такова: при правильно поставленном BPDU-spooffing принципиально невозможно отличить "легальные" пакеты от поддельных. Под правильно поставленным BPDU-spooffing понимается подделка не только параметров STP пакета, но и адресов в MAC фрейме. При этом, благодаря 5, даже если не использовать собственно spoofing, можно все равно добиться интересных результатов. Играя с времяобразующими параметрами Max Age, forward delay, hello time в фальсифицированных C-BPDUs мы могли бы управлять, по крайней мере, близлежащими STP-устройствами посредством постоянной и очень быстрой посылки таких C-BPDU. Под "фальсифицированными bpdu" в данном случае понимаются c-bpdu с такими же параметрами, как у текущего designated bridge или designated root bridge, и с тем же, что и у него source MAC, но с другими значениями параметров, определяющих различные паузы в рамках протокола, что, правда, может вызвать один из случаев описанных в этой статье - переконфигурацию STP-дерева с последующим частичным DoS. Для того чтобы этого избежать фальсифицированные пакеты не должны вызывать реконфигурацию дерева. Этого можно добиться, выставив в них port id в большее значение (согласно протоколу при этом должен выключиться этот интерфейс), или же выставить худший path-cost - в этом случае STP выключит этот порт, но BPDU тем не менее он будет принимать. Однако само по себе это мало что дает - все, что мы получим, меняя эти параметры, это незначительная "дезориентация" ближайшего свитча и свитчей, который получают информацию от уже "обманутого" (те, что находятся ниже в STP-дереве). То есть максимум, что это может дать - увеличение времени жизни некорректной структуры дерева после того, как мы перестали передавать пакеты по этому атакующему алгоритму. В случае возникновения реальной STP-переконфигурации, возможны проблемы из-за появления data loops. По сравнению с уже затронутыми вариантами DoS это просто не серьезно. Однако использование Max Age может привести к тому, что DoS по одному из описанных выше алгоритмов будет функционировать дольше. 6.2. Provocation AgingТак же следует заметить, что возможна подделка вообще любых bpdu: не только configuration-bpdu (c-bpdu), но и notification bpdu (n-bpdu, tcn-bpdu). Например, согласно последнему абзацу главы 7.9.2 в [1], используя tcn-bpdu, можно реализовать еще одну атаку - "provocation aging" - управление величиной времени хранения информации о положении в сети MAC-адресов, динамически формируемой в процессе работы устройства. Согласно [1] стр. 45, таблица 7.4, величина Aging Time может быть сброшена не ранее, чем через 10 секунд.
Сама по себе эта атака малофункциональна, но, теоретически, может быть использована для других атак, при которых одним из требований является внесение ложных записей в таблицу коммутации в качестве катализатора, обеспечивающего повышение скорости срабатывания такой атаки. Возможно, использование этой методики для помощи в provocation sniffing (см. раздел 6.6) поможет дать боле-менее существенные результаты. Кроме того, эта атака может быть использована в случае поддержки STP-совместимым устройством расширений STP, например STP port fast (Cisco). Как будет показано, ниже в таких случаях aging time может быть сброшено до нулевой величины. В таком случае атака provocation aging станет синонимом provocation sniffing. Впрочем, об этом ниже. 6.3. BPDU filterОчевидно, что осуществить DoS в рамках одного коммутатора очень легко. Для этого необходимо организовать data-loop, который послужит причиной лавинного размножения и саморегенерации пакетов. Данная атака, разумеется, эффективна в пределах одного vlan, однако, она затронет и остальные за счет снижения производительности всего устройства. Это происходит из-за повышения накладных расходов на обработку постоянного большого паразитного трафика, объем которого может вырасти до суммарной пропускной способности образованных между устройствами линков. Идея этой атаки крайне проста: создается дополнительный link между двумя STP-совместимыми устройствами, в середину которого ставится фильтр BPDU, который просто "тупо" вырезает BPDU с любыми source & destination, не влияя на остальной траффик, либо, дополнительно создавая его. В силу своей неэлегантности, и в силу того, что для реализации обязательно требуется доступ к включенным портам хотя бы одного из коммутаторов этот метод авторы считают мало интересным с практической точки зрения. 6.4. Отказ в обслуживании (DoS)Авторы предполагают, что аудитория достаточно хорошо понимает сам термин. Если же этот термин не знаком, советуем отложить чтение этой статьи и внимательно прочесть [3], либо другую обзорную литературу содержащую необходимый теоретический минимум. Тем не менее, авторы приведут одно из многочисленных (неакадемических) определений DoS: Отказ в обслуживании -- это довольно распространенная атака. Однако до настоящего момента ее применение в основном ограничивалось глобальными сетями, а также локальными сетями, использующими протоколы глобальных сетей (наиболее распространены DoS-атаки связанные с реализацией или принципами работы стека протоколов TCP/IP). Если классифицировать атаки по протоколам, то история атак на уровнях выше 2-го OSI гораздо богаче. Этот документ добавит описание еще нескольких экземпляров в немногочисленную коллекцию атак, возможных на 2-м уровне OSI. С использованием STP возможны две схемы реализации DoS. 6.4.1. STP DoS: "вечные выборы" или постоянный перебор Наиболее эффективный метод: подождать появления STP пакета c текущим STP-root, затем по очереди перебирать значения bridge id, посылая bpdu с все меньшими значениями (id=id-1), до тех пор пока не будет достигнуто предельное значение, вызывая таким образом перевыборы designated root каждым посланным пакетом (для большей уверенности - посылать одинаковые c-bpdu несколько раз подряд). Когда же будет достигнуто минимально возможное значение - подождать, пока это значение не устареет из-за паузы, и начать сначала. С учетом того, что все параметры, включая время устаревания, устанавливаются в посылаемых назначенным корнем конфигурационных bpdu, можно получить ситуацию, при которой порты никогда не войдут в состояние "forwarding" пока происходит генерация фреймов, обеспечивающих отказ в обслуживании. Более того, в силу особенностей протокола состояние отказа в обслуживании будет продолжаться еще некоторое время, равное параметру Max Age, который можно выставить согласно стандарту до 40 секунд (см. [1], стр. 108, таблица 8.3).
Поскольку помимо 65535 возможных приоритетов bridge id включает в себя еще и MAC адрес,
то количество времени, которое потребуется чтобы перебрать все возможные значения весьма
велико и составит (в шестнадцатеричной системе cчисления):
Значение по умолчанию для ForwardDelay составляет 15 секунд и может доходить до 30. На самом деле при зацикливании алгоритма состояние DoS может продолжаться сколь угодно долго, пока посылаются пакеты с фальшивыми BPDU. При этом, как видите, вариаций алгоритма можно найти довольно много. 6.4.2. STP DoS: алгоритм "исчезновения корня" Начать посылку BPDU с минимально возможным bridge id, то есть с максимально возможным приоритетом, периодически переставая передавать конфигурационные bpdu, чтобы это наше значение назначенного корня устарело и так по кругу. На первый взгляд это не настолько эффективно, поскольку может существовать небольшой промежуток времени, когда сеть работает, тем не менее, в силу того, что ограничения, накладываемые спецификацией протокола, позволяют нам устанавливать время устаревания значений в очень широких пределах (см. раздел 6.4.7), этим методом можно достигнуть точно такой же эффективности. Более того, этот метод наиболее прост в реализации, поскольку не требует от нас ни знания текущего идентификатора назначенного корня, ни каких-либо предположений относительно его величины (в отличие от предыдущего случая). Следует заметить, что если в некоторой ЛВС текущий идентификатор designated root не является идентификатором наивысшего возможного приоритета (имеется ввиду нулевые и Bridge Priority и MAC address), то эта ЛВС, скорее всего, подвержена обоим типам DoS в полной мере. В случае же, если на одном из STP-совместимых устройств установлен bridge id равный 0, то DoS, тем не менее, может быть реализована, но только на части устройств, а именно на тех, к которым подключен атакующий. Дело в том, что ситуация, когда мы имеем два STP-совместимых устройства c одним и тем же bridge id может быть воспринята как кольцо, и STP отключит либо порт атакующего, либо другой порт, в зависимости от соотношения номера порта, на котором производится атака, и номера порта к которому подключена атакуемая часть сети (см. раздел 1). 6.4.3. STP DoS: алгоритм случайного совпадения Этот подраздел касается случаев сетей с использованием технологии port-based VLAN. В случае такой организации сети описанные до этого момента DoS атаки могут сработать исключительно в пределах одного VLAN. Однако и в этом случае злоумышленник может наделать неприятностей всей сети - дело в том, что, как рассматривалось выше, STP может выделяться в отдельное дерево посредством фильтрования по bridge ID.
Этот алгоритм назван алгоритмом случайного совпадения потому, что атакующему придется подбирать designated root bridge ID именно такой, который совпадет с имеющимся в соседнем VLAN. Разумеется наиболее точно эта атака воспроизводится в случае, если атакующий может получить dump работы сети за время порядка Hello Time (по умолчанию - 2 секунды). 6.4.4. STP DoS: другие возможные алгоритмы Возможны также произвольные комбинации вышеописанных методик. Например, можно сделать вариант 2 не с максимально весомым bridge identifier, а просто с текущим designated root +1 и периодически его анонсировать, по мере устаревания. Однако вариации на тему пройденного, разумеется не представляют интереса, поэтому в дополнение к сказанному отдельно следует рассмотреть атаки, которые могут произвести отказ обслуживания в пределах некоторого сегмента ЛВС, тем самым создав ситуацию "частичного отказа в обслуживании". 6.4.5. STP DoS: частичный отказ в обслуживании В случае, если атакующему каким-то образом, стало известно значение bridge identifier одного или более устройств в ЛВС, он может вызвать выборы designated bridge для того или иного участка ЛВС, послав соответствующее c-bpdu для оспаривания статуса назначенного моста для соответствующего сегмента ЛВС. Воздействуя исключительно на ближайшее к атакующему устройство, он может объявить себя лучшим возможным путем к соседнему с ним устройству, например, заявив, что его порт является самым дешевым по стоимости путем к нему, в результате чего "более дорогой" порт будет переведен в состояние Blocking, а поскольку реальной связи нет, все оконечные устройства, подключенные к атакованному устройству, потеряют возможность работать с отключенным сегментом ЛВС.
В описанном на рисунке 7 случае в примере B), псевдо-бридж-система атакующего, анонсируя лучшие параметры, выиграла выборы назначенного моста (designated bridge), не являясь таковым. Одновременно порт, к которому подключен атакующий, стал назначенным портом для атакуемой части сети (статус перешел от порта перешедшего в состояние Blocking). Следует отметить, что при переходе статуса назначенного моста для сегмента в результате STP атаки, в случае, если оспаривавшие этот статус устройства были подключены к разным портам, изменяется и назначенный порт. С точки зрения пользователя сети сегмент "Victim LAN" перестает "видеть" остальную сеть (все, что подключено через Bridge 1), при этом атакующий (attacker) продолжает видеть все сегменты сети, кроме сегмента "Victim LAN". Объектом атаки является "Bridge 1", которому посылаются BPDU от имени "Bridge 2", но с "лучшими" (с точки зрения выигрыша STP-выборов) параметрами.
Пример A) отличается от B) тем, что будучи подключенным к тому же порту "Bridge 1" атакующий (attacker) также, как и жертва ("Victim LAN") перестает "видеть" остальную сеть. Объектом атаки является "Bridge 1", которому возвращаются BPDU, полученные от него же и измененные так, чтобы сэмулировать закольцовывание между этим и другим интерфейсом. При этом параметры таких BPDU должны быть подобраны именно так, чтобы выключился именно этот, а не соседний интерфейс. Вариант A) может быть также реализован в случае если атакующий (attacker) подключен не к "Bridge 1" через концентратор, а к "Bridge 2" - в этом случае объектом атаки будет "Bridge 1", которому для реализации частичной DoS по этой схеме необходимо присылать BPDU от имени "Bridge 1" с параметрами "лучшими", чем имеющееся подключение между "Bridge 1" и "Bridge 2". Собственно, по этой схеме можно добиться DoS для любого порта на том же STP-совместимом устройстве. Эти схемы проиллюстрированы рисунком 8. При разумном подборе параметров BPDU это становится возможным также и для портов на соседних STP-совместимых устройствах.
Более типичной будет схема показанная на рисунке 9. В реальных условиях у злоумышленника редко есть возможность расцепить линк между коммутаторами, "врезать" туда концентратор и вставлять в поток свои пакеты. Скорее возможен такой сценарий: сервера включены в один коммутатор, клиенты включены в концентраторы, подсоединенные к одному или нескольким коммутаторам. По аналогии атаки Митника на Шимомуру, атакующему надо "выключить" одного из участников соединения, а именно, сервер. Для этого он должен убедить коммутатор, к которому подключен концентратор с интересующим его клиентом, что он имеет лучший путь до второго коммутатора, к которому подключен сервер. В результате, линк между коммутаторами рвется, и атакующий может прикидываться сервером или просто злорадствовать от факта недоступности сервера клиенту (см. рис. 9). Разумеется, концентратор здесь не принципиален, хотя можно строить атаку, подобную этой, на всю сеть, не задумываясь над подсчетом величин для данного сегмента сети. Если конечной целью является компьютер, подключенный к концентратору - он не "упадет" от этой атаки, ибо слишком "глуп".
Рисунок 8, часть а), обращает внимание на следующую особенность: если считать, что нумерация портов идет слева направо, то атакующий, пытаясь устроить частичный DoS для линка между коммутаторами, может сделать его исключительно себе, если не подобрать параметры специальным образом. Дело в том, что, при прочих равных условиях, включенным останется порт с меньшим ID. Поэтому атакующий должен подобрать для фальсификации такой номер порта соседнего коммутатора, который заставит коммутатор "Bridge 2" выключить именно необходимый атакующему линк, а не тот, с которого идет атака. Для случая же с одним единственным STP-совместимым устройством (рис. 8, часть b)) атака легко реализуема для всех LAN, подключенных к портам, большим по номеру. Однако при попытке реализовать ее по отношению к первому порту ничего не выйдет: получив BPDU на большем по номеру порту от имени порта c меньшим номером, устройство выключит порт с большим номером. Изменяя Max Age, forward delay, hello time в ложных c-bpdu, мы можем управлять как минимум ближайшими коммутаторами, изменяя их представление о топологии сети, а также (что принципиально при организации частичной DoS) - изменять тайм-ауты протокола, что позволяет нам выставить конфликтующие с остальной сетью значения. Следует заметить, что в силу таймаутов реконфигурации в рамках протокола и того, что в момент реконфигурации пользовательские фреймы не передаются, применение данной методики для временного получения пакетов (например, части пакетов используемых при установлении соединения с помощью протоколов верхних уровней, например, IP) нецелесообразно, поскольку в момента изменения топологии эти пакеты блокируются.
Предметом атаки может быть маршрут между любыми двумя STP-совместимыми устройствами сети. Следует также отметить, что при организации части описываемых здесь атак придется угадывать bridge ID части устройств, однако эта задача зачастую облегчается возможностью получить часть идентификатора или диапазон возможных значений косвенным образом - через протоколы более высокого уровня (например, используя стек TCP/IP, можно получить MAC коммутатора, пропинговав его и посмотрев arp таблицу), используя таблицы зарезервированных за тем или иным производителем диапазонов MAC адресов и др. Имея один из MAC адресов многопортового активного устройства, легко вычислить остальные, поскольку производители обычно присваивают MAC адреса портам подряд, а их изменение, даже если оно доступно администратору, практически не требуется для типичных задач администрирования. Важно заметить, что реализация частичной DoS не требует использования перевыборов STP-root - достаточно перевыборов designated bridge, что, как следствие, позволяет, при определенных условиях, провести эту атаку незаметно для всей остальной сети.
6.4.6. STP DoS: величины, которые должны быть установлены в STP пакетах, организующих DoS Глава 8.6 (конкретнее, раздел 8.6.1.3) в [1] содержит подробное описание всех параметров BDPU. Разумеется, в зависимости от алгоритма атаки величины используются разные. Для DoS атаки посредством постоянной инициации выборов STP root bridge важны следующие параметры. Root bridge устанваливает следующие значения:
Message Age надо устанавливать минимально возможным, так, чтобы пакет считался молодым. В любом случае этот параметр должен быть намного меньше Max-age. Впрочем установка этого параметра также зависит от выбранного алгоритма. Как и Message Age, Max Age надо устанавливать в зависимости от выбранного алгоритма. Так, для атак, в которых важно максимально долго сохранить навязанную структуру STP дерева, Max Age должен быть установлен в максимум, 40 секунд (см. [1], стр. 108, таблица 8.3), а для тех случаев, когда необходимо инициировать как можно больше перевыборов - минимальным, т.е. 6 секунд. Bridge ID должен устанавливаться в соответствии с алгоритмом из раздела 6. Выборы выигрывают меньшие значения. Port ID - в определенных случаях участвует в выборах, поэтому должно быть выбрано значение с максимальным приоритетом - 0. 6.4.7. STP DoS: наиболее эффективные величины пауз при организации отказа в обслуживании Max Age ([1], 8.5.1.6, стр. 68; [1], 8.5.3.4, стр. 69) - должен быть максимально возможным. Forward Delay ([1], 8.5.1.8) - должен быть максимально возможным (чтобы максимально затормозить переключение в forwarding state). Время которое порт не передает фреймы t = 2*foward delay (определяется [1], 8.7.5, шаг 2) ). Hello Time ([1], 8.5.3.5) - должен быть минимальным. Bridge ID - рассматривается в другой главе. На страницах 108 и 109 в [1] приведены таблицы значений, в том числе значений таймеров. Для максимально эффективной DoS нужно, чтобы 2*Forward_Delay>Max_Age. Выбирая разрешенные стандартом значения из таблицы 8-3 из [1], 8.10.2, стр.107 видим, что неравенство 2*30>40 выполняется с хорошим запасом.
Определенные значения из таблиц интересны только при отдельных типах атаки, например, path cost имеет смысл устанавливать только при нежелании оспаривать статус "designated root". 6.5. Навязывание ложного маршрута (человек посередине), или "перетяни кольцо на себя".Как уже упоминалось, в силу того, что топология сети определяется при участии протокола STP, возможна атака по схеме "ложный объект РВС с навязыванием ложного пути" (в терминологии [3]), известная по англоязычным публикациям как MitM (Man-in-the-Middle). Однако реализовать такую атаку можно только при определенных условиях конфигурации сети, а именно в тех случаях, когда жертвы, трафик между которыми надо перехватить (то есть, направить по каналу, который можно прослушивать), находятся в сети с двумя (как минимум) STP-совместимыми коммутаторами и подключены к разным коммутаторам. Причем, для реализации атаки в полной мере требуется два сетевых интерфейса, подключение которых необходимо осуществить так, чтобы образовать потенциальный дубликат имеющегося пути между источниками.
Рассмотрим рис. 10. На нем изображена сложная сеть, построенная на интеллектуальных коммутаторах (bridge), поддерживающих протокол STP. Сеть показана в "устоявшемся" состоянии, т.е. формирование топологии завершено, резервные линки переведены в состояние "blocking". В задачу злоумышленника входит осуществить перехват трафика между устройствами, подключенными к коммутаторам Bridge2 и Bridge8 (на рисунке изображены как Workstation1 и Workstation2). Результатом атаки будет перевод имеющихся соединений между Bridge1 и Bridge2 в состояние "blocking" (на рисунке отмечено крестиком) и перенаправление всего трафика между этими коммутаторами (а значит, и трафика между обеими точками, траффик которых атакующему необходимо подслушать) на интерфейсы атакующего. В принципе, задача определения мест включения в сеть, при которых будет возможна атака STP-MitM, должна поддаваться описанию через теорию графов. Для того, чтобы получить именно MitM, а не DoS, атакующий хост должен поддерживать работу обоих своих интерфейсов в режиме моста, что легко реализуемо, поскольку существует несколько свободно распространяемых (в том числе по GNU GPL лицензии) реализаций bridging'а, например, для Linux. Заметим, что для этого даже не требуется поддержка STP ОС, работающей как мост. Более того, такая полнофункциональная поддержка только повредит, поскольку принцип MitM атаки при использовании двух сетевых интерфейсов базируется на том, что атакующий может посылать BPDU пакеты от чужого имени (например, в Bridge1 от имени Bridge2) чтобы представить себя как наилучший путь хождения пакетов. При такой логике атаки полноценная поддержка STP только помешает атакующему, поэтому для реализации MitM по схеме на рис. 10 необходимо отключать поддержку Spanning Tree, либо использовать OS+software, в которых нет поддержки STP, например, реализовать bridge на OpenBSD, либо модифицировать исходный код поддержки STP в данной OS. Таким образом, машина, реализующая MitM, на самом деле не нуждается в полноценной поддержке bridging'а, а может функционировать на манер концентратора, с единственным исключением - транзитный STP-траффик должен отбрасываться и вместо него генерироваться собственный, анонсирующий себя как наиболее выгодный путь для пакетов. Хочется акцентировать внимание читателя на том, что на самом деле эта атака более общего свойства и предметом атаки может быть маршрут между любыми двумя STP-совместимыми устройствами сети (см. раздел 6.4.5). Простота этого протокола делает возможной достаточно дешевую реализацию описываемой атаки "в железе" - за менее чем 5-10 тысяч долларов (в основном на оплату интеллектуального труда разработчиков) за срок порядка полугода возможно построить достаточно универсальный, если требуется и программируемый, "деструктор" сети или же реализовать "в железе" вариант MitM-атаки, описываемой в этом разделе.
К сожалению такие разработки могут заинтересовать разве что военных, а тратить на разработку экспериментального образца собственные деньги авторы не считают возможным.
Требование наличия как минимум двух коммутаторов связано с тем, что в случае подключения к одному коммутатору анонсирование себя, как лучшего пути создаст тупиковый путь, то есть это случай, относящийся к разделу 6.4.5. К тому же для этого случая гораздо проще воспользоваться arp-poisoning. Важно заметить, что все так однозначно и просто только в случае, если атакующий подключен к соседним коммутаторам. В случае же, если он подключен к коммутаторам непосредственно не соединенным, придется подбирать значения root id, возможно последовательным перебором, поскольку bpdu не ходят (в неизменном виде) дальше первого встреченного STP-совместимого устройства. Поэтому такая атака кажется не слишком часто применимой. Помимо этого у данной атаки есть еще одно неудобство - в случае реализации данной атаки на обычной персоналке, сразу же упадет пропускная способность сети между точками, соединенными через интерфейсы атакующего, за счет переноса соединения на более медленные сетевые интерфейсы ПК. В принципе, злоумышленнику не обязательно иметь подключение к коммутаторам являющимся частью разорванного STP-кольца - он может "растянуть" кольцо на себя, если в сети есть другие дублируемые соединения. Просто в случае подключения к коммутаторам, образующим кольцо, задачу организации MitM решить легче. Описанная атака работает не на всех конфигурациях. Однако в случае, когда злоумышленник захватил контроль над компьютером, который по какой-либо причине подключен к двум или более коммутаторам различными интерфейсами - он имеет возможность ее реализовать. 6.5.1. Заметки по конструированию пакетов для реализации атаки Man in the Middle В общем случае величины используемые при конструировании пакетов, должны зависеть от параметров, полученных от устройств, в которые включен атакующий, либо могут подбираться, что может вызвать частичный/временный DoS. Отправной точкой к значениям, используемым в этой атаке, являются величины, используемые при выборах и анонсируемые точками подключения MitM-члена сети. В частном случае, чтобы выиграть выборы designated root для данного сегмента ЛВС, будет достаточно подстановки меньшего значения PathCost (при прочих равных условиях). Однозначно не стоит трогать глобальные параметры, поскольку они чреваты DoS всей сети. 6.6. Провокационный сниффингПровокационный сниффинг получил свое название по аналогии с провокационным спуфингом. На момент написания статьи авторам не встречалось описания аналогичных методик в области сниффинга. Идея провокационного сниффинга возникает после внимательного прочтения стандарта [1], а точнее той его части, которая описывает поведение STP-совместимого устройства в случае изменения STP-дерева (например, сразу после перевыборов Designated Bridge). Дело в том, что после такого события, согласно стандарту, коммутатор должен обнулить свою таблицу коммутации (кроме статически заданных администратором значений), а в случае нулевой таблицы коммутации коммутатор (первое время, до того, как запомнит на каком порту какой MAC) начинает вести себя как концентратор. 6.6.1. Что такое провокационный сниффинг Провокационный сниффинг -- это алгоритм атаки, который может быть использован при определенных настройках активного сетевого оборудования для "отупления" этого оборудования с целью подслушивания трафика, проходящего через его порты. Грубо говоря посредством провокационного сниффинга коммутатор превращается в концентратор посредством "провокации" - фальсификации события "произошло изменение топологии сети", после которого все динамические записи в таблице коммутации очищаются. Однако использование такой провокации с толком возможно только при одном условии: коммутатор не должен успеть обучиться. Под "обучением" в данном случае понимается формирование таблицы соответствия портов и MAC адресов подключенных к ним устройств. Поскольку обучение коммутатора происходит практически сразу же по получении им пакета (фрейма) от подключенного устройства, реализация полноценного сниффинга становится нетривиальной задачей, сложность которой пропорциональна скорости трафика в данной сети. Отсюда следует, что существуют условия при которых эта атака в принципе не реализуема в полном объеме. Например, если трафик между станциями, обмен которых необходимо "подслушать" (станциями "жертвами"), использует более 49% полосы пропускания. Для 100% эффективности данная атака предполагает бомбардировку "отупляемого" коммутатора STP пакетами хотя бы вдвое чаще, чем проходят пакеты между жертвами, для того, чтобы каждый новый принятый пакет приходил на коммутатор с только что очищенной таблицей коммутации. C учетом того, что от порта коммутатора начинается коллизионный домен, полноценный сниффинг кажется еще более затрудненным, что, правда, не касается full-duplex портов. Для полноценного сниффинга без потери пакетов за счет обучения коммутатора суммарный траффик, проходящий через коммутатор в единицу времени, не должен превышать 48-49% пропускной способности канала атакующего. Такая атака в нормальных условиях, следуя букве стандарта, не реализуема, поскольку сброс таблицы коммутации не осуществляется мгновенно по приходу C-BPDU с отличной от текущей конфигурацией. Однако многие устройства поддерживают расширения стандарта, в которые заложена возможность мгновенного перехода из blocking в forwarding. Как следствие, время жизни таблицы коммутации в таких устройствах в случае возникновения изменений топологии можно сбросить в 0. В этом случае, необходимо подобрать такие условия работы устройства, чтобы оно, не прерывая работы (т.е. без DoS), тем не менее постоянно сбрасывало свою таблицу коммутации. Как и MitM-атака, атака provocation sniffing может быть использована, например, для получения доступа к управлению STP-совместимым устройством. Многие устройства, работающие преимущественно на 2-м уровне модели OSI, не поддерживают терминального доступа иначе, чем при помощи telnet, а пароли к сессии, открытой по этому протоколу передаются, как известно, в открытом виде. Помимо этого, атаки на втором уровне OSI могут служить подготовкой к атакам на более высоких уровнях. Например, имея возможность "слушать" трафик, можно эффективно угадывать sequence numbers для "вклинивания" в tcp-соединения. 6.6.2. Использование STP-выборов для реализации провокационного сниффинга Основная сложность в случае стандартной поддержки STP заключается в том, что необходимо выбрать такой алгоритм, при котором постоянно происходят перевыборы чего либо "неважного". В такой ситуации помочь могут перевыборы, например, designated bridge или designated port для данного сегмента сети, что позволяет не вызвать DoS для сети и, в частности, для сегментов ЛВС, подключенных к данному коммутатору. В случае если при проведении STP-перевыборов в одном из сегментов остальные продолжают работать -- это удача. Задача атакующего облегчается, если коммутатор поддерживает расширенную спецификацию STP, а именно аналог cisco "spanning-tree portfast". В этом случае, по крайней мере, не будет пауз в процессе передачи фреймов "Frame Relaying" (см. определение Relayng Entity в [1] 7.2.2) даже при затрагивании более существенных параметров, чем designated port или bridge. Помимо этого условия важно избрать для оспаривания такую выборную величину, выборы которой не вызовут перехода в состояние Blocked порта, с которого производится атака. В процессе перевыборов можно играть практически всеми выборными параметрами STP, но так, чтобы не занять статус designated root, поскольку, если коммутаторов более двух, то, проводя перевыборы корня, мы автоматически затрагиваем все коммутаторы, а это может вызвать DoS, если на остальных коммутаторах не включена поддержка "spanning-tree portfast". В простейшем случае, если у нас есть всего один свитч, на котором установлено "STP portfast", мы можем смело устраивать перевыборы корня дерева по наиболее агрессивному из DoS алгоритмов, причем стараясь послать как можно больше пакетов, поскольку перевыборы должны стартовать чаще прихода пакетов от клиента, которого надо "прослушать", на коммутаторе. Следует также иметь ввиду, что в следствие того, что STP BPDU не проходят сквозь STP-совместимые устройства, а лишь вызывают посылку собственных, невозможно будет добиться полного "охабливания" всех коммутаторов, а не только ближайшего. В отличие от атакующей машины, коммутатор связан стандартами и, скорее всего, не будет посылать собственные BPDU чаще, чем через минимально возможный таймаут, определенный стандартом, поэтому часть коммутаторов успеет за время паузы "обучиться", пусть и частично. Впрочем, можно чередовать эту атаку с атаками provocation spooffing и Man in the Middle, что позволит при грамотном подборе параметров получить больше информации, чем при чистой "provocation sniffing" атаке. В процессе изучения стандарта мы обратили внимание на то, что возможна также реализация provocation sniffing исключительно на C-BPDU, не вызывающих перевыборы. Такую атаку (без перевыборов) можно реализовать, используя особенность, определенную в [1] 8.3.5, "Notifying topology changes", в части, описывающей поведение моста по получении C-BPDU с установленным "topology change flag". Здесь имеет смысл вспомнить как работает сам алгоритм ST: когда топология сети меняется, мосты нуждаются в информации об этом чтобы переобучиться. Единственный доступный механизм быстрого переобучения - сброс информации о MAC адресах в таблице коммутации и ее повторное построение (Learning). Стандарт определяет следующую последовательность действий: обнаружив изменения в сети, некий мост передает TCN-BPDU в сторону designated root устройства до тех пор, пока не получит подтверждения от "designated bridge" для этой сети посредством С-BPDU. Соответствующий TCN-BPDU генерируется designated bridge этой сети и передается дальше в сторону корневого устройства. Когда корневое устройство (designated root) получает TCN-BPDU, генерация им C-BPDU изменяется, и в течении времени определяемого Topology Change Timer ([1], 8.5.3.13), они содержат флаг "topology change" установленным. По получении C-BPDU с установленным флагом topology change, мост обязан временно сбросить время жизни MAC адресов в таблице коммутации на минимум, равный значению Forward Delay. В случае использования расширений STP, позволяющих сразу перейти из состояния blocking в Forwarding и наоборот, параметр Forward Delay, очевидно, равен 0, что, при наличии C-BPDU flood заставит коммутатор вести себя как концентратор, если конечно он не переконфигурирован специальным образом. Данная атака не действенна в случае, если MAC-адреса станцийы прописан на коммутаторе администратором, поскольку, согласно стандарту [1] (глава 8.3.5), Aging Time можно сбросить только для записей, набираемых динамически в процессе самообучения коммутатора. Впрочем, и здесь есть ограничения - посылка C-BPDU вызовет хотя бы разовые выборы того или иного параметра, однако, в этом случае, если возможности послать C-BPDU от имени "верхнего к данному" коммутатора (обязательно через тот же порт) нет, то DoS для части сети практически неизбежен. Этого можно избежать, если образовать дополнительную петлю и скомбинировать эту атаку с методом, описанным в разделе 6.5, но уже во избежание DoS, чтобы заменить собой designated bridge для этой сети. Для того, чтобы иметь возможность произвести атаку без последовательных перевыборов, надо подделать "keep-alive" C-BPDU, которые распространяет designated bridge этого сегмента сети (то есть тот, который ближе к designated root, чем атакуемый), что возможно без DoS не во всех случаях. Кстати, согласно той же главе [1] восприимчивость к topology changes может быть выключена администратором. В то же время, согласно стандарту [1] (8.5.5.10), реакция на TCN-BPDU и C-BPDU с установленным флагом topology change должна быть включена и возможность выключения этой способности не обязательна. Для полноты картины имеет смысл прочитать главы 8.6.14 и 8.6.15 из [1]. Кроме того, на возможность реализации данной атаки может влиять поддержка свитчем и включение администратором таких дополнений к IEEE STP, как аналоги Cisco "BPDU Guard" и "BPDU root guard". Об этом будет рассказано ниже в разделе 8. 6.6.3. Сравнение arp-poisoning и provocation sniffing Существенной разницей между arp-poisoning и провокационным сниффингом является то, что arp-poisoning позволяет перехватывать трафик только между определенными узлами, работающими по IP, provocation sniffing же позволяет перевести коммутаторы в режим концентратора, в результате можно перехватить весь трафик, всех узлов, по всем протоколам (включая ipx, netbeui и т.п.), как 3го и выше, так и второго уровня OSI.
6.6.4. Комментарии к написанию кода для provocation sniffing Прежде всего, чтобы коммутатор не успевал обучиться "надолго" его нужно постоянно бомбардировать C-BPDU с установленным topology change flag, по приходу которых Max Age динамических записей в таблице коммутации становится минимально возможным (около 4 секунд). Разумеется, это полезно для атакующего, поскольку часть пакетов в результате будет распространена во все порты из-за устаревания информации о нахождении MAC-адреса, которому данный пакет предназначен. И это без всяких перевыборов и при выключенном "spanning-tree portfast"!
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
Помимо описанных выше фундаментальных атак на топологию сети
существует еще одна - не страшная, но тоже неприятная особенность:
благодаря STP возможно получение дополнительных данных о структуре
сети. При этом такое получение дополнительных знаний может быть как
пассивным (прослушивание среды передачи данных), так и активным -
выиграв на короткое время статус STP корня мы автоматически
становимся целью отправки STP TCN-BPDU (см. раздел
1), которые сами по себе несут некоторый объем
познавательной информации. Например, проанализировав source MAC
адрес, можно понять устройство какой фирмы отправило этот пакет, а
это тоже атака, хоть и пассивная (см. [3]).
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
Здесь и далее уделяется внимание поддержке LAG'ов - Link Aggregation Group - одного из вариантов, который, в некоторых случаях, может стать приемлемой заменой STP. 8.1. CiscoДовольно "продвинутые" возможности настройки. Часть может быть использована для защиты от DoS атак. Поддерживается фильтрация STP для эмуляции раздельного STP-дерева на каждый vlan. Эта фирма не зря занимает лидирующие позиции на мировом рынке, однако это не мешает следующим недостаткам: STP во всех устройствах его поддерживающих по умолчанию включен. Имеющиеся наработки на самом деле, скорее всего, не предназначались для защиты от атак. Нет возможности выключить STP на отдельном порту. Очевидным необходимым правилом для устойчивой к DoS настройке каждого порта будет следование следующему примеру (взято из конфигурации cisco 2924XL): ------------cut------------- interface FastEthernet0/2 description Any Port Sample spanning-tree portfast ------------cut------------- Также заслуживают внимания следующие возможности IOS: BPDU Guard В общих чертах эта "фича" позволяет отключить порт, когда на нем появляется устройство, мнящее себя designated root. Предназначено для запрета изменения конфигурации STP Tree без ведома администратора. Спасает только от атаки, включающей фазу перевыборов designated root. Перевыборы же Designated Bridge для некоторого сегмента LAN не отслеживает (в общем случае сложно отличить атаку от нормальной работы, иногда невозможно, см. раздел 15.1). В рамках тематики данной статьи, как и spanning-tree portfast, считаем очень полезной. Поддерживаются LAGи. 8.2. Avaya (бывш. Lucent)В серии коммутаторов cajun (cajun P120, P330(R), P220, P550(R), P880) заявлена поддержка 802.1d, причем на моделях P550/P880 заявлена поддержка ST per VLAN, при этом в учебнике курса "Cajun Campus Training" отдельно отмечено, что поддержка ST per vlan не совместима с реализацией ST у других производителей. Интересно чем? :) Однако далее пишется, что не смотря на эту "несовместимость" P550/P880 все-таки работают с 802.1d и 802.1q устройствами других производителей. :) Чудеса в решете. ;) Впрочем, поддержку STP в Avaya стоит рассмотреть отдельно. Наиболее слабые модели (P120 и ей подобные) поддерживают STP только в рамках спецификации 802.1d, более "продвинутые" (P330 и выше) поддерживают не только спецификацию STP из 802.1d, но и из 802.1q и, самые продвинутые (серии P580 & P882) поддерживают еще одну реализацию Spaning Tree, разработанную avaya, и имеющуюся только на их оборудовании - "Spaning Tree Dual Layer". Грубо говоря, это STP 802.1q + STP 802.1d, одновременно связанные так, что STP-деревья, работающие по алгоритму 802.1d терминируются на тех портах, к которым подключены устройства, не поддерживающие 802.1q. Вообще, у avaya очень большое внимание уделяется поддержке гетерогенных, с точки зрения наличия оборудования разных поставщикови просто возможностей тех или иных "железок", сетей, особенно в моделях 580/582. Собственно Spaning Tree Dual Layer предназначена именно для случая, когда часть коммутаторов не поддерживает STP per VLAN, а выбрасывать их не с руки. Spaning Tree Dual Layer организовано таким образом, что внутренности P580/P882 отслеживают возможные проблемы с STP, работающем по обоим стандартам. Хотя STP Dual Layer является закрытым алгоритмом, который до сих пор (Nov 29 2001) не опубликован avaya, это не освобождает его от всех принципиальных уязвимостей, свойственных STP алгоритму. Наоборот, в силу усложнения протокола без отхода от его принципов, количество потенциальных уязвимостей может быть больше. Также важно, что, начиная с версии ПО 3.2.8, функционирование STP можно отключить на любом порту. Это очень удобно: если вам необходимо предоставлять подключение клиенту поверх LAN, и вы уверены, что STP-колец образоваться не может, то вы можете выключить поддержку STP на границах вашей части LAN и не боятся каких-либо STP-атак извне, по-прежнему пользуясь преимуществами STP внутри доверенной среды своей организации. В общем, не смотря на то, что, например, настроек вроде cisco "bpdu guard" у них нет, Avaya производит в этом отношении довольно приятное впечатление. Поддерживаются LAGи. 8.3. IntelПоскольку, в отличие от cisco и avaya, продукция других компаний знакома авторам, в основном, по документации, далее будет идти речь о конкретных моделях (что не отменяет ни одного слова, сказанного о глобальной уязвимости протокола и не делает устройства других компаний менее уязвимыми).Модель 460T поддерживает STP, однако не поддерживает STP-фильтров для эмуляции отдельного ST-дерева на vlan, что является очевидным минусом и упрощает STP-атаки, не говоря уже просто о неудобствах для обыденной работы администратора сети. Поддерживаются LAGи. 8.4. HPМодели HP212M/214M приятно удивили своей резистивностью к STP атакам в конфигурации с настройками по умолчанию - STP disabled. Но на этом приятные сюрпризы закончились - по факту включения STP, коммутатор становится точно так же уязвим, как и все остальные. К тому же он не поддерживает VLAN. Впрочем, низкая стоимость этих моделей подразумевает это.
8.5. 3ComSTP поддерживают многие, если не все, интеллектуальные модели. Далее речь о коммутаторах 3Com SuperStack и им подобных. Ниже приводится выжимка из документации, доступной по url 5 в разделе 20.1 Коммутатор имеет полностью раздельные системы STP для каждого специфицированного вами VLAN. Каждый VLAN имеет свои Root Bridge, Root Ports и BPDU.
В числе параметров STP в этих моделях 3COM доступны для просмотра следующие:
8.5.1. Установка параметров STP для порта Состояния портов (read only):
ВНИМАНИЕ! Если вы поставите порту Fast Start Enable, когда к нему присоединено несколько конечных станций, в сети могут появиться петли.
Как видно из этих выжимок из документации обсуждаемая модель 3COM
поддерживает аналог cisco "spanning-tree portfast", что важно в контексте
этой статьи.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ядро linux имеет поддержку бриджинга (см. раздел 20.2). На
сайте Linux bridging project есть утилиты для управления параметрами
бриджа. В качестве одного из вариантов конструирования атак,
обсуждаемых в этой статье, можно просто сделать скриптик, который
будет вызывать эти утилиты с параметрами "понизить bridge id"
(т.е. стать designated root) и периодически менять различные
параметры, например max age и т.п. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
GARP - Generic Attribute Registration Protocol. Протокол используемый для
регистрации некоторых абстрактных свойств в рамках сети. Чем так интересен
GARP? Тем, что STP это частный случай GARP, а значит сам по себе GARP стоит
рассмотреть на предмет потенциальных дыр. GVRP -- Generic VLAN Registration
Protocol -- протокол регистрации информации о VLAN. Позволяет разделять
информацию о VLAN между мостами и производить администрирование
распространения VLAN. Чем так интересен GVRP? Также, как и STP, является
частным случаем GARP, а значит его стоит проверить на предмет потенциальных
дыр. По крайней мере полное отсутствие механизмов обеспечения безопасности в
STP наводит на мысль, что и с GARP вообще и с GVRP в частности ситуация будет
весьма похожей. =)
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
В этом разделе сделаны краткие заметки о других возможных типах атак на 2-м уровне OSI.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
Устройства и комплектующие. Все устройства полностью совместимые с спецификацией Spanning Tree протокола [1] определенной в комитете стандартизации IEEE, или, другими словами, почти все интеллектуальное оборудование, обслуживающее локальные вычислительные сети и часть оборудования, используемого для создания WAN соединений. Это включает большинство достаточно интеллектуальных коммутаторов и некоторые маршрутизаторы. Не затронутыми данным типом атак будут все "глупые" устройства, например, концентраторы, поскольку они настолько глупы, что не поддерживают спецификацию ST в [1]. Частично ситуация решается в устройствах, имеющих аналоги cisco BPDU-guard и BPDU-root-guard. Тем не менее, по умолчанию такие устройства также уязвимы, поскольку поддержка STP в них также включена по умолчанию, расширения STP выключены, а кроме того включение их никак не помогло бы покупателям этих устройств, поскольку настройка защиты от STP-атак требует знания топологии сети, и, самое главное, защититься можно отнюдь не от всех перечисленных атак. Неполный список компаний, производящих так или иначе подверженные STP-атакам устройства включает: Cisco, Avaya(Lucent), 3Com, Intel, HP, Cabletron Systems и так далее - любой производитель, производящий интеллектуальные устройства с поддержкой спецификации [1] может "похвастаться" "дырявостью" этого оборудования. Особенно забавно читать слово secure в названии SFPS от Cabletron Systems в рекламном обзоре Ethernet Switching Bridge Media Interface Module от 1994 года - эта аббревиатура расшифровывается как "SecureFast Packet switching" - на первой же странице красуется поддержка 802.1d - security на небывалой высоте. :) Неважно, кто сделал то или иное STP-совместимое устройство - все они, поддерживая спецификацию Spaning Tree протокола, становятся уязвимыми, поскольку уязвимости эти заложены в самом протоколе.
Программное обеспечение.
Проект реализации коммутатора на основе компьютера с OS Linux --
Linux Bridge (см. секцию 20.2 в разделе 20). Как
утверждается на основной странице разработчиков - проект полностью
совместим с IEEE 802.1D спецификацией STP, поэтому коммутатор,
построенный с использованием этого ПО на PC или промышленном ПК,
будет также подвержен STP-атакам, как и любой другой коммутатор,
совместимый с [1]. Поскольку функции "BPDU-guard" или
"spanning-tree portfast" не заявлены, такой коммутатор не имеет
никаких средств борьбы с STP-атаками. Мы настоятельно рекомендуем
разработчикам включить поддержку этих возможностей в todo на
ближайшее время, поскольку в этом случае проект будет иметь хотя бы
какое-то подобие системы безопасности.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
Этот абзац статьи должен был быть посвящен изготовителям червей призванных устроить DoS врагу (например chineese и его бесславному Code Red, который так и не смог сделать DoS сайту www.white-сами-знаете.gov). В случае применения материалов данного документа устройство DoS сводится к захвату контроля хотя бы над одним из компьютеров в атакуемой сети, подключенном к ЛВС атакуемого объекта. Правда дополнительным условием становится интеллектуальность оборудования, то есть поддержка STP-протокола. Однако на момент написания этих строк (Пт Ноя 2 03:27:47 2001) большая часть известного нам сетевого оборудования, поддерживающего STP, поставлялось с включенной по умолчанию ("из коробки") поддержкой STP, что распространяет возможность использовать данную атаку на все сети с конфигурацией по умолчанию. Единственным приятным исключением были модели HP ProCurve 212М и 224M компании Hewlett Packard, но они не поддерживали VLANы, не говоря уже о раздельных STP деревьях в них. Стоит также напомнить, что основное применение Spaning Tree -- защита от образования колец в сети, например, за счет введения запасных каналов для повышения надежности. Такая структура сети наиболее вероятна в крупных правительственных учреждениях (например, сеть американских Белого Дома и Пентагона наверняка построена с использованием избыточности). Самое интересное, что в силу наличия дублирующих каналов, администратор в некоторых случаях не сможет отказаться от использования Spaning Treе. Надо заметить, что во многих известных мне устройствах, обслуживающих сеть, Spaning Tree включался и выключался для всего устройства, так что администратор просто не имеет возможности выключить работу Spaning Tree на одном из портов, не выключая этот порт. На сегодняшний день авторам не известны устройства, которые позволяли бы выключать поддержку STP на отдельном порту, хотя, при чтении документации к коммутатору intel 460Т создается впечатление, что этот коммутатор умеет выключать поддержку STP индивидуально на каждом порту, но, скорее всего, имелся ввиду вариант с установкой порта в режим STP-blocking перманентно.
К числу прочих организаций, которые могут пострадать от STP-DoS, относятся провайдеры Internet с последней милей на LAN-технологии (например Ethernet). Устройства у провайдеров с большой вероятностью должны быть интеллектуальными, и, в случае богатого провайдера (или богатого клиента), они могут иметь дублирующие каналы.
Разумеется, в случае возникновения атаки в одной из двух ЛВС, соединенным неким устройством 2-го уровня OSI (bridge, hub), или даже маршрутизатором, который поддерживает spaning tree, DoS перекинется с одной ЛВС в другую, поскольку второй уровень прозрачен для STP протокола. Сущности, обменивающиеся STP-пакетами, используют мультикастовую адресацию, которая позволяет пакетам проходить в том числе и через оборудование, которое не поддерживает STP, например через концентраторы. Помимо этого подверженными STP-атакам будут хостинговые площадки провайдеров - стоит обратить внимание на то, что для организации DoS-атаки для некоего сервера не обязательно получать контроль над компьютером, предоставляющим место именно этому информационному ресурсу - достаточно будет получить контроль над компьютером, находящимся в том же сегменте ЛВС, что и основная жертва, так, чтобы между zombie host и victim host не было маршрутизатора.
Также возможно распространение атаки через WAN-линки в случае, если
оборудование настроено на частичный пропуск пакетов административных
протоколов, включая STP. Сюда относится и обычное dialup-соединение.
Для атаки поверх такого соединения злоумышленнику надо всего лишь
изменить поведение своего модуля, осуществляющего PPP соединение,
так, чтобы он запрашивал поддержку STP протокола при соединении. По
умолчанию эта функциональность не запрашивается и атака невозможна,
далее все зависит от настроек оборудования провайдера - если STP
поднимется по запросу, DoS атака со стороны анонимного покупателя
интернет карты может стать реальностью. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
Если обеспечение безопасности сети стоит не на последнем месте, лучше отключать поддержку Spaning Tree всегда, когда это возможно, и пытаться заменить STP другими технологиями там, где требуются решения с дублированием каналов, но все же можно обойтись без особенностей STP. Например, можно использовать технологию Link Agregation (поддерживается многими устройствами, в том числе произведенными Intel, Avaya и др.). Если же безопасность важна, но выключить STP по тем или иным неутешительным причинам для всей сети неприемлемо, придется использовать расширения Spaning Tree доступные, в частности, в решениях, предоставляемых cisco,
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
В каждой организации, всерьез заботящейся о безопасности своих данных, должна стоять система обнаружения атак - IDS (Intrusion Detection System). В этом разделе рассматриваются особенности STP-атак, которые можно использовать для их обнаружения и трассировки атакующей стороны. К сожалению, большинство возможных способов настройки "сенсоров" IDS на STP-атаки требуют индивидуальной настройки на данную сеть, то есть потребуют от настраивающего как минимум хорошего представления о функционировании STP и знания всех особенностей данной сети в контексте функционирования STP протокола. 15.1. Сложности обнаружения STP-атак и их причиныОсновная сложность обнаружения состоит в том, что для атаки используют вполне стандартные для протокола пакеты - BPDU. То есть присутствие STP-пакетов в сети однозначно означает STP-атаку лишь в одном из возможных случаев. Вторая сложность (скорее даже особенность): большинство рассматриваемых возможностей обнаружения таких атак связаны с внесением в базу IDS некоторых данных о топологии сети ее администратором. Следующая сложность связана с тем, что поскольку атака идет на топологию и работоспособность сети, IDS должна иметь собственный независимый канал для передачи сообщений ответственному за безопасность. Это может быть, например, передача сообщений через модем, через подсоединенный к IDS мобильный телефон (в частности, есть решения по соединению с PC телефонов Nokia через RS-232) или выделенное соединение точка-точка (например ethernet-кросс) между IDS и рабочей станцией ответственного за безопасность. Впрочем, это условие весьма типично и для других DoS атак. 15.2. Варианты обнаружения атак15.2.1. Вариант обнаружения по наличию STP пакетов
15.2.2. Вариант обнаружения по "чужому" Bridge ID
15.2.3. Вариант обнаружения по длительности
15.2.4. Вариант обнаружения по интенсивности
15.2.5. Вариант обнаружения по монотонности
Комментарий: Для получения большей уверенности в том, что это атака, следует совместить данный способ с вариантом 15.2.2 или 15.2.3. 15.2.6. Вариант обнаружения по цикличности
15.2.7. Вариант обнаружения по потере производительности
15.2.8. Вариант обнаружения по изменению интервалов между ST событиями
15.2.9. Невозможность обнаружить атаку. Пример
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
Теоретически нет возможности полностью избежать описанных атак для протокола подобного STP, кроме как отключением поддержки этого протокола для всей сети, поскольку требуется (все одновременно): и возможность подключить сетевое устройство в любое место сложной ЛВС с динамической топологией любым возможным способом, и без дополнительной административной акции получить автоматическую правильную реконфигурацию топологии, и не использовать каких-либо криптографических методов для обеспечения аутентификации (проверки того, что данный BPDU послал тот, кто посылал их ранее). Использование для этой цели криптографических алгоритмов с открытым ключом мало поможет, так как вновь подключаемое устройство должно иметь возможнось переконфигурировать топологию. То, что в процессе реконфигурации кадры пользователей не должны передаваться, позволяет реализовать DoS, однако совершенно не влияет на работоспособность атаки MitM. У этой проблемы есть несколько возможных (несколько - довольно практичных) решений, которые могли бы быть применены производителями сетевого оборудования. Ниже описываются возможные методы решения, часть из которых, разумеется, может по различным причинам показаться спорной.
Мы расположили варианты в порядке увеличения сложности их
применения.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
Хочется верить, что практически полное отсутствие в сетевых протоколах 2-го уровня OSI средств аутентификации сущностей административных протоколов, а также игнорирование других основ построения безопасных систем (за исключением, разве что, концепции VLAN-divided сетей), вызвано исключительно беспечностью авторов этих протоколов, создававших их во времена, когда о безопасности почти не беспокоились, а не результат "демократичности" законов США, обязывающих оставлять черные ходы для сотрудников спецслужб. 18.1. Кратко: что можно сделать с помощью нецелевого применения STP?
18.2. Кратко: чего нельзя сделать с помощью нецелевого применения STP?
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
19.1. Олег АртемьевХочу сказать спасибо:
19.2. Владислав МяснянкинХочется сказать спасибо:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
20.1. Ссылки, относящиеся к Spanning Tree
20.2. Ссылки, относящиеся к теме "bridging"
20.3. Ссылки по конструированию фреймов
20.4. Open Systems Interconnection refernce model20.5. Другие интересные ссылки
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
/* * Written 2001-09-23 * * Copyright 2001 Vladislav V. Myasnyankin, Yekaterinburg Russia * hugevlad@yahoo.com http://cybervlad.port5.com * All rights reserved. * * WARNING! Be very careful, because you can occasionaly crash * your network. * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU Library General Public License * as published by the Free Software Foundation; either version 2 of * the License, or (at your option) any later version. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * POSSIBILITY OF SUCH DAMAGE. */ #include <stdio.h> #include <unistd.h> #include <ctype.h> #include <stdlib.h> #include <string.h> #include <errno.h> #include <netdb.h> #include <arpa/inet.h> #include <net/if.h> #include <netinet/if_ether.h> #include <sys/ioctl.h> #include <sys/socket.h> #define DEFAULT_DEVICE "eth0" #define ETH_HW_ADDR_LEN 6 char usage[]={ "usage: stp \ [-v] \ [-dev <device>] \ [-dmac <dmac>] \ [-smac <smac>] \n\ -protoid <proto_id> \ -protovid <proto_v_id> \ -bpdu <bpdutype> \ -flags <flags> \n\ -rootid <rootid> \ -rootpc <rootpc> \ -brid <brid> \ -portid <portid> \ -mage <mage> \n\ -maxage <maxage> \ -htime <hellotime> \ -fdelay <fdelay> \n\ where:\n\ -v - be verbose and write output to file packet.dmp instead socket \n\ device - ethernet device name (default - eth0)\n\ dmac - destination MAC (default - 01:80:C2:00:00:00)\n\ smac - source MAC (default - MAC on given or default device)\n\ proto_id - Protocol Identifier (hex, 2 bytes)\n\ proto_v_id - Protocol Version Identifier (hex, 1 byte)\n\ bpdutype - BPDU type (hex, 1 byte)\n\ flags - flags value (hex, 1 byte)\n\ rootid - Root Identifier (hex, 8 bytes)\n\ rootpc - Root Path Cost (hex, 4 bytes)\n\ brid - Bridge Identifier (hex, 8 bytes)\n\ portid - Port Identifier (hex, 2 bytes)\n\ mage - Message Age (hex, 2 bytes)\n\ maxage - Max Age (hex, 2 bytes)\n\ hellotime - Hello Time (hex, 2 bytes)\n\ fdelay - Forward Delay (hex, 2 bytes)\n\ \n"}; struct bpdu_packet { u_char targ_hw_addr[ETH_HW_ADDR_LEN]; /* dest. ether address */ u_char src_hw_addr[ETH_HW_ADDR_LEN]; /* src. ether address */ u_char frame_type[2]; /* 0x00 0x26 */ u_char llc_dest; /* 0x42 */ u_char llc_src; /* 0x42 */ u_char unknown; /* 03 why? I don`t know :( */ u_char proto_id[2]; /* Protocol Identifier */ u_char proto_v_id; /* Protocol Version Identifier */ u_char bpdu_type; /* BPDU Type */ u_char flags; /* Flags */ u_char rootid[8]; /* Root Identifier */ u_char rootpc[4]; /* Root Path Cost */ u_char brid[8]; /* Bridge Identifier */ u_char portid[2]; /* Port Identifier */ u_char mage[2]; /* Message Age */ u_char maxage[2]; /* Max Age */ u_char hellotime[2] /* Hello Time */ u_char fdelay[2]; /* Forward Delay */ u_char padding[8]; /* padding packet to 60 bytes */ }; void fireexit(char *); /* print error message and exit with code 1*/ void get_hex_value(char*,char*,int); /* convert string to hex */ /**** MAIN PART *****/ int main(int argc,char** argv){ FILE *f; struct bpdu_packet pkt1; struct sockaddr saddr; struct ifreq ifr; int sd,i; char eth_dev[30]; unsigned char verbose=0; unsigned int complete=0; /* array of bites: 14 device 7 rootid 0 fdelay 13 dmac 6 rootpc 12 smac 5 brid 11 proto_id 4 portid 10 proto_v_id 3 mage 9 bpdutype 2 maxage 8 flags 1 hellotime */ strncpy(eth_dev,DEFAULT_DEVICE,29); for(i=1; i<argc; i++){ if (!strncasecmp(argv[i],"-v",2)) verbose=1; if (!strncasecmp(argv[i],"-dev",4)){ if (verbose) printf("Device: "); strncpy(eth_dev,argv[++i],29); if (verbose) printf("Ok\n"); complete|=0x4000; }; if (!strncasecmp(argv[i],"-dmac",5)){ if (verbose) printf("Destination MAC: "); get_hex_value(pkt1.targ_hw_addr,argv[++i],6); if (verbose) printf("Ok\n"); complete|=0x2000; }; if (!strncasecmp(argv[i],"-smac",5)){ if (verbose) printf("Source MAC: "); get_hex_value(pkt1.src_hw_addr,argv[++i],6); if (verbose) printf("Ok\n"); complete|=0x1000; }; if (!strncasecmp(argv[i],"-protoid",8)){ if (verbose) printf("Protocol Identifier: "); get_hex_value(pkt1.proto_id,argv[++i],2); if (verbose) printf("Ok\n"); complete|=0x0800; }; if (!strncasecmp(argv[i],"-protovid",9)){ if (verbose) printf("Protocol Version Identifier: "); get_hex_value(&pkt1.proto_v_id,argv[++i],1); if (verbose) printf("Ok\n"); complete|=0x0400; }; if (!strncasecmp(argv[i],"-bpdu",5)){ if (verbose) printf("BPDU Type: "); get_hex_value(&pkt1.bpdu_type,argv[++i],1); if (verbose) printf("Ok\n"); complete|=0x0200; }; if (!strncasecmp(argv[i],"-flags",6)){ if (verbose) printf("Flags: "); get_hex_value(&pkt1.flags,argv[++i],1); if (verbose) printf("Ok\n"); complete|=0x0100; }; if (!strncasecmp(argv[i],"-rootid",7)){ if (verbose) printf("Root Identifier: "); get_hex_value(pkt1.rootid,argv[++i],8); if (verbose) printf("Ok\n"); complete|=0x0080; }; if (!strncasecmp(argv[i],"-rootpc",7)){ if (verbose) printf("Root Path Cost: "); get_hex_value(pkt1.rootpc,argv[++i],4); if (verbose) printf("Ok\n"); complete|=0x0040; }; if (!strncasecmp(argv[i],"-brid",5)){ if (verbose) printf("Bridge Identifier: "); get_hex_value(pkt1.brid,argv[++i],8); if (verbose) printf("Ok\n"); complete|=0x0020; }; if (!strncasecmp(argv[i],"-portid",7)){ if (verbose) printf("Port Identifier: "); get_hex_value(pkt1.portid,argv[++i],2); if (verbose) printf("Ok\n"); complete|=0x0010; }; if (!strncasecmp(argv[i],"-mage",5)){ if (verbose) printf("Message Age: "); get_hex_value(pkt1.mage,argv[++i],2); if (verbose) printf("Ok\n"); complete|=0x0008; }; if (!strncasecmp(argv[i],"-maxage",7)){ if (verbose) printf("Max Age: "); get_hex_value(pkt1.maxage,argv[++i],2); if (verbose) printf("Ok\n"); complete|=0x0004; }; if (!strncasecmp(argv[i],"-htime",6)){ if (verbose) printf("Hello Time: "); get_hex_value(pkt1.hellotime,argv[++i],2); if (verbose) printf("Ok\n"); complete|=0x0002; }; if (!strncasecmp(argv[i],"-fdelay",7)){ if (verbose) printf("Forward delay: "); get_hex_value(pkt1.fdelay,argv[++i],2); if (verbose) printf("Ok\n"); complete|=0x0001; }; }; /* Check, if all needed parameters set */ if ((complete & 0x0FFF) < 0x0FFF) fireexit(usage); /* Set constant values */ pkt1.frame_type[0]=0x00; pkt1.frame_type[1]=0x26; pkt1.llc_dest=0x42; pkt1.llc_src=0x42; pkt1.unknown=03; bzero(pkt1.padding,8); if (verbose) { f=fopen("packet.dmp","a"); fwrite(&pkt1,1,sizeof(pkt1),f); fclose(f); exit(0); }; /* Open raw socket */ if ((sd = socket(AF_INET, SOCK_PACKET, htons(ETH_P_ALL))) < 0){ perror("Can't get raw socket: "); exit(1); } /* Get our hardware address, if not given */ if (!(complete & (12<<1))){ strcpy(ifr.ifr_name, eth_dev); if (ioctl(sd, SIOCGIFHWADDR, &ifr) < 0){ perror("Can't get hardware address: "); close(sd); exit(1); }; memcpy(pkt1.src_hw_addr,ifr.ifr_hwaddr.sa_data,6); }; /* Set device to use */ strcpy(saddr.sa_data,eth_dev); /* Send prepared packet */ if(sendto(sd,&pkt1,sizeof(pkt1),0,&saddr,sizeof(saddr)) < 0) perror("Send packet"); /* Close socket */ close(sd); exit(0); } /*************** END MAIN PART ********************/ void fireexit(char* str){ fprintf(stderr,"%s\n",str); exit(1); } void get_hex_value(char* buf,char* str,int len){ int i; char c,val; for(i=0;i<len;i++){ if( !(c = tolower(*str++))) fireexit("Invalid hex value"); if(isdigit(c)) val = c-'0'; else if(c >= 'a' && c <= 'f') val = c-'a'+10; else fireexit("Invalid hex value"); *buf = val << 4; if( !(c = tolower(*str++))) fireexit("Invalid hex value"); if(isdigit(c)) val = c-'0'; else if(c >= 'a' && c <= 'f') val = c-'a'+10; else fireexit("Invalid hex value"); *buf++ |= val; if(*str == ':')str++; } } |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
#!/bin/sh # # Copyright 2001 Vladislav V. Myasnyankin, Yekaterinburg Russia # hugevlad@yahoo.com http://cybervlad.port5.com # All rights reserved. # # WARNING! Be very careful, because you can occasionaly crash # your network. # # SEE DISCLAMER IN MAIN PROGRAM # # note: # all numbers can be like 00010203040506 or like 00:01:02:03:04:05:06 # device=eth0 # ethernet device name (default - eth0) dmac=01:80:C2:00:00:00 # destination MAC (default - 01:80:C2:00:00:00) smac=00:01:38:00:b4:c7 # source MAC (default - MAC on given # or default device) proto_id=0000 # Protocol Identifier (hex, 2 bytes) proto_v_id=00 # Protocol Version Identifier (hex, 1 byte) bpdutype=00 # BPDU type (hex, 1 byte) flags=00 # flags value (hex, 1 byte) rootid=800000013800b4c7 # Root Identifier (hex, 8 bytes) rootpc=00000000 # Root Path Cost (hex, 4 bytes) brid=800000013800b4c7 # Bridge Identifier (hex, 8 bytes) portid=8002 # Port Identifier (hex, 2 bytes) mage=0000 # Message Age (hex, 2 bytes) maxage=1400 # Max Age (hex, 2 bytes) hellotime=0200 # Hello Time (hex, 2 bytes) fdelay=0f00 # Forward Delay (hex, 2 bytes) ./stp -v -dev $device -dmac $dmac -smac $smac -protoid $proto_id\ -protovid $proto_v_id -bpdu $bpdutype -flags $flags\ -rootid $rootid -rootpc $rootpc -brid $brid -portid $portid\ -mage $mage -maxage $maxage -htime $hellotime -fdelay $fdelay |