标签：
A Cisco ASA can maintain the state of connections passing through it in order to provide effective security. Connection state involves parameters such as address translation, connection
direction and flow, and limits on the connection itself. In addition, an ASA must be able to inspect various protocols as they pass through, so that the protocols themselves meet criteria defined in the security policies.
Traffic inspection can be one of the most complex functions to perform and configure.
A Cisco ASA offers many robust traffic inspection features that you can leverage to secure a network in a variety of ways. The key to using these features lies in understanding the modular approach to configuring security policies.
A robust security appliance should also be able to identify specific traffic flows and apply the appropriate security policies to them.
Fortunately, the ASA offers much more flexibility through its Modular Policy Framework (MPF). In a nutshell, the MPF provides an organized and scalable means of defining inspection policies for network traffic flows. With the MPF feature, you can define a set of policies that identifies traffic and then takes some specific actions on it. The MPF doesn’t replace the use of ACLs—it simply augments ACLs with additional functionality.
The MPF concept might be confusing at first, especially when you begin trying to configure it or reverse engineer it for the first time. Think of the MPF as a set of three nested items:
Because the MPF is designed to be modular, a service policy can contain one or more policy maps, which can, in turn, contain one or more class maps. As well, any class maps you define can be referenced in multiple policy maps and service policies.
To get an idea of the MPF structure, you can look at the policies that are configured by default in an ASA. First, you can use the show running-config service-policy command to see which service policies have been defined and applied to the ASA interfaces.
ciscoasa# show running-config service-policy service-policy global_policy global ciscoasa#
A service policy always references a policy map—the next level down in the MPF hierarchy.
Now you know that the name of the policy map is global_policy, but what does it do? Next, you can look for the policy map configuration to find out. Use the show running-config
policy-map global_policy command to display its contents
ciscoasa# show running-config policy-map global_policy ! policy-map global_policy class inspection_default inspect dns preset_dns_map inspect ftp inspect h323 h225 inspect h323 ras inspect rsh inspect rtsp inspect esmtp inspect sqlnet inspect skinny inspect sunrpc inspect xdmcp inspect sip inspect netbios inspect tftp inspect ip-options ! ciscoasa#
Notice how the policy map named global_policy begins with a class command and then contains a long list of inspect commands. A policy map must always classify or identify traffic first and then take some action on it. The class command references a class map that does the actual traffic classification, while the inspect commands define each of the actions that must be taken on the matching traffic.
One more thing—what sort of traffic is being classified in the policy map? To find out, you need to look at the configuration of a class map called inspection_default. You can do that by using the show running-config class-map inspection_default command
ciscoasa# show running-config class-map inspection_default ! class-map inspection_default match default-inspection-traffic ! ciscoasa#
The service policy references a single policy map, which references a single class map. Keep in mind that you can leverage the MPF to create much more robust or complex policy configurations, where a list of policy maps can use multiple class maps and actions to treat many different traffic flows in unique ways.
service-policy pmap1 policy-map pmap1 class cmap1 action ...
class-map cmap1 match ...
标签：
原文地址：http://www.cnblogs.com/elewei/p/4898709.html
