https://bugtraq.ru/library/books/stp/chapter06/

Идея этих атак лежит на самой поверхности. Поразительно, что потратив 3 часа на поиски я так и не наткнулся на полное описание атак возможных при помощи протокола Spanning Tree - одни лишь намеки и частные случаи. Возможно из-за лени администраторов? :-) Для того чтобы устроить Отказ в Обслуживании можно воспользоваться тем, что STP-совместимые устройства в момент реконфигурации работают не на пользователя, а лишь на создание Spanning Tree дерева. Поскольку реконфигурация может быть вызвана, в том числе, появлением нового STP-совместимого устройства, можно имитировать периодически появление нового устройства с параметрами, которые будут лучше установившихся, что вызовет реконфигурацию (перевыборы) одного из выборных параметров. Некоторые (глупые) устройства будут пытаться пересматривать состояние всех портов при появлении любого нового устройства даже с худшими (с точки зрения выигрыша в выборах) чем у них параметрами. На более умное железо эта атака может действовать исключительно в случае появления устройства с лучшими (с точки зрения STP) параметрами - в худшем случае может пройти состояние реконфигурации только один порт. Однако даже такая ситуация будет противоречить спецификации протокола [1], в котором не предусмотрена ситуация переконфигурации устройства, к которому подключают другое с худшими (с точки зрения STP) параметрами. Поскольку предметом атаки могут быть любые "выборные" значения, мы можем выделить несколько типов атак по используемым методам их проведения:

1. Инициация перевыборов назначенного корня для всей сети.
2. Инициация перевыборов назначенного моста для сегмента сети.
3. Инициализация перевыборов назначенного порта для сегмента сети.

Как будет показано ниже в разделе 6.4.5, случай 3) часто сопутствует случаю 2).

Здесь и далее под "лучшим" понимается такое значение параметра, содержащегося в BPDU, которое позволяет добиться рассматриваемой цели. Чаще всего под "лучшим" будет пониматься такое значение параметра, которое обеспечит победу в STP-выборах.

В качестве побочных эффектов STP-атак могут образовываться "пакетные штормы" внутри сети (в большинстве случаев - недолговременные).

6.1. BPDU spooffing

Эта часть статьи была добавлена уже примерно на середине разработки. Как вы сможете заметить далее, эта методика нужна для части описываемых здесь алгоритмов и изначально мы обошли ее вниманием, считая, что в ней нет ничего такого, что могло бы его заслужить. Тема c общим названием "spoofing" разжевана во многих источниках настолько хорошо, что, казалось, ничего нового сказать нельзя. Однако в применении к STP и с учетом уровня OSI, на котором работает Spanning Tree, у этой методики есть несколько принципиальных особенностей. Говоря кратко, spooffing -- это подмена. Наиболее типична подмена адреса отправителя - случай, в котором потребуется подменить адрес получателя, придумать трудно, хотя и можно, к тому же, почти все они будут относится исключительно к локальному для данной машины стеку TCP/IP, за исключением разве что методик отлова недостаточно хорошо спрятанных promiscuous интерфейсов. Типичные способы борьбы с этой атакой в Internet заключаются в:

1. введении граничных условий;
2. введении дополнительных требований в протокол обмена между source и destination;
3. введении требования установления соединения между участниками обмена трафиком (в принципе это частный случай 2).

Особенностями STP, важными с точки зрения детального рассмотрения BPDU spooffing, является следующее:

1. Это протокол 2-го уровня OSI, который не маршрутизируем.
2. C-BPDU пакеты этого протокола ходят исключительно между двумя STP-совместимыми устройствами. Любое STP-совместимое устройство, получив такой пакет, генерирует в качестве реакции свой (то есть другой) пакет, ограничивая таким образом зону хождения C-BPDU.
3. Этот протокол не предполагает каких-либо административных ограничений на его использование.
4. Этот протокол не предусматривает входной фильтр хождения BPDU по интерфейсу с которого оно получено, поскольку сам факт получения BPDU на том или ином интерфейсе является событием протокола

   Исключения возможны при поддержке расширений, например Cisco BPDU Root Guard, см. раздел 8.

5. Этот протокол предусматривает динамическое конфигурирование. Причем, ограничений на факт и время появления в структуре нового устройства не предусмотрено.
6. Это протокол без установки соединения (connection-less protocol).

Из 1 и 4 следует, что граничные условия фильтрации ложных пакетов к нему не применимы.

По крайней мере до тех пор, пока нет уверенности, что на определенных интерфейсах получение BPDU принципиально невозможно (или не приемлемо по каким либо соображениям). Такую уверенность может иметь администратор, однако сам по себе стандарт в данном случае не предусматривает возможности отключения STP поинтерфейсно - в таком поведении стандарта есть смысл только до тех пор, пока безопасность имеет меньший приоритет, чем удобство.

Из 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).

Это если программисты не забыли поставить знак неравенства. А если забыли - вплоть до максимальной величины, вмещающейся в отведенную под этот параметр область памяти. Опять же, разные производители зачастую совершенно по-своему соблюдают совместимость с тем или иным IEEE стандартом. ;)

Поскольку помимо 65535 возможных приоритетов bridge id включает в себя еще и MAC адрес, то количество времени, которое потребуется чтобы перебрать все возможные значения весьма велико и составит (в шестнадцатеричной системе cчисления):
(CurrentVictimBridgePriority-1 + VictimBridgeMAC-1)* (ListeningTime + LearningTime)= (CurrentVictimBridgePriority+VictimBridgeMAC-2)* (ListeningTime+LearningTime) = (CurrentVictimBridgePriority+VictimBridgeMAC-2)* 2*ForwardDelay ~секунд.

Значение по умолчанию для 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.

Это всего лишь один из возможных вариантов, пока требующий подтверждения.

Поэтому, если в рамках данного VLAN отправлять BPDU от имени имеющегося в соседнем VLAN designated root или просто designated bridge, коммутаторы можно убедить в том, что в некотором месте VLAN'ы стали вдруг как-то соединены. Это вызовет перевыборы designated bridge, в том числе и в сегменте, который атакуется и принадлежит VLAN, отличному от VLAN атакующего.

Этот алгоритм назван алгоритмом случайного совпадения потому, что атакующему придется подбирать 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-выборов) параметрами.

Рис. 7. Частичный DoS (пример 1)

Пример 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-совместимых устройствах.

Рис. 8. Частичный DoS (пример 2)

Более типичной будет схема показанная на рисунке 9. В реальных условиях у злоумышленника редко есть возможность расцепить линк между коммутаторами, "врезать" туда концентратор и вставлять в поток свои пакеты. Скорее возможен такой сценарий: сервера включены в один коммутатор, клиенты включены в концентраторы, подсоединенные к одному или нескольким коммутаторам. По аналогии атаки Митника на Шимомуру, атакующему надо "выключить" одного из участников соединения, а именно, сервер. Для этого он должен убедить коммутатор, к которому подключен концентратор с интересующим его клиентом, что он имеет лучший путь до второго коммутатора, к которому подключен сервер. В результате, линк между коммутаторами рвется, и атакующий может прикидываться сервером или просто злорадствовать от факта недоступности сервера клиенту (см. рис. 9). Разумеется, концентратор здесь не принципиален, хотя можно строить атаку, подобную этой, на всю сеть, не задумываясь над подсчетом величин для данного сегмента сети. Если конечной целью является компьютер, подключенный к концентратору - он не "упадет" от этой атаки, ибо слишком "глуп".

Рис. 9. Частичный DoS (пример 3)

Рисунок 8, часть а), обращает внимание на следующую особенность: если считать, что нумерация портов идет слева направо, то атакующий, пытаясь устроить частичный DoS для линка между коммутаторами, может сделать его исключительно себе, если не подобрать параметры специальным образом. Дело в том, что, при прочих равных условиях, включенным останется порт с меньшим ID. Поэтому атакующий должен подобрать для фальсификации такой номер порта соседнего коммутатора, который заставит коммутатор "Bridge 2" выключить именно необходимый атакующему линк, а не тот, с которого идет атака. Для случая же с одним единственным STP-совместимым устройством (рис. 8, часть b)) атака легко реализуема для всех LAN, подключенных к портам, большим по номеру. Однако при попытке реализовать ее по отношению к первому порту ничего не выйдет: получив BPDU на большем по номеру порту от имени порта c меньшим номером, устройство выключит порт с большим номером.

Изменяя Max Age, forward delay, hello time в ложных c-bpdu, мы можем управлять как минимум ближайшими коммутаторами, изменяя их представление о топологии сети, а также (что принципиально при организации частичной DoS) - изменять тайм-ауты протокола, что позволяет нам выставить конфликтующие с остальной сетью значения.

Следует заметить, что в силу таймаутов реконфигурации в рамках протокола и того, что в момент реконфигурации пользовательские фреймы не передаются, применение данной методики для временного получения пакетов (например, части пакетов используемых при установлении соединения с помощью протоколов верхних уровней, например, IP) нецелесообразно, поскольку в момента изменения топологии эти пакеты блокируются.

Тем не менее, при определенных настройках с использованием расширенной спецификации STP-протокола это все-таки имеет смысл (см. раздел 8.1)

Предметом атаки может быть маршрут между любыми двумя STP-совместимыми устройствами сети. Следует также отметить, что при организации части описываемых здесь атак придется угадывать bridge ID части устройств, однако эта задача зачастую облегчается возможностью получить часть идентификатора или диапазон возможных значений косвенным образом - через протоколы более высокого уровня (например, используя стек TCP/IP, можно получить MAC коммутатора, пропинговав его и посмотрев arp таблицу), используя таблицы зарезервированных за тем или иным производителем диапазонов MAC адресов и др. Имея один из MAC адресов многопортового активного устройства, легко вычислить остальные, поскольку производители обычно присваивают MAC адреса портам подряд, а их изменение, даже если оно доступно администратору, практически не требуется для типичных задач администрирования. Важно заметить, что реализация частичной DoS не требует использования перевыборов STP-root - достаточно перевыборов designated bridge, что, как следствие, позволяет, при определенных условиях, провести эту атаку незаметно для всей остальной сети.

Данная атака может оказаться нереализуемой без физического подключения к атакуемому сегменту. Авторы планируют уточнить это дополнительными экспериментами. После обсуждения с Dmitry Goloubev (адрес см. в разделе 19) опубликованной авторами статьи, являющейся выжимкой данной работы, у нас появились сомнения в порядке работы STP-совместимых устройсв с BPDU. Существует две возможности: 1) коммутатор изменяет состояние порта в случае прихода BPDU на любой порт и 2) коммутатор изменяет состояние порта только по приходе BPDU именно на него. Разумеется во втором случае часть описаных атак сужает область своего применения (но только часть!).

6.4.6. STP DoS: величины, которые должны быть установлены в STP пакетах, организующих DoS

Глава 8.6 (конкретнее, раздел 8.6.1.3) в [1] содержит подробное описание всех параметров BDPU. Разумеется, в зависимости от алгоритма атаки величины используются разные. Для DoS атаки посредством постоянной инициации выборов STP root bridge важны следующие параметры.

Root bridge устанваливает следующие значения:

RootPathCost = 0	([1], 8.5.3.2)
RootPort = 0	([1], 8.5.3.3)
Bridge'srootport = 0	([1], 8.8.1.a)

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. Человек посередине

Рассмотрим рис. 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-атаки, описываемой в этом разделе.

Причем, не только интеллектуальной сети - "глупые" сети, построенные на концентраторах, можно вывести из строя, заставив NIC постоянно передавать сигнал jam, можно совместить по очереди jam'ing и описываемый здесь STP-redirect.

К сожалению такие разработки могут заинтересовать разве что военных, а тратить на разработку экспериментального образца собственные деньги авторы не считают возможным.

Более того, об этом есть смысл говорить только применительно к портативному устройству с автономным питанием, которое можно незаметно пронести в здание, т.к. специалист сможет построить такой "деструктор" на базе старенькой ПЭВМ с двумя сетевыми платами, потратив на оборудование менее 100 долларов.

Требование наличия как минимум двух коммутаторов связано с тем, что в случае подключения к одному коммутатору анонсирование себя, как лучшего пути создаст тупиковый путь, то есть это случай, относящийся к разделу 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"!

Здесь не стоит забывать, что практически сведение aging time таблицы коммутации устройства-жертвы к 4 секундам будет давать крохи.

Следует помнить, что "перевыбирать" можно только те параметры, которые не заденут функциональность собственного порта, иначе можно легко организовать DoS самому себе. В качестве одного из возможных вариантов можно привести использование выборов designated port для K из N (K<N) сегментов сети, подключенных к атакуемому коммутатору. Почему не одного? Можно и одного, но если задействовать несколько сегментов, то можно чередовать выборы, устраивая их по очереди, чтобы процесс перевыборов происходил как можно чаще. Следующим после перебора designated port некоторого сегмента ЛВС, будет перебор designated bridge. Однако есть еще лучший путь - диапазон значений для некоторого порта содержит также определенный диапазон для изменения приоритета, причем не такой уж и маленький, таким образом можно свести побочный эффект атаки к DoS всего лишь одного порта, а при неполном заполнении портов - обойтись без DoS, устраивая перевыборы designated port для незанятого ничем порта. В случае если поддерживается аналог "spanning-tree portfast" (Cisco), мы имеем самый простой случай - можно атаковать коммутатор, используя как C-BPDU, так и TCN-BPDU, что даст почти одинаковый эффект. Однако TCN-BPDU предпочтительнее, так как не вызывают DoS.