Defining Security Policies in a Modular Policy Framework

Traditionally, Cisco firewalls have supported security policies that are applied to all traffic passing through them. Although that does offer a common level of security to all the protected networks and hosts, it does not offer a way to fine-tune or vary the policies according to differing requirements.

Beginning with ASA 7.0(1) and FWSM 3.1(1), a Cisco firewall can be configured to provide security policies that are tailored for various traffic types, quality of service (QoS), or inspection requirements. This is known as the modular policy framework (MPF).

With the MPF feature, you can define policies to identify a specific set of traffic and take any of the following actions on it:

• Apply application inspection engines— You 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 firewall 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 in very specific ways. This can be done differently for each set of traffic identified.

• Limit management traffic— Connections that terminate on the firewall itself can be limited, just like other types of connections that pass through the firewall. Configuring limits on management traffic can help prevent unnecessary strain on the firewall CPU.

• Send traffic to a Security Services Module (SSM)— The ASA platform can divert specific traffic to an embedded Advanced Inspection and Prevention (AIP) module or an embedded Content Security and Control (CSC) module.

• Limit the bandwidth used— You 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 a firewall interface. This allows time-critical applications to receive premium service as those packets are inspected and passed through the firewall.

As shown in Figure 7-1, you can configure security policies in a modular fashion. Traffic is classified according to an arbitrary type, and a policy can take some arbitrary action on it. The policy is actually carried out on a firewall interface or globally on all interfaces. This whole process is configured in scalable pieces, according to the following model:

• Class map— A template that uses a match command to classify or identify types of traffic.

• Policy map— A list of policies, each referencing a class map to match or identify traffic and an action to take on that traffic.

• Service policy— A policy map is applied to one or all firewall interfaces, defining an entire set of match/action policies.

Figure 7-1. The Modular Policy Framework for Applying Security Policies

[View full size image]

The Modular Policy Framework is a bit of a double-edged sword. On one hand, it is a very versatile means of defining robust security policies. On the other hand, it is so versatile that it can be confusing to configure.

As you begin to configure your security policies, you should outline the structure of the policy map as a list of the individual policies. Each policy needs a class map to identify the traffic and an action to perform on the traffic.

In a sense, you have to work backward first, because you need to configure class maps to identify traffic before the policy map can reference those class maps.

Continue reading here: Classifying Layers 3 and 4 Traffic

Was this article helpful?

0 0