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

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

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

Вообще, у компании Cisco Systems на данный момент в арсенале имеется богатый портфель решений по идентификации, как пользователей, так и устройств, получающих доступ к сети благодаря добавленному несколько лет назад продукту контроля и учета доступа в сеть – Identity Services Engine (ISE). I dentity 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.

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

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

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

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

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

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

Адресация тестового стенда: 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, настройку веб портала можно выполнить по следующей инструкции.

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

  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_agentOwner для этих записей.HKEY_CLASSES_ROOT\CLSID\; HKLM\Software\Classes\Wow6432Node\CLSID\
  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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

📎📎📎📎📎📎📎📎📎📎