Протокол связующего дерева stp
Часто, для обеспечения стабильности работы сети в случае проблем со связью между коммутаторами (выход порта из строя, обрыв провода), используют избыточные линии – дополнительные соединения (рис. 8.2). Идея простая – если между коммутаторами по какой-то причине не работает одна линия, то используется запасная.
Рисунок 8.2. Локальная сеть с избыточной линией
Теперь представим себе такую ситуацию: два коммутатора S0 и S1 соединены двумя физическими линиями. Один из узлов, подключенных к S0, отправляет в сеть широковещательный кадр. Коммутатор S0, получив такой кадр, направит его во все остальные свои порты. Коммутатор S1 сделает то же самое, в итоге кадр по второй линии вернётся на S0. Тот снова отправит кадры на все свои порты, в т. ч. и коммутатору S1 и т.д. В результате сеть блокируется, т.к. коммутаторы будут бесконечно заниматься пересылкой одного и того же кадра. Это называют широковещательным штормом (broadcast storm).
Чтобы избежать широковещательного шторма при такой настройке сети, используется Spanning Tree Protocol (STP). Его основная задача – предотвращение петель на втором уровне. Задача решается путём отключения избыточных линий, пока они не нужны. Для этого STP использует алгоритм STA(Spanning Tree Algorithm), результатом работы которого является граф в виде дерева (связный и без простых циклов).
Для обмена информацией между собой коммутаторы используют специальные пакеты BPDU (Bridge Protocol Data Units), которые бывают двух видов: конфигурационные (Configuration BPDU) и топологические (TopologyChange Notification BPDU). Первые регулярно рассылаются корневым коммутатором и ретранслируются остальными и используются для построения топологии, вторые, как понятно из названия, отсылаются в случае изменения топологии сети (подключении\отключении коммутатора или обрыве линии). Конфигурационные BPDU содержат несколько полей, остановимся на самых важных:
Bridge ID – идентификатор отправителя,
Root Bridge ID – идентификатор корневого коммутатора,
Port ID – идентификатор порта, из которого отправлен данный пакет,
Root Path Cost – стоимость маршрута до корневого коммутатора.
Так как устройства не знают и не хотят знать своих соседей, никаких отношений (смежности/соседства) они друг с другом не устанавливают. Они шлют BPDU из всех работающих портов на групповой Ethernet-адрес 01-80-c2-00-00-00 (по умолчанию каждые две секунды), который прослушивают все коммутаторы со включенным STP.
На первом этапе выбирается так называемый корневой коммутатор (здесь применяется термин «мост») – root bridge. Это устройство, которое STP считает точкой отсчета, центром сети; все дерево STP сходится к нему. Выбор базируется на таком понятии, как идентификатор моста (Bridge ID). Bridge ID это число длиной в восемь байт, которое состоит из приоритета (Bridge Priority от 0 до 65535, по умолчанию 32768+номер VLAN) и MAC-адреса устройства. В начале выборов каждый коммутатор считает себя корневым, о чем и заявляет всем остальным с помощью BPDU, в котором представляет свой идентификатор как ID корневого коммутатора (Root Bridge ID). При этом если он получает BPDU с меньшим Bridge ID, он перестает считать себя корневым и начинает анонсировать полученный Bridge ID в качестве корневого. В итоге, корневым оказывается тот коммутатор, чей Bridge ID меньше всех.
Такой подход таит в себе довольно серьезную проблему. Дело в том, что, при равных значениях приоритета (а они равные, если не менять ничего) корневым выбирается самый старый коммутатор, так как MAC-адреса прописываются на производстве последовательно, соответственно, если используется оборудование одного производителя, то чем MAC меньше, тем устройство старше. Понятное дело, это ведет к падению производительности сети, так как старое устройство, как правило, имеет худшие характеристики. Подобное поведение протокола следует пресекать, выставляя значение приоритета на желаемом корневом коммутаторе вручную.
После того, как коммутаторы обменялись идентификаторами и выбрали корневой, каждый из остальных коммутаторов должен найти один, и только один порт, который будет вести к корневому (Root port). Чтобы понять, какой порт лучше использовать, каждый некорневой коммутатор определяет стоимость маршрута от каждого своего порта до корневого. Эта стоимость определяется суммой стоимостей всех линий, которые нужно пройти кадру, чтобы дойти до корневого коммутатора. В свою очередь, стоимость линии определяется по его скорости – чем выше скорость, тем ниже стоимость.
Процесс определения стоимости маршрута связан с полем BPDU Root PathCost. Корневой коммутатор посылает BPDU с полем Root Path Cost, равным нулю. Ближайший коммутатор смотрит на скорость своего порта, куда BPDU пришел, и добавляет стоимость (например, при 100Мбит/с – 19, при 1Гбит/с – 4). Далее этот второй коммутатор посылает этот BPDU нижестоящим коммутаторам, но уже с новым значением Root Path Cost, и далее по цепочке вниз. Если имеют место одинаковые стоимости, корневым выбирается порт с меньшим номером.
Далее выбираются назначенные порты (Designated port). Из каждого конкретного сегмента сети должен существовать только один путь по направлению к корневому коммутатору, иначе это петля. В данном случае имеем в виду физический сегмент, в современных сетях без концентраторов это, грубо говоря, просто провод. Назначенным портом выбирается тот, который имеет лучшую стоимость в данном сегменте. У корневого коммутатора все порты – назначенные.
И вот уже после того, как выбраны корневые и назначенные порты, оставшиеся блокируются (Non-Designated port), таким образом, разрывая петлю.
В классической реализации STP существует пять различных состояний портов:
блокировка (blocking) – блокированный порт не шлет ничего. Это состояние предназначено, как говорилось выше, для предотвращения петель в сети. Блокированный порт, тем не менее, слушает BPDU (чтобы быть в курсе событий, это позволяет ему, когда надо, разблокироваться и начать работать)
прослушивание (listening) – порт слушает и начинает сам отправлять BPDU, кадры с данными не отправляет.
обучение (learning) – порт слушает и отправляет BPDU, а также вносит изменения в CAM- таблицу, но данные не перенаправляет.
перенаправление\пересылка (forwarding) – этот может все: и посылает\принимает BPDU, и с данными оперирует, и участвует в поддержании таблицы mac-адресов. То есть это обычное состояние рабочего порта.
отключен (disabled) – состояние administratively down, отключен командойshutdown. Понятное дело, ничего делать не может вообще, пока не будет включен вручную.
При включении (а также при подключении линии) все порты на устройстве с STP проходят вышеприведенные состояния именно в таком порядке (за исключением disabled-портов). Сначала 15 секунд (по умолчанию) порт пребывает в состоянии прослушивания – он смотрит BPDU, попадающие в него, выясняет свое положение в сети, потом переходит к обучению еще на 15 секунд – пытается выяснить, какие MAC-адреса имеются на линии, и потом, убедившись, что ничего он не поломает, начинает уже свою работу. Итого, мы имеем целых 30 секунд простоя, прежде чем подключенное устройство сможет обмениваться информацией со своими соседями. Если сюда включить время загрузки ОС коммутатора, то получится ещё дольше.
Для современных компьютеров даже 30 секунд – большой промежуток времени. ОС загружается за 10-20 секунд и тут же пытается получить сетевые настройки от DHCP-сервера. Не получив ответа, она прописывает IP-адрес автонастройки (169.254.x.x). Чтобы избежать подобной ситуации, на коммутаторах используется особый режим порта – portfast. При подключении устройства к такому порту, он, минуя промежуточные стадии, сразу переходит кforwarding-состоянию. Само собой, portfast следует включать только на интерфейсах, ведущих к конечным устройствам (рабочим станциям, серверам, телефонам и т.д.), но не к другим коммутаторам.
Rapid Spanning Tree Protocol(RSTP)
Первая реализация протокола STP (802.1d) была разработана в 1985 году, и в то время перестройка топологии в течение >30 секунд считалось нормальным. Но время идёт, скорости передачи данных растут, а в месте с ними растут и требования к подобного рода задержкам. В 2001 году был представлен новый стандарт RTSP (Rapid STP, 802.1w). Сравнение между STP и RSTP приведено в таблице 8.1.
STP |
RSTP |
В уже сложившейся топологии только корневой коммутатор шлет BPDU, остальные ретранслируют |
Все коммутаторы шлют BPDU в соответствии с Hello-таймером |
Состояния портов |
|
|
|
Роли портов |
|
|
|
Таймеры |
|
|
Используется процесс предложения и соглашения (proposal andagreement)
|
Механизм работы |
|
При обнаружении изменения топологии, коммутатор извещает корневой коммутатор, который, в свою очередь, требует от всех остальных очистить их записи о текущей топологии в течение Forward delay timer |
Обнаружение изменений в топологии влечет немедленную очистку записей |
Если не-корневой коммутатор не получает Hello- пакеты от корневого в течение Max Age, он начинает новые выборы |
Начинает действовать, если не получает BPDU в течение 3 Hello-интервалов |
Порта последовательное проходит через состояния Blocking (20 сек) – Listening (15 сек) – Learning (15 сек) – Forwarding |
Быстрый переход к Forwarding для p2p и Edge-портов |
Одним из главных отличий являются роли портов: роль заблокированного порта разделили на две новые роли Alternate (резервный корневой порт) иBackup (резервный назначенный порт). Меняется поведение системы в целом: вместо реактивной (которая начинает искать решение проблемы только после того, как она случилась) система становится проактивной, заранее просчитывающей “пути отхода” еще до появления проблемы. Затем, чтобы в случае отказа основной переключиться на резервную линию, RSTP не нужно заново просчитывать топологию, он просто переключится на запасную, заранее просчитанную линию.
Другим отличием является введение понятия пограничный порт (p2p иEdge) для конечных устройств. Пограничные порты, как и раньше, работают в режиме portfast и при включении сразу переходят к Forwarding-состоянию.Shared-порты работают по старой схеме с прохождением через состояния BLK – LIS – LRN – FWD. А вот на p2p-портах RSTP используется процесс предложения и соглашения (proposal and agreement). Коммутатор справедливо считает, что если порт не обозначен, как пограничный, значит, на нем только два устройства- он и другой коммутатор. Вместо того чтобы ждать входящих BPDU, он сам пытается связаться с коммутатором на том конце провода с помощью специальныхproposal BPDU, в которых, конечно, есть информация о стоимости маршрута к корневому коммутатору. Второй коммутатор сравнивает полученную информацию со своей текущей и принимает решение, о чем извещает первый коммутатор посредством agreement BPDU. Так как весь этот процесс теперь не привязан к таймерам, всё происходит очень быстро: только подключили новый коммутатор, и он практически сразу вписался в общую топологию и приступил к работе.
Безопасность сети на канальном уровне
Безопасность канального уровня можно считать синонимом безопасности локальной сети. Как правило, атаки на канальном уровне предполагают, что злоумышленник находится в локальной сети, либо есть некий посредник, который умышленно или неумышленно помогает выполнению атак.
Задача злоумышленника получить доступ к определенным ресурсам, информации или, как минимум, нарушить нормальную работу сети. Как правило, атаки выполняются в комплексе, а не по одной.
Опасность проблем в безопасности на канальном уровне заключается в том, что взломав сеть на канальном уровне, атакующий может перешагнуть через средства защиты на более высоких уровнях. Удачное выполнение атаки может быть не целью, а средством получить что-то большее.
Защита CAM-таблицы
Одним из очевидных средств защиты на канальном уровне является ограничение количества MAC-адресов, связанных с данным портом, с помощью средства Port Security. Например, администратор знает, что к данному порту коммутатора должно быть подключено только одно конечное устройство, он указывает это в настройках порта. Более того, зная конкретный MAC-адрес пользователя, можно привязать его к этому порту вручную или автоматически (адрес подключенного в данный момент устройства).
Далее задаётся поведение в случае нарушения правила: порт либо отключается, и потом его нужно поднимать вручную (shutdown), либо отбрасывает пакеты с незарегистрированного MAC-адреса и пишет об этом в консоль (restrict), либо просто отбрасывает пакеты (protect).
Помимо очевидной функции у данного средства есть другая, возможно, более важная: предотвращать атаки. Одна из возможных – истощение CAM-таблицы. С компьютера злоумышленника рассылается огромное число кадров, возможно, широковещательных, с различными значениями в поле MAC-адрес отправителя. Первый же коммутатор на пути начинает их запоминать. Рано или поздно память коммутатора заполнится, и дальнейшее поведение коммутатора при этом может быть различным. Самое опасное из них с точки зрения безопасности: коммутатор может начать рассылать все кадры, приходящие на него, как широковещательные, потому что MAC-адрес получателя не известен (или уже забыт), а запомнить его уже просто некуда. В этом случае сетевая карта злоумышленника будет получать все кадры, летающие в сети.
Защита DHCP-сервера
Другая возможная атака нацелена на DHCP-сервер. Как известно, DHCPобеспечивает клиентские устройства всей нужной информацией для работы в сети: IP-адресом, маской подсети, адресом шлюза, DNS-сервера и пр. Злоумышленник может поднять собственный DHCP, который в ответ на запрос клиентского устройства будет отдавать в качестве шлюза по умолчанию (а также, например, DNS-сервера) адрес подконтрольной злоумышленнику машины. Соответственно, весь трафик, направленный за пределы подсети обманутыми устройствами, будет доступен для изучения злоумышленнику (типичная man-in-the-middle атака).
Чтобы защититься от подобного вида атак, используется инструмент под названием DHCP snooping. Идея совсем простая: указать коммутатору, на каком порту подключен настоящий DHCP-сервер, и разрешить DHCP-ответы только с этого порта, запретив для остальных.
Либо такой вариант: злоумышленник генерирует кучу DHCP-запросов с поддельными MAC-адресами и DHCP-сервер на каждый такой запрос выдаёт IP-адрес до тех пор, пока не истощится пул.
Защита от подмены IP-адреса
После включения DHCP Snooping’а, он начинает вести у себя базу соответствия MAC и IP-адресов устройств, которую обновляет и пополняет за счет прослушивания DHCP-запросов и ответов. Эта база позволяет нам противостоять еще одному виду атак – подмене IP-адреса (IP-Spoofing). При включенном IPSource Guard, каждый приходящий пакет может проверяться на:
соответствие IP-адреса источника адресу, полученному из базы DHCPSnooping (иными словами, IP-адрес закрепляется за портом коммутатора);
соответствие MAC-адреса источника адресу, полученному из базы DHCPSnooping.
Само собой, для работы IP Source Guard требуется включенный DHCPSnooping, а для контроля MAC-адресов должен быть включен Port Security.
Защита от подмены MAC-адреса
Как уже известно, чтобы узнать MAC-адрес устройства по его IP-адресу, используется протокол ARP. Схема работы протокола уязвима для атаки, называемой ARP-poisoning или ARP-spoofing: вместо настоящего узла с искомым адресом отвечает узел злоумышленника, заставляя, таким образом, не предназначенный ему трафик следовать через него.
Для предотвращения такого типа атак используется инструмент под названием Dynamic ARP Inspection. Схема работы похожа на схему DHCP-Snooping’а: порты делятся на доверенные и недоверенные. На недоверенных каждый ARP-ответ подвергаются анализу: сверяется информация, содержащаяся в этом пакете, с той, которой коммутатор доверяет (либо статически заданные соответствия MAC-IP, либо информация из базы DHCP Snooping). Если не сходится, пакет отбрасывается и генерируется сообщение в syslog.
Защита VLAN
Атаки на VLAN становятся возможны чаще всего благодаря неправильным настройкам.
Пример: порты коммутаторов по умолчанию настроены в режим DynamicAuto. Такой порт готов изменить своё состояние на Trunk, если соседний порт также будет установлен в режим Trunk. Подключение компьютера к такому порту позволяет потенциальному злоумышленнику получить доступ к тем VLAN, которым доступа у него быть не должно. Для защиты рекомендуется все порты переводить в режим Nonegotiate и затем настраивать вручную.
Подобная мера также может защитить от другого способа атаки: дважды тегированного трафика. Этот способ также связан с работой протокола DTP. Злоумышленник посылает дважды тегированный кадр (рис. 8.3). Первая метка удалится на первом коммутаторе, вторая – на втором. В итоге жертва получит этот нежелательный кадр. Этот способ может обеспечить только однонаправленную передачу данных. Также в целях защиты от данного способа атаки рекомендуется по возможности не использовать Native VLAN, если его использование необходимо, то задать другой номер (не 1).
Существуют способ атаки через VTP. Подключившись к транковому порту коммутатора, злоумышленник может направить в сеть VTP-сообщение о том, что «не настроено ни одного VLAN». Получившие такое сообщение коммутаторы удалят все свои VLAN во всём VTP-домене. Такая атака может быть вызвана непреднамеренно: при подключении в сеть неправильно настроенного коммутатора.
Защита STP
Протокол STP также может быть подвержен атаке. Для её совершения злоумышленник отправляет ложные топологические BPDU-пакеты. После получения такого пакета корневой коммутатор начнёт перестройку топологии, что может привести к отказу сети (DoS атака). Также злоумышленник может получать кадры, не предназначенные ему.
Существует несколько инструментов, позволяющих защитить STP:
BPDU Filtering запрещает на интерфейсе приём и отправку BPDU-пакетов.
BPDU Guard запрещает прохождения BPDU-пакетов с интерфейсов, работающих в режиме portfast. При получении такого пакета интерфейс отключается.
Root Guard отключает интерфейс (переводит в состояние root-inconsistent), если с него был получен BPDU-пакет со значением Root Bridge ID лучше (меньше), чем текущий. После того как порт перестает получать BPDU, он переходит в нормальное состояние.
Loop Guard обеспечивает дополнительную защиту от возникновения петель. Подобная защита может понадобиться, когда блокированный порт в избыточной топологии ошибочно переводится в состояние forwarding. В случае использования Loop Guard порт после прекращения получения пакетов BPDU переводится в состояние loop-inconsistent и остаются по-прежнему блокированным.
Unidirectional Link Detection обнаруживает однонаправленные связи и переводит соответствующий интерфейс в режим err-disable. В таком состоянии порт остаётся до того, как его включат вручную, или до истечения таймера. Однонаправленная связь имеет место, когда один коммутатор может отправлять пакеты соседу, но ответы от него не получает.