When you configure firewall rules policies, you should keep in mind the logical order in which the rules are processed. For example, if you plan to drop all traffic of a certain type in an access rule, there is no reason to create rules in other firewall policies that apply to that type of traffic, because they will never be triggered. Conversely, if you want to apply certain types of inspection or web filtering on traffic, you must ensure that your access rules first allow that traffic to enter the device.

Following is the general logical processing order of firewall rules:

• AAA rules—If you require authentication, with or without authorization, the user must successfully pass the test or the traffic is dropped.

• Access rules (In direction)—The traffic must then get through your access rules. If you used AAA rules, you might have allowed temporary per-user access rules to be configured for the user’s session. These per-user rules are configured in your AAA server, not in Security Manager.

  On ASA 8.3+ devices, global access rules are then processed after any interface-specific access rules. For more information, see Understanding Global Access Rules.

• Inspection rules (In direction), web filter rules (In direction), botnet rules, service policy rules (IPS, QoS, Connection)—All of these are applied to the traffic. For devices that do not allow you to configure the direction, all rules are considered to be in the In direction.

• Zone-based firewall rules—If you configured zone-based rules for an IOS device, these rules replace inspection and web filter rules (botnet rules do not apply to IOS devices).

• Routing protocols are then applied to the traffic. The traffic is dropped if it cannot be routed. (Routing policies are in the Platform folders for the various device types and are not considered firewall policies.)

• ScanSafe Web Security policies, Inspection rules (Out direction), web filter rules (Out direction)—For IOS devices only, if you created ScanSafe policies, or inspection or web filter rules in the Out direction, they are now applied.

• Access rules (Out direction)—Finally, the traffic must pass through any Out direction access rules.

Transparent rules do not fit into this picture. Because transparent rules apply to non-IP layer-2 traffic only, if a transparent rule applies to a packet, no other firewall rule applies to it; and conversely, if other rules apply, the transparent rule never applies.

Devices that support firewall rules also allow you to configure network address translation (NAT). NAT substitutes the real address in a packet with a mapped address that is routable on the destination network.

If you configure NAT to occur on an interface, the firewall rules that are also configured on that interface should assess traffic based on the translated address rather than on the original (pre-NAT) address, with the exception of ASA 8.3+ devices.

Devices running ASA software release 8.3 and later use the original, or real, IP address when evaluating traffic with the exception of IPSec VPN traffic policies. Thus, when you configure firewall rules, ACL policy objects, or the IOS, QoS, and connection rules platform service policy, ensure that you use the original addresses.

For more information about NAT, see the following topics:

• ASA, PIX, FWSM devices—Understanding Network Address Translation.

• IOS devices—NAT Policies on Cisco IOS Routers.

Security Manager tries to preserve user-defined access control list (ACL) names as they appear in device configurations. Security Manager can preserve the ACL names configured on a device in the following circumstances:

• If the ACL name is specified in Security Manager.

For access rules policies, you can specify ACL names in Firewall > Settings > Access Control or Firewall > Settings > IPv6 Access Control. You can specify a given name for a single interface and direction, but the name is used for any other interfaces and directions that use the same ACL. Keep in mind that you cannot use the same name as an ACL policy object that you assign to other policies on the device, and you cannot use the same name for IPv4 and IPv6 ACLs.

Note

Prior to the release of Security Manager 4.4 and versions 9.0 and later of the ASA, separate pages, policies and policy objects were provided for configuring IPv4 and IPv6 firewall rules and policies. With Security Manager 4.4 and ASA 9.0+, these policies and policy objects were combined or unified. However, for the earlier ASA versions, a separate page for IPv6 access rules is still provided in Device view, while in Policy view, IPv4 and unified versions of the AAA-, access- and inspection-rule policy types are provided.

• If a policy uses an ACL policy object, the name of the policy object is used for the ACL name. ACL policy objects created during discovery use the name of the ACL defined on the device whenever possible. Behavior depends on an administrative setting:

  • If you select Allow Device Override for Policy Objects in Tools > Security Manager Administration > Discovery, if a policy object with the same name exists in Security Manager, but it has different content, the name is reused and a device-level override is created.

  • If you do not select that option, a new policy object is created with the same name but with a number appended to it, for example, ACLobject_1. This is the default behavior.

• If you select Reuse Existing Names for the Firewall Access List Names setting in Tools > Security Manager Administration > Deployment, names defined on the device are reused for firewall rules that generate ACLs.

• If the ACL is unshared, even if you change the content of the ACL in Security Manager.

• If the ACL is shared, but the policies that share the ACL are defined identically in Security Manager. If you change the content of the ACL, one ACL retains the name and the others are assigned generated names.

Note

On ASA devices and on PIX devices not running version 6.3(x), Security Manager does not reuse the ACL name if it is used by a NAT policy static rule and contains an object-group. The ACL is deployed with the contents of the object-group defined as the source. This is because the device requires that all ACEs in the ACL have the same source.

Rules tables in Security Manager display sets of rules (for example, access rules) that make up a policy. These types of tables are used in only a select group of policies, but many of the firewall services rules policies use them. Rules tables are used when the order of the rules within the policy matter.

The below figure details the features in rules tables.

Following is an explanation of the numbered call-outs of the rules table features:

• Device and policy identification banner (1)—The banner provides information about policy sharing and inheritance and includes the ability to perform some actions. For detailed information, see Using the Policy Banner.

• Table filter (2)—You can filter the rules displayed to help you find rules in a large table. For more information, see Filtering Tables.

• Table column headings (3)—You can sort by column and move, show, and hide columns. For more information, see Table Columns and Column Heading Features.

• Rules, Workarea (4)—The body of the table shows the rules that are included in the policy.

• User-defined sections (5)—You can group rules into sections for your convenience. For more information, see Using Sections to Organize Rules Tables.

• Table buttons (6)—Use the buttons below the table to do the following:

  • Enable automatic conflict detection (Access Rules only). For more information, see Using Automatic Conflict Detection.

If conflict detection is enabled, you can click the Generate Report button to create an HTML report of the conflicts that can be printed or exported to another tool.

When you first open the Access Rules page, the Generate Report button is replaced with a progress bar. After conflict analysis has completed, the Generate Report button becomes available along with the other conflict detection features.

• Update the hit count information displayed in the table. For more information, see Viewing Hit Count Details and Hit Count Selection Summary Dialog Box.

• Run a policy query, which can help you evaluate your rules and identify ineffective rules. See Generating Policy Query Reports.

• Find and replace items within rules (button with the binoculars icon)—For more information, see Finding and Replacing Items in Rules Tables.

• Move and rearrange rules (up and down arrows)—For more information, see Moving Rules and the Importance of Rule Order.

• Add rules to the table (+ icon)—For more information, see Adding and Removing Rules.

• Edit the selected rule (pencil icon)—For more information, see Editing Rules.

• Delete the selected rule (trash can icon)—For more information, see Adding and Removing Rules.

• Conflict Navigation Bar (7)—Use the Conflict navigation bar to navigate to conflicting rules in the rules table. For more information, see Using Automatic Conflict Detection.

When you work with policies that use rules tables, like many of the firewall rules policies, you can add rules to the policy using several methods:

• Add Row button (+ icon)—Clicking the Add Row button beneath the table is the standard method to add a new rule. Clicking this button opens the dialog box for adding rules that is specific to that type of policy. If you select a row or section heading, the new rule is added after the selected row. Otherwise, it is added at the end of the appropriate scope (typically, the local scope).

• Right-click a row and select Add Row—This is equivalent to selecting a row and clicking the Add Row button.

• Copy and paste—If you want to create a new rule that is similar to an existing rule, you can select the rule, right-click and select Copy, then select the row after which you want to place the rule, right-click and select Paste. This creates a duplicate rule, which you can select and edit (see Editing Rules).

• Cut and paste—Cut and paste is similar to copy and paste, except you are deleting the existing rule when you select the Cut command. Instead of cut and paste, consider moving the rule (see Moving Rules and the Importance of Rule Order).

When you no longer need a rule, you can remove it by selecting the rule and clicking the Delete Row button (trash can icon).

Tip

Rather than deleting a rule, consider first disabling the rule. By disabling a rule, you remove it from the device (when you redeploy the configuration) without removing it from Security Manager. Then, if you discover that you really needed that rule after all, you can simply enable it and redeploy the configuration. If you delete the rule, you would have to recreate it (there is no undo function). Thus, you might want to develop a policy of deleting rules only after they have been disabled for a certain amount of time. For more information, see Enabling and Disabling Rules.

To edit an existing rule in any of the rules policies that use rules tables, select the rule and click the Edit Row button, or right-click and select Edit Row. This allows you to edit all aspects of the selected rule.

Tip	You cannot edit any aspect of an inherited rule from a local device rule policy. Edit inherited rules in Policy view.

For most rule tables, you can also edit specific attributes, or table cells, instead of editing the entire rule, using commands in the right-click menu.

The ability to edit a cell is limited by whether it makes sense to edit the content. For example, Inspection Rules have many limitations based on how the rule is configured:

• If you applied the rule to All Interfaces, you cannot edit source or destination addresses, the interface, or the direction of the rule.

• If you selected Default Inspection Traffic for the traffic match criteria (without selecting the option to limit inspection between source and destination), or Custom Destination Ports, you cannot edit source or destination addresses.

• If you selected Destination Address and Port (IOS), you cannot edit source addresses.

The following cell-level commands are available, although the ability to edit multiple rows is not supported in all policies that use rule tables:

• Add <Attribute Type>—When you select multiple rows and right-click a Source, User, Destination, Services, or Interface cell, you can select the Add command to append entries to the data currently in the selected cells. The Add command’s full name includes the name of the attribute, for example, Add Source.

• Edit <Attribute Type>—Most attributes allow you to edit the content. Editing replaces the content of the cell. You can edit a single cell, or select multiple rows and edit the contents of the same type of cell in all rows at once. The Edit command’s full name includes the name of the attribute, for example, Edit Interfaces.

• Edit <Entry>—In some cases, when you edit Source, User, Destination, Services, or Interfaces, you can select an entry in the cell and edit just that entry. For example, if the Sources cell contains three network/host objects and an IP address, you can select any of them and edit the entry. The edit command includes the name of the entry, for example, Edit HostObject.

• Remove <Entry>—In some cases, when you edit Source, User, Destination, Services, or Interfaces, you can select an entry in the cell and remove the entry. You cannot remove the last entry in the cell, because the rule would become invalid. The remove command includes the name of the entry, for example, Remove IP.

• Create <Object Type> Object from Cell Contents—In the Sources, User, Destinations, and Services cells, you can select the Create command to create a policy object of the appropriate type. You can also select an entry in the cell and create a policy object from just the selected item. The create command includes the policy object type you can create, and the name of the item that is the source for the object, either cell contents for everything in the cell, or the name of an entry if you selected one. When creating network/host objects, you are always creating network/host group objects.

• Show <Attribute Type> Contents; Show <Entry> Contents—The show commands let you view the actual data defined in the cell. The results depend on the view you are in:

  • Device View, Map View, or Import Rules—You are shown the actual IP addresses, fully-qualified domain names (FQDNs), services, or interfaces to which the rule will apply for the specific device. For example, if the rule uses network/host objects, you will see the specific IP addresses or FQDNs defined by the objects. If the rule uses interface objects, you will see the specific interfaces defined on the device that the object identifies, if any.

The IP addresses for network/host objects are sorted in ascending order on the IP address, and then descending order on the subnet mask.

Service objects are sorted on protocol, source port, and destination port.

Interface objects are listed in alphabetical order. If the interface is selected because it matches a pattern in an interface object, the pattern is listed first, and the matching interface is shown in parentheses. For example, “* (Ethernet1)” indicates that the Ethernet1 interface on the device is selected because it matches the * pattern (which matches all interfaces).

• Policy View—You are shown the patterns defined in the policy objects and entries defined for the policy. Entries are sorted alphabetically, with numbers and special characters coming first.

In policies that use rules tables, you can search for items in some cells and selectively replace them. The cells that you can search depend on the policy. You can use wildcard characters to find items based on pattern matching, for example, so that you can replace several related networks with a new network/host policy object defined for them.

To use find and replace, click the Find and Replace (binoculars icon) button at the bottom of any policy that uses rules tables to open the Find and Replace Dialog Box. In the Firewall folder, this includes AAA rules, access rules, IPv6 access rules, inspection rules, zone based firewall rules, and web filter rules (for ASA/PIX/FWSM devices only). For ASA/PIX/FWSM devices, it also includes the NAT translation rules policy (but not for every combination of context and operational mode) and the IOS, QoS, and connection rules platform service policy.

When searching for items, you select the type of item, the columns you want to search, and enter the string that you want to find and optionally, the string you want to use to replace it. You can find and replace the following types of items:

• Network—A network/host object name, or the IP address of a host or network.

• User—An Active Directory (AD) username (NetBIOS_DOMAIN\user), user group name (NetBIOS_DOMAIN\\user_group), or identity user group object name.

• Service—A service object name or protocol and port, for example TCP/80. The search is syntactic, not semantic, that is, if you are searching for TCP/80 and a rule uses HTTP, the search results will not find it.

• Interface Role—An interface name or interface role object name.

Note

In access rules, you can search for global rules by using the Global interface name. However, there is no way to convert between global and interface-specific rules. Although you can find global rules using the Global interface name, if you try to replace an interface name with the name “Global,” you are actually creating an interface-specific access rule that uses a policy object named Global.

• Text—A text string in a Description field.

The following are some examples of what you might do with find and replace:

• If you create a new network/host object named network10.100 for all networks in the 10.100.0.0/16 range, you can search and replace all subordinate network specifications. For example, you can search for ^10.100* to find all addresses like 10.100.10.0/24. Select the Find Whole Words Only and Allow Wildcard options, and enter network10.100 as the replacement string. Because you selected Find Whole Words Only, the string that is replaced is the entire 10.100.10.0/24 string, not just the 10.100 portion.

• If you want to find all rules that use IP addresses (instead of network/host objects), you can search for *.*.*.* to find all host or network IP addresses. You can then selectively edit the cell while the Find and Replace dialog box is open.

• If you want to replace all interface role objects that include “side” in the name (such as inside and outside) with the interface role object named External, search for *side with the Find Whole Words Only and Allow Wildcard options selected, and enter External in the Replace field.

Rules policies that use rules tables are ordered lists. That is, the top to bottom order of the rules matters and has an effect on the policy.

When the device analyzes a packet against a rules policy, the device searches the rules in order from top to bottom. The first rule that matches the packet is the rule that is applied to the packet, and all subsequent rules are ignored. Thus, if you place a general rule pertaining to IP traffic before a more specific rule pertaining to HTML traffic for a given source or destination, the more specific rule might never be applied.

For access control rules, you can use the automatic conflict detection tool to help identify when rule order will prevent a rule from ever being applied to traffic (for more information, see Using Automatic Conflict Detection). For other rules policies, carefully inspect the table to spot problems with rule order.

When you find that you need to rearrange the order of a rule, select the rule that needs to be moved and click the Up Row (up arrow) or Down Row (down arrow) buttons as appropriate. If these buttons do not appear beneath the rules table, rule order does not matter and you cannot rearrange them.

If you use sections to organize your rules, you can move rules only within the section. When you move rules that are outside the sections, you can move them above or below the section. For more information about working with sections, see Using Sections to Organize Rules Tables.

Tip	Special rules apply to moving access rules when you mix interface-specific and global rules in a policy. For more information, see Understanding Global Access Rules.

You can enable and disable individual rules in a policy that uses rules tables, such as most firewall services rules policies. Your change takes effect when you redeploy the configuration to the device.

If a rule is disabled, it appears in the table overlain with hash marks. When you deploy the configuration, disabled rules are removed from the device.

Disabled rules are kept in the rules policy in Security Manager as a convenience so that you can easily enable needed rules without recreating them. Thus, it is often wise to disable a rule that you believe you no longer need instead of immediately deleting it.

To change whether a rule is enabled or disabled, select the rule, right-click and select Enable or Disable, as appropriate.

You can organize policies that use rules tables into sections. There are two types of sections:

• Scopes, which define inheritance relationships between a policy and an inherited policy. These sections are automatically created when you inherit policies. For more information, see Understanding Rule Inheritance.

• User-defined sections, which are convenient groupings that help you organize rules so that you can evaluate and edit the policy more easily. These types of sections are most useful for policies that contain a large number of rules.

All rules within a section must be sequential; you cannot group rules randomly. If you want to identify non-contiguous rules as being related, you can assign the same category to the rules.

User-defined sections are set off visually from the other rules in the table by an indented section heading. The heading contains, left to right, a +/- icon for opening and closing the section, a band of color identifying the category you assigned the section (if any), the section name, the first and last rule number contained in the section (for example, 4-8), and the description, if any, you gave the section.

Note	You might need to resize the rule number column to see the numbering of rules in sections.

Whether you create user-defined sections is completely up to you. If you decide creating these types of sections is worthwhile, the following information explains how to create and use them:

• To create a new section, right-click a row that you want to place the section and select Include in New Section. (You can also use Shift+click to select a block of rules.) You are prompted for a name, description, and category for the section (the name is the only required element).

• To move existing rules into a section, select one or more contiguous rules, right-click and select Include in Section <name of section>. This command appears only if the selected rows are next to an existing section. If the rows you want to add to a section are not currently next to the section, you can do one of two things: move the rules until they are next to the section; cut the rules and paste them into the section.

• You cannot move a section. Instead, you need to move the rules that are outside of the section around it. When you move a rule that is next to, but not within, a section, the rule jumps over the section.

• You cannot move a rule outside of or through a section. A section defines the borders within which you can move rules. If you want to move rules out of a section and back into the Local scope section, select one or more contiguous rules, right-click and select Remove from Section <name of section>. The rules must be at the beginning or end of the section to use this command. If they are not, you can either move the rules until they are, or use cut and paste to move them out of the section.

• To add a new rule to a section, select the rule after which you want to create the rule before clicking the Add Row button. To place it at the beginning of the section, select the section heading.

If you want to create a rule after, but outside of, a section, you can either create it as the last rule in the section and then remove it from the section, or create it just above the section and click the down arrow button.

• You can change the name, description, or category of a section by right-clicking the section heading and selecting Edit Section.

• When you delete a section, all rules contained in the section are retained and moved back into the Local scope section. No rules are deleted. To delete a section, right-click the section heading and select Delete Section.

• If you use the Combine Rules tool, the resulting combined rules respect your sections. Rules that are in a section can be combined only with other rules in that section.

When you deploy firewall rules policies to an ASA, PIX, FWSM, or IOS 12.4(20)T+ device, you can configure Security Manager to evaluate and optimize the network/host policy objects that you use in the rules when it creates the associated network object groups on the device. Optimization merges adjacent networks and removes redundant network entries. This reduces the runtime access list data structures and the size of the configuration, which can be beneficial to some FWSM and PIX devices that are memory-constrained.

For example, consider a network/host object named test that contains the following entries and that is used in an access rule:

192.168.1.0/24
192.168.1.23
10.1.1.0
10.1.1.1
10.1.1.2/31

If you enable optimization, when you deploy the policy, the resulting object group configuration is generated. Note that the description indicates the group was optimized:

object-group network test
 description (Optimized by CS-Manager)
 network-object 10.1.1.0 255.255.255.252
 network-object 192.168.1.0 255.255.255.0

If you do not enable optimization, the group configuration would be as follows:

object-group network test
 network-object 192.168.1.0 255.255.255.0
 network-object 192.168.1.23 255.255.255.255
 network-object 10.1.1.0 255.255.255.255
 network-object 10.1.1.1 255.255.255.255
 network-object 10.1.1.2 255.255.255.254

This optimization does not change the definition of the network/host object, nor does it create a new network/host policy object. If you rediscover policies on the device, the existing unchanged policy object is used.

Note	If a network/host object contains another network/host object, the objects are not combined. Instead, each network/host object is optimized separately. Also, Security Manager cannot optimize network/host objects that use discontiguous subnet masks.

To configure optimization, select the Optimize Network Object-Groups During Deployment option on the Deployment Page (select Tools > Security Manager Administration and select Deployment from the table of contents). The default is to not optimize network object groups during deployment.

Note

if you have upgraded to CSM 4.19 without configuring CSM 4.17 SP1 and CSM 4.18, the deployment of a firewall that has an object-group service fails for the following objects: service-object gre service-object 41 service-object ah You must execute the following SQL queries on the DB side of the CSM server to avoid the deployment failure. $SIG{INT} = 'IGNORE'; use CRM; use DBI; use lib "$ENV{NMSROOT}/lib/perl/install"; use InstallUtility; require "$ENV{NMSROOT}/cgi-bin/dbadmin/pdbadmin/dbAdminCommon.pl"; my $DROP_CONNECTION_FLAG = false; checkDMisRunning(); &resolveGreSubTypeEntries(); sub checkDMisRunning { my $d = '\\'; my ($rc, $dmIsRunning, $line, @lines); $rc = open IN, "$ENV{NMSROOT}${d}bin${d}pdshow 2>&1 |"; if (!$rc) { print "ERROR: *** Could not execute pdshow ***\n"; print "ERROR: *** probable cause: daemon manger is corrupted ***"; exit(-1); } @lines = <IN>; $dmIsRunning = 1; for $line (@lines) { if ($line =~ m/ERROR:\s+connect\s+to\s+dmgtd.*on\s+port\s+.+failed:/) { $dmIsRunning = 0; last; } } close IN; if ($dmIsRunning) { print "Daemon manager is running ..\n"; } else { print "Daemon manager is not running ..\n"; print "Deamon manager should be running to execute this file\n"; exit(-1); } } sub resolveGreSubTypeEntries { $dsn="vms"; $node_dbh = &dbinternal::connect("dsn=$dsn"); if ($node_dbh) { print "\n*******************************************\n"; print "\nScript Execution Starts \n" ; print "\n*******************************************\n"; my $select_query = "select count(*) from BB_MAIN where OBJECTID =1106 and name='gre' and subtype!='SO'"; my $select_query_prep = $node_dbh->prepare($select_query) || die "Error preparing query" . $node_dbh->errstr; $select_query_prep->execute || die "Error executing query" . $select_query_prep->errstr; my @node_results; $impactedcount = 0; while (@node_results = $select_query_prep->fetchrow_array()) { my $size = @node_results; for (my $j=0; $j < $size; $j++) { $impactedcount = $node_results[$j]; } } if($impactedcount > 0){ my $updateQuery = "update BB_MAIN set subtype='SO' where OBJECTID=1106"; my $prep = $node_dbh->prepare($updateQuery) || die "Error preparing query" . $node_dbh->errstr; $prep->execute || die "Error executing query" . $prep->errstr; } print "\n*******************************************\n"; print "\nScript Execution Completed! \n" ; print "\n*******************************************\n"; } return 0; }

Copy the script into ~CSCOpx/bin directory and execute the following command:

C:\PROGRA~2\CSCOpx\bin\perl C:\PROGRA~2\CSCOpx\bin\resolveDBEntriesCSCvj54910.pl#!/usr/bin/perl

When you discover policies from a device that uses object groups, you can elect to have those object groups expanded into the items they contain rather than create policy objects from the group.

For example, if an object group named CSM_INLINE_55 contains the hosts 10.100.10.15, 10.100.10.18, and 10.100.10.25, importing an access control list by expanding the objects will create a rule that includes all three addresses in the source (or destination, as appropriate) cell rather than a network/host policy object named CSM_INLINE_55.

To configure expansion, you must have a naming scheme for your object groups that allows you to identify the prefix of groups that you want to expand. The default is to expand any object group that starts with the prefix CSM_INLINE. Configure these prefixes in the Auto-Expand Object Groups with These Prefixes field on the Discovery Page by selecting Tools > Security Manager Administration and selecting Discovery from the table of contents.