First Look at the New Cisco Firepower Threat Defense Software (UPD 09/02/16)



    Hello, Habr! Last fall, we shared with you the experience of implementing FirePOWER services on the Cisco ASA firewall. And in the New Year's flashbacks, they mentioned FirePOWER version 6.0, in which one of the main innovations was the management of all services using ASDM. Progress in Cisco does not stand still and this spring there was a announcement of a new lineup of Cisco Firepower 4100 and 9300. These, in fact, are the same modular ASAs, similar to 5585-X, but with a new name (hi marketing department), more sophisticated, more efficient and with the new centralized management software Firepower Threat Defense (FTD). FTD can be launched not only on devices of the new model range, but also on all ASA 5500-X models, except for 5585-X (at least for the moment). This new software from Cisco will be discussed in this article.

    A bit of background. In FirePOWER version 5.4, everything was “simple”: there was a sensor located on the ASA SSD (either a separate piece of hardware or a virtual machine) and there was software for managing the FireSIGHT Management Center (aka Defense Center). The ASA had its own standard IOS image with control through the CLI / ASDM. The sensor needed its own image, access to which was through the same ASA CLI (or SSH to the mgmt port). Well, access to FireSIGHT was through a browser. To this you need to add separate licenses + smartnet for ASA, separate subscriptions for the sensor and smartnet for FireSIGHT. It goes without saying that such a distributed approach to managing all services did not suit many. With the release of FirePOWER version 6.0, it became possible to manage all services using ASDM. A number of limitations imposed by ASDM itself,

    Gossip. Gossip
    Tsiska says that the development of a new ASDM for Cisco ASA is in full swing and it will be written in HTML 5. It's time. Thanks.

    With the release of FTD, they got centralized control - one image on which the sensor software and Cisco ASA software revolve. Both are managed through the Firepower Management Center (FMC is FireSIGHT, the third name for the same, stop now, please). And everything would be fine, but if in the case of ASDM we received restrictions on FP services, now we get restrictions on the functionality and configuration of ASA. The main limitation is the “non-working” VPN. And it’s not that it doesn’t work, it simply cannot be configured using regular means. Neither Site-to-Site VPN nor Remote access VPN can be configured at this time.

    About Site-to-Site VPN
    In the case of Site-to-Site VPN, everything is rather ambiguous: in Release Notes to version 6.0.1 it is written in black and white: “Devices running Firepower Threat Defense do not support VPN functionality in Version 6.0.1 but do support switching and routing functions. ", But at the same time, the Configuration Guide for FMC 6.0.1 (in pdf format) reads in the same way," 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. " I am inclined to the version from Release Notes, as attempts to configure Site-to-Site VPN from FMC were unsuccessful.

    FTD Installation An FTD

    image is available for installation on all ASA 5500-X and FP 4100/9300 platforms. Not without virtual execution - vFTD, on the basis of which, in the main, further narration will be built.

    The first FTD image received version 6.0.1. In order to be able to connect FTD to FMC, you need to update FireSIGHT to version 6.0.1 (the requirements for FMC do not differ from the requirements for previous versions of the product). The process of preparing a virtual environment or Cisco ASA with the subsequent installation of an FTD image and its connection to FMC is described in detail in the Quick Start guides ( VMware , Cisco ASA and just in case Firepower 4100 , Firepower 9300), so we will not dwell on it. Moreover, this process for ASA and VMware is not much different from installing a separate FP sensor on these platforms. Ultimately, the picture of the connected FTD (in our case, vFTD) will look like this:


    Figure 1 - Displaying vFTD in the FMC console

    What should be noted here:

    1. Licensing

    Licenses now go through the Smart License program - another new licensing scheme from Cisco.

    Gossip. Gossip
    Tsiska says that in the distant future this scheme will replace all traditional licensing schemes, including the recently introduced Cisco ONE scheme.

    The main message of this scheme is the automatic monitoring of the relevance of the subscription / license by the device (the device periodically asks Cisco whether the installed license is relevant and whether the custom functionality matches the subscription conditions) and the ability to centrally manage all subscriptions / licenses through the Smart Software Manager portal created for this.


    Figure 2 - Smart Licenses for vFTD

    2. Routed Mode for Virtual FTD

    Unlike the virtual FP sensor, vFTD can operate in routing mode. This is understandable, because now we have an ASA software image inside FTD. And in the case of virtualization, you need to run it on something and this is something, of course, - ASAv, and more specifically ASAv30. In the process of loading vFTD, the console is constantly replete with messages about starting ASAv, and even asks what image to load:


    Figure 3 - Downloading vFTD. Choosing an image for ASAv

    By the way, the console at the time of loading vFTD is the only place where you can peek at the current licenses for ASAv itself:


    Figure 4 - “VPN Premium” license with activated 3des-aes and without Anyconnect

    Since this is ASAv30, then with installation vFTD we get performance comparable to the iron ASA 5525-X, judging by the numbers in the vendor’s datasheets (ASA 5500-X , ASAv pdf). Of course, it is not yet clear what kind of performance is there taking into account the FP functionality, but still nice.

    About routed and transparent mode
    According to the documentation, transparent mode is also available for FTD, but in the case of vFTD, only routing mode is available.

    FTD Setup FTD

    Setup can be divided into three points:
    1. System Settings
    2. Routing settings.
    3. Customization of functionality by subscription (NGFW, NGIPS, AMP).

    System Settings

    These settings are configured / edited in the Devices -> Platform Settings tab. They look as follows:


    Figure 5 - Platform Settings for vFTD

    In principle, from the names it’s clear what is responsible for, so I will focus only on one thing: a bunch of External Authentication + Secure Shell / HTTP.

    Such a bundle is needed so that we can get directly to the ASAv console. You cannot create local accounts, so you have to use either LDAP or RADIUS (External Authentication) for authentication. Everything seems to be as usual: first configure the authentication method, and then from which addresses, which interface and protocol can be accessed. And if everything is fine with SSH, then HTTP is apparently made "for the future." HTTP on Cisco ASA is usually configured for access via ASDM, but in this case the ASDM image is not available on ASAv and there are no options for downloading and configuring it in FMC, so we get 404 error when accessing through the browser, and when connecting via ASDM “Unable to launch device manager”:


    Figure 6 - Connecting to FTD via HTTP

    Once in the console on SSH, the first thing we watch is show version:


    Figure 7 - Show version via SSH

    Here is information on the vFTD version and on the ASAv software / hardware. Many little scratch with the CLI, come to the conclusion that it was created with only one purpose - monitoring and troubleshooting. Most of the standard commands from the show category are no different from the same commands for the "full" ASAv / ASA. There are capture, packet-tracer, debug, test , etc. commands . Configuration Mode ( conf t ) is absent. The only thing you can configure from enable mode is aaa-serverto authenticate users to the same CLI. And there are two options: either these are account access restrictions, or such an ASAv image, although the name is quite standard for it ( asa961-smp-k8.bin ). But still, having carefully examined the displayed configuration, a tendency to the second option appears, but not without the participation of the first.

    Routing Settings

    Actually, this is the same ASA functionality setting via FMC. All settings are performed in two tabs: Devices -> Device Management and in the Objects tab. In the Objects tab, you can see the standard ASA settings for SLA, route-map, ACL and [AS path, community list, policy list] for BGP:


    Figure 8 - Components of the classic ASA settings

    All custom "objects" in the Objects tab are created for the purpose of their further use by various policies, in particular, the policy applied to the device in the Device Management tab.

    Objects in the CLI
    It is worth considering the fact that even if the configuration of a particular “object” is present in FMC, but it is not used in any of the policies, then such a “object” will not be displayed in the CLI.

    The policy setting in the Device Management tab includes:

    1. The Devices section.

    Similar when setting up a separate FP sensor.


    Figure 9 - Section Devices

    2. Routing.

    Static and dynamic ( EIGRP , OSPF, RIP, BGP, Multicast ). Apparently, for the ability to configure BGP, you should thank version 9.6 (1) of the virtual ASA.


    Figure 10 - Routing setup

    Here is an example of applying the “object” SLA for a static route and displaying it in the CLI:


    Figure 11 - Example of configuring SLA

    3. NAT.

    Here, without nuances and restrictions, all variants of NAT rules are available.


    Figure 12 - Configuring translation rules

    4. Configuring interfaces.


    Figure 13 - Configuring interfaces

    With interfaces, everything is quite standard, with the exception of one point - you cannot set the usual security-level, all interfaces come with a zero security level. But despite the fact that the configuration does not have permission to pass traffic between an interface with the same level of security ( same-security-traffic permit inter-interface ), everything works fine.

    Same-security-traffic inter-interface permission
    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. Set up inline sets.

    Tap mode - instead of passing all traffic through the sensor, only a copy of the traffic will get to the sensor, accordingly, no active actions will be applied to the traffic. But at the same time events (for example, IPS events) will be generated. A kind of monitoring mode for traffic on a selected pair of interfaces ("span mode", when compared with a separate FP sensor). Propagate Link State - bypass mode, we skip all traffic without checking, and if one of the interfaces in the pair is sent in the down state, the same thing happens with the second one (as soon as the problematic interface returns the up state, the second one rises automatically). Strict TCP Enforcement- Enabling triple handshake control for TCP sessions. Tap mode and Strict TCP Enforcement cannot be enabled at the same time.


    Figure 14 - Configuring Inline Sets

    6. Configuring the DHCP service.

    In three options: DHCP server, DHCP relay and DDNS.


    Figure 15 - Configuring DHCP

    This is probably all. As for the parameters of the classical traffic inspection: they cannot be changed, although in the CLI they look quite standard with minor additions in the form of ip options and additional options for tcp.

    Classic Inspection Settings
    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
    !
    


    Configuring subscription policies (NGFW, NGIPS, AMP)

    All policies are configured in the same way as before. The main thing is not to forget to choose the necessary device when deploying them. An interesting point is the Access Control Policy (NGFW) - all configured and applied rules can be viewed through the CLI. In the CLI, they are displayed as an ACL that has a specific name and no less specific syntax:


    Figure 16 - Access Control Policy rules.

    And the main thing here is that such an ACL is applied globally ( access-group CSM_FW_ACL_ global ) and moreover, the absence of the classic deny any any rule at the end of the ACL, in fact, really means its absence. All traffic that does not fall under the created rules (including in the direction of outside-inside) is processed by the “default action” (Default Action, Figure 16). Therefore, it is worthwhile to pay extra attention to the preparation of rules in order to avoid the situation when all incoming traffic is allowed. Any nuances in configuring file policies or IPS policies were not noticed.

    Conclusion

    At first glance, version 6.0.1 FTD seemed extremely"Damp", but for that it is the first version, updates are just around the corner (at the time of writing this article, an upgrade to version 6.0.1.1 was released, which includes a number of bug fixes). At the moment, you cannot transfer all the functionality of the classic ASA to the new platform and, of course, the lack of VPN is especially embarrassing. In any case, a solution based on ASA FTD is well suited for situations in which only FirePOWER functionality is needed. In any other situation, you should still use the “split” version of Cisco ASA with FirePOWER Services. And for those who read to the end (or started from the end) and seriously thought about using such a solution (or maybe they already use it), a small “life hack” is lower under the cut.

    Cheats for Site-to-Site VPN
    You can set up a Site-to-Site VPN crutch . We have access via SSH and, yes, we cannot edit the configuration. But we can load it - the copy command is available in full. All we need to do is upload the running-config, for example, to a tftp server and edit it, load it back. All the necessary lines for the VPN can be added to the gap between the penultimate and last lines of the configuration file (Cryptochecksum and 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
    

    You need to load the prepared configuration with the command, with a clear indication of the location of the configuration file on the FTD:
    copy tftp system:running-config
    

    After the file is copied, the SSH connection will break, you will need to reconnect and save the configuration ( write memory ). After completing the appropriate configuration on the other side, we get a full-fledged, working Site-to-Site VPN.



    And all would be nothing, but it would not be a “crutch”, if not for one nuance: the access-list created for this crypto card created in this way will be deleted from the FTD configuration every time we apply any changes in the FMC console (we perform Deploy) . In this situation, the Embedded Event Manager (EEM), added to the ASA from version 9.2 (1), comes to our aid. In the same way as with the VPN configuration, we add to the EEM configuration:
    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
    

    Such an EEM will add every 5 seconds to the configuration the ACL we need. It is also necessary to add the ACL binding command to the crypto card, since removing the ACL from the configuration also removes the binding. Thus we get a fully functional VPN.

    In such an implementation, one should expect packet loss at the moments of the deployment of policies from FMC to FTD:



    A possible alternative to the event timer in EEM is to perform actions when a message appears in the logs with a specific id ( event syslog id ). This option has not been tested, so I can’t say anything about its success (even in the case of correctly selected id).

    UPD (09/02/2016):

    On August 29, Tsiska released updates to version 6.1. A full list of updates, as usual, in Release Notes on the official website.
    There are a lot of updates and all of them are delicious and pleasant. Here are a few of them:
    1. TS Agent for terminal servers (VDI Identity Support).
      Now it is possible to recognize users behind the terminals. The principle of operation is similar to how it works in Check Point - allocation of a range of ports to each user. I do not hint at anything, but why not do it before? well done anyway.
    2. Kerberos Authentication.
      Can help with Single Sign-On. They also waited, thanks.
    3. Rate Limiting.
      Now we can cut the bandwidth over networks, zones, users / groups, applications, ports and parameters received from ISE.
    4. Site-to-Site VPN.
      Now it should work without any cheats.
    5. Enhanced Virtualization Support.
      Wait for KVM, now it remains to wait for Hyper-V.

    Everything looks cool, but have not been tested in practice, so we can’t say anything about how things really are. At least for now.

    Also popular now: