Well, the release of Firepower 6.3 is now upon us! This release brings several long awaited features including multi-instance and FQDN Access Control rules. Let’s take a closer look at some of the highlights.
There is a new Specific License Reservation available for approved customers. This allows the using the Firepower Management Center (FMC) on an air-gapped network. Previously, the only way to use the smart license feature was to have either Internet access or a satellite license server. Now a special license can be installed which is valid for a specific duration without the requirement to access the Cisco site or the Smart Software Satellite Server.
New/modified screens: System → Licenses → Specific Licenses
** This is detailed in it’s own blog: https://www.lammle.com/post/cisco-firepower-ftd-6-3-new-licensing-feature/
Another often requested feature has been hardware bypass modules for the 2100 series Firepower devices. With 6.3 you can now use hardware bypass network modules for your transparent inline sets. This provides an added safety net to allow traffic to pass if the device loses power. Bypass can also be enabled from the FMC web user interface under Device Management.
There is now a configurable update interval for URL category and reputation data. If you are using the URL license to control the sites your users can access you may be interested in this change. To keep your URL data more up-to-date you can reduce this interval. As noted in the documentation, this is a tradeoff between accuracy and performance. A shorter update interval will keep your URL categorization data more current however it could result in slower web browsing for your users. You should test in your own environment to determine the best setting. Note that while the option to expire this data is present in 6.3 the default remains the same – cached URL data does not expire.
New/modified screens: System → Integration → Cisco CSI → Cached URLs Expire
Intelligent Application Bypass (IAB) is now enabled by default.
This is a fairly important under the hood setting in the Advanced tab of the Access Control policy. It may not be something you’ve enabled in the past but it’s worth looking at. The setting controls Snort’s behavior when there are large traffic flows which can tie up CPUs and cause high utilization and increased traffic latency. On systems such as the ASA with Firepower Services these large flows can even impact the other flows on the device. Intelligent Application Bypass is a highly configurable and automatic way to bypass these flows once certain thresholds are reached.
New Access Control policies created in version 6.3 will enable the IAB feature. Existing policies will not be changed. Keep in mind that this change in policy defaults can introduce unwanted deviations across your policies. If you create a new Access Control policy and assume it will have the same default settings as your existing policies you can wind up with inconsistent coverage in your environment. One feature that can help in this regard is policy hierarchy. Using a master Access Control policy to enforce settings on child policies can keep your environment in sync even when defaults change between versions.
Access Control and prefilter rules can now use fully qualified domain (FQDN) network objects.
You must configure DNS server groups and DNS platform settings so the system can resolve DNS names. This has been an often requested feature and brings FTD closer to parity with the ASA.
You can find the DNS Server group in Objects, and must also be configured in Platform settings for the FTD devices
High Availability and Scalability
Probably the biggest new feature in 6.3 is Multi-instance or, the ability to deploy multiple logical devices on a single security engine/module. This applies to the 4100 an 9300 devices only. This is not your father’s multi-context! Instead of processes sharing computing power like multi-context, Multi-instance allows you to allocate a number of CPUs to each instance.
The underlying technology uses Docker to run several virtual appliances on the same security module. Each instance looks like a separate FTD device to the FMC and each is managed separately. All processing is isolated to the instance so the CPU utilization of one instance cannot affect other instances on the same module. The number of instances available depends on the hardware model.
In this release you can setup high availability (HA) between instances on different chassis but clustering support will come in a later release. Also, Multi-instance currently only supports FTD. Hopefully we will see the ability to run both FTD and ASA instances on a single engine/module in a future release!
You also get this new Multi-instance capability without buying any additional licenses. Licensing is still done at the engine/module level so all the instances you create on the module use the same licenses already purchased.
SSL hardware acceleration has now been extended to the 2100 series Firepower devices. Similar to their big brothers the 4100 and 9300, the 2100 can now use it’s on-board crypto chip to improve SSL decryption performance.
Note that upgrading to 6.3 automatically enables SSL hardware acceleration on eligible devices. If you are not using SSL decryption in your deployment, Cisco recommends disabling this setting on your devices that are not decrypting traffic.
The above note also applies to anyone who is using SSL decryption on a device that previously supported hardware acceleration. If you previously did not have this feature enabled, it will be automatically enabled upon upgrading to 6.3. This could be important as the hardware decryption chip does not support all of the cipher suites that are supported by software decryption. Make sure you test thoroughly to ensure you are not breaking some of your SSL sessions by enabling hardware acceleration.
Events, Logging and Analysis
One of the less touted but still interesting features is Contextual Cross-Launch. This makes external integrations with the FMC event views possible. There are dozens of cross-launch integration links included and you can even create your own custom links. Very handy for pivoting to other systems to gain additional context around a Firepower event.
Look under: Analysis → Advanced → Contextual Cross-Launch
Event logging via syslog has been improved.
There have been some format changes for syslog messages for connection, security intelligence and intrusion events. You may need to update your SIEM systems to ensure syslog messages are properly parsed.
The Access Control policy now has a Logging tab which consolidates several types of logging.
Access Control, Prefilter, SSL and Intrusion policy external syslog is now controlled by the settings on this tab. We are hoping for additional consolidations in the future bringing the ASA logs into the same central configuration scheme.
Administration and Troubleshooting
There have been a number of changes and improvements in the administration and troubleshooting areas. Some of these include the ability to set an access list for SNMP on devices. This is something classic Firepower has had for over a decade but is just finding its way into FTD. Also, you can now lock down the command line on the FMC by implementing a limited CLI and disabling the bash shell.
Additional login security options have been added for FMC users including tracking successful logins, limiting password reuse and disabling access temporarily for multiple login failures.
You can also now backup and restore FTD device configurations with a pull or pull option. You can also copy configurations between devices. This should speed up deployment of multiple devices and also help with device recovery.
Those are some highlights of the new Firepower 6.3 version.