Firepower cisco asa что это
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Настройка и обзор Cisco FirePower
В одной из предыдущих статей мы рассматривали межсетевой экран ASA и порядок его первоначальной настройки. Но ничего не стоит на месте и в какой-то момент Cisco купила компанию Sourcefire за баснословные миллиарды «Даларов». Зачем? Ну, во-первых, у Sourcefire был один из лучших в то время на рынке IPS-ов и еще был ряд интересных продуктов, которые Cisco успешно забрала себе в портфолио, например – Advanced Malware Protection, который по сути своей является End Point Detection & Response решением. Зачем? А чтобы можно было вовремя реагировать на угрозы и проводить расследования.
Онлайн курс по Кибербезопасности
Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии
Ну да ладно, мы таки FirePower настраивать собрались. Первоначально Firepower выступал в качестве дополнительного модуля (виртуального в случае 5506-5555 и физического в случае 5585) к ASA. Что есть этот модуль? Этот модуль – отдельный и самобытный кусок ПО, доставшийся от Sourcefire. Отсюда следует забавный вывод: для управления этим модулем требовалась отдельная консоль управления (в идеале). А еще, логика обработки пакетов была довольной необычной, но так как экран работал с относительно небольшими скоростями, было принято решение о выносе модуля FirePower в качестве отдельного, уже не относящегося к межсетевому экрану ASA и назвали это чудо FirePower Threat Defense – где в базе используется ASA, а сверху прилеплен NGFW функционал. Новые FirePower-ы имеют огромную производительность – подробнее смотрите в даташитах.
Кратко о наших баранах или общие рекомендации
Вариации настройки платформы Firepower Threat Defense всего два (а если рассматривать ASA + FirePower сервисы, то аж три, или даже четыре – такой вот коленкор):
Мы же рассмотрим самую медленную, но самую богатую (по функционалу) вариацию – средство централизованного управления FMC. Она обладает многопользовательской настройкой, более продвинутым реагированием на угрозы, такой прям мини-SIEM. Также предусмотрено наследование политик (централизованный пуш конфигурации на устройства), что упрощает настройку. Перейдем непосредственно к первоначальной настройке FMC. Настройки будем рассматривать для IPS/IDS (комплексы средств для предотвращения и обнаружения угроз в локальную сеть). Чтобы максимально эффективно использовать IDS/IPS, нужно придерживаться следующих рекомендаций:
Настройте вы его уже наконец – часть 1
Итак, приступим к настройке платформы Сisco FirePower: Устанавливаем Необходимое ПО: Его можно найти в вашем комплекте поставки, либо можете скачать с официального сайта cisco.com (при наличии у вас сервисного контракта). ПО понадобится следующее: FirePower Management Center (поддерживает ESXi и KVM) и образ для вашей железяки или же образ виртуального Firepower-а, который американцы прозвали NGFWv.
Подключаем кабели (согласно указанной ниже схеме и что неприменимо к виртуалке).
Поместите FMC в сеть управления логическими устройствами. Для обновлений FTD и FMC требуется подключение к интернету. Если оборудование не новое (было кем-то использовано), необходимо стереть текущую конфигурацию следующими командами (выделены «жирным»):
Подключитесь к последовательному консольному порту, используя эмулятор терминала. Firepower 9300 включает последовательный консольный кабель RS-232 – RJ-45. Вам может понадобиться использовать кабель последовательного интерфейса USB от стороннего производителя для подключения. Используйте следующие серийные параметры:
При появлении запроса войдите в систему с именем пользователя admin и паролем cisco123. Вводим только то, что выделено «жирным».
Когда появится запрос о подтверждении конфигурации, подтверждаете – просто наберите yes.
Настройте вы его уже наконец – часть 2
Далее нам необходимо произвести настройки, используя браузер. Обращаю внимание, что не каждый браузер подойдет! Настраивать можно только с управляющего компьютера, IP-адрес которого попадаем в диапазон, который указывали в конфигурации.
Заходим в браузер и в поисковую строку (строку ввода URL) вводим следующее: https://адрес_железки
Вводим имя пользователя admin и новый пароль для входа в дальнейшем. Осуществляем процедуру входа в систему.
Настраиваем NTP соединение. Оно нужно нам для синхронизации времени на всех устройствах. От этого зависит как стабильность, так и сама работа в принципе.
Заходим непосредственно в настройки и выбираем параметр использования NTP-сервера. В правом нижнем углу выберите «Add»
Сохраняем изменения. Заходим во вкладку «Current Time», затем «Time Zone» и выбираем свой часовой пояс из списка и после сохраняем настройки.
Настройте вы его уже наконец – часть 3. Настройка базового функционала.
Настроим интерфейсы. Для этого переходим в саму вкладку «Interfaces», расположенную у рамки окна в черной полосе. Нажимаем «Edit» для интерфейса, который собираемся настроить.
Открываем порт для работы галочкой напротив «Enable». В строке «Type» выбираем назначение интерфейса (мы будем передавать данные, поэтому выбираем пункт «data-sharing». Остальные данные заполнять не обязательно. Скажу, что там настраивается Скорость передачи, авто согласование и режим дуплекса соответственно. Лучше оставить данные параметры не настроенными, система сама перестроится для работы. Перейдем непосредственно к настройке IPS (политика обнаружения вторжений).
Выбираем пункт Policies > Access Control > Intrusion
Далее жмем Сreate Policy (справа кнопка)
И в появившемся окне заполняем имя (Name) (обязательный параметр). Если вы не обладаете достаточными знаниями для детальной настройки IPS, воспользуйтесь рекомендуемыми фильтрами. Пункт Base Policy, в нем выбираем Maximum Detection (максимальная защита). Создаем и применяем изменения с помощью кнопки Create and Edit Policy.
IPS тут умен, гораздо умнее автора этой статьи. В ходе эксплуатации вы это заметите. А именно, что при использовании максимальной степени защиты (Maximum Detection) программное обеспечение предложит вам исключить правила, которые не нужны и просто на «холостую» тратят ресурсы вашего устройства защиты. Такие рекомендации она делает по результатам статистики. Она хранится в Policies > Access Control > Intrusion > Firepower Recommendations > Generate Recommendations
Таким образом, система адаптируется индивидуально для вашей сети.
Настроим обнаружение вирусов и зараженных файлов. Но для более адекватной работы сети, рекомендуется создать DNS «ловушку» (следующий пункт), которая покажет, на какое именно устройство пришел вредоносный файл. Если «ловушку» не создавать, то информация о зараженном файле появится в общем хранилище и определить, какое из устройств получило этот вредоносный файл (код), не представится возможным.
Переходим по пути: Policies > Access Control > Malware & File. Создаем новую политику, даем ей название. Затем добавляем правило (Add Rule). Заполнить рекомендуется так, как указано на изображении. Это общепринятое правило с максимальной степенью защиты. Нажимаем Save.
Теперь настроим DNS «ловушку». Objects > Object Management. Отыскиваем в левой колонке Sinkhole. Далее нажимаем Add Sinkhole
Заполняем таблицу. При заполнении обратите внимание на то, что данные, указанные в IPv4/6 не должны быть в вашей сети. После настройки нажимаем Save.
Далее переходим в настройку DNS политики (Policies > Access Control > DNS). Выбираем Add DNS Policy, добавляем название и сохраняем. Нас автоматически переводит в это правило. Мы видим, 2 раздела (белый и черный листы. Нам необходимо создать и настроить своё правило. Для этого нажимаем Add DNS Rule и появляется новое окно. Заполняем его как на изображении.
В нем мы добавляем все возможные правила, рекомендуемые компанией Cisco. Выбираем все файлы и нажимаем Add to Rule. И непосредственно здесь мы можем применить свою DNS «ловушку». Для этого в пункте Action выбираем Sinkhole. Напротив откроется новый пункт, в котором мы выбираем наш DNS «ловушку». Теперь мы сможем видеть, на какое устройства пришел вредоносный файл (код). На этом первоначальные настройки произведены. Далее производится более детальная настройка исходя из ваших потребностей.
Полный курс по Сетевым Технологиям
В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer
Новое решение Cisco по безопасности следующего поколения (NGFW + NGIPS + AMP)
Итак, свершилось. Компания Cisco анонсировала свое новое решение — FirePOWER for ASA (презентация на русском языке); результат интеграции технологий компании Sourcefire с “родными” решениями Cisco, а точнее с многофункциональной защитной платформой Cisco ASA 5500-X.
Надо заметить, что это не первый совместный продукт. Еще весной, спустя всего полгода с момента приобретения компании Sourcefire, мы интегрировали систему обнаружения и отражения вредоносного кода Advanced Malware Protection (AMP) в наши средства контроля и защиты доступа к Интернет Cisco Web Security (физическое, виртуальное и облачное решение) и средство защиты электронной почты Cisco Email Security (физическое, виртуальное и облачное решение), тем самым расширив платформу для обнаружения вредоносного кода не только на уровне сети или оконечных устройств, но и на прикладном уровне.
Отличительные особенности
Мы уже писали и про NGFW, и про NGIPS, и про AMP, являющиеся основой нового решения Cisco (описания данных решений доступны на русском языке и на нашем сайте). Но мне хотелось бы напомнить его ключевые особенности.
Во-первых, Cisco ASA with FirePOWER обладает встроенной возможностью корреляции событий безопасности. Кто знаком с родными средствами Cisco по предотвращению вторжений (Cisco IPS), тот помнит, что у них есть такой механизм как Meta Event Generator или механизм локальной корреляции, который позволяет обнаруживать мультивекторные угрозы, использущие для вторжения сразу несколько способов проникновения. Каждый такой способ может характеризоваться событиями, которые по отдельности не представляют интереса и имеют низший приоритет. Однако в совокупности эти события могут означать серьезную целенаправленную угрозу. Раньше для обнаружения таких мультивекторных угроз требовались внешние системы корреляции и управления событиями (SIEM), обходящиеся компаниям слишком дорого (и с точки зрения цены, и с точки зрения усилий по внедрению). В Cisco IPS, а затем и в Cisco ASA with FirePOWER эта возможность является встроенной, что позволяет обнаруживать и предотвращать атаки до достижения ими цели, а не после анализа на SIEM. Отличие нового решения в том, что технологии Sourcefire используют больше сведений и источников данных для корреляции.
Второй интересной особенностью Cisco ASA with FirePOWER является приоритезация угроз, опираясь на критичности атакуемых узлов. Иными словами мы можем использовать контекст совершения атаки для отделения важных событий от неважных, для приоритезации усилий специалистов по безопасности по отражению угроз. У Cisco IPS был схожий механизм под названием Risk Rating, позволяющий оценивать каждую угрозу с точки зрения бизнеса. В Cisco ASA with FirePOWER возможность приоритезации еще больше расширена и максимально автоматизирована.
Кстати, автоматизация — это еще один конек технологий Sourcefire и Cisco ASA with FirePOWER. Помимо автоматизации настроек сигнатур и правил в политике безопасности (это делается на базе анализа сетевого и прикладного трафика и распознавания используемых в сети узлов, устройств, протоколов, приложений, операционных систем и др.), сами политики могут динамически адаптироваться в зависимости от изменения ситуации в сети — появления новых сервисов, узлов, пользователей и, конечно, же угроз.
Продолжая тему корреляции, нельзя не упомянуть про такую возможность Cisco ASA with FirePOWER как использование признаков (индикаторов) компрометации, позволяющих оперировать не только событиями от одного средства защиты (например, от сенсора системы обнаружения вторжений), но событиями от разноплановых средств защиты, разбросанных по сети. Например, сканирование сети, обнаруженное IPS, может быть “объединено” с фактом взаимодействия с командным сервером ботнета, определенным межсетевым экраном NGFW, и выполнением вредоносного кода, идентифицированного агентом системы отражения вредоносного кода AMP. Эти три разрозненных события могут служить признаком (indicator of compromise, IOC) того, что против компании готовится атака или сеть компании уже скомпрометирована целенаправленной угрозой.
Наконец, последним по списку, но не последним по важности, является функция ретроспективной безопасности, позволяющей отслеживать факт компрометации узлов сети, которая могла произойти за счет обхода средств периметровой защиты, несанкционированной установки 3G/4G-модема или точки доступа, подключения зараженной флешки и других причин. С помощью анализа пост-фактум мы можем обнаруживать уже свершившиеся факты попадания вредоносных программ внутрь организации, мы можем оперативно отслеживать и локализовывать зараженные узлы, прослеживать цепочку распространения вредоносного кода и анализировать причины компрометации (например, уязвимость в Acrobat Reader или Firefox).
Указанная трехзвенная концепция «ДО — ВО ВРЕМЯ — ПОСЛЕ» реализована во всех наших решениях — Cisco Cyber Threat Defense, Cisco ISE, Cisco ESA/WSA, Sourcefire NGIPS/NGFW/AMP и т.п. Cisco ASA with FirePOWER продолжает эту традицию.
Производительность
Так как новая функциональность Cisco ASA with FirePOWER работает на всем модельном ряду Cisco ASA 5500-X — от модели Cisco ASA 5512-X до Cisco ASA 5585-X (включая и все промежуточные — 5515, 5525, 5545 и 5555), то закономерен вопрос, а какова производительность данного решения? Надо отметить, что она зависит от двух параметров — самой модели и используемой функциональности (NGFW, NGIPS, AMP — в разных комбинациях). Минимальная производительность — 100 МБит/сек (для Cisco ASA 5512-X), максимальная — 15 ГБит/сек (для Cisco ASA 5585-X). Если необходима бОльшая производительность, то лучше ориентироваться на выделенные физические устройства Sourcefire 8300, работающие на скорости до 60 ГБит/сек в режиме NGIPS и до 120 ГБит/сек в режиме NGFW.
Управление ASA with FirePOWER
Закономерный вопрос — а как управляется Cisco ASA with FirePOWER? В настоящий момент для этого необходимо всего два решения — ASDM (для управления одним устройством) или CSM (для централизованного управления несколькими устройствами) и FireSIGHT Manager. ASDM/CSM позволяют управлять функциональностью традиционного МСЭ Cisco ASA, подсистемами VPN, а также позволяют настраивать сетевой функционал защитной платформы — кластеризацию, множественные контексты, маршрутизацию и т.п.
FireSIGHT, уже описанный нами ранее, управляет всей вновь приобретенной функциональностью — NGFW, NGIPS, фильтрация URL и AMP. В скором будущем запланирована интеграция обеих консолей в одном решении по управлению Cisco ASA with FirePOWER.
В качестве резюме
Само решение уже доступно для заказа и использования. При этом, для уже существующих пользователей Cisco ASA, достаточно всего лишь активировать лицензию на необходимый новый функционал (NGFW, NGIPS, AMP — в любой комбинации). Нет ни ожидания поставки физических устройств (исключая модуль для старшей модели Cisco ASA 5585-X — на ней модуль FirePOWER аппаратный), ни необходимости в получении дополнительных разрешений на ввоз. Да и с тестированием данного решения никаких особых проблем — достаточно иметь в своей сети Cisco ASA 5500-Х и запросить в Cisco тестовый ключ (на 45 дней), чтобы протестировать весь описанный функционал. Иными словами, мы позволяем сохранить уже сделанные инвестиции в Cisco ASA 5500-X и использовать эту платформу для расширения защитной функциональности.
Делимся опытом. Интеграция сервисов FirePOWER на Cisco ASA
Привет 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
Так как периодически возникает путаница с лицензиями, попробую внести ясность.
Данная лицензия обеспечивает возможность обнаружения устройств и пользователей в сети (политики Discovery). Лицензия не имеет ограничений на срок действия. Пример партномера лицензии FireSIGHT для управления не более двух Cisco ASA с модулем FirePOWER:
FS-VMW-2-SW-K9=
Cisco FireSIGHT Management Center,(VMWare) for 2 devices
Количество 50 000 – это максимально возможное количество обнаруживаемых устройств и пользователей, поддерживаемое конкретной моделью Defence Center (FireSIGHT). Для виртуального FireSIGHT именно такое ограничение – 50 тысяч.
Кстати сказать, мы нигде в FireSIGHT не заметили, где указывается ограничение на количество подключаемых управляемых устройств (FirePOWER-модулей)…
Пример партномера лицензии PROTECT+CONTROL для ASA5515:
ASA5515-CTRL-LIC=
Cisco ASA5515 Control License
Нюанс лицензии PROTECT+CONTROL. Хочу обратить особое внимание, данный партномер имеет нулевую стоимость. Рекомендую очень внимательно отслеживать спецификации на момент заказа, чтобы данный партномер нигде не потерялся. В моём случае произошло именно так. PAK для лицензии ASA5515-CTRL-LIC не поступил. Пришлось написать письмо на licensing@cisco.com с просьбой сгенерировать для меня недостающую лицензию. Надо отдать должное Cisco TAC, недостающую лицензию выслали в течение шести часов, не задавая никаких лишних вопросов.
Лицензии-подписки (Protection, URL Filtering, Malware)
Нюанс лицензий-подписок. Очень важный момент. Лицензии-подписки начинают действовать с момента заказа, а не с момента установки на устройство. Таким образом, если работы по внедрению системы начались спустя 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
Обращаю внимание, хотя данная подписка включает подписку на 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 предложит подождать 30 минут:
А потом ещё 10 минут:
После загрузки FireSIGHT в консоли мы видим стандартную linux-подобную командную оболочку. Для проведения начальной инициализации и установки сетевых настроек необходимо запустить соответствующий скрипт и выполнить все предлагаемые шаги:
И вот, мы наконец-то получаем долгожданный Web-интерфейс FireSIGHT:
После первого входа в Web-интерфейс, FireSIGHT предложит сменит пароль администратора и выполнить/подтвердить дополнительные настройки начальной инициализации (сетевые настройки, настройки даты/времени, настройки обновлений, настройки резервного копирования и т.д.)
Шаг №2 — Установить необходимые лицензии.
Все необходимые лицензии поставляются в формате Product Activation Key (PAK):
Для того, чтобы сгенерировать лицензионные файлы из данных PAK нужно пройти стандартную для практически любой продукции Cisco Systems процедуру на сайте Product License Registration.
Данный License Key необходимо ввести вместе с PAK в процессе генерации лицензионного файла на вышеупомянутом сайте:
Если в дальнейшем потребуется получить лицензионные файлы для другого экземпляра FireSIGHT с другим параметром License Key – потребуется провести процедуру «License Rehosting» (по аналогии с ситуацией, когда происходит замена оборудования Cisco по RMA).
После прохождения процедуры регистрации PAK на сайте, содержание полученных лицензионных файлов необходимо ввести в FireSIGHT:
Нюансы лицензирования я уже подробно описал в первой части статьи. Здесь напомню ещё раз две основные идеи:
1. Не потеряйте CTRL-лицензию на Cisco ASA (бесплатная позиция в спецификации);
2. Лицензии-подписки начинают действовать с момента выполнения заказа.
После установки патча система автоматически перезагрузится.
Нюансы. На данном шаге нюансы отсутствуют. Единственный момент, который я опять же хотел упомянуть, установка патчей – длительный процесс, поэтому рекомендую выполнять этот этап заранее.
Шаг №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».
После добавления ASA5515 FirePOWER к системе управления FireSIGHT необходимо применить имеющиеся лицензии к управляемому модулю:
Нюанс. На данном шаге нюансы отсутствуют.
После установки патча модуль FirePOWER автоматически перезагрузится.
Нюанс. На данном шаге нюансы отсутствуют. Единственный момент, я опять же, установка патчей – длительный процесс.
Первое действие – создать непосредственное соединение 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:
Нюансы. В моём случае потребовалось развернуть 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. Хотя в документе в примере на скриншоте видно, что используется именно эта групповая политика.
Шаг №11 — Настроить политики доступа пользователей.
Система предлагает очень широкие возможности по созданию политик контроля доступа. Это контроль доступа к приложениям различных типов (Web-applications, Client Applications, Application Protocols и т.д.), контроль доступа по категориям и репутациям URL, файловые политики, Security Intelligence (обнаружение/блокировка Bot-сетей, Open Proxy, Spam-распространителей, TOR и т.д.), IPS. Вопросы возможностей системы – это уже материал для других статей и обсуждений.