BugTraq.Ru
 Русский BugTraq
https://bugtraq.ru/library/books/stp/chapter17/

17. Как производители могли бы отреагировать на появление в публичном доступе информации по STP-атакам
  1. До тех пор, пока не будут найдены лучшие пути, устройства "из коробки" должны игнорировать STP протокол, как сделано, например, в коммутаторах Hewlett Packard HP212M и 224M (в них поддержка STP "из коробки" выключена). Это позволит избежать атак в тех ситуациях, когда STP не является жизненно необходимым элементом сети (например, в сети с единственным коммутатором).
  2. Следует отказаться от принципа plug&play по отношению к сети: например, выпустив новую версию стандарта, которая будет требовать переконфигурации администратором некоего STP пароля (желательно нетранслируемого напрямую в сеть), который требовался бы для участия в изменении топологии по новому STP-протоколу, и без ввода которого поддержка STP была бы выключена. Так можно было бы значительно усложнить воспроизведение атаки на топологию сети. Ничего особенно страшного в том, что устройство перед вводом в полнофункциональную работу с сетью надо будет чуть-чуть отконфигурировать нет: обычно устройства все же конфигурируют, перед тем, как задействовать в сложных сетях, а сети, в которых STP работает не просто так, а с пользой, явно сложнее остальных, которых, кстати, большинство.:) Конкретная реализация может быть выполнена с использованием известных криптографических методов, например, при помощи Кодов Подтверждения Достоверности (Message Authentication Code, MAC). Для этого в пределах группы оборудования, которое должно образовать stp-дерево, выбирается "общий секрет" (пароль, ключ), заносимый в каждое устройство (лучше с помощью dip-switches на панели, т.е. аппаратно)
Такой подход позволит автоматически выполнить и предыдущую рекомендацию, если положение переключателей по умолчанию ("все в 0") будет означать для устройства отключение поддержки STP.. После этого перед посылкой BPDU-пакета к нему добавляется секрет, для всего массива (пакет вместе с "общим секретом") рассчитывается значение хеш-функции (например, SHA-1) и прибавляется к отправляемому BPDU-пакету ("общий секрет", естественно, при этом не передается). На принимающей стороне к принятому пакету также добавляется секрет и рассчитывается значение хеш-функции, которое сравнивается с полученным в пакете. В результате получатель уверен, что пакет послал кто-то из "своих" (обладающих знанием секрета), при этом сам секрет по сети не передается и не может быть перехвачен злоумышленником для последующего использования.
  1. Каждое устройство, поддерживающее STP, должно иметь возможность отключить обработку STP на каждом порту по отдельности, это реализуется переписыванием управляющего софта. Без выполнения этого условия применение такого устройства в сети становится небезопасным. Разумеется, в момент выключения STP на порту администратор должен понимать, что он лишается возможности использовать преимущества STP и ставит себе потенциальную ловушку. Однако есть масса случаев, когда это оправдано. Например, предоставление клиентам ISP сервиса по Ethernet сети - в этом случае сети всегда будут разделены и STP на клиентских портах никогда не принесет пользы. С точки зрения реализации, порты с выключенной поддержкой STP должны просто отбрасывать любые STP-BPDU и не должны посылать никаких STP-BPDU.
  2. Крайне желательно, чтобы каждое STP-совместимое устройство поддерживало команду, аналогичную командам Сisco STP portfast и BPDU-guard. Это позволило бы избежать некоторых типов DoS (STP portfast), а также (BPDU-guard) локализовать сегмент с атакующим.
  3. Каждое устройство, поддерживающее и STP, и VLANы, должно поддерживать отдельное STP-дерево на каждый VLAN, в противном случае атака в одном VLAN может привести к отказу работы всей сети (например, в случае использования intel 460T с включенным STP).
  4. Алгоритм работы STP должен быть пересмотрен: на используемые алгоритмом таймауты должны быть наложены более жесткие ограничения, такие, чтобы стала невозможной постоянная реконфигурация устройств, при которой время, проводимое в состояниях с запрещенной трансляцией фреймов, не может быть больше времени устаревания информации.
  5. Протокол STP требует доработки в части внесения в него функций обеспечения аутентичности и целостности передаваемой информации (пакетов BPDU), например, с применением криптографических методов. Это позволило бы избежать ситуации когда конфигурация изменяется атакующим в любой момент времени посредством посылки bpdu от имени другого устройства.
  6. Спецификация алгоритма STP (как и прочих административных протоколов, работающих на 2-м уровне OSI), а также спецификация канального уровня всех LAN могут быть расширены таким образом, чтобы NIC'и физически не могли общаться с устройствами, обслуживающими сеть (маршрутизаторы, мосты, концентраторы и т.п.) с использованием административных протоколов. Иными словами, административные протоколы, используемые коммутаторами для определения топологии, могли бы работать с использованием отдельной схемы электрической сигнализации (другой вольтаж или метод кодирования сигнала). Поскольку сетевые адаптеры конечных устройств не будут иметь такой схемы, они физически не смогут вмешаться в работу административных протоколов. Этот вариант изменения протокола представляется мало перспективным. Во-первых, он достаточно сложен в реализации (необходимо перепроектировать аппаратную часть). Во-вторых, аппаратная несовместимость остановит лишь часть личностей с деструктивными наклонностями (не умеющих держать в руках паяльник). В-третьих, сразу же встает вопрос обратной совместимости с ранее выпущенным оборудованием. Таким образом, несмотря на серьезные затраты, он не является панацеей.
  7. Возможно, следует изменить STP протокол таким образом, чтобы пользовательские фреймы передавались всегда, предусмотрев при этом дополнительную маркировку фреймов, переданных в период реконфигурации маркером, который помогал бы уничтожать их по прошествии некоторого таймаута - в конце концов не так уж и много урона сети нанесут продублированные по разным каналам фреймы, в отличие от описанных в этой статье DoS атак.
  8. Возможно, стоит создавать более сложные административные протоколы - с установлением соединения (подобно tcp). Это может серьезно усложнить спуфинг конфигурационных сообщений.
  9. Также, возможно, стоит расширить STP таким образом, чтобы устройства запрашивали подтверждения происходящего поверх заблокированных каналов в тех случаях, когда это возможно. Такая модификация отбросит возможность определенных подвидов атак (в частности, MitM).




  Copyright © 2001-2024 Dmitry Leonov Design: Vadim Derkach