antiCisco blogs


блоги по технологиям и оборудованию cisco от инструкторов

Опубликовано 27 Июль , 2012

Структура безопасности Cisco TrustSec (далее CTS) позволяет строить защищенные сети с помощью установки домена из доверенных сетевых устройств. Связь между устройствами в домене защищена с помощью шифрования, проверки целостности и механизмов защиты от повторных пакетов данных. CTS использует данные устройства и пользователей в процессе аутентификации для классификации пакетов группами безопасности (Security Groups, SG) когда они попадают в защищенный домен. Классификация пакетов осуществляется с помощью тегирования на входе в CTS-сеть. Этот тэг, называемый тэгом группы безопасности (Security Group Tag, SGT), позволяет сети применять политики контроля доступа для конечных устройств.

Архитектура CTS базируется на трех ключевых компонентах:

— Проверенная сетевая инфраструктура. После того как первое устройство (которое еще называют корневым) проходит аутентификацию на сервере аутентификации (Cisco ACS или Cisco ISE), создается CTS домен. Каждое следующее добавляемое сетевое устройство в домен проходит аутентификацию с пирами, уже находящимися в домене. Такое новое добавляемое устройство идентифицируется сервером аутентификации и ему назначается номер группы безопасности в соответствии с политиками, настроенным на сервере.

— Безопасный контроль доступа на основе групп (Security Group Access, SGA). Политики доступа внутри CTS домена не зависят от топологии сети, а базируются на так называемых ролях (о чем свидетельствует номер SG) устройства-источника и устройства-назначения. Все пакеты, проходящие между двумя устройствами в сети, тэгируются номером SG источника.

— Защищенные соединения. На устройствах с поддержкой аппаратного шифрования все пакеты на линках могут быть зашифрованы.

На рисунке ниже представлен пример CTS домена. В этом примере некоторые сетевые устройства и конечные компьютеры находятся внутри домена, а некоторые нет.

Каждый участник в процессе аутентификации CTS берет на себя одну из следующих ролей:

— Саппликант  (Supplicant, проситель). Это неаутентифицированное устройство, которое подсоединяется к легитимному устройству внутри безопасного домена, и пытается в стать членом этого домена.

— Сервер аутентификации. Это сервер, который проверяется валидность саппликанта и определяет те политики, которые будут применены к просителю.

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

Когда линк между саппликантом и аутентификатором переходит в состояние UP, обычно происходит следующий набор событий:

  1. Аутентификация. Саппликант проходит проверку подлинности на сервере аутентификации. Возможно установление взаимной аутентификации.
  2. Авторизация. Основываясь на информации от саппликанта, сервер аутентификации выдает политики авторизации – например, назначение группы безопасности или ACL.
  3. Установление ассоциаций безопасности протокола (Security Association Protocol, SAP). Если обе стороны линка поддерживают шифрование, то саппликант и аутентификатор договариваются о необходимых параметрах для установки ассоциаций безопасности (Security Associations, SA).

После того, как все три шага, описанных выше, выполнены, аутентификатор изменяет состояние своего линка с неавторизованного на авторизованное и саппликант становится частью домена CTS.

CTS использует входное тэгирование и фильтрацию пакетов на выходе из домена для соблюдения политик контроля доступа. Все пакеты, которые попадают в домен из вне маркируются с помощью SGT, который содержит в себе номер группы безопасности устройства-источника. Классификация такого пакета ведется на всем пути следования данных внутри CTS домена. Оконечное устройство защищенной сети на пути описанного пакета, применяет политику контроля доступа, основываясь на группе безопасности устройства-источника и группе безопасности конечного CST устройства. В противовес традиционным спискам доступа, которые работают для IP-адресов, политики контроля в CTS выполнены в стиле списков доступа по политикам и называются списками доступа для групп безопасности (Security Group ACL, SGACL).

Аутентификация

Аутентификация позволяет идентифицировать конечные устройства (или же пользователей) которые подключаются в сеть. В процессе аутентификации система проверяет некоторые атрибуты устройства (например логин и пароль или сертификат) и узнает к какой группе относится тот или иной девайс. CTS предоставляет три метода аутентификации:

  1. 802.1X
  2. Mac Authentication Bypass. Используется для устройств, которые не поддерживают 802.1x (например, принтеры).
  3. Web Authentication. Этот метод чаще всего используется для компьютеров тех пользователей, у которых нет поддержки 802.1Х.

Рассмотрим первый метод чуть более подробно. Устройство контроля доступа (Network Device Admission Control, NDAC) использует 802.1х-аутентификацию с протоколом EAP-FAST в качестве метода аутентификации. Т.е. администраторы могут использовать привычные методы аутентификации типа MSCHAPv2, но внутри защищенного TLS-туннеля. В процессе EAP-FAST обмена, сервер аутентификации создает и передает саппликанту уникальные параметры доступа (Protected Access Credentials, PAC), которые содержат ключ и токен для установления защищенного сеанса связи с сервером. На рисунке снизу представлен процесс обмена сообщений между аутентификатором и саппликантом

 

Контроль доступа в сеть на основе групп безопасности

Группа безопасности это группа пользователей, конечных сетевых устройств, которые разделяют одинаковые политики доступа в сетевую инфраструктуру. Группы определяются администратором на сервере аутентификации. CTS назначает каждой группе уникальный (в пределах домена) 16-ти битный номер.

После того, как устройство однажды было аутентифицировано, все пакеты от данного девайса помечаются с помощью SGT. Пакет переносит этот тэг через всю защищенную сеть внутри CTS заголовка. Формально, SGT – просто метка, которая определяет уровень доступа устройства-источника.

Поскольку SGT содержит в себе номер группы безопасности источника, то такой тэг часто называют SGT источника. Целевое устройство (устройство назначения пакета, destination device) также имеет свою метку, которую называют тэгом группы назначения (Destination Group Tag, DTG).

Прим. CTS пакет не содержит в себе метку DTG

SGACL политики

Используя SGACL можно контролировать сетевые права доступа пользователей, основываясь на том, какие метки назначены устройствам-источнику и целевому устройству. В домене CTS такие политики доступа реализуются с помощью матрицы разрешений. Пример такой матрицы представлен на рисунке ниже.

Каждая ячейка такой матрицы может содержать специфичный ACL, который определяет взаимодействие между устройством-источником и целевым устройством.

Как я уже замечал ранее, политики контроля в CTS осуществляются с помощью тэгирования пакета от пользователя на входе в домен и применения опр. политик к этому пакету на выходе из защищенного домена (Egress Enforcement). На входе в CTS домен, траффик от источника тэгируется SGT (который содержит в себе номер группы безопасности источника). SGT распространяется через весь домен и на точке выхода из домена, выходное устройство, используя полученный номер группы и DGT определяет, какую политику доступа из матрицы SGACL необходимо применить.

Рассмотрим по шагам весь процесс работы домена CTS при прохождении пакета между компьютером пользователя и веб-сервером.

  1. PC передает пакет к веб-серверу. И хотя указанные компьютеры не являются членами CTS домена, путь пакета пролегает через защищенную сеть.
  2. Коммутатор (или маршрутизатор, не важно) на входе в домен изменяет пришедший пакет, добавляя к нему метку SGT с номер группы безопасности (в данном примере – 3). Этот номер группы безопасности назначается сервером аутентификации для конечного компьютера.
  3. На выходе из домена, коммутатор применяет SGACL-политику для 3-ей группы источника и 4-ой целевой группы (4-ый номер группы для сервера также был назначен сервером аутентификации).
  4. Если SGACL разрешает прохождение пакета, то данные передаются, в противном случае пакет дропается.

Сетевое устройство может определить SGT для пакета одним из следующих четырех методов:

— Получение SGT в процессе получения политики. После завершения процесса CTS аутентификации, аутентификатор забирает с сервера аутентифкации политику доступа для саппликанта. Если этот саппликант является недоверенным устройством (например, конечный хост, а не коммутатор сети), то сервер аутентификации может также назначить предоставить SGT для маркировки всех пакетов от указанного устройства.

— Получение SGT из пакета. Если пакет приходит от доверенного устройства домена, то он несет в себе SGT. Этот метод определения SGT применяется всеми устройствами, которые стоят не первыми на пути следования пакета в домене.

— Просмотр SGT источника, основываясь на личности источника. При наличии Identity Port Mapping (IPM, я не знаю как это нормально перевести) Вы может вручную сконфигурировать связку линк-личность.

— Просмотр SGT источника, основываясь на IP-адреса источника. В некоторых ситуациях может потребоваться ручная настройка сопоставления SGT и IP-адреса. Также для передачи такой информации между сетевыми устройствами может использоваться протокол SXP (SGT Exchange Protocol).

Отмечу, что в процессе аутентификации сервер передает следующие аттрибуты аутентификатору:

— CTS trust. Аттрибут указывает на то, что пиру можно доверять и его пакеты необходимо помечать с помощью SGT

— Peer SGT. Если пир является недоверенным, то все пакеты от него необходимо помечать этим SGT

— Время окончания авторизации. Определяет число секунд перед окончанием политики доступа. CTS устройство обязано обновить свои политики до истечения указанного таймера.

Авторизация и назначение политик

После окончания процесса аутентификации, саппликант и аутентификатор получают политики доступа от сервера аутентификации, т.е. начинается процесс авторизации. При этом все политики относятся к ID устройства. Если аутентификация настроена через 802.1х, то каждый участник (пир) использует тот ID, который был получен от сервера аутентификации. Если же безопасность линков достигается ручной настройкой, то необходимо вручную каждому устройству присвоить его ID.

Еще одним важным компонентом в среде CTS являются данные об окружающей среде (Environment Data). Это некий набор информации (или политик), которые помогают устройству функционировать в качестве участника CTS домена. Устройство приобретает данные окружающей среды от сервера аутентификации во время первого подключения к домену, хотя что-то Вы можете настроить и руками. Например, Вы должны дать корневому (или зерновому) устройству CTS домена информацию о сервере аутентификации.

Устройство использует протокол RADIUS чтобы получить следующие данные об окружающей среде от сервера аутентификации:

— Server List. Это список серверов, которые клиент может использовать для следующих RADIUS-запросов (как для аутентификации, так и для авторизации).

— Device SG. Группа безопасности, к которой относится само сетевое устройство.

— Expiry Timeout. Интервал времени, отвечающий за частоту обновления данных окружающей среды.

Безопасность каналов передачи данных

Если стороны на двух концах линка поддерживают протокол 802.1АЕ (MacSec), то возможно установление SAP (смотри расшифровку в начале статьи). В этом случае происходит обмен EAPOL-Key сообщениями между саппликантом и аутентификатором для согласования алгоритма шифрования и обмена сессионными ключами.

Использование CTS-несовместимых устройств в CTS домене

Тэгирование пакетов с помощью SGT требует аппаратной поддержки этой функции. Вполне может случиться так, что в Вашей сети окажутся устройства, которые данную функцию не поддерживают, но при этом могут участвовать в CTS аутентификации (например, по протоколу 802.1х).

Используя протокол SXP данные устройства могут пропускать информацию о связке IP-SGT к пирам, которые являются аппаратно совместимыми с CTS (CTS-capable hardware devices).

Чаще всего, SXP работает между входным коммутатором уровня доступа и коммутатором уровня распределения. Устройство уровня доступа проводит CTS-аутентификацию внешнего устройства и определяет (во время связи с сервером аутентификации) SGT для входных пакетов. Далее устройство узнает IP-адрес клиента используя технологии IP Tracking и DHCP Snooping. После этого поднимается сеанс связи по протоколу SXP к аппаратно-совместимому CTS коммутатору. Во время этого сеанса связи передается информация IP-to-SGT.

Хочу обратить Ваше внимание на тот факт, что SXP соединения настраиваются вручную. Настройка происходит в несколько шагов:

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

— Необходимо настроить каждого пира в качестве спикера или же слушателя. Устройство-спикер распределяет информацию IP-to-SGT к слушателю.

— Опционально можно настроить IP-адреса, с которых будет устанавливаться SXP сессия.

Прим. Устройство с аппаратной поддержкой CTS не обязательно должно быть на расстоянии одного хопа от устройства, которое такую функцию не поддерживает. Однако, SXP сессия всегда настраивается только с ближайшим устройство. Если информацию SGTtoIP необходимо передать через несколько хопов, на каждом промежуточном коммутаторе необходимо настроить SXP сессии с ближайшими соседями.

 

Прим. CTS устройства для поддержания SXP сессий используют TCP keepalives

 

Метки:
Опубликовано: Безопасность cisco

 

3 комментария “Обзор архитектуры Cisco TrustSec”

comment rss - Trackback

  1. P@ve1:

    Весьма интересная и толковая систематизация данного топика. Спасибо.
    PS
    Интересно, есть где либо хотя бы нормальная полноценная лаба сабжа? В продакшене ведь это наверняка еще никто не делал даже…
    Вообще, на сколько я понимаю — пока это все еще оч сыро. Далеко не все коммутаторы умеют это. ASA вот только с 9 верси должна научится…

  2. fantas1st0:

    Лаба — для курсов по 802.1x/ISE.
    Единственное, там не рассматривается настройка самого CTS-домена, только настройка самого ISE и 3560. Ну и Nexus7k в топологии есть.
    Табличку о том, какие коммутаторы что умеют я приведу позже — когда допишу процесс настройки.
    С ASA основная проблема в том, что она не умеет Change of Authorization .. но и это решаемо, если ISE поставить в режим Inline (ака IPS :))
    В продакшене проекты есть … правда пока фирм, которые могут продавать ISE мало — 3 или 4. Знаю, что Газпром при проектировании сетки ISE уперся в ограничение кол-ва серверов, которые могут быть в деплойменте 🙂

  3. mishinevpa:

    Картинки не грузит (((

» Оставить комментарий

Вы должны войти чтобы прокомментировать.