Перший погляд на нове програмне забезпечення Cisco Firepower Defense Threat



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

Трохи передісторії. У FirePOWER версії 5.4 все було просто: був сенсор, розташований на SSD ASA (або окрема залізка, або на виртуалке) і було для управління FireSIGHT Management Centre (він же Defense Centre). Для ASA був свій стандартний образ IOS з керуванням через CLI/ADSM. Для сенсора потрібен був свій образ, доступ на який здійснювався через той же CLI ASA (або SSH до mgmt-порту). Ну а доступ до FireSIGHT здійснювався через браузер. До цього потрібно додати окремі ліцензії+смартнет на ASA, окремі підписки на сенсор і смартнет на FireSIGHT. Само собою, що такий розподілений підхід до управління всіма сервісами не влаштовував багатьох. З виходом FirePOWER версії 6.0 з'явилася можливість управляти всіма сервісами за допомогою ADSM. Ряд обмежень, що накладається самим ADSM, брак централізованого розподілу політик з різних сенсорів і кілька інших особливостей не всім припав до душі, тому багатьом все ж доводиться чекати повноцінного рішення для централізованого управління всім і відразу.

Чутки. ПліткиЦиска подейкує, що повним ходом ведеться розробка нового ADSM для Cisco ASA і буде він написаний на HTML 5. Давно пора. Спасибі.

З виходом FTD централізоване управління отримали – один образ, на якому крутиться сенсора і ПО Cisco ASA. Управління і тим і іншим відбувається через Firepower Management Center (FMC – все той же FireSIGHT, вже третє назва одного й того ж, зупиніться, будь ласка). І все б нічого, але якщо у випадку з ADSM ми отримували обмеження на сервіси 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 Defense Threat 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 Defense Threat 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» з активованим 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 зазвичай налаштовується для доступу через ADSM, але в даному випадку образ ADSM відсутній на ASAv і опцій для його завантаження і налаштування в FMC немає, от і отримуємо, що при доступі через браузер у нас помилка 404, а при підключенні через ADSM «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 і [path AS, 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-maximum length client auto
message-maximum length 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 watchdog timer 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).

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.