Когда вы настраиваете порты на коммутаторе (SW1) как доверенные, вы влияете на то, какие служебные кадры и сообщения сможет “принять” сеть. Чаще всего это нужно, чтобы защитные механизмы на уровне канального уровня (например, DHCP Snooping) работали корректно и при этом снижали риск подмены источников - от фальшивого DHCP-сервера до атак на канальном уровне.
Ниже разберем практический подход: что значит “доверенный порт” на магистрали, как понять, какие порты действительно должны быть доверенными, и как проверить результат.
Что дает “доверенный порт” на коммутаторе
Многие механизмы защиты на уровне 2 работают через идею “порта и источника”:
- на ненадежные порты сеть обычно не допускает ответы серверов (или отбрасывает часть сообщений);
- на доверенные порты разрешается нужный тип трафика от действительно авторизованных узлов.
Типичный пример - DHCP Snooping: серверные ответы DHCP, пришедшие на ненадежный порт, отбрасываются, чтобы злоумышленник не мог “встать” вместо DHCP-сервера. Логику “trusted vs untrusted” описывают в материалах по защите канального уровня и на практике применяется именно так: доверять портам, где реально подключен сервер, и не доверять остальным. Это же направление отражено в обзорах атак канального уровня (подмена DHCP, перехват и отказ в обслуживании) и мерах защиты. Источник: Wikipedia, разделы про атаки канального уровня и защитные механизмы, включая DHCP Snooping (https://ru.wikipedia.org/wiki/%D0%90%D1%82%D0%B0%D0%BA%D0%B8_%D0%BA%D0%B0%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B3%D0%BE_%D1%83%D1%80%D0%BE%D0%B2%D0%BD%D1%8F).
Когда магистральный порт на SW1 должен быть доверенным
Магистральный порт (trunk) обычно несет трафик нескольких VLAN между коммутаторами. На SW1 он становится “входом” для служебных сообщений, которые должны поступать от соседнего коммутатора или от инфраструктурных узлов.
Делайте порт доверенным в этих сценариях:
1. На другой стороне магистрали подключен настоящий DHCP-сервер или relay, который должен выдавать клиентам адреса.
2. На магистрали идет трафик, который должен быть разрешен защитным механизмом на уровне 2 (по аналогии с DHCP Snooping и подобными проверками).
3. Вы используете защиту, где требуется явно указать доверенные направления для корректной работы сервисов сети.
Не делайте магистраль доверенной “на всякий случай”. Доверие расширяет поверхность - злоумышленнику проще “протащить” нежелательные ответы, если он попадет в VLAN, который проходит по trunk.
Практический порядок действий
Шаг 1. Определите, какие VLAN ходят по магистрали SW1
На trunk вы пропускаете список VLAN (allowed VLAN). Это важно, потому что защитные политики на коммутаторе применяются по VLAN.
Проверка на SW1 (идея команды зависит от ОС/вендора):
- посмотреть настройки trunk: allowed VLAN
- посмотреть режим порта: trunk/access
- убедиться, что native VLAN задан осмысленно (native VLAN часто участвует в обмене тегами)
Шаг 2. Выделите “источник сервиса”
Найдите, где реально “живет” нужный сервис:
- DHCP сервер
- DHCP relay
- другой узел, чьи ответы должны приниматься
Если этот источник идет через магистраль, тогда доверие нужно именно магистральному порту SW1 к соседу. Если источник локально на SW1, то доверие может требоваться к другому порту, а trunk оставляют ненадежным.
Шаг 3. Включите защитный механизм (если он еще не включен)
Часто настройка “trusted” работает в паре с механизмом защиты. Например, DHCP Snooping должен быть активирован, иначе смысла в доверии может не быть.
Смысл подхода описан в защитных рекомендациях по DHCP Snooping: порты делят на доверенные и ненадежные, а DHCP ответы отбрасывают на ненадежных портах. Источник: Wikipedia про атаки канального уровня и описание DHCP Snooping (https://ru.wikipedia.org/wiki/%D0%90%D1%82%D0%B0%D0%BA%D0%B8_%D0%BA%D0%B0%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B3%D0%BE_%D1%83%D1%80%D0%BE%D0%B2%D0%BD%D1%8F).
Шаг 4. Назначьте магистральный порт SW1 как trusted
На SW1:
- зайдите в интерфейс trunk порта
- включите параметр доверия для port
Синтаксис команды зависит от платформы. Логика одна - задать статус trusted именно для магистрального порта, который несет трафик к нужному узлу/соседу.
Шаг 5. Зафиксируйте не-доверие для пользовательских access-портов
Если к SW1 подключены пользователи или endpoints, оставляйте их access порты ненадежными. Так снижается риск подмены источников на уровне канального уровня.
Таблица: что доверять и что нет
| Тип порта на SW1 | Что обычно там проходит | Делать trusted? | Почему |
|---|---|---|---|
| Trunk к соседнему коммутатору | трафик VLAN, служебные сообщения для сервисов | Да, если там реально “источник” сервиса (например, DHCP) | Иначе защита может блокировать корректные ответы |
| Trunk к узлу, где стоит DHCP relay/сервер | DHCP запросы/ответы, служебные операции | Да | Защитные механизмы ожидают разрешенный путь от доверенного источника |
| Access к пользователям/камерам/принтерам | пользовательский трафик и запросы клиентов | Нет | Снижает риск подмены (в том числе DHCP/ARP-подобные сценарии) |
| Access к оборудованию администрирования | иногда служебный трафик управления | Только если это действительно контролируемый источник | Trusted расширяет доверенную поверхность |
Как проверить, что настройка сработала
Проверки делайте по этапам:
1. Состояние trunk: VLAN действительно проходят по магистрали.
2. Статусы trusted/untrusted: у нужного trunk порта должен быть установлен trusted, у остальных - нет.
3. Поведение клиентов:
- DHCP адреса выдаются без ошибок
- клиенты стабильно получают параметры сети
4. Журналы:
- отсутствие отбрасываний DHCP-сообщений с доверенного направления
- отсутствие признаков, что клиенты получают “не те” ответы
Если вы видите, что DHCP перестал работать после смены trust, почти всегда причина одна из трех:
- trusted назначили не тому trunk-порту
- VLAN сервиса не включены в allowed VLAN trunk
- защитный механизм не активен или активен, но параметры применяются не к тем VLAN
Типичные ошибки
- Доверяют все магистрали без разбора. Это повышает риск подмены в сети.
- Не совпадают VLAN: trunk пропускает одни VLAN, а сервис работает в другой.
- trusted включают на access-порте пользователя, а не на направлении, где реально находится серверный источник.
- Считают, что “доверенный порт” сам по себе не влияет. На практике он работает в связке с защитными механизмами уровня 2 и влияет на принятие сервисных ответов.
Почему это важно с точки зрения безопасности сети
Атаки канального уровня часто опираются на протоколы и поведение второго уровня OSI, где уязвимости проявляются через подмену источников и отказ в обслуживании. В частности, подмена DHCP и другие сценарии упомянуты в обзорах атак канального уровня, а защитные функции вроде DHCP Snooping используют логику trusted/untrusted именно для перекрытия таких путей. Источник: Wikipedia, атаки канального уровня (https://ru.wikipedia.org/wiki/%D0%90%D1%82%D0%B0%D0%BA%D0%B8_%D0%BA%D0%B0%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B3%D0%BE_%D1%83%D1%80%D0%BE%D0%B2%D0%BD%D1%8F).
Вывод
Чтобы “настроить магистральные порты на SW1 как доверенные порты” без лишнего риска:
1. Определите, где реально находится источник нужных сервисных ответов.
2. Сделайте trusted только на тех trunk-портах SW1, через которые этот источник доступен по нужным VLAN.
3. Для access-портов оставляйте ненадежность.
4. Проверьте работу клиентов и журналы отбрасывания DHCP/служебных сообщений.
Так вы одновременно сохраняете корректную работу сервисов в сети и уменьшаете вероятность атак на уровне канала.