Introduction

This document discusses the Secure Firewall'sAccess Control feature's key components and configuration best practices using a sample scenario. Configuration steps are based on SecureFirewall Management Center (FMC) v7.2, which may differ slightly from previous versions. 

Background Information

One of the essential functions of a firewall is to provide access control by determining which network connections enter your network from the outside or leave your network from the inside. The specifics of what should and should not be permitted are beyond this document's scope, as each network has unique requirements. However, we will provide some best practice guidance on structuring your access policy to protect against malicious activity.

📘

Note

This document focuses on the Access Control policy only. Separate guides are available that cover other policies associated with the access control policy, such as Network Discovery, Intrusion Prevention (IPS), File and Malware.

Access Control

Access Control policies are just one part of theFirewall Threat Defense (FTD) feature set that organizations use to control network traffic. As packets ingress the firewall, many checks occur. For example, is the packet part of an existing connection, and does the packet require decryption or network address translation? Once the packet has had these checks applied, it passes into theAccess Control Policy (ACP).

An ACP can be assigned to one or more managed devices. However, a device can only have one ACP deployed at one time. The benefit of assigning a single ACP to more than one device is that a single change to the policy via the FMC UI can quickly be applied to multiple devices, reducing operational overheads.

Network data that is processed by managed devices can be filtered and controlled by a set of rules based on:

• Simple, easily determined transport and network layer characteristics: source and destination, ports,
  protocols and applications

• The latest contextual information on the traffic, including characteristics such as reputation, risk,
  business relevance, the application used, or URL visited

• Realm, user, user group, or ISE attribute

• Custom Security Group Tag (SGT)

• Characteristics of encrypted traffic; you can also decrypt this traffic for further analysis

• Whether unencrypted or decrypted traffic contains a prohibited file, detected malware, or intrusion
  attempt

• Time and day

Each rule within an access policy requires an associated action determining how to handle the traffic that matches a rule.Figure 1 below details the various rule actions. Additional properties define how to record the activity in the form of logs or alerts.

• Rule 1: Monitor evaluates traffic first to track and log network traffic. The system continues matching traffic against additional rules to determine whether to permit or deny it.

• Rule 2: Trust evaluates traffic next. Matching traffic is allowed to pass to its destination without further inspection, though it is still subject to identity requirements and rate limiting. Traffic that does not match continues to the next rule.

• Rule 3: Block evaluates traffic third. Matching traffic is blocked without further inspection. Traffic that does not match continues to the final rule. (Optional) Interactive Block allows a user to bypass the block if deemed appropriate. Typically, a user-defined warning message is displayed alongside an interactive block explaining the company security policy.

• Rule 4: Allow is the final rule. For this rule matching traffic is allowed. However, prohibited files, malware, intrusions, and exploits within that traffic are detected and blocked. Remaining non-prohibited, non-malicious traffic is allowed to its destination, though it is still subject to identity requirements and rate limiting. You can configure Allow rules that perform only file inspection, or only intrusion inspection, or no further inspection.

• Default Action handles all traffic that does not match any of the rules in the ACP. In this scenario, the default action performs a Block All, which is considered best practice in most deployments, as any traffic that hasn't explicitly been allowed or denied per your organization's strategic security policy should be blocked and logged for further analysis.

ACP Default Action

As seen above, each ACP has a default action. A newly created policy (without any custom rules) directs managed devices targeted by that policy to handle all traffic using thedefault action. When rules are added to the policy by the firewall administrator, the default action applies to the traffic that:

• is not on a Security Intelligence block list
• is not blocked by SSL inspection
• does not match any of the rules in the policy defined by the administrator

The default action can be set to block traffic, trust traffic without further inspection or analyze traffic for intrusion and discovery data.

Access Rule Order

Rules placement in your ACP is important. A specific rule toblock traffic can be missed if a more general ruleallows traffic above it in the policy. Whereas a rule thatallows traffic may never trigger if there is ablock rule matching traffic before it.

Another effect on rule ordering is performance. Rules that require further inspection (such as Intrusion Prevention or File and Malware processing) consume more resources. Therefore, it is advisable to remove as many threats as possible using less resource-intensive methods such as blocking traffic using layer-3/4 criteria (such as IP address, security zone and port number).

In general, place rules that are likely to be "hit" the most towards the top of your policy, along with more specific rules. Whenever possible, place specific block rules near the top of the policy so that the firewall can make the earliest possible decision on undesirable traffic, especially if those rules block traffic based on layer-3/4 criteria. Rules that filter on URL or application should come next, followed by the more resource-intensive rules that require the traffic to be processed further by Intrusion and/or file policies.

There are no hard and fast rules on how you structure your ACP. However, the guidelines above will help to ensure that you achieve the best performance out of your firewall. The most crucial factor is having the correct rules to suit your organization's security needs.

Prefilter Policies and Security Intelligence

Before processing network traffic by the Access Control policy, there are additional security checks and controls that can be used to enhance your security posture further. These components bring advantages in terms of performance fine-tuning and security effectiveness.

Prefilter Policies

Prefiltering can be thought of as the first phase of access control before the firewall passes connections onto more resource-intensive evaluation controls. A prefilter policy uses limited, outer-header criteria to process connections quickly. The rule actions available in a prefilter policy areFastpath, Block and Analyze.

TheFastpath rule action in the prefilter policy bypasses all further packet inspection and handling, including security intelligence, authentication requirements, SSL decryption, access control rules, deep inspection (IPS), network discovery and rate limiting.

Fastpathing traffic is useful where connections are trusted, therefore not requiring further controls or inspection. The real benefit of the fastpath action is improved performance.

The prefilter policy'sBlock rule action allows the system to block connections at the earliest possible stage as they traverse the firewall. Useful for identifiable connections that can be blocked using basic layer-3/4 criteria, discarding them without requiring too much processing overhead.

TheAnalyze rule action in the prefilter policy is for all other connections that are not being blocked or fastpathed. The Analyze rule action tells the policy to pass the connections to the next control point in the packet flow process, including sending the connections to the Security Intelligence checks, access control policy and potentially more advanced controls such as NGIPS and Malware control.

Security Intelligence

Security Intelligence (SI) is another early defense against malicious activity applied before passing connections to the access control policy for further processing. SI uses reputation-based intelligence backed by Talos, the threat intelligence organization at Cisco. It can block connections to or from IP addresses, URLs and domain names using a block-list, improving performance by quickly excluding traffic from further inspection.

AThreat license is required to use SI, which enables the regular update of intelligence feeds. Cisco provides intelligence feeds and the option of using supplemental third-party and custom feeds without a license. In addition to custom blocklists, creating custom allow lists allow for overriding SI blocking if required.

Configuration

The following steps guide you by creating a basic Access Control Policy and adding rules to control traffic to traverse a managed firewall.

👍

Best Practice

It is recommended to be as specific as possible with any firewall policy configuration. That is to say, have a full understanding of your company's strategic security policy, user requirements, and business operations. This approach allows you to create an access control policy that blocks unwanted traffic, allows everyday business transactions, and provides auditing that can help in the event of a breach.

This example assumes that the firewall is an Internet-facing, edge firewall protecting a trusted internal network and a semi-trusted DMZ. These scenarios typically have the following requirements:-

• Only allow limited inbound traffic from the outside (Internet) to the inside or DMZ networks
• Provide access to the Internet for web browsing from internal systems and users in a controlled manner
• Provide backend access between the internal networks and the DMZ
• Ensure logging and auditing of connections to assist in troubleshooting

Step 1: Create a new Access Control Policy by navigating toPolicies > Access Control

Step 2: ClickNew Policy

Step 2a: Enter a name for the policy along with an optional description.

Step 2b: ChooseBlock all traffic for theDefault Action to ensure that any traffic that isn't matched by rules will be blocked.

Step 2c: UnderTargeted Devices, select the firewall or firewalls that this policy will be applied to and clickAdd to Policy.

📘

Note

You can create a policy without specifying target devices, which is useful if you are designing your policy and do not want to apply it until you are ready.

ClickingSave presents you with an empty policy (Figure 3):

Step 2d:(optional) Version 7.2 brings an option to try the new UI layout, you can toggleTry New UI Layout button at the upper right of the screen to experience it (Figure 3a):

Step 3: For consistency, we will continue with the legacy UI, ToggleSwitch to Legacy UI to switch back. At this stage, deploying this policy to a managed firewall would block all traffic using the Default Action. Before creating the rules, it's best to create theNetwork Objects we will use first to reference them in the rules later.

📘

Note

Create objects in the Object Management window or directly from within the Add Rule properties. We'll show both so you can decide which method works best for you.

Step 3a: Navigate toObjects > Object Management and clickNetwork in on the left-hand side.

Step 3b: At the top of the window, click on theAdd Network drop-down list and clickAdd Object.

Step 3c: Complete the fields as shown inFigure 4 below, substituting the IP address for your own:

Step 3d: ClickSave

Step 4: Next, add a rule to the Access Policy created in Step 2 to allow web traffic to the server on the DMZ.

Step 4a: Navigate toPolicies > Access Control and click on the pencil icon to edit the access control policy.

👍

Best Practice

It is recommended to lock the policy, in version 7.2 the Access Control Policy Lock feature provides administrators the ability to lock the policy to prevent other administrators from editing it. Left unlocked, if multiple administrators edit the policy simultaneously, the first administrator who save changes wins, and the other administrators lose their changes.

Step 5:To lock the policy and avoid changes being made by other administrators click theLock icon on the upper left corner of the screen (Figure 6):

Step 5a: Click+ Add Rule (over on the top-right hand side)

Step 5b: General rule properties.- Assign a ruleName that helps identify the purpose of the rule without viewing each component in detail.

• TheEnabled checkbox allows the rule to be enabled/disabled
• TheAction defines how we want the firewall to handle the traffic that matches the rule. In this example,
  we want to allow traffic to our web server.
• Insert lets you choose where the rule appears in the policy. The position can be changed at any time.
• TheTime Range allows you to control when the rule should be active, including setting recurring
  schedules. This rule is always active, so we'll leave this set toNone.

Step 5c: Now configure the rule matching criteria. The first tab addsZones, which in this example from the list of zones available, we've addedDMZ toDestination andOutside toSource.

📘

Note

Create Zones underObjects > Object Management > Interfaces or during device configuration and are used to represent security zones made up of one or more interfaces.

Step 5d: Next, we move to theNetworks tab. Here we can control which source/destination networks/hosts we want to communicate. Figure 8 shows the completed Networks tab.

• In our example, we're hosting a public webserver with a source network ofANY, which is the default for
  both source and destination.
• For the destination, look in the list of available networks, selectWebserver_Public and clickAdd to
  Destination.

📘

Note

If the network object doesn't exist, you can create one "on the fly." To the right of the "Available Networks" click the+ sign to create a new network object, as seen inStep 4c.

Step 5e: TheApplications allow the firewall to inspect the traffic to ensure that the correct applications access resources. Again, in our example, we are hosting a public webserver, so the applications we want to allow are HTTP and HTTPS.

• From the list ofAvailable Applications, typeHTTP in the search box. Then selectHTTP,
  HTTPS and clickAdd to Rule.

📘

Note

Application Visibility and Control (AVC) causes the firewall to inspect the payload of network connections, verifying that the connections contain the allowed application to prevent malicious actors from tunneling different applications across standard ports. Traditional port-based rules would miss this activity. Combiningapplications andports to force applications to use a particular port number provides better access control. For example, configuring HTTP as the destination application and 80/tcp as the destination port ensures all HTTP connections occur over port 80/tcp. With no port specified, then HTTP as an application would be accepted over any tcp port.

Step 5f: The final step in our example rule is to define the Logging options. Move to the Logging tab and check the following boxes:

• Log at Beginning of Connection
  Creates a log event when connections are established.

• Log at End of Connection
  Creates a log event when connections are closed.

• Send Connection Events to Event Viewer
  Sends events to the internal event viewer for review.

👍

Best Practice

Logging settings depend on your security strategy and regulatory compliance requirements. In general, only log at both the beginning and end of connections to capture audit information such as the duration of connections and the number of bytes sent/received.

• ClickAdd

Step 6: Now that the rule is configured, create aNetwork Address Translation (NAT) rule so the firewall can forward packets that arrive destined for the webserver's public IP address to its private (internal) address on the DMZ.

Step 6a:Navigate to Devices > NAT. ClickNew Policy and selectThreat Defense NAT.

Step 6b: Give the Policy aname and add your firewall device to the policy by clicking the device name underAvailable Devices and then clickingAdd to Policy.

Step 6c: Click+ Add Rule. We're going to use anAuto NAT Rule in our example to translate connections arriving at the firewall for the webserver. Auto NAT is the simplest form of NAT where the NAT rule becomes a parameter for a network object. The network object IP address serves as the original (real) address. Complete the rule using the detail below andfigure 11 as reference.

• UnderNAT Rule, selectAuto NAT Rule.- ForType, selectStatic
• On theInterface Objects tab, selectDMZ for theSource Interface Objects andOutside for theDestination Interface Objects.
• On theTranslation tab, selectWebserver_Private as theOriginal Source and forTranslated Source, selectAddress > Webserver_Public- ClickOk andsave the NAT policy.

Step 7: Repeat Steps 4 to 6 to complete objects, rules and NAT for inbound SMTP (mail) access. Create objects that reference the relevant IP addresses for the public and private address for your mail server.

Step 8: Next, create a rule to allow general Internet access from the inside network. If not already open, Navigate to Policies > Access Control and edit your access control policy by clicking the pencil icon.

Step 8a: Click+Add Rule and configure the general rule options as below inFigure 12:

📘

Note

We're inserting the rule below rule number 2 (our Inbound Web Access rule) as this follows our best practice of placing more specific rules above more general rules.

Step 8b: As done in the Inbound Web Access rule, add the matching criteria for the rule, including zones, applications and logging options. Use the following example settings:

• Zones tab: Source Zone =Inside, Destination Zone =OutsideFigure 13

• Applications tab: AddDNS,HTTP,HTTPS andFTP to theSelected Applications and Filters boxFigure 14

• Logging tab: Check bothLog at Beginning &End of Connection and Send Connection Events toEvent ViewerFigure 15

Step 8c: ClickAdd and then clickSave to commit your changes to the policy.

Step 8d: To accompany the Outbound Internet rule, we need a NAT rule for connections that originate from our internal (private) network, going to the Internet with a valid, publicly routable IP address. Navigate toDevices > NAT and edit your NAT policy by clicking thepencil icon.

Step 8e: Click+Add Rule. This time we're going to use aDynamicAuto NAT Rule to translate connections leaving the firewall from inside to outside by translating them using a range of public IP addresses. Complete the rule using the detail below andFigure 17 as reference.

• UnderNAT Rule, selectAuto NAT Rule.

• ForType, selectDynamic

• On theInterface Objects tab, selectInside for theSource Interface Objects andOutside for theDestination Interface Objects.

• On theTranslation tab, selectyour internal subnet as theOriginal Source and forTranslated Source, selectAddress and then click the + sign to add a new network object.

• Give the new object a name (e.g.Example_NAT_Pool), select Range, and enter a valid public IP address range from your available public address space. Enter the range in the form ofx.x.x.x-x.x.x.x (see Figure 18 as an example).

📘

Note

A more straightforward way of achieving this is to have all outbound traffic use the outside interface's IP address as a translated source address to negate the need to create a NAT pool/range object. This configuration is useful for smaller or remote office deployments where the number of concurrent outbound connections is relatively low.

• ClickSave to save the new network object and select it from the drop-down list underTranslated Source.- ClickOk andsave the NAT policy.

Step 8f: Apply URL control to access control rules (optional). If you have aURL license for your deployment, it is possible to control the categories of websites that your users can access. URL control uses the Talos web category database that provides control of 85+ content and threat categories.

Step 8g: Navigate toPolicies > Access Control and edit your access control policy by clicking the pencil icon. Edit the rule created above inStep 8a Outbound Internet).

Step 8h: Move to theURLs tab for the rule and add the categories you want to allow (or deny if the rule is a block rule) to theSelected URLs box.

📘

Note

You can control access based on ANY URL within a category or URLs with a specific reputation score.

Step 9: The final rule in our example is to allow connections between the inside network and the DMZ for backend communications between the web server and internal databases or for other required application traffic. This rule does not require NAT, as the DMZ networks and inside are private, so we control the routing. However, to add additional security, we will see how to attachIntrusion Prevention,File andMalware control to the access policy rules.

📘

Note

A valid THREAT license (subscription) is required to use Intrusion policies, and a valid Malware license (subscription) is required to enable Malware & File control.

Step 9a: Before we add a rule to our access control policy, we need to create a File & Malware policy to attach to our new rule. Navigate toPolicies > Malware & File and clickNew File Policy. Give the file policy a name, e.g. Block Malware & Executables

Step 9b: Click +Add Rule and configure as per Figure 21 below to block executable files and clickSave.

Step 9c: Click+Add Rule again and configure as per Figure 22 below to block traffic identified as containing malware.

📘

Note

Under File Type Categories, select all except for Executables (we're blocking these in the previous rule), Dynamic Analysis Capable and Local Malware Analysis Capable.

Step 9d: ClickSave to save the rule and thenSave again to commit the changes to our Malware & file Policy.

Step 9e: Navigate toPolicies > Access Control and edit your access control policy by clicking thepencil icon. Click+Add Rule and complete the general rule options as shown here in Figure 23.

Step 9f: Next, add a rule to allowANY connections between theInside andDMZ zones.Note: After adding the zones, all other tabs can be left as default (any).

Step 9g: To add Intrusion Prevention (IPS) to traffic that matches this rule, move to theInspection tab and select theBalanced Security and Connectivity Intrusion Policy. Using this base policy adds a default SNORT policy to the rule to identify threats and vulnerabilities that may be present in the traffic. IPS is backed by Cisco's Talos organization, which is comprised of world-class threat hunters and security intelligence gathered worldwide.

Step 9h: ForFile Policy, select the Malware & File Policy we created inStep 9a.

Step 9i: ClickSave to save the rule. Your Access Control Policy should look similar to Figure 27:

📘

Note

For the last rule, notice that the Intrusion Policy and Malware & File Policy icons are active. The icons indicate that the rule has advanced inspection options enabled.

Step 9: ClickSave to save the changes to the access control policy.

Step 10: The access control policy is now ready to deploy to your device. Navigate toDeploy > Deploy this device icon to the right of the device to begin deployment.

Step 11 Once the deployment begins click on theLock icon toUnlock the access control policy so that other administrators can make additional changes to the policy if needed.

Verification/Troubleshooting

To verify your configuration, check that you can access devices/networks as per your access rules. For example, check that a device (e.g. a web browser) can access your webserver from the Internet. Also, check that users on the internal network can access the Internet.

If connectivity isn't as expected, check the event logs for details. Remember, we enabled logging on all rules to get this valuable information.

Navigate toAnalysis > Unified Events and verify that you can see connection events related to your activity. Then confirm that theaction for that event is what you expect (e.g. allowed/blocked). If not, verify your access control policy rules have the correct action defined. It's a common mistake to create a rule and forget to change the action to the desired option.

Summary

Access Control policies are a crucial component of your Secure Firewall deployment. They allow you to map your organization's security strategy and policies to the network connections traversing your firewall or firewalls. Granular and flexible, they enable configurations that protect and control up to the application layer. When combined with Intrusion and Malware policies, the firewall becomes a powerful, multifaceted threat defense solution.

📚 Additional Resources

For more information about the Cisco Secure Firewall, please see the following resources:

• Firewall Management Center Configuration Guide v7.2

• Cisco Secure Firewall YouTube Channel

Updated over 3 years ago