Кратко

  • RFC 5418 описывает безопасность CAPWAP как набор попарных связей между беспроводной станцией, службой AAA, контроллером доступа и Wireless Termination Point. Защищённые соседние соединения сами по себе не создают сквозного разрешения.
  • При предварительно заданном общем ключе полномочия могут распространяться на целый класс устройств. Один лишь ключ не всегда позволяет отличить контроллер доступа от точки завершения беспроводного соединения.
  • Действительный сертификат, защищённый канал управления и разрешение на подключение к конкретной сети — разные факты. Регистрацию устройства, его роль, ключи AAA и фактический путь данных нужно проверять отдельно.

Успешное соединение не определяет допустимую роль

Подключение WTP к AC может пройти проверку канала, но само по себе не устанавливает, к какой сети относится устройство и какую роль ему разрешили. В модели RFC 5418 это отдельные решения: удостоверить партнёра по каналу, проверить его роль и подтвердить регистрацию в конкретном развертывании.

RFC 5418 предлагает конкретную модель такого разделения. Опубликованный в 2009 году информационный документ анализирует дополнительную уязвимую поверхность, возникающую при разделении обычной точки доступа на два элемента: WTP на беспроводном краю и Access Controller (AC) в другом месте. Обмены, которые раньше происходили внутри одного устройства, теперь идут через сеть третьего уровня. Согласно документу, безопасность зависит от промежуточной сети и от того, как функции распределены между WTP и AC.

Область анализа ограничена CAPWAP в среде IEEE 802.11. Это не обзор внедрённых продуктов, не отчёт об атаке и не стандарт Интернета. Ценность документа — в разделении вопросов, которые схема сети может слить в одну подпись «защищено»: кто находится на другом конце? Какую роль он вправе выполнять? Какие ключи ему передаются? По какому маршруту на самом деле идут данные клиента?

Методологическая рамка этой статьи — Note 65 Хенга Лу «Running-Code Primacy»: сопоставлять заявления с тем, что системы действительно исполняют и что оператор способен проверить. Записка посвящена проектированию систем координации Интернета, а не требованиям к беспроводной безопасности. Здесь её принцип означает, что схема или текст политики не заменяют доказательства о действующих учётных данных, проверках ролей, связях контроллеров и маршрутах передачи.

CAPWAP добавляет доверительные отношения

В обычной точке доступа одно устройство соединяет беспроводной край с проводной сетью. CAPWAP разделяет эту работу: WTP передаёт и принимает беспроводной трафик, а AC выполняет управление и функции проводной стороны. Это упрощает централизованное управление и допускает разные схемы размещения филиалов, но добавляет новые доверительные связи.

Упрощённый пример в RFC 5418 включает как минимум семь связей или передач ключевого материала:

Шаг Связь или передача Что она устанавливает в примере
1 WTP–AC Связь CAPWAP между узлами
2 AC–AAA Аутентифицированное соединение контроллера со службой аутентификации
3 Станция–AAA Аутентификация EAP и создание ключевого материала
4 AAA → AC Передача контроллеру Pairwise Master Key
5 AC–станция Четырёхстороннее рукопожатие и временные ключи
6 AC → WTP Передача временного ключа при децентрализованном шифровании
7 WTP–станция Защита беспроводного соединения клиента

Это не единое сквозное рукопожатие. RFC 5418 подчёркивает, что речь идёт о попарных отношениях доверия. Станция может доверять AAA, AAA — AC, а AC — WTP, но из этого не следует, что станция должна автоматически доверять данному WTP. Скомпрометированный WTP может сохранить связь с AC и при этом передавать станции ложные сведения о сети. Компрометация узла в иерархии способна затронуть нижестоящие устройства.

Это описание структурного риска, а не утверждение, что каждая сеть скомпрометирована. Проверка должна проследить каждую идентичность и каждый ключ до предоставленных полномочий и оценить, что скомпрометированный узел может сделать с этими правами.

Что доказывает общий ключ — и чего он не доказывает

RFC 5418 разделяет аутентификацию и авторизацию. Аутентификация отвечает на вопрос, может ли другая сторона подтвердить личность или владение учётными данными. Авторизация определяет, к каким ресурсам и действиям ей разрешён доступ.

Для предварительно заданных общих ключей документ описывает широкую, грубую модель авторизации: знание ключа относит устройство к доверенному классу. Разные ключи могут разделять классы, однако сам ключ класса не всегда устанавливает, является ли его обладатель AC или WTP. Если оба типа устройств используют один секрет, его обладатель может заявить любую из ролей, если другой механизм не ограничивает запрос.

Риск растёт, когда секрет распространяется шире, чем показывает инвентаризация. Ключ, скопированный в заводскую подготовку, рабочие заметки, конфигурацию контроллера и процедуру замены, перестаёт быть свойством одного устройства и становится общей рабочей возможностью. Важно, кто может получить его, насколько строго разделены классы устройств, как проводится ротация и проверяет ли принимающая сторона заявленную роль. RFC 5418 не утверждает, что конкретный оператор использует такие методы; это вопросы контроля, которые должен выяснить сам оператор.

Сертификаты допускают более точные проверки, но документ не считает одно лишь их наличие полной политикой регистрации. RFC 5418 рассматривает имя субъекта с MAC-адресом устройства и биты Extended Key Usage, которые могут разделять роли AC и WTP. Это помогает, только если принимающее устройство проверяет, что имя разрешено для данной сети, и строго применяет назначение роли. Разрешение общего Extended Key Usage может стереть различие ролей, если не проверяется имя субъекта.

Сертификат производителя доказывает происхождение учётных данных, но не отвечает на вопрос оператора: какой AC должен принять WTP именно в этой сети и какие WTP входят в её состав? RFC 5418 прямо отмечает, что авторизация на основе сертификатов и конфигурация без ручного вмешательства совместимы не полностью. В анализе предполагается, что WTP распознаёт правильный AC, а AC — правильные WTP; механизм первоначального выбора не рассматривается. Эту границу необходимо явно сохранять при закупках и проверках безопасности.

У AAA есть отдельный владелец контроля

В упрощённом примере AC выступает аутентификатором и связывается с сервером AAA по RADIUS или Diameter. RFC 5418 предупреждает: неуникальные или слабые долгосрочные данные для связи AC–AAA могут серьёзно подорвать безопасность всего CAPWAP-развёртывания. Документ рекомендует взаимную аутентификацию, конфиденциальность и целостность, а также ссылается на рекомендации по управлению ключами AAA в RFC 4962.

Эта рекомендация защищает другую связь, а не WTP–AC. Действительная сессия DTLS между ними не подтверждает автоматически сервер AAA, выбранный контроллером. Надёжный метод EAP между станцией и AAA не доказывает, что результирующие ключи получит только нужный контроллер. Успешное беспроводное рукопожатие также не показывает, что ключ передан нужному WTP. Оператор должен назначить владельца каждой учётной записи и каждого решения об авторизации.

Есть и организационная сторона. Команда беспроводной сети может регистрировать устройства, служба безопасности — управлять сертификатами, а команда идентификации — обслуживать AAA. Каждая может сообщить, что её соединение защищено, но никто не проверит стык между этими гарантиями. Полезный реестр связывает каждое отношение с издателем учётных данных, проверяющей стороной, предоставляемой ролью и доказательством принадлежности к сети.

Туннель управления не показывает путь данных

Одних идентичностей и распределения ключей недостаточно, чтобы описать архитектуру. RFC 5418 отделяет управление от передачи пользовательских данных и рассматривает варианты Split MAC, Local MAC и другие схемы. При Local MAC большую часть функций MAC выполняет WTP, а кадры данных обычно мостятся в локальной сети. Термины CAPWAP не задают жёстко все детали туннелирования данных.

RFC 5415 проводит границу на уровне протокола: Discovery Request и Discovery Response передаются без DTLS, чтобы WTP мог найти возможные контроллеры. Остальные управляющие сообщения CAPWAP должны использовать DTLS. Защита пакетов данных необязательна и зависит от политики AC. Поэтому защищённое соединение управления не доказывает, что клиентские данные проходят через AC, идут по отдельному защищённому каналу или передаются локально в проводную сеть.

Выбор меняет и место исполнения политики. Централизованная передача даёт контроллеру точку контроля, но добавляет маршрут и зависимость. Локальное мостовое соединение избавляет от возврата всего трафика к удалённому контроллеру, но переносит сегментацию, проверку и наблюдение ближе к краю сети и подключённой проводной инфраструктуре. Это архитектурный компромисс, а не универсальная рекомендация. Важно проверить, что фактический маршрут соответствует политике и плану реагирования на инциденты.

Шифрование тоже не устраняет все угрозы. RFC 5418 обсуждает истощение ресурсов, пассивное наблюдение, анализ трафика и вмешательство с отбрасыванием пакетов. Среди угроз вне CAPWAP упоминаются подмена DNS или DHCP и отравление ARP-кэша. Эти ограничения не отменяют пользы DTLS; они показывают, что защищает этот механизм и где нужен другой владелец контроля.

Проверка должна идти по графу отношений

Практическая проверка CAPWAP начинается с реальной топологии и отвечает на вопросы:

  1. Какие AC принимает каждый WTP и как подтверждается принадлежность контроллера к этой сети?
  2. Какие WTP принимает каждый AC и как различаются их роли?
  3. Достаточно ли общие ключи ограничены назначенным классом? Кто может получить, установить, заменить или отозвать их?
  4. Какие проверки имени и роли фактически выполняют AC и WTP? Что происходит, если сертификат действителен, но устройства нет в списке разрешённых?
  5. Какие учётные данные AC использует для AAA и где фиксируются передача ключей и её авторизация?
  6. Идут ли данные клиента через AC или мостятся локально? Где находятся шифрование, сегментация, проверка и журналирование?
  7. Какие риски сохраняются при DTLS: истощение ресурсов, анализ трафика, отбрасывание пакетов, манипуляция поиском контроллера или атака на соседнюю LAN?

Так фраза «в WLAN используются сертификаты» превращается в проверяемые утверждения. При замене точки доступа нужно обновить инвентаризацию и ролевую авторизацию, а не только проверить подпись производителя. При переводе филиала на локальную передачу план применения политики и наблюдения должен переместиться вместе с пакетами. Ротация ключа AC–AAA не должна незаметно разрушить идентификацию WTP–AC или закрыть резервный путь.

Сохраняйте границы документа

RFC 5418 — анализ CAPWAP и IEEE 802.11 по состоянию на 2009 год. Его криптографические примеры и терминологию нельзя использовать как современные инструкции настройки. RFC 5415 описывает протокол CAPWAP, а RFC 5418 анализирует дополнительную уязвимую поверхность, возникающую при разделении функций точки доступа. Ни один документ не доказывает, что продают производители сегодня, как настроена конкретная сеть или что произошёл инцидент.

Сохраняется более узкий аналитический вывод: защищённый канал — лишь одно ребро графа доверия. Важно не количество значков замка, а то, соответствует ли каждая принятая идентичность правильной сети, роли и полномочиям и идёт ли клиентский трафик по тому пути, который организация считает управляемым. Владеть учётными данными — не то же самое, что контролировать систему, которую они открывают.

Источники