Первый взгляд на новое программное обеспечение Cisco Firepower Threat Defense (UPD 02.09.16)



    Здравствуй, Хабр! Осенью прошлого года мы делились с тобой опытом внедрения сервисов FirePOWER на межсетевом экране Cisco ASA. А в новогодних флэшбэках упомянули про FirePOWER версии 6.0, в которой одной из основных новшеств было управление всеми сервисами с помощью ASDM. Прогресс в Cisco не стоит на месте и этой весной произошел анонс нового модельного ряда Cisco Firepower 4100 и 9300. Это, по сути, все те же модульные ASA, на подобие 5585-X, но с новым названием (привет отдел маркетинга), более навороченные, более производительные и с новым программным обеспечением централизованного управления Firepower Threat Defense (FTD). FTD можно запускать не только на устройствах нового модельного ряда, но и на всех моделях ASA 5500-X, кроме 5585-X (по крайне мере на данный момент). Как раз об этом новом ПО от Cisco и пойдет речь в этой статье.

    Немного предыстории. В FirePOWER версии 5.4 все было «просто»: был сенсор, расположенный на SSD ASA (или отдельная железка, или на виртуалке) и было ПО для управления FireSIGHT Management Centre (он же Defense Centre). Для ASA был свой стандартный образ IOS с управлением через CLI/ASDM. Для сенсора нужен был свой образ, доступ на который осуществлялся чрез тот же CLI ASA (или SSH к mgmt-порту). Ну а доступ к FireSIGHT осуществлялся через браузер. К этому нужно добавить отдельные лицензии+смартнет на ASA, отдельные подписки на сенсор и смартнет на FireSIGHT. Само собой, что такой распределенный подход к управлению всеми сервисами не устраивал многих. С выходом FirePOWER версии 6.0 появилась возможность управлять всеми сервисами с помощью ASDM. Ряд ограничений, накладываемый самим ASDM, нехватка централизованного распределения политик по разным сенсорам и несколько других особенностей не всем пришелся по душе, поэтому многим все же приходится ждать полноценного решения для централизованного управления всем и сразу.

    Слухи. Сплетни
    Циска поговаривает, что полным ходом ведется разработка нового ASDM для Cisco ASA и будет он написан на HTML 5. Давно пора. Спасибо.

    С выходом FTD централизованное управление получили – один образ, на котором крутится ПО сенсора и ПО Cisco ASA. Управление и тем и другим происходит через Firepower Management Center (FMC – все тот же FireSIGHT, уже третье название одного и того же, остановитесь, пожалуйста). И все бы ничего, но если в случае с ASDM мы получали ограничения на сервисы FP, то теперь получаем ограничения на функционал и настройку ASA. Основным ограничением является «не работоспособность» VPN. Да и не то что бы он не работал, его просто нельзя настроить штатными средствами. На текущий момент нельзя настроить ни Site-to-Site VPN, ни Remote access VPN.

    По поводу Site-to-Site VPN
    В случае с Site-to-Site VPN все достаточно неоднозначно: в Release Notes к версии 6.0.1 черным по белому написано: «Devices running Firepower Threat Defense do not support VPN functionality in Version 6.0.1 but do support switching and routing functions.», но при этом в Configuration Guide для FMC 6.0.1 (в виде pdf) точно так же написано «The Firepower Threat Defense appliance provides a unified next-generation firewall and next-generation IPS device. In addition to the IPS features available on Firepower Software models, firewall and platform features include Site-to-Site VPN, robust routing, NAT, clustering (for the Firepower 9300), and other optimizations in application inspection and access control». Я же склонен к варианту из Release Notes, так как попытки настроить Site-to-Site VPN из FMC не увенчались успехом.

    Установка FTD

    Образ FTD доступен для установки на всех платформах ASA 5500-X и FP 4100/9300. Не обошлось и без виртуального исполнения – vFTD, на базе которого, в основном, и будет строиться дальнейшее повествование.

    Первый образ FTD получил версию 6.0.1. Для того, чтобы можно было подключить FTD к FMC, необходимо обновить FireSIGHT до версии 6.0.1 (требования к FMС не отличаются от требований к предыдущим версиям продукта). Сам же процесс подготовки виртуальной среды или Cisco ASA с последующей инсталляцией образа FTD и его подключение к FMC подробно описан в Quick Start гайдах (VMware, Cisco ASA и на всякий случай Firepower 4100, Firepower 9300), поэтому останавливаться на нем не будем. Тем более, этот процесс для ASA и VMware мало чем отличается от установки отдельного FP сенсора на этих платформах. В конечном итоге картина подключенного FTD (в нашем случае vFTD) будет похожа на такую:


    Рисунок 1 – Отображение vFTD в консоли FMC

    На что здесь следует обратить внимание:

    1. Лицензирование

    Лицензии теперь идут по программе Smart License – очередная новая схема лицензирования от Cisco.

    Слухи. Сплетни
    Циска поговаривает, что эта схема в далеком скором будущем заменит все традиционные схемы лицензирования, в том числе и недавно появившуюся схему Cisco ONE.

    Основной посыл этой схемы – это автоматическое отслеживание актуальности подписки/лицензии устройством (устройство самостоятельно периодически спрашивает у Cisco актуальна ли установленная лицензия и соответствует ли настраиваемый функционал условиям подписки) и возможность централизованного управления всеми подписками/лицензиями через созданный под это портал Smart Software Manager.


    Рисунок 2 – Smart Licenses для vFTD

    2. Routed Mode для виртуального FTD

    В отличии от виртуального сенсора FP, vFTD может работать в режиме маршрутизации. Оно и понятно, ведь теперь у нас внутри FTD есть образ ПО ASA. А в случае с виртуализацией его надо на чём-то запускать и это что-то, конечно же, — ASAv, а конкретнее ASAv30. В процессе загрузки vFTD, консоль то и дело пестрит сообщения о запуске ASAv, а то и вообще спрашивает какой образ загрузить:


    Рисунок 3 – Загрузка vFTD. Выбор образа для ASAv

    Кстати говоря, консоль в момент загрузки vFTD – это единственное место, где можно подсмотреть текущие лицензии на саму ASAv:


    Рисунок 4 – Лицензия “VPN Premium” c активированным 3des-aes и без Anyconnect

    Раз уж это ASAv30, то с установкой vFTD мы получаем производительность сравнимую с железной ASA 5525-X, судя по цифрам в даташитах вендора (ASA 5500-X, ASAv pdf). Конечно, пока не понятно, какая там производительность с учетом функционала FP, но все же приятно.

    Про routed и transparent mode
    По документации, для FTD доступен и transparent мод, но в случае с vFTD доступен только режим маршрутизации.

    Настройка FTD

    Настройку FTD можно разделить на три пункта:
    1. Системные настройки.
    2. Настройки маршрутизации.
    3. Настройка функционала по подпискам (NGFW, NGIPS, AMP).

    Системные настройки

    Настраиваются/редактируются эти настройки во вкладке Devices -> Platform Settings. Выглядят они следующим образом:


    Рисунок 5 – Platform Settings для vFTD

    В принципе, из названий и так понятно, что за что отвечает, поэтому остановлюсь лишь на одном: на связке External Authentication + Secure Shell/HTTP.

    Такая связка нужна для того, чтобы мы смогли попасть непосредственно в консоль ASAv. Создать локальные учетные записи нельзя, поэтому для аутентификации приходится использовать либо LDAP, либо RADIUS (External Authentication). Все вроде бы как обычно: сначала настроить метод аутентификации, а затем с каких адресов, на какой интерфейс и по какому протоколу можно заходить. И если с SSH все отлично, то вот HTTP видимо сделан «на будущее». HTTP на Cisco ASA обычно настраивается для доступа через ASDM, но в данном случае образ ASDM отсутствует на ASAv и опций для его загрузки и настройки в FMC нет, вот и получаем, что при доступе через браузер у нас ошибка 404, а при подключении через ASDM «Unable to launch device manager»:


    Рисунок 6 – Подключение к FTD по HTTP

    Попав в консоль по SSH, первым делом смотрим show version:


    Рисунок 7 – Show version через SSH

    Тут и информация по версии vFTD и по софту/железу ASAv. Много Немного поковыряв CLI, приходим к выводу, что создан он с одной лишь целью – мониторинг и траблшутинг. Большинство стандартных команд из категории show ничем не отличаются от таких же команд для «полноценных» ASAv/ASA. Есть команды capture, packet-tracer, debug, test и т.п. Режим конфигурации (conf t) отсутствует. Единственное, что можно настроить из enable режима, – это aaa-server для аутентификации пользователей к этому же CLI. И тут два варианта: либо это ограничения доступа учетных записей, либо такой уж образ ASAv, хотя название для него вполне стандартное (asa961-smp-k8.bin). Но все же внимательно просмотрев выводимую конфигурацию, появляется склонность ко второму варианту, но не без участия первого.

    Настройки маршрутизации

    Собственно говоря, это та самая настройка функционала ASA через FMC. Все настройки выполняются в двух вкладках: Devices -> Device Management и во вкладке Objects. Во вкладке Objects можно увидеть стандартные для ASA настройки SLA, route-map, ACL и [AS path, community list, policy list] для BGP:


    Рисунок 8 – Компоненты классических настроек ASA

    Все настраиваемы «объекты» во вкладке Objects создаются с целью дальнейшего их использования различными политиками, в частности политикой, применяемой к устройству во вкладке Device Management.

    Objects в CLI
    Стоит учитывать тот факт, что даже если настройка того или иного «объекта» присутствует в FMC, но он не используется ни в одной из политик, то в CLI такой «объект» отображаться не будет.

    Настройка политики во вкладке Device Management включает в себя:

    1. Раздел Devices.

    Аналогичный при настройке отдельного сенсора FP.


    Рисунок 9 – Раздел Devices

    2. Маршрутизация.

    Статическая и динамическая (EIGRP, OSPF, RIP, BGP, Multicast). Видимо, за возможность настройки BGP стоит поблагодарить версию 9.6(1) виртуальной ASA.


    Рисунок 10 – Настройка маршрутизации

    А вот и пример применения «объекта» SLA для статического маршрута и его отображение в CLI:


    Рисунок 11 – Пример настройки SLA

    3. NAT.

    Здесь без нюансов и ограничений, доступны все варианты правил NAT.


    Рисунок 12 – Настройка правил трансляций

    4. Настройка интерфейсов.


    Рисунок 13 – Настройка интерфейсов

    С интерфейсами все вполне стандартно, за исключением одного момента – привычный всем security-level задать нельзя, все интерфейсы идут с нулевым уровнем безопасности. Но несмотря на то, что в конфигурации отсутствует разрешение на прохождение трафика между интерфейса с одинаковым уровнем безопасности (same-security-traffic permit inter-interface), всё прекрасно работает.

    Разрешение same-security-traffic inter-interface
    firepower# sh run inter g0/0
    !
    interface GigabitEthernet0/0
     description inside interface
     nameif inside
     security-level 0
     ip address 192.168.20.254 255.255.255.0
    firepower# sh run inter g0/1
    !
    interface GigabitEthernet0/1
     description outside interface
     nameif outside
     security-level 0
     ip address 192.168.200.251 255.255.255.128
    firepower# sh run same-security-traffic
                   	^
    ERROR: % Invalid input detected at '^' marker.
    firepower# sh run | i same
    firepower#
    


    5. Настройка Inline сетов.

    Tap mode – вместо того, что бы пропускать весь трафик через сенсор, на сенсор будет попадать только копия трафика, соответственно активные действия по отношению к трафику применяются не будут. Но при этом события (например, события IPS) генерироваться будут. Своего рода режим мониторинга для трафика на выбранной паре интерфейсов («span mode», если сравнивать с отдельным сенсором FP). Propagate Link State – режим bypass, пропускаем весь трафик без проверки, при этом, если один из интерфейсов в паре отправляется в состоянии down, то и со вторым происходит тоже самое (как только проблемный интерфейс возвращает себе состояние up, второй поднимается автоматически). Strict TCP Enforcement – включение контроля тройного рукопожатия для TCP сессий. Tap mode и Strict TCP Enforcement одновременно включить нельзя.


    Рисунок 14 – Настройка Inline Sets

    6. Настройка сервиса DHCP.

    В трех вариантах: DHCP сервер, DHCP релей и DDNS.


    Рисунок 15 – Настройка DHCP

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

    Настройки классического инспектирование
    firepower# sh run class-map
    !
    class-map inspection_default
     match default-inspection-traffic
    !
    firepower# sh run policy-map
    !
    policy-map type inspect dns preset_dns_map
     parameters
      message-length maximum client auto
      message-length maximum 512
    policy-map type inspect ip-options UM_STATIC_IP_OPTIONS_MAP
     parameters
      eool action allow
      nop action allow
      router-alert action allow
    policy-map global_policy
     class inspection_default
      inspect dns preset_dns_map
      inspect ftp
      inspect h323 h225
      inspect h323 ras
      inspect rsh
      inspect rtsp
      inspect sqlnet
      inspect skinny
      inspect sunrpc
      inspect xdmcp
      inspect sip
      inspect netbios
      inspect tftp
      inspect icmp
      inspect icmp error
      inspect dcerpc
      inspect ip-options UM_STATIC_IP_OPTIONS_MAP
     class class-default
      set connection advanced-options UM_STATIC_TCP_MAP
    !
    firepower# sh run tcp-map
    !
    tcp-map UM_STATIC_TCP_MAP
      tcp-options range 6 7 allow
      tcp-options range 9 255 allow
      urgent-flag allow
    !
    


    Настройка политик по подпискам (NGFW, NGIPS, AMP)

    Настройки всех политик выполняются тем же самым образом, что и раньше. Главное не забывать выбирать необходимое устройство при их развертывании. Интересный момент заключается в политиках NGFW (Access Control Policy) – все настроенные и примененные правила можно посмотреть через CLI. В CLI они отображаются в качестве ACL, который имеет специфическое имя и не менее специфический синтаксис:


    Рисунок 16 – Правила Access Control Policy.

    И главное здесь то, что такой ACL применяется глобально (access-group CSM_FW_ACL_ global) и более того отсутствие в конце ACL классического правила deny any any, фактически, действительно означает его отсутствие. Весь трафик, который не попадает под созданные правила (в том числе в направлении outside-inside), обрабатывается «действием по умолчанию» (Default Action, рисунок 16). Поэтому, стоит крайне внимательно отнестись к составлению правил, дабы избежать ситуации, когда весь входящий трафик разрешен. Какие-либо нюансы в настройке файловых политик или политик IPS замечены не были.

    Вывод

    На первый взгляд версия 6.0.1 FTD показалась крайне «сыроватой», но на то она и первая версия, апдейты не за горами (на момент написания статьи вышел апгрейд до версии 6.0.1.1, включающий в себя ряд багфиксов). На текущий момент, нельзя перенести весь функционал классической ASA на новую платформу и, конечно же, особенно сильно смущает отсутствие VPN. В любом случае, решение на базе ASA FTD хорошо подойдет для ситуаций, в которых необходим исключительно функционал FirePOWER. В любых других ситуациях стоит по-прежнему использовать «раздельный» вариант Cisco ASA with FirePOWER Services. А для тех, кто дочитал до конца (или начал с конца) и всерьез задумался об использовании такого решения (а может уже использует), небольшой «лайфхак» ниже под катом.

    Читы для Site-to-Site VPN
    Настроить костыльный Site-to-Site VPN можно. Доступ по SSH у нас есть и, да, редактировать конфигурацию мы не можем. Но можем ее загружать – команда copy доступна в полном объеме. Всё, что нам нужно это выгрузить running-config, например, на tftp сервер и отредактировав его, загрузить обратно. Все необходимые строки для VPN можно добавить в разрыв между предпоследней и последней строками конфигурационного файла (Cryptochecksum и end):

    Cryptochecksum:073c34a024b2cff7f7303a5c888c2c61
    crypto ikev1 policy 10
     authentication pre-share
     encryption 3des
     hash sha
     group 2
     lifetime 86400
    crypto ikev1 enable outside
    crypto ipsec ikev1 transform-set ESP-AES-SHA esp-aes-256 esp-sha-hmac
    access-list crypto-acl extended permit ip host 192.168.20.5 host 172.25.25.20
    crypto map CMAP 10 match address crypto-acl
    crypto map CMAP 10 set peer 192.168.200.252
    crypto map CMAP 10 set ikev1 transform-set ESP-AES-SHA
    crypto map CMAP interface outside
    tunnel-group 192.168.200.252 type ipsec-l2l
    tunnel-group 192.168.200.252 ipsec-attributes
     ikev1 pre-shared-key 123456
    : end
    

    Загружать подготовленную конфигурацию нужно командой, с четким указанием расположения конфигурационного файла на FTD:
    copy tftp system:running-config
    

    После того как файл скопируется, SSH соединение оборвется, нужно будет снова подключиться и сохранить конфигурацию (write memory). Выполнив соответствующую конфигурацию на другой стороне, мы получим полноценный, работающий Site-to-Site VPN.



    И все бы ничего, но это был бы не «костыль», если бы не один нюанс: созданный таким образом access-list для крипто карты, будет удаляться из конфигурации FTD каждый раз, когда мы применяем любые изменение в консоли FMC (выполняем Deploy). В этой ситуации, к нам на помощь, приходит Embedded Event Manager (EEM), добавленный в ASA с версии 9.2(1). Точно так же, как и с конфигурацией VPN, добавляем в конфигурацию EEM:
    event manager applet cryptoACL
     event timer watchdog time 5
     action 0 cli command "access-list crypto-acl extended permit ip host 192.168.20.5 host 172.25.25.20"
     action 1 cli command "crypto map CMAP 10 match address crypto-acl"
     output none
    

    Такой EEM будет добавлять каждые 5 секунд в конфигурацию необходимый нам ACL. Так же необходимо добавлять команду привязки ACL к крипто карте, так как удаление ACL из конфигурации приводит и к удалению привязки. Таким образом мы получаем вполне работоспособный VPN.

    В такой реализации, стоит ожидать потери пакетов, в моменты развертывания политик с FMC на FTD:



    Возможная альтернатива event timer’у в EEM – это выполнение действий при появлении сообщения в логах с конкретным id (event syslog id). Такой вариант не был протестирован, поэтому о его успехе я сказать ничего не могу (даже в случае корректно подобранного id).

    UPD (02.09.2016):

    29-го августа Циска выпустила обновления до версии 6.1. Полный список обновлений, как обычно, в Release Notes на официальном сайте.
    Обновлений достаточно много и все они вкусные приятные. Вот несколько из них:
    1. TS Agent для терминальных серверов (VDI Identity Support).
      Теперь стало возможным распознавать пользователей за терминалами. Принцип работы похож на то как работает в Check Point – выделение каждому пользователю своего диапазона портов. Я как бы ни на что не намекаю, но почему раньше так не сделать? всё равно молодцы.
    2. Kerberos Authentication.
      Сможет помочь с Single Sign-On. Это тоже ждали, спасибо.
    3. Rate Limiting.
      Теперь можем резать полосу пропускания по сетям, зонам, пользователям/группам, приложениям, портам и параметрам, получаемых от ISE.
    4. Site-to-Site VPN.
      Теперь должно работать без всяких читов.
    5. Enhanced Virtualization Support.
      Дождались KVM, теперь осталось дождаться Hyper-V.

    Все выглядит классно, но на практике не проверяли, поэтому, как дела обстоят на самом деле, сказать ничего не можем. По крайне мере пока что.
    • +11
    • 12,2k
    • 8
    CBS 51,67
    Компания
    Поделиться публикацией
    Комментарии 8
    • 0
      Спасибо за интересную и честную статью.

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

      Я не знаю какие должны быть аргументы, чтобы выбрать эту… конструкцию против конкурентов. При этом ценовым демпингом и не пахнет — даже по сравнению с Чекпойнтами особо радоваться нечему, а уж какой-нибудь Фортинет и вовсе можно установить в двукратном количестве за те же деньги.

      Странный зверь, в общем.
      • 0
        А вы сравнивали цены на годовую подписку на блейды CP и лицензию на FP?
        На сколько я знаю выигрыш там приличный. Именно поэтому мы сейчас вовсю тестируем FP с целью переноса на платформу функций URL\Application фильтрации с CheckPoint-а
        • 0
          На сколько мне известно, нет там никакого выигрыша. Для средненьких ЧП (4400-4600 например) стоимость блейда URL на год — около 1,5К $ примерно. У FP дешевле? Да, и у ЧП URL фильтрация сделана действительно хорошо. Хуже конечно чем в IronPort, но и IronPort уже совсем другие цены и лицензирование по кол-ву пользователей, что совсем не удобно.
          • 0
            У нас как-то не получился выигрыш, причем именно по подписке. В закупке подешевле получалось, но потом всё плюс-минус то же самое. Правда, это по состоянию на конец прошлого года, сейчас, я смотрю, лицензирование FP меняется, надо заново считать.

            Впрочем, у Чекпоинта такой ворох лицензий доступен, что стоимость как закупки, так и продления варьируется в весьма широких пределах. Примерно от «что-то несколько дороговато», до «безумно дорого» :)
          • +4
            Всегда пожалуйста.

            Не возьмусь сказать за всех, но для многих основным аргументом служит IPS. Объективно выражая свое субъективное мнение, NGIPS в FP действительно хорош. Да и Циска, в большей степени, старается позиционировать FP, как решение NGIPS (+AMP), а уже потом как NGFW.

            Первая версия FTD действительно получилась «странной». Но попытка создания централизованного управления «всем и сразу» засчитана. Будем ждать следующих релизов. Как минимум, интересно же, чем там дело закончится с VPN (особенно с Remote Access).
            • 0
              Согласен, IPS хорош, и в этой части Sourcefire всегда были в лидерах. Вполне себе аргумент. Но для NFGW этого мало, а их маркетинг явно завидует успехам PAN :)

              Вот и развивать бы Firepower им отдельно, раз он хорош сам по себе, прикрутить туда VPN от ASA, а остальные ASA-части в EOL. Не думаю что кто-то из клиентов очень сильно расстроится.

              Либо уж тогда встраивать FP движок к себе в ASA OS нативно.

              Я согласен, по сравнению с тем, что было, единое управление на базе FP — это прогресс. Но в целом им NGFW как продукт еще пилить и пилить, а у конкурентов глобально все уже допилено.
          • –1
            Старый колхоз с обновленным фасадом… Крайне печально))
            Оч надеялся, что наконец они реально что то новое и внятное сделают на базе одной новой ОС. Но они похоже даже и не собираются…
            • 0
              29-го августа Циска выпустила обновления до версии 6.1. По этому поводу, небольшой update в конце статьи.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое