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

Вступление.

Доброго дня уважаемые друзья! В данной статье мы рассмотрим пример настройки архитектуры контроля сетевого доступа 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).

Рис. 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 канал до ближайшего устройства, которое либо может отфильтровать трафик, основываясь на метках, либо сможет аппаратно затегировать и отправить дальше уже тегированный трафик.

Рис. 2

Рис. 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).

Рис. 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).

Рис. 4-1

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

Рис. 4-2

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

Рис. 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 означает возможность тегирования трафика.

Рис. 6

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

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

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

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

   Рис. 7

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

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

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

   
   Рис. 8

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

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

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

   Рис. 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 адрес.

   Рис. 9

Стенд Cisco Connect 2014.

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

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

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

Рис. 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.

Рис. 11-1

Рис. 11-2

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

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

Рис. 12

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

Рис. 13

Рис. 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) как наиболее интересные и вызывающие много вопросов:

Рис. 15

Рис. 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 ISEvrf 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):

Рис. 17

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

Рис. 18

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

Рис. 18-1

Рис. 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.

Рис. 18-3

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

Рис. 18-4

Рис. 18-5

Рис. 18-6

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

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

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

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

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

Рис. 19

Рис. 19-1

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

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

Таблица 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).

Рис. 20

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

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

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

Рис. 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).

Рис. 21-1

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

В столбце Results мы устанавливаем то, какие профили подключения устанавливать пользователю, какие агенты оценки состояния применять и их настройки. Раскроем позиции в категории Result на рисунке 21-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).

Рис. 21-3

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

Рис. 21-4

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

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

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

Рис. 21-5

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

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

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

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

Рис. 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) условие для проверки писалось мной вручную и оно тривиально.

Рис. 21-7

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

Рис. 21-8

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

Рис. 21-9

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

Рис. 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:

Рис. 21-11

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

Рис. 21-12

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

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

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

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

Рис. 22

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

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

Рис. 23

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

Рис. 23-1

Рис. 23-2

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

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

Рис. 24

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

Рис. 24-1

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

Рис. 25

Заключение.

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

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

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

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

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

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