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

Дмитрий Казаков


Доброго дня, друзья. 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 и/или его группового членства.


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


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


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

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


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


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


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


 Создаем пользователя и добавляем его в группу Domain Admins, в нашем случае пользователь cda_agent.
Создаем обычного системного пользователя для интеграции с ASA, в нашем случае — asa-login.
Изменяем две записи реестра: указанным записям ставим права доступа для пользователя 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}
Убеждаемся, что ведется аудит лог на события логина
  Заходим через меню Пуск 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 разделен на три части:


Active Directory Server — привязка AD серверов и их ассоциация с определенным доменом.
Consumer Devices — конфигурация устройств, которым будет отдаваться информация о маппинге IP<->Username
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 limitAttempting 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.12Validating Shared Secret between WSA and Primary AD agent…
Success: AD agent 192.168.10.12 verified shared secretTest 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

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


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


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


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


WMI 
Installation and Configuration Guide for Context Directory Agent, Release 1.0
Cisco ASA Configuring Identity Firewall v9.1 CLI
WEB Security Appliance End-User Guide
Web Security Using Cisco WSA Deployment Guide


Источник: Cisco