Introduction to Cisco ASA FirePOWER module

Last time we saw what type of modules ASA supports these days. Let’s now see a brief description of the newest member of the family – FirePOWER or SFR module.

This is software module which runs from a SSD disk drive inserted into our ASA 5500-X appliance. Please note the X in the name, because this is new generation of ASA appliances such as 5512-X, 5525-X, and so on. This module cannot run on previous ASA generation, such as 5520, for example. Beside the need of having the new generation of ASA boxes, we must have at least 9.2(2.4) version of ASA code to support this module. This applies to the first wave of new ASA boxes. For the newest members, such as 5506-X, we need to run 9.3(2) code. The SFR software must be at least 5.3.1 for models 5512-X through 5585-X, or 5.4.1 for 5506-X. The management server, called FireSIGHT or Defence Center, must run the same or higher version of code than SFR module.

The 5585-Xs run the FirePOWER in hardware module inserted into top slot of the ASA box.

Like with previous modules, hardware or software, this module operates in the same way: we match a traffic we want to inspect, then use MPF to forward this traffic from the ASA box to the module. On the module, we have set of policies that, depending on available licenses, check for various stuff and than send back the information to ASA whether to allow or drop the flow. This is important to have in mind: the module does NOT block the flow. It only instructs ASA to block it or not.

Depending on our licensing model, the SFR module can block and/or log traffic based on URL conditions, files being uploaded/downloaded, intrusion attempts, or just simple conditions such as TCP/IP parameters. In short, we have several licensing options available with the SFR:


We can have only URL filtering capabilities, or we can have only IPS capabilities. If we wanted more than just two of those, we could do that, but in that case the IPS license is required. For example, to have the IPS and AMP (Advanced Malware Protection) enabled, we have to have the TAM license. For all available functionalities, we need the TAMC license package.

The SFR module can be deployed inline with the regard to the traffic flow, or can passively monitor the traffic. The first case is depicted in the following Cisco’s picture:

13-Mar-2015 1-02-47 PM

Here we can see that the traffic coming to one interface is subject to ASA’s ordinary stuff, such as IPSec decryption, NAT and ACLs, before it gets sent to the SFR module. Depending on the verdict from the SFR module, the traffic is dropped or passed on to its destination interface. How do we send the traffic to the module? With the help of MPF. For example:

class-map SFR
 match any
class-map inspection_default
match default-inspection-traffic
policy-map type inspect dns preset_dns_map
message-length maximum client auto
message-length maximum 512
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 esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect ip-options
inspect icmp
class SFR
  sfr fail-open

In this example we created small class map that matches all traffic. Then inside of global policy, which is applied to all interfaces, we call upon that class map and send matched traffic to the SFR module with command sfr fail-open. The fail-open argument says that the traffic will continue to flow even if the SFR module crashes or is in process of upgrade and reboot. In some environments we may not allow this and we could say sfr fail-close to disallow the traffic flow through the ASA, while SFR module is not operational for some reason.

The other way we can use the SFR module is to only monitor the traffic. We will not be able to interfere with the traffic in any way, just to monitor it. The SFR module does not ask the ASA to drop the traffic, it just “applies” the security policies and logs events. If the traffic is to be dropped, the SFR module marks it as “would have dropped” in the log event.


We can see that the traffic keeps flowing, no matter what the SFR has to say. To enable this mode we would say:

class SFR
sfr fail-open monitor-only

in our MPF configuration.

The SFR can run in A/S, A/A or cluster ASA scenarios, as well as in routing or transparent modes.

In the following blogs we will deal a little bit more with this SFR module.


Thanks for reading.




This entry was posted in ASA, Cisco, FirePOWER, Firewall, IPS, Security and tagged , , , , . Bookmark the permalink.

2 Responses to Introduction to Cisco ASA FirePOWER module

  1. Pingback: Installing Cisco ASA FirePOWER software module | popravak

  2. Pingback: Sourcefire File Policies (aka Advanced Malware Protection) | popravak

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s