BugTraq.Ru: замечания, вытекающие из анализа RFC 2878

4. Замечания, вытекающие из анализа RFC 2878

Согласно RFC 2878:

Two basic algorithms are ambient in the industry for Bridging of Local Area Networks. The more common algorithm is called "Transparent Bridging", and has been standardized for Extended LAN configurations by IEEE 802.1. The other is called "Source Route Bridging", and is prevalent on IEEE 802.5 Token Ring LANs.

Поскольку RFC доступны в виде ASCII-текстов, их цитирование гораздо удобнее, чем IEEE-стандартов, распространяемых в формате pdf (см. раздел 20). В этом разделе цитаты из RFC 2878 в связи с большим их количеством будут просто браться в кавычки и выделяться в отдельный абзац, без специального упоминания о том, какой именно цитируется документ - достаточно одного раза.

The implementor may model the line either as a component within a single MAC Relay Entity, or as the LAN media between two remote bridges. The IEEE 802.1G Remote MAC Bridging committee has proposed a model of a Remote Bridge in which a set of two or more Remote Bridges that are interconnected via remote lines are termed a Remote Bridge Group. Within a Group, a Remote Bridge Cluster is dynamically formed through execution of the spanning tree as the set of bridges that may pass frames among each other. We allow for modelling the line either as a connection residing between two halves of a "split" Bridge (the split-bridge model), or as a LAN segment between two Bridges (the independent-bridge model). In the latter case, the line requires a LAN Segment ID. By default, PPP Source Route Bridges use the independent-bridge model. Given that source routing is configured on a line or set of lines, the specifics of the link state with respect to STE frames are defined by the Spanning Tree Protocol in use. Choice of the split - bridge or independent-bridge model does not affect spanning tree operation. In both cases, the spanning tree protocol is executed on the two systems independently.

Здесь STE frame - Spanning Tree Explorer frame - специфичный для 802.5 MAC фрейм.

Таким образом, для систем, использующих "Source Route Bridging", STP-атаки из удаленного сегмента во многих случаях не страшны. Внутри таких систем, соединенных WAN-линком, существуют независимые STP-деревья, так что максимум, чего мог бы добиться атакующий - опустить WAN-link, передавая STP пакеты от имени удаленного designated root. Однако даже это может оказаться невозможным - смысл в поддержке STP пакетов для линка между двумя различными STP-сущностями не очевиден.

The Bridging Control Protocol (BCP) is responsible for configuring, enabling and disabling the bridge protocol modules on both ends of the point-to-point link. BCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. Before any Bridged LAN Traffic or BPDUs may be communicated, PPP MUST reach the Network-Layer Protocol phase, and the Bridging Control Protocol MUST reach the Opened state.

Из главы 4.1.4. [5] "Separation of Spanning Tree Domains"

It is conceivable that a network manager might wish to inhibit the exchange of BPDUs on a link in order to logically divide two regions into separate Spanning Trees with different Roots (and potentially different Spanning Tree implementations or algorithms). In order to do that, he should configure both ends to not exchange BPDUs on a link. An implementation that does not support any spanning tree protocol MUST silently discard any received IEEE 802.1D BPDU packets.

То есть, во-первых, администратор может разделить 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):

To avoid network loops and improve redundancy, Bridges exchange a Spanning Tree Protocol data unit known as BPDU. Bridges also exchange a Generic Attributes Registration Protocol data unit to carry the GARP VLAN Registration Protocol (GVRP) data and GARP Multicast Registration Protocol (GMRP). GVRP allow the Bridges to create VLAN groups dynamically. GMRP allows bridges to filter Multicast data if the receiver is absent from the network. These Bridge protocols include Spanning Tree Protocol and GARP protocols data units are carried with a special destination address assigned by the IEEE.

Ну, и, наконец, в следующем абзаце определяется самое главное в контексте STP-атак:

These bridge protocols data units and GARP protocol data units must be carried in the frame format shown in section 4.2 or 4.3.

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

But there is one exception to this rule: if the bridge is connected to an old BCP bridge [10] and can support backward compatibility, it MUST send the BPDU in the old format described in Appendix A.

Здесь ссылка [10] - ссылка на RFC 1638.

Резюмируем: в принципе PPP WAN линки могут служить переносчиками STP атак.

Теперь о деталях. В BCP методика действий сходна с PPP LCP:

BCP uses the same packet exchange mechanism as the Link Control Protocol.

LCP, грубо говоря, служит для определения того, какие потенциально возможные опции устанавливаемого линка будут применены в данном конкретном соединении. В PPP LCP используется система обмена запрос/ответ. Аналогичный подход и в BCP:

If a Configuration Option is not included in a Configure-Request packet, the default value for that Configuration Option is assumed.

То есть могут использоваться какие-то значения по умолчанию. Какие же? Давайте посмотрим - ниже будут замечания по этим значениям, а пока стоит взглянуть на главу 5.6 в [5]. Эта глава описывает поведение устройств при работе с STP. Первым же абзацем идет определение совместимости со старым форматом (RFC 1638):

The Spanning-Tree-Protocol Configuration enables a Bridge to remain compatible with older implementations of BCP [10].This configuration option is, however, incompatible with the Management-Inline option, which enables a bridge to implement the many protocols that IEEE now expects a bridge to be able to use.

Здесь ссылка [10] - ссылка на RFC 1638.

Далее определяется возможное поведение системы, в случае, если на другом конце стоит устройство, работающее по RFC 1638, и при этом выбирается совместимый с ним алгоритм работы:

If both bridges support a spanning tree protocol, they MUST agree on the protocol to be supported. The old BPDU described in Appendix A MUST be used rather than the format shown in section 4.2 or 4.3. When the two disagree, the lower-numbered of the two spanning tree protocols should be used. To resolve the conflict, the system with the lower-numbered protocol SHOULD Configure-Nak the option, suggesting its own protocol for use. If a spanning tree protocol is not agreed upon, except for the case in which one system does not support any spanning tree protocol, the Bridging Control Protocol MUST NOT enter the Opened state.

Здесь стоит сделать следующий комментарий - согласно RFC 2878 Spanning Tree протоколов несколько, каждый из которых пронумерован согласно RFC 1700 [7]:

Null (no Spanning Tree protocol supported)
IEEE 802.1D spanning tree
IEEE 802.1G extended spanning tree protocol
IBM Source Route Spanning tree protocol
DEC LANbridge 100 Spanning tree protocol

Очевидно, все эти протоколы имеют некие общие свойства, позволяющие называть их Spanning Tree протоколами, что, кстати, наталкивает на мысль, что все они могут быть подвержены, как минимум части описываемых здесь атак на Spanning Tree Protocol, пронумерованный в [7] как 1. Поскольку часть сказанного в данной статье относится к Spanning Tree алгоритму вообще, то слабость этих протоколов очевидна.

В данной статье пока рассматривается только IEEE реализация STP, однако в дальнейшем мы планируем включить анализ и остальных реализации ST-алгоритма.

Приложение A в [5] содержит аналогичную таблицу для значений передаваемых в поле идентификатора STP протокола, согласно [7]:

Value (in hex) Protocol

0201 IEEE 802.1 (either 802.1D or 802.1G)

0203 IBM Source Route Bridge

0205 DEC LANbridge 100

Далее декларируется возможность PPP WAN линков работать сразу с несколькими типами STP:

Most systems will only participate in a single spanning tree protocol. If a system wishes to participate simultaneously in more than one spanning tree protocol, it MAY include all of the appropriate protocol types in a single Spanning-Tree-Protocol Configuration Option.

А вот еще одно важное замечание: если устройства на обоих концах не могут прийти к согласию по поводу того, какой STP протокол использовать, то выигрывает протокол с меньшим номером, то есть, IEEE реализация, если STP вообще поддерживается, конечно:

When the two disagree, the lower-numbered of the two spanning tree protocols should be used. To resolve the conflict, the system with the lower-numbered protocol SHOULD Configure-Nak the option, suggesting its own protocol for use. If a spanning tree protocol is not agreed upon, except for the case in which one system does not support any spanning tree protocol, the Bridging Control Protocol MUST NOT enter the Opened state.

Выделенное заглавными буквами весьма важно - если с обоих сторон поддерживается STP, то он должен обязательно быть использован. Далее сказано, что по умолчанию либо STP поддерживает хотя бы IEEE реализацию, либо не поддерживается вовсе:

By default, an implementation MUST either support the IEEE 802.1D spanning tree or support no spanning tree protocol.

Теперь рассмотрим эту ситуацию в следующем теоретическом случае, очень близком к повсеместной практике. Допустим, мы имеем ISP с dialup доступом, построенном на маршрутизаторе доступа. Если этот маршрутизатор доступа поддерживает STP (например, многие модели Cisco), то, вероятно, PPP линки, которые организуются между ISP и его клиентом, будут поддерживать STP со стороны ISP. В нормальной ситуации PPP клиенты не запрашивают поддержку STP просто за ненадобностью, однако, если вместо обычного пользователя PPP соединение с провайдером установит вредитель, он, вероятно, сможет, модифицировав процедуру установления PPP соединения, реализовать часть STP-атак на сеть провайдера.

Стоит заметить, что согласно главе 5.7 [5], по WAN линкам может также передаваться информация о VLAN (и прочих опциях определяемых тегированными фреймами 802.1q [4]). При этом определено, что если удаленное устройство не заявило о поддержке 802.1q, то тегированные фреймы не должны ему посылаться. Однако ситуация, при которой злоумышленник будет посылать со своей стороны такие фреймы не определена, что позволяет предположить различную реакцию со стороны устройств различных производителей:

By default, IEEE 802 Tagged Frame is not supported. A system which does not negotiate, or negotiates this option to be disabled, should never receive a IEEE 802 Tagged Frame.

Не следует забывать, что помимо PPP существуют еще и другие WAN-линки, например, ADSL based, на которые есть свои стандарты. Они также могут допускать свободное хождение STP по умолчанию - это дотошный читатель может выяснить самостоятельно.