NGFW Policy Order of Operations

[igrahamit]

After reading the NGFW Policy Order of Operations guide here, https://www.cisco.com/c/dam/en/us/td/docs/security/firepower/Self-Help/NGFW_Policy_Order_of_Operations.pdf

I am even more confused about how the firepower device processes rules. According to this guide, if I want to block all port 443, but allow access to google drive, I would need to put a rule blocking 443 before the rule allowing google drive. This is on page 5 of the linked guide.

Could someone please explain how a setup like that would allow google drive while simultaneously blocking all 443 traffic? If the block for port 443 comes before the application detection rule for google drive, the application detection rule would never be able to identify a google drive connection, because it would be blocked at the very first packet.

[Mike.Cifelli]

So to briefly hit on the order of operation Security Intelligence will occur first prior to parsing through your access control entries, which is where you can do global whitelisting/blacklisting. After that your mandatory rules will be evaluated followed by the remaining zones and ACEs in an ordered fashion. As for your use case you have a couple of options. You could accomplish it using URL filtering in an ACE, application filtering in an ACE, whitelisting drive.google.com, or straight up old school IP to drive.google.com IP and then block all on port 443.

See here for licensing: https://www.cisco.com/c/en/us/td/docs/security/firepower/60/configuration/guide/fpmc-config-guide-v60/Licensing_the_Firepower_System.html

See here for good tutorials: http://www.labminutes.com/video/sec

HTH!

[igrahamit]

Thanks Mike,

I think I understand the order of operations, but I'm trying to figure out if there is a discrepancy in the guide I'm reading, since it it proposing to make a 443 blacklist ACE in the ACP before the application detection ACE for allowing google drive.

It would seem to me that such a configuration would not properly allow google drive to work, since all 443 traffic would be blocked prior to the google drive allow - e.g. the application detection would not be able to do it's job because the 443 block ACE is preventing any packets from getting through. However the cisco published guide is clearly stating this is the preferred way to set up such a configuration.

Assuming you were in some ultra-high security environment where you were doing zero trust and whitelisting, blocking 443 at the top of the ACL would render any application detection useless, correct?

[Ilkin]

That example scenario just covers a specific scenario when blocking ALL traffic to port 443 is required. It specifically says on page 5: 'If we want to block ALL traffic going to Port 443 we want to ensure this rule is NOT below a rule containing an Application Filter or something we will need to wait for information for". This means that IF the intention is to block ALL traffic going to port 443, then rules 3 should be 1st in the list.
In other scenarious implementation may be different.

[PaulPatterson99634]

Is this document still available? I can not find it anywhere. 

[Marvin Rhoads]

You can refer to this diagram:

[Sir Chris]

Hello Legends.

Apologies for sabotaging the thread but I have a question along similar lines and somehting we may see a lot of in the coming years.

Picture the scene:

* SDA fabric with VNs
* Cisco FTDs being used as the Fusion router
* VNs temrinate on the FTDs (SVI)
* Different virtual routing instance run on the FTD for each VN (BGP)
* ISE updating FTDs with context info (ie SGTs to IP mapping) via SXP
* One instance/container being run on the FTD

OK, so let's say that Bob on VN-Blue wants to reach Jane on VN-Pink. How will that look?

Well firstly, the routes need to be leaked between the VNs. That can be done manually with route targets, etc.
Secondly, a rule needs to be created to allow Bob's IP address to be allowed to destination Jane's IP address.

Given that this may be a common requirement according to design requirements, Im wondering whether the pain is worth it. But that's a side note.

Question .. Where in that flow diagram will all this take place? Given that the packet will go from trusted VN zone to trusted VN zone, will the packet still have to pass through the SNORT engine, the standard ACLS, etc? My head is in a spin thinking about it.