Which IPS Rules does Cisco Enable on your Firepower System? Think you know? You’re probably wrong!
So, think you know what IPS rules are enabled on your Firepower system, and do you feel comfortable with Cisco’s defaults and sleep well at night? This blog may just start keeping you up at night!
A couple weeks ago I was training/consulting at a very large school district outside of Columbus, Ohio. They have all 9300 NGFW’s to cover hundreds of thousands of students, so I immediately got to work on tuning these already configured systems, which a consulting company installed for them. They called me because their 10Gig links were saturated and they couldn’t find the problem, and also wanted additional training on their Firepower/FTD systems.
What I found upon arrival was the basic defaults of Balanced Security and Connectivity as their IPS policy, but worse, the consultants disabled the Security Intelligence (SI) completely saying it would bring down the network. That’s not true obviously, and the SI was a quick fix.
Question: Was their network secure because they had Cisco Firepower 6.3 code and the Cisco recommended IPS rules enabled on their systems? is your network secure by being configured this same way?
Let’s start by answering that question, and then I’ll circle back to how a Cisco FTD 9300 was brought to it’s knees (Never seen that before!), and how I solved this customers issues.
If you follow Cisco’s recommendations, your system will have both the IPS and NAP policies set to Balanced Security and Connectivity. Sounds reasonable, but will it protect you? Let’s take a look:
First, create a policy, and then choose to Create and Edit Policy:
Notice the Drop when Inline and the default Base Policy. When you’re first bringing up your system, the IPS policy needs to be tuned. I typically disable the Drop when Inline checkbox so the rules can be tweaked for the environment without dropping any traffic in the meantime. After a period of time (different for each network), I’ll enable the Drop when Inline and start dropping the bad traffic. However, let’s just concentrate on the Base Policy shown.
To understand what this does, start by going into your IPS police(s), scroll down to the Cisco base policy, then click on Rules:
Now open the Rule Content in the Rule accordion and scroll down to Rule Overhead as shown:
What the arrows show is which rules are enabled by default with each policy – click on each Overhead (Low, Medium, High, and Very High) to see which are enabled and disabled. I am not making this up, Cisco’s way of choosing which rules are enabled is only decided by Rule Overhead. They should just change the Overhead names from Low to Connectivity over Security, from Medium to Balanced Security and Connectivity, and High to Security Over Connectivity, and make it easier on us. (reality check here: it’s unlikely they use overhead only to make a rule determination, but there is no documentation to say otherwise [yet], so here we are).
For example, and to demonstrate what I am saying; if you choose the useless Connectivity over Security base policy, then only the Low Overhead rules are enabled as shown below, or about 500 rules, with all other 35,000+ rules disabled:
Next, the default of Balanced Security and Connectivity enables the Low and Medium Overhead rules, which again, is Cisco’s recommendation. Add up the Low and Medium Overhead rules, that is the amount of rules enabled. Period.
With Balanced Security and Connectivity, the High and Very High Overhead rules are all disabled:
Now understand that f you choose the Security over Connectivity policy, then the Low, Medium, and High rules are enabled, which gives us now 15,493 enabled rules (in this example).
However, none of the three policies I’ve mentioned would ever enable a Very High overhead rules, which means that 21,498 rules are disabled by default,.
If you double click on any of these disabled rules, you can see they are Very High overhead
So if you are using the default IPS policy, you’ll then ask yourself: “But what about this zero day attack that is occurring, and Cisco IPS rules just downloaded automatically; these important rules must be enabled by Cisco, so I am safe and secure, yes?” No, not unless all the rules imported are Low and Medium Overhead. The High and Very High Overhead rules are imported to your system, but they are disabled by default, even if the rules are all-so-important!
So, how many rules do you have available?
You can see the amount of rules on your system by going to the Rules option (click any of them) in any policy with no filter, which is 37,426 in this example:
By looking at the IPS policy summary, I have 10,514 rules enabled by default (the amount of low and medium overhead rules found on the systems). This means over 25,000 rules are disabled. Cisco’s reasoning for this default recommendation is that you need low latency. True, but my customer had $1.2M dollar NGFW’s that can easily handle tens of thousands of rules enabled! Even with 2110’s you can enable thousands more and be just fine.
You may be saying “Well Cisco knows what they are doing, and if they never enable a Very High Overhead rule, then neither shall I.”
Let’s go take a look at something. Shown here is a Rule update that came into my FMC (Rules are released twice a week – Tuesdays and Thursdays, so on Wednesday and Friday mornings you should be checking these!).
In this example, seven rules changed, and 35 rules were added. Seems that if Cisco added these, they might be important. So why are the first four rules here disabled? Because they are not important? No, they are very important, they are just Very High Overhead.
Is your network better off with Security over Connectivity as a base policy? Sure, but it can still be better. “Can I just forget about it then”, you ask? No, but you probably will, as most of my customers do. It’s better to go in twice a week and look for the new downloaded rules and enable the Very High overhead rules you think are needed for your network. But again, most of my customers only do this for a few weeks after I leave; just like when you go to the gym the first two weeks of January…you mean to go back to the gym, but hey, you’re busy!
Can My System Handle Security Over Connectivity (SoC)?
There is a caveat here. If you have xx40/50 (or the new 41×5’s!) or even 9300, enabling another 5-6000 rules going from Balanced policy to Security over Connectivity (SoC) should not cause you any issues, but maybe you just don’t feel comfortable changing from Cisco’s recommended settings because you know you’ll never login and check it.
Regardless, there may be a use-case for enabling the larger number of rules for a short time on any system without stressing or losing sleep, just to verify your data, then set it back to Balanced if you feel this will lower your stress level.
Understand that enabling a very large amount of rules for the long term may not be a good idea as you may see many of these rules ignored due to PPM (packet latency). This can be found in the Advanced tab of your ACP:
Since the PPM will make sure you don’t have latency when you enable more rules, why not just turn all the rules on? Because you will not get complete inspection, that’s the key. You think you’re getting better inspection but in fact, Snort is bypassing traffic to keep the latency low. Keep this in mind, especially when using lower power systems.
Important TIP! Lastly regarding enabling more rules:I always tell my customers that if you want to enable rules manually, that’s great! But, you also need a regular process, maybe once every 6 months, where you go back and disable the rules you don’t need anymore.
What about Firepower Recommendations?
So, if you use Firepower recommendations, first make sure your FTD box is North-South traffic (or don’t use this at all!) or Firepower will probably disable most of your rules. To match your SoC policy go to the Advanced configuration and move the slider bar to High, so that the Low, Medium and High Overhead rules will be enabled, because as usual, only the Low and Medium rules are enabled with Firepower.
Although you can still make your network more secure, this is still a lot better than the defaults.
But There is Still One More Setting: MAXIMUM DETECTION
I know this is a long post, and most of the people will never read this far, but if you did, you might as well keep going now!
The mostly unused Maximum Detection is an odd bird and must be tested on your network with the Drop while Inline disabled for a quite a while.
(UPDATE: This rule was update 5/2/19 and now has about 28k rules enabled, so I need to do a blog on just this policy soon)
This policy is the only one that enables some Very High Overhead rules; 5784 to be exact (as of this writing). However, it disables thousands of High Overhead rules that would normally be enabled with Security over Connectivity. I’ve never used this policy in production, nor do I know any customers that have, but again, you can use this, but just test it – and then please let me know what happens!
Saturated 9300
Lastly, what about my customer in Ohio and the 9300 that was brought to its knees? Yes, once we moved the IPS policy to a base of Security over Connectivity, we found the problems they were having quickly. The IPS events started triggering about 6000 hits a minute after we deployed, and the CPU on the 9300 spiked to over 80% as it was trying to process all the IPS events. That’s a LOT of high overhead events to do that to a 9300! The FTD 9300 was no longer passing data…wow, not only have I never seen this, I’ve never even heard of this!
After we were able to do some analysis on the new IPS events (which got to over 100,000 in just a few minutes!), I had to verify these weren’t false positives and then find the culprits. Drilling down, we found that their entire server farm was infested heavily with CnC’s, and only the High Overhead rules found these CnC’s. Those attacks were so well drilled into these servers, they each had thousands of connections, which would explain the bandwidth issue! We immediately started blacklisting these servers and the CPU percentage dropped to less than 10%, and the bandwidth saturation went from 80% to less than 20%!
The customer feared that they had these attacks on their systems for possibly years….and what found them? It wasn’t the Cisco default settings…
The customer had some serious issues on their servers to fix, but my job here was done.
If you do set the Security Over Connectivy IPS policy, you should match the NAP with the same policy! I’ll cover that in another blog
Great post!! Thanks Todd!!
That you, Sam!
That was really awesome…
We are using Balanced Security and connectivity with Firepower Recommendations enabled. Could you please advice which custom IPS rules (apart from default enabled) we should enable in production environment.
I’d have to look at your network and understand your application flow before the can be decided
I think that if you turned on Security over connectivity, you’d get more events to you can tune your IPS policy faster and more efficient for your network.
Thank you for your reply.. We can try this to fine tune our IPS rules.
Thanks for the sharing. great post, you did.
I will probably test the “maximum detection” on my vFTD before to configure them on four 4120s Firepower. I just wonder that I will hit a high CPU usage with this conf
depends on your user data amount. the maximum doesn’t turn on as many rules as I will! :)
Hey Todd, Do you advise to turn on 134:1:1 to report on Aborted connections? I turned it on for a week and am finding that its great for learning some stuff, but not going to leave it on permanently.
Thanks for the heads-up, Evan. I’ll turn that on in class this week and get some feedback!
Evan, I don’t get much events with this. What applications did you use to get this to trigger?
I am confused by this article. In the past I have always seen:
Connectivity over Security: ~ 500 Rules
• CVSS Score of 10
• Age of Vulnerability: 2 year and newer
Balanced : ~ 7200 Rules
• CVSS Score of 9 or greater
• Age of Vulnerability: 2 year and newer
• Rule category equals Malware-CnC, blacklist, SQL Injection, Exploit-kit
Security over Connectivity: ~ 10000 Rules
• CVSS Score of 8 or greater
• Age of Vulnerability: 3 years and newer
• Rule category equals Malware-CnC, blacklist, SQL Injection, Exploit-kit, App-detect
Is this still the case? How does this tie in with what you are stating? I have been helping our NOSC personnel with the FMC, I just want to make sure I am telling them and management the right info.
so these change every week.
can you tell me where you are seeing this CVSS score on a cisco authored IPS policy?
my article is showing me how they choose rules, and it is based solely on overhead. however, you can change a rules overhead which they may or may not do…
the sOC is about 500 rules as you state, and this rarely changes. The BSAC is about 9k rules now, the SOC is about 15k rules, and the new Maximum detection is about 28k rules on with the latest updates.
Marty, I found it. That was from Cisco internal technote. However, that note is from 2014 and not valid any longer. it doesn’t work that way now. They said they were going to update that document since it is 5 years old now!!
Ok, that’s good to know. I actually got that information from a Cisco live presentation I watched not so long ago. I was fairly comfortable with them basing recommendations on CVSS scores, I need think about this new method. Thank you for the time, I appreciate your explanation.
So I talked to Talos after your first post, and they said they were going to update that document. Probably will have it at Cisco Live I imagine….
Cisco updated the document, even though the balanced policy information isn’t accurate, they needed to make this clear. I’ll be updating a video blog on this
https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/214405-what-are-the-metrics-used-to-determine-t.html
they are also going to rename the overhead folders to the name of the policies as I suggested in this blog, to make it clearer…glad that they are starting to document and let us know how this works internally.
Thanks for the update. I hadn’t seen an official document covering this before. I read through your update, good stuff. Thanks again, I hope the book is good reading :-)
I just updated this post here: https://www.lammle.com/post/which-ips-rules-does-cisco-enabled-on-your-firepower-system-think-you-know-part-ii/
Cisco responded yesterday LOL
When looking at Firepower recommendations, do you recommend checking the option ‘Accept Recommendations to Disable Rules’?
No, because I never recommend using Firepower recommendations. You need to tune the IPS policy yourself and make it more efficient. Firepower recommendations are for people that would never login to their system all year long….
We have a 5506-X managed by a virtual FMC. I noticed that I have the default settings of Balanced Security and Connectivity with drop when inline checked. I was going to modify this to Security over Connectivity. If I do that, should drop inline be checked? It sounds like I should leave it unchecked for a while. Small network, <30 users.
Take off the drop while in line for 2-5 days and see what would have been dropped, and then tune out the ones that shouldn’t. Won’t be much with your small network, but you need to do this!! Let me know how I can help
Todd
Before I changed to SOC, I noticed a malware-cnc event (sid 37215) occurred while still on BSAC with drop when inline checked. This event is set to drop and create event with BSAC. However, the inline result was would have dropped. Do you know why the event was not dropped?
Two reasons it didn’t drop.
1. it didn’t receive the whole file in time so it “would have dropped” had it received the full file
2. it hit another IPS policy in a rule that is set to not drop while inline
Understood. Must be reason 1 because I only have one IPS policy. Also, I’ve been running for 48 hours on SOC and have zero intrusion events. Can I assume at this point, I can re-enable drop when inline and keep an eye on the events for a few more days just to be sure nothing legitimate gets caught?
I would! Seems okay at this point, just keep an eye on it
thanks,
Todd
I appreciate your help on this Todd. Thanks again.
Still no issues with IPS policy setup for SOC and drop when inline. However, I noticed on my Default ACL the default action at the bottom is BSAC. Should I change this to SOC as well?
depends on what the rules are above. Most of mine are deny/deny/deny, some details permits, and they an allow any inside>outside, and then the default action is block all. if they are hitting your default action, then yes. You can see which rules are hit in connection>Events>Table view
Hi Todd, first of all thanks for the post. You know following you everywhere.. jk
Quick questions, lets say if i have my Fp 4100 series running in Passive mode, what Policy should i set? At present i have this set to SoC. But I am seeing like thousand of events. Tuning every one of them is more of a headache now and the reporting for the Intrusion events to my customers are not very helpful because i can not give them a week report full of millions of events. Should i make it to BSec?
No, I would not do that. You are seeing issues, but you’re not dropping anything. What you should do is tune those rules and then make that an inline pair where your dropping bad packets…however, I don’t think you’ll do that or you would have already. I’d leave it as SoC, and then create a report (which is not that hard to do), and send the customer this report showing them all the attacks getting through because you (or they) are running in passive….at a minimum you should cover yourself by showing them what you are letting through and advise them that you should be blocking these…but then again, I don’t know enough of your environment to give you all this advise, I am just guessing based on my experience! :)
Todd, when looking at the rule updates in the intrusion policy, why are some rules set to generate and drop events, while others are disabled? What’s a good way to judge what to enable?
Always a good question, but there is not a single answer, its different for every customer I go to.
So I have some blogs on this, and my new CCNP Security book out next month covers this in depth as well, but look for a blog titled “Which IPS Rules are enabled by default” on lammle.com…
The best thing is to turn on a base policy of Security over Connectivity (SoC) with Drop while Inline OFF, and then tune your system…
Basically the SoC turns on low, medium and high overhead rules, which is based on overhead for sure, but also other important factors such as CVE, as discussed in that blog post.
Hope this helps!
Todd, how in the world do I cross-reference a block event (within the connections events) to a Rule/Snort rule?
All the “block” event says is that it was blocked by Default Action rule which I do understand that it means none of my rules matched this activity and it was dropped by this last default rule. The Network Analysis Policy says it is from my IPS “Balanced Security and Connectivity”.
I’m just trying to know which rule from my Intrusion Policy this event hit. The event details doesnt tell me the SSID or anything like that…. or I just dont see it.
My apologies for jumping into this thread like this, but I’ve been researching on this for the past few hours and no luck…
Thank you in advanced
ap
Angel, there is no single or easy answer. You need to do correlation of events by going through the network analysis steps. You should be able to see the IPS events in Analysis>IPS Events, but you need to be able to read the data.
Unfortunately, the cisco firepower system is great, but you need to learn how to tune it. I highly recommend the video series on my site, and also my latest Cisco Firepower book. http://www.lammle.com/firepower
https://www.amazon.com/CCIE-CCNP-Security-SNCF-300-710/dp/B086Y2YWFF/ref=tmm_pap_swatch_0?_encoding=UTF8&qid=1588467095&sr=8-3
Hi Todd, Thank you for the response. I went at it last night and even called TAC. They argue that because the traffic is not getting matched against any allow/denied rule, it hits the bottom “Block All Traffic” rule without being inspected and this is also why there is no events in the Analysis>IPS Events.
I really dont know whether or not this is true because in the Analysis>Connections Events, the “block” action shows few details and one of them, under the Network Analysis Policy column, says “Balanced Security and Connectivity”.
So which one is true? If a packet finds no match rules, then it will hit the “denied all” and will just be dropped without further inspection?
Or is the packet, even thoug it has landed on the bottom default “denied all” rule, still inspected agains any of the IP rules? If so, I want to know which one of the 11K rules was matched so I can fine-tune the IDS/IPS system.
Thank you again sir. I am actually purchasing your book as we speak…. you read my mind as I was just looking for good books in Amazon… I only had one, the Cisco Next-Generation Security Solutions (All-in-one Cisco ASA FirePOWER Services, NGIPS, and AMP) but I need a lot more details on FirePOWER as we have around 25 sensors we are managing….
you have 11k rules in your ACP and your packets don’t match them?
Angel, you need my book, and only that one as i JUST came out and is the newest (and best by far)….but I gotta tell you, it would be best if:
1. You can attend my course online (4-days)
2. you can get some consulting dollars and I can help you get this fixed
3. Get a membership to lammle.com so you can get through all the training
if you have 25 sensors and they won’t buy you any training???…you are being setup for disaster.
The Firepower is AWESOME, just not out of the box!
I can show you how to tune this, either with my class or consulting, or better to get both if you can!
If you get my book, that’s great, but its 1800 pages of intense material. If that’s all they’ll give you that’s really sad. They are hurting their business and obviously have NO security.
Let me know how I can help
Todd
Hey Todd, our 4110 has 3 inline sets.(DMZ,LAN and INTERNET). What happens if traffic coming from internet inline set and goes to the dmz inline set then the single traffic inspected 2 times ? In addition do you think if we make single inline set containing dmz, lan and internet interfaces then the traffic would be inspected one time ? My goal is to not the inspect the traffic more than 1 time and not cause any overload on cpu and memory.
Thanks,
John
That all dependes on your ACP rules. TRaffic coming from the DMZ shoudl be inspected, regardless of where it originated from.
are you using transparent mode, is that why you created inline sets?
Firewall is in transparent mode, you are correct. Our Cisco SE mentioned about the question I asked you.
Cannot really wrap my head around how FP recommendation gets generated?
In my FP recommendation report.
1)There are certain rules for which there is no recommendation generated at all (all of them having base policy action as disabled).
2)For some rules which are already disabled in base policy FP recommendation was to disable them.
What is the logic applied here? Have gone through the config guide , but it does not make sense.
you need a base policy, for one. You need a Firepower Network Discovery policy for another.
without either of those, you won’t get Firepower user data.
You need to go through lammle.com Firepower training, look for the Firepower Network Discovery policy.This will help you.
Then you can do Firepower recommendations, but even then I don’t recommend using Firepower recommendations. My videos will explain why.
Sure. Thank you for your reply.
Just wanted to say this was an awesome blog. It really helped me to set up our new edge FirePowers and prompted me to go straight for the Security over Connectivity policy. We had one or two problems with some customers SFTP traffic being blocked but once we’d fine tuned those rules we’ve never had anymore problems. I’d also never heard of Security Intelligence until I read some of your blogs and I can’t believe how much traffic gets blocked by that alone. I’ve recently added the SI URLs too which started picking up even more straight away.
Absolutely brilliant bits of kit! Thanks again for these blogs!
This is great to hear! Don’t forget to also do the DNS SI feed. You have to do that through the DNS policy.
SI stops well over 50% of issues before they even hit the ACP! So needed!
I have some videos on lammle.com as well as some books on the subject as well if you wanted to get more detail on the tuning.
Thanks for writing!
Todd Lammle
Thanks for the information provided! we will use this information into our GPT/Chat-GPT dataset