Firepower Best Practices: The Access Control Policy
post by: mosesrenegade
As people who are purchasing Cisco Firepower gear get more invested in the product many of the legacy Cisco customers have come to me and asked me about Firepower Best Practices. What I find however is that the answers to those questions are ‘it depends’. The purpose of this series of posts is to get people familiar with Firepower and Firepower Services. These series of articles covers version 6.x of the product.
The Access Control Policy, what is it and how to use it.
The access control policy has become the heart of the firepower system. It is sometimes completely misunderstood because in certain circumstances it is used as a Firewall policy but on an IPS it can be used in completely interesting and unique ways. If the engineers understand how the system is meant to act the AC-Policy becomes a wonderful thing.
With that started, let’s go through some tips and tricks on the AC Policy, first our standard visualization that helps us talk about how the AC policy works and looks.
As you can see the AC Policy takes a number of policies and puts them, or pieces them together. It is really critical to understand how the AC Policy can be used to redirect each flow to and from the different engines.
I hope this guide can serve as tips and tricks for people. The first of the things that I would recommend is to push block rules as to the highest area in the policy. I would also recommend pushing items that do no need to get inspected to the top also if possible.
The Firepower management center is involved heavily in things like policy management but also participates actively in AMP Disposition lookups and checking. You could run all of this without cloud communications but you would lose some capabilities like:
- Dynamic URL Categorization
- Advanced Malware Hash Lookups
- Dynamic IP/URL/FQDN/DNS Reputation
Allow, Monitor, Trust, and Block
There are 4 major types of actions that are in the Access Control policy of the system. Remember the product had a heritage of IDS (and IPS) before Firewall and NGFW policies and so the rules do reflect this.
Trust rules will be rules that will not add any further inspection. For example, if the rule has a source address 126.96.36.199 and destination of any, then any packet matching those parameters will not go through IPS, File, or URL inspection.
Monitor Rules are somewhat special, they are designed for logging of traffic but will neither automatically permit or deny, instead they will fall to the next rule which could be a permit or deny. This is important because you may want to just monitor and allow but end up denying a packet or vice versa. It will also automatically log at the END of a connection. Logging is another subject we will get into.
Block will block traffic without inspection, Block with Reset is really meant for IDS mode in which a TCP Reset will attempt to stop the communication of the traffic. Interactive Block is also unique, remember this system has the capability to present the user with a Web Page that can prompt the user to bypass the block in various ways. If you are doing Web Based blocking for categorization, this would be an area where a user can bypass the block, in which case it would fall into an allow rule.
Zones, Networks, Geo-IP, and VLANS
This system was designed with IPS/IDS in mind, but the same concepts can be applied to firewalls in the case of Zone Based Firewalls. Zone based will allow a user to define the appropriate rules per zone which could be somewhat interface specific and allow for more granular and flexible policies.
Now there are some other treasures in the system iincluding the ability to block entire countries, how does one do that? It is actually hidden somewhat in the network and is accessible in a tab called GeoLocation. I have pulled out a screenshot which should help you find the location of it. One of the things that is important to note is that you can block continent and country but there is a limit of somewhere in the 40 or so objects in the rule. That is critical because it will change how you add those countries. What I caution most people however is not fall into the trap of block countries because while it can help it is not a foolproof way to stop attackers from coming in the network. I leverage the results to look at who is communicating or connecting to my device for analysis but I don’t generally take action on this.
VLANs tagging in a policy is generally used for layer 2 inspections. There are some tips and tricks that I will talk about in a future post on how you can stop double inspecting traffic and one of the methods that can be used is through the AC Policy is the VLANs area.
The Advanced Tab
There is one last thing that is happening in the system that most people don’t realize, and that is in the advanced tab has a wealth of more tuning capabilities that can help further intrusion analysis. I will not be-labour this particular area as much but I will highlight a few gems that I find to be great to enable.
The first thing is Adaptive Profiles, so what are those? Those are really well defined here in this area: Firepower User Guide - Passive Deployments. The reason I mention these is because in the passive deployment section you can implement Adaptive Profiles which will change the way that packets are re-assembled and automatically change the behavior seen in those packets. This can detect anomalies such as fragmentation attacks and other IDS evasion tactics. To configure Adaptive Profiles, you need to click on the pencil icon and not only enable adaptive profiles but add the network ranges for those profiles.
The second item here that I will mention is the Network Analysis Policy which can change the behavior of the rules. In the 5.X version of the product instead of having preprocessors stored within the IPS policy as you would expect you could add change each policy specifically for use in different AC-Policies and for different actions. Some of the more interesting items you will find in this area? The ability to change HTTP Configurations. In here you will see how we can capture the originating IP address from a proxy by using the X-Forward-For header to show the originating IP address so that not all the attacks show up as coming from your proxy. We can also add static ports to some of these areas to further our investigation. While I would not recommend changing all the features within this area without thinking about it first, I would recommend giving it a cursory look.
- You can move any rule up and down in the list by just clicking on the rule and dragging it up or down
- You can click on any of the objects in the rule base such as source ip, ports, applications, the shield (NGIPS), etc, to get into that rule and right into that tab.
This is only one of a few Firepower Best Practices posts.