Challenges of Cisco Firepower Threat Defense Implementation

by | Mar 5, 2021 | Security

If you needed to know one thing before upgrading an old ASA firewall to a Cisco Firepower Threat Defense (FTD) appliance, gone are the days of the CLI (sort of), scripting bulk changes, and Notepad++.  For those of us that live and die in the CLI, it’s a very significant reality to get used to. 

In the past, if you were moving an ASA configuration from one ASA to another ASA, copy and paste were your friend.  You’d simply dump the more:system running-config” into Notepad, then start pasting bits of code over to the new ASA.  Sure, you might need to massage the code a bit (especially if the interface names or numbers don’t match up exactly, or if the old ASA is running 8.2(5) or older), but the programming was so much more efficient since you were not having to manually enter items via the GUI.   

The CLI is still semi-available if you SSH to the appliance, and you can troubleshoot problems that way or run show commands, but all configuration changes are made via FDM (standalone appliance – Firepower Device Management) or via FMC (Firepower Management Center – for managing 1+ appliances). 

Challenge #1 – moving configuration from ASA to FTD 

One of the first things you should do to make an ASA to FTD migration easier, is to audit the existing firewall and to eliminate configuration ‘junk’ (old and/or unused bits of code).  This part is critical for starting off fresh on the new firewall as well as making troubleshooting a lot easier due to a smaller configuration footprint and less complexity. 

Once the configuration is cleaned up, you can now start migrating items over to the new FTD.  Cisco has a tool to assist with the conversion (https://www.cisco.com/c/en/us/products/security/firewalls/firepower-migration-tool.html), but the caveat here is it only works if you have FMC in the environment to manage the new firewalls.  You can also use Cisco Defense Orchestrator (CDO) for the conversion.  Also, if you do use this tool, be sure to double-check things like the access lists to make sure they are accurate. 

If you don’t have FMC or CDO, then you’re stuck with FDM and you’ll have to manually enter all of the objects, object-groups, access-lists, etc., which can be very time-consuming as well as having a higher likelihood for user error.  Even if you’re only managing a single FTD appliance, I highly recommend having a virtual FMC appliance manage it.  The overall FMC interface is a lot better, along with having a lot more nerd knobs available.  A virtual FMC does require one of the following platforms (running 6.7): 

  • Amazon AWS 
  • Microsoft Azure 
  • Google Cloud (new as of 6.7) 
  • Oracle Cloud (new as of 6.7)
  • KVM 
  • VMware 

https://www.cisco.com/c/en/us/td/docs/security/firepower/670/relnotes/firepower-release-notes-670/compatibility.html 

 Challenge #2 – Dealing with configurations unsupported in the GUI 

 Ever since Cisco released the FTD line of appliances, they’ve been slowly adding in support for various functions that the legacy ASA can already do.  For instance, when the FTD line first came out, support for AnyConnect did not yet exist. 

 In version 6.7, Cisco finally has EIGRP support via the Smart CLI.  Previously, it was required to configure using the FlexConfig.  In Smart CLI, you are given a template based configuration. For a particular feature, where you supply values for specific variables,Cisco recommends deploying via Smart CLI if the Cisco defined template exists. FlexConfig provides a way to deploy commands that are not supported in any other way via the GUI, or Smart CLI. FlexConfig does have some pre-built code structures, but you can create custom scripts as well.   

 In a previous blog, I wrote about mapping an LDAP security group to a particular group-policy on the ASA firewall.  In FMC/FTD, it’s a bit more complicated given the fact that you are currently required to use FlexConfig in order to set this up.  To throw another wrench into the process, you also need to set the FlexConfig object to either deploy the config once, or every time.  According to cisco.com, “The only way to choose the right option is to test the results of deployment.  Cisco also recommends a firewall administrator to have extensive familiarity with the CLI before using FlexConfig. 

 Alternatively, one way to quickly find out is if you need to deploy a FlexConfig once or every time it to test it on an ASA firewall (hopefully you have one handy).  First paste in the configuration snippets you are testing.  In the following example, I’m adding an ldap attribute-map.  As you can see, errors pop up stating that mapping already exists.  In the case of applying via a FlexConfig, this would apply correctly the first time, but the second time, it would remove everything after the ldap attribute-map LdapMap, which in this case, would obviously cause some issues to remote users. 

  •  ASA(config)# ldap attribute-map LdapMap 
  • ASA(config-ldap-attribute-map)# map-name memberOf Group-Policy 
  • ASA(config-ldap-attribute-map)# map-value memberOf “CN=VPN BYOD,O$ 
  • ASA(config-ldap-attribute-map)# map-value memberOf “CN=VPN Users,$ 
  • ASA(config-ldap-attribute-map)#  
  • ASA(config-ldap-attribute-map)#  
  • ASA(config-ldap-attribute-map)# exit 
  • ASA(config)# ldap attribute-map LdapMap 
  • ASA(config-ldap-attribute-map)# map-name memberOf Group-Policy 
  • ERROR: Mapping already exists 
  • ASA(config-ldap-attribute-map)# map-value memberOf “CN=VPN BYOD,O$ 
  • ERROR: map-value object already exists 
  • ASA(config-ldap-attribute-map)# map-value memberOf “CN=VPN Users,$ 
  • ERROR: map-value object already exists 
Complete steps on fully implementing a FlexConfig of an lLdap aAttribute-map, then applying the attribute map to an aaa-server group: 
First, configure the aaa-server group.  This is done  under the Ssystem > Iintegrations > Realms section of FMC. 

Once configured, make sure to note the syntax of the name you gave to the aaa-server group and domain controller names, because we’ll use that in our Flexconfig.  An easy way to see how the aaa-server syntax shows up in the running config in the FTD, is to SSH to the firewall’s management IP, enter “system support diagnostic-cli” and run the command show run aaa-server”: 

  1. > system support diagnostic-cli  
  2. Attaching to Diagnostic CLI … Press ‘Ctrl+a then d’ to detach. 
  3. Type help or ‘?’ for a list of available commands. 
  4. ftd-01> enable
  5. Password: ****
  6. ftd-01# show run aaaserver 
  7. aaa-server test.domain.com protocol ldap 
  8.  max-failed-attempts 4 
  9.  realm-id 3 

aaa-server test.domain.com host DC1.test.domain.com 

    •  server-port 636 
    •  ldap-base-dn DC=test,DC=domain,DC=com 
    •  ldap-group-base-dn OU=Groups,DC=test,DC=domain,DC=com 
    •  ldap-scope subtree 
    •  ldap-naming-attribute samaccountname 
    •  ldap-login-password ***** 
    •  ldap-login-dn user@domain.com 
    •  ldap-over-ssl enable 
    •  server-type microsoft 

 aaa-server test.domain.com host DC2.test.domain.com 

    •  server-port 636 
    •  ldap-base-dn DC=test,DC=domain,DC=com 
    •  ldap-group-base-dn OU=Groups,DC=test,DC=domain,DC=com 
    •  ldap-scope subtree 
    •  ldap-naming-attribute samaccountname 
    •  ldap-login-password ***** 
    •  ldap-login-dn user@domain.com 
    •  ldap-over-ssl enable 
    •  server-type microsoft 
    • ftd-01# 
 Second, we configure the ldap attribute-map FlexConfig object, and set it to apply “Once”: 
  1. ldap attribute-map LdapMap 
  2. map-name memberOf Group-Policy 
  3. map-value memberOf “CN=VPN BYOD,OU=Groups,DC=test,DC=domain,DC=com” PersonalDevicesVPN  
  4. map-value memberOf “CN=VPN Users,OU=Groups,OU=test,DC=domain,DC=com” WebVPNPolicy 

Next, we set up a second FlexConfig object.

FlexConfig object is the modification to the aaa-server group that we set up in step 1, which will append the ldap-attribute-map function.  This will be set to apply every time (since it does not error out). 

  1. aaa-server test.domain.com host DC1.test.domain.com 
  2.  ldap-attribute-map LdapMap 
  3.  aaa-server test.domain.com host DC2.test.domain.com 
  4.  ldap-attribute-map LdapMap 

 Once you’ve completed those steps, you’ll go into the Flexconfig setup and create a new FlexConfig policy, which is located under Devices > FlexConfig.  In there, you will add the FlexConfig objects in steps 2 and 3.  Remember, the ordering of step is critical here.  You’ll need to apply the attribute-map object first, and the aaa-server object second.  If these are out of order, you will not have a pleasant experience. 

 Those are, just a couple of challenges you may run into when deploying a new FTD firewall.  If you’d like additional assistance in implementing a new FTD and FMC solution, email info@peters.com.  We are happy to help!