antiCisco blogs


блоги по технологиям и оборудованию cisco от инструкторов

Опубликовано 19 Август , 2012

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-протоколу. В этом нам поможет команда aaaserver <NAME> protocol ldap. Далее говорим АSA’ке куда необходимо пересылать все ldap запросы командой aaaserver <NAME> (<INTERFACE>) host <IP_ADDRESS>.

Далее необходимо указать положение в LDAP-иерархии, откуда серверу необходимо начинать поиск пользователя при входящем запросе от сетевого экрана. Делается это командой ldapbasedn. Если производить поиск надо не только на уровне, который определен командой ldapbasedn, но и во вложенных уровнях, то необходимо дать команду ldapscope subtree. После этого командами ldaplogindn и ldaploginpassword указываем данные пользователя, от имени которого ASA будет обращаться к серверу. У этого пользователя должны быть права администратора домена. Если сервер AD поддерживает передачу LDAP поверх SSL, то необходимо ввести команду ldapoverssl enable. При необходимости можно задать порт, на который будут высылаться LDAP-запросы. Для этого служит команда serverport <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).

 

Прим. Я здесь специально изменил ldaplogindn на CN=agusev для иллюстрации возможной проблемы

 

Посмотреть как корректно должна писаться запись можно непосредственно на LDAP-сервере. В случае Windows этой командой будет dsquery user -name <USERNAME>

Вторым шагом является установка и настройка AD-агента. Качаем файл AD_Agentv1.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 createname <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. Настройка абсолютно типична. За исключением того, что необходимо дополнительно дать команду adagentmode.

aaa-server AD_AGENT protocol radius
 ad-agent-mode
aaa-server AD_AGENT (inside) host 10.1.1.100
 key cisco

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

 

Метки: , ,
Опубликовано: Безопасность cisco

 

19 комментариев “ASA Identity Firewall”

comment rss - Trackback

  1. Aleks305:

    Хорошая статья, очень полезная!Спасибо,Леш!

  2. m0ps:

    >>указываем данные пользователя, от имени которого ASA будет обращаться к серверу. У этого пользователя должны быть права администратора домена.

    А зачем нужны права администратора? Ведь ничего правиться в АД не будет, нужно ведь только читать из АД. Для этого должно быть достаточно обыкновенного пользователя, у которого есть права на чтение из АД.

  3. pdz:

    Интересный функционал, однако интересует один момент.

    > Агент постоянно мониторит файл аудит-лога на сервере, если в нем происходят изменения, то скачивает его к себе по протоколу WMI и после этого пересылает обновления на ASA.

    Представим что у пользовательского компьютера изменился IP, но процедуры login/logout в домен не было (при этом доменные ресурсы типа MS Exchange или файл-сервер продолжают использоваться). Клиент это отследит и автоматически обновит информацию об ассоциации user-IP на ASA или нет?

    Спасибо.

  4. paralon:

    Ещё вы немного забыли упомянуть с какой версии IOS доступна эта фича

  5. dima:

    подскажите пожалуйста что не так.
    все настроил нормально, только с пользователями беда, 6 из 40 только актив. остальные не активны. делаю перелогон, пользователь активен буквально через полчаса уже нет.

  6. rastler:

    Доброго времени суток, а вот такой вопрос. Где можно задать время проверки обновления членства пользователей в группах через LDAP или такого в принципе не предусмотрено. И если пользователь исключен или добавлен в группу, то руками нужна на ASA правила «передергивать»? Спасибо.

    P.S. Версия 9.1

  7. vlp:

    Данный функционал Циско поддерживает без локализации, иными словами на «русском» Windows Server ничего работать не будет.

  8. kazaros:

    Добрый день.
    Кто сможет, прошу подсказать.
    Поднял данную фичу в сети (CDA + ASA 9.1.2).
    Теперь проблема — когда два и более пользователя логинятся на терминальном сервере, то ASA «видит» только того, кто залогинился последним. Все предыдущие помечаются как inactive, хотя они качают трафик.

  9. dima:

    походу эта хрень не доделанная, на клиентах с вин 7 не работает.

  10. kazaros:

    Такая же беда: через 5-10 минут после логина пользователь помечается как inactive, и запрещенный трафик становиться доступен.

  11. remvord:

    Внедрил данную схему — работает отлично более 2-х лет.
    …пользователь помечается как inactive…
    Интервал сессии устанавливается в самом AD — по памяти точно не скажу, нужно будет — найду.
    У меня сейчас выставлен где-то около часа — если пользователь бездействует , но браузер открыт — то при попытке войти через час — болт. Нужно делать завершение сеанса — чтобы переустановить сессию.
    Мало того на базе всего этого хозяйства — по настоянию руководства был развернут Cisco WSA — s100V — прокси сервер от CISCO.
    Ну просто отлично работает — по сути ASA отправляет запросы для HTTP, HTTPS на проксю а затем уже выплевывает в инет.

  12. remvord:

    немнго не в тему — но все таки, внедрили еще ESA — также работает на ура )

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

Вы должны войти чтобы прокомментировать.