Блог Cisco в России и СНГ
Share

Управление доступом в архитектуре Cisco TrustSec.


February 11, 2015


Вступление.

Доброго дня уважаемые друзья! В данной статье мы рассмотрим пример настройки архитектуры контроля сетевого доступа Cisco TrustSec, ее функциональные, технические особенности, построение и непосредственно разберем вариант реализации. Познакомимся с возможностью более глубокой реализации функций Identity Based Networking (IBNS) и Identity Based FireWall (IDFW). Пример реализации и настроек разберем на базе стенда по информационной безопасности, собранном мной для секции World Of Solutions на прошедшей в ноябре 2014 года выставке Cisco Connect 2014.

Архитектура Cisco TrustSec – это система управления безопасностью сети с помощью меток безопасности Secure Group Tag (SGT), которые по своему потенциалу несут если не революционный (хотя на мой взгляд именно такой), то уж точно намного более глубокий и продвинутый подход к формированию политик доступа в сеть с возможностью их детализации и применения прозрачно через всю сеть.

Ключевым элементом данной системы является сервер политик, а именно система контроля и учета доступа в сеть – Cisco Identity Services Engine (ISE), поэтому говорить об архитектуре TrustSec с отрывом от ISE, на мой взгляд, было бы не правильно.

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

Сложности классических моделей управления доступом в сеть.

В классических вариантах авторизации доступа в сеть традиционно доминировали два метода:

  • динамическое назначение VLAN на порту коммутатора и контроллере БЛВС;
  • загрузка динамического ACL на порт коммутатора/контроллер беспроводной сети.

При авторизации пользователя на устройстве доступа коммутаторе/контроллере БЛВС/VPN шлюзе отсутствовала возможность привязки текущей сессии пользователя (как сущности, обладающей множеством параметров, а не только IP) к правилам ACL в межсетевом экране (МСЭ), контентных шлюзах внутри сети, ЦОД, периметральных устройствах ИБ. Таким образом, конфигурация МСЭ была крайне статична и фактически авторизация групп пользователей сводилась к статичной привязке IP подсетей к логическим группам пользователей и дальнейшей фильтрации в правилах ACL на МСЭ.

В более продвинутых вариантах разных вендоров, представленных на рынке решений ИБ, рассматривались возможности интеграции их МСЭ и шлюзов контентной фильтрации с AD посредством установки различного рода агентов на оконечные хосты и/или подстройку доменных контроллеров MS AD на возможность экспорта информации об активных пользователях. При таких подходах возникали следующие проблемы:

  • Зачастую для мониторинга активности логинов использовался Security Log доменного контроллера, что не давало разницы в том залогинен пользователь посредством терминальной сессии RDP или локально. Не отмечались события типа Logout, что приводило к возникновению реального риска при подмене адреса рабочей станции в случае такой “висячей сессии”;
  • Требовалось вносить изменения в реестр и настройки доменных контроллеров, получение для агента учетной записи администратора домена, либо расширенных прав доступа;
  • Гостевые пользователи никоим образом такой системой учета пользователей отслеживаться не могли;
  • Установка агентов на оконечные компьютеры влечет за собой дополнительную административную нагрузку на развертывание таких инсталляций и их поддержку;

Коробочные решения такого рода не имели интеграции с NAD (оконечными сетевыми устройствами доступа), что приводило к отсутствию архитектурного подхода как такового и гибкости в интеграции таких решений.

Пользователь зачастую был жестко привязан к своему рабочему месту, блоку IP адресов, активным сессиям аутентификации в приложениях и на МСЭ, которые приходилось многократно проходить для получения доступа в тот или иной сегмент сети. Помимо всего прочего на МСЭ ЦОД (к примеру) было невозможно  узнать каков был результат прохождения процедуры оценки состояния пользовательским устройством, тип устройства пользователя и так далее. Передача знаний о пользователе в систему WEB контентной фильтрации (корпоративного прокси) также была связана с трудностями интеграции своих собственных агентов, либо с необходимостью в организации активной аутентификации через портал.

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

При работе через терминальные сервера ориентироваться просто на IP адрес для авторизации не информативно. Даже если можно выдать уникальный адрес для терминальной сессии пользователя, МСЭ ничего не знает о конкретном пользователе и его дополнительных атрибутах (вроде тех, что назначаются в AD, возможно о членстве в группе и тд).

Описание архитектуры Cisco TrustSec.

Архитектура Cisco TrustSec совместно с системой контроля и учета доступа в сеть Cisco ISE призваны реализовать гибкие централизованные сервисы управления пользовательским и не пользовательским доступом в сеть и обеспечить:

  • Аутентификацию пользовательских и не пользовательских устройств в сети по различным методам и протоколам аутентификации с использованием широкого набора интегрируемых внешних сервисов и баз аутентификации.
  • Авторизацию доступа в сеть в зависимости от:
    • Различного набора критериев, которым удовлетворяет сессия. Гибкость формирования критериев авторизации обеспечивается булевой логикой при написании правил. Некоторые из критериев:
      • Членство пользователя в группе AD/LDAP;
      • Параметры аутентификации – атрибуты как пользователя в сторонней базе аутентификации, поля сертификата, тип аутентификации dot1x/mab и тд.
      • Местоположение подключаемого пользователя;
      • Тип подключения пользователя Wired/Wireless/VPN;
      • Тип подключаемого устройства;
      • Время подключения;
      • Оценка состояния устройства – NAC Posture;
    • Профилирование типов подключающихся устройств с целью более гибкого формирования правил авторизации доступа с учетом типа подключаемого устройства, в том числе этот функционал помогает защититься от подмены устройства.
    • Оценка состояния подключающихся устройств на предмет соответствия политике безопасности, проведение таких оценок как:
      • Windows Update: Версии ОС, наличие Service Pack, Hotfix, версия браузера;
      • Антивирус установлен/ свежие ли базы
      • Антишпионское ПО установлено/ свежие ли базы;
      • Файловые параметры;
      • Сервисы
      • Приложения;
    • И многие-многие другие параметры сессии, доступные во встроенной библиотеке параметров Cisco ISE;
  • Полный цикл управления гостевым доступом с разделением на роли, как гостей, так и тех кто этих гостей может создавать.
  • Интеграцию со сторонними системами: MDM, СКУД, SourceFire FirePower, Cisco Threat Defense, SIEM системами и другими партнерскими решениями, поддерживающими взаимодействие с ISE через API, либо pxGrid (Cisco Platform Exchange Grid).
  • Применение методов авторизация сессии по результату проверки совпадения выполняемых условий:
    • URL перенаправление;
    • VLAN динамическое назначение
    • DACL загрузка динамического ACL;
    • SGACL динамическая загрузка Secure Group ACL(SGACL) на коммутаторы, входящие в доверенную сеть TrustSec;
    • Авторизация VPN доступа;
    • SGT – назначение метки Secure Group Tag;
    • Назначение произвольных Radius-атрибутов для авторизации сессии;
    • Change of Authorization – изменение авторизации уже установленной сессии, например при выключении политики NAC на оконечном устройстве (Пример: выключили антивирус..)

Важно понимать, что все вышеперечисленные методы авторизации могут применяться как раздельно, так и совместно. Метод Radius CoA применяется в автоматическом режиме:

  • при изменении профиля устройства;
  • по результату очередной проверки соответствия оконечного устройств;
  • по сигналу от AnyСonnect/NAC агента;

Архитектура TrustSec – это прежде всего возможность управления доступом в сети посредством групп безопасности Secure Group Tag (SGT). Метка SGT несет в себе контекст информации о конкретной сессии доступа в сеть, ее параметрах, таких как перечисленные ниже:

  • время доступа;
  • тип доступа в сеть;
  • метод аутентификации;
  • тип устройства;
  • параметры аутентификации;
  • пользователь и его параметры;
  • оценка состояния устройства и тд..

Данная метка назначается на устройство оконечного доступа сервером контроля и учета доступа Cisco ISE, который выполняет роль RADIUS сервера с сильно расширенными возможностями. Метка назначается как результат авторизации сессии оконечного подключившегося устройства, уникально его идентифицирует и переносится через всю сеть вместе с трафиком оконечного устройства. Происходит так называемое тегирование трафика оконечного устройства. Тегирование дает возможность каждому устройству МСЭ/Маршрутизатору/Коммутатору на пути следования пакета видеть, принимать решение по фильтрации и логировать транзакции, опираясь не на абсолютно не информативный IP адрес (который можно подменить), а на богатый набор информации об источнике трафика.

Что же из себя представляет метка безопасности SGT и как она передается по сети? Метка безопасности это число от 1 до 65535, соответственно занимающая при тегировании поле размером 16 бит в заголовке пакета данных. Метка включается в поле Cisco Meta Data, которое вместе с меткой добавляет в L2 фрейм дополнительно 20 байт (см Рис. 1).

PIC0001Рис. 1

Метки по сети могут передаваться двумя путями:

  • Прямым тегированием пакетов;
  • Через служебный протокол обмена метками – SGT Exchange Protocol over TCP (SXP);

Рассмотрим оба метода в отдельности.

Методы передачи меток SGT по сети.

Для того чтобы обеспечить тегирование и фактически изменение фрейма на лету без ущерба производительности и обеспечения линейной скорости передачи данных, устройство доступа, к примеру коммутатор, должно иметь реализацию тегирования на аппаратном уровне, то есть в ASIC(аппаратный чипсет). Следует отметить, что ASIC , который будет производить модификацию фреймов, стоит определенных денег и стал внедряться в устройства Cisco относительно недавно. Таким образом, тегирование пакетов поддерживает относительно небольшое количество устройств, хотя их список постоянно пополняется.

С актуальным списком моделей устройств, поддерживаемых архитектурой Cisco TrustSec можно ознакомиться по ссылке.

На момент написания статьи можно говорить о том, что аппаратное тегирование поддерживают все современные коммутаторы начиная с 3560x/3750x, 3650/3850 и далее Cat4k, Cat6k, Nexus5k, Nexus7k, ISRG2, ASR, WLC 5760 и другие, детали по ссылке выше.

В аппаратном тегировании есть как плюсы, так и определенные минусы. Что касается плюсов – экономия ресурсов сетевого оборудования, поскольку не надо использовать Control-Plane протоколы для хранения привязок IP<->SGT в оперативной памяти TCAM, большая масштабируемость. Также из плюсов – широкие возможности по защите от подмены меток, об этом отдельно ниже. Касательно минусов:

  • Далеко не всем так повезло иметь коммутатор Catalyst 3k-X на уровне доступа;
  • В случае, если тегированный трафик попадает на устройство не Cisco (не понимающее теги), фрейм просто отбрасывается, как не удовлетворяющий IEEE стандарту. Мало того, что не многие располагают кампусом полностью построенном на Cisco, так еще и передача тегов через WAN сети для многих вопрос весьма актуальный ввиду наличие филиалов и удаленных площадок;

Во избежание перечисленных неудобств и необходимости сделать внедрение архитектуры TrustSec гибко и на большем количестве платформ, был разработан протокол обмена метками SGT между сетевыми устройствами.

Протокол SXP работает поверх транспортного протокола TCP на порту 64999. В деталях о протоколе SXP можно почитать по ссылке.

Сессии SXP устанавливаются в топологии точка-точка между устройствами обменивающимися знаниями о метках. Клиентская сессия в процессе авторизации получает метку безопасности от Radius сервера (Cisco ISE), данная метка сохраняется в базе оконечного устройства доступа (NAD) вместе с привязкой текущего IP адреса клиента, как показано на рисунках 2 и 3 ниже. Данной таблицей соответствия IP<->SGT и обмениваются устройства по протоколу SXP. SXP сессия может строиться между разными L3 сегментами и хоть через WAN канал до ближайшего устройства, которое либо может отфильтровать трафик, основываясь на метках, либо сможет аппаратно затегировать и отправить дальше уже тегированный трафик.

PIC0002

Рис. 2

PIC0003

Рис. 3

Касательно ресурсов ЦОД и в частности серверов, которые аутентифицировать в сети по 802.1x никто не будет (это и не требуется), есть несколько гибких решений для присвоения им меток как статически, так и динамически. Статически можно задавать привязку метки на IP/Интерфейс коммутатора/VLAN. В зависимости от конкретной используемой модели коммутатора ЦОД могут быть доступны разные модели статического присвоения метки. Статическое присвоение метки может быть полезно в случае невозможности реализации динамического метода присвоения меток, например, отдельно стоящие сервера без виртуализации, Z-системы, P-системы и другие специфические архитектуры, на которых нельзя запустить гипервизор VMWare ESX.

Динамический метод – это использование распределенного виртуального коммутатора гипервизора VMWare ESX от компании Cisco – Nexus 1000v, который начиная с версии ПО 5.2(1)SV3(1.1) поддерживает протокол SXP. Если кратко, то этот виртуальный коммутатор (имеет бесплатную версию) ставится вместо Distributed коммутатора (VDS) в ESX ферму. Работает Nexus 1000v как полноценный модульный коммутатор с консолью и богатым функционалом. Сервера ESX являются его линейными картами, а супервизоры резервируемо запускаются на отдельных виртуальных машинах (см. Рис 4).

PIC0004

Рис. 4

На коммутаторе Nexus 1000v создаются портовые профили, которые в дальнейшем будут присвоены виртуальным машинам. В портовом профиле отражаются сетевые настройки, которые должны быть унаследованы виртуальной машиной. Среди этих настроек может быть настроен и тег SGT (пример профиля см. Таблица 1).

Все создаваемые виртуальные машины с присвоенным портовым профилем будут автоматически иметь указанную метку. Знание об этой метке IP<->SGT по протоколу SXP от гипервизора N1kv будет автоматически распространено по сети. В Таблице 1 метка SGT указана в HEX формате, в этом есть отличие формата записи меток в конфигурации коммутаторов Catalyst от коммутаторов серии Nexus. Приведенная метка 0x104 в десятичном виде будет выглядеть как 260.

port-profile type vethernet BYOD-DMZ
switchport mode access
switchport access vlan 260
org root/LAB-Home
cts manual
policy static sgt 0x104
no shutdown
state enabled
vmware port-group

Таблица 1

Изначально метка 260 с ее описанием задается на ISE, откуда уже метка вместе с описанием распространяется на доверенные сетевые устройства (см Рис 4-1).

PIC0004-1

Рис. 4-1

В таблице 1 мы видим пример настроенного портового профиля Nexus 1000v – BYOD-DMZ. Портовый профиль с привязанной к нему конфигурацией появляется в интерфейсе настройки сети виртуальной машины в консоли администратора ESX (см. Рис 4-2). Независимо от миграции виртуальной машины, вся конфигурация привязанного к ней интерфейса Nexus 1000V мигрирует вместе с виртуальной машиной.

PIC0004-2

Рис. 4-2

Из дополнительного мощного и очень расширяемого метода передачи меток хочется отметить ESP инкапсуляцию. Благодаря ей VPN шлюзы вроде ASR, ISRG2 могут тегировать трафик непосредственно передаваемый через IPSEC туннели, поддерживаются DMVPN, FLEXVPN, GETVPN (см Рис. 5), информацию обо всех поддерживаемых VPN конфигурациях и версиях ПО можно получить в актуальной версии документации.

PIC0005

Рис. 5

Далее несколько слов о защите меток от подмены. В случае аппаратного тегирования фрейма метка передается на транковых каналах. Устройство, терминирующее транк, для принятия меток от соседнего устройства должно соседу доверять.

Создается так называемая сеть доверия, где каждый коммутатор заводится в базе устройств NDG (Network Device Group) на Cisco ISE, аутентифицируется по паролю и получает автоматически PAC. Далее коммутатор по протоколу 802.1x аутентифицирует соседа посредством EAP-FAST, в результате успешной аутентификации строится сеть доверия (подробнее по ссылке). Для сохранения конфиденциальности, целостности и неподменности (CIA Triad) передаваемых тегов и данных, опционально на транке между двумя коммутаторами может быть активирована криптозащита MACSEC 802.1AE (Если оба коммутатора поддерживают 802.1AE).

В случае использования протокола SXP для передачи базы меток между сетевыми устройствами оба участника сессии SXP опционально аутентифицируются по Pre-Shared-Key.

Подменить метку безопасности, даже если не использовать перечисленные выше средства защиты значительно тяжелее, чем IP адрес по нескольким причинам:

  • Понять на какой IP адрес нужно произвести подмену довольно просто, отслеживая проходящие активности;
  • Понять какую метку безопасности из 65535 возможных вариантов нужно проставить в пакете довольно сложно, поскольку сама метка, увиденная в сниффере – просто число;
  • Для того чтобы анализировать тегированный трафик нужен соответствующий сниффер, который понимает обновленный формат заголовка пакета;
  • Тем более для изменения тега в пакете требуется иметь соответствующие утилиты, которых на широком рынке пока нет;
  • Напомню, что теги передаются в кампусе только в транке между доверенными устройствами, что уже усложняет возможный путь внедрения и подмены;

Говоря о сетевых устройствах, которые поддерживаются архитектурой TrustSec стоит отдельно отметить, что в отличие от аппаратного тегирования, которое поддерживает ограниченное количество устройств, протокол SXP поддерживается на куда более широком списке оборудования. На стенде Cisco Connect 2014 для реализации и демонстрации архитектуры Cisco TrustSec для передачи меток между устройствами использовался только протокол SXP. На рисунке 6 я приведу краткую таблицу с сериями оборудования и технологиями в рамках архитектуры TrustSec ими поддерживаемыми. Детальную и обновленную информацию можно посмотреть по ссылке. На рисунке 6 в графе “Распространение“ пометка Inline означает возможность тегирования трафика.

PIC0006

Рис. 6

Методы контроля доступа по меткам безопасности.

Далее предлагаю перейти к рассмотрению методов фильтрации, сегментации трафика на основании меток. Методов применения политики безопасности по меткам два SGACL и SGFW:

  1. SGACL – централизованно настраиваемые ACL списки доступа, настройка происходит на ISE, применение на коммутаторах доступа или оконечных коммутаторах домена доверия TrustSec. От классических ACL они отличаются тем, что оперируют в полях источник и назначение пакета исключительно метками. При составлении политики безопасности метки дают возможность полностью отвязаться от физической IP адресации. Метка намного более уникально описывает состояние и идентификацию объекта, нежели IP адрес и дает огромную гибкость ввиду своего динамического характера назначения на основании политики безопасности.

    SGACL настраивается в виде матрицы, где на пересечении метки источника и метки назначения указывается необходимый ACL (см Рис. 7).

    PIC0007Рис. 7

    Первая часть волшебства этих SGACL кроется в их полностью автоматическом назначении коммутаторам, на которых существуют метки оконечного следования трафика (destination) в вышестоящей матрице из рисунка 7.

    Вторая часть волшебства кроется в возможности фильтрации и сегментации трафика между устройствами с одной и той же меткой безопасности, даже если они находятся в одном VLAN на одном и том же коммутаторе доступа. На практике это позволяет, имея один VLAN доступа на коммутаторе одним только функционалом SGT/SGACL безопасно (подтверждено VeriSign для PCI DSS) разделять совершенно разные по классу доступа и доверия группы пользователей и устройств.

    Этот подход существенно снижает операционные расходы (OPEX). В виде наглядного примера приведу фильтрацию активности на часто используемые червями сервисы между хостами одного VLAN с одной и той же меткой (см. Рис. 8).

    PIC0008
    Рис. 8

    Не стоит забывать и о том, что при классическом разделении зон безопасности или ролей пользователей на VLAN мы сильно увеличиваем наши операционные расходы и нагрузку на оборудование. При добавлении новой роли пользователя нам надо (см. Рис 8-1):

    • Выделить новый VLAN;
    • Выделить подсеть;
    • Настроить DHCP pool;
    • Если есть настройки HA, адаптировать и их;
    • Настроить статический ACL на SVI или шлюзе;
    • Настроить маршрутизацию в новый сегмент;

    А ведь эту конфигурацию еще требуется поддерживать и добавление одного доп. сегмента на 1000 филиалов может превратиться в непростую задачу с соответствующими трудозатратами и риском ошибки. В случае проблем с адресным пространством, выльется в двукратное (как минимум!) увеличение таблиц маршрутизации. Помочь перейти к более эффективной системе контроля доступа может внедрение архитектуры TrustSec.

    PIC0008-1

    Рис. 8-1

  2. SGFW – Если метод SGACL являет собой возможность динамического внедрения функций сегментации и базового пакетного фильтра на коммутаторах:
    • уровня доступа,
    • границ сегментов доверия TrustSec,
    • ЦОД и серверной фермы виртуализации (Nexus1kv),

    то SGFW (Secure Group Firewall) – это функционал полноценного межсетевого экрана и применяется он на МСЭ серии ASA и маршрутизаторах Cisco, начиная с ISR G2 в рамках функционала ZBFW (Zone-Based FireWall). Метки и их описание централизованно настраиваются в Cisco ISE. Из Cisco ISE описание и номера меток распространяются по всей сети доверия Cisco TrustSec на коммутаторы, маршрутизаторы, МСЭ, контроллеры БЛВС.

    На рисунке 9 приведен пример, где сначала настраиваются метки безопасности и их описания на ISE, далее эти метки динамически распространяются на МСЭ ASA, где мы можем их использовать для написания политики доступа. На ASA можно использовать в одной и той же записи ACE (Access-Control Entry – строчка в ACL), как привычные IP объекты, так и Source/Destination метки безопасности SGT. Можно использовать в ACE даже одни только метки для указания источника и назначения трафика, поскольку, метки несут намного больше информационной составляющей для принятия решения о фильтрации, нежели просто IP адрес.

    PIC0009

    Рис. 9

Стенд Cisco Connect 2014.

Рассмотрение настроек Cisco TrustSec и Identity Firewall.

После обзорного рассмотрения основ архитектуры TrustSec я бы хотел перейти к части настроек, а именно рассмотрению стенда Cisco Connect 2014 в разрезе TrustSec конфигурации и реализованного функционала.

Для начала рассмотрим топологию и сценарии демонстрации. Общая топология стенда представлена на рисунке 10.

PIC00010

Рис. 10

Многие компоненты стенда виртуализованы, что позволяют сделать последние релизы многих продуктов от компании Cisco. В частности стенд развернут на двух серверах под управлением гипервизора VMWARE ESX 5.5.

Виртуальные машины стенда в рамках архитектуры TrustSec и Identity FW:

  • Cisco ISE v1.3;
  • Nexus 1000v v5.2(1)SV3(1.1);
  • Context Directory Agent patch 3 (обновленодо patch4);
  • MS AD – Windows Server 2008 R2 Enterprise SP;
  • Web Security Appliance v8.5;
  • SourceFire FireSight Manager v5.3.1.1;
  • Remediation Server – Windows Server 2008 R2 Enterprise SP1;
  • vASA v9.3.1;

Компоненты аппаратные:

  • WLC 2504 v7.6;
  • WAP Cisco 2602i;
  • Catalyst WS-C3750X-24P-S v15.0(2)SE2;
  • ASA5515-X with FirePower Services;

В лабораторной схеме работает Active Directory на базе MS 2008 R2 SP1 и для демонстрации существует несколько групп пользователей:

  • Employee – Сотрудники компании;
  • Contractor – Контрактные рабочие;

На стенде поддерживается (протестирована) работа клиентов со следующими типами операционных систем:

  • Apple IOS v5+;
  • MacOSX10.8 + (ниже не тестировалось);
  • Windows 7 Enterprise;
  • Android 4.4.2+;

Рассматриваются cледующие сценарии работы:

  1. Сотрудник из группы Employee аутентифицируется по проводной/беспроводной сети при помощи сертификата (посредством 802.1Х с использованием EAP-TLS), выданного CA сервером, встроенным в Cisco ISE 1.3. Для сотрудников, еще не получивших сертификат, происходит процесс WEB аутентификации с регистрацией устройства и выдачей сертификата – так называемый процесс Native Supplicant Provisioning (NSP). На момент проведения процесса заведения устройства в системе и выписки ему сертификата, сессия авторизуется в системе с присвоением соответствующего загружаемого DACL (на коммутатор/БЛВС контроллер/МСЭ) и назначением метки безопасности SGT – SGT_Provisioning (8).На стенде в качестве 802.1х супликанта используются встроенные возможности операционных систем клиентов. После аутентификации и авторизации клиентское устройство проходит процедуру оценки состояния (Posture Assessment) при помощи устанавливаемого на клиентский компьютер агента Anyconnect v4.0 с модулем Posture (если подключаемое устройство имеет операционные системы типа MAC OSX или Windows 7).
    • В случае удачного прохождения оценки состояния (получение статуса Compliant), пользователь допускается в сеть и ему назначается загружаемый ACL (на коммутатор/БЛВС контроллер/МСЭ) и метка SGT – SGT_Employee_Compliant (3).
    • В случае не соответствия политике безопасности (получения соответствующего статуса NON-Compliant) пользователю назначается другой загружаемый ACL (на коммутатор/БЛВС контроллер/МСЭ) и метка безопасности SGT_Remediation (6).
  2. В случае, если пользователь из группы Employee заходит в систему с использованием устройства с операционной системой и типом устройства, относящимся к мобильным, процесс, указанный в пункте 1 повторяется за следующими исключениями:
    • Оценка состояния не проводится;
    • По результату успешной аутентификации и авторизации сессии назначается соответствующий загружаемый DACL (на коммутатор/БЛВС контроллер/МСЭ) и метка безопасности SGT_Employee_BYOD (2);
    • Пользователь, аутентифицирующийся в сети как член группы Contractor, получает в процессе Native Supplicant Provisioning настройки сети и в дальнейшем аутентифицируется автоматически по протоколу 802.1Х с использованием EAP-PEAP (по логину/паролю). Далее клиент проходит оценку состояния посредством WEB NAC Agent. Как результат успешной авторизации и проверки состояния сессии присваивается загружаемый DACL (на коммутатор/БЛВС контроллер/МСЭ) и метка безопасности SGT_Contractor_Compliant (4);
  3. Гостевые пользователи, подключаясь к сети, как по проводной, так и по беспроводной сети автоматически перенаправляются на портал WEB аутентификации, где аутентифицируются под своей учетной записью, а в виде результата авторизации получают динамически назначаемый гостевой VLAN (отмечен на схеме), загружаемый ACL и метку безопасности SGT – SGT_Guest (5).
  4. Аутентифицированные пользователи члены AD через связку ISE -> CDA -> WSA имеют прозрачный доступ в Интернет в соответствии с их членством в AD без необходимости дополнительной активной аутентификации и установки каких-либо агентов на клиентские устройства. WSA (Cisco WEB Security Appliance) в отчетах пользовательской активности видит четкую привязку сессий и запросов к конкретным пользователям базы каталогов AD.
  5. В случае, когда пользователи члены группы Employee работают удаленно и пытаются получить доступ к ресурсам сети через удаленное подключение VPN при помощи Cisco Anyconnect VPN Client v4.0 на корпоративный VPN Gateway на базе vASA v9.3.1, происходит следующий процесс:
    • Если пользователь никогда ранее не подключался к шлюзу компании, его запрашивают логин/пароль и автоматически происходит выписка сертификата для дальнейших сессий аутентификации. Сертификат выписывается сервисом CA, развернутым на PDC (Primary Domain Controller);
    • После выписки сертификата, Anyconnect клиент автоматически переподключается и аутентифицируется по сертификату, попадая в совершенно другую туннельную группу с индивидуальными правами доступа, динамически загружаемыми с ISE;

Адресация основных ресурсов стенда, относящиеся к теме TrustSec:

Имя ресурса FQDN IP
Active Directory PDC ad.example.ru 192.168.99.132
WLC wlc.example.ru 192.168.99.135
ISE ise.example.ru 192.168.99.134
WSA wsa.example.ru 192.168.99.143
CDA cda.example.ru 192.168.99.133
Remediation Server remediation.example.ru 192.168.99.136
ISE SPONSOR Portal sponsor.example.ru (CNAME) 192.168.99.134
ISE DEVICES Portal devices.example.ru (CNAME) 192.168.99.134
VMWARE VCenter vcenter.example.ru 192.168.99.124
ESXi Host esxi.example.ru 192.168.99.122
Nexus 1kv VSM n1kvsm.example.ru 192.168.99.115

 Таблица 2

Настройка оконечных устройств доступа (NAD) для работы с ISE.

Устройства доступа (NAD) Вашей сети могут быть различными – WLC контроллеры БЛВС, коммутаторы доступа, МСЭ ASA. Для работы в единой архитектуре TrustSec устройства NAD должны быть прописаны на ISE и получить PAC для взаимной аутентификации. С целью создания большей гибкости в написании правил доступа и управления устройствами NAD, устройства можно разбить на группы по типу, географическому расположению и по иным критериям в интерфейсе ISE.

Начнем с того, что заведем все устройства в ISE. Для этого мы переходим в меню Administration > Network Devices (см Рис 11). Далее выбираем +ADD (См Рис. 11-1) и следуем примеру конфигурации на рисунке 11-2. Аналогично настраиваем WLC и ASA.

PIC00011-1

Рис. 11-1

PIC00011-2PIC00011-2 PIC00011-3 PIC00011-4 PIC00011-5

Рис. 11-2

Единственное отличие в добавлении ASA будет то, что PAC на ASA не распространяется автоматически и его надо скачать из ISE и вручную установить на ASA, однако импорт PAC мы будем проводить после первоначальной настройки на работу с ISE самой ASA.

Для понимания организации передачи меток на стенде, я приведу схематический пример организации SXP сессий в рамках лабораторного стенда и по шагам опишу пример сессии подключения сотрудника из группы Employee с уже выданным сертификатом и настроенным супликантом 802.1х (см Рис.12). Для беспроводного доступа алгоритм будет аналогичен проводному.

PIC00011-6

Рис. 12

Для более детального понимания процесса аутентификации и авторизации приведу слайды на рисунках 13 и 14:

PIC00011-7

Рис. 13PIC00011-8

Рис. 14

Настройки на коммутаторе доступа:

version 15.0
service timestamps debug datetime msec
service timestamps log datetime msec!
hostname Switch-Lab
!
logging buffered informational
logging monitor informational
!
aaa new-model
!
aaa authentication dot1x default group radius
aaa authorization exec default local
aaa authorization network default group radius
aaa authorization network ise group radius
aaa accounting dot1x default start-stop group radius
!
aaa server radius dynamic-author
client 192.168.99.134 server-key XXXXXXX
server-key XXXXXXX
!
ip dhcp snooping vlan 1-300
no ip dhcp snooping information option
ip dhcp snooping
ip domain-name example.ru
ip device tracking
vtp mode transparent
!
device-sensor filter-list dhcp list DHCP_LST
option name host-name
option name class-identifier
option name client-identifier
!
device-sensor filter-list cdp list CDP_LST
tlv name device-name
tlv name platform-type
!
device-sensor filter-list lldp list LLDP_LST
tlv name port-id
tlv name system-name
tlv name system-description
device-sensor filter-spec dhcp include list DHCP_LST
device-sensor filter-spec lldp include list LLDP_LST
device-sensor filter-spec cdp include list CDP_LST
device-sensor accounting
device-sensor notify all-changes
epm logging
!
cts authorization list ise
cts sxp enable
cts sxp default source-ip 192.168.99.150
cts sxp default password XXXXXXX
cts sxp connection peer 192.168.99.129 password default mode peer listener
!
dot1x system-auth-control
! ## VLAN, использованные в рамках стенда (Урезано для функционала TrustSec)##
vlan 200
name BYOD-Employee
vlan 207
name MGMT
vlan 208
name ATTACKER
vlan 210
name BYOD-WiFi
vlan 230
name BYOD-Guest
vlan 260
name BYOD-DMZ
!
! ## Типичная настройка порта доступа для коммутатора стенда ##
interface GigabitEthernetХ/Х/Х
description Access ports DOT1X
switchport access vlan 200
switchport mode access
switchport voice vlan 210
ip access-group ACL-DEFAULT in
authentication event fail action next-method
authentication event server dead action reinitialize vlan 230
authentication event server dead action authorize voice
authentication event server alive action reinitialize
authentication host-mode multi-auth
authentication open
authentication order dot1x mab webauth
authentication priority dot1x mab webauth
authentication port-control auto
authentication periodic
authentication timer reauthenticate server
authentication violation restrict
mab
dot1x pae authenticator
dot1x timeout tx-period 3
spanning-tree portfast
!
interface Vlan10
ip helper-address 192.168.99.132
!
interface Vlan200
ip address 192.168.200.200 255.255.255.0
!
interface Vlan230
ip address 192.168.230.200 255.255.255.0
!
interface Vlan260
ip address 192.168.99.150 255.255.255.224
!
default-gateway 192.168.99.129
ip http server
ip http secure-server
ip http secure-active-session-modules none
ip http active-session-modules none
!
ip access-list extended ACL-DEFAULT
permit udp any eq bootpc any eq bootps
permit udp any any eq domain
permit icmp any any
permit ip any host 192.168.99.132
permit udp any any eq tftp
deny   ip any any log-input
ip access-list extended ACL-WEBAUTH-REDIRECT
deny   udp any any eq domain
deny   udp any host 192.168.99.134 eq 8905
deny   udp any host 192.168.99.134 eq 8906
deny   tcp any host 192.168.99.134 eq 8443
deny   tcp any host 192.168.99.134 eq 8905
deny   tcp any host 192.168.99.136 eq www
deny   tcp any host 192.168.99.136
deny   ip any host 192.168.99.132
permit ip any any
ip access-list extended ACL_BLACKHOLE_Redirect
deny   udp any eq bootpc any eq bootps
deny   udp any host 192.168.99.132 eq domain
deny   ip any host 192.168.99.134
permit ip any any
ip access-list extended ACL_Provisioning_Redirect
deny   udp any eq bootpc any eq bootps log
deny   udp any host 192.168.99.132 eq domain
deny   ip any host 192.168.99.134
permit tcp any any eq www
permit tcp any any eq 443
!
ip radius source-interface Vlan260
logging origin-id ip
logging source-interface Vlan260
logging host 192.168.99.134 transport udp port 20514
!
snmp-server community XXXXXXX RW
snmp-server trap-source Vlan260
snmp-server source-interface informs Vlan1
snmp-server enable traps snmp authentication linkdown linkup coldstart warmstart
snmp-server host 192.168.99.134 XXXXXXX mac-notification snmp
!
radius-server attribute 6 on-for-login-auth
radius-server attribute 6 support-multiple
radius-server attribute 8 include-in-access-req
radius-server attribute 25 access-request include
radius-server dead-criteria time 5 tries 3
radius-server host 192.168.99.134 auth-port 1812 acct-port 1813 key XXXXXXX
radius-server host 192.168.99.134 pac key XXXXXXX
radius-server key XXXXXXX
radius-server vsa send accounting
radius-server vsa send authentication
!
!
!
line con 0
exec-timeout 0 0
logging synchronous
line vty 0 4
exec-timeout 0 0
line vty 5 15
exec-timeout 0 0
!
ntp server 192.168.99.132
mac address-table notification change interval 0
mac address-table notification change
end

 

В указанной выше конфигурации мы видим список различных ACL, опишем их функциональность:

Имя списка доступа (ACL) Функциональное назначение
ACL-DEFAULT Список доступа по-умолчанию на портах доступа, данный ACL фильтрует трафик еще не получивших должную авторизацию пользователей и устройств в сети и дает возможности базово получить IP, видеть DNS и доменный контроллер.
ACL-WEBAUTH-REDIRECT Используется для функции URL-Redirect в политике, отвечающей за оценку состояния и помогает агенту NAC / Anyconnect клиенту обнаружить сервер политик для оценки состояния.
ACL_BLACKHOLE_Redirect Используется для функции URL-Redirect в политике потерянных устройств на ISE.
ACL_Provisioning_Redirect Используется для функции URL-Redirect в политике ISE, отвечающей за централизованную WEB аутентификацию CWA.

 Таблица 3

Отдельно необходимо ввести Ваш Device-ID и пароль, указанные в интерфейсе ISE при регистрации устройства на рисунке 11-2 это соответственно поля Name и Shared Secret.

Switch-Lab#cts credentials id C3750-X-Access password XXXXX

Подробности по настройке коммутатора для работы с ISE можно посмотреть в соответствующем разделе документации, к примеру по ссылке.

Для того чтобы убедиться в успешном получении PAC и получении информации из ISE по группам и политикам SGT можно выполнить следующие команды:

Switch-Lab# show cts pacs
AID: 3ABDD52E1124613DFA56AC607258D0FF
PAC-Info:
PAC-type = Cisco Trustsec
AID: 3ABDD52E1124613DFA56AC607258D0FF
I-ID: C3750-X-Access
A-ID-Info: ise.example.ru
Credential Lifetime: 16:06:19 MSK Mar 30 2015
PAC-Opaque: XXXXXXX
Refresh timer is set for 3y45w
!
Switch-Lab#show cts environment-data
CTS Environment Data
====================
Current state = COMPLETE
Last status = Successful
Local Device SGT:
SGT tag = 7-00:SGT_NetworkDevices
Server List Info:
Installed list: CTSServerList1-0001, 1 server(s):
*Server: 192.168.99.134, port 1812, A-ID 3ABDD52E1124613DFA56AC607258D0FF
Status = ALIVE
auto-test = TRUE, keywrap-enable = FALSE, idle-time = 60 mins, deadtime = 20 secs
Security Group Name Table:
0-00:Unknown
2-00:SGT_Employee_BYOD
3-00:SGT_Employee_Compliant
4-00:SGT_Contractor_Compliant
5-00:SGT_Guest
6-00:SGT_Remediation
7-00:SGT_NetworkDevices
8-00:SGT_Provisioning
9-00:SGT_Management
201-00:SGT_Quarantine
260-00:SGT_BYOD_DMZ (reserved)
Environment Data Lifetime = 86400 secs
Last update time = 19:59:47 MSK Wed Jan 28 2015
Env-data expires in   0:06:06:24 (dd:hr:mm:sec)
Env-data refreshes in 0:06:06:24 (dd:hr:mm:sec)
Cache data applied           = NONE
State Machine is running

Не надо забывать и о том, что все компоненты нашего стенда должны быть синхронизированы по времени, в моем случае использовался публичный NTP сервер.

Настройки контроллера БЛВС.

Настройку контроллера не так легко привести в статье, как настройку коммутатора, поэтому шаги по настройке через GUI можно пройти по примеру из документации по ссылке.

Тем не менее, я обязательно приведу часть своей конфигурации в текстовом виде:

config logging traceinfo disable debugging
config logging syslog level informational
config logging syslog level 6
config logging syslog host 192.168.99.134
config trapflags client enhanced-802.11-stats disable
config trapflags client max-warning-threshold enable
config trapflags client neighborclientsignal disable
config trapflags client enhanced-authentication disable
config trapflags client 802.11-authfail enable
config trapflags client 802.11-assocfail enable
config trapflags client 802.11-deauthenticate enable
config trapflags client enhanced-802.11-deauthenticate disable
config trapflags client nac-alert enable
config trapflags client 802.11-disassociate enable
config trapflags client enhanced-802.11-associate disable
config trapflags client 802.11-associate enable
config trapflags client excluded enable
config trapflags client authentication enable
config trapflags stpmode disable
config radius fallback-test username radtest
config radius fallback-test mode active
config radius auth add encrypt 1 192.168.99.134 1812 password ХХХХХХ
config radius auth network 1 enable
config radius auth management 1 enable
config radius auth retransmit-timeout 1 2
config radius auth rfc3576 enable 1
config radius auth enable 1
config radius acct add encrypt 1 192.168.99.134 1813 password ХХХХХХ
config radius acct retransmit-timeout 1 2
config radius acct network 1 enable
config radius acct enable 1
config snmp trapreceiver mode enable XXXXXX
config snmp trapreceiver create XXXXXX 192.168.99.134
config snmp syscontact “Dmitry Kazakov”
config snmp community mode enable XXXXXX
config snmp community ipaddr 192.168.99.134 255.255.255.224 XXXXXX
config snmp community accessmode rw XXXXXX
config snmp community create XXXXXX
config snmp syslocation LAB
config dhcp proxy disable bootp-broadcast disable
config custom-web ext-webauth-url https://ise.example.ru:8443/guestportal/Login.action
config custom-web redirecturl http://internet.example.ru
config custom-web webauth-type external
config cts sxp connection peer 192.168.99.129
config cts sxp default password encrypt 1 XXXXXX
config cts sxp enable
config sysname wlc
config interface address management 192.168.99.135 255.255.255.224 192.168.99.129
config interface address virtual 2.2.2.2
config interface address dynamic-interface employee 192.168.200.2 255.255.255.0 192.168.200.1
config interface vlan employee 200
config interface address dynamic-interface guest 192.168.230.2 255.255.255.0 192.168.230.1
config interface vlan guest 230
config interface dhcp management primary 192.168.99.132
config interface port management 1
config interface create employee 200
config interface dhcp dynamic-interface employee primary 192.168.99.132 secondary 192.168.99.134
config interface port employee 1
config interface create guest 230
config interface dhcp dynamic-interface guest primary 192.168.99.132 secondary 192.168.99.134
config interface port guest 1
config interface create mgmt 207
config interface dhcp dynamic-interface mgmt primary 192.168.99.132
config interface port mgmt 1

Отдельно я бы хотел привести настройки ACL (см. Рис. 15) и WLAN (см. Рис. 16) как наиболее интересные и вызывающие много вопросов:

PIC00012

PIC00012-2

PIC00012-3

PIC00012-5

PIC00012-6 PIC00012-7

Рис. 15

PIC00013PIC00013-1 PIC00013-2PIC00013-3 PIC00013-4 PIC00013-5PIC00013-6 PIC00013-7 PIC00013-8 PIC00013-9PIC00013-10 PIC00013-11

Рис. 16

Комментируя вышеуказанные рисунки, разберем предназначение ACL:

Имя списка доступа (ACL) Функциональное назначение
ACL_Provisioning_Redirect Используется как для функции URL-Redirect, так и для фильтрации трафика в политике ISE, отвечающей за централизованную WEB аутентификацию CWA.
ACL_BLACKHOLE_Redirect Используется для функции URL-Redirect в политике потерянных устройств на ISE.
ACL-EMPLOYEE-LIMITED Использован для фильтрации трафика пользователей группы Employee, вошедшими в сеть с личных устройств – сценарий BYOD.
ACL-AGENT-REDIRECT Используется для функции URL-Redirect для обеспечения поиска PolicyСервера для функции NAC/Anyconnect Agent с целью оценки состояния оконечного устройства.
ACL-POSTURE-REMEDIATION Используется в связке с предыдущим ACL для обеспечения карантинной фильтрации трафика от клиента на время оценки состояния.
ACL-INTERNET-ONLY Фильтрующий ACL для сценария подключения гостевой учетной записи.

Таблица 4

На рисунке 14 приведены настройки двух SSID, разберем их назначение:

Имя SSID
Функциональное назначение
Guest-byod Открытый SSID, необходимый для:

  • Гостевого доступа
  • Процедуры Provisioning, Device Registration, Onboarding наших корпоративных пользователей у которых нет супликанта 802.1х или сертификата или просто отсутствуют соответствующие настройки подключения к сети Employee.

По умолчанию выполняется перенаправление всех запросов на портал централизованной аутентификации CWA.

Employee Закрытый SSID с аутентификацией через 802.1x методы EAP-TLS или PEAP для корпоративных пользователей с выданным сертификатом или аутентифицирующихся контрактников по логину/паролю.
Сценарий PEAP оставлен как резервный.
Данный SSID может быть скрытым.

 

Таблица 5

Настройки МСЭ ASA.

Подробную пошаговую инструкцию по настройке ASA для работы в архитектуре TrustSec можно найти по следующей ссылке.

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

В моем примере настроек ASA указываем Radius сервер с функцией COA – это у нас ISE, устанавливаем связь с AD-агентом (подробности в моей другой статье).

Устанавливаем три SXP сессии для получения соответствия меток SGT <-> IP от других NAD (от WLC, коммутатора доступа и коммутатора Nexus 1000v).

dns domain-lookup DMZ
dns server-group EXAMPLE
name-server 192.168.99.132
domain-name example.ru
dns-group EXAMPLE
!
aaa-server ISE protocol radius
authorize-only
interim-accounting-update periodic 1
dynamic-authorization
aaa-server ISE (DMZ) host 192.168.99.134
key XXXXXX
aaa-server AD-Agent protocol radius
ad-agent-mode
aaa-server AD-Agent (DMZ) host 192.168.99.133
key XXXXXX
aaa-server BYOD-AD protocol ldap
aaa-server BYOD-AD (DMZ) host 192.168.99.132
ldap-base-dn DC=example,DC=ru
ldap-group-base-dn OU=GroupData,DC=example,DC=ru
ldap-scope subtree
ldap-login-password XXXXXX
ldap-login-dn EXAMPLE\asa-login
ldap-over-ssl enable
server-type microsoft
group-search-timeout 300
cts server-group ISE
cts sxp enable
cts sxp default password XXXXXX
cts sxp default source-ip 192.168.99.129
cts sxp reconciliation period 60
cts sxp retry period 60
cts sxp connection peer 192.168.99.135 source 192.168.99.129 password default mode local listener
cts sxp connection peer 192.168.99.150 password default mode peer speaker
cts sxp connection peer 192.168.99.115 source 192.168.99.1 password none mode local listener
user-identity domain EXAMPLE aaa-server BYOD-AD
user-identity default-domain EXAMPLE
user-identity action domain-controller-down EXAMPLE disable-user-identity-rule
user-identity inactive-user-timer minutes 120
user-identity logout-probe netbios local-system probe-time minutes 10 retry-interval seconds 10 retry-count 2 user-not-needed
user-identity poll-import-user-group-timer hours 1
user-identity ad-agent hello-timer seconds 20 retry-times 3
user-identity ad-agent aaa-server AD-Agent
snmp-server host DMZ 192.168.99.134 community XXXXXX version 2c
snmp-server location Moscow
snmp-server contact Dmitry Kazakov
snmp-server community XXXXXX
snmp-server enable traps syslog
dhcprelay server 192.168.99.132 DMZ
dhcprelay server 192.168.99.134 DMZ
dhcprelay enable Employee
dhcprelay enable Guest

После проведенных настроек можно сгенерировать PAC (делаем это в интерфейсе ISE для ASA по примеру с рисунка 11-2). Далее закачиваем PAC на ASA и инсталлируем по процедуре, описанной по ссылке.

Настройки коммутатора гипервизора VMWare ESX – Nexus 1000v.

version 5.2(1)SV3(1.1)
svs switch edition advanced
hostname n1kvsm
feature telnet
feature dot1x
feature netflow
feature cts
cts device-id n1kvsm password 7 XXXXXX
ip domain-lookup
ip host n1kvsm 192.168.99.115
radius-server host 192.168.99.134 key 7 “XXXXXX” pac authentication accounting
retransmit 3
aaa group server radius aaa-private-sg
aaa group server radius ISE
server 192.168.99.134
use-vrf management
errdisable recovery cause failed-port-state
snmp-server community C1sc0123 group network-operator
ntp server 91.189.94.4
aaa authentication cts default group ISE
aaa authorization cts default group ISE
vrf context management
ip route 0.0.0.0/0 192.168.99.1vlan 200
name BYOD-Employee
vlan 205
name CSM
vlan 206
name GOST-VPN
vlan 207
name MGMT
vlan 208
name ATTACKER
vlan 210
name BYOD-WiFi
vlan 230
name BYOD-Guest
vlan 260
name BYOD-DMZspanning-tree port type edge bpduguard default
no hardware ip verify fragment
port-channel load-balance ethernet source-mac
port-profile default max-ports 32
port-profile type vethernet BYOD-Employee
switchport mode access
switchport access vlan 200
org root/LAB-Home
policy static sgt 0xc8
no shutdown
state enabled
vmware port-group
port-profile type vethernet BYOD-Guest
switchport mode access
switchport access vlan 230
org root/LAB-Home
policy static sgt 0xe6
no shutdown
state enabled
vmware port-group
port-profile type vethernet BYOD-DMZ
switchport mode access
switchport access vlan 260
org root/LAB-Home
cts manual
policy static sgt 0x104
no shutdown
state enabled
vmware port-group
port-profile type vethernet BYOD-WiFi
switchport mode access
switchport access vlan 210
org root/LAB-Home
policy static sgt 0xd2
no shutdown
state enabled
vmware port-group
port-profile type vethernet CSM
switchport mode access
switchport access vlan 205
org root/LAB-Home
no shutdown
state enabled
vmware port-group
port-profile type vethernet GOST-VPN
switchport mode access
switchport access vlan 206
org root/LAB-Home
no shutdown
state enabled
vmware port-group
port-profile type vethernet MGMT
switchport mode access
switchport access vlan 207
org root/LAB-Home
no shutdown
state enabled
vmware port-group
port-profile type vethernet ATTACKER
switchport mode access
switchport access vlan 208
org root/LAB-Home
no shutdown
state enabled
vmware port-group
cts device tracking
cts interface delete-hold 60
cts sxp enable
cts sxp connection peer 192.168.99.1 source 192.168.99.115 password none mode listener vrf management
interface mgmt0
ip address 192.168.99.115/25
clock timezone MSK 3 0

Настройка политик в ISE для TrustSec.

На текущий момент мы уже успели настроить все устройства NAD, завести их на ISE, получить PAC и загрузить Environment-data. Далее я буду приводить довольно много скриншотов настройки политик в интерфейса ISE с краткими пояснениями.

Для начала нашей работы я бы хотел порекомендовать сразу настроить интерфейс политик ISE для работы с так называемыми Policy-Set, что сильно (на мой взгляд) облегчает работу с политиками и их отладку. Если Вы еще не включили режим отображения и настройки политик как Policy Set, сделать это можно в соответствующем пункте меню – Administration > System > Settings > Policy Sets.

Подробнее о Policy-Set можно почитать в соответствующем разделе документации по ссылке.

В моих Policy-Set я разделил политики по типу подключения Wired/Wireless/VPN, для этого я развел свои NAD на соответствующие типы устройств по созданным группам в режиме настройки Network Devices (см. Рис.17):

PIC00017

Рис. 17

Рассмотрим Policy-Set для беспроводной сети на рисунке 18. Под синей рамкой мы видим мой набор политик, их три – VPN/WIRED/WIRELESS. Для каждой политики можно написать свой собственный набор политик аутентификации и авторизации. Для того чтобы направить сессию пользователя в ту или иную политику задаются условия совпадения сессии с политикой, в моем случае классификация ведется по принадлежности запрашивающего NAD устройства к той или иной группе по типу подключения. Условие приведено в зеленой рамке на рисунке 18.

PIC00018

Рис. 18

Первоначально нам потребуется подключить внешнюю базу Аутентификации, в моем случае – MS AD (см. Рис 18-1). Выполняется данная процедура в соответствующем разделе ISE Administration > External Identity Sources > Active Directory. Подробные шаги по настройке даны в инструкции по ссылке. Выбрать необходимые группы в AD, которые в дальнейшем будут использованы для авторизации, можно в соответствующей закладке меню (см. Рис. 18-2)

PIC00018-2

Рис. 18-1

PIC00018-2-2

Рис. 18-2

Далее рассмотрим политики аутентификации, на примере рисунка 18. Красной рамкой обведена политика аутентификации для рассматриваемого Policy-Set. В политике рассматривается два сценария аутентификации:

  • MAB (MAC Authentication Bypass);
  • 802.1x с методами EAP-TLS и PEAP, каждый из которых запрашивает аутентификацию в своей базе;

В случае, когда пользователь не может пройти по указанным политикам MAB или 802.1х он отсылается на WEB аутентификацию и реализуется это следующим образом (см. Рис. 18-3). В моем примере настройки порта доступа коммутатора очередность аутентификации следующая – 802.1х -> MAB -> WEBAUTH.

Мы видим на рисунке 18-3 в поле MAB на событие user-not-found установлено действие Continue, в результате которого ISE отсылает ответ на NAD Radius:Access-Accept и назначает действие по умолчанию из политики авторизации (Wireless CWA), которая загружает URL-Redirect действие вместе c фильтрующим ACL на NAD.

PIC00018-1

Рис. 18-3

Далее перейдем к политике Авторизации, ее я рассмотрю для всех трех вариантов реализации Policy-Set. Мы обязательно рассмотрим содержимое моих политик. На рисунке 18-4, 18-5, 18-6 показаны в порядке следования политики авторизации для Wireless/Wired/VPN доступа.

PIC00018-3-1PIC00018-4-2
PIC00018-4-3

Рис. 18-4

PIC00018-5-1 PIC00018-5-2

Рис. 18-5

PIC00018-6

Рис. 18-6

Хочу обратить Ваше внимание на построение политик, как аутентификации, так и особенно, авторизации. Политика организована по принципу ACL построчно. После первого совпадения выполняется действие и политика дальше не анализируется, поэтому очень важно соблюдать порядок следования правил в политике. Рассмотрим политику по столбцам:

  • Первый – статус, показывает включено правило (сценарий) или нет;
  • Второй – название правила (сценария);
  • Третий – само условие правила, сформированное по булевой логике, которое должно быть удовлетворено параметрами сессии для применения профиля авторизации;
  • Четвертый – профиль авторизации.

Остановлюсь на графе под номером 4 – профиле авторизации, применяемом на успешное совпадение с условием правила. На каждое правило (сценарий) можно назначить одновременно два профиля, каждый из которых будет иметь свой тип. В приведенных примерах один профиль назначает метку SGT, а второй профиль выполняет классические методы авторизации. Второй профиль может выполнять функции:

  • Назначает загружаемый DACL;
  • Назначает динамически VLAN;
  • Назначает URL для перенаправления трафика пользователя для функций CWA/POSTURE/DEVICE REGISTRATION/PROVISIONING;
  • Указывает ACL для фильтрации трафика на WLC;
  • Назначает атрибуты авторизации Radius сессии как стандартные, так и vendor-specific;

Приведу пример полного интерфейса режима настройки DACL и профиля авторизации на рисунке 19 и 19-1:

PIC00019

Рис. 19

PIC00019-1

Рис. 19-1

Обращаю внимание на механизм настройки DACL. На рисунке 19 показано, что сам DACL с проверкой синтаксиса настраивается в соответствующем разделе меню ISE и в последующем на DACL можно сослаться в профиле авторизации на рисунке 19-1, где дополнительно настраивается множество дополнительных необходимых атрибутов авторизации. Все назначенные атрибуты показаны в окне, обведенном фиолетовой рамкой.

Далее в порядке перечисления я приведу примеры настроек всех политик авторизации, приведенных в лаборатории.

PIC00019-1-1 PIC00019-1-2 PIC00019-1-3Таблица 6

В таблице 7 я перечислю использованные DACL:

Имя DACL
Содержимое
 ACL-EMPLOYEE-LIMITED permit udp any any eq 68
permit udp any any eq 53
permit tcp any host 192.168.99.136
permit tcp any host 192.168.99.137
permit tcp any host 192.168.99.134 eq 443
deny ip any 192.168.0.0 0.0.255.255
permit tcp any any eq 80
permit tcp any any eq 443
permit tcp any any eq 143
permit tcp any any eq 993
permit tcp any any eq 995
permit tcp any any eq 465
deny ip any any log
 Internet_Only permit udp any any eq 53
permit udp any any eq 68
deny ip any 10.0.0.0 0.255.255.255
deny ip any 172.16.0.0 0.15.255.255
deny ip any 192.168.0.0 0.0.255.255
permit icmp any any echo
permit tcp any any eq 80
permit tcp any any eq 443
deny ip any any log
POSTURE_REMEDIATION permit udp any any eq domain
permit icmp any any
permit tcp any host 192.168.99.134 eq 8443
permit tcp any any eq 80
permit tcp any any eq 443
permit tcp any host 192.168.99.134 eq 8905
permit udp any host 192.168.99.134 eq 8905
permit udp any host 192.168.99.134 eq 8906
permit tcp any host 192.168.99.134 eq 80
permit ip any host 192.168.99.134
permit ip any host 192.168.99.132
permit ip any host 192.168.99.136
deny ip any any log
ACL_Provisioning permit udp any eq bootpc any eq bootps
permit udp any host 192.168.99.132 eq domain
permit ip any host 192.168.99.134
deny ip any any
ACL-EMPLOYEE-LIMITED-ASA permit udp any any eq 53
permit tcp any host 192.168.99.136
permit tcp any host 192.168.99.137
permit tcp any host 192.168.99.134 eq 443
permit tcp any any eq 80
permit tcp any any eq 443
permit tcp any any eq 143
permit tcp any any eq 993
permit tcp any any eq 995
permit tcp any any eq 465
deny ip any any log
ASA-ACL-Provisioning permit tcp any any eq 80
permit ip any host 192.168.99.134
permit icmp any any
permit udp any host 192.168.99.132 eq 53

Таблица 7

Настройка политик SGT довольно проста, фактически мы присваиваем нужную метку для того или иного сценария авторизации. Настройка меток производится в меню ISE Policy > Policy Elements > Results > TrustSec > Security Groups, в моем конкретном случае набор меток выглядит следующим образом (см. Рис. 20).

PIC00020

Рис. 20

Настройка Device Provisioning – настройка супликантов 802.1x.

Посмотрим на то как выглядит процесс заведения устройства вообще без предварительных настроек. В моем случае использован MacBook с OSX 10.9.5. Интерфейс общения с пользователем будет полностью русифицирован, если открывать браузер с русской локалью как основной (такового у меня не нашлось на текущий момент).

Процесс выдачи сертификатов и настройки супликантов в корпоративной среде по всем канонам рекомендуется выдаваться через GPO. В нашем случае я рассмотрю возможности по заведению устройств (Onboarding/Provisioning), предоставляемые самим ISE. Рассмотрим шаги, которые проходит пользователь Employee для получения сертификата, настройки 802.1x и регистрации устройства через стандартную процедуру ISE на рисунке 21.

PIC00021

Рис. 21

 Разбираем по шагам процесс с рисунка 21:

  1. Пользователь подключается к SSID Guest-BYOD без ввода паролей – это открытый SSID. Открывая браузер, пользователь автоматически перенаправляется на портал аутентификации CWA на ISE, где требуется ввести учетные данные.
  2. Пользователь ngnevano (участник группы AD Employee) ввел свои учетные данные и автоматически был переведен в процесс регистрации и заведения устройства (onboarding).
  3. В данном портале пользователь вводит название и краткое описание устройства с которого он зашел в сеть, MAC адрес уже автоматически подставлен в соответствующее не редактируемое поле.
  4. Пользователю предлагается скачать и запустить мастер настройки сетевого подключения.
  5. Запускаем приложение, нажимаем кнопку Старт.
  6. Мастер настройки скачивает соответствующий профиль подключения, настраивает проводное/беспроводное подключение на 802.1x, настраивает беспроводную сеть Employee с параметрами безопасности, выписывает и устанавливает сертификат пользователя.
  7. В результате окончания работы мастера компьютер успешно подключен к SSID Employee автоматически с аутентификацией 802.1х по методу EAP-TLS.

Предлагаю рассмотреть процесс настройки процесса выдачи параметров супликанта, выписки сертификатов и т.д. Настройки выполняются из меню Policy > Client Provisioning(см. Рис. 21-1).

PIC00021-1 PIC00021-1-1

Рис. 21-1

Как и в политике авторизации, мы имеем дело с набором правил, следующих друг за другом в определенной последовательности. Сначала я поместил правила обрабатывающие подключение пользователей через Wireless, далее Wired и в конце уже VPN подключения. Если со столбцами имя правила, условие и операционная система все более-менее логично, то я остановлюсь на последнем столбце – Results.

В столбце Results мы устанавливаем то, какие профили подключения устанавливать пользователю, какие агенты оценки состояния применять и их настройки. Раскроем позиции в категории Result на рисунке 21-2:

PIC00021-2

Рис. 21-2

В пункте Agent мы выбираем агента (а в случае Anyconnect и его профиль, об этом смотри в разделе оценки состояния), которым будет осуществляться процедура оценки состояния и на текущий момент у нас есть три выбора в зависимости от операционной системы Windows или MAC:

  • Anyconnect клиент версии 4 и выше с модулем Posture, устанавливается как приложение в ОС.
  • NAC Agent, устанавливается как приложение в ОС.
  • Web NAC Agent – запускается в браузере как Java апплет или Active-X в зависимости от используемого браузера и его возможностей.

В пункте Native Supplicant Provisioning мы и настраиваем функции того самого Мастера Настройки сетевого соединения, который видели на рисунке 21. Выбираем в поле Config Wizard последнюю версию мастера, из предложенных, для нужной нам ОС клиента. В поле Wizard Profile фигурирует настраиваемый нами профиль подключения к сети, перейдем к рассмотрению настройки этого профиля (см. Рис. 21-3).

PIC00021-3

Рис. 21-3

В разделе меню Policy > Policy Elements > Results > Client Provisioning > Resources у нас располагается много интересных ресурсов, интересует среди них нас профиль подключения для NSP (Native Supplicant Provisioning– или настройка супликанта 802.1х). Выбираем наш выделенный профиль и открываем его настройки кнопкой Edit (см. Рис. 21-4).

PIC00021-4Рис. 21-4

В этой форме мы указываем:

  • Название нашего профиля;
  • ОС клиента, для которой он будет работать;
  • Тип подключения: проводная или беспроводная сеть;
  • Разрешенные протоколы: TLS или PEAP;
  • В случае выбора TLS появляется поле шаблона сертификата, выбираем предоставленную опцию (сейчас мы и рассмотрим их настройку);

Начиная с версии ISE 1.3 появился функционал встроенного CA сервера и я просто не мог его не продемонстрировать в рамках выставки. Для того, чтобы настроить шаблон для выдачи сертификатов из внутреннего CA ISE, перейдем в пункт меню Administration > Certificates > Certificate Authority > Certificate Templates и настроим необходимые нам параметры шаблона выдаваемых сертификатов пользователей. Из этой же ветки меню можно управлять уже выданными сертификатами (см. Рис. 21-5).

PIC00021-5

Рис. 21-5

Настройка сервиса оценки состояния.

Перейдем к сервису оценки состояния – Posture Assessment, как его еще называют. Сервис дает возможность оценить:

  • Windows Update: Версии ОС, наличие Service Pack, Hotfix, версия браузера;
  • Антивирус установлен/ свежие ли базы;
  • Антишпионское ПО установлено/ свежие ли базы;
  • Файловые параметры;
  • Запущенные сервисы;
  • Установленные приложения;

После оценки состояния оконечного устройства, результат проверки может быть учтен в политике авторизации с использованием соответствующих параметров Compliant/Non-Compliant. Рассмотрим пошагово на рисунке 21-6 то, как будет выглядеть процесс оценки состояния для пользователя, после процедуры на рисунке 21.

PIC00021-6

Рис. 21-6

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

  1. Пользователь открывает браузер и попадает автоматически на портал, где его просят пройти оценку соответствия. Если бы клиент уже был установлен, то сразу бы начался процесс под шагом 6 и 7.
  2. После нажатия кнопки НАЧАТЬ, производится попытка обнаружения агента на компьютере пользователя, по прошествии 10 секунд и при неудачном процессе обнаружения, пользователю выводятся подробные инструкции по дальнейшим шагам.
  3. Прочитав инструкции, пользователь нажимает ссылку “Нажмите здесь и установите Anyconnect”.
  4. Выскакивает окно скачивания установщика клиента Anyconnect.
  5. Пользователь устанавливает агент Anyconnect (Естественно имея соответствующие права на PC).
  6. Агент установлен и запущен. Началась проверка соответствия, сразу же мы видим окно предупреждения о том, что на компьютере не установлено Anti Malware ПО и предлагается исправить эту проблему, нажав кнопку Start. Нажимаем кнопку Startи на компьютер скачивается установщик агента Anti Malware с Remediation сервера. Начинаем установку агента.
  7. Агент Anti Malware установлен, Anyconnect показывает статус Compliant, ISE производит переавторизацию сессии (CoA) клиента и выдает метку SGT SGT_Employee_Compliant (3), получаем полный доступ к сети.

Настройка системы оценки состояния начинается с написания условий, из набора условий будут формироваться требования к оцениваемой системе. Все возможные типы условий (как уже готовых, так и вручную задаваемых) и их различные логические связки настраиваются в пункте меню Policy > Policy Elements > Conditions. В моем лабораторном стенде проверялось, запущен ли специализированный агент борьбы с Malware – Cisco FireAMP (см. Рис. 21-7) условие для проверки писалось мной вручную и оно тривиально.

PIC00021-7

Рис. 21-7

Далее мы собираем наши условия и формируем из них требования к системе применительно к конкретным типам ОС. Но для начала мы соберем все составляющие перед переходом к формированию политики требований. Последним необходимым компонентом станет действие исправления состояния (Remediation). Действий по исправлению довольно много, часть из них может быть автоматической. В моем примере, я лишь предоставляю клиенту возможность скачать агент FireAMP со специального Remediation сервера (обычный WEB сервер с IIS). Настройка действий исправления производится из меню Policy > Policy Elements > Results > Posture > Remediation Actions(см. Рис. 21-8).

PIC00021-8

Рис. 21-8

Переходим к формированию единого цельного требования (Requirement), которых у нас может быть множество к системе. Настройка требований выполняется из пункта меню Policy > Policy Elements > Results > Posture > Requirements, где мы называем наше требование, указываем операционную систему, подставляем наши условия и действия по исправлению (см. Рис. 21-9).

PIC00021-9

Рис. 21-9

На текущем этапе мы сформировали требования, которые мы хотим гранулярно применять к различным группам пользователей, возможно к пользователям разных офисов и т.д. Такую гибкость нам дает политика Posture – головная политика в настройке системы оценки состояния, настраивается из меню Policy > Posture. Она похожа чем-то на политику авторизации, где можно формировать гибкие условия для правил: которым должна удовлетворять сессия пользователя, чтобы к ней были применены соответствующие требования политики оценки состояния. Посмотрим на рисунок 21-10, где моя базовая политика оценки состояния включает всего 2 условия:

PIC00021-10

Рис. 21-10

Правило под номером один формирует требование проведения проверки к пользователям из группы Employee и срабатывает оно единственный раз, когда пользователь изначально соединяется к сети. Характеризуется первичная проверка в условии параметром Initial_assesment.

Второе правило представляет собой повторяющуюся проверку, которая происходит уже во время успешно подключенного и работающего клиента к сети. Характеризуется повторяющаяся проверка в условии параметром Reassesment. Периодичность оценки состояния можно задавать в разделе меню Administration > Settings > Posture > Reassessments.

Обратите внимание, что на рисунке 21-2 в разделе Client Provisioning, я обратил внимание на профиль Anyconnect, о котором мы сейчас и поговорим. Данная настройка и профиль к нему нам необходимы, чтобы пользователи могли установить Anyconnect Client версии 4.0 с модулем posture. Создадим же профиль для Anyconnect, дабы в последующем он нам стал доступен в выборе профилей на этапе Client Provisioning. Необходимо создать два профиля, один из которых на функцию Posture, второй на основные функции Anyconnect клиента.

Создадим первый профиль на Posture пройдя по следующим пунктам меню Policy > Policy Elements > Results > Client Provisioning > Resources далее +ADD > NAC Agent of Anyconnect Posture Profile, в ниспадающем меню выбираем Anyconnect. Пример моего Posture Profile на рисунке 21-11:

PIC00021-11

Рис. 21-11

Используем созданный Posture Profile в настройке профиля Anyconnect пройдя по следующим пунктам меню Policy > Policy Elements > Results > Client Provisioning > Resources далее +ADD > Anyconnect Configuration. Вариант моей конфигурации профиля приведен на рисунке 21-12.

PIC00021-12

Рис. 21-12

Теперь политика оценки состояния может считаться настроенной, за дополнительной информацией по настройкам и их назначению лучше обратиться к официальной документации.

Глубокая интеграция сервисов IDFW.

Последним штрихом в интеграции нашего решения будет подключение полноценного сервиса IDFW с прозрачной передачей имени пользователя оконечного устройства при помощи интеграции ISE и CDA агента. Первичные настройки для развертывания инфраструктуры CDA и IDFW Вы можете прочитать в моей предыдущей статье, посвященной этой теме.

Для начала мы обновим CDAдо последней актуальной версии (на момент написания статьи – patch 4). Далее настраиваем CDA на прием SYSLOG от ISE (см. Рис. 22):

PIC00022

Рис. 22

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

Рассмотрим ситуацию заведения нового устройства в сети, IPAD сотрудника с логином ngnevano. В списке живых сессий ISE данная активность будет выглядеть следующим образом (см. Рис. 23, 23-1, 23-2):

PIC00023

Рис. 23

Приведу вырезки из отчетов активности пользователя ngnevano с деталями применённых профилей авторизации (см. Рис. 23-1 и 23-2).

PIC00023-1

Рис. 23-1

PIC00023-2

Рис. 23-2

На рисунке 23-1 изображен профиль авторизации, примененный в процессе регистрации устройства, веб-аутентификации и загрузки сертификата. На рисунке 23-2 устройство уже аутентифицировано по сертификату и ему назначена метка SGT сценария Employee BYOD.

Посмотрим на логи МСЭ ASA, который фильтрует запросы во внешние сети от данного клиента (Затертая часть это домен пользователя, я его скрыл):

PIC00024

Рис. 24

В интерфейсе политик фильтрации ASDM – Access Control мы можем видеть пример фильтрации ACL с использованием меток SGT:

PIC00024-1

Рис. 24-1

Далее обратим внимание на лог системы контентной фильтрации Cisco Web Security Appliance, которая получает в текущей версии WSA8.5.0 информацию о пользователях с CDA. CDA текущей версии может брать информацию об активных пользователях непосредственно с ISE (что намного точнее, нежели из классического Security Log) (см. Рис. 25). Стоит отметить, что последующая версия WSA будет интегрироваться с ISE уже напрямую.

PIC00025Рис. 25

Заключение.

В рамках данной статьи мы рассмотрели принципы работы, архитектуру и пример настройки лабораторного стенда на основе архитектуры Cisco TrustSec.

Реализация данной архитектуры управления доступом дает неоспоримую гибкость в реализации политики сетевой безопасности компании, имеет глубочайшую интеграцию внутри продуктового портфолио Cisco.

Интеграция решения по управлению доступом Cisco ISE имеет не только богатый собственный функционал, но и интегрируется с рядом партнерских решений вроде ведущих решений MDM (Mobile Device Manager) рынка, CTD (Cisco Threat Defense) в партнерстве с Lancope, а богатый API и pxGrid еще больше расширяет сферу возможных применений продукта и его интеграционный потенциал.

Дополнительные ссылки:

Русскоязычный ролик по Advanced Malware Protection – ссылка;

Новый портал с русскоязычными документами по безопасности Cisco – ссылка.

 

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