Привет habr! В данной статье хотел поделиться опытом внедрения сервисов FirePOWER на межсетевом экране Cisco ASA. О том, что такое FirePOWER, SourceFIRE и т.д. уже достаточно много написано на хабре в блоге компании cisco тут и тут. В данной статье попробую в первую очередь описать процесс начальной инициализации решения с практической точки зрения, рассказать про нюансы и проблемы, с которыми приходилось столкнуться.

Описание шагов начальной инициализации компонентов системы, приводимое в данной статье, опирается на документ FirePOWER Services for ASA POV Best Practices.

Статью разобью на две части. В первой части я опишу моменты, на которые, на мой взгляд, стоит обратить особое внимание на этапах планирования и внедрения решения. Первый момент – особенности лицензирования FirePOWER на Cisco ASA, второй момент – особенности аутентификации пользователей и интеграции системы с Microsoft Active Directory. Во второй части пробегусь по всем шагам внедрения, выделяя по возможности более мелкие нюансы.

Сразу сделаю небольшое замечание. На момент внедрения FirePOWER на Cisco ASA, описываемое в данной статье, сервисы FirePOWER на ASA5515 настраивались только с помощью отдельно стоящей системы управления Defence Center (FireSIGHT). Наиболее предпочтительным вариантом являлась виртуальная машина Defence Center. Именно этот вариант описывается в статье. Однако, почти перед самым моментом публикации статьи вышла новая версия FirePOWER 6.0.0.0. Судя по Release Notes, в новой версии FirePOWER управление может осуществляться с помощью графического интерфейса ASA — ASDM, т.е., использование отдельно стоящей системы управления не является обязательным условием.

Особенности лицензирования FirePOWER на Cisco ASA

Так как периодически возникает путаница с лицензиями, попробую внести ясность.

Все лицензии устанавливаются с помощью FireSIGHT. Для внедрения сервисов FirePOWER на Cisco ASA требуется следующий набор лицензий:

1. Лицензия FireSIGHT;
2. Лицензия PROTECT+CONTROL;
3. Лицензии-подписки (Protection, URL Filtering, Malware);

Теперь остановимся более подробно на каждом типе лицензий.

Лицензия FireSIGHT

Данная лицензия обеспечивает возможность обнаружения устройств и пользователей в сети (политики Discovery). Лицензия не имеет ограничений на срок действия. Пример партномера лицензии FireSIGHT для управления не более двух Cisco ASA с модулем FirePOWER:

FS-VMW-2-SW-K9=
Cisco FireSIGHT Management Center,(VMWare) for 2 devices

В интерфейсе FireSIGHT во вкладке System -> Licenses данная лицензия откроет следующие позиции:



Количество 50 000 – это максимально возможное количество обнаруживаемых устройств и пользователей, поддерживаемое конкретной моделью Defence Center (FireSIGHT). Для виртуального FireSIGHT именно такое ограничение – 50 тысяч.

Кстати сказать, мы нигде в FireSIGHT не заметили, где указывается ограничение на количество подключаемых управляемых устройств (FirePOWER-модулей)…

Лицензия PROTECT+CONTROL

Данная лицензия открывает функционал:

• PROTECT: IPS, контроль файлов (обнаружение типов файлов, возможность блокировки скачивания/выгрузки файлов по типам), Security Intelligence (обнаружение/блокировка Bot-сетей, Open Proxy, Spam-распространителей, TOR и т.д.). Тут нужно оговориться. Для полноценной работы IPS помимо лицензии PROTECT требуется лицензия-подписка для доступа к облаку Cisco, откуда будут подкачиваться обновления сигнатур IPS. Лицензии-подписки будут рассмотрены далее.
• CONTROL: Распознавание и контроль приложений, управление доступом для пользователей.

Лицензия не имеет ограничений на срок действия.

Пример партномера лицензии PROTECT+CONTROL для ASA5515:

ASA5515-CTRL-LIC=
Cisco ASA5515 Control License

На FireSIGHT во вкладке System -> Licenses данная лицензия откроет следующие позиции:



Нюанс лицензии PROTECT+CONTROL. Хочу обратить особое внимание, данный партномер имеет нулевую стоимость. Рекомендую очень внимательно отслеживать спецификации на момент заказа, чтобы данный партномер нигде не потерялся. В моём случае произошло именно так. PAK для лицензии ASA5515-CTRL-LIC не поступил. Пришлось написать письмо на licensing@cisco.com с просьбой сгенерировать для меня недостающую лицензию. Надо отдать должное Cisco TAC, недостающую лицензию выслали в течение шести часов, не задавая никаких лишних вопросов.

Лицензии-подписки (Protection, URL Filtering, Malware)

Данные лицензия открывают функционал:

• Protection. Подписка на обновления сигнатур IPS;
• URL Filtering. Подписка на обновления категорий и репутаций URL;
• Malware. Подписка на функционал AMP – проверка файлов на наличие вредоносного кода на основе анализа репутаций файлов, проходящих через устройство (репутация запрашивается для значения хеш функции, применённой к файлу).

Лицензии-подписки могут быть сроком на 1 год и на 3 года. Для новых моделей ASA (5506, 5508, 5516) доступны подписки сроком на 5 лет.

Нюанс лицензий-подписок. Очень важный момент. Лицензии-подписки начинают действовать с момента заказа, а не с момента установки на устройство. Таким образом, если работы по внедрению системы начались спустя 3 месяца с момента заказа лицензий, то эти 3 месяца действия лицензии будут безвозвратно утрачены.

Update
Лицензии-подписки FirePOWER начинают действовать спустя 31 день с момента заказа. Недавно стало известно, что с ноября 2015 года при заказе лицензий-подписок FirePOWER стало возможно указать сдвиг начала и окончания действия лицензий в месяцах. Максимальный срок сдвига составляет 2 месяца (60 дней).

Лицензии комбинируются в различные варианты бандлов (URL Filtering + Protection, Protection + Malware, URL Filtering + Protection + Malware). В моём случае использовалась лицензия URL Filtering + Protection. Партномер выглядел следующим образом:

L-ASA5515-TAC=
Cisco ASA5515 FirePOWER IPS and URL Licenses

На FireSIGHT во вкладке System -> Licenses данная лицензия откроет следующие позиции:



Обращаю внимание, хотя данная подписка включает подписку на IPS (Protection), наличие лицензии Protection отображается в другом месте, за которое отвечает лицензия PROTECT+CONTROL.

Особенности аутентификация пользователей и интегрирования с AD

Так как мы хотим иметь возможность аутентифицировать пользователей и применять политики доступа в Интернет к конкретным учётным записям и/или группам AD, интеграция системы с AD необходима.

На момент нашего внедрения FirePOWER на Cisco ASA аутентификация пользователей происходит только в пассивном режиме. Пассивная аутентификация подразумевает, что отдельно устанавливается программное обеспечение «агент», которое «прослушивает» активность пользователей в логах AD, формирует базу данных соответствия IP-адрес – пользователей, и передаёт эту информацию системе (в нашем случае FireSIGHT). Большим плюсом пассивной аутентификации является тот факт, что User Experience для конечного пользователя абсолютно никак не изменяется. Но есть и минусы, о которых постараюсь рассказать.

Недостаток подхода пассивной аутентификации проявляется в первую очередь, если в компании несколько пользователей одновременно используют одну доменную машину (точнее говоря, один IP-адрес) для выхода в Интернет. Такая схема аутентификации может приводить к некорректной работе правил ограничения доступа. Простейший пример проблемной ситуации – использование терминальной фермы (построенной на базе Microsoft RDS). Проблема проявляется, если пользователи одного и того же терминального сервера должны иметь различные ограничения доступа в Интернет. Каждый новый пользователь, входящий в систему терминального сервера, предоставляет всему IP-адресу сервера (а, следовательно, всем другим работающим пользователям) свои права доступа в Интернет.

Также, проблема с неверным предоставлением прав доступа может проявиться, если на момент входа пользователя в систему ПК был отключен от сети. Таким образом, в теории, новый пользователь сможет получить права доступа предыдущего пользователя ПК, если через какое время подключит ПК обратно к сети.

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

Активная аутентификация может быть доработана режимом Single Sign On (SSO). В этом случае, пользователю уже ничего вводить не требуется. У нас был опыт внедрения предыдущего решения Cisco в классе NGFW – ASA CX. Благодаря стыку нескольких технологий, а именно, активной аутентификации в режиме SSO, IP Virtualization на терминальных серверах и особой настройке DHCP, средствами ASA CX удалось решить задачу корректной аутентификации пользователей терминальных серверов. Решение описанной задачи средствами продукта ASA+FirePOWER пока не проверялось нами.

К слову сказать, некоторое время назад мы проводили сравнение различных систем, обеспечивающих функции межсетевого экранирования нового поколения. Сравнивали такие продукты как ASA CX, ASA FirePOWER, Cisco WSA (несмотря на то, что это web-прокси, а не NGFW, WSA предоставляет схожие возможности в плане контроля Интернет-доступа), Checkpoint и Fortigate. В процессе тестирования мы обращали особое внимание процедурам аутентификации пользователей и, в особенности, проблеме аутентификации пользователей терминальных серверов. В итоге выяснили, что корректно распознавать пользователей терминальных серверов способны Web-прокси сервер Cisco WSA и программно-аппаратные комплексы компании Checkpoint.

Cisco WSA способно идентифицировать клиентские сессии не только по IP-адресу источника, но и по так называемым отпечаткам сессий (Session Cookie). Проще говоря, Cisco WSA посылает пользовательскому браузеру информацию, которая далее используются на WSA, чтобы определить принадлежность сессии тому или иному пользователю. Следовательно, правила фильтрации Интернет-доступа будут корректно применяться к пользователям терминальных серверов, выходящих в Интернет с одинаковых IP-адресов.

Checkpoint предлагает использовать специальное ПО — Identity Agent, который может быть установлен в том числе и на терминальный сервер (далее ТС). Принцип работы ТС агента отличается от принципа работы WSA. ТС агент устанавливает TDI драйвер (Transport Driver Interface), который перехватывает все запросы от всех процессов пользователя на новое соединения. Как только TDI получает такой запрос, он говорит системе закрепить пользователя за этим новым соединением и выбирает для него исходящий порт из пула портов, выделенного конкретно этому пользователю.

Но вернёмся к FireSIGHT и FirePOWER. Как уже было отмечено ранее, аутентификация пользователей в нашем случае работает в пассивном режиме. В качестве агента используется программное обеспечение FireSIGHT User Agent. Что из себя представляет данный агент, и какие настройки потребуется выполнить, будет рассказано чуть позже в разделе «Процесс внедрения». На данный момент хочу добавить только одно: на шаге интеграции системы с корпоративным Active Directory, вероятно, потребуется поддержка специалистов по Microsoft, администраторов Active Directory. Во-первых, возможно, потребуется проверка настроек и/или донастройка Active Directory в соответствии с требованиями User Agent. С требованиями User Agent можно ознакомиться в руководстве пользователя в разделе «Configuring Permissions to Connect to an Active Directory Server».

Во-вторых, если что-то не заработает: (а у нас пару раз и не работало), потребуется помощь в диагностике проблемы.

Процесс внедрения

Итак, приступим к описанию процесса внедрения. Мне посчастливилось внедрять решение FirePOWER на Cisco ASA5515. Внедрение межсетевого экрана Cisco ASA 5515 в сетевую инфраструктуру в данной статье опускаю и начинаю рассказ с того этапа, когда нужно было внедрять непосредственно сервисы FirePOWER.

Первым делом я выделил следующий план, которого и придерживался в дальнейшем:

• Установить систему управления FireSIGHT:
  1. Развернуть и настроить виртуальную машину системы управления FireSIGHT;
  2. Установить необходимые лицензии;
  3. Установить патч для FireSIGHT;
  
• Установить программный модуль FirePOWER на Cisco ASA:
  4. Обновить IOS на Cisco ASA до версии 9.2.2(4) или выше;
  5. Установить SSD диск на Cisco ASA;
  6. Установить и настроить программный модуль FirePOWER на Cisco ASA;
  
• Дальнейшие настройки:
  7. Подключить программный модуль FirePOWER к системе управления FireSIGHT;
  8. Установить патч для модуля FirePOWER с помощью системы управления FireSIGHT;
  9. Установить FireSIGHT User Agent для интеграции системы с корпоративным сервером AD;
  10. Настроить внедряемую систему в соответствии с best practice;
  11. Настроить политики доступа пользователей в Интернет.
  

Итак, шаг №1 – Развернуть и настроить виртуальную машину системы управления FireSIGHT. Необходимо развернуть виртуальную машину из OVF-template на сервере ESXi. Подробно описывать данный шаг не буду, есть подробная инструкция.

Системные требования для FireSIGHT:

Опция	Значение по умолчанию	Настраиваемое значение
Оперативная память	4 ГБ	4 ГБ – минимум 7 ГБ – максимум (рекомендуется при использовании фильтрации по категориям и репутации сайтов и при использовании функционала Security Intelligence)
Виртуальные процессоры	4	до 6
Жёсткие диски	250 ГБ	не настраиваемое

Официально поддерживаемые среды виртуализации:

• VMware ESXi 5.5 (vSphere 5.5)
• VMware ESXi 5.1 (vSphere 5.1)
• VMware vCloud Director 5.1

Нюансы.На данном шаге каких-либо интересных нюансов я не выделил. Единственный момент, который я хотел упомянуть, первый запуск FireSIGHT занимает длительное время.

Сперва в процессе загрузки FireSIGHT предложит подождать 30 минут:



А потом ещё 10 минут:



После загрузки FireSIGHT в консоли мы видим стандартную linux-подобную командную оболочку. Для проведения начальной инициализации и установки сетевых настроек необходимо запустить соответствующий скрипт и выполнить все предлагаемые шаги:



И вот, мы наконец-то получаем долгожданный Web-интерфейс FireSIGHT:



После первого входа в Web-интерфейс, FireSIGHT предложит сменит пароль администратора и выполнить/подтвердить дополнительные настройки начальной инициализации (сетевые настройки, настройки даты/времени, настройки обновлений, настройки резервного копирования и т.д.)
?
Шаг №2 — Установить необходимые лицензии.
Все необходимые лицензии поставляются в формате Product Activation Key (PAK):



Для того, чтобы сгенерировать лицензионные файлы из данных PAK нужно пройти стандартную для практически любой продукции Cisco Systems процедуру на сайте Product License Registration.

В случае виртуальной машины FireSIGHT лицензии привязываются к конкретному экземпляру. Если вы захотите развернуть второй экземпляр из того же OVF-template, для полноценной работы потребуется докупка дополнительного набора лицензий. Уникальным идентификатором виртуальной машины является параметр License Key. Узнать License Key виртуальной машины FireSIGHT можно на вкладке System -> Licenses, нажав на кнопку Add New License:



Данный License Key необходимо ввести вместе с PAK в процессе генерации лицензионного файла на вышеупомянутом сайте:



Если в дальнейшем потребуется получить лицензионные файлы для другого экземпляра FireSIGHT с другим параметром License Key – потребуется провести процедуру «License Rehosting» (по аналогии с ситуацией, когда происходит замена оборудования Cisco по RMA).
После прохождения процедуры регистрации PAK на сайте, содержание полученных лицензионных файлов необходимо ввести в FireSIGHT:



Нюансы лицензирования я уже подробно описал в первой части статьи. Здесь напомню ещё раз две основные идеи:
1. Не потеряйте CTRL-лицензию на Cisco ASA (бесплатная позиция в спецификации);
2. Лицензии-подписки начинают действовать с момента выполнения заказа.
?
Шаг №3 — Установить патч для FireSIGHT. Рекомендуется установить самый последний патч для Вашей версии FireSIGHT. Промежуточные патчи устанавливать не требуется, потому что они заложены в последний патч.
Патчи устанавливаются на вкладке System -> Updates:



После установки патча система автоматически перезагрузится.

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

Шаг №4 — Обновить IOS на Cisco ASA до версии 9.2.2(4) или выше. Поддержка модуля FirePOWER на Cisco ASA заявлена начиная с версии IOS 9.2.2(4) и выше, поэтому необходимо провести апгрейд IOS. Эта информация описана в документе Cisco ASA Compatibility, таблица 8 «ASA Module Compatibility».

Нюансы. Особых нюансов опять же нет. Пути обновления ASA до версии 9.2.2 описаны Release Notes в разделе Upgrading the Software.

Если на Cisco ASA до момента внедрения FirePOWER использовались какие-либо другие программные модули (Legacy IPS или ASA CX), необходимо деинсталлировать эти модули.
?
Шаг №5 — Установить SSD диск на Cisco ASA.



Нюансы. SSD диск Hot-swappable, но, чтобы ASA его увидела, требуется перезагрузка. Статус SSD-диска можно проверить командной show inventory:


?
Шаг №6 — Установить и настроить программный модуль FirePOWER на Cisco ASA. Сперва нужно установить boot image:



Процесс установки займёт 10-15 минут. Проверять, закончилась ли установка или нет, можно с помощью команды session sfr console. Если выдаётся сообщение с ошибкой – ждём. Если провалились в командную строку boot image, загрузка завершена успешно.
Далее, необходимо выполнить сетевые настройки и запустить установку system package:



После установки system package необходимо ещё раз повторить сетевые настройки и указать систему управления для данного модуля FirePOWER, т.е. указать IP-адрес нашей системы FireSIGHT, которую мы развернули на предыдущих шагах:



Нюанс. Чтобы попасть в командную строку FirePOWER из командной строки Cisco ASA нужно ввести команду session sfr console из режима enable (привилегированного режима). Чтобы вернуться в командную строку Cisco ASA нужно зажать комбинацию CTRL+SHIFT+6, отпустить эту комбинацию и нажать клавишу-букву «x».

Шаг №7 — Подключить программный модуль FirePOWER к системе управления FireSIGHT. На предыдущем шаге во время настройки модуля FirePOWER мы указали для него систему управления командной configure manager add. Теперь, на системе управления FireSIGHT мы также должны добавить новое управляемое устройство. Это можно сделать на вкладке Devices -> Device Management, нажав кнопку Add Device:



После добавления ASA5515 FirePOWER к системе управления FireSIGHT необходимо применить имеющиеся лицензии к управляемому модулю:



Нюанс. На данном шаге нюансы отсутствуют.

Шаг №8 — Установить патч для модуля FirePOWER с помощью системы управления FireSIGHT. На шаге 3 мы уже устанавливали патч для FireSIGHT. Теперь нужно установить патч для управляемого устройства – модуля FirePOWER. Как обычно, рекомендуется установить самый последний патч для Вашей версии. Промежуточные патчи устанавливать не требуется, потому что они заложены в последний патч.
Патчи устанавливаются на вкладке System -> Updates:



После установки патча модуль FirePOWER автоматически перезагрузится.
Нюанс. На данном шаге нюансы отсутствуют. Единственный момент, я опять же, установка патчей – длительный процесс.

Шаг №9 — Установить FireSIGHT User Agent для интеграции системы с корпоративным сервером AD. Особенности интеграции системы с AD и процесса аутентификации пользователей я уже описал в первой части статьи. Здесь покажу, что и как нужно настроить.
Вначале необходимо выполнить два действия на FireSIGHT во вкладке Policies -> Users:



Первое действие – создать непосредственное соединение FireSIGHT c Active Directory (кнопка Add LDAP Connection) и задать необходимые параметры LDAP в появившемся меню (IP-адреса/порты AD, BASE DN, учётная запись пользователя). Непосредственное соединение FireSIGHT необходимо для того, чтобы можно было создавать политик доступа для конкретных пользователей и групп из AD. Кроме того, непосредственное соединение необходимо для определения принадлежности пользователей к группам.

Второе действие – указать FireSIGHT User Agent (кнопка Add User Agent).

Далее, для интеграции с AD необходимо установить небольшое программное обеспечение FireSIGHT User Agent на любой компьютер в домене или непосредственно на сервер Active Directory. Внешний вид основной вкладки агента представлен на рисунке ниже:



Далее необходимо выполнить две простые настройки агента. На вкладке Active Director Servers необходимо добавить корпоративные сервера AD:



Authorized User/Password – учётная запись пользователя, под которой агент будет входить в Active Directory для чтения Security logs. Учётная запись пользователя должна обладать некоторыми правами и разрешениями, которые подробно описаны в документе Grant Minimum Permission to an Active Directory User Account.

На вкладке FirePOWER Management Centers необходимо указать IP-адрес системы FireSIGHT:



Если всё настроено верно, на вкладке Analysis -> Users -> User Activity мы сможем увидеть текущую активность пользователей:



Нюансы. В моём случае потребовалось развернуть User Agent непосредственно на сервере Active Directory. Администратор AD самостоятельно выполнил и проверил необходимые настройки AD и предоставил учётные записи пользователя. Однако, при попытке добавления AD сервера в FireSIGHT User Agent мы всё время получали ошибку «Unable to read security logs»:



Складывалось впечатление, что учётка пользователя всё же не обладает всеми необходимыми правами. Однако, когда мы попробовали установить User Agent на удалённый компьютер, сервер AD добавился в User Agent без проблем. В итоге, выяснилось, что я просто не внимательно прочитал User Guide. Оказалось, если агент устанавливается непосредственно на сервер AD, в поле Server Name/IP Address нужно указывать ключевое слово «localhost», а не IP-адрес или доменное имя сервера.

Параллельно с написанием статьи мой коллега внедрял FirePOWER и также потерял некоторое время именно на этапе интеграции агента с AD. В его случае администратор AD также выполнил необходимые требования для учётки пользователя, используемой в агенте. Однако, сервер AD отказывался отправлять необходимые данные агенту, не смотря на жалкие потуги все усилия агента (Polling Status – available – агент отправляет запросы в AD с указанным интервалом):



Выделенный столбец присутствует только в версии агента 2.2 (отображает информацию о том, когда последний раз были получены данные от сервера AD). Помимо этого, при включенном режиме Real-time, Real-time Status отображается как unavailable (и как выяснилось позже, это не имело отношения к проблемам описанным в данном документе, не смотря на соответствующие сообщения в логе агента):



На рисунке изображен агент версии 2.3 и именно Real-time Status и отсутствие столбца Last Reported в этой версии агента, изначально, пустили нас по ложному следу.

Но в конечном итоге, выяснилось, что помимо Default Domain Controllers Policy на сервере AD использовалась другая групповая политика, и администратор AD добавлял разрешения на Manage auditing and security log пользователю именно средствами этой, отдельно созданной групповой политики. Специалисты по Microsoft подсказали, что разрешения на Manage auditing and security log в Default Domain Controllers Policy всегда имеет приоритет над другими групповыми политиками. Как только добавили разрешение пользователю непосредственно в Default Domain Controllers Policy проблема решилась. Здесь хочется заметить, в документации Cisco мы нигде не нашли точного указания использовать именно Default Domain Controllers Policy. Хотя в документе в примере на скриншоте видно, что используется именно эта групповая политика.

Шаг №10 — Настроить внедряемую систему в соответствии с best practice. На данном шаге предполагается настроить следующие политики:

• System Policy (NTP, DNS, База данных и др.);
• Health Policy (параметры и пороги срабатывания для различных показателей «жизнедеятельности» системы);
• Network Discovery (политики обнаружения устройств в сети);
• Intrusion Policy (политики системы обнаружения вторжений);
• File Policy (политики обнаружения типов файлов, блокировки скачивания/выгрузки файлов, политики обнаружения вредоносного кода в файлах).

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

Нюансы. Временная зона Москвы в FireSIGHT до сих пор неверная (UTC+4). Для корректного отображения событий приходится использовать другую временную зону UTC+3. Я выбрал Бахрейн (Asia -> Bahrain).

Шаг №11 — Настроить политики доступа пользователей.
Система предлагает очень широкие возможности по созданию политик контроля доступа. Это контроль доступа к приложениям различных типов (Web-applications, Client Applications, Application Protocols и т.д.), контроль доступа по категориям и репутациям URL, файловые политики, Security Intelligence (обнаружение/блокировка Bot-сетей, Open Proxy, Spam-распространителей, TOR и т.д.), IPS. Вопросы возможностей системы – это уже материал для других статей и обсуждений.

Заключение

В данной статье я постарался рассказать об основных нюансах внедрения FirePOWER на Cisco ASA и кратко пробежаться по шагам внедрения. Надеюсь, данная статья поможет более детально познакомится с продуктом и некоторыми аспектами его работы. Ну и в заключении про FirePOWER хочется сказать: «Да прибудет с вами сила… ОГНЯ.»