информационная безопасность
без паники и всерьез
 подробно о проекте
Rambler's Top100Где водятся OGRыПортрет посетителяСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Microsoft обещает радикально усилить... 
 Ядро Linux избавляется от российских... 
 20 лет Ubuntu 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / библиотека / книги / spanning tree / как IDS могут обнаружить STP атаки
SPANNING TREE
титул
содержание
введение в spanning tree протокол
STP & VLANs
STP в гетерогенных средах
замечания, вытекающие из анализа RFC 2878
комментарии к написанию кода
возможные схемы атак
получение дополнительной информации о сети
особенности реализации у различных производителей
замечания по поводу Linux bridging project
замечания по поводу GARP и GVRP
обзор атак на 2 уровне OSI
уязвимые продукты
примеры уязвимых сетей
как администраторы могут противостоять атакам
как IDS могут обнаружить STP атаки
корни проблемы, или "откуда ноги растут"
что делать производителям
эпилог
благодарности
ссылки
список литературы
глоссарий
программа формирования ST пакетов
сценарий для запуска программы




Подписка:
BuqTraq: Обзор
RSN
БСК
Закон есть закон




15. Как IDS могут обнаружить STP атаки

В каждой организации, всерьез заботящейся о безопасности своих данных, должна стоять система обнаружения атак - 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 пакетов

Дано:
В сети нет устройств, поддерживающих STP, либо поддержка STP отключена на всех устройствах сети, сеть не подсоединена к другим сетям, в которых есть STP-совместимые устройства.
Событие:
обнаружены STP пакеты (C-BPDU или N-BPDU).
Статус:
Это однозначно STP-атака.
Администрирование:
Для того, чтобы IDS могла использовать этот метод, администратор должен внести в ее конфигурацию информацию о том, что в сети нет STP-совместимых устройств.

15.2.2. Вариант обнаружения по "чужому" Bridge ID

Дано:
В сети всего N устройств, поддерживающих STP, либо поддержка STP отключена на всех остальных устройствах сети, сеть не подсоединена к другим сетям, в которых есть STP-совместимые устройства.
Событие:
обнаружены STP пакеты (C-BPDU или N-BPDU) с root id (bridge id) иным, нежели у всех имеющихся устройств.
Статус:
Это однозначно STP-атака.
Администрирование:
Для того, чтобы IDS могла использовать этот метод, администратор должен внести в ее конфигурацию информацию о всех возможных bridge id.

15.2.3. Вариант обнаружения по длительности

Дано:
В сети есть N STP-совместимых устройств, администратору необходима возможность подключения новых устройств с автоматическим вводом их в работу в сети, предполагается, что одновременно в сети не может появиться более чем K новых STP-совместимых устройств, bridge ID имеющихся устройств не документируются.
Событие 1:
обнаружены STP выборы (смена Designated Root ID, возможно последовательная).
Событие 2:
a) в течении периода в <(N+K)*X + ensure_time> секунд выборы периодически повторяются с разными Designated Root ID.
или
b) за любое время обнаружено N+K bridge ID.
Статус:
Это однозначно STP-атака.
Администрирование:
Для того, чтобы IDS могла использовать этот метод, администратор должен внести в ее конфигурацию информацию о устраивающих его значениях "ensure_time" (времени, суммируя которое с временем на прошедшие выборы можно получить время, за которое сеть должна основательно успокоиться (т.е. все выборы к окончанию этого периода пройти). Этот параметр можно рассчитать, исходя из количества STP-совместимых устройств в сети.

15.2.4. Вариант обнаружения по интенсивности

Дано:
В сети есть N STP-совместимых устройств, администратору необходима возможность подключения новых устройств с автоматическим вводом их в работу в сети, предполагается, что одновременно в сети не может появиться более чем K новых STP-совместимых устройств, bridge ID имеющихся устройств не документируются.
Событие:
За время t, меньшее, чем минимальное определенное в стандарте, приходит более одного C-BPDU с одинаковыми bridge ID или с одинаковыми designated root ID.
Статус:
Это однозначно STP-атака.
Администрирование:
Не требуется в случае параметра t, устанавливаемого по умолчанию, но полезной будет возможность выставить параметр t, поскольку это одна из регулируемых (по стандарту) настроек, которые может производить пользователь (администратор сети). В случае, если t настраиваемо, этот вариант становится частным случаем варианта 15.2.8.

15.2.5. Вариант обнаружения по монотонности

Дано:
В сети есть некоторое количество STP-совместимых устройств, администратору необходима возможность подключения новых устройств с автоматическим вводом их в работу в сети.
Событие:
За время меньшее чем <some_test_time>, bridge id или designated root ID или Designated bridge ID монотонно убывают.
Статус:
Это STP-атака c очень большой вероятностью.
Администрирование:
задание диапазона изменения этих id-величин, либо задание some_test_time (которое можно устанавливать в некоторое значение по умолчанию).

Комментарий: Для получения большей уверенности в том, что это атака, следует совместить данный способ с вариантом 15.2.2 или 15.2.3.

15.2.6. Вариант обнаружения по цикличности

Дано:
В сети есть некоторое количество STP-совместимых устройств, администратору необходима возможность подключения новых устройств с автоматическим вводом их в работу в сети. Предполагается, что в сети нет устройств, сконфигурированных как STP-root-backup (см. раздел 8.1).
Событие:
За время меньшее, чем <some_test_time>, bridge id или designated root ID или Designated bridge ID постоянно циклически меняются.
Статус:
Это STP-атака c очень большой вероятностью.
Администрирование:
не требуется, если some_test_time оставлено по умолчанию, однако, этот параметр должен быть настраиваемым.

15.2.7. Вариант обнаружения по потере производительности

Дано:
В сети есть некоторое количество STP-совместимых устройств, администратору необходима возможность подключения новых устройств с автоматическим вводом их в работу в сети.
Событие:
Резкое снижение пропускной способности сети.
Статус:
Это может быть STP-атакой. Вероятность того, что это STP-MitM, зависит от величины изменения пропускной способности и должна подбираться экспериментальным путем - это один из самых сложных алгоритмов обнаружения STP-MitM атаки, реализация которого возможна скорее лишь теоретически, поскольку скорость работы в сети может меняться в зависимости от многих переменных параметров, например, от количества работающих пользователей и объема передаваемых ими друг другу данных. Такую атаку проще обнаружить визуально по субъективным ощущениям, чем искать способ заставить IDS уловить грань.
Администрирование:
потребует от администратора задания нескольких параметров, определяющих допустимые скачки скорости работы сети.

15.2.8. Вариант обнаружения по изменению интервалов между ST событиями

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

15.2.9. Невозможность обнаружить атаку. Пример

Дано:
В сети всего N устройств, поддерживающих STP, поддержка STP включена на части устройств сети, сеть подсоединена к другим сетям, в которых есть STP-совместимые устройства, однако STP-root административно зафиксирован (например, заданием меньшего по модулю bridge ID, чем у остальных устройств), bridge id остальных устройств не введены в базу IDS, администратору необходима возможность подключения новых устройств с автоматическим вводом их в работу в сети.
Событие:
обнаружены STP пакеты (C-BPDU или N-BPDU) с designated root id иным, нежели у устройства, bridge id которого зафиксирован как указано выше.
Статус:
Это не может быть однозначно определено как STP-атака, поскольку в процессе выборов STP-root-bridge может произойти поочередная смена designated root между уже имеющимися STP-совместимыми устройствами, что приведет к рассылке подобных C-BPDU или N-BPDU.
Возможные решения:
следует воспользоваться рекомендациями для случая 15.2.2 или случая 15.2.3.




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



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


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach