Our system has installed Cisco ASA 5525 X firewall with active-standby setting. We would now like to procure the FirePOWER service and deploy on the existsing firewall. However, we have concern what if the ASA firewall behave if the FirePOWER service is mulfunction? Would the traffic being by-passed the investigation? Or the ASA would able to detect the FirePOWER service is down and fail-over to the standby ASA?
Appreciate if anyone can advice. Thanks!
You can set it according to your requirements.
When you setup the service policy to tell the ASA to redirect selected traffic to the module, you can choose the behavior of “fail open” or “fail closed”. (i.e., continue to process traffic without inspection subject to all your other ASA settings or stop forwarding the traffic which was designated for inspection)
Additionally, the default for for an Active-Standby HA pair is to failover in the event of a service module failure on the Active member.
If the module on the Standby member fails it is (by default) marked as Failed as a candidate for Active status.
May I ask you a simple question?
I have two ASA5545X-IPS active-active, and I know that IPS SSM-20 module is EOL and the signature release will stop on April 2018.
Can I move to Firepower on the same chassis? If yes, how can I move the configuration to the FP?
I have to purchase the FP license or software to deploy on the chassis?
There is any disruption on the production traffic when we move to the new software?
Thank you in advance,
You need to add the SSD to each of your your 5545-X appliances for them to support the Firepower module. While adding an SSD can be done as a hot swap, you need to reload the ASA to make it initialize properly.
Yes you have to uninstall the old IPS modules and then install the Firepower service modules. It's all software (and licenses). Additionally we generally recommend you use Firepower Management Center to manage your policies and keep the modules' setting and policies synchronized. Just like the IPS modules, the Firepower modules in an HA pair have no idea that they are operating thus.
Unless you have done a lot of customization of your IPS rules it usually makes much more sense to just install the Firepower fresh and not worry about trying to migrate.
You can do all of the above non-disruptively if you plan it out carefully (and don't make any mistakes). However my strong advice would be to plan for an outage and schedule downtime nonetheless. That way if anything goes wrong your users are expecting some outage. If it all goes right then everybody wins.
If you have purchased Firepower services you will have access to download the image for a Firepower module. You can install it and run it unlicensed but will not be able to deploy any policies to it without at least the basic Protect and Control license (available for free from Cisco via your reseller).
You do require an IPS term subscription for the module to have legal right to use IPS policies. If you want to use the other licensed features (URL Filtering and Advanced Malware Protection or AMP) they also require licenses.
There is no publicly available trial license for the Firepower features. However, if you ask your reseller they can obtain a 30 day license for Proof of Value (POV) purposes. You can use that for testing purposes and to get familiar with the software.
I'd suggest you have a look at some of the many free training resources for Firepower - Cisco Live presentations, online videos from on Youtube and labminute.com are a few to get you started.
I haven't purchase any firepower services I only purchase IPS service for our ASA5545X. There is any possible ask cisco to able our account to download firepower services for the POV purpose?
Our actual license expires on 2019 as you can see:
Cisco Intrusion Prevention System, Version 7.3(5)E4
Realm Keys key1.0
Signature Update S1002.0 2017-12-05
Threat Profile Version 16
OS Version: 126.96.36.199
Serial Number: XXXXXXXXXX
Licensed, expires: 06-Aug-2019 UTC
Sensor up-time is 27 days.
Using 5154M out of 5549M bytes of available memory (92% usage)
system is using 34.9M out of 160.0M bytes of available disk space (22% usage)
application-data is using 93.2M out of 385.9M bytes of available disk space (25% usage)
boot is using 65.8M out of 77.1M bytes of available disk space (90% usage)
application-log is using 19.3M out of 513.0M bytes of available disk space (4% usage)
MainApp C-2016_02_08_08_56_7_3_4_11 (Release) 2016-02-08T09:02:59-0800 Running
AnalysisEngine C-2016_02_08_08_56_7_3_4_11 (Release) 2016-02-08T09:02:59-0800 Running
CollaborationApp C-2016_02_08_08_56_7_3_4_11 (Release) 2016-02-08T09:02:59-0800 Running
CLI C-2016_02_08_08_56_7_3_4_11 (Release) 2016-02-08T09:02:59-0800
* IPS-sig-S1001-req-E4 21:34:07 UTC Wed Nov 15 2017
IPS-sig-S1002-req-E4.pkg 21:26:20 UTC Fri Dec 08 2017
Recovery Partition Version 1.1 - 7.3(5)E4
Host Certificate Valid from: 01-Dec-2017 to 02-Dec-2019
Just to clarify, in my case, if we have Active-Standby HA pair, no matter I set "fail open" or "fail close" in the ASA, it will fail over to the standby firewall in the event of a service module failure on the Active member?
No. That is the default behavior but you can override that (since ASA software release 9.3(1)) with the command
no monitor-interface service-module
We usually don’t do this in production if we are using the FirePOWER module since we would want to ensure continued protection to the network.
More details on the feature can can be found here:
Instead of "Big-bang" deploying the FirePOWER as "Inline mode" to our existing network, I would like to operate the module as IDS first for a period such that I can monitor if any normal traffic being blocked unexpectedly before turning it as IPS. Should I operate the module in "Promiscuous mode"? Can I set it work like as IDS and allow the traffic flow through even intrusion detected with notification?
If the Firepower service module fails, you have the option of the policy to be "fail open" (keep passing traffic without Firepower inspection) or "fail-close" (stop until the module is restored to service). The latter is "secure" but also service-affecting.
The exact configuration stanza (if present) would be: