Filter
Top Products
16-5
User Guide for Cisco Security Manager 4.4
OL-28826-01
Chapter 16 Managing Firewall Access Rules
Understanding Access Rules
If an access rule allows TCP/UDP traffic in one direction, the appliance automatically allows return
traffic (you do not need to configure a corresponding rule for the return traffic), except for ICMP
traffic, which does require a return rule (where you permit the reverse source and destination), or
you must create an inspection rule for ICMP.
• FWSM devices—Deny all traffic entering an interface, permit all traffic leaving an interface.
You must configure access rules to allow any traffic to enter the device.
If you create any rules for an interface for any type of device, the device adds an implicit deny any rule
at the end of the policy. It is a good practice for you to add this rule yourself so that you remember it is
there. Adding the rule also allows you to get hit count information for the rule. For more information,
see Viewing Hit Count Details, page 16-33.
Tip When you create the access rule policy, ensure that you include a rule that will permit access to the
device from the Security Manager server, or you will not be able to manage the device using the product.
Related Topics
• Understanding Access Rules, page 16-1
• Understanding Access Rule Address Requirements and How Rules Are Deployed, page 16-5
Understanding Access Rule Address Requirements and How Rules Are
Deployed
One of the complexities of creating access control lists using the operating system commands on the
command line interface (CLI) is the fact that different operating systems have different IP address
formats for source and destination addresses.
For example, Cisco IOS Software requires that you enter addresses using wildcard masks instead of
subnet masks. To create a rule for the 10.100.10.0/24 network (subnet mask 255.255.255.0), you are
required to enter the address as 10.100.10.0 0.0.0.255. The 0 and 1 have the reverse meaning in a
wildcard mask that they have in a subnet mask. In ASA, PIX, and FWSM software, however, you use
subnet masks, so you enter 10.100.10.0 255.255.255.0.
Security Manager simplifies addressing requirements for access rules: you always use the subnet mask.
You are not even allowed to enter a wildcard mask. When you deploy the access rules to a device,
Security Manager considers the operating system of the device and converts subnet masks to wildcard
masks automatically when needed.
This makes it possible for you to create shared rules based on logical policies and to apply those rules
to all of your devices. For example, there might be a set of access rules that you want all devices to use,
in which case you can create the shared policy and assign it as the inherited policy for all devices. You
do not have to worry about defining rules using the “right” syntax for the device type. You can use the
same network/host objects that you use in other types of policies to identify targeted hosts and networks.
The specific CLI commands generated in deployed configurations are also based on the type of device.
For IOS devices, the ip access-list command is used. For ASA, PIX, FWSM devices, the access-list or
ipv6 access-list command is used and the access-group command binds it to the interface. With ASA,
PIX, FWSM, and IOS 12.4(20)T+ devices, if you use network/host objects to identify the source or
destination addresses for a rule, the object-group command is used to create object groups for those
network/host objects. Object groups are also created for service objects.