Identity Firewall (здесь и далее IFW) является эволюцией технологии фаирволла на сетевых экранах Cisco ASA. Главной особенностью технологии является возможность написания различных правил доступа (напр. ACL) относительно не IP-адресов, а конкретно для определенного пользователя или же группы пользователей. Это может быть очень удобно для сетей, где у пользователей нет фиксированных IP-адресов, т.е. в подавляющем большинстве компаний.
Технология IFW серьезно завязана на службу каталогов Active Directory (AD). IFW интегрируется в структуру AD посредством специального ПО, называемого AD-агентом, которое передает на сетевой экран актуальную информацию о связке «имя пользователя-IP адрес». Весь процесс для пользователя прозрачен и от него не требуется ввода какой-либо дополнительной информации после выхода в домен (что было неудобно при технологии cut-through-proxy).
Концептуально IFW состоит из трех компонентов: Cisco ASA, Microsoft AD, AD Agent. Рассмотрим как указанные компоненты взаимодействуют друг с другом.
ASA—>AD: взаимодействие между ASA и службой каталогов осуществляется по протоколу LDAP. ASA посылает LDAP-запросы на сервер, чтобы получить список пользователей и групп.
ASA—>AD-агент: агент передает на фаирволл списки связок «пользователь-IP адрес» по RADIUS’у
AD-агент—>AD: поскольку у ASAпостоянно должен быть актуальный список доменных пользователей с их адресами, то на AD-агента ложится функция скачивания данного списка с AD-сервера. Агент постоянно мониторит файл аудит-лога на сервере, если в нем происходят изменения, то скачивает его к себе по протоколу WMI и после этого пересылает обновления на ASA.
Посмотрим как настраивается IFW на примере следующей топологии:
— по адресу 10.1.1.100 поднят и настроен сервер AD в домене demo.local
— есть блок клиентских станций, которые принадлежат указанному домену и получают IP-адреса по DHCP
— указанная выше сеть находится в зоне INSIDE для Cisco ASA
— в зоне OUTSIDE есть сервера public1.lab и public2.lab, которые будут использоваться в качестве эмуляции интернета
Итак, первым делом настраиваем связь между ASA и AD по LDAP.
Сначала создаем сервер и указываем, что связь с ним будет по LDAP-протоколу. В этом нам поможет команда aaa—server <NAME> protocol ldap. Далее говорим АSA’ке куда необходимо пересылать все ldap запросы командой aaa—server <NAME> (<INTERFACE>) host <IP_ADDRESS>.
Далее необходимо указать положение в LDAP-иерархии, откуда серверу необходимо начинать поиск пользователя при входящем запросе от сетевого экрана. Делается это командой ldap—base—dn. Если производить поиск надо не только на уровне, который определен командой ldap—base—dn, но и во вложенных уровнях, то необходимо дать команду ldap—scope subtree. После этого командами ldap—login—dn и ldap—login—password указываем данные пользователя, от имени которого ASA будет обращаться к серверу. У этого пользователя должны быть права администратора домена. Если сервер AD поддерживает передачу LDAP поверх SSL, то необходимо ввести команду ldap—over—ssl enable. При необходимости можно задать порт, на который будут высылаться LDAP-запросы. Для этого служит команда server—port <PORT>.
Для нашей лабораторной конфиг выглядит следующим образом:
aaa-server AD_DC protocol ldap
aaa-server AD_DC (INSIDE) host 10.1.1.100
ldap-base-dn DC=demo,DC=local
ldap-scope subtree
server-type microsoft
server-port 389
ldap-login-dn CN=Alexey Gusev,CN=Users,DC=demo,DC=local
ldap-login-password cisco123
После этого было бы неплохо выполнить команду aaa-server authentication AD_DC чтобы проверить правильность настроек. Если все хорошо, то при вводе данных существующего пользователя, Вы увидите сообщение INFO: Authentication Successful. Если же нет, то скорее всего будет нечто следующее: ERROR: Authentication Server not responding: AAA Server has been removed
Для отлова источника проблемы рекомендую использовать команду debug ldap 255
ASA# debug ldap 255
debug ldap enabled at level 255
ASA#test aaa-server authentication AD_DC host 10.1.1.100 username employee1 p$
INFO: Attempting Authentication test to IP address <10.1.1.100> (timeout: 12 seconds)
[100] Session Start
[100] New request Session, context 0xbc2fa288, reqType = Authentication
[100] Fiber started
[100] Creating LDAP context with uri=ldap://10.1.1.100:389
[100] Connect to LDAP server: ldap://10.1.1.100:389, status = Successful
[100] supportedLDAPVersion: value = 3
[100] supportedLDAPVersion: value = 2
[100] Binding as agusev
[100] Performing Simple authentication for agusev to 10.1.1.100
[100] Simple authentication for agusev returned code (49) Invalid credentials
[100] Failed to bind as administrator returned code (-1) Can't contact LDAP server
[100] Fiber exit Tx=176 bytes Rx=566 bytes, status=-2
[100] Session End
ERROR: Authentication Server not responding: AAA Server has been removed
Данное сообщение говорит о том, что неправильно введены данные учетной записи, под которой ASA заходит на LDAP-сервер (в моем случае это учетная запись agusev).
Прим. Я здесь специально изменил ldap—login—dn на CN=agusev для иллюстрации возможной проблемы
Посмотреть как корректно должна писаться запись можно непосредственно на LDAP-сервере. В случае Windows этой командой будет dsquery user -name <USERNAME>
Вторым шагом является установка и настройка AD-агента. Качаем файл AD_Agent—v1.0.0.32-build-539-Installer и устанавливаем на сервер.
Прим. Агент не обязательно должен ставиться на контроллер домена. Главное, чтобы между агентом и контроллером была IP-связность
При установке агент создает свою папку C:\IBF, в которой мы и будем работать. Сначала убедимся, что все работает. Для этого сначала переходим в папку C:\IBF\CLI и даем команду adactrl.exe show running
running C:\\IBF\\watchdog\\radiusServer.bat since 2012- 8-18 T20: 9:15
running C:\\IBF\\watchdog\\adObserver.bat since 2012- 8-18 T20: 9:16
Если что-то из этого не работает, то лучше сразу переустановить агент.
Неплохо бы настроить передача syslog-сообщений с агента. Сделать это можно командой adacfg syslog create –name <SYSLOG_NAME> —ip <SYSLOG_IP> —facility <FACILITY_LEVEL>, где SYSLOG_NAME – локальный идентификатор сервера.
Чтобы агент забирал информацию с AD-сервера, необходимо дать команду adacfg dc create –name <DC_NAME> -host <DC_FQDN_OR_SIMPLE_NAME> -domain <DOMAIN> -user <USERNAME> -password <PASSWORD>, где DC_NAME – локальный идентификатор сервера, а пользователь должен входить в группу, которой позволено считывать security-log файл с контроллера и коннектиться к серверу через WMI.
Далее необходимо настроить AD-агент на связь с Cisco ASA (напомню, они общаются по протоколу RADIUS). Делается это командой adacfg client create –name <CLIENT_NAME> -ip <CLIENT_IP> -secret <RADIUS_KEY>.
В нашем случае команды примут вид
adacfg dc create –name ADAG –host DC –domain demo.local –user Administrator –password 1234QWer
adacfg client create –name ASA –ip 10.1.12.1 –secret cisco
Проверить настройку можно следующими командами
— проверить настройку связи с AD
C:\IBF\CLI>adacfg dc list
Name Host/IP Username Domain-Name Latest Status
---- ------- ------------- ----------- -------------
ADAG DC Administrator DEMO up
Если Вы наблюдаете что-то иное, кроме состояния Up, то скорее всего Вы ошиблись либо при указании логин/пароля либо при написании имени домена. Еще одним источником проблем может быть фаирвол, если AD-агент и AD-сервер располагаются на разных компьютерах. В этом случае, убедитесь, что обеспечивается доступ для WMI, который использует динамический диапазон портов. Если агент и сервер располагаются на одной физической машине, то фаирвол должен пропускать TCP-соединения на порт 8888.
— посмотреть настроенных клиентов можно следующим образом
C:\IBF\CLI>adacfg client list
Name IP/Range
---- ------------
ASA 10.1.12.1/32
Следующим шагом настройки является настройка RADIUS на ASA. Настройка абсолютно типична. За исключением того, что необходимо дополнительно дать команду ad—agent—mode.
aaa-server AD_AGENT protocol radius
ad-agent-mode
aaa-server AD_AGENT (inside) host 10.1.1.100
key cisco
После вышеупомянутой настройки переходим к конфигурированию identity-опций. Первым шагом включаем технологию IFW глобально командой user—identity enable. Нам доступны следующие команды:
— user-identity domain <DOMAIN> aaa-server <AAA_SERVER_NAME>. Здесь <DOMAIN> — NetBios имя домена, настроенного на AD-сервере <AAA_SERVER_NAME>
— user-identity logout-probe netbios local-system probe-time minutes <MINUTES> retry-interval seconds <SECONDS> retry-counts <TIMES>. Включение NetBios-проб (типа NetBios keepalive). Указывает на то, как часто ASA будет высылать тестовые сообщения на IP-адреса пользователей чтобы убедиться, что они все еще в сети. Эти пробы высылаются только после того, как период неактивности (idle time) у пользователя превысит время MINUTES
— user-identity inactive-user-timer minutes <MINUTES>. Если пользователь не активен в течении времени MINUTES, то ASA помечает соответствующий IP-адрес неактивным и удаляет его из своего кэша.
— user-identity action netbios-response-fail remove-user-ip. Если ответ на NetBios-пробу не был получен, то ASA удаляет из памяти связку пользователь-IP
— user-identity ad-agent active-user-database {on-demand|full-download}. Определяет каким способом ASA будет получать списки о связке пользователь-IP от агента. Если настроено full-download, то ASA посылает запрос к агенту для скачивания существующей таблицы целиком (при старте сетевого экрана) и дальнейшего получения частичных обновлений когда пользователь входит или выходит из домена. Если настроено on-demand, то ASA запрашивает обновление от агента в случае получения пакета, IP-адрес источника в котором не находится в БД user-identity.
— user-identity ad-agent aaa-server <AAA_SERVER>. Указывает фаирволлу на то, что AAA-сервер является AD-агентом.
user-identity ad-agent aaa-server AD_AGENT
user-identity domain DEMO aaa-server AD_DC
user-identity logout-probe netbios local-system probe-time minutes 30 retry-interval seconds 15 retry-counts 3
user-identity ad-agent active-user-database full-download
Следующим (и последним) шагом является написание правил доступа.
object-group user AD_CONTRACTORS
user-group DEMO\\GR_Contractors
user DEMO\agusev
access-list ACL_INSIDE extended permit ip user-group DEMO\\GR_Lobby any host public.lab
access-list ACL_INSIDE extended permit tcp user-group DEMO\\GR_Employees any any eq telnet
access-list ACL_INSIDE extended permit ip user DEMO\contractor1 any host public2.lab
access-list ACL_INSIDE extended permit ip object-group-user AD_Contractors any any
С ASA можно посмотреть различную информацию из AD:
— какие группы созданы (частичный вывод)
ASA# show user-identity ad-groups DEMO
Domain:DEMO AAA Server Group: AD_DC
Group list retrieved successfully
Number of Active Directory Groups: 40
dn: CN=Administrators,CN=Builtin,DC=demo,DC=local
sAMAccountName: Administrators
dn: CN=Users,CN=Builtin,DC=demo,DC=local
sAMAccountName: Users
dn: CN=GR_Employees,CN=Users,DC=demo,DC=local
sAMAccountName: GR_Employees
dn: CN=GR_Lobby,CN=Users,DC=demo,DC=local
sAMAccountName: GR_Lobby
dn: CN=GR_Contractors,CN=Users,DC=demo,DC=local
sAMAccountName: GR_Contractors
— какой IP-адрес у пользователя
ASA# show user-identity ip-of-user DEMO\employee1
DEMO\10.1.2.100 (Login)
Если хотите отслеживать добавление новых пользователей непосредственно на ASA, можно дать команду debug user-identity user. В этом случае, когда новый пользователь входит в сеть, Вы увидите примерно следующее сообщение
idfw_adagent[0]: IP-User mapping 10.1.2.100<->DEMO\contractor1 added
Иногда можно встретить примерно следующую проблему: ASA получает список всех групп и пользователей в Active Directory, но связку имени пользователя с IP-адресом нет. В этом случае, скорее всего, есть проблема с AD-агентом. Посмотреть в каком состоянии находится связь между агентом и ASA можно командой
ASA# show user-identity ad-agent
Primary AD Agent:
Status up (registered)
Mode: full-download
IP address: 10.1.1.100
Authentication port: udp/1645
Accounting port: udp/1646
ASA listening port: udp/3799
Interface: INSIDE
Up time: 8 mins 1 sec
Average RTT: 12 msec
AD Domain Status:
Domain DEMO: up
Если вместо этого выдается следующее
ASA#show user-identity ad-agent statistics
ERROR: AD-Agent not configured
То не дана команда user-identity ad-agent aaa-server AD_AGENT
Метки: ASA, firewall, identity
Опубликовано: Безопасность cisco
Хорошая статья, очень полезная!Спасибо,Леш!
>>указываем данные пользователя, от имени которого ASA будет обращаться к серверу. У этого пользователя должны быть права администратора домена.
А зачем нужны права администратора? Ведь ничего правиться в АД не будет, нужно ведь только читать из АД. Для этого должно быть достаточно обыкновенного пользователя, у которого есть права на чтение из АД.
Мне тоже не понятно. Просто для ЛДАПа достаточно любого юзера (с правами на чтение)
У меня в памяти очень сильно отложилось, что где-то на cisco.com я сие вычитывал. Сейчас не могу ни подтверждения, ни опровержения.
Завтра проверю этот «факт» в деплойменте
Интересный функционал, однако интересует один момент.
> Агент постоянно мониторит файл аудит-лога на сервере, если в нем происходят изменения, то скачивает его к себе по протоколу WMI и после этого пересылает обновления на ASA.
Представим что у пользовательского компьютера изменился IP, но процедуры login/logout в домен не было (при этом доменные ресурсы типа MS Exchange или файл-сервер продолжают использоваться). Клиент это отследит и автоматически обновит информацию об ассоциации user-IP на ASA или нет?
Спасибо.
Ещё вы немного забыли упомянуть с какой версии IOS доступна эта фича
подскажите пожалуйста что не так.
все настроил нормально, только с пользователями беда, 6 из 40 только актив. остальные не активны. делаю перелогон, пользователь активен буквально через полчаса уже нет.
Доброго времени суток, а вот такой вопрос. Где можно задать время проверки обновления членства пользователей в группах через LDAP или такого в принципе не предусмотрено. И если пользователь исключен или добавлен в группу, то руками нужна на ASA правила «передергивать»? Спасибо.
P.S. Версия 9.1
Данный функционал Циско поддерживает без локализации, иными словами на «русском» Windows Server ничего работать не будет.
Имеется в виду с русской локализацией сервера с ролью контроллера домена.
Добрый день.
Кто сможет, прошу подсказать.
Поднял данную фичу в сети (CDA + ASA 9.1.2).
Теперь проблема — когда два и более пользователя логинятся на терминальном сервере, то ASA «видит» только того, кто залогинился последним. Все предыдущие помечаются как inactive, хотя они качают трафик.
Это логично, поскольку все пользователи терминала будут иметь один IP
походу эта хрень не доделанная, на клиентах с вин 7 не работает.
асе пофиг какая версия винды стоит на конечной машине, она работает только с IP-адресами, которые подсосались из логов АД
Такая же беда: через 5-10 минут после логина пользователь помечается как inactive, и запрещенный трафик становиться доступен.
Внедрил данную схему — работает отлично более 2-х лет.
…пользователь помечается как inactive…
Интервал сессии устанавливается в самом AD — по памяти точно не скажу, нужно будет — найду.
У меня сейчас выставлен где-то около часа — если пользователь бездействует , но браузер открыт — то при попытке войти через час — болт. Нужно делать завершение сеанса — чтобы переустановить сессию.
Мало того на базе всего этого хозяйства — по настоянию руководства был развернут Cisco WSA — s100V — прокси сервер от CISCO.
Ну просто отлично работает — по сути ASA отправляет запросы для HTTP, HTTPS на проксю а затем уже выплевывает в инет.
Здравствуйте. Сервер с AD у вас с русской локализацией?
jeekey:
нет конечно же
немнго не в тему — но все таки, внедрили еще ESA — также работает на ура )
тут проявилось — что максимально пользователь может зайти с 15 разных компов (на 16 не дает выйти в инет). Можно увеличить как-то и где это установлено?