2.3 Возникновение эффекта «unicast flooding» в результате уязвимостей в маршрутизации
Пусть существуют два виртуальных компонента ИТКС, каждому из которых в качестве шлюза по умолчанию назначен коммутатор 3 уровня (s1 и s2). При этом некоторые элементы ИТКС, относящиеся к одному виртуальному компоненту ИТКС имеют подключение к коммутатору другого виртуального компонента ИТКС. Предположим, что к определенному моменту времени, когда элементу первого виртуального компонента ИТКС понадобилось связаться с элементом другого виртуального компонента ИТКС, IP-адреса и MAC-адреса этих элементов уже содержались соответственно в таблицах маршрутизации и коммутации обоих коммутаторов (рис. 2.5).
Рис. 2.5. Граф предварительного состояния CAM-таблиц маршрутизаторов
После отправки запроса элементом ИТКС, принадлежащим одному виртуальному компоненту ИТКС, другому элементу ИТКС, принадлежащему соответственно другому виртуальному компоненту ИТКС (рис. 2.6), ответ может быть представлен, например, UDP-потоком (рис. 2.7).
Рис. 2.6. Граф процесса отправки запроса элементу, входящему в другой виртуальный компонент ИТКС
Рис. 2.7. Граф процесса ответа на запрос элементу, входящему в другой виртуальный компонент ИТКС
Устаревание и автоматическое очищение CAM-таблицы коммутатора происходит, по умолчанию, каждые 5 минут [132]. Таким образом, через каждые 5 минут, в случае настроек по умолчанию, CAM-таблицы маршрутизаторов будут переходить в состояние, обобщенно представленное на рис. 2.8.
Рис. 2.8. Граф состояния CAM-таблиц коммутаторов
после их устаревания и самоочищения
Если какой-либо элемент ИТКС снова попытается связаться с другим элементом не из своего виртуального компонента ИТКС, то за неимением в CAM-таблице сведений о MAC-адресе получателя, коммутатор являющийся шлюзом для элемента-отправителя, перенаправит получаемые от отправителя пакеты на все свои порты внутри соответствующего виртуального компонента ИТКС, что является вполне рабочей ситуацией и не сказывается критическим образом на функционировании ИТКС (рис. 2.9). Перенаправленный одноадресный поток, попав на коммутатор – шлюз элемента-получателя, будет доставлен по месту назначения (рис. 2.10).
Рис. 2.9. Граф процесса рассылки запроса элементам
виртуального компонента элемента-получателя
Рис. 2.10. Граф процесса доставки запроса элементу-получателю
Отвечая на полученный запрос, элемент ИТКС начинает передавать на свой шлюз данные (например, UDP-поток). Но поскольку MAC-адрес элемента-получателя ответа не содержится в CAM-таблице маршрутизатора, поток буден направлен всем элементам ИТКС, входящим в виртуальный компонент ИТКС элемента-получателя ответа (рис. 2.11).
Рис. 2.11. Граф процесса ответа на запрос элементу
другого виртуального компонента ИТКС
В результате такого перенаправления элементы ИТКС начнут получать и обрабатывать критические объемы трафика, что вызовет отказ компонента ИТКС, что приведет к нарушению доступности информации и ресурсов в ИТКС.
2. 4 Некорректное использование и атаки на протокол stp, как причина возникновения эффекта «unicast flooding»
Протокол связующего дерева (англ. Spanning Tree Protocol, STP) и соответствующий алгоритм (англ. Spanning Tree Algorithm, STA) предназначен для построения ИТКС, использующих параллельные соединения [210]. При этом гарантируется, что дублирующие пути во время штатного функционирования основного пути будут недоступны, а в случае нарушения работы основного пути будет открыт один из дублирующих. Таким образом, решается критическая задача устранения петель в топологии ИТКС с избыточными соединениями, когда маршрутизаторы соединенные в «кольцо», бесконечно и неконтролируемо передавая трафик друг-другу, способны исчерпать пропускную способность каналов связи компонента ИТКС и полностью парализовать его работу [210]. В этом случае использование протокола STP позволяет логически скорректировать потенциально опасную топологию ИТКС (рис.. 2.12 а) и сделать недоступными дублирующие связи внутри компонента ИТКС (рис. 2.12 б). В момент обновления логической топологии каждый элемент ИТКС изменяет состояние своих портов по схеме блокирован → слушает → обучается → передает, в которой только в последнем состоянии порт будет передавать все фреймы.
Рис. 2.12. Ячеистая топология ИТКС до и после работы протокола STP
Однако оптимальная логическая топология ИТКС определяется в первую очередь исходя из физической топологии ИТКС, которая может быть изменена в процессе функционирования ИТКС. В этом случае необходимо повторно определить новую оптимальную логическую топологию ИТКС, предварительно сообщив корневому элементу (sr) о новом подключенном элементе (snew) с помощью специального сообщения об изменении топологии (англ. Topology Change Notification, TCN). Получив такое сообщение, коммутатор уменьшит время актуальности своей CAM-таблицы с 5 минут до 15 секунд [193], по истечении которых очистит таблицу коммутации (рис. 2.13) и снова начнет процесс «обучения». Такая последовательность действий определена штатной работой коммутатора и в общем случае не наносит ущерба ИТКС.
Рис. 2.13. Состояние ИТКС после добавления нового элемента
Подобное обновление должно происходить только в случае кардинальных изменений в физической топологии ИТКС, например, таких как добавление или удаление нового коммутатора, изменение конфигурации ИТКС или обновление оборудования [193]. Отсюда очевидно, что на работу STA не должно влиять изменение состояния оконечного оборудования (сnew) (принтеров, персональных компьютеров, серверов), не участвующего в коммутации.
В случае ненадлежащей конфигурации портов коммутатора, включение или отключение оконечного оборудования, подключенного к ним, будет вызывать устаревание CAM-таблиц коммутаторов на всем пути вплоть до корневого (рис. 2.14). И однократные штатные одноадресные штормы в ИТКС превратятся в постоянную неконтролируемую передачу фактически вредоносного трафика элементам ИТКС, что вызовет отказ отдельных компонентов или всей ИТКС [204].
Рис. 2.14. Состояние ИТКС после добавления нового элемента в случае некорректного использования протокола STP
Такая уязвимость протокола STP может быть использована злоумышленником для перевода одного или нескольких коммутаторов ИТКС в постоянное состояние «обучения» и создания непрерывного эффекта «unicast flooding». Для усиления действия эффекта злоумышленник так же может стать источником вредоносного трафика, критические объем которого и вызовет отказ компонента ИТКС, что приведет к нарушению доступности информации и ресурсов в ИТКС.