1. Modular Policy Framework (MPF)
ASA
Modular Policy Framework
(MPF)
NetWork Training Center N.T.C
Teymur Azimov

2. ACLs alone, packets are permitted or denied based on the information that can be found in the packet headers. Although that approach does offer granular control over things such as source and destination addresses and Layer 3 and 4 protocols and port numbers, it still treats all types of traffic identically once the packets are permitted or denied. For eaxmple Babek need to examine specific application protocols with a deep packet inspection. To make sure that hosts are using the protocols correctly. Sometimes WE use an intrusion prevention system (IPS) process to detect and prevent any malicious activity. Functions such as these are not possible with simple interface ACLs.
ASA offers much more flexibility through its Modular Policy Framework (MPF).
With the MPF feature, WE can define a set of policies that identifies traffic and then takes some specific actions on it. MPF as a set of three nested items:
A service policy: An entire set of policies that is applied to one or all ASA interfaces,
configured with the service-policy command.
A policy map: Where an action is taken on matched traffic, configured with the
policy-map command
A class map: Where specific traffic flows are identified or classified, configured
with the class-map command

3. 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.
Configuring Modular Policy Framework consists of the following tasks:
1. Identify the traffic on which WE want to perform Modular Policy Framework actions by creating Layer 3/4 class maps.
For example, WE might want to perform actions on all traffic that passes through the ASA; or We might only want to perform certain actions on traffic from /24 to any destination address.

4. 2. If one of the actions WE want to perform is application inspection, and We want to perform additional actions on some inspection traffic, then create an inspection policy map. The inspection policy map identifies the traffic and specifies what to do with it.
For example, Sahib might want to drop all HTTP requests with a body length greater than 1000 bytes.
If Ferid want to match text with a regular expression within inspected packets, he can create a regular expression or a group of regular expressions (a regular expression class map). Then, when WE define the traffic to match for the inspection policy map, WE can call on an existing regular expression.
For example, WE might want to drop all HTTP requests with a URL including the text
“milli.az”

5. 3. Define the actions WE want to perform on each Layer 3/4 class map by creating a Layer 3/4 policy map. Then, determine on which interfaces Hikmet want to apply the policy map using a service policy.

7. To get an idea of the MPF structure, WE look at the policies that are configured by
default in an ASA. First, WE can use the show running-config service-policy command
to see which service policies have been defined and applied to the ASA interfaces.
Service policy that refers to something called global_policy, which has been applied globally to all ASA interfaces. A service policy always references a policy map—the next level down in the MPF hierarchy.
Default Service Policies
ciscoasa# show running-config service-policy
service-policy global_policy global
ciscoasa#
WE know that the name of the policy map is global_policy, but what does it do? Next,
WE can look for the policy map configuration to find out.
Policy Map Configuration

8. Policy Map Configuration
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

9. 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.
What sort of traffic is being classified in the policy map? To find out,
WE need to look at the configuration of a class map called inspection_default.
Class Map Configuration
ciscoasa# show running-config class-map inspection_default !
class-map inspection_default
match default-inspection-traffic
ciscoasa#

10. Simple Hierarchy of the Default MPF Configuration
service-policy pmap1
policy-map pmap1
class cmap1
action ...
class-map cmap1
match ...

11. MPF supports these features:
TCP normalization, TCP and UDP connection limits and timeouts, and TCP sequence number randomization
CSC (content security control)
Application inspection
IPS
QoS input policing
QoS output policing
QoS priority queue

12. What can WE configure in a policy map ?
The following list describes the actions that an ASA can take on traffic it encounters:
Apply application inspection engines: We can tailor the stateful inspection
process that is performed on a very specific type of traffic. Different sets of traffic
can be inspected differently.
Set connection limits: The ASA can control the volume of UDP and TCP connections
that are initiated for matched traffic.
Adjust TCP parameters: Values carried in the TCP header can be inspected,
changed, or normalized to conform to configured limits in very specific ways. This
can be done differently for each set of traffic identified
Limit management traffic: Connections that terminate on the ASA itself can be
limited, just like other types of connections that pass through the ASA. Configuring
limits on management traffic can help prevent unnecessary strain on the ASA’s CPU.
Send traffic to a Security Services Module (SSM): Specific traffic can be
diverted to an embedded Advanced Inspection and Prevention (AIP) module or an
embedded Content Security and Control (CSC) module.

13. Limit the bandwidth used: WE can tailor traffic policers to limit the bandwidth
used by predefined sets of traffic. For example, mission-critical applications might be
allowed to use any available bandwidth, whereas peer-to-peer file sharing applications
are limited to a small portion of interface bandwidth.
Provide priority handling: Specific types of traffic can be given priority over other
types as packets are sent out an interface. This allows time-critical applications to
receive premium service as those packets are inspected and passed through the ASA.
As a rule, remember the following security policy building blocks and their functions:
■ Class map: Which traffic will be matched?
■ Policy map: What action will be taken on each class of traffic?
■ Service policy: Where will the policy map be applied?

14. WE can configure security policies according to the following broad categories
OSI Layers 3 and 4: Match and take action based on information found in the
Layer 3 and 4 headers, such as IP address, protocol, and port numbers.
OSI Layers 5–7: Match and take action on traffic flows, based on information
found in the application layer content of packets
Management traffic: Match and take action on traffic that terminates on the ASA
itself, rather than passing through the ASA

16. We can use the following steps to configure a security policy, first with the CLI or
with ASDM:
Step 1. Define a Layer 3–4 class map.
Step 2. Define a Layer 3–4 policy map.
Step 3. Apply the policy map to the appropriate interfaces.
Step 1: Define a Layer 3–4 Class Map
As traffic moves through an ASA, it can be identified or classified according to the matching
conditions defined in a class map. WE can configure multiple class maps to identify
several different classes of traffic, if needed. Then a different policy can be applied to
each traffic class.
First, identify the class map with the class-map command, as follows:
ciscoasa(config)# class-map class_map_name
ciscoasa(config-cmap)# description text

17. All traffic: All packets passing through an ASA interface
■ Default traffic: Packets that belong to a predefined set of protocols and port numbers
■ Traffic flow: Packets destined for a unique IP address, where the policy action will
be applied on a per-flow basis
■ Destination port: Packets being sent to a destination port number or range of
port numbers
■ Access list: Packets that are permitted by an access list, matched according to protocol,
IP addresses, and port numbers
■ QoS values: Packets that contain up to four matching IP precedence values or up to
eight matching Differentiated Services Code Point (DSCP) values
■ RTP port range: Real-time Transport Protocol (RTP) packets that fall within a range
of UDP port numbers
■ VPN group: Packets that pass through a specific VPN tunnel group name

18. Match Commands Used in a Class Map
Matching Condition Command Syntax
Any traffic ciscoasa(config-cmap)# match any
Default traffic types ciscoasa(config-cmap)# match default-inspection-traffic
Traffic flow ciscoasa(config-cmap)# match flow ip destination-address
Destination port Number
ciscoasa(config-cmap)# match port {tcp | udp} {eq port | range
start end}
Access list
ciscoasa(config-cmap)# match access-list acl_name
QoS: IP precedence
ciscoasa(config-cmap)# match precedence value1 [value2 [value3
[value4]]]
QoS: DSCP
ciscoasa(config-cmap)# match dscp value1 [value2 ...[value8]]
RTP port number range
ciscoasa(config-cmap)# match rtp starting_port range

19. VPN tunnel group name
ciscoasa(config-cmap)# match tunnel-group
Configuring Three Class Maps
ciscoasa(config)# class-map anything
ciscoasa(config-cmap)# match any
ciscoasa(config-cmap)# exit !
ciscoasa(config)# class-map voice
ciscoasa(config-cmap)# match rtp
ciscoasa(config)# access-list extended dc permit ip any
ciscoasa(config)# class-map data-center
ciscoasa(config-cmap)# match access-list dc
From

20. Step 2: Define a Layer 3–4 Policy Map
Security policies are defined in a policy map as a sequence of match-action pairs. Each
security policy references a class map to match traffic, followed by one or more actions to
take on the matched traffic.
First, identify the policy map with the policy-map command, as follows:
ciscoasa(config)# policy-map policy_map_name
ciscoasa(config-pmap)# description text
Give the policy map an arbitrary name as policy_map_name, and then use the
description command to describe the purpose of the policy map.
Next, use the class command to identify a class map that will be used to match or classify
traffic, as follows:
ciscoasa(config-pmap)# class {class_map_name | class-default}

21. Choose an action to take on any traffic that is matched or classified by the class
map. The following list summarizes the actions that are possible;
Set connection limits:
Adjust TCP options:
Inspect the traffic with an application inspection engine:
Inspect the traffic with an intrusion prevention system (IPS) or Content
Security and Control (CSC) module:
Police or shape the traffic to control the bandwidth used:

23. Configuring a Policy Map with Three Security Policies
ciscoasa(config)# policy-map p1
ciscoasa(config-pmap)# class anything
ciscoasa(config-pmap-c)# set connection ...
ciscoasa(config-pmap-c)# inspect ...
ciscoasa(config-pmap-c)# class voice
ciscoasa(config-pmap-c)# priority
ciscoasa(config-pmap-c)# exit
ciscoasa(config-pmap)# class data-center
ciscoasa(config-pmap-c)# set connection timeout ...
ciscoasa(config-pmap)# exit

24. Step 3: Apply the Policy Map to the Appropriate Interfaces
The entire policy map is applied to one or all ASA interfaces, where the classifications and actions are carried out. Use the following command to define a service policy that binds a policy map to an interface:
ciscoasa(config)# service-policy policy_map_name {global | interface if_name}
The ASA supports only one global service policy
Remember that a global service policy is configured by default. Therefore, WE cannot add a second global service policy; WE can
edit the existing one or WE can remove it and add a different one in its place.
ciscoasa(config)# service-policy p1 interface outside

25. ciscoasa(config)# class-map class_map_name
MPF Structure for the TCP Normalizer
ciscoasa(config)# class-map class_map_name
ciscoasa(config-cmap)# match condition
ciscoasa(config-cmap)# exit
ciscoasa(config)# policy-map policy_map_name
ciscoasa(config-pmap)# class class_map_name
ciscoasa(config-pmap-c)# set connection advanced-options tcp-map
ciscoasa(config-pmap-c)# exit
ciscoasa(config-pmap)# exit
ciscoasa(config)# service-policy policy_map_name interface interface

26. Enabling ICMP and ICMP Error Inspection Globally
ciscoasa(config)# policy-map global_policy
ciscoasa(config-pmap)# class inspection_default
ciscoasa(config-pmap-c)# inspect icmp
ciscoasa(config-pmap-c)# inspect icmp error
ciscoasa(config-pmap-c)# exit
ciscoasa(config-pmap)# exit
ciscoasa(config)#
Configuring Dynamic

27. Configuring HTTP Inspection for Specific Traffic on an Interface
ciscoasa(config)# access-list MYHTTP extended permit tcp any
eq www
ciscoasa(config)# class-map CMAP_HTTP
ciscoasa(config-cmap)# match access-list MYHTTP
ciscoasa(config-cmap)# exit
ciscoasa(config)# policy-map MYPOLICY
ciscoasa(config-pmap)# class CMAP_HTTP
ciscoasa(config-pmap-c)# inspect http
ciscoasa(config-pmap-c)# exit
ciscoasa(config-pmap)# exit
ciscoasa(config)# service-policy MYPOLICY interface outside

28. THANKS