Continuing the series of Firepower 101 series of posts, we will look at basic device registration and system configuration in this article. If you haven’t read my previous article yet, I suggest to go back and familiarise yourself with the solution and what it can offer – Firepower Solution Overview.
So, you’ve got your shiny new firewall and you’re ready to get it configured! In this article I’m going to assume you are managing the device via Firepower Management Centre (FMC). If you’re not, you are potentially missing out on everything the solution can offer!
I’m also going to skip going into detail of the device imaging process. “Why? That’s really unhelpful”. A few reasons…
- Whilst drafting this I was sat in a hotel in Liverpool without access to a device console to play with and ensure I’m giving you accurate info! I’ve worked primarily with the ASA-X and the Firepower Threat Defense (FTD) 2100 appliances, but the imaging process on the 4100 appliances is pretty different due to another underlying OS called FXOS. I’d rather give you no info than wrong info
- I want to focus my articles more on the FMC side of things – that is where most of the magic happens
- If I told you how to do everything then I’d be out of the job 😉
Follow the relevant installation guide for your appliance and you can’t go far wrong. It really is pretty straightforward, and I haven’t hit any issues before.
Installation and upgrade guides for the Firepower appliances can be found here.
Installation and upgrade guide for FMC can be found here and here
So, now you’ve gone and got your appliances and FMC imaged, IP’d and ready to go, we can begin…
Licensing – everyone’s favourite subject! First step in getting your devices ready to go is to ensure your FMC has all the relevant licenses added. As with a lot of Cisco products, there are two options now – Classic “PAK” based licensing and Smart Licensing. Cisco is slowly moving everything to Smart Licensing and if you haven’t already set your organisation up for Smart Licensing it is worth doing – it is nothing scary. More info on Smart Licensing can be found here.
When it comes to Firepower you are probably going to be deploying it as either Firepower services on an ASA or FTD. At the moment Firepower services on an ASA will use classic PAK licensing and FTD will only use Smart Licensing. These are both setup under System > Licenses then the relevant tab based on the type you are using. Note, for Smart Licensing the FMC appliance will need reachability to the Internet.
For some helpful reason the terminology used for the licensed features is slightly different between classic and smart licenses as shown below.
- Control and Protection (TA) – Provides firewalling, application control, IPS and threat intelligence
- Control, Protection and URL (TAC) – Provides all of the above, plus the ability to do URL filtering
- Control, Protection and Malware (TAM) – Provides all that TA does, plus the ability to do Advanced Malware Protection (AMP)
- Control, Protection, Malware and URL (TAMC) – The full works
- URL (where adding to existing TA) – If you already had a TA subscription this allows you to bolt on URL at a later date
- AMP – If you already had a TA subscription this allows you to bolt on AMP at a later date
- Threat (T) – Equivalent to Control and Protection
- Threat and URL (TC) –Equivalent to Control, Protection and URL (TAC)
- Threat and Malware ™ –Equivalent to Control, Protection and Malware (TAM)
- Threat, Malware and URL (TMC) –Equivalent to Control, Protection, Malware and URL (TAMC)
- URL – Same as classic but can be used with or without threat
- AMP – Same as classic but can be used with or without threat
Some licenses are term-based and there are some restrictions on certain things. The partner you purchase through should make sure you get the right licenses you need, but more info is available here if you are interested.
Register devices against FMC
Whether you have chosen to go Firepower services or FTD, you need to look at registering the devices against the FMC. All subsequent configuration will then be carried out through the FMC web console.
Connect to the console/management IP of the Firepower appliance (the username/password will vary based on the deployed version but nowadays tends to be admin/Admin123) and issue the following command:
configure manager add <fmc_hostname|ip|DONTRESOLVE> <registration_key> <nat_id>
If your FMC is sat behind a NAT device then you may not have a dedicated IP for it. In this instance you can use the “DONTRESOLVE” and “nat_id” options. This basically says to the Firepower appliance “An FMC is going to connect and manage you, but I don’t know what the IP will be“. A couple examples to clarify this:
- FMC and Firepower can talk directly over private IP – “configure manager add 10.1.1.1 Cisco123”
- FMC is behind a PAT device – “configure manager add DONTRESOLVE Cisco123 123456”
One point to consider here… depending on your topology there is a bit of an issue. If FMC and Firepower can talk directly via private management IPs then happy days! But what if you are deploying Firepower to a remote branch office? What are the options? At the moment you are limited to the following really:
- Management on the Internet – In order to allow FMC and the Firepower appliance to talk you could put the Firepower management port directly on the Internet. This prevents any issues where the management traffic has to route through the Firepower device itself, but obviously could be viewed as a bad idea for security reasons
- Management through Firepower – You could pre-stage the Firepower appliance with all relevant settings. When the appliance is then shipped to site, the management traffic would route through the Firepower itself. This is fine, until the point you mess something up! Having Firepower management flow through the data plane it is controlling isn’t a great idea – it is much better out-of-band
- Utilise another device for VPN – If you have another device (such as a router) that could be used to tunnel the management traffic back to the FMC then this would be ideal. It prevents the management traffic from flowing through the Firepower data plane but also keeps the management port off the Internet
- Separate FMC – You could have a separate FMC per site if you were particularly worried about the above, but it isn’t a scalable approach – I’d definitely not recommend this
You could of course always manage the remote appliance using the local Firepower Device Manager GUI, but then you wouldn’t want to do that would you – you’d lose some features!
Once you’ve added the relevant command to all of your Firepower appliances it is time to finish the registration by logging into FMC. Once logged in, navigate to Devices > Device Management then click Add. Note, if you are going to be adding a High Availability (HA) pair, you will first need to add the two devices individually. The HA pair is added after with the Add > High Availability option (note, this is only applicable to Firepower Threat Defense appliances – not Firepower services).
Once you’ve selected Device from the drop-down menu you’ll be presented with the following.
The values are pretty self-explanatory, but just to make sure there is no confusion…
- Host – The IP address of FQDN of the Firepower Firewall/services module
- Display Name – Whatever name you want to assign to the firewall
- Registration Key – This needs to be the same as the one you entered on the CLI earlier using the “configure manager add” command
- Group – An optional entry. Device groups allow you to group devices for ease of management when deploying policies or updates. For example, you may choose to group devices based on country or site etc. – the choice is entirely yours here. Whatever will make sense for you (or none at all)
- Access Control Policy – This basically refers to the firewall policy you will deploy to the device. If you haven’t already created one, then you’ll need to do so here. When creating one through this screen you’ll need to provide a name and a default action – everything else will be configured later
- Licensing – The options you see here will vary based on the version you are running and the device type you are adding (e.g. Firepower services vs FTD)
- Advanced – If you had to configure a NAT-ID due to the placement of your FMC then this is the section to look at configuring that. Otherwise it can be left as it is
Once you click register the FMC will go away and try and initiate communication with the Firepower device. After a little while you’ll see it appear in the list of devices and it will then go through a synchronisation process. This can take 5⁄10 minutes, but once complete you should be left with a green healthy looking device.
If you need to setup a HA pair, then you can do this after initially registering the two devices individually. When creating a HA pair you will select a primary and secondary device as well as the device type. There are two options for device type:
- Firepower Threat Defense – Refers to FTD appliances
- Firepower – Refers to the Firepower 7000⁄8000 NGIPS appliances (not something we will be covering)
You’ll notice neither option provides a solution for Firepower services on ASA. With Firepower services on a pair of HA ASAs you will manage them as two totally separate devices. It is therefore important you keep the policies on both synchronised. This is one example where a group may be useful.
Focusing on the FTD option, you will need to ensure the devices are running the same level of hardware/software as you would on most devices.
Under the hood the settings you configure in the GUI will setup the ASA “failover” commands (amongst other things). If you are familiar with these ASA commands then the settings shown above should be familiar to you. If you haven’t, then there are two main link types. The “High Availability” link provides a heartbeat interface for the devices to communicate with each other (they also use data interfaces as a backup) and a method to sync config. The state link is the interface used to pass information on active connections passing through such as source/dest IP and ports and NAT translations. Both these roles can reside on a single psychical link, however it is best practice to split them out.
The IPs you use in the configuration here do not need to be globally routeable – they only need to provide connectivity between the two FTD appliances. The name can be anything you like such as “FOVER-LINK” and “FOVER-STATE”.
Once you’ve added the HA pair, any further configuration such as IP addressing and policy deployment is applied to the HA object, not the actual individual devices themselves.
If you are deploying your firewalls in production then it is probably a good idea to have some monitoring in use too! Monitoring of appliances (including FMC itself) is taken care of by way of health policies. By default there is a single health policy (Initial_Health_Policy) that applies to all Firepower devices and FMC. If you have specific monitoring needs that may vary based on individual devices/groups of devices then it may be sensible to create additional policies.
The default health policy (for some reason) doesn’t enable some checks that you likely want. One of those checks is CPU usage – my guess is because perhaps the devices peak quite a bit and it is possibly a bit noisy. Test it in your environment and see if it causes you any headaches. Typically for a new deployment I will go into the policy and enable the CPU usage check (it hasn’t caused me any problems so far).
Once you’ve finished editing your health policy and clicked save, don’t forget to deploy the changes. This isn’t done with the usual deploy button, instead there is a special little green tickbox that will push the monitoring changes…
One other setting you may want to disable (or blacklist on a per device basis) is the Interface Status check. This check looks at traffic levels and generates an alert when very low levels are seen. Where you have a single device this isn’t usually an issue – you probably want to know if traffic drops off a cliff for some reason. But with HA devices, there is always going to be one device that isn’t doing anything and typically this flags up as an alarm. You can either disable the check completely under the health policy or navigate to System > Health > Blacklist and just disable this on a specific appliance (i.e. the secondary).
Monitoring policies are all setup and deployed to the relevant devices. But how are we going to know when an alarm triggers? By default alarms that are generated are just going to appear in the FMC console. This is all well and good if you have someone monitoring it 24⁄7, however chances are you won’t have, and will also want an email or syslog to be generated.
Alert generation is accomplished with a Monitor Alert Policy. Before we configure the policy we need to setup the relevant SMTP settings and define an email alert object. Navigate to System > Configuration and enter the relevant details followed by a quick test then save. It is important to test – often the SMTP server hasn’t been setup to allow FMC to relay mail through it. Obviously if your SMTP server supports encryption then go ahead and use it, and if required fill out the authentication details.
Now the SMTP relay settings are configured we need to define an SMTP object. Navigate to Policies > Actions > Alerts and click on Create Alert. Give it a name and provide a to/from address then click Save. After clicking save it should be automatically enabled – but just double check the “enabled” switch to the right of the page to be sure.
Finally, we will create the actual monitoring policy. This allows you to specify what alarms to generate emails for and at what severity. Navigate to System > Health > Monitor Alerts. To create a policy, give it a name and then select one or more values using the mouse and CTRL/SHIFT buttons in each column. When you’ve selected the ones you want and optionally provided a threshold – click save.
The threshold can be used to suppress notifications for a period of time. For example, if the monitor policy configured earlier had a run time of 5 minutes (the default) and you set the threshold in the alert policy to 15 minutes, then the alarm would have to be active for three policy run intervals (15 minutes) before alerting you to it.
Under System > Configuration you’ll find lots of different options. I’d advise looking through them to understand which are applicable for you. Some of the settings I’d recommend visiting include:
- Access List – By default this allows any IP to connect on HTTPS and SSH to the FMC. I’d recommend locking this down to your relevant internal administration networks. Addresses are provided in CIDR notation e.g. 10.1.1.0/24
- Login Banner – If you utilise login banners to provide appropriate warnings then configure that here
- Database – If you aren’t getting enough history of events in FMC as you’d like, then you may need to look at tweaking how many events are stored. I wouldn’t recommend adjusting this to begin with, but you may need this setting further down the line
- Email Notification – As configured in the section above
- Access Control Preferences – If you want to enforce comments in access policies to ensure changes are tracked then you can do so here
- HTTPS Certificate – If you have an internal PKI infrastructure then I’d recommend sticking a valid certificate on FMC to prevent certificate errors
- Intrusion Policy Preferences – Same as per the access control preferences above. Allows you to enforce comments
- Remote Storage Devices – Allows you to configure an external file server so that backups and reports can be saved off device. I’d strongly recommend configuring this – it will be no good having a backup on the server if it dies!
- Shell Timeout – Per best practices you can set browser/CLI timeout values
Critical with any system. You need to ensure you are backing FMC and the associated Firepower policies. Navigate to System > Tools > Backup then click on the Backup Profiles tab to setup a backup object. This will hopefully be pointing at an external Remote Storage Device (per the previous section) rather than the local system as pictured below.
If you are saving just to the local system, ensure you are regularly downloading the files and saving them offline. Alternatively, you can use the “copy when complete” option to backup locally and then SCP to an external server – just keep an eye on FMC disk space.
Once you’ve created and saved your backup profile, don’t forget to go and create a recurring scheduled task to automatically take care of backups going forward (System > Tools > Scheduling then Add Task).
Updates and Scheduled Tasks
If you navigate to System > Updates you will see there are three main tabs that enable different types of updates. These are summarised below:
- Product Updates – This allows you to update the images for Firepower services/FTD and FMC. You obviously want to keep these up to date as you would with any system. There is no option to just enable this automatically, however scheduled tasks can be used to achieve this should you wish
- Rule Updates – Enables IPS rule updates. This can be automatically scheduled on a recurring basis
- Geolocation Updates – Enables updates of IP to Geographical location mapping (which can then be used in access policies). Again, this can be automatically updated
A word of warning… the approach I see most customers take is to enable rule and geo updates automatically, but to take care of Firepower patches and upgrades manually. This makes sense. However, one thing I commonly see missed out is consideration for the Vulnerability Database (VDB) definition updates. VDB updates provide Firepower with mappings of operating system types to vulnerabilities. This is in addition to the IPS rule updates. Enabling auto rule updates does not take care of everything.
For most customers I recommend setting up the VDB updates as a scheduled task to take place out of hours. There are actually three separate scheduled tasks you will have to create to take care of this:
- Download VDB Updates – Downloads the latest files
- Install VDB Updates – The target for the installation will be FMC. Ensure you leave enough time between the download and install action
- Deploy Policies – Re-deploy policies to the relevant devices to ensure any changes are pushed
The VDB definitions aren’t published as frequently as other rules – maybe once or twice a month at most, so you are probably good to set this up for a bi-weekly or monthly job. I’d recommend a recurring date avoiding any business critical periods as there is always the chance of introducing new false positives with these types of updates.
Hopefully this article has given you some ideas on getting started with FMC and adding devices. In the subsequent articles we will look at actually configuring the Firepower device ready to start receiving traffic and then setup some of the various Firepower policies.
As always, any questions or comments I’d love you to get in touch!
2018-07-23 01:00 +0100