Shortcomings of Cisco ASA 5500-X with FirePOWER Services

firesightsplashI 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

firepower_ssl_reqOftentimes 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.

sfr_user_control_req

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.

22 Comments

  1. Z0lt4r said:

    Thanx for this!

    I’m hitting the fail-open “design feature”, and I’m banging my head against TAC to get an answer/fix.

    Now I know that the fail-open does not work as expected, and can continue troubleshooting with this in mind.

    April 28, 2015
    Reply
    • Chris said:

      Absolutely! Yeah, the options now are to create policies that “Trust” the traffic or else policy maps that deny it being sent to SFR. Good luck!

      April 28, 2015
      Reply
  2. Leon said:

    Hi,

    I thought I’d provide a few comments that aim to provide some clarity. I did include a valid email while posting in case you have any follow-up questions.

    SSL: “I ran across references saying that it was only supported on “Series 3″ devices, yet I couldn’t quite find how Cisco categorised FirePOWER services.”

    We could have probably provided a link to what devices are classified as ‘Series 3’ in that area of the documentation, however there is however a full table listing product numbers, device types and the ‘series’ value in the “Summary of Supported Capabilities by Managed Device” section. It’s also in the online help, but to save you looking it up, FirePOWER 7000 and FirePOWER 8000 devices are all ‘Series 3’ FirePOWER devices. Those appliances support SSL decryption in multiple modes in 5.4.1 as standard (it’s not an extra feature you need to purchase).

    “Summary: SSL traffic remains cloaked to FirePOWER services. IPS can only treat the headers (read: source/destination IP and port).”

    Without decryption, the expected constraints of looking at an encrypted stream will apply. ‘Attack detection’ (IPS) takes place against the service/client itself as part of the service initiation, take a look at any rules that are focused on SSL vulnerabilities for more info. In addition, further detection is also applied where applicable. Application ID can commonly (depends on the app) be detected based on details in the SSL Certificate, e.g. CN=api.someapp.com. In addition to Application ID, all of the security intelligence and web reputation/categorisation against details are applied to data that can be taken from the certificate. IP based security intelligence is obviously applied as well.

    User Control:
    While user identity can be detected via multiple methods, however for the purpose of access control we only use an authoritative source of identity. There are multiple good reasons for this, but I won’t go into them here because of time. Authoritative data comes from integration with Active Directory, and you don’t need to have software on all clients for this. A good overview of how it functions is included in the ‘User Agent Configuration Guide’. Once you have that installed on the network (note that it does *not* need to be installed on a Domain Controller), you can control traffic by user identity, application ID, application type, business relevance and many many other things as well.
    This is supported on FirePOWER Services (including your ASA5500-x) as well as the dedicated FirePOWER models.

    -L

    April 29, 2015
    Reply
    • Chris said:

      Leon & others following this,

      Apologies for the late reply. Since this post, we’ve migrated off the integrated FirePOWER modules and onto new Sourcefire 3D7030 appliances to address the items I covered.

      As you mentioned, the “Series 3” reference means 7000 and 8000 series devices, which I had found at the time of writing, but didn’t elaborate enough to mention. My point was that the documentation wasn’t clear enough at the time to help customers understand what they were (or weren’t) purchasing.

      What you expounded upon in the SSL traffic point is true. My point was simply to explain that the decryption feature that is only available on Series 3 devices was essential to my use case. As such, the FirePOWER modules were quite impotent to inspect and protect my web application traffic. I didn’t expect the IPS to magically see inside SSL traffic without it, but we did have the incorrect impression that FirePOWER would be able to inspect/decrypt given our certificates.

      For User Control, I misunderstood the requirement to install user agents to mean that the agents needed to be on user endpoints (see the last section of http://www.cisco.com/c/en/us/td/docs/security/firesight/541/firepower-module-user-guide/asa-firepower-module-user-guide-v541/AC-Rules-User.html). However, with regards to the “Control” aspect, I rechecked the Online Help from the FireSight Management Console and am updating the post above with the table that specifies that User Control is supported on “Any devices except Series 2 or X-Series”, which would seem to include FirePOWER modules.

      Gunny, I think the FirePOWER modules are a fine product, but they need the proper qualifications for where they do and don’t fit. It’s also a relevant point that in our deployments of FirePOWER and the 3D7030’s (by Presidio, no less :), FirePOWER was in-line outside the ASA while the 3D7030’s were in-line inside the ASA. Perhaps the former could have been implemented like the latter now is, but the hardware implementation is definitely more efficient (no need to IPS inspect traffic that will be cleanly blocked by normal ASA rules).

      Thanks!
      Chris

      July 23, 2015
      Reply
  3. Jacob said:

    Excellent write-up and comments. Thank you!

    July 5, 2015
    Reply
  4. Gunny Fitz said:

    Chris, I am curious to your response to the well crafted reply from Leon, whom I suspect is an engineer or serves a similar role at Cisco. I work in marketing for a top-ranked VAR and am hosting an event on the Cisco ASA product next week. Since I graduated in 1991 with a BFA in Fine Art, I am not in the least bit competent to decide if Leon provided a proper rebuttal to the shortcomings you described. Would you indulge me in a response, please? It matters to me that we present an accurate portrayal of the product in use.

    July 23, 2015
    Reply
    • Chris said:

      Hope the reply above helps! You work for a good shop; our account team at Presidio is excellent.

      July 23, 2015
      Reply
      • gunnyfitz said:

        Thanks for the prompt reply and the shout out for the team at Presidio. I would love to say I understood “IT” but, alas, that was not my gift.
        Count me as a new fan!

        July 23, 2015
        Reply
  5. asad said:

    Your discussion here , is a life-saver you mastered the art of decrypting big vendors technical jargon from marketing verbatim. I’m researching a model, where I have dedicated firepower appliance (series 3) that alone does the job of ssl inspection (all in one box). For that I think both ips engine rules/sigs have to be in same box, and unencrypted traffic doesn’t leave the box.

    Does the Firepower appliance have ability to re encrypt traffic out of its interface?. Thanks.

    August 1, 2015
    Reply
    • Chris said:

      asad,

      The FirePOWER appliance doesn’t proxy or bridge the connection. Rather, it taps it and uses available SSL certificates loaded into it to read/assess the traffic. Thus, it doesn’t need to re-encrypt the traffic because it effectively copied it and discards its copies after assessing. It all happens in the same box.

      One thing to make sure of is the software version of Defense Center and the appliances. Both need to be 5.4 to support SSL inspection.

      Thanks,
      Chris

      August 2, 2015
      Reply
  6. Pong said:

    I have heard whispers that the next version release for FirePOWER Services has SSL inspection.

    August 13, 2015
    Reply
    • Chris said:

      Interesting. It would be totally possible; the only limitation as I understand it is resources if too much inspection is taking place for the module to handle.

      August 14, 2015
      Reply
      • troybob said:

        SSL Decryption is released as of last month.

        December 8, 2015
        Reply
        • Chris said:

          Good luck on trying to implement it, even if it is supported. We found that even separate, dedicated hardware couldn’t handle the load of IPS, AMP, and SSL. Keep an eye on memory usage and packet latency/loss after turning it on.

          December 8, 2015
          Reply
  7. Chris said:

    An update you might be interested in: regardless of what the engineer said long ago, it seems that fail-open blocking traffic was indeed a bug as it now will allow traffic to pass when the module is offline. Traffic doesn’t get blocked for me when I shutdown the module or update it using 9.4 on the ASA.

    August 17, 2015
    Reply
    • Chris said:

      Great to hear, Chris. Sounds like Cisco’s default response was “by-design” and when enough push back came, or a proactive developer finally engaged, they recognized it as a bug (or bad design) that it was.

      Interestingly enough on our end, our newly deployed 3D7030’s are turning out to be underspec’d and can’t handle the load of running IPS (Snort), AMP (malware), and SSL inspection. Blows the cap on memory usage. So we’re back to the drawing boards, again…

      August 18, 2015
      Reply
  8. Rotex said:

    HI Chris,

    Need a little clarification on point 2 (User Control). We currently have a proxy service hosted on Microsoft platform whereby we are able to control who access the internet at a particular time, which url the person accesses etc. We intend to decommission this proxy services on the microsoft platform, we are planning to procure a ASA firepower.

    My question is, can the asa firepower also be able to achieve this type of granular control on users accessibility to the internet. The one we currently do on the microsoft proxy server.

    October 13, 2015
    Reply
    • Chris said:

      Regarding User Control, as best I can tell, Sourcefire will not address your use-case (time-based restrictions). The access control parameters appear to be transport-based (user, source, destination, protocol, URL) only. While Sourcefire provides URL restrictions, I see this primarily focused on the security context and not as much on the business productivity context (i.e. preventing social media, etc). I do see that timing is related to security (some staff should *not* be crossing perimeters outside of their hours), but as of FSMC 5.4, this doesn’t seem to be a policy option.

      If others in the field (or Cisco) have more accurate knowledge or experience with this, I welcome correction. A review of the documentation just now and my own FSMC console, though, doesn’t appear to allow it.

      If you only need to restrict URLs, that *should* work, so long as you have LDAP configured and user agents installed on all devices.

      October 14, 2015
      Reply
  9. Hi Chris, I know I’m late to the game, but I wonder if you can answer a couple of questions. Our Cisco vendor was a little vague about both of these topics, and I wasn’t able to figure them out from the on-line documentation. Would an ASA 5506 with FirePOWER allow me to block URLs that start with an IP address rather than a hostname? Lots of malicious emails deliver links that have an IP address in them. Also, how good is FirePOWER at blocking ad servers? I was hoping to be able to bulk-upload a list of known hostnames and IPs for ad servers the way I currently do with our Squid / DansGuardian proxy server. Our rep says you can’t do it, but he thinks that Cisco has their own blacklists that they use. Thanks.

    August 10, 2016
    Reply
    • Chris said:

      Hi Alex. I’d be pretty wary about trying to run anything other than the basic IPS functions of FirePOWER on a 5506-X. From what I read in the online docs (lower half of http://www.cisco.com/c/en/us/td/docs/security/firesight/541/firepower-module-user-guide/asa-firepower-module-user-guide-v541/AC-Rules-App-URL-Reputation.html), your best use case for URL Filtering with FirePOWER is to use Cisco’s categories. Otherwise, you are limited to 50 entries, which would likely be insufficient for your bulk upload of hostnames/IPs. I also do *not* see any rule for blocking URLs with IPs instead of FQDNs. Since FirePOWER also only looks at the base FQDN, it also seems easy to subvert (see the “Limitations” section at the bottom of the online guide).

      Nutshell: It can’t hurt to give Cisco’s categories a try and see how they perform for you, but if you require a robust solution, consider one of the leaders in that space (back when I looked at it in 2010-ish, that was BlueCoat and WebSense).

      August 17, 2016
      Reply
  10. Barrett Cowan said:

    Alex, when you state “Would an ASA 5506 with FirePower allow me to block URLs that start with an IP address rather than a hostname?”, the answer is simply, yes. Keep in mind, a URL can contain either an IP or FQDN, it just depends on what FirePower service you would like to filter (block/accept) it at. You don’t need FirePower for that, the ASA can do that with ACLs. Furthermore, you’ll find, Security Intelligence (SI … fka Botnet) will block the majority of the malicious IPs, URLs, and DNS requests already (when properly configured of course).
    As far as FirePower’s capability with ads, you’ll find it’s just as capable as any other web filter out there. Your rep was correct on bulk uploading IPs or URLs to create objects within FirePower, that’s just not a feature yet (yeah, I know, it frustrates me too), but this can be done through SI feeds, which is just another area to whitelist/blacklist IPs & URLs. As a side note, SI is processed before anything else. Of course, to leverage URL & app filtering to its fullest, you’ll need to utilize SSL decryption.

    September 27, 2016
    Reply
  11. Matt Melick said:

    Yes, information like this is often understated by VARs and later found after the purchase. These type of write-ups are of great value. Thank you for the contribution.

    October 10, 2016
    Reply

Leave a Reply