Привет habr! Начиная с версии FirePOWER 6.0.0.0, появилась возможность интеграции с корпоративным сервером централизованной аутентификации и авторизации Cisco ISE. В данной заметке кратко рассмотрим, что именно даёт связь Cisco FirePOWER с ISE и как эта связь настраивается.


Что такое Cisco ISE
Достаточно подробно написано на habrahabr в корпоративном блоге Cisco.
Также есть серьёзная статья от инженера Cisco, описывающая сценарии использования Cisco ISE и архитектуру TrustSec.

Интеграция FirePOWER c ISE даёт в первую очередь новый способ получения идентификационных данных пользователей. До версии FirePOWER 6.0.0.0 аутентификация пользователей происходила в пассивном режиме. Это означает, что где-то в сети на компьютере, входящем в домен, или непосредственно на сервере Active Directory (AD) должен быть установлен агент. Данный агент должен мониторить логи AD на предмет событий login/logoff пользователей и передавать соответствия IP-адреса и учётной записи пользователя на FirePOWER. Последняя реинкарнация данного агента от SourceFIRE получила название Cisco FirePOWER User Agent.

Агенты пассивной аутентификации
В наследство от SourceFIRE компания Cisco получила агент SourceFIRE User Agent, способный интегрироваться с системой управления Defence Center (FireSIGHT). К слову сказать, сейчас актуальное название системы управления FirePOWER выглядит так: FirePOWER Management Center (сокращённо FMC). А агент именуется Cisco FirePOWER User Agent.

До этого у Cisco были собственные варианты агентов: Cisco Active Directory Agent (AD Agent), управляемый из командной строки, и более позднее решение с графическим интерфейсом — Context Directory Agent (CDA). Данные решения можно было использовать для получения функциональности Identity FireWall на устройстве Cisco ASA. Т.е. на Cisco ASA появлялась возможность создавать списки доступа не по IP-адресам, а по учётным записям из AD. Также CDA можно было использовать с решением Cisco ASA CX (данное решение уже более не продаётся в пользу ASA+FirePOWER), с WEB-proxy сервером Cisco WSA и с сервером аутентификации и авторизации Cisco ISE.

Преимущество использования агента для аутентификации пользователей – полная прозрачность процесса аутентификации. Другими словами, User Experience для конечного пользователя абсолютно никак не меняется при внедрении аутентификации на сетевом шлюзе. Однако, у данного метода ряд недостатков. Очевидный минус заключается в самом подходе: нужно устанавливать дополнительное ПО, которое должно круглосуточно мониторить логи AD. Если по какой-то причине логи AD будут недоступны, пользователь не будет авторизован на сетевом устройстве. Также может проявиться проблема с неверным предоставлением прав доступа. Например, если на момент входа пользователя в систему ПК был отключен от сети, в теории, новый пользователь сможет получить права доступа предыдущего пользователя ПК, если через какое-то время подключит ПК обратно к сети.

Другой подход – активная аутентификация, при которой установка агента не требуется, но пользователи должны самостоятельно вводить учётные данные по запросу. Недостаток этого метода очевиден.

Активная аутентификация на FirePOWER также была представлена с выходом версии 6.0.0.0.

Использование Cisco ISE для идентификации пользователей на FirePOWER решает проблемы, присущие как пассивной аутентификации с агентом, так и активной аутентификации. Как следует из определения, Cisco ISE является централизованной системой аутентификации и авторизации пользователей при подключении в сеть. Как только пользователь успешно проходит процедуры аутентификации и авторизации и получает доступ в сеть, на Cisco ISE появляется полная информация об этом пользователе, включающая IP-адрес пользователя и его учётную запись. Далее эту информацию достаточно передать на FirePOWER, а точнее на систему управления FirePOWER Management Center. Cистема получит возможность сопоставить IP-адрес сетевой транзакции с учётной записью пользователя и применить настроенные политики доступа.

Но функциональность Cisco ISE не ограничивается аутентификацией и авторизацией пользователей в сети. Cisco ISE позволяет профилировать пользовательские устройства, т.е. определять, какое устройство подключено к определённому порту определённого коммутатора. К информации об устройстве относятся: производитель, версия ОС, тип устройства (мобильное/стационарное) и т.д. Данная информация также может быть передана на FirePOWER. Это даёт возможность настраивать разные правила доступа для разных типов устройств. Например, для Android и iOS более специфичные ограничения, чем для Microsoft Workstation. Пример настройки правила с учётом типа устройства представлен ниже:



Помимо профилирования устройств Cisco ISE позволяет реализовать архитектуру Cisco TrustSec. Очень кратко, Cisco TrustSec позволяет разграничивать доступ в сети по меткам, называемым Security Group Tags (SGT). Метка представляет собой произвольное число от 1 до 65535 передаётся в рамках Ethernet-кадра. Соответственно, устройства, через которые проходят кадры с метками SGT, должны поддерживать архитектуру TrustSec. В противном случае, информация о метке для сетевой транзакции может передаваться посредством протокола Security Group Tag Exchange Protocol (SXP). При успешном прохождении процедур аутентификации и авторизации пользователю присваивается метка, определяющая его доступ к ресурсам сети. Описание, присвоение метки SGT, а также настройка правил доступа по меткам (SGT ACL) осуществляется при помощи Cisco ISE. Начиная с версии FirePOWER 6.0.0.0 появилась возможность использовать метки SGT в политиках доступа на FirePOWER. Пример настройки правила с учётом метки SGT представлен ниже:



Последний атрибут ISE, который может быть использован в политиках доступа FirePOWER версии 6.0.0.0, – Location IP. Данный атрибут означает IP-адрес сетевого устройства, которое аутентифицировало пользователя через Cisco ISE. Следовательно, можно создавать различные правила доступа для одного и того же пользователя, в зависимости от того, к какому сетевому устройству он подключен (коммутатор или точка доступа WiFi, или, например, коммутатор в головном офисе или коммутатор в удалённом филиале, или, например, подключение пользователя удалённо через AnyConnect).

Прежде чем переходить к настройке связи FirePOWER c Cisco ISE подведём итог. При интеграции FirePOWER и Cisco ISE получаем следующие преимущества:
  1. Отпадает необходимость использования агента Cisco FirePOWER User Agent для аутентификации пользователей. Также отпадает необходимость в активной аутентификации. Все задачи аутентификации и авторизации пользователей в сети берёт на себя Cisco ISE.
  2. Более точная идентификация пользователей на FirePOWER по сравнению с использованием агента Cisco FirePOWER User Agent.
  3. Использование атрибутов Cisco ISE, а именно:
    • Появляется возможность использовать результаты профилирования Cisco ISE в правилах доступа FirePOWER.
    • Появляется возможность использовать метки TrustSec (SGT) в правилах доступа FirePOWER.
    • Появляется возможность использования IP-адреса авторизующего устройства в правилах доступа FirePOWER.


Настройка связи FirePOWER с Cisco ISE

Настройка приводится для FirePOWER Management Center версии 6.0.1 и Cisco ISE версии 2.0.0.306. Как говорилось ранее, Cisco ISE хранит подробную информацию об авторизованных в сети пользователях. Основная задача – передать необходимую информацию на FirePOWER.

Традиционно, когда одна система должна коммуницировать с другой системой, используют кастомные или проприетарные API (Application Programing Interface). Cisco предлагает собственную технологию, посредством которой осуществляется взаимодействие различных продуктов Cisco, а также связь решений Cisco с системами других вендоров. Технология именуется Cisco Platform Exchange Grid (pxGrid). Данная технология предлагает общий язык взаимодействия для обмена информации между различными системами, например, FirePOWER, ISE, WSA, Cyber Threat Defense (CTD) и т.д.

Центральным компонентов pxGrid является Cisco ISE. Другие внешние системы выступают в роли клиентов или агентов в рамках pxGrid и подписываются на Cisco ISE для получения или передачи информации. Когда внешние системы подключаются к pxGrid, регистрируясь на Cisco ISE, они получают возможность обмениваться информацией по схеме «каждый с каждым», используя для этого единые методы. Регистрация внешних систем на Cisco ISE в pxGrid осуществляется посредством цифровых сертификатов. Для возможности использования pxGrid на Cisco ISE требуется наличие лицензии PLUS.

Перейдём к настройкам. Сперва Cisco ISE.

1. Активировать pxGrid Persona на Cisco ISE.

Вкладка Administration -> System -> Deployment.



Выбрать сервер ISE. Кликнуть по его названию. Установить галку напротив pxGrid:



Нажать Save.

2. Получить цифровой сертификат для pxGrid. Сервис pxGrid требует расширенные возможности использования цифрового ключа, а именно, аутентификация как сервера, так и клиента. Поэтому сертификат, используемый для стандартных задач ISE (EAP Authentication, Admin portals, User Portals) не подходит для pxGrid. Необходимо сгенерировать и подписать на корпоративном удостоверяющем центре (далее корпоративный CA) сертификат для pxGrid. Для этого нужно зайти на вкладку Administration -> System -> Certificates и в меню слева выбрать Certificate Signing Requests:



Нажать Generate Certificate Signing Request (CSR) и заполнить необходимые поля. Пример на изображении ниже:



Нажимам Generate и экспортируем полученный CSR. Теперь идём на корпоративный CA и подписываем по CSR сертификат. На данном моменте подробно останавливаться не буду, просто вставлю скриншоты:









Подписанный сертификат получен. Возвращаемся на ISE, привязываем сертификат к CSR:





Теперь на ISE есть необходимый сертификат для pxGrid:



3. Проверить подключенные по pxGrid клиенты можно на вкладке Administration -> pxGrid Services. Здесь же установим настройку «Enable Auto Registration»:



ISE настроен. Теперь перейдём к настройкам pxGrid на FirePOWER.

4. Необходимо перейти на вкладку System -> Integration -> Identity Sources и выбрать Identity Services Engine в качестве источника идентификационной информации:



5. Заполнить обязательные поля. Необходимо указать IP-адрес или имя сервера ISE:



6. Указать сертификаты «pxGrid Server CA» и «MNT Server CA». В качестве этих сертификатов можно использовать корневой сертификат корпоративного CA:



7. Указать сертификат и ключ «FMC Server Certificate». Данный сертификат FirePOWER Management Center будет предъявлять Cisco ISE при попытке подключения к pxGrid. Чтобы получить этот сертификат, нужно на FirePOWER сгенерировать CSR, подписать его на корпоративном CA и загрузить полученный подписанный сертификат на FirePOWER. Для этого нужно сгенерировать пару ключей и CSR из командной строки FMC, используя утилиту openssl:



Я использовал следующую строку параметров для создания CSR и Private Key:

req -batch -new -newkey rsa:2048 -nodes -keyout fp.key -subj '/C=RU/ST=Moscow/L=Moscow/O=CBS/OU=Computers/emailAddress=uskov@cbs.ru/CN=fmc/CN=cbs/CN=com/CN=ru' -out fp.csr

Далее по CSR нужно подписать сертификат на корпоративном CA. Процедура абсолютно аналогична процессу получения сертификата pxGrid для ISE. Подписанный сертификат импортируем на FirePOWER Management Center. Вкладка Objects -> Object Management меню PKI -> Internal Certs:



Нажимаем Add Internal Cert, выбираем подписанный сертификат и Private Key:



Сертификат и ключ «FMC Server Certificate» готов. Возвращаемся на вкладку System -> Integration -> Identity Sources и выбрать Identity Services Engine. Указываем «FMC Server Certificate»:



8. В этом же меню нажимаем Test. Должно появиться окно «Success»:



9. Не забыть нажать Save в верхнем правом углу:



10. Вернёмся к ISE, проверим вкладку Administration -> pxGrid Services. Видим, появились новые клиенты pxGrid:



Проверим работоспособность настроенного решения. Cisco ISE настроен на аутентификацию тестового сегмента проводной сети. Настройки политик Cisco ISE в рамках данной заметки рассматривать не будем. Подключимся с помощью ноутбука к проводной сети, в качестве сапликанта используем Cisco AnyConnect Network Access Manager (NAM):



В логах ISE проверим Radius Livelog (вкладка Operations -> RADIUS Livelog):



Аутентификация прошла успешно. Теперь проверим User Activity на FirePOWER (вкладка Analysis -> Users -> User Activity):



Если промотать вывод User Activity правее, то можно увидеть, что FirePOWER Management Center получил от ISE дополнительные атрибуты: Security Group Tag, Endpoint Profile и Endpoint Location:



На этом описание настройки интеграции ISE и FirePOWER я завершаю. Надеюсь, приведённый материал будет полезен читателям.

Если данная тема заинтересует, добро пожаловать к нам на демостенды по Cisco ISE, Cisco FirePOWER.
Поделиться с друзьями
-->

Комментарии (28)


  1. Matvey-Kuk
    29.06.2016 11:29

    Когда дизайнер рисует зубчатое зацепление. Брррр


    1. Boris_Uskov
      29.06.2016 11:56

      На вкус и цвет…


      1. Matvey-Kuk
        29.06.2016 12:08
        +1

        Только не в деталях машин.


  1. paralon
    29.06.2016 11:29

    Борис, добрый день.
    Спасибо за статью.
    Правильно ли я понял, что в данном раскладе мы опять таки возвращаемся к активной аутентификации? То есть каждому пользователю с каждого его устройства нужно вводить логин\пароль через Cisco AnyConnect.
    И что произойдёт если мы изменили политику доступа? Нужно ли будет пользователю «перелогиниться» чтобы политики применились к нему?


    1. Boris_Uskov
      29.06.2016 11:55
      +2

      Роман, да, мы получаем активную аутентификацию. При этом Anyconnect Network Access Module (NAM) можно настроить для Single Sign On, пользователю не придётся вводить учётные данные.
      Кстати, использование Anyconnect для 802.1X аутентификации не обязательно. Например, Windows имеет встроенный сапликант. Нужно включить сервис «Проводная автонастройка», и тогда в настройках сетевого адаптера появится вкладка «Проверка подлинности»:

      Windows по умолчанию будет предлагать учётные данные, под которыми пользователь вошёл в систему.

      Таким образом, аутентификация, хоть и активная, но проходит прозрачно для конечных пользователей.

      Если мы изменим политику доступа на FirePOWER, перелогиниться на нужно. Просто новая политика станет применяться к тем же пользователям.


      1. paralon
        29.06.2016 12:21

        Про «проводную автонастройку» не знал, спасибо!

        В данном стенде, получает, вовсю используется trustsec? Иначе не понятно где конкретно мы проходим аутентификацию


        1. Boris_Uskov
          29.06.2016 12:32
          +2

          Для этой статьи trustsec метку (SGT) я использую только чтобы показать, что в консоли FirePOWER (FMC) появится соответствющий атрибут. То есть, что ISE передаёт на FirePOWER метку. Аутентификация происходит на ISE в не зависимости от использования trustsec.

          Механизм таков: Коммутатор не пускает на своём порту никакой трафик от клиента, кроме трафика 802.1X, пока ISE не сообщит коммутатору с помощью протокола RADIUS, что аутентификация прошла успешно, и что пользователь авторизован к некоторым ресурсам. В результате авторизации могут происходить разные события: присвоение метки Trustsec, присвоение ACL на порт коммутатора, изменение VLAN на порту коммутатора и т.д. Основная идея в том, что как только аутентификация и авторизация прошли, на ISE появилось соответствие IP-адрес и учётной записи пользователя, и эту информацию можно передать далее на FirePOWER (в рамках pxGrid). И теперь, когда трафик авторизованного пользователя дойдёт до FirePOWER-сенсора, FirePOWER сможет понять от какого именно пользователя трафик пришёл, и сможет применить политики (например, запретить доступ в соц. сети для пользователя «Иванов»).


          1. paralon
            29.06.2016 12:41

            Да, теперь понятно, сначала это обычный 802.1x и в качестве radius-клиента у нас коммутатор\wlc.
            Тогда такой практический вопрос. Понятно что для тех же linux worksation или Mac-OS мы можем использовать Cisco AnyConnect. Но как быть в случае если у нас нет GUI? То есть нужно что-то вроде консольного супликанта.


            1. Boris_Uskov
              29.06.2016 12:47

              Ну да, видимо нужны консольные сапликанты…
              ISE ещё умеет аутентифицировать по MAC-адресу — MAC Authentication Bypass (MAB). Это подойдёт для принтеров, камер видеонаблюдения и т.д.

              Если вернуться к FirePOWER, тут уже такой момент. Коль нет GUI, вероятно и гранулярный контроль Web-приложений на FirePOWER для таких устройств не нужен. Достаточно разрешить доступ к определённым ресурсам (хоть по IP-адресам).


              1. paralon
                29.06.2016 13:17

                Да вот в том то и дело, что нужен контроль… Сервера, хоть и не имеют GUI, обращаются к огромному количеству веб-ресурсов (git, maven, репозитории, etc) к которым доступ по IP предоставить сложно, ввиду огромного количества оных и тут нужна фильтрация именно по URL-ам.
                Сейчас это делается либо открытием доступа по src IP, либо с помощью костылей типа «искуственных» AD Query и опять же выдёргиванием привязки юзер\IP из AD Security логов.
                А хотелось бы чего-то более интеллектуального…


      1. dubidrubi
        29.06.2016 16:18
        +1

        Жаль только, что нативный сапликант не поддерживает EAP Chaining…


  1. Night_Snake
    30.06.2016 10:31

    Учитывая, что ISE уже может выполнять функции фаервола (точнее, хранит SGACL/DACL и разливает их на железки), то зачем еще FirePOWER? Как нечто более продвинутое? Или как средства контроля периметра?


    1. Boris_Uskov
      30.06.2016 10:39
      +1

      FirePOWER — и как более продвинутый фаервол, и как контроль периметра. SGACL/DACL — контроль только по IP-адресам и меткам. FirePOWER даёт распознавание приложений (например, facebook можно разбить на facebook games, facebook comment, facebook like, facebook message и т.д.) URL-фильтрация по категориям и репутациям. Плюс FirePOWER предлагает NG IPS и AMP (AMP — это своего рода антивирусная проверка проходящих через сенсор файлов).


      1. Night_Snake
        30.06.2016 10:40

        а насчет фейсбука можно поподробнее? ;) Если на комп пользователя ничего не ставится, то как вы собираетесь распознавать, какой ssl-трафик относится к играм, а какой к лайкам?


        1. Boris_Uskov
          30.06.2016 10:45

          Ну FirePOWER умеет дешифровать ssl. Как обычно, с подменой сертификата. А далее, в прошивке FirePOWER зашиты сигнатуры различный приложений. По этим сигнатурам FirePOWER хитро распознаёт, трафик какого приложения проходит через сенсор. Соответственно, политиками можно блокировать тот или иной трафик.


          1. Night_Snake
            30.06.2016 10:47

            С подменой сертификата сможет, простите «каждый дурак». При этом пользователь получает security exception, а в отдельных случаях — просто невозможность работы с ресурсом. некомильфо, в общем.


            1. ksg222
              30.06.2016 10:55

              А есть другие варианты?


              1. Night_Snake
                30.06.2016 10:56

                Официально нет.
                Но зачем продвигать заведомо кривое решение?


            1. Boris_Uskov
              30.06.2016 11:06

              FirePOWER — корпоративный фаервол, сертификат подменяется корпоративным сертификатом. При этом сертификат ресурса также остаётся. Поэтому security exception не появляется, и проблем с доступом к ресурсам в 99% случаев не возникает.


              1. Night_Snake
                30.06.2016 11:09

                Это я знаю.
                Но сложности с тем же гуглом и прочим hsts остаются.


                1. Boris_Uskov
                  30.06.2016 11:18

                  Не сталкивались. Не расскажете поподробнее?


                  1. Night_Snake
                    30.06.2016 11:24

                    В Chrome, например, зашиты цифровые подписи их сертификатов. В случае попытки подмены сертификата цифровая подпись меняется (не смотря на то, что сертификат является доверенным) — получаем security exception. В FF нечто подобное тоже есть, на сколько я знаю.
                    Алсо, pinning так же сводит все усилия по подмене сертификатов на нет.


                    1. navion
                      03.07.2016 17:19

                      И это всё отключается при подмене сертификатом доверенного CA.


              1. Pave1
                30.06.2016 11:37

                Подождите))) Любой нормальный браузер помимо подлинности самого сертификата сверяет url с атрибутами этого сертификата. И если при заходе на google.com аналогичного атрибуда в сертификате не найдет — будет ругаться. Что с этим делать?


                1. Boris_Uskov
                  30.06.2016 11:44
                  +1

                  Корпоративный сертификат «вклинивается» перед сертификатом конечного ресурса. Сертификат конечного ресурса также остаётся со всеми его атрибутами, поэтому по этой причине браузер ругаться не будет.


                  1. Pave1
                    30.06.2016 12:53

                    А можно где то подробно прочитать про механизм? А то не совсем понятно. Выходит браузер знает, что его ломают, но молчит))) Спасибо.


                    1. Boris_Uskov
                      30.06.2016 12:59

                      Поподробнее можно почитать прямо в User Guide по FirePOWER. Ссылочку сделал именно на раздел дешифрации.


            1. m0ps
              30.06.2016 11:19
              +1

              Если у вас есть свой CA, то можно сделать так, что FirePower будет генерить сертификаты для «интересных» сайтов, которым будут доверять ваши браузеры (т.к. CA-сертификат будет разложен по клиентам). Правда SSL работает крайне нестабильно. Тестировали декриптование входящего SSL трафика по известным сертификатам (своих публичных ресурсов, что бы определять атаки, которые идут через SSL) на всех версиях кроме последней (6.0.1.1) — куча проблем, пришлось отказаться.