First look at the new Cisco Firepower Threat Defense software (UPD 02.09.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 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 an announcement of the new Cisco Firepower 4100 and 9300 lineup. These are, in fact, all the same modular ASAs, like the 5585-X, but with a new name (hello marketing department), more sophisticated, more productive 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 time being). Just about this new software from Cisco and will be discussed in this article.

A little 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 (also known as the Defense Center). ASA had its standard IOS image with control through CLI / ASDM. The sensor needed its own image, which was accessed through the same CLI ASA (or SSH to the mgmt port). Well, access to FireSIGHT was carried out through a browser. To this you need to add separate licenses + smart for ASA, separate subscriptions for the sensor and smart 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 is possible to manage all services using ASDM. A number of restrictions imposed by the ASDM itself, the lack of a centralized distribution of policies across different sensors and several other features did not please everyone, so many still have to wait for a complete solution for centralized management of everything at once.
')

With the release of FTD, the centralized management received - one image on which the sensor software and Cisco ASA software is running. Both are managed through the Firepower Management Center (FMC is the same FireSIGHT, the third name of the same one, please stop). And everything would be fine, but if in the case of ASDM we received restrictions on FP services, then now we get restrictions on the functionality and configuration of the ASA. The main limitation is the "not working" VPN. And not that it does not work, it simply can not be set up by regular means. Currently, neither Site-to-Site VPN, nor Remote access VPN can be configured.


FTD installation

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

The first FTD image got version 6.0.1. In order to be able to connect FTD to FMC, you need to upgrade FireSIGHT to version 6.0.1 (requirements for FMC do not differ from requirements for previous versions of the product). The very process of preparing a virtual environment or Cisco ASA followed by the installation of an FTD image and its connection to FMC are described in detail in the Quick Start Guide ( 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. In the end, the picture of the connected FTD (in our case vFTD) will look like this:


Figure 1 - Displaying vFTD in the FMC console

What you should pay attention to here:

1. Licensing

Licenses are now under the Smart License program - another new licensing scheme from Cisco.


The main message of this scheme is the automatic tracking of the subscription / license up to date by the device (the device itself periodically asks Cisco whether the installed license is relevant and whether the customized functionality meets the subscription conditions) and the ability to centrally manage all subscriptions / licenses via the Smart Software Manager portal created for it.


Figure 2 - Smart Licenses for vFTD

2. Routed Mode for Virtual FTD

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


Figure 3 - Loading vFTD. Image selection 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 the ASAv itself:


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

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


FTD Setup

The FTD setting can be divided into three points:

1. System settings.
2. Routing settings.
3. Setting subscription functionality (NGFW, NGIPS, AMP).

System settings

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


Figure 5 - Platform Settings for vFTD

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

This bundle is needed so that we can get directly to the ASAv console. You cannot create local accounts, so you must 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 which protocol you can access. 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 there is no ASDM image on ASAv and there are no options to load and configure it in the FMC, so we get that when accessing via the browser we have error 404, and when connecting via ASDM "Unable to launch device manager":


Figure 6 - Connecting to FTD via HTTP

Having got to the console on SSH, first of all we watch show version:


Figure 7 - Show version via SSH

Here and information on the version of vFTD and software / hardware ASAv. Many Having picked CLI a little, we come to the conclusion that it was created with the sole purpose - monitoring and troubleshooting. Most of the standard commands from the show category are no different from the same commands for “full-fledged” ASAv / ASA. There are commands capture, packet-tracer, debug, test , etc. Configuration mode ( conf t ) is missing. The only thing that can be configured from the enable mode is an aaa-server to authenticate users to the same CLI. And then there are two options: either these are access restrictions for accounts, or such an ASAv image, although the name for it is quite standard ( asa961-smp-k8.bin ). But still, carefully reviewing the output configuration, there is a tendency to the second option, but not without the participation of the first.

Routing Settings

As a matter of fact, this is the very same setting of the ASA functionality through FMC. All settings are performed in two tabs: Devices -> Device Management and in the Objects tab. In the Objects tab, you can see the default settings for the ASA SLA, route-map, ACL and [AS path, community list, policy list] for BGP:


Figure 8 - Components of classic ASA settings

All customizable “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.


Setting a policy in the Device Management tab includes:

1. Devices section.

Similar when setting up a separate FP sensor.


Figure 9 - Devices Section

2. Routing.

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


Figure 10 - Configure Routing

Here is an example of using the “object” SLA for a static route and its display in the CLI:


Figure 11 - SLA configuration example

3. NAT.

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


Figure 12 - Setting translation rules

4. Configuring interfaces.


Figure 13 - Interface settings

With interfaces, everything is quite standard, with the exception of one thing - the usual security-level cannot be defined, all interfaces come with a zero level of security. But despite the fact that in the configuration there is no permission to pass traffic between the interface with the same security level ( same-security-traffic permit inter-interface ), everything works fine.


5. Setting up inline sets.

Tap mode - instead of passing all traffic through the sensor, only a copy of the traffic will be sent to the sensor, respectively, active actions will not be applied to 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, while if one of the interfaces in the pair is sent in the down state, then the same happens with the second one (as soon as the problematic interface returns to its up state, the second one rises automatically). Strict TCP Enforcement - enable triple handshake control for TCP sessions. Tap mode and Strict TCP Enforcement cannot be enabled at the same time.


Figure 14 - Setting Inline Sets

6. Configure the DHCP service.

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


Figure 15 - DHCP Setting

On this, perhaps, everything. As for the parameters of the classic traffic inspection: they cannot be changed, although in the CLI they look quite standard with small additions in the form of ip options and additional options for tcp.


Setting subscription policies (NGFW, NGIPS, AMP)

All policies are configured in the same way as before. The main thing to remember is to choose the necessary device when deploying them. An interesting point is the NGFW (Access Control Policy) policies - all configured and applied rules can be viewed through the CLI. In CLI, they are displayed as an ACL that has a specific name and at least a 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 classical deny any any rule at the end of the ACL actually means its absence. All traffic that does not fall under the rules created (including in the direction outside-inside) is processed by the “default action” (Default Action, Figure 16). Therefore, it is necessary to carefully consider the drafting of the rules in order to avoid a situation where all incoming traffic is allowed. There were no nuances in the configuration of file policies or IPS policies.

Conclusion

At first glance, version 6.0.1 of FTD seemed extremely “damp”, but then it is also the first version, updates are not far off (at the time of writing this article there was an upgrade to version 6.0.1.1, which includes a number of bug fixes). At the moment, it is impossible to transfer all the functionality of a classic ASA to a new platform and, of course, the absence of a VPN is especially confusing. In any case, the ASA FTD solution is well suited for situations in which only FirePOWER functionality is needed. In any other situations, 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 already using it), a small “life hack” is below the cut.


UPD (09/02/2016):

On August 29th, Tsisk released updates to version 6.1. A complete list of updates, as usual, in the Release Notes on the official site.
There are a lot of updates and all of them are tasty and pleasant. Here are a few of them:

1. TS Agent for terminal servers (VDI Identity Support).
   It is now possible to recognize users behind the terminals. The principle of operation is similar to how it works in Check Point — allocating to each user its own range of ports. I do not hint at anything, but why not do this before? Well done anyway.
2. Kerberos Authentication.
   Can help with Single Sign-On. This was also expected, thank you.
3. Rate Limiting.
   Now we can cut the bandwidth across 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.
   They waited for KVM, now it remains to wait for Hyper-V.

Everything looks cool, but we haven’t checked it in practice, so we cannot say anything about how things really are. At least for now.