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

Интеграция сервисов пользовательского доступа с привязкой к Active Directory на межсетевых экранах Cisco ASA и устройствах защиты Вэб-трафика Cisco Web Security Appliance.


April 10, 2014


Доброго дня, друзья. Cегодня я хотел бы осветить очень интересную, однако, как показывает опыт, слабо освещенную в Рунете тему интеграции сервисов защиты по пользователям (Identity Firewall  – IDFW) в продуктах Cisco ASA и Web Security Appliance.

Вообще, у компании Cisco Systems на данный момент в арсенале имеется богатый портфель решений по идентификации, как пользователей, так и устройств, получающих доступ к сети благодаря добавленному несколько лет назад продукту контроля и учета доступа в сеть – Identity Services Engine (ISE). Identity Services Engine (ISE) дает нам возможность использовать сторонние базы аутентификации (AD, LDAP, Radius, RSA, Сертификаты и строить политики доступа с учетом типа устройств, их принадлежности, состояния, местоположения, времени и вида подключения.

Тем не менее в данной статье я бы хотел освeтить технологию прямой интеграции с каталогом пользователей AD, используя программного агента Context Directory Agent (CDA).

Данная технология представляет собой интеграцию сервисов прозрачной аутентификации в каталоге пользователей Active Directory и фильтрации как трафика в целом по политике безопасности на межсетевом экране  ASA, так и фильтрации контента и приложений HTTP/HTTPS с защитой от вредоносного программного обеспечения (Malware) и угроз на шлюзе Web Security Appliance. Простым языком говоря, теперь мы можем строить нашу политику фильтрации на МСЭ и контентную фильтрацию на базе не статичных IP адресов, а на основе логина пользователя в AD и/или его группового членства.

Компоненты решения

Итак, перечислим основные компоненты решения:

  1. Active Directory сервер (DC) – Контроллер домена , на котором ведется журнал событий безопасности (Security log), отмечающий события логина пользователей и соответствие их адресов IP. Поддерживаемые CDA v1.0.0.011-2 версии – Windows 2003, Windows 2003R2, Windows 2008, Windows 2008 R2, Windows 2012.
  2. Context Directory Agent (CDA) – Отдельная виртуальная машина на базе ОС Linux. Поставляется как готовый к развертыванию OVA Template, развертывание и настройка занимает минуты. Служит для получения с DC соответствия IP<->Username и обмена этой информацией с потребителями.
  3. Cisco ASA (Опционально) – Межсетевой экран Cisco Adaptive Security Appliance с базовой лицензией.
  4. Cisco Web Security Appliance (WSA) (Опционально) – Шлюз контентной фильтрации и защиты от WEB угроз. Доступен в виде виртуальной машины, также поставляется как OVA Template.

Концептуальная схема решения:

 img-1

img-2

Схема интеграции гибридной аутентификации:

img-3

Алгоритм и принцип работы схемы

Поскольку  системам межсетевого экранирования и контентной фильтрации требуется иметь знания относительно структуры Active Directory и членства пользователя в группах, на каждом необходимом межсетевом экране требуется настроить сервер аутентификации с непривилегированным служебным пользователем AD для просмотра дерева AD. Вышеуказанная связь с сервером каталогов требуется для загрузки пользовательских групп и списков пользователей, состоящих в них, что будет служить основой для построения правил фильтрации. Таким образом, мы настраиваем связь ASA <-> контроллер домена по протоколам LDAP/S. Настройки на ASA можно проводить как через консоль, так и через ASDM и систему централизованного управления устройствами безопасности Cisco Systems – Cisco Security Manager.  Стоит отметить, что помимо уже имеющихся в AD групп пользователей, администратор ASA может создавать свои собственные группы и использовать их в политиках доступа.

Также на ASA настраивается связь с одним или несколькими агентами  CDA, для получения текущих соответствий IP<->Username, то есть IP адреса аутентифицированных пользователей в AD. Связь ASA с CDA происходит по протоколу Radius. В зависимости от настроек, ASA может либо загружать полную базу соответствий, либо отсылать запросы об IP пользователя на CDA. Контроль активности пользователя в сети настраивается опционально, ASA может проверять активность пользователя путем отсылки запросов по протоколу NETBIOS/UDP. Для успешного прохождения проверки активности, протокол NETBIOS/UDP должен быть разрешен на Windows Firewall клиента. В случае отключения AD, МСЭ ASA может опционально отключать правила фильтрации, содержащие привязку к пользователям и группам.

В случае, если пользователь является гостем и не может аутентифицироваться в AD посредством логина в домен, предусмотрен режим Proxy аутентификации на ASA с предоставлением WEB-портала.  Что же касается пользователей, не входящих в AD, а являющихся гостями, контрактниками, студентами и т.д., их можно аутентифицировать путем интеграции в инфраструктуру Identity Firewall сервера контроля доступа – ISE. При интеграции с ISE, вопрос контроля активности пользователей и устройств можно будет во многом снять. Интеграция с ISE будет описана в дальнейших статьях.

CDA, в свою очередь, и является тем волшебным компонентом, который получает в режиме реального времени информацию о о аутентифицированных в AD пользователях, и их текущем адресе IP. CDA имеет простой и удобный WEB интерфейс, где с одной стороны мы подключаем к нему AD сервера из интересующего нас домена для чтения журнала Security Log посредством Windows Management Instrumentation (WMI), а с другой стороны регистрируем на нем весь список устройств, с которыми мы будем обмениваться этими данными. На данный момент CDA  может обмениваться данными со следующими устройствами: ASA-CX, WSA, ASA и сервисом облачной фильтрации контента Cisco CWS.

Стоит отметить интереснейший функционал агента CDA. В случае, если Вы получаете удаленный доступ к корпоративной сети посредством Remote Access VPN, будь то средствами классического IPSEC Remote Access или SSL-VPN Anyconnect, если аутентификация происходит через LDAP либо по сертификатам, выданным Enterprise CA на базе Microsoft CA Server, VPN шлюз, принявший соединение и выдавший туннельный IP адрес клиенту, автоматически пересылает на CDA текущее соотвествие VPNIP Address <-> Username. Впоследствии CDA пересылает эту информацию всем зарегистрированным на нем устройствам. Таким образом, пользователь, подключившись удаленно, получает права доступа прозрачно, как будто находится в офисе.

Расширяемость CDA:

  • CDA поддерживает до 80 контроллеров домена (DC).
  • Кеширует до 64,000 соответствий адресов IP на имя пользователя.
  • Поддерживает до 100 зарегистрированных устройств.
  • CDA обрабатывает до 1000 новых соответствий адресов IP на имя пользователя в секунду (входящих и исходящих).

WSA – система контентной фильтрации Web/Ftp трафика, лидер Gartner за последние годы в своей области. Предоставляет сервисы фильтрации URL корпоративного уровня, с категоризацией сайтов, контентной фильтрацией, контролем приложений эвристическим анализом содержимого, интеграцией с системами защиты от утечек (DLP), антивирусной защитой и защитой от вредоносных приложений (Malware). Рассматриваемая интеграция позволяет реализовать прозрачную фильтрацию трафика пользователей – членов домена по отдельным политикам, привязываясь к их членству в AD. Для интеграции понадобится пользователь AD с правами доменного администратора для создания учетной записи компьютера, ассоциированного с WSA  в базе AD. Данная интеграция нужна с целью получения структуры AD для написания политик доступа, а также для выписки Kerberos Ticket при прохождении активной аутентификации через WEB портал в том случае если пользователь не имеет активного соответствия на CDA (BYOD сценарий без ISE).

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

NB! Убедитесь, что время синхронизировано с помощью NTP на всех компонентах решения – ASA, AD, CDA и WSA.

Конфигурация решения

Установка виртуальных машин

CDA имеет следующие требования к виртуальной машине и устанавливается с образа ISO.

NB!  Для корректной инсталляции VM укажите тип сетевой карты E1000 и жесткого диска тип IDE.

Рекомендуемые требования:

CPU Intel Xeon 2.66 GHz Q9400 (Quad Core)
System memory 4 GB of SDRAM
Hard disk space 250 GB
NIC 1 NIC or virtual NIC

 

Минимальные требования:

CPU 2 Virtual Processors
System memory 2 GB of SDRAM
Hard disk space 120 GB
NIC 1 virtual NIC

 

Обязательно установите последний патч на CDA через репозиторий. Процесс установки патча как и шаги быстрой инсталляции можно найти по ссылке.

WSA в рамках этой статьи ставим в режиме прозрачного прокси WCCPv2. Работать WSA будет на виртуальной машине VMWARE и разворачивается посредством OVA Template в несколько простых шагов. OVA template можно скачать с сайта Cisco Systems при наличии соответствующей подписки, либо запросить у партнера в рамках пилота.

Ссылка на быструю инструкцию по установке.

Системные требования для виртуальных машин различной пользовательской емкости/производительности:

img-4
Адресация тестового стенда:
            CDA: 192.168.10.2
            MS DC: 192.168.1.1 (DOMAIN: TESTDOM.LOCAL)
            WSA: 192.168.10.3
            ASA (inside): 192.168.10.1

Первичная конфигурация ASA

! ### Настраиваем AD Ldap и связь с CDA.aaa-server AD-TMP protocol ldap
aaa-server AD-TMP (ad-domain) host 192.168.1.1
ldap-base-dn DC=testdom,DC=local
ldap-scope subtree
ldap-login-password PASSWORD
ldap-login-dn TESTDOM\asa-login
server-type microsoft
ldap-group-base-dn OU=GroupData,DC=testdom,DC=local
ldap-over-ssl enable
group-search-timeout 300
!
aaa-server AD-Agent protocol radius
ad-agent-mode
aaa-server AD-Agent (mgmt) host 192.168.10.2
key PASSWORD
user-identity ad-agent aaa-server AD-Agent
user-identity enable
user-identity domain TESTDOM aaa-server AD-TMP
user-identity action domain-controller-down TESTDOM disable-user-identity-rule
user-identity logout-probe netbios local-system probe-time minutes 10 retry-interval seconds 10 retry-count 2 user-not-needed
user-identity inactive-user-timer minutes 120
user-identity poll-import-user-group-timer hours 1
user-identity ad-agent active-user-database full-download
user-identity ad-agent hello-timer seconds 20 retry-times 3
user-identity ad-agent aaa-server  AD-Agent
! ### Настраиваем WCCPv2 прозрачное проксирование на WSA
access-list ACL-WEBPROXY-TRAFFIC extended permit tcp 192.168.x.0 255.255.255.0 any eq https
access-list ACL-WEBPROXY-TRAFFIC extended permit tcp 192.168.x.0 255.255.255.0 any eq www
! ### Обратите внимание, при конфигурации WCCP c ASA->WSA не стоит забывать, что ASA не умеет
! ### делать GRE, таким образом перенаправление может происходить только по L2,
! ### таким образом WSA должен быть в том же VLAN, что и интерфейс nameif ASA, откуда
! ### приходят проксируемые клиенты, в нашем случае интерфейс inside.
! ### В случае использования для проксирования по WCCP маршрутизатора, ограничений нет.
wccp 90 redirect-list ACL-WEBPROXY-TRAFFIC
wccp interface inside 90 redirect in
!

Если необходимо настроить Proxy аутентификацию для клиентов, не попавших в таблицу соответствия CDA, настройку веб портала можно выполнить по следующей инструкции.

Ассоциированная схема:

 img-5  img-6

Комментарий к рисунку:

  1. Пользователь инициирует  HTTP/S запрос.
  2. ASA делает прозрачный редирект запроса на WSA.
  3. WSA проверяет запрос и запрещает его, в случае нарушения политик.
  4. WSA инициирует новое соединение к запрошенным WEB ресурсам, если соединение разрешено.
  5. Web Server отвечает контентом, который пересылается на WSA.
  6. WSA проверяет контент по политикам и форвардит обратно клиенту, если нарушений не найдено.

Конфигурация Домен-контроллера

Для каждой версии Windows доменного контроллера есть своя подробная инструкция по настройкам, приведенная по ссылке.

Приведем пример Windows 2008 R2 и пользователя с правами доменного администратора, который мы будем использовать для интеграции с CDA.

  1.  Создаем пользователя и добавляем его в группу Domain Admins, в нашем случае пользователь cda_agent.
  2. Создаем обычного системного пользователя для интеграции с ASA, в нашем случае – asa-login.
  3. Изменяем две записи реестра: указанным записям ставим права доступа для пользователя cda_agent как Full Control, но сначала делаем cda_agent Owner для этих записей.
    HKEY_CLASSES_ROOT\CLSID\{76A64158-CB41-11D1-8B02-00600806D9B6};
    HKLM\Software\Classes\Wow6432Node\CLSID\{76A64158-CB41-11D1-8B02-00600806D9B6}
  4. Убеждаемся, что ведется аудит лог на события логина
  •   Заходим через меню Пуск Start > Programs > Administrative Tools > Group Policy Management.
  •   Спускаемся по дереву до нужного нам домена.
  •    Выбираем Default Domain Controller Policy, жмем правой кнопкой  Edit.
  •    Появляется The Group Policy Management Editor.
  •    ВыбираемDefault Domain Controllers Policy > Computer Configuration > Policies > Windows Settings > Security Settings .

Для Windows Server 2008 R2 и Windows 2012, выбираем Advanced Audit Policy Configuration > Audit Policies > Account Logon.
Для двух пунктов, Audit Kerberos Authentication Service и Audit Kerberos Service Ticket Operations, убеждаемся что пункт Policy Setting включает действие Success.

  • Через командную строку обновляем политику gpupdate /force.

        5. Отключаем Windows Firewall, либо делаем иcключение для WMI.

Конфигурация CDA

img-26

Интерфейс домашней страницы CDA разделен на три части:

  1. Active Directory Server – привязка AD серверов и их ассоциация с определенным доменом.
  2. Consumer Devices – конфигурация устройств, которым будет отдаваться информация о соответствии IP<->Username
  3. Syslog сервера – настройка внешнего логирования, например прием логов с ISE.

Используя кнопку ADD первого раздела добавляем ассоциацию с доменом.

В рамках данной статьи для простоты будем использовать учетную запись пользователя для связи с AD, имеющего права доменного администратора – cda_agent (Также есть вариант использования обычного пользователя, см. документацию)

Далее добавляем кнопкой ADD второго раздела необходимые устройства, с которыми будет производиться обмен записями соотвествия  пользовательских адресов IP и имен.

Добавляем новый сервер AD: Добавляем ASA/WSA:
 img-8  img-25

В разделе меню Mappings -> IP to Identity можно увидеть текущие соответствия:

img-10

Конфигурация WSA

Для успешной настройки все доменные имена WSA настроенные во время инсталляции должны корректно разрешаться службой DNS.

В первую очередь, после первичной настройки WSA нам требуется принять перенаправляемый с ASA трафик по протоколу WCCPv2. Для этого переходим в меню Network -> Transparent Redirection, убеждаемся, что в поле Transparent Redirection Device установлено значение WCCPv2 Router.

img-24

В пункте WCCP v2 Services нажимаем кнопку Add Service для добавления сервиса WCCP.

Выбираем Dynamic Service ID и указываем 90, как и на ответной стороне ASA. Указываем порты, которые будем слушать. В поле Router IP Addresses вводим IP адрес Inside интерфейса ASA, с которого будет приходить WCCPv2 редирект.

img-23 img-22

Произведем настройку аутентификационного реалма, перейдем в раздел меню Network-> Authentication.

img-11

Далее в окне настройки аутентификации нажимаем кнопку Add Realm.

img-12

Для присоединения к домену нажмите кнопку Join Domain и введите логин/пароль пользователя cda_agent.

После проведенных настроек можно проверить их корректность нажав кнопку в конце страницы Start Test:

Checking DNS resolution of WSA hostname(s)…
Success: Resolved ‘wsa.testdom.local’ address: 192.168.x.13
Success: Resolved ‘wsa-data.testdom.local’ address: 192.168.x.148
Success: Resolved ‘wsa-data’ address: 192.168.x.148Checking DNS resolution of Active Directory Server(s)…
Success: Resolved ‘192.168.1.1’ address: 192.168.1.1Checking DNS resolution of AD Server(s)’ full computer name(s)…
Success: Resolved ‘dc.testdom.local’ address: 192.168.1.1Validating configured Active Directory Domain…
Success: Active Directory Domain Name for ‘192.168.1.1’ : TESTDOM.LOCALAttempting to get TGT…
Success: Kerberos Tickets fetched from server ‘192.168.1.1’ :Checking local WSA time and server time difference…
Success: AD Server time and WSA time difference within tolerance limit

Attempting to fetch group information…
Success: Able to query for Group Information from Active Directory server ‘192.168.1.1’.

Checking DNS resolution of Primary Active Directory agent…
Success: Resolved ‘192.168.10.12’ address: 192.168.10.12

Validating Shared Secret between WSA and Primary AD agent…
Success: AD agent 192.168.10.12 verified shared secret

Test completed successfully.

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

После успешного вывода результата теста соединения мы сохраним и применим настройки, нажав кнопки Submit и Commit Changes

Далее переходим в настройку Identity, переходим в раздел меню Web Security Manager -> Identities

В разделе меню Identities нажимаем кнопку Add Identity.

Настраиваем соответственно проведенному примеру, либо меняем параметры на индивидуальные.

img-13 img-14

Если для текущего клиента нет записи о соотвествии, полученной от CDA (transparent auth), тогда применяется принудительная аутентификация через портал по схеме Kerberos, либо можно просто дать гостевой доступ по политики Global Policy.

После добавления нового Identity мы сохраним и применим настройки, нажав кнопки Submit и Commit Changes.

Для написания собственных политик фильтрации WEB контента с привязкой к доменным записям идем в Web Security Manager -> Access Policy. По умолчанию имеем только Global Policy, оставим ее для гостевых учетных записей, и создадим свою новую политику, нажав кнопку Add Policy.

Настраиваем политику соответственно проведенному ниже примеру, либо меняем параметры на индивидуальные.

img-15img-16

Здесь можно указать к каким группам будет относиться данная политика или/и конкретных пользователей, группы можно выбрать в разделе Authorized Users and Groups.

Конфигурация ASA вторичная настройка

На данном этапе у нас уже функционирует CDA, есть привязка ASA по Radius к CDA и по LDAP к Active Directory, это все что нам нужно для использования функции Identity Firewall.

Теперь можно открыть ASDM и настроить наш привычный фильтр Access Control List (ACL), но с учетом групп и пользователей.

В привычном окне ACL теперь можно выбрать параметр user и указать интересующих пользователей из списка и группы.

img-17

img-18

img-19

Хочется отдельно отметить возможность написания правил не только с основывающихся на IP адресах как таковых, пользователях и группах, но и полных доменных именах (FQDN) сайтов. Так в указанном примере, пользователи User1, User2 и члены группы WSA-Test имею возможность ходить по HTTP на Microsoft.com (объект Microsoft).

Ограничения и особенности IDFW на ASA

  • IDFW поддерживается в режимах как единого МСЭ, так и множества виртуальных МСЭ (single and multiple context).
  • IDFW поддерживается как в режиме маршрутизирующего МСЭ (Routed) так и в режиме прозрачного (transparent) МСЭ.
  • В режиме горячего резервирования устройств поддерживается репликация таблицы соответствия  IP <-> Username и статуса AD Agent. Тем не менее, база пользователей и групп с AD не реплицируется.
  • AD Agent надо настраивать на связь с обоими устройствами отказоусточивого кластера.
  • Поддержка IPv6.
  • Следующие ASA функции не поддерживают использование IDFW и FQDN в расширенных фильтрах (Extended ACL):
    • Route maps
    • Crypto maps
    • WCCP
    • NAT
    • Group policy (except for VPN filters)
    • DAP

Полный список ограничений можно найти по ссылке.

Лицензирование

Получение и лицензирование компонент решения :

  1. ASA – любой МСЭ Cisco ASA, с версии программного обеспечения начиная с ASA 8.4(2), достаточно базовой лицензии.
  2. CDA (Context Directory Agent) – бесплатен и доступен для скачивания с сайте cisco.com соответствующего раздела и при наличии подписки на поддержку МСЭ ASA (Smartnet).
  3. WSA – Web Security Appliance, отдельного лицензирования функции интеграции нет. Для аутентификации Kerberos требуется обновление программного обеспечения  до версии ASYNC OS 8.x. Для получения продукта на тестирование, обратитесь к Вашему представителю в компании Cisco Systems или партнеру.

Полезные ссылки

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