I started to title this a “Review” of the Cisco ASA with FirePOWER, but my objective is to highlight a few limitations of the integrated solution so that potential customers understand the product. It may turn out to be a review after all, but that’s the focus.
Let’s set some product context. Cisco completed its acquisition of Sourcefire on October 7, 2013, and its initial integration into the Cisco Security family on November 10, 2014. That makes this union very fresh–think of Cisco FirePOWER as newlyweds. They’re starting to share the same roof, but carry a lot of individuality and his/her domain around with them.
Next, let’s zoom in on the word, “Services”, or as you may see elsewhere, “Module”. Sourcefire makes a number of standalone, independent intrusion prevention system and application firewall appliances (i.e. 7000 series, 8000 series). When Cisco and Sourcefire united, they introduced the ability to put a dependent Sourcefire module into the Cisco ASA 5500-x next-generation firewall family. One Cisco partner described it as functioning like a virtual machine within the ASA (of sorts). Summation: it needs the host (ASA) to survive.
This “Module” should actually be packaged and marketed as a “Starter Kit” or an entry-level, feature-limited offering (with no building-block upgrade path; it’s a hardware ceiling). And perhaps it is by some Cisco VARs, but it’s new, so I think many are still coming up to speed with what it brings to the table.
To justify my above assertion, I’ll highlight four characteristics that have affected or disappointed me in my deployment, and that have motivated a new set of quotes to move to the hardware/standalone solution.
1. SSL Inspection
Oftentimes you don’t know what you don’t know and thus you lack the wisdom to ask about it. That was me with this feature. I didn’t know that the integrated module only supported a subset of features, so I didn’t know to ask about its ability to decrypt inbound SSL traffic.
We host a number of public HTTPS services, though, so one goal of implementing FirePOWER was to protect against intrusion via that conduit.
While reading the Online Help and attempting configuration, I ran across references saying that it was only supported on “Series 3” devices, yet I couldn’t quite find how Cisco categorized FirePOWER services. FireSight Management Center (a.k.a. “Defense Center”) also gives the illusion of hope in this matter, because it reveals all features as configurable, being that it can manage the largest of Sourcefire appliances. The rubber meets the road, though, when you try to apply a policy with SSL inspection to unsupported devices. And yep, the module is one of those.
Summary: SSL traffic remains cloaked to FirePOWER services. IPS can only treat the headers (read: source/destination IP and port).
2. User Control
This one was less important to me, but still an unfortunate discovery. FirePOWER (all devices) support “User Awareness” through LDAP integration and user agents installed on endpoints, but the ability to control traffic based on the identity of the user as another hardware-only feature. Thus, you can see who is doing what, but control must be applied through hardware or traffic identity, not user.
3. Fail-Close Design
I may butcher the explanation here, but because of the integrated nature of the FirePOWER module and services, if FirePOWER inside of an ASA firewall goes down (crashes, restarts Snort, etc), traffic through the ASA stops. This is regardless of the “sfr fail-open” command, which only practically applies to standalone appliances.
I discovered this with Cisco TAC on a Webex where they put the Sourcefire into software bypass to troubleshoot traffic flow and attempt to take it out of line. That didn’t work so well. Alarms and alerts started flying as the ASA clamped down on all new sessions (existing ones seemed to hold–very thankful as I was remote). Anyways, TAC didn’t know of this design either until they asked engineering about a potential bug and were told it was “by design”.
Major Warning/PSA: Adding FirePOWER Services to your ASA will introduce a new network availability risk. You will be very secure, though, since traffic will stop if the IPS is down. Blessing? Curse? Depends on you.
4. Bug: Active FTP is blocked by FirePOWER Services (CSCze96017)
Cisco was still working on this one when I closed my case regarding it, and their internally-published workaround wasn’t accurate at the time. The practical impact, though, is that Active FTP traffic is blocked by Sourcefire due to network address translation (NAT) confusion. The ASA handles it fine, but when the FTP server initiates the new data channel outbound to the client, Sourcefire gets confused and blocks it.
The workaround, which sounds like it may become the “solution” (not fixable), is to deny FTP traffic in your Sourcefire policy:
access-list Outside_SFR extended deny tcp any any eq ftp access-list Outside_SFR extended permit ip any any
class-map Outside-class match access-list Outside_SFR
policy-map Outside-policy class Outside-class sfr fail-open
Note: the last line still contains “sfr fail-open”, but it won’t apply until we replace the module with the full appliance.
This bug means that Sourcefire cannot inspect or provide any services (not even against IP headers) to FTP traffic. It will not show up in FireSight (Defense Center). Only the ASA will be able to treat it based on standard ACLs, etc.
Alright, let’s end on a high note. Apart from those four things, the Cisco ASA with FirePOWER Services solution works well, provides great insight, applies Advanced Malware Protection strongly, and shuts down a ton of illegitimate connections before they can attACK ;).
If you’re looking to get your feet wet, and if SSL inspection isn’t critical, I recommend giving FirePOWER a shot.