Todd Lammle, LLC https://www.lammle.com Cisco Security Training Wed, 15 May 2019 10:03:29 +0000 en-US hourly 1 Cisco Firepower FastPath, Blacklist & White list. What does that have to do with the Dreaded Pirate Roberts from Princess Bride? https://www.lammle.com/post/cisco-firepower-fastpath-blacklist-white-list-what-does-that-have-to-do-with-the-dreaded-pirate-roberts-from-princess-bride/ https://www.lammle.com/post/cisco-firepower-fastpath-blacklist-white-list-what-does-that-have-to-do-with-the-dreaded-pirate-roberts-from-princess-bride/#respond Fri, 17 May 2019 21:15:01 +0000 https://www.lammle.com/?p=49723 The Todd Lammle Cisco Firepower TidBit provides cool features of Cisco Firepower/FTD in just a couple minutes! Cisco’s Firepower/FTD FastPath, Blacklist & White list. What does that have to do with the Dreaded Pirate Roberts from Princess Bride? Watch move Tidbit Of the Day (TOD) to find out!    

The post Cisco Firepower FastPath, Blacklist & White list. What does that have to do with the Dreaded Pirate Roberts from Princess Bride? appeared first on Todd Lammle, LLC.

]]>

The Todd Lammle Cisco Firepower TidBit provides cool features of Cisco Firepower/FTD in just a couple minutes!

Cisco’s Firepower/FTD FastPath, Blacklist & White list. What does that have to do with the Dreaded Pirate Roberts from Princess Bride?

Watch move Tidbit Of the Day (TOD) to find out!

 

 

The post Cisco Firepower FastPath, Blacklist & White list. What does that have to do with the Dreaded Pirate Roberts from Princess Bride? appeared first on Todd Lammle, LLC.

]]>
https://www.lammle.com/post/cisco-firepower-fastpath-blacklist-white-list-what-does-that-have-to-do-with-the-dreaded-pirate-roberts-from-princess-bride/feed/ 0
How, Why & When you would use a pass rule in a Cisco Firepower Intrusion policy (IPS) https://www.lammle.com/post/how-why-when-you-would-use-a-pass-rule/ https://www.lammle.com/post/how-why-when-you-would-use-a-pass-rule/#respond Fri, 17 May 2019 04:50:24 +0000 https://www.lammle.com/?p=49698 This TidBit of the day will provide cool features of Cisco Firepower/FTD in just a couple minutes! So I received this questions from a reader: What is the best easy way to exempt a host or network from a specific snort signature/rule?  I want to prevent traffic from being dropped if the source IP is…

The post How, Why & When you would use a pass rule in a Cisco Firepower Intrusion policy (IPS) appeared first on Todd Lammle, LLC.

]]>

This TidBit of the day will provide cool features of Cisco Firepower/FTD in just a couple minutes!

So I received this questions from a reader:

What is the best easy way to exempt a host or network from a specific snort signature/rule?  I want to prevent traffic from being dropped if the source IP is 10.1.1.10 even if it matches the Rule SID 38678 signature. All else still inspect and drop if the signature matched.

This is a great question, and one I receive a lot. I find that admins, in order to meet this business requirement, use the Suppression filter in the IPS policy, however, that just stops you from getting an alert and still drops all the traffic! You just would never know….This accomplishes nothing! You’d be better off disabling the rule.

Suppressing a rule is just this:

So let’s take a look at the How, Why & When you would use a pass rule in an Cisco Firepower Intrusion policy (IPS)

 

Caution: When an original rule that the pass rule is based on receives a revision, the pass rule is not automatically updated. Therefore, pass rules might be difficult to maintain.

Verify

You should monitor the new events for some time in order to make sure no events are generated for this specific rule for the defined source or destination IP address.

The post How, Why & When you would use a pass rule in a Cisco Firepower Intrusion policy (IPS) appeared first on Todd Lammle, LLC.

]]>
https://www.lammle.com/post/how-why-when-you-would-use-a-pass-rule/feed/ 0
New Cisco Firepower Best Practices Book by Alex Tatistcheff, now available! https://www.lammle.com/post/new-cisco-firepower-best-practices-book-by-alex-tatistcheff-now-available/ https://www.lammle.com/post/new-cisco-firepower-best-practices-book-by-alex-tatistcheff-now-available/#respond Thu, 16 May 2019 21:42:10 +0000 https://www.lammle.com/?p=49692 The post New Cisco Firepower Best Practices Book by Alex Tatistcheff, now available! appeared first on Todd Lammle, LLC.

]]>

The post New Cisco Firepower Best Practices Book by Alex Tatistcheff, now available! appeared first on Todd Lammle, LLC.

]]>
https://www.lammle.com/post/new-cisco-firepower-best-practices-book-by-alex-tatistcheff-now-available/feed/ 0
How to find a hidden graph that shows your Cisco Firepower IPS “Would have Dropped” events https://www.lammle.com/post/todd-lammles-cisco-firepower-ftd-tidbit-of-the-day-tod/ https://www.lammle.com/post/todd-lammles-cisco-firepower-ftd-tidbit-of-the-day-tod/#respond Thu, 16 May 2019 19:22:28 +0000 https://www.lammle.com/?p=49679 This Tidbit of the Day will provide cool features of Cisco Firepower/FTD in just a couple minutes! In this Tidbit of the Day (TOD), I will show you how to find a hidden feature in the Dashboard>Overview in order to se your IPS “Would have Dropped” events

The post How to find a hidden graph that shows your Cisco Firepower IPS “Would have Dropped” events appeared first on Todd Lammle, LLC.

]]>
This Tidbit of the Day will provide cool features of Cisco Firepower/FTD in just a couple minutes!

In this Tidbit of the Day (TOD), I will show you how to find a hidden feature in the Dashboard>Overview in order to se your IPS “Would have Dropped” events

The post How to find a hidden graph that shows your Cisco Firepower IPS “Would have Dropped” events appeared first on Todd Lammle, LLC.

]]>
https://www.lammle.com/post/todd-lammles-cisco-firepower-ftd-tidbit-of-the-day-tod/feed/ 0
Which IPS Rules does Cisco Enabled on your Firepower System? Think you know? Part II https://www.lammle.com/post/which-ips-rules-does-cisco-enabled-on-your-firepower-system-think-you-know-part-ii/ https://www.lammle.com/post/which-ips-rules-does-cisco-enabled-on-your-firepower-system-think-you-know-part-ii/#respond Wed, 15 May 2019 13:50:06 +0000 https://www.lammle.com/?p=49627 In the late 1990’s Dale Carnegie wrote what would become one of the most famous and popular business books ever to be written: “How to Win Friends & Influence People”. I am pretty sure that Cisco Talos has Fed Ex’d me a copy by now… In one of my current blog posts titled (4/13/19): “Which IPS…

The post Which IPS Rules does Cisco Enabled on your Firepower System? Think you know? Part II appeared first on Todd Lammle, LLC.

]]>
In the late 1990’s Dale Carnegie wrote what would become one of the most famous and popular business books ever to be written: “How to Win Friends & Influence People”. I am pretty sure that Cisco Talos has Fed Ex’d me a copy by now…

In one of my current blog posts titled (4/13/19): “Which IPS Rules does Cisco Enable on your Firepower System? Think you know?” which is now Part I of this series, I showed that by opening the Rule Accordion, clicking on Rule Content, and lastly, opening Rule Overhead in an IPS policy, you can easily tell which rules are enabled and disabled by default. There’s your answer. No wiggle room here, except for speculation, and that is what this blog will discuss.

In that post I showed you how each Cisco base policy rules are enabled in each overhead listing. However, I’m pretty sure that everyone would know or guess that Cisco certainly may use overhead in some situations for some rules, but there was probably another method they used; however, no one knew what it was, or if they did they couldn’t prove it as plainly as shown above. Also, in that post, I used the Advanced tab slider bar in the Firepower Recommendation section to show how those rules are enabled as well (this is important to remember for this post):

To be clear, most advanced and experinced Sourcefire/Firepower people do not believe that you should use Firepower Recommended Rules (RR) because you probably can’t get enough good Firepower data to make your network secure or more secure, but that’s another blog post…just keep this in mind.

So how does Cisco Choose the rules to enable for each IPS base policy?

There are almost 7 Billion people in the world now, and probably less than a dozen people in the world (within Talos) actually knew the answer to how and why rules were enabled in the Cisco Firepower System, and they weren’t talking. Sure, there were some old  documents from the Sourcefire days that discussed (the last updated document was in 2014!) CVSS scores, categories, date of rule, etc, but nothing recent or anything that made sense on why they are listing everything as enabled by Rule Overhead.

My post received a lot of traction, mostly good because I wasn’t attacking Cisco on the rule set, but because I was telling a story on how changing from the default IPS policy of Balance Security and Connectivity to a higher policy can be useful to find problems, and the post provided an excellent example of how I used a Security over Connectivity policy to be successful at a large customer.

However, there was going to be some pushback expected, and the end result was that Cisco did respond, and will be fixing/clarifying some of the issues that I brought up in that earlier post, and to clarify they said: “inaccurate, albeit understandable, assumptions”… with that said, Cisco did end their email with “TALOS team will be looking into the misunderstanding seen in the blog, as well as the remediations they’re planning on making to ensure the behavior of the product is more intuitive & clear in this area.”

Personal note:

Now you might be thinking that this was an ego trip, etc, on my part to find and amplify these questions regarding the IPS policy and get a lot of hits on a blog post, but my goal and reasoning is always and only always my business bottom line – period. Meaning that if I cannot fix a Firepower issue at a customer (or teach) because of lack of documentation or understanding, that this is going to affect both my customers as well as my own bottom line (I can easily include cisco’s in here as well).

My intentions are only to make sure that my customers are working to the best of my ability. Since this may include confronting Cisco on some issues, this direction may upset people at Talos at times, and I understand that, but they aren’t paying me, my customers are. Same with you; either the company you’re employed at, and/or your customers, are your bottom line, not Cisco feelings, which is why you always call and yell at Cisco TAC. Yes, I know you do.

Quick Summary Answer if you don’t want to read the rest of this blog post (You’re welcome):

Bottom line is that Cisco responded regarding my blog, and I will summarize their response for you: “The Rule Overhead was meant to only be used with the Cisco Firepower Recommendation (RR) Slider bar, and should not have been in the Rule Accordion, so they will be deleting that Rule Overhead section from that location in the IPS policy.” With all that said, does this solve the issue? No, not really, now they are just going to make it harder for us to find this information; yes, that was their solution. Why do I say this? Because if you have SoC, weather or not you enable Firepower RR, the listed high overhead rules will still never be enabled. Again, they are just taking this view away from us, that’s all.

So now we’ll have to look elsewhere to find how they enable the rules in each Cisco provided IPS policy. Where? Well, that won’t be quite as easy, but look no further than the metadata in a Snort rule as such:

alert udp $HOME_NET any -> any 53 (msg:”APP-DETECT DNS request for Dynamic Internet Technology domain dongtaiwang.net”; flow:to_server; byte_test:1,!&,0xF8,2; content:”|0B|dongtaiwang|03|net|00|”; fast_pattern:only; metadata:policy max-detect-ips drop, policy security-ips drop, service dns; reference:url,wikipedia.org/wiki/Freegate; classtype:misc-activity; sid:27997; rev:2; gid:1; )

Looking at the metadata section, we can see that this rule 27997 is enabled in the Maximum Detection and Security over Connectivity polices.

You can also see all the rules enabled in the IPS policy by typing “metadata:policy” in the filter bar as such to get the enabled rules for each policy:

Your four metadata filters are: metadata:connectivty, metadata:balanced, matadata:security, and metadata:max

I’ll be fleshing out the changes when they come out with 6.5 code…

For those that want to know more:

Here is the full email for your reading pleasure, then I’ll finish this post by listing how Talos says the rules are chosen for each Cisco policy.

The “Rule Overhead” available values of Low, Medium, High, and Very High were intended to provide customers a way of limiting the the rulesets enabled when using Recommended Rules so RR would not enable rules in more security conscientious base Intrusion Policies. These rulesets resulting from these filters are determined programmatically by the FMC at the time the SRU is imported, and are not pre-built by Talos.

Low —> Set of rules from ‘Connectivity over Security’

Medium —> Set of rules from ‘Balanced Security and Connectivity,’ excluding rules included in the ruleset resulting from using the ‘Low’ filter

High —> Set of rules from ’Security over Connectivity,’ excluding rules included in the ruleset resulting from using the ‘Medium’ filter

Very High —> Set of all rules, excluding rules included in the ruleset resulting from using the ‘High’ filter

It appears this functionality, which was originally intended to be applicable for Recommended Rules, was also included in the Rule Selection Editor in the Intrusion Policy. This is an error, as constraining the rulesets based upon Talos-provided base Intrusion Policies are already provided via the ‘Base Policy’ selector when the Intrusion Policy is first created.

Additionally, “Rule Overhead” is an inaccurate way of describing the functionality in the first place, as it gives the impression Talos has some universal metric used to quantify the performance impact of a given rule. This is not the case. The base Intrusion Policies any given snort rule is enabled by default in are determined by a combination of the CVSS score (where applicable) of the vulnerability the rule is designed to protect against exploitation of, as well as constrain the rulesets based upon how old, or how prevalent threats are. Published details can be found here https://www.snort.org/faq/why-are-rules-commented-out-by-default.

Finally, there appears to be a small, albeit present, discrepancy between the rulesets enabled in each base Intrusion Policy Talos ships and the rulesets resulting from the various Low/Medium/High/VeryHigh filters from Recommended Rules. TALOS will be working internally to identify the source of that discrepancy & remediate it.

To this end, Talos will work on the following issue internally:

1: Update the Slider Bar in Recommended Rules to reference the base policies, instead of “Rule Overhead”

2: Update the Rule Selection Editor in the Intrusion Policy to remove the “Rule Overhead” as a method of filtering for rules

3: Update the product documentation to more accurately reflect how the slider bar in Recommended Rules leverages base policies to constrain the rulesets that the product will automatically enable.

Hopefully, this makes it clear that the blog post referenced makes a set of conclusions based upon inaccurate, albeit understandable, assumptions about how the product & Talos select rules to be enabled in the various base Intrusion Policies. TALOS team will be looking into the misunderstanding seen in the blog, as well as the remediations they’re planning on making to ensure the behavior of the product is more intuitive & clear in this area.

All Our Love, 

Talos

(I might have embellished the signature section a little…)

 

Lastly, here is the newest information on how the four Cisco authored polices enable and disable rules, as said so by God, err.. I mean Cisco Talos:

  1. Connectivity over Security
    1. This policy is specifically designed to favor device performance over the security controls in the policy. It should allow a customer to deploy one of our devices with minimal false positives and full rated performance of the box in most network deployments. In addition, this policy should detect the most common and most prevalent threats our customers will experience.
    2. Criteria:
      1. CVSS Score = 10
      2. CVE year is current – 2 (So, for example, 2019, 2018, 2017)
  2. Balanced
    1. This policy is the default policy that is recommended for initial deployments. This policy attempts to balance security needs and performance characteristics. Customers should be able to start with this policy and get a very good block rate with public evaluation tools, and relatively high performance rate with evaluation and testing tools. It is the default shipping state of the Snort Subscriber Ruleset for Open-Source Snort.
    2. Criteria:
      1. CVSS Score >= 9
      2. CVE year is current – 2 (For example, 2019, 2018, 2017)
      3. MALWARE-CNC rules
      4. EXPLOIT-KIT rules
      5. SQL Injection rules
      6. Blacklist rules
      7. Includes the rules in the Connectivity over Security policy.
  3. Security over Connectivity
    1. This policy is designed for the small segment of our customer base that is exceptionally concerned about organizational security (translation: people that care enough to look into network analysis on their IPS events) Customers deploy this policy in protected networks, that have a lower bandwidth requirements, but much higher security requirements. Additionally, customers care less about false positives and noisy signatures. Application control, and locked down network usage are also concerns to customers deploying this policy. It should provide maximum protection, and application control, but should not bring the network down.
    2. Criteria:
      1. CVSS Score >= 8
      2. CVE year is current -3 (For example, 2019, 2018, 2017, 2016)
      3. MALWARE-CNC rules
      4. EXPLOIT-KIT rules
      5. SQL Injection rules
      6. Blacklist rules
      7. App-detect rules
      8. Includes the rules in the Connectivity over Security and Balanced policies.
  4. Maximum Detection
    1. This ruleset is meant to be used in testing environments and as such is not optimized for performance. False Positives for many of the rules in this policy are tolerated and/or expected and FP investigations will normally not be undertaken.
    2. Criteria:
      1. The coverage is required for in field testing
      2. Includes rules in the Security, Balanced, and Connectivity rule sets.
      3. Includes all active rules above Sid:10000, unless otherwise specified. (holy crap! First, it’s unlikely many of you are reading this far, but read #3 again if you’re still with me. That’s why this policy has about 28k rules enabled; since there are about 38k rules now…)

 

…So what does this all mean? How can I tell what is enabled by default? Not sure completely yet, only time will tell now, and I’m sure I’ll add a part III to this soon.

I think I hear the doorbell, oh its Fed Ex…

The post Which IPS Rules does Cisco Enabled on your Firepower System? Think you know? Part II appeared first on Todd Lammle, LLC.

]]>
https://www.lammle.com/post/which-ips-rules-does-cisco-enabled-on-your-firepower-system-think-you-know-part-ii/feed/ 0
Is Cisco Firepower/FTD 6.4 code ready for production? https://www.lammle.com/post/is-cisco-firepower-ftd-6-4-code-ready-for-production-no-not-really-please-read-on/ https://www.lammle.com/post/is-cisco-firepower-ftd-6-4-code-ready-for-production-no-not-really-please-read-on/#comments Sat, 04 May 2019 20:06:38 +0000 http://www.lammle.com/?p=49409 This is a follow up blog from my initial writeup on the release of Cisco Firepower/FTD 6.4 code release. I mention in that blog that I had class that week and was going to thoroughly test the new 6.4 code, and then write a new blog on my recommendations, so here we are. To cut…

The post Is Cisco Firepower/FTD 6.4 code ready for production? appeared first on Todd Lammle, LLC.

]]>
This is a follow up blog from my initial writeup on the release of Cisco Firepower/FTD 6.4 code release.

I mention in that blog that I had class that week and was going to thoroughly test the new 6.4 code, and then write a new blog on my recommendations, so here we are.

To cut to the chase, meaning that if your busy and don’t want to read anymore, just don’t upgrade or install 6.4 code yet, wait for 6.4.0.1.  Also, it’s worth stating that you should never install a “.0” code if possible.

UPDATE 5/16/19: 6.4.0.1 came out and has solved a couple of the issues addressed in this post. Will update this again once this is confirmed.

Update 5/16/19: I have confirmed that the new 6.4.0.1 patch has indeed fixed the firepower discovery issue with the new FMC installs

Here is a Concerning Issue:

In my six-years of almost full-time work on Sourcefire/Cisco Firepower, I have never seen a problem with RUA/RNA, FireSIGHT, or what we now just call Firepower Network Discovery, and I can almost guarantee no one else has either. Cisco Firepower/FTD code 6.4 seems to have broken that winning streak.

Update: see cisco bug CSCvp59960 (Sev 3)

In the screen shot below, I am showing the three Cisco created objects that I use or you can use in your Networks configuration of network discovery. (No, I did not use all three at the same time, I am just showing you the three I tested with individually for brevity).

Once deployed, go Analysis>Host>Network Map notice that there are no hosts present. This shocked and amazed me (I might have said WTF out loud too)! We tested this and tested this to make sure we weren’t making a mistake, but screwing up the easiest policy in Firepower is not easy to do! Usually, you’ll get data whether you like it or not…

Below, you can see the three manual configuration that we tried, again, all configured and deployed separately. When we deployed the Enterprise group, immediately hosts showed up. We also then tested typing in manually quad zeros, and then the 10.0.0.0/8 manually as well; every time we tested a manual object, Firepower starting worked as it always has…

Here we used a manually created network configuration in Firepower and hosts immediately showed up!

Solution? Use a manually created object, or just don’t upgrade to 6.4 yet.

Is the Juice of Upgrading to 6.4 worth the Squeeze?

From the ACP, you can click on Analyze Hit Counts, and then choose your 6.4 FTD devices and get hit counts via a the GUI. If you click on the rule name, it takes you to the rule itself, and if you click on the magnifying glass it opens and edits the rule. Useful. Maybe not worth the upgrade since you could always use the show acccess-list-config FTD command and get much more information than this provides…but hey, people love their GUI…

However, I’d rather just have a column in the ACP rules that shows you the hit count, for example put this where the Comment count is listed now (that now one gives a damn about), as shown here:

In addition, Cisco was also touting the new FTD command “show rule hits” at the CLI…however, this one made me scratch my head. Looking at the output below of the show rule hits command- that I first had to copy into notepad, so I could then compare the Rule ID to the actual ACP rule set. Seriously.

Remember, you could have always just typed in show access-list, as I did here, and see the hit counts as well…but, it’s not a GUI, true.

Possibly Cosmetic Issue or just plain odd…

When configuring the File/Malware policy with the same exact configuration that I’ve deployed for year, this error message popped up.

Update: please see Cisco bug CSCvp60050 (Sev 4)

I actually thought they had done some work on the new File policy, but no, just press OK here and the rule takes the commands, as it always has. We could find no issues with this, other than possibly a cosmetic message.

MISC

After mentioning this in the last blog, this really needs to be understood:

No alt text provided for this image

What Cisco doesn’t tell you here is that you still need to go into Devices>Platform Settings>Syslog and configure the MID’s into the Event List to make this work; and you might as well turn on 430001 (identifies an intrusion event), 430002 (identifies a connection event logged at the beginning of the connection) and 430003 (identifies a connection event logged at the end of the connection) well you’re at it. There is no documentation that tells you that you need this configuration!

No alt text provided for this image

Cisco just added these MID’s to the documentation: Cisco Firepower Syslog event messages

The Object Usage screen in Objects, starting in 6.4 is somewhat helpful for telling you the policy an Object is used in, however, it would be nice if it listed the rule number as well.

Also, there are some random issues that I ran into when creating rules: as in that it wouldn’t take the rule, and the Monitor rule wouldn’t, well, log. I can’t reproduce those on command though…also, 6.4 code breaks WCCP.

Lastly, I mentioned in my previous blog that Cisco is moving from Brightcloud to Talos categories for SI and URL’s. This has been delayed until 6.5 code now. Not an issue, just a heads up…

Can’t wait to see what 6.4.0.1 brings us…

 

 

The post Is Cisco Firepower/FTD 6.4 code ready for production? appeared first on Todd Lammle, LLC.

]]>
https://www.lammle.com/post/is-cisco-firepower-ftd-6-4-code-ready-for-production-no-not-really-please-read-on/feed/ 16
The Quiet Release of the New Cisco Firepower/FTD 6.4 Code https://www.lammle.com/post/the-quiet-release-of-the-new-cisco-firepower-ftd-6-4-code/ https://www.lammle.com/post/the-quiet-release-of-the-new-cisco-firepower-ftd-6-4-code/#comments Sat, 27 Apr 2019 18:54:28 +0000 http://www.lammle.com/?p=49299 The new Cisco Firepower 6.4 code has some great features. Something for Cisco to be proud of, and I’ll list a few of the top ones in this short article. However, it seemed to me that this release had less fanfare than say the “make it or break it code of 6.2.3”, or the “powerful…

The post The Quiet Release of the New Cisco Firepower/FTD 6.4 Code appeared first on Todd Lammle, LLC.

]]>

The new Cisco Firepower 6.4 code has some great features. Something for Cisco to be proud of, and I’ll list a few of the top ones in this short article. However, it seemed to me that this release had less fanfare than say the “make it or break it code of 6.2.3”, or the “powerful 6.3 code” releases. Why? is it not as quite as powerful or full or fixes and features? Sure it is; not as much as 6.3, but still a good amount and worth the upgrade.

My thought is that we’ll see that they will make more use of this new code at Cisco Live when they announce some new all-so-powerful FTD devices. For example, you can’t run multiple instances using both ASA and FTD code except on the 9300. The existing 4100’s do not support it. In addition, the low-end 5506 doesn’t support anything above 6.2.3 code. Let’s see what Cisco Live brings us with the new 41×5 and 1000 series devices running the all-new-powerfull 6.4 code.

Worth the upgrade?

Sure, read on and find out. I believe the change in objects is worth it alone. However, they were very clear in the documentation that it’s a faster upgrade and that you’ll see faster deploy times. I upgraded over 20 FMC’s and the 90 minutes was about the same as 6.2.3 to 6.3. Also, there is zero time change in my deployments, but maybe you’ll see different results with this (hopefully!).

Non-Documented Changes

I could not for the life of me find these two new features in the Cisco Firepower Release Notes, Version 6.4.0: Object Usage and URL Categories

Object Usage

This is a pretty great new feature: You can now click and find the Object usage.

You can’t however see what rule the object is used in from here, but you can click on the Usage Policy listed, and it will take you to that rule. Very useful.

Firepower 6.4 code Change in Objects visibility
In In addition, and not such a big deal, this didn’t warrant a place in the documentation either, as they now put the Objects in alphabetical order, something I find annoying now, but I’m sure I’ll get used to it.
Objects are now in alphabetical order

URL Catagories

Another big change, and again not documented, is the URL categories. Firepower will now utilize categories from Cisco’s Talos and not brightcloud. https://www.talosintelligence.com/categories 

[UPDATE 5/2/2019: The new URL categories for 6.4 were not implemented in this change as discussed in the beta, so 6.4 is still using bright cloud. This feature has been moved to the 6.5 release.]

 

The ACP has two good changes:

First, you can now configure an external syslog server to receive file/malware events, which are generated by file policies configured on access control rules. Important: File events use message ID 430004, malware events are 430005 (this is not documented in the Cisco Syslog Documentation).

No alt text provided for this image

What Cisco doesn’t tell you here is that you still need to go into Devices>Platform Settings>Syslog and configure the MID’s into the Event List to make this work; and you might as well turn on 43001 (identifies an intrusion event), 43002 (identifies a connection event logged at the beginning of the connection) and 43003 (identifies a connection event logged at the end of the connection) well you’re at it.

UPDATE 5/1/19: Cisco just added these to the documentation: https://www.cisco.com/c/en/us/td/docs/security/firepower/Syslogs/b_fptd_syslog_guide/security-event-syslog-messages.html#id_105507

No alt text provided for this image

Also new inside your ACP is your Analyze Hit counts for your PreFilter and ACP. We’ll see how good this really is as my customers upgrade, but it sounds good.

No alt text provided for this image

There are some new CLI commands for this feature as well such as show rule hits that can be run on your FTD. Also, the show failover now contains object static counts related to syncing hit counts between HA peers

Enhancements & Improvements

There were five enhancements to the Firepower Threat Defense Encryption and VPN, however, this is the one I was waiting for the most:

RA VPN: Duo as first factor in two-factor authentication. You can now use a Duo proxy server (which also acts as a RADIUS server) as the first factor in RA VPN two-factor authentication

There were also five enhancements to the Events, Logging, and Analysis of Firepower.

Here is one of them: Cisco Threat Response (CTR) integration via System > Integration > Cloud Services

No alt text provided for this image

Cisco Threat Response is a new Cisco offering that you will be able to integrate with Firepower Threat Defense deployments. CTR’s powerful analysis tools will allow you to integrate Firepower event data with data from other sources for a unified view of threats on your network.

Also, Splunk users can use a new, separate Splunk app, Cisco Firepower App for Splunk, to analyze events. If you use Splunk, you need to check this out as it’s pretty cool, plus estreamer is going away soon: https://splunkbase.splunk.com/app/3663/

Connection-based troubleshooting

Connection-based troubleshooting or debugging provides uniform debugging across modules to collect appropriate logs for a specific connection.

It also supports level-based debugging up to 7 levels and enables uniform log collection mechanism for lina and Snort logs.

debug packet start, debug packet start, show packet debugs and clear packet debugs are the new commands

Performance

Snort restart improvements for 4100/9300 devices: Before Version 6.4, during Snort restarts, the system dropped encrypted connections that matched a ‘Do not decrypt’ SSL rule or default policy action. Now, routed/transparent traffic passes without inspection instead of dropping, as long as you did not disable large flow offload or Snort preserve-connection.

Faster access control The Version 6.4 upgrade process enables egress optimization on eligible devices, which enhances access control performance. Cisco TAC strongly recommend you leave this feature enabled.

Faster SNMP event logging Performance improvements when sending intrusion and connection events to an external SNMP trap server.

Faster deploy: Cisco mentions that they made improvements to appliance communications and deploy framework for faster deployment times. However, after my upgrade the deploy time was about the same as it was in 6.2.3 and 6.3. Will keep an eye on this one.

Lastly, there were quite a few new features available in FTD 6.4 when configured using Firepower Device Manager (FDM).

The post The Quiet Release of the New Cisco Firepower/FTD 6.4 Code appeared first on Todd Lammle, LLC.

]]>
https://www.lammle.com/post/the-quiet-release-of-the-new-cisco-firepower-ftd-6-4-code/feed/ 37
Can Law Enforcement use Cisco devices to spy on you? Yes they can! https://www.lammle.com/post/can-law-enforcement-use-cisco-devices-to-spy-on-you-yes-they-can/ https://www.lammle.com/post/can-law-enforcement-use-cisco-devices-to-spy-on-you-yes-they-can/#respond Tue, 23 Apr 2019 16:28:12 +0000 http://www.lammle.com/?p=49253 Are Law Enforcement Agencies using your equipment to spy on you or others without you even knowing? Possibly! Lawful intercept is a process that enables a Law Enforcement Agency (LEA) to perform electronic surveillance on an individual (a target) as authorized by a judicial or administrative order. Congress requires that service providers (SPs) and Internet…

The post Can Law Enforcement use Cisco devices to spy on you? Yes they can! appeared first on Todd Lammle, LLC.

]]>
Are Law Enforcement Agencies using your equipment to spy on you or others without you even knowing? Possibly!

Lawful intercept is a process that enables a Law Enforcement Agency (LEA) to perform electronic surveillance on an individual (a target) as authorized by a judicial or administrative order. Congress requires that service providers (SPs) and Internet service providers (ISPs) implement their networks to explicitly support authorized electronic surveillance.

Because this: The service provider then intercepts the target’s traffic as it passes through the Catalyst 6500 series switch, and sends a copy of the intercepted traffic to the LEA without the target’s knowledge

See, you aren’t just being paranoid!

Get out your  before you read on!

…and the winners are:

The surveillance is performed through the use of wiretaps on traditional telecommunications and Internet services in voice, data, and multiservice networks. The LEA delivers a request for a wiretap to the target’s service provider, who is responsible for intercepting data communication to and from the individual. The service provider uses the target’s IP address to determine which of its edge Catalyst 6500 series switchs handles the target’s traffic (data communication).

The service provider then intercepts the target’s traffic as it passes through the Catalyst 6500 series switch, and sends a copy of the intercepted traffic to the LEA without the target’s knowledge

Lawful intercept provides:

  • Allows multiple LEAs to run a lawful intercept on the same target without each other’s knowledge.
  • Does not affect subscriber services on the Catalyst 6500 series switch.
  • Supports wiretaps in both the input and output direction.
  • Supports wiretaps of Layer 1 and Layer 3 traffic. Layer 2 traffic is supported as IP traffic over VLANs.
  • Supports wiretaps of individual subscribers that share a single physical interface.
  • Cannot be detected by the target. Neither the network administrator nor the calling parties is aware that packets are being copied or that the call is being tapped.
  • Uses Simple Network Management Protocol Version 3 (SNMPv3) and security features such as the View-based Access Control Model (SNMP-VACM-MIB) and User-based Security Model (SNMP-USM-MIB) to restrict access to lawful intercept information and components.
  • Hides information about lawful intercepts from all but the most privileged users. An administrator must set up access rights to enable privileged users to access lawful intercept information.
  • Provides two secure interfaces for performing an intercept: one for setting up the wiretap and one for sending the intercepted traffic to the LEA.

..While supplies last!

A mediation device (supplied by a third-party vendor) handles most of the processing for the lawful intercept.

The mediation device:

  • Provides the interface used to set up and provision the lawful intercept.
  •  Generates requests to other network devices to set up and run the lawful intercept
  • Converts the intercepted traffic into the format required by the LEA (which can vary from country to country) and sends a copy of the intercepted traffic to the LEA without the target’s knowledge.

 

Nice, huh?

The post Can Law Enforcement use Cisco devices to spy on you? Yes they can! appeared first on Todd Lammle, LLC.

]]>
https://www.lammle.com/post/can-law-enforcement-use-cisco-devices-to-spy-on-you-yes-they-can/feed/ 0
Which IPS Rules does Cisco Enable on your Firepower System? Think you know? You’re probably wrong! https://www.lammle.com/post/which-ips-rules-does-cisco-enable-on-your-firepower-system-think-you-know-youre-probably-wrong/ https://www.lammle.com/post/which-ips-rules-does-cisco-enable-on-your-firepower-system-think-you-know-youre-probably-wrong/#comments Sat, 13 Apr 2019 18:03:42 +0000 https://www.lammle.com/?p=48761 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…

The post Which IPS Rules does Cisco Enable on your Firepower System? Think you know? You’re probably wrong! appeared first on Todd Lammle, LLC.

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

The post Which IPS Rules does Cisco Enable on your Firepower System? Think you know? You’re probably wrong! appeared first on Todd Lammle, LLC.

]]>
https://www.lammle.com/post/which-ips-rules-does-cisco-enable-on-your-firepower-system-think-you-know-youre-probably-wrong/feed/ 20
Cisco Firepower Threat Defense (FTD) devices are expensive! Which one should you get? https://www.lammle.com/post/cisco-firepower-threat-defense-ftd-are-expensive-which-one-should-you-get/ https://www.lammle.com/post/cisco-firepower-threat-defense-ftd-are-expensive-which-one-should-you-get/#comments Thu, 04 Apr 2019 19:58:20 +0000 https://www.lammle.com/?p=48680 This post goes hand-in-hand with my FMC blog Cisco FTD devices are expensive!…and they are announcing new more expensive one’s next week…here are the current as of right now: Cisco’s 2100, 4100 and 9300 FTD Devices So which one of these expensive FTD devices do you need? Did you know it’s actually pretty easy to…

The post Cisco Firepower Threat Defense (FTD) devices are expensive! Which one should you get? appeared first on Todd Lammle, LLC.

]]>
This post goes hand-in-hand with my FMC blog

Cisco FTD devices are expensive!…and they are announcing new more expensive one’s next week…here are the current as of right now:

Cisco’s 2100, 4100 and 9300 FTD Devices

So which one of these expensive FTD devices do you need?

Did you know it’s actually pretty easy to figure out the FTD device(s) you need for your network?

Only one small caveat to this easy way is that you need a CCO login and then access to page ngfwpe.cisco.com

Most of you probably already have this access, but ask your rep if not. This is what your rep will use to determine on what to sell you…if he says you can’t have access (BS), then tell him you want to watch him perform this…

Here is the home page of ngfwpe.cisco.com after logging into Cisco.

First pick your threat inspected throughput wanted/needed for your network:

Then choose your typical network packet size on your network, or leave default

…Most importantly, add Enabled Features:

It’s best to keep clicking on various features to see different products suggested…

IMPORTANT NOTE: Let me stop and discuss the Features listed above. I actually had a customer that didn’t buy any licenses for any features. This means you’ll only get Base licensing (which is included by default), so they couldn’t add any SI, IPS, Malware or URL. At a minimum you NEED Threat licensing, which provides Security Intelligence (SI) and IPS capability. If you don’t want to buy at a minimum Threat, then just go to BestBuy and buy a NetGear Firewall for $50.

Now add the typical network utilization you think you’ll use…I usually click on the <40 to get as many possible solutions shown as possible

In Advanced choose the model you have or are possibly thinking of getting:

Add other filters, such as OS. However, I just typically click on FTD to make it easy…

Now, go to the top and click APPLY.

In the following output, I had filtered on 1Gbps inspected throughput, common packet size, <40 Utilization, Base, IPS and URL filtering, and then choose FTD OS.

You can see the 11 hardware devices that it is suggesting…

Just keep adding filters to narrow down and find your device! It’s actually fun to see what Cisco comes up with on your filters.

The post Cisco Firepower Threat Defense (FTD) devices are expensive! Which one should you get? appeared first on Todd Lammle, LLC.

]]>
https://www.lammle.com/post/cisco-firepower-threat-defense-ftd-are-expensive-which-one-should-you-get/feed/ 6