Security Appliance
The Security Appliance allows interfaces to be shared between contexts. This is allowed only
with adherence to the following guidelines:
■ The Security Appliance must be in routed mode.
■ The shared interface must have either a unique IP address for each context or a unique
VLAN for each context that will be using it.
After you have decided to enable shared interfaces on a Security Appliance, you must
consider several issues. To allow traffic through shared interfaces, Network Address
translation (NAT) must be enabled on that interface. The classifier used by the Security
Appliance requires an address translation configuration that classifies the packet within a
context. Using NAT translation commands, the destination address of the traffic must be
translated to comply with this restriction. This can also be achieved through the use of the
global command if NAT translation is not performed.
A restriction arises when considering where traffic flows will originate from the shared
interfaces on the Security Appliance. When dynamic NAT is used for the destination
addresses, a connection through those addresses cannot be initiated. This restricts the
interfaces in such a way that they can only respond to existing connections, and a new
connection can never be initiated. To get around this issue, static NAT must be used for the
destination addresses, allowing the interface to initiate as well as to respond to connections.
Configuring an inside shared interface might pose another potential problem when using
shared interfaces and NAT. This problem arises when communication between a shared
interface and an external network, such as the Internet, is desired and the destination
addresses are unlimited. The Security Appliance requires Static NAT translation to support
this configuration, which will limit the kind of Internet access that can be provided to users
on the inside shared interface. As previously stated, many issues must be considered before
configuring shared interfaces, especially when NAT is also deployed on the Security
Appliance. Take time to work out the design so that these issues do not hinder your network’s
stability.
with adherence to the following guidelines:
■ The Security Appliance must be in routed mode.
■ The shared interface must have either a unique IP address for each context or a unique
VLAN for each context that will be using it.
After you have decided to enable shared interfaces on a Security Appliance, you must
consider several issues. To allow traffic through shared interfaces, Network Address
translation (NAT) must be enabled on that interface. The classifier used by the Security
Appliance requires an address translation configuration that classifies the packet within a
context. Using NAT translation commands, the destination address of the traffic must be
translated to comply with this restriction. This can also be achieved through the use of the
global command if NAT translation is not performed.
A restriction arises when considering where traffic flows will originate from the shared
interfaces on the Security Appliance. When dynamic NAT is used for the destination
addresses, a connection through those addresses cannot be initiated. This restricts the
interfaces in such a way that they can only respond to existing connections, and a new
connection can never be initiated. To get around this issue, static NAT must be used for the
destination addresses, allowing the interface to initiate as well as to respond to connections.
Configuring an inside shared interface might pose another potential problem when using
shared interfaces and NAT. This problem arises when communication between a shared
interface and an external network, such as the Internet, is desired and the destination
addresses are unlimited. The Security Appliance requires Static NAT translation to support
this configuration, which will limit the kind of Internet access that can be provided to users
on the inside shared interface. As previously stated, many issues must be considered before
configuring shared interfaces, especially when NAT is also deployed on the Security
Appliance. Take time to work out the design so that these issues do not hinder your network’s
stability.
allocate-interface Command Parameters (Continued)
Parameter Description
subinterface Assigns the subinterface number. You can specify a range of subinterfaces
such as ethernet1.0–ethernet0.100
visible (Optional) Allows context users to see the physical interface properties in
the show interface command even if a mapped name is assigned.
invisible (Default) Allows context users to only see the mapped name (if configured)
in the show interface command.
The allocate-interface command can assign multiple interfaces at once, as long as they are
the same interface type or they are all subinterfaces of the same physical interface.
Each interface or group of interfaces is assigned mapped names that must adhere to the
following guidelines:
■ The mapped name must consist of an alphabetic portion followed by a numeric portion.
The alphabetic portion must be consistent throughout an assigned range of interfaces.
■ The numeric portion of the mapped name must include the same quantity of numbers as
the subinterface range.
Example 9-2 illustrates how to assign a range of interfaces to a context. Interfaces assigned
to a context are seen as the mapped name by default when a show interface command is
executed. This restricts administrators of specific security contexts from being able to see the
physical interface names. This can be changed by adding the visible attribute to the allocateinterface
command on a context. An administrator in the admin context can always see the
physical interface named.
Allocating Interfaces to a Context
pixfw1(config)# context sciencelab1
pixfw1(config-ctx)# allocate-interface gigabitethernet0/1 int0
pixfw1(config-ctx)# allocate-interface gigabitethernet1/1.1-gigabitethernet1/1.100 int1-
int100
pixfw1(config-ctx)#
NOTE If a context is configured as a transparent firewall, the context can only be
assigned two interfaces, with the exception of the management port, which can be assigned
as the third interface.
subinterface Assigns the subinterface number. You can specify a range of subinterfaces
such as ethernet1.0–ethernet0.100
visible (Optional) Allows context users to see the physical interface properties in
the show interface command even if a mapped name is assigned.
invisible (Default) Allows context users to only see the mapped name (if configured)
in the show interface command.
The allocate-interface command can assign multiple interfaces at once, as long as they are
the same interface type or they are all subinterfaces of the same physical interface.
Each interface or group of interfaces is assigned mapped names that must adhere to the
following guidelines:
■ The mapped name must consist of an alphabetic portion followed by a numeric portion.
The alphabetic portion must be consistent throughout an assigned range of interfaces.
■ The numeric portion of the mapped name must include the same quantity of numbers as
the subinterface range.
Example 9-2 illustrates how to assign a range of interfaces to a context. Interfaces assigned
to a context are seen as the mapped name by default when a show interface command is
executed. This restricts administrators of specific security contexts from being able to see the
physical interface names. This can be changed by adding the visible attribute to the allocateinterface
command on a context. An administrator in the admin context can always see the
physical interface named.
Allocating Interfaces to a Context
pixfw1(config)# context sciencelab1
pixfw1(config-ctx)# allocate-interface gigabitethernet0/1 int0
pixfw1(config-ctx)# allocate-interface gigabitethernet1/1.1-gigabitethernet1/1.100 int1-
int100
pixfw1(config-ctx)#
NOTE If a context is configured as a transparent firewall, the context can only be
assigned two interfaces, with the exception of the management port, which can be assigned
as the third interface.
allocate-interface Command Parameters
allocate-interface Command Parameters
Parameter Description
map_name (Optional) Sets a mapped name. The map_name is an alphanumeric alias
for the interface that can be used within the context instead of the interface
ID. If a mapped name is not specified, the interface ID is used within the
context
A mapped name must start with a letter, end with a letter or digit, and have
as interior characters only letters, digits, or an underscore. For example,
you can use the following names:
• Int0
• Inta
• Int_a
For subinterfaces, you can specify a range of mapped named such as
int0-int100.
physical_interface Assigns the interface ID.
Parameter Description
map_name (Optional) Sets a mapped name. The map_name is an alphanumeric alias
for the interface that can be used within the context instead of the interface
ID. If a mapped name is not specified, the interface ID is used within the
context
A mapped name must start with a letter, end with a letter or digit, and have
as interior characters only letters, digits, or an underscore. For example,
you can use the following names:
• Int0
• Inta
• Int_a
For subinterfaces, you can specify a range of mapped named such as
int0-int100.
physical_interface Assigns the interface ID.
Assigning Interfaces to a Context
Assigning Interfaces to a Context
Each context can be allocated a number of interfaces that have been enabled in the system
configuration mode. Assigned interfaces will be given a mapped name that the contexts
configuration file will reference for policies and network settings specific to the context. The
interfaces can be physical or logical, including subinterfaces. To assign one or more interfaces
to a security context, use the allocate-interface command:
allocate-interface physical_interface[map_name][visible | invisible]
allocate-interfacephysical_interface.subinterface[=physical_interface.subinterface]
[map_name[-name_name]][visible | invisible]
Table 9-2 describes the parameters for the allocate-interface command.
Each context can be allocated a number of interfaces that have been enabled in the system
configuration mode. Assigned interfaces will be given a mapped name that the contexts
configuration file will reference for policies and network settings specific to the context. The
interfaces can be physical or logical, including subinterfaces. To assign one or more interfaces
to a security context, use the allocate-interface command:
allocate-interface physical_interface[map_name][visible | invisible]
allocate-interfacephysical_interface.subinterface[=physical_interface.subinterface]
[map_name[-name_name]][visible | invisible]
Table 9-2 describes the parameters for the allocate-interface command.
Creating a New Context
Creating a New Context
Each security context will have a unique case-sensitive name, using alphanumeric characters
no longer than 32 characters. The context names are case sensitive, and a context cannot be
assigned either “System” or “Null” as names, as these are reserved by the system. To create
a context, use the context command in global configuration mode:
context [name]
The context command, when executed, will enter into a context configuration submode. In
this configuration mode, interface assignments and the location of the context firewall
configuration file are input.
Each security context will have a unique case-sensitive name, using alphanumeric characters
no longer than 32 characters. The context names are case sensitive, and a context cannot be
assigned either “System” or “Null” as names, as these are reserved by the system. To create
a context, use the context command in global configuration mode:
context [name]
The context command, when executed, will enter into a context configuration submode. In
this configuration mode, interface assignments and the location of the context firewall
configuration file are input.
Configuring Security Contexts
Configuring Security Contexts
In multiple-context mode, a security administrator can create new security contexts up to the
Security Appliances license limit. These contexts will have policies that apply only to the
interfaces that are assigned to that context. A security context contains two parts:
■ System configuration of the context—Defines the context name, VLAN, interfaces and
configuration file URL that the context will use.
■ Context configuration file—Contains all the firewall policies and interface
configurations that will be used on the context.
In multiple-context mode, a security administrator can create new security contexts up to the
Security Appliances license limit. These contexts will have policies that apply only to the
interfaces that are assigned to that context. A security context contains two parts:
■ System configuration of the context—Defines the context name, VLAN, interfaces and
configuration file URL that the context will use.
■ Context configuration file—Contains all the firewall policies and interface
configurations that will be used on the context.
Administration Context
Administration Context
Security Appliances with multiple security contexts enabled use a special context to manage
the system interfaces, as well as all other contexts contained on the firewall. As described
previously, the admin context is created by the Security Appliance when enabled in multiple
security context and uses the admin.cfg file to store the admin context configuration.
Unlike in single mode, where the system configuration controls the network resources, in
multiple-security context mode, the admin context handles all the system network resources
for the Security Appliance. This is required because the system execution space does not
contain any traffic-passing interfaces. All policies and interfaces that have been configured
on the admin context will be used by the system to communicate with other devices.
The authentication, authorization, and accounting (AAA) feature commands are not
accepted in the admin context. This will require local database credentials for individual
logins. It is recommended that restrictions be placed on logins created in the local database
to limit system execution space.
The admin context is also used to acquire a configuration file from a remote location for
another security context. Additionally, these network settings configure appropriate systemlevel
syslog options to send syslog data for remote capture.
The admin context is designed to allow a security administrator control over other security
contexts. To create new security contexts or change the admin context, a security administrator
must log into the admin context.
At times, a department or division head requires control over department or division firewall
configurations. This can be accommodated through the assignment of context administrators.
These administrators can only configure and manage the specific context to which they
are assigned and cannot configure or view system resources or the administration context.
To stop different contexts from inadvertently affecting each other, system resources and
VLAN management are done outside the multiple security contexts and within the system
configuration.
An admin context can also be used as a regular security context. This can be a bit tricky, as
all policies applied to the admin context affect the system as well as the assigned interfaces
for the context. If the first new security context is created before an admin context has been
created, the new security context is labeled as the admin context. An already configured
security context can be assigned to act as the admin context. This will convert the current
admin context to a regular security context and will install the newly assigned context as the
admin context. To do this, use the admin-context command in global configuration mode:
admin-context name
NOTE You can only use a context as an admin context if its configuration file resides on
the internal Flash memory.
Security Appliances with multiple security contexts enabled use a special context to manage
the system interfaces, as well as all other contexts contained on the firewall. As described
previously, the admin context is created by the Security Appliance when enabled in multiple
security context and uses the admin.cfg file to store the admin context configuration.
Unlike in single mode, where the system configuration controls the network resources, in
multiple-security context mode, the admin context handles all the system network resources
for the Security Appliance. This is required because the system execution space does not
contain any traffic-passing interfaces. All policies and interfaces that have been configured
on the admin context will be used by the system to communicate with other devices.
The authentication, authorization, and accounting (AAA) feature commands are not
accepted in the admin context. This will require local database credentials for individual
logins. It is recommended that restrictions be placed on logins created in the local database
to limit system execution space.
The admin context is also used to acquire a configuration file from a remote location for
another security context. Additionally, these network settings configure appropriate systemlevel
syslog options to send syslog data for remote capture.
The admin context is designed to allow a security administrator control over other security
contexts. To create new security contexts or change the admin context, a security administrator
must log into the admin context.
At times, a department or division head requires control over department or division firewall
configurations. This can be accommodated through the assignment of context administrators.
These administrators can only configure and manage the specific context to which they
are assigned and cannot configure or view system resources or the administration context.
To stop different contexts from inadvertently affecting each other, system resources and
VLAN management are done outside the multiple security contexts and within the system
configuration.
An admin context can also be used as a regular security context. This can be a bit tricky, as
all policies applied to the admin context affect the system as well as the assigned interfaces
for the context. If the first new security context is created before an admin context has been
created, the new security context is labeled as the admin context. An already configured
security context can be assigned to act as the admin context. This will convert the current
admin context to a regular security context and will install the newly assigned context as the
admin context. To do this, use the admin-context command in global configuration mode:
admin-context name
NOTE You can only use a context as an admin context if its configuration file resides on
the internal Flash memory.
Multiple Context Modes
Multiple Context Modes
A Security Appliance can support either a single or multiple context mode. In a single-mode
configuration, the Security Appliance does not separate the firewall options from the system
resources. When the multiple-contexts mode is enabled, the Security Appliance creates a new
configuration scheme. The Security Appliance separates the context options from the current
start-up configuration and places these configurations in an administrative context called the
admin context. The remaining system configurations are stored in the start-up configuration
file. The administration configuration uses the admin.cfg file. The original running
configuration is saved as old_running.cfg on the local Flash disk when the security context
mode is changed. If the running configuration differs from the start-up configuration, the
start-up configuration should also be saved manually. If you are copying a configuration
from a Security Appliance in multiple-context mode to a device configured for single-context
mode, the context mode must be manually changed, or scripted with the [noconfirm] switch
This is needed because the security context mode is not saved in the configuration file. All
mode changes must be made from the command-line interface (CLI) and cannot be done
through the Cisco Adaptive Security Device Manager (ASDM). To enable the multiplecontext
mode, use the mode command:
mode {single | multiple} [noconfirm]
With the noconfirm command syntax, the mode of the Security Appliance can be changed
without confirmation. This can be done when managing the appliance through scripts
through the CLI, but it will cause the Security Appliance to reboot without a warning.
If the security administrator chooses to return the Security Appliance to single mode, the
Security Appliance will inherit most of the necessary configuration options from the multiple
contexts to create a nonfunctioning configuration for a single-mode firewall. It is
recommended that a full start-up configuration be applied to the Security Appliance before
converting to single mode. After the Security Appliance resets to single-context mode, all the
interfaces will be offline. To enable the interfaces, as well as to copy any additional
configuration settings back onto the Security Appliance, access to the CLI will be required.
A security administrator can verify the security-context mode that the Security Appliance has
enabled by using the show mode command in EXEC mode. Example 9-1 shows sample
output from the show mode command.
A Security Appliance can support either a single or multiple context mode. In a single-mode
configuration, the Security Appliance does not separate the firewall options from the system
resources. When the multiple-contexts mode is enabled, the Security Appliance creates a new
configuration scheme. The Security Appliance separates the context options from the current
start-up configuration and places these configurations in an administrative context called the
admin context. The remaining system configurations are stored in the start-up configuration
file. The administration configuration uses the admin.cfg file. The original running
configuration is saved as old_running.cfg on the local Flash disk when the security context
mode is changed. If the running configuration differs from the start-up configuration, the
start-up configuration should also be saved manually. If you are copying a configuration
from a Security Appliance in multiple-context mode to a device configured for single-context
mode, the context mode must be manually changed, or scripted with the [noconfirm] switch
This is needed because the security context mode is not saved in the configuration file. All
mode changes must be made from the command-line interface (CLI) and cannot be done
through the Cisco Adaptive Security Device Manager (ASDM). To enable the multiplecontext
mode, use the mode command:
mode {single | multiple} [noconfirm]
With the noconfirm command syntax, the mode of the Security Appliance can be changed
without confirmation. This can be done when managing the appliance through scripts
through the CLI, but it will cause the Security Appliance to reboot without a warning.
If the security administrator chooses to return the Security Appliance to single mode, the
Security Appliance will inherit most of the necessary configuration options from the multiple
contexts to create a nonfunctioning configuration for a single-mode firewall. It is
recommended that a full start-up configuration be applied to the Security Appliance before
converting to single mode. After the Security Appliance resets to single-context mode, all the
interfaces will be offline. To enable the interfaces, as well as to copy any additional
configuration settings back onto the Security Appliance, access to the CLI will be required.
A security administrator can verify the security-context mode that the Security Appliance has
enabled by using the show mode command in EXEC mode. Example 9-1 shows sample
output from the show mode command.
Security Context Overview
Security Context Overview
Within a single Security Appliance, a security administrator can create more then one
security context (see Figure 9-1). Each context uses a separate configuration that describes
the security policy, assigned interfaces, and options that the security context manages. This
reduces the amount of equipment, cost, rack space, and administrative duties that a security
department would normally incur if each department required a separate firewall unit.
Figure 9-1 Multiple Security Contexts
Multiple Security Contexts
Each security context configuration is stored in a separate file that can be saved on the local
Flash RAM drive or accessed from a remote location using TFTP, FTP, or HTTP(S).
Multiple security contexts should be used in the following scenarios:
■ A large enterprise company or campus with a requirement to completely separate each
department.
■ An enterprise that requires unique security policies for each department.
■ An Internet service provider (ISP) that wishes to sell security and firewall services to
multiple companies.
■ A network that requires more than one firewall.
Although security contexts give a security administrator more flexibility when designing a
security platform, a few features are not supported within a security context when enabled
in multiple context mode:
■ Dynamic routing protocols such as OSPF or RIP. Only static routes are supported.
■ VPNs.
■ Multicasts.
For the Security Appliance to route traffic flows through the appropriate security context, the
Security Appliance must first classify the traffic flow based on the contents of the flow
packets. Using two characteristics of the packets within the flow, the Security Appliance
classifies the packets based on which characteristic is unique to the Security Appliance
contexts and is not shared across them. The two characteristics that the Security Appliance
checks for are these:
■ Source interface (VLAN)
■ Destination address
Within a single Security Appliance, a security administrator can create more then one
security context (see Figure 9-1). Each context uses a separate configuration that describes
the security policy, assigned interfaces, and options that the security context manages. This
reduces the amount of equipment, cost, rack space, and administrative duties that a security
department would normally incur if each department required a separate firewall unit.
Figure 9-1 Multiple Security Contexts
Multiple Security Contexts
Each security context configuration is stored in a separate file that can be saved on the local
Flash RAM drive or accessed from a remote location using TFTP, FTP, or HTTP(S).
Multiple security contexts should be used in the following scenarios:
■ A large enterprise company or campus with a requirement to completely separate each
department.
■ An enterprise that requires unique security policies for each department.
■ An Internet service provider (ISP) that wishes to sell security and firewall services to
multiple companies.
■ A network that requires more than one firewall.
Although security contexts give a security administrator more flexibility when designing a
security platform, a few features are not supported within a security context when enabled
in multiple context mode:
■ Dynamic routing protocols such as OSPF or RIP. Only static routes are supported.
■ VPNs.
■ Multicasts.
For the Security Appliance to route traffic flows through the appropriate security context, the
Security Appliance must first classify the traffic flow based on the contents of the flow
packets. Using two characteristics of the packets within the flow, the Security Appliance
classifies the packets based on which characteristic is unique to the Security Appliance
contexts and is not shared across them. The two characteristics that the Security Appliance
checks for are these:
■ Source interface (VLAN)
■ Destination address
Security Context Overview
Security Context Overview
Within a single Security Appliance, a security administrator can create more then one
security context (see Figure 9-1). Each context uses a separate configuration that describes
the security policy, assigned interfaces, and options that the security context manages. This
reduces the amount of equipment, cost, rack space, and administrative duties that a security
department would normally incur if each department required a separate firewall unit.
In the ever-expanding workplace, companies are requiring more and more security on
sensitive material. In addition, the need to control and manage the network activities of
employees has become a paramount duty for security administrators. Traditionally, when a
security administrator required unique security configurations for different departments,
multiple firewalls would be deployed, one for each department. As companies and campuses
have grown, this practice has become complex and difficult to manage. With Secure Firewall
software version 7.0, a security administrator can create multiple virtual firewalls within a
single Security Appliance.
Within a single Security Appliance, a security administrator can create more then one
security context (see Figure 9-1). Each context uses a separate configuration that describes
the security policy, assigned interfaces, and options that the security context manages. This
reduces the amount of equipment, cost, rack space, and administrative duties that a security
department would normally incur if each department required a separate firewall unit.
In the ever-expanding workplace, companies are requiring more and more security on
sensitive material. In addition, the need to control and manage the network activities of
employees has become a paramount duty for security administrators. Traditionally, when a
security administrator required unique security configurations for different departments,
multiple firewalls would be deployed, one for each department. As companies and campuses
have grown, this practice has become complex and difficult to manage. With Secure Firewall
software version 7.0, a security administrator can create multiple virtual firewalls within a
single Security Appliance.
Class maps—Class maps
This “Foundation Summary” provides a convenient review of many key concepts in this
chapter. If you are already comfortable with the topics in this chapter, this summary can help
you recall a few details. If you just read this chapter, this review should help solidify some
key facts. If you are doing your final preparation before the exam, this summary provides a
convenient way to review on the day before the exam.
Cisco Service Appliance software version 7.0 and later introduced a new way to dynamically
manipulate traffic flows. With the introduction of Modular Policy Framework, a security
administrator could manage, inspect, and set priorities on specific traffic flows instead of
applying these settings to the total traffic on the Security Appliance. A Modular Framework
Policy consists of three parts:
■ Class maps—Class maps define the traffic flow that will be managed.
■ Policy maps—Policy maps define one or more actions that will be applied to the traffic
flow.
■ Service maps—Service maps assign the policies to specific interfaces or globally to all
interfaces.
Policy maps assign actions, or domains, to traffic classes assigned by the class map. These
five actions, called feature domains, control the inspection and QoS actions that a policy map
can apply. The featured actions are as follows:
■ inspect—Inspects a traffic flow assigned to it at Layer 3 to Layer 7.
■ ips—Sends traffic to the AIP-SSM module for deep packet inspection.
■ priority—Assigns traffic flows to the low-latency queue for prioritization.
■ police—Sets a rate limit and burst limit on assigned traffic flows.
■ set-connection—Allows the limiting of TCP and UDP connections, as well as embryonic
connections.
chapter. If you are already comfortable with the topics in this chapter, this summary can help
you recall a few details. If you just read this chapter, this review should help solidify some
key facts. If you are doing your final preparation before the exam, this summary provides a
convenient way to review on the day before the exam.
Cisco Service Appliance software version 7.0 and later introduced a new way to dynamically
manipulate traffic flows. With the introduction of Modular Policy Framework, a security
administrator could manage, inspect, and set priorities on specific traffic flows instead of
applying these settings to the total traffic on the Security Appliance. A Modular Framework
Policy consists of three parts:
■ Class maps—Class maps define the traffic flow that will be managed.
■ Policy maps—Policy maps define one or more actions that will be applied to the traffic
flow.
■ Service maps—Service maps assign the policies to specific interfaces or globally to all
interfaces.
Policy maps assign actions, or domains, to traffic classes assigned by the class map. These
five actions, called feature domains, control the inspection and QoS actions that a policy map
can apply. The featured actions are as follows:
■ inspect—Inspects a traffic flow assigned to it at Layer 3 to Layer 7.
■ ips—Sends traffic to the AIP-SSM module for deep packet inspection.
■ priority—Assigns traffic flows to the low-latency queue for prioritization.
■ police—Sets a rate limit and burst limit on assigned traffic flows.
■ set-connection—Allows the limiting of TCP and UDP connections, as well as embryonic
connections.
show service-policy Command Syntax (Continued)
show service-policy Command Syntax (Continued)
Syntax Description
intf Specifies the interface name.
action Specifies an action for which the statistics data are to be shown.
flow
flow_description
Specifies a data flow on which policies that are enacted will be displayed,
including the following:
Protocol
host source_ip | source_ip source_mask
source_ip
source_mask
eq
source_port
destination_ip
destination_mask
destination_port
icmp
icmp_type
show service-policy Command Output
ASAfirewall(config)# show service-policy
Interface outside
Service-policy: outside1
Class-map: http1
police:
cir 64000 bps, bc 1000 bytes
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps
Class-map: internet
IPS: mode inline, packet 0
Syntax Description
intf Specifies the interface name.
action Specifies an action for which the statistics data are to be shown.
flow
flow_description
Specifies a data flow on which policies that are enacted will be displayed,
including the following:
Protocol
host source_ip | source_ip source_mask
source_ip
source_mask
eq
source_port
destination_ip
destination_mask
destination_port
icmp
icmp_type
show service-policy Command Output
ASAfirewall(config)# show service-policy
Interface outside
Service-policy: outside1
Class-map: http1
police:
cir 64000 bps, bc 1000 bytes
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps
Class-map: internet
IPS: mode inline, packet 0
Viewing the Service Policy Statistics
Viewing the Service Policy Statistics
Security administrators like to have as much information as possible in front of them about
their networks’ health. To help with this, the Security Appliance gathers statistics on each
service policy, including details such as the number of hits to a policy and how much traffic
uses a policy. The show service-policy command displays the service policy statistics per
interface:
show service-policy [global | interface intf] [ action | flow flow_description]
Table 8-8 describes the parameters for this command.
Security administrators like to have as much information as possible in front of them about
their networks’ health. To help with this, the Security Appliance gathers statistics on each
service policy, including details such as the number of hits to a policy and how much traffic
uses a policy. The show service-policy command displays the service policy statistics per
interface:
show service-policy [global | interface intf] [ action | flow flow_description]
Table 8-8 describes the parameters for this command.
Viewing the Service Policy Configuration
Viewing the Service Policy Configuration
To display all service policy configurations, a security administrator can use the show
running-config service-policy command in the global configuration mode. The output from
this command displays each service policy, the policy map assigned to them, and the interface
to which it is assigned, as illustrated in Example 8-5.
First-Match Classification Policy
If a service policy contains only a single domain throughout all assigned class maps, the
service policy will use the first-match classification policy. Like an access list, each packet will
enter the service policy and have the match criteria compared to it. If it fits a match criterion,
the action applied to that match criteria takes effect and the service policy stops attempting
to match the packet. The order in which the service policy compares the match criteria is
based on how the service policy is configured, with the first match in the configuration taking
effect first.
To display all service policy configurations, a security administrator can use the show
running-config service-policy command in the global configuration mode. The output from
this command displays each service policy, the policy map assigned to them, and the interface
to which it is assigned, as illustrated in Example 8-5.
First-Match Classification Policy
If a service policy contains only a single domain throughout all assigned class maps, the
service policy will use the first-match classification policy. Like an access list, each packet will
enter the service policy and have the match criteria compared to it. If it fits a match criterion,
the action applied to that match criteria takes effect and the service policy stops attempting
to match the packet. The order in which the service policy compares the match criteria is
based on how the service policy is configured, with the first match in the configuration taking
effect first.
Multimatch Classification Policy
Multimatch Classification Policy
The multimatch classification policy applies to any service policy containing a policy map
that applies multiple domains to traffic classes. For example, a policy map that assigns an
inspect action to class map A and a police action to class map B would qualify as a
multimatch classification. Each domain is allowed an attempt to match its criteria to the
packet. Once all matches have been verified, all actions assigned by these matches are applied
to the packet. For example, an H.323 traffic class could be assigned an inspection domain,
while all TCP traffic could be assigned a set-connections domain and all voice traffic could
be set a priority domain. If a VoIP traffic flow enters the Security Appliance, all three domains
would affect and match this traffic flow, causing it to be inspected, have TCP connection
limits applied to the flow, and be prioritized in the LLQ.
The Security Appliance will apply these actions in a specific order that does not reflect the
order in which the actions have been configured:
1. IPS
2. TCP Flow Control
3. Inspection
4. Policing
5. Priority
The multimatch classification policy applies to any service policy containing a policy map
that applies multiple domains to traffic classes. For example, a policy map that assigns an
inspect action to class map A and a police action to class map B would qualify as a
multimatch classification. Each domain is allowed an attempt to match its criteria to the
packet. Once all matches have been verified, all actions assigned by these matches are applied
to the packet. For example, an H.323 traffic class could be assigned an inspection domain,
while all TCP traffic could be assigned a set-connections domain and all voice traffic could
be set a priority domain. If a VoIP traffic flow enters the Security Appliance, all three domains
would affect and match this traffic flow, causing it to be inspected, have TCP connection
limits applied to the flow, and be prioritized in the LLQ.
The Security Appliance will apply these actions in a specific order that does not reflect the
order in which the actions have been configured:
1. IPS
2. TCP Flow Control
3. Inspection
4. Policing
5. Priority
Service Policy Matching Logic
Service Policy Matching Logic
When the Security Appliance applies a service policy to an interface, it must sort the
matching criteria. In a traditional policy map or access list, the Security Appliance would use
a first-match rule; as soon as a packet matched a criteria in the policy map or access list, the
action was handled and the service appliance went on to the next packet. Using an MPF, it
is possible to require a packet to match multiple criteria, each with separate actions that
should be applied to the packet. The first-match rule is used, as it only supports a single
action per packet. To allow for multiple matches and allow multiple actions to apply to a
packet, two policies dictate how the service policy handles matching criteria.
When the Security Appliance applies a service policy to an interface, it must sort the
matching criteria. In a traditional policy map or access list, the Security Appliance would use
a first-match rule; as soon as a packet matched a criteria in the policy map or access list, the
action was handled and the service appliance went on to the next packet. Using an MPF, it
is possible to require a packet to match multiple criteria, each with separate actions that
should be applied to the packet. The first-match rule is used, as it only supports a single
action per packet. To allow for multiple matches and allow multiple actions to apply to a
packet, two policies dictate how the service policy handles matching criteria.
Service Policy Directional Use Table
Service Policy Directional Use Table
Policy Type Single Interface Direction Global Direction
IPS Bidirectional Ingress
TCP normalization; connection limits and
timeouts (set-connection)
Bidirectional Ingress
Policy Type Single Interface Direction Global Direction
IPS Bidirectional Ingress
TCP normalization; connection limits and
timeouts (set-connection)
Bidirectional Ingress
Output—Output,Bidirectional—Bidirectional,Input—Input or ingress refers to all traffic flow entering the Security Appliance through
Service policies use several parameters that govern the traffic direction based on the
classification that is performed. Some policies will affect inbound traffic flows for specific
classifications, while others may affect bidirectional traffic flows. The three types of policies
follow:
■ Input—Input or ingress refers to all traffic flow entering the Security Appliance through
the assigned interface.
■ Output—Output or egress refers to all traffic flow leaving the Security Appliance
through the assigned interface.
■ Bidirectional—Bidirectional, both ingress and egress, affects both directions of all traffic
that accesses the assigned interface.
Each action has an implicit direction policy assigned to it by the Security Appliance,
including the global policy, as shown in Table 8-7. The global policy treats inspection-type
actions as input-only actions. These actions handle only traffic flow that enters the security
appliance and ignores traffic leaving the Security Appliance. This would include inspect, ips,
and set-connection policies. The QoS-type of actions are treated by the global policy as
output-only actions. This would include the police and priority actions.
classification that is performed. Some policies will affect inbound traffic flows for specific
classifications, while others may affect bidirectional traffic flows. The three types of policies
follow:
■ Input—Input or ingress refers to all traffic flow entering the Security Appliance through
the assigned interface.
■ Output—Output or egress refers to all traffic flow leaving the Security Appliance
through the assigned interface.
■ Bidirectional—Bidirectional, both ingress and egress, affects both directions of all traffic
that accesses the assigned interface.
Each action has an implicit direction policy assigned to it by the Security Appliance,
including the global policy, as shown in Table 8-7. The global policy treats inspection-type
actions as input-only actions. These actions handle only traffic flow that enters the security
appliance and ignores traffic leaving the Security Appliance. This would include inspect, ips,
and set-connection policies. The QoS-type of actions are treated by the global policy as
output-only actions. This would include the police and priority actions.
service-policy Command Syntax
service-policy Command Syntax
Syntax Description
policy-map_name The name of a configured policy map-map.
global Assign the policy map to all interfaces. By default, the Global_policy
is already assigned to this setting.
interface Assigns the policy map to a specific interface.
intf The interface name defined in the nameif command.
Syntax Description
policy-map_name The name of a configured policy map-map.
global Assign the policy map to all interfaces. By default, the Global_policy
is already assigned to this setting.
interface Assigns the policy map to a specific interface.
intf The interface name defined in the nameif command.
Assigning Policies to an Interface
Assigning Policies to an Interface
For interfaces to be activated, you need to assign policies to them. An interface is defined as
any physical interface or as a logical interface that can be defined by the nameif command.
Additionally, you can apply a policy to the global interface. To assign a policy to an interface,
use the service-policy command. The service-policy command assigns a policy map to a
specific interface. Only one service-policy command can be made on any one interface. To
disable the command, use the no form of this command:
service-policy policy-map_name [global | interface intf]
Table 8-6 describes the parameters of the service-policy command.
For interfaces to be activated, you need to assign policies to them. An interface is defined as
any physical interface or as a logical interface that can be defined by the nameif command.
Additionally, you can apply a policy to the global interface. To assign a policy to an interface,
use the service-policy command. The service-policy command assigns a policy map to a
specific interface. Only one service-policy command can be made on any one interface. To
disable the command, use the no form of this command:
service-policy policy-map_name [global | interface intf]
Table 8-6 describes the parameters of the service-policy command.
Viewing the Policy Map Configuration
Viewing the Policy Map Configuration
To display all policy map configurations, a security administrator can use the show run
policy-map command. The output from this command will display all policy maps, the class
maps assigned to them, and each action applied to the class maps, as illustrated in Example 8-4.
Assigning Policies to an Interface
For interfaces to be activated, you need to assign policies to them. An interface is defined as
any physical interface or as a logical interface that can be defined by the nameif command.
Additionally, you can apply a policy to the global interface. To assign a policy to an interface,
use the service-policy command. The service-policy command assigns a policy map to a
Table 8-5 set connection Command Options
Command Parameter Description
conn-max The maximum number of simultaneous TCP and UDP connections
that are allowed.
embryonic-conn-max The maximum number of half-open TCP connections associated with
a policy map.
random-sequence-number Enables or disables TCP sequence number randomization. This
option should be used when multiple Security Appliances are placed
inline with each other, with one appliance performing the sequence
number randomization.
Example 8-4 show run policy-map Command Output
ASAfirewall(config)# show run policy-map
policy-map outside1
class http1
police 64000 1000
class internet
IPS inline fail-close
class vpn1
set connection conn-max 256
embryonic-conn-max 25
ASAfirewall(config)#
To display all policy map configurations, a security administrator can use the show run
policy-map command. The output from this command will display all policy maps, the class
maps assigned to them, and each action applied to the class maps, as illustrated in Example 8-4.
Assigning Policies to an Interface
For interfaces to be activated, you need to assign policies to them. An interface is defined as
any physical interface or as a logical interface that can be defined by the nameif command.
Additionally, you can apply a policy to the global interface. To assign a policy to an interface,
use the service-policy command. The service-policy command assigns a policy map to a
Table 8-5 set connection Command Options
Command Parameter Description
conn-max The maximum number of simultaneous TCP and UDP connections
that are allowed.
embryonic-conn-max The maximum number of half-open TCP connections associated with
a policy map.
random-sequence-number Enables or disables TCP sequence number randomization. This
option should be used when multiple Security Appliances are placed
inline with each other, with one appliance performing the sequence
number randomization.
Example 8-4 show run policy-map Command Output
ASAfirewall(config)# show run policy-map
policy-map outside1
class http1
police 64000 1000
class internet
IPS inline fail-close
class vpn1
set connection conn-max 256
embryonic-conn-max 25
ASAfirewall(config)#
set connection Command Options
set connection Command Options
Command Parameter Description
conn-max The maximum number of simultaneous TCP and UDP connections
that are allowed.
embryonic-conn-max The maximum number of half-open TCP connections associated with
a policy map.
random-sequence-number Enables or disables TCP sequence number randomization. This
option should be used when multiple Security Appliances are placed
inline with each other, with one appliance performing the sequence
number randomization.
Using the set connection command, you can control the timeout for TCP connections. The
connection types that a timeout can be set for are connections, embryonic (half-opened)
connections, and half-closed connections. The set connection command uses a different
syntax for timeouts:
set connection {[embryonic hh[:mm[:ss]]] [half-closed hh[:mm[:ss]]] [tcp hh[:mm[:ss]]]}
Command Parameter Description
conn-max The maximum number of simultaneous TCP and UDP connections
that are allowed.
embryonic-conn-max The maximum number of half-open TCP connections associated with
a policy map.
random-sequence-number Enables or disables TCP sequence number randomization. This
option should be used when multiple Security Appliances are placed
inline with each other, with one appliance performing the sequence
number randomization.
Using the set connection command, you can control the timeout for TCP connections. The
connection types that a timeout can be set for are connections, embryonic (half-opened)
connections, and half-closed connections. The set connection command uses a different
syntax for timeouts:
set connection {[embryonic hh[:mm[:ss]]] [half-closed hh[:mm[:ss]]] [tcp hh[:mm[:ss]]]}
Policy Map TCP Connection Policy Overview
Policy Map TCP Connection Policy Overview
Policy maps have four basic actions that can be assigned to traffic flow. In addition to these
four actions, policy maps offer a general connection policy that can manage the actual traffic
flow’s connection state. This is useful if a security administrator needs to restrict the number
of HTTP connects allowed through parts of the network or needs to restrict the time a
connection is allowed to stay up. To assign a connection policy, the set connection command
must be applied to a class map in class configuration mode like the other four policy map
actions:
set connection {[conn-max number] [embryonic-conn-max number] [random-sequence-number
{enable | disable}}
Table 8-5 describes the options of the set connection command.
Policy maps have four basic actions that can be assigned to traffic flow. In addition to these
four actions, policy maps offer a general connection policy that can manage the actual traffic
flow’s connection state. This is useful if a security administrator needs to restrict the number
of HTTP connects allowed through parts of the network or needs to restrict the time a
connection is allowed to stay up. To assign a connection policy, the set connection command
must be applied to a class map in class configuration mode like the other four policy map
actions:
set connection {[conn-max number] [embryonic-conn-max number] [random-sequence-number
{enable | disable}}
Table 8-5 describes the options of the set connection command.
fail-open
■ fail-open—Enabling this ips command option will allow all traffic flows assigned to the
IPS policy to be transmitted without inspection to its destination, pending any other
policy assigned to the traffic flow.
IPS policy to be transmitted without inspection to its destination, pending any other
policy assigned to the traffic flow.
fail-close
■ fail-close—Enabling this ips command option will cause all traffic flows assigned to the
IPS policy to be dropped if for any reason the AIP-SSM fails. This is the recommended
setting, as it is the most secure of the two options.
IPS policy to be dropped if for any reason the AIP-SSM fails. This is the recommended
setting, as it is the most secure of the two options.
Promiscuous mode
■ Promiscuous mode—The Security Appliance can send copies of live traffic assigned to
the IPS policy to the AIP-SSM for inspection. Using promiscuous mode avoids direct
manipulation of the live traffic flow, allowing higher throughput and less latency that
may be caused during inline mode. What is lost is the ability to stop an attack as it is
happening. Without direct access to the live traffic flow, the AIP-SSM is working in a
reactive security state, rarely responding during the fact and potentially causing a need
for manual intervention by a security administrator to stop the attack.
Redirecting traffic to a secondary module can cause an additional point of failure. If the AIPSSM
module fails for any reason, the traffic that has been redirected there would be dropped
altogether. This could be a problem if the security policy for a site is to be always online. Two
options are supported in the ips command to resolve this issue:
the IPS policy to the AIP-SSM for inspection. Using promiscuous mode avoids direct
manipulation of the live traffic flow, allowing higher throughput and less latency that
may be caused during inline mode. What is lost is the ability to stop an attack as it is
happening. Without direct access to the live traffic flow, the AIP-SSM is working in a
reactive security state, rarely responding during the fact and potentially causing a need
for manual intervention by a security administrator to stop the attack.
Redirecting traffic to a secondary module can cause an additional point of failure. If the AIPSSM
module fails for any reason, the traffic that has been redirected there would be dropped
altogether. This could be a problem if the security policy for a site is to be always online. Two
options are supported in the ips command to resolve this issue:
Inline mode
The IPS policy works in one of two modes:
■ Inline mode—The Security Appliance will redirect live traffic flow assigned to the IPS
policy to the AIP-SSM for inspection. The module inspects the live packets envelope, as
well as Layers 3 to 7, for malicious or dangerous content and drops the packet if needed.
An inline AIP-SSM module sits in the forwarding path, allowing the IPS process to stop
attacks by dropping malicious traffic before it reaches its final destination. Any traffic
found to be clean is released and transmitted to its final destination. This can affect the
flow of traffic and reduces the maximum throughput of the Security Appliance.
■ Inline mode—The Security Appliance will redirect live traffic flow assigned to the IPS
policy to the AIP-SSM for inspection. The module inspects the live packets envelope, as
well as Layers 3 to 7, for malicious or dangerous content and drops the packet if needed.
An inline AIP-SSM module sits in the forwarding path, allowing the IPS process to stop
attacks by dropping malicious traffic before it reaches its final destination. Any traffic
found to be clean is released and transmitted to its final destination. This can affect the
flow of traffic and reduces the maximum throughput of the Security Appliance.
ips Command Syntax
ips Command Syntax
Syntax Description
Inline Redirects packets to the AIP-SSM module for inspection
promiscuous Duplicates packets for the AIP-SSM module for inspection
fail-close Blocks traffic if the AIP-SSM module fails
fail-open Permits traffic if the AIP-SSM module fails
Syntax Description
Inline Redirects packets to the AIP-SSM module for inspection
promiscuous Duplicates packets for the AIP-SSM module for inspection
fail-close Blocks traffic if the AIP-SSM module fails
fail-open Permits traffic if the AIP-SSM module fails
IPS Policy Overview
IPS Policy Overview
With the optional AIP-SSM module installed in the Security Appliance, detailed deep packet
inspection is available for traffic flows assigned to the IPS policy. The Security Appliance will
take a subset of the traffic flow on the firewall and send it to the AIP-SSM module for
inspection. This grants the Security Appliance greater efficiency with packet inspections and
will cause fewer false-positives due to only having to inspect a subset of the total traffic flow
in the Security Appliance. Like the inspect command, the AIP-SSM module will inspect both
the ingress and egress traffic flows assigned to it from a normal interface, but it is restricted
to the ingress traffic flows from the global interface. Use the ips command to assign the IPS
policy to a class map:
ips {inline | promiscuous} {fail-close | fail-open}
With the optional AIP-SSM module installed in the Security Appliance, detailed deep packet
inspection is available for traffic flows assigned to the IPS policy. The Security Appliance will
take a subset of the traffic flow on the firewall and send it to the AIP-SSM module for
inspection. This grants the Security Appliance greater efficiency with packet inspections and
will cause fewer false-positives due to only having to inspect a subset of the total traffic flow
in the Security Appliance. Like the inspect command, the AIP-SSM module will inspect both
the ingress and egress traffic flows assigned to it from a normal interface, but it is restricted
to the ingress traffic flows from the global interface. Use the ips command to assign the IPS
policy to a class map:
ips {inline | promiscuous} {fail-close | fail-open}
Inspect Policy Overview
Inspect Policy Overview
Today, many services and applications are run on the Internet. With corporations and small
businesses using the Internet more and more, it is crucial to restrict and control the
applications and services accessed through the Internet. Many applications use static ports,
making inspection by classic firewalls quick and simple. More recently, applications such as
FTP, multimedia, and SQL require dynamic port assignments, which can confuse classic
firewalls to the point of breaking these applications. Security administrators have to decide
if the applications can be allowed to access the network, and if so, they will have to create a
security hole in the firewall for all the dynamic port assignments to work properly. Creating
any hole, permanent or not, in a security system makes it vulnerable to attack and breach.
Cisco has found a way around this issue on the Security Appliance by enabling the inspect
command in policy maps. As of version 7.0, the inspect command replaces the fixup
comment for all inspection features.
The inspect command allows the firewall to inspect bidirectional packets at Layers 3 to 7 on
an interface, and it permits them to transverse the network using dynamic, stateful
adjustments to the security policy. By default, protocol inspection is enabled in the global
policy map and inspects the following protocols:
policy-map global_policy
class inspection_default
inspect dns maximum length 512
inspect ftp
inspect h323 h225
inspect h323 ras
inspect netbios
inspect sunrpc
inspect rsh
inspect rtsp
inspect sip
inspect skinny
inspect esmtp
inspect sqlnet
inspect tftp
inspect xdmcp
Today, many services and applications are run on the Internet. With corporations and small
businesses using the Internet more and more, it is crucial to restrict and control the
applications and services accessed through the Internet. Many applications use static ports,
making inspection by classic firewalls quick and simple. More recently, applications such as
FTP, multimedia, and SQL require dynamic port assignments, which can confuse classic
firewalls to the point of breaking these applications. Security administrators have to decide
if the applications can be allowed to access the network, and if so, they will have to create a
security hole in the firewall for all the dynamic port assignments to work properly. Creating
any hole, permanent or not, in a security system makes it vulnerable to attack and breach.
Cisco has found a way around this issue on the Security Appliance by enabling the inspect
command in policy maps. As of version 7.0, the inspect command replaces the fixup
comment for all inspection features.
The inspect command allows the firewall to inspect bidirectional packets at Layers 3 to 7 on
an interface, and it permits them to transverse the network using dynamic, stateful
adjustments to the security policy. By default, protocol inspection is enabled in the global
policy map and inspects the following protocols:
policy-map global_policy
class inspection_default
inspect dns maximum length 512
inspect ftp
inspect h323 h225
inspect h323 ras
inspect netbios
inspect sunrpc
inspect rsh
inspect rtsp
inspect sip
inspect skinny
inspect esmtp
inspect sqlnet
inspect tftp
inspect xdmcp
Rate-Limited Connection to Headquarters
Rate-Limited Connection to Headquarters
As long as the traffic flow does not exceed 64,000 bytes per second, the police policy will
transmit the data. The conform-rate syntax sets the maximum rate of traffic in bits per
second. The traffic that never exceeds the rate limit can be either transmitted or dropped.
This is assigned by the conform-action attribute within the police command. If the traffic
flow exceeds the rate limit, that traffic would normally be dropped. The problem with this is
that IP traffic is inherently bursty, and dropping the bursty traffic might not be the correct
action. It is common for a traffic flow to burst beyond its average sustained rate for a very
short time. To allow for bursty traffic, you can configure the police command with a burst
size set in the conform-burst syntax. This new burst rate specifies the maximum amount of
bytes that can exceed the set rate limit during any one instance. Traffic might still exceed the
burst rate, and the security administrator must determine what action should apply to the
excess traffic. Using the exceed-action command within the police command allows the
traffic either to continue to be transmitted or to be dropped.
Priority Policy Overview
With video and audio streaming, as well as voice over IP (VoIP) services becoming more
mainstream, the need for high-quality bandwidth connections is critical due to jitter and
latency restrictions. Many national and international companies rely on VoIP traffic to
communicate between offices that run over the Internet. VPNs over the Internet between
offices are becoming more prevalent, requiring QoS features. The Security Appliance can use
low-latency queuing (LLQ) to prioritize egress packet transmission, enabling a form of QoS
for the prioritized packets. This can be done within a policy map using the priority
command. The priority command assigns the class map to the low-latency queue, while all
egress traffic not assigned the priority command will be sent into the default, best-effort
NOTE When deciding the burst size for a police policy, you should use the following
formula:
(conform-rate/8) * 1.5
For example, if you use a conform rate of 80 kbps, use the formula to get the following as
your burst size:
(80/8) * 1.5 = 15 kbps
As long as the traffic flow does not exceed 64,000 bytes per second, the police policy will
transmit the data. The conform-rate syntax sets the maximum rate of traffic in bits per
second. The traffic that never exceeds the rate limit can be either transmitted or dropped.
This is assigned by the conform-action attribute within the police command. If the traffic
flow exceeds the rate limit, that traffic would normally be dropped. The problem with this is
that IP traffic is inherently bursty, and dropping the bursty traffic might not be the correct
action. It is common for a traffic flow to burst beyond its average sustained rate for a very
short time. To allow for bursty traffic, you can configure the police command with a burst
size set in the conform-burst syntax. This new burst rate specifies the maximum amount of
bytes that can exceed the set rate limit during any one instance. Traffic might still exceed the
burst rate, and the security administrator must determine what action should apply to the
excess traffic. Using the exceed-action command within the police command allows the
traffic either to continue to be transmitted or to be dropped.
Priority Policy Overview
With video and audio streaming, as well as voice over IP (VoIP) services becoming more
mainstream, the need for high-quality bandwidth connections is critical due to jitter and
latency restrictions. Many national and international companies rely on VoIP traffic to
communicate between offices that run over the Internet. VPNs over the Internet between
offices are becoming more prevalent, requiring QoS features. The Security Appliance can use
low-latency queuing (LLQ) to prioritize egress packet transmission, enabling a form of QoS
for the prioritized packets. This can be done within a policy map using the priority
command. The priority command assigns the class map to the low-latency queue, while all
egress traffic not assigned the priority command will be sent into the default, best-effort
NOTE When deciding the burst size for a police policy, you should use the following
formula:
(conform-rate/8) * 1.5
For example, if you use a conform rate of 80 kbps, use the formula to get the following as
your burst size:
(80/8) * 1.5 = 15 kbps
Police Policy Overview
Police Policy Overview
The police command creates bandwidth restrictions on traffic flows. Table 8-3 describes the
parameters for the police command, the syntax for which is as follows:
police conform-rate conform-burst | conform-action {drop | transmit} | exceed-action
{drop | transmit}
This police command allows a security administrator to set maximum transmit limits, or
caps, on egress traffic through a specific interface or the global interface. The rate limit is
compared to the sustained traffic rate of the associated traffic flow. In Figure 8-2, Client A
has a VPN connection to Headquarters through an ASA 5520 Security Appliance. A policy
map has been applied to Client A’s traffic flow, and the rate has been limited to 64 kbps using
the following police command:
ASAfirewall(config-pmap-c)# police 64000 1000 conform-action transmit exceed-action
drop
Table 8-3 police Command Parameters
Syntax Description
conform-action The action to take when the traffic rate is below the conform-burst value.
conform-rate Sets the maximum speed (rate limit) for the traffic flow. This value can be
between 8000 and 2,000,000,000.
conform-burst Sets the maximum number of bytes allowed in a sustained burst at any one
instance. This value can be between 1000 and 512,000,000.
exceed-action The action to take when the traffic rate exceeds the conform-burst value.
drop Drop the packet.
transmit Transmit the packet.
The police command creates bandwidth restrictions on traffic flows. Table 8-3 describes the
parameters for the police command, the syntax for which is as follows:
police conform-rate conform-burst | conform-action {drop | transmit} | exceed-action
{drop | transmit}
This police command allows a security administrator to set maximum transmit limits, or
caps, on egress traffic through a specific interface or the global interface. The rate limit is
compared to the sustained traffic rate of the associated traffic flow. In Figure 8-2, Client A
has a VPN connection to Headquarters through an ASA 5520 Security Appliance. A policy
map has been applied to Client A’s traffic flow, and the rate has been limited to 64 kbps using
the following police command:
ASAfirewall(config-pmap-c)# police 64000 1000 conform-action transmit exceed-action
drop
Table 8-3 police Command Parameters
Syntax Description
conform-action The action to take when the traffic rate is below the conform-burst value.
conform-rate Sets the maximum speed (rate limit) for the traffic flow. This value can be
between 8000 and 2,000,000,000.
conform-burst Sets the maximum number of bytes allowed in a sustained burst at any one
instance. This value can be between 1000 and 512,000,000.
exceed-action The action to take when the traffic rate exceeds the conform-burst value.
drop Drop the packet.
transmit Transmit the packet.
Assign Policies for Each Class
Step 3: Assign Policies for Each Class
You can assign five policies, or domains, to traffic classes within a policy map. The five
policies are as follows:
■ police—Allows rate limiting of matched traffic flows.
■ inspect—Allows protocol inspection services on the matched traffic flows.
■ priority—Allows strict scheduling priority for matched traffic flows.
■ Intrusion Protection Services (IPS)—Allows IPS for all traffic flows that have been
matched.
■ TCP normalization—Allows the limiting of TCP and UDP connections, as well as
embryonic connections.
You can assign more than one domain to a traffic class, allowing inspection, policing, or any
of the other three policy types on a single traffic flow
You can assign five policies, or domains, to traffic classes within a policy map. The five
policies are as follows:
■ police—Allows rate limiting of matched traffic flows.
■ inspect—Allows protocol inspection services on the matched traffic flows.
■ priority—Allows strict scheduling priority for matched traffic flows.
■ Intrusion Protection Services (IPS)—Allows IPS for all traffic flows that have been
matched.
■ TCP normalization—Allows the limiting of TCP and UDP connections, as well as
embryonic connections.
You can assign more than one domain to a traffic class, allowing inspection, policing, or any
of the other three policy types on a single traffic flow
Assign Traffic Classes to the Policy Map
Step 2: Assign Traffic Classes to the Policy Map
With the policy map created, traffic classes must be assigned to the policy map. To do this,
use the class command while in the policy map configuration mode. This will access the class
configuration mode for that specific class map assigned to the policy map, as illustrated in
Example 8-3.
Adding a Traffic Class to a Policy Map
ASAfirewall(config)# class-map http1
ASAfirewall(config-cmap)# match port tcp eq 80
ASAfirewall(config-cmap)# exit
ASAfirewall(config)# policy-map outside1
ASAfirewall(config-pmap)# class-map http1
ASAfirewall(config-pmap-c)#
Each class map added to the policy map will have its own class configuration mode. All
actions assigned in these modes will only affect traffic matched using that specific class map.
Step 3: Assign Policies for Each Class
You can assign five policies, or domains, to traffic classes within a policy map. The five
policies are as follows:
■ police—Allows rate limiting of matched traffic flows.
■ inspect—
With the policy map created, traffic classes must be assigned to the policy map. To do this,
use the class command while in the policy map configuration mode. This will access the class
configuration mode for that specific class map assigned to the policy map, as illustrated in
Example 8-3.
Adding a Traffic Class to a Policy Map
ASAfirewall(config)# class-map http1
ASAfirewall(config-cmap)# match port tcp eq 80
ASAfirewall(config-cmap)# exit
ASAfirewall(config)# policy-map outside1
ASAfirewall(config-pmap)# class-map http1
ASAfirewall(config-pmap-c)#
Each class map added to the policy map will have its own class configuration mode. All
actions assigned in these modes will only affect traffic matched using that specific class map.
Step 3: Assign Policies for Each Class
You can assign five policies, or domains, to traffic classes within a policy map. The five
policies are as follows:
■ police—Allows rate limiting of matched traffic flows.
■ inspect—
Create a Policy Map
Step 1: Create a Policy Map
A policy map can be created in the same way as a class map. Using the policy-map command,
a policy map is created with a unique name. To disable the command, use the no form of this
command:
policy-map class-map_name
Like a class map, the execution of a policy-map command will place you in the policy map
configuration mode. The policy map configuration mode supports two commands:
■ description {description}—Specifies a description for the policy-map command.
■ class {class-map name}—Specifies the class map that will be associated with the policy
map. You can associate multiple class maps with a single policy map.
Step 2: Assign Traffic Classes to the Policy Map
With the policy map created, traffic classes must be assigned to the policy map. To do this,
use the class command while in the policy map configuration mode. This will access the class
configuration mode for that specific class map assigned to the policy map, as illustrated in
Example 8-3.
Each class map added to the policy map will have its own class configuration mode. All
actions assigned in these modes will only affect traffic matched using that specific class map.
Step 3: Assign Policies for Each Class
You can assign five policies, or domains, to traffic classes within a policy map. The five
policies are as follows:
■ police—Allows rate limiting of matched traffic flows.
■ inspect—Allows protocol inspection services on the matched traffic flows.
NOTE Like class maps, there is a default policy map called global_policy. This is a policy
map that cannot be removed or turned off and is defaulted to protocol inspection.
A policy map can be created in the same way as a class map. Using the policy-map command,
a policy map is created with a unique name. To disable the command, use the no form of this
command:
policy-map class-map_name
Like a class map, the execution of a policy-map command will place you in the policy map
configuration mode. The policy map configuration mode supports two commands:
■ description {description}—Specifies a description for the policy-map command.
■ class {class-map name}—Specifies the class map that will be associated with the policy
map. You can associate multiple class maps with a single policy map.
Step 2: Assign Traffic Classes to the Policy Map
With the policy map created, traffic classes must be assigned to the policy map. To do this,
use the class command while in the policy map configuration mode. This will access the class
configuration mode for that specific class map assigned to the policy map, as illustrated in
Example 8-3.
Each class map added to the policy map will have its own class configuration mode. All
actions assigned in these modes will only affect traffic matched using that specific class map.
Step 3: Assign Policies for Each Class
You can assign five policies, or domains, to traffic classes within a policy map. The five
policies are as follows:
■ police—Allows rate limiting of matched traffic flows.
■ inspect—Allows protocol inspection services on the matched traffic flows.
NOTE Like class maps, there is a default policy map called global_policy. This is a policy
map that cannot be removed or turned off and is defaulted to protocol inspection.
Assigning Actions to a Traffic Class
Assigning Actions to a Traffic Class
For purposes of managing, controlling, and manipulating the traffic classes, actions should
be assigned to these traffic classes. A security administrator might want to rate-limit only the
HTTP traffic that crosses the network, and use deep inspection on all TCP traffic entering
the network. This can be done by assigning one or more traffic classes, through class maps,
to policy maps. Policy maps assign one or more actions to one or more class maps assigned
to it. Each action is called a domain, and the sets are known as feature domains. Similar to
creating a class map, three steps are required to create a policy map:
Step 1 Create a policy map.
Step 2 Assign traffic classes to the policy map.
Step 3 Assign policies for each class.
For purposes of managing, controlling, and manipulating the traffic classes, actions should
be assigned to these traffic classes. A security administrator might want to rate-limit only the
HTTP traffic that crosses the network, and use deep inspection on all TCP traffic entering
the network. This can be done by assigning one or more traffic classes, through class maps,
to policy maps. Policy maps assign one or more actions to one or more class maps assigned
to it. Each action is called a domain, and the sets are known as feature domains. Similar to
creating a class map, three steps are required to create a policy map:
Step 1 Create a policy map.
Step 2 Assign traffic classes to the policy map.
Step 3 Assign policies for each class.
Viewing the Class Map Configuration
Viewing the Class Map Configuration
A security administrator can view the class map configuration using the show run class-map
command. The output from this command will display each class map and its match criteria,
as illustrated in Example 8-2.
Assigning Actions to a Traffic Class
For purposes of managing, controlling, and manipulating the traffic classes, actions should
be assigned to these traffic classes. A security administrator might want to rate-limit only the
HTTP traffic that crosses the network, and use deep inspection on all TCP traffic entering
the network. This can be done by assigning one or more traffic classes, through class maps,
to policy maps. Policy maps assign one or more actions to one or more class maps assigned
to it. Each action is called a domain, and the sets are known as feature domains. Similar to
creating a class map, three steps are required to create a policy map:
Step 1 Create a policy map.
Step 2 Assign traffic classes to the policy map.
Step 3 Assign policies for each class.
Example 8-1 Class Map Configuration Examples
ASAfirewall(config)# class-map http1
ASAfirewall(config-cmap)# match port tcp eq 80
ASAfirewall(config)# class-map internet
ASAfirewall(config-cmap)# match access-list cleaninet
ASAfirewall(config)# class-map vpn1
ASAfirewall(config-cmap)# match tunnel-group vpn-group1
ASAfirewall(config-cmap)# match flow ip destination-address
Example 8-2 show run class-map Command Output
ASAfirewall(config)# show run class-map
class-map http1
match port tcp eq 80
class-map internet
match access-list cleaninet
class-map vpn1
match flow ip destination-address
match tunnel-group vpn-group1
ASAfirewall(config)#
A security administrator can view the class map configuration using the show run class-map
command. The output from this command will display each class map and its match criteria,
as illustrated in Example 8-2.
Assigning Actions to a Traffic Class
For purposes of managing, controlling, and manipulating the traffic classes, actions should
be assigned to these traffic classes. A security administrator might want to rate-limit only the
HTTP traffic that crosses the network, and use deep inspection on all TCP traffic entering
the network. This can be done by assigning one or more traffic classes, through class maps,
to policy maps. Policy maps assign one or more actions to one or more class maps assigned
to it. Each action is called a domain, and the sets are known as feature domains. Similar to
creating a class map, three steps are required to create a policy map:
Step 1 Create a policy map.
Step 2 Assign traffic classes to the policy map.
Step 3 Assign policies for each class.
Example 8-1 Class Map Configuration Examples
ASAfirewall(config)# class-map http1
ASAfirewall(config-cmap)# match port tcp eq 80
ASAfirewall(config)# class-map internet
ASAfirewall(config-cmap)# match access-list cleaninet
ASAfirewall(config)# class-map vpn1
ASAfirewall(config-cmap)# match tunnel-group vpn-group1
ASAfirewall(config-cmap)# match flow ip destination-address
Example 8-2 show run class-map Command Output
ASAfirewall(config)# show run class-map
class-map http1
match port tcp eq 80
class-map internet
match access-list cleaninet
class-map vpn1
match flow ip destination-address
match tunnel-group vpn-group1
ASAfirewall(config)#
Class Map Configuration Examples
Class Map Configuration Examples
ASAfirewall(config)# class-map http1
ASAfirewall(config-cmap)# match port tcp eq 80
ASAfirewall(config)# class-map internet
ASAfirewall(config-cmap)# match access-list cleaninet
ASAfirewall(config)# class-map vpn1
ASAfirewall(config-cmap)# match tunnel-group vpn-group1
ASAfirewall(config-cmap)# match flow ip destination-address
ASAfirewall(config)# class-map http1
ASAfirewall(config-cmap)# match port tcp eq 80
ASAfirewall(config)# class-map internet
ASAfirewall(config-cmap)# match access-list cleaninet
ASAfirewall(config)# class-map vpn1
ASAfirewall(config-cmap)# match tunnel-group vpn-group1
ASAfirewall(config-cmap)# match flow ip destination-address
Define Class Map Matches
Define Class Map Matches
With a class map defined and given a name, you must assign a match parameter to the class
map. This parameter will match traffic using the packet content, Layers 3 to 7. Examples of
content would be voice, video, or HTTP. When assigning a match criterion, you can assign
one match command to a class map, with the exception of the tunnel-group and defaultinspection-
traffic criteria. Use the match command to assign match criteria to a class map.
A class map can match to nine criteria. The match commands for each are as follows:
■ access-list {access-list name} —Match using a predefined access list. If a packet fails to
match an entry in the access list or matches a deny statement in the access list, the match
will result in a no-match. Otherwise, if the packet matches a permit statement in the
access list, the match results in a match.
■ any—Match on any traffic flow or content. The class-map class-default command uses
this match criterion as its default.
■ dscp {DSCP value}—Match on the IETF-defined Differential Service Code Point (DSCP)
field in the IP header defined in the ToS byte.
■ flow ip destination-address—Keyword pair specifies to match the destination address
within a tunnel group. This match criterion must be used with the tunnel group criteria.
■ port tcp | udp {eq n | range n1 n2}—Match using a TCP or UDP destination port.
■ precedent {precedent value}—Matches the precedence value in the TOS byte in the IP
header.
■ RTP — Match using RTP destination ports. This allows matching using a range of
destination UDP ports.
■ tunnel-group {tunnel-group name}—Matches tunnel traffic. This match criterion can
only be used with quality of service (QoS) configurations.
■ default-inspection-traffic—Matches default traffic for the inspect command in a policy
map.
The tunnel-group command, an exception to the single match statement rule, matches a
previously configured tunnel group as its first match criteria. An additional match criterion
can be added to the class map already configured to match tunnel groups. This second match
criteria will apply to traffic within that specific tunnel group.
Additionally, the default-inspection-traffic command can also be assigned a second match
criterion. In a class map with a default-inspection-traffic command and a second match
command, the class map will logically combine the two matches for use in an inspect
command assigned in a policy map. Example 8-1 provides several examples of class map
configurations.
With a class map defined and given a name, you must assign a match parameter to the class
map. This parameter will match traffic using the packet content, Layers 3 to 7. Examples of
content would be voice, video, or HTTP. When assigning a match criterion, you can assign
one match command to a class map, with the exception of the tunnel-group and defaultinspection-
traffic criteria. Use the match command to assign match criteria to a class map.
A class map can match to nine criteria. The match commands for each are as follows:
■ access-list {access-list name} —Match using a predefined access list. If a packet fails to
match an entry in the access list or matches a deny statement in the access list, the match
will result in a no-match. Otherwise, if the packet matches a permit statement in the
access list, the match results in a match.
■ any—Match on any traffic flow or content. The class-map class-default command uses
this match criterion as its default.
■ dscp {DSCP value}—Match on the IETF-defined Differential Service Code Point (DSCP)
field in the IP header defined in the ToS byte.
■ flow ip destination-address—Keyword pair specifies to match the destination address
within a tunnel group. This match criterion must be used with the tunnel group criteria.
■ port tcp | udp {eq n | range n1 n2}—Match using a TCP or UDP destination port.
■ precedent {precedent value}—Matches the precedence value in the TOS byte in the IP
header.
■ RTP — Match using RTP destination ports. This allows matching using a range of
destination UDP ports.
■ tunnel-group {tunnel-group name}—Matches tunnel traffic. This match criterion can
only be used with quality of service (QoS) configurations.
■ default-inspection-traffic—Matches default traffic for the inspect command in a policy
map.
The tunnel-group command, an exception to the single match statement rule, matches a
previously configured tunnel group as its first match criteria. An additional match criterion
can be added to the class map already configured to match tunnel groups. This second match
criteria will apply to traffic within that specific tunnel group.
Additionally, the default-inspection-traffic command can also be assigned a second match
criterion. In a class map with a default-inspection-traffic command and a second match
command, the class map will logically combine the two matches for use in an inspect
command assigned in a policy map. Example 8-1 provides several examples of class map
configurations.
Modular Policy Example Flow
Modular Policy Example Flow
Step 1: Create a Class Map
You must assign a name to the class map. This name must be unique and should be intuitive
to the content it will be matching. Use the class-map command to create and assign a name
to a class map. To disable the command, use the no form of this command:
class-map class-map_name
When this command has been executed, it will enter the class map configuration mode.
Setting the different match criteria, as well as creating a description of the class map, can be
done in this mode. Table 8-2 provides a list of available commands.
Table 8-2 match Command Syntax
Command Description
description Specifies a description for the class-map command.
match any Specifies that all traffic is to be matched. This can be used to
catch all traffic flowing through an interface, regardless of the
content, type, or destination.
match access-list Specifies the name of an access list to be used as match criteria.
This can be used when a specific destination or source requires
special attention, as well as a unique set of policy actions. Using
access to the Internet falls under this category.
match port Specifies to match traffic using a TCP/UDP destination port. Use
this to assign a traffic class to a port not already specified by the
default port lists. Additionally, you can use this match type to
reassign matching for a known port, such as FTP, to a new port
location, such as 10234 instead of 21.
Class Map:
Internet
Class Map:
Voice
Class Map:
Inspect_Default
Match all traffic
through all
interfaces
Policy Map:
outside_interface
Policy Map:
Global Policy
Match using
Internet ACL
Match on
dscp cs5
Apply the following
actions to Internet
class-map
inspect IPS
Apply the following
actions to voice
class-map Priority
Apply the following
actions to
Inspect_Defaultmap:
Inspect
Service Policy:
Outside Interface
Service Policy:
Global Interface
match Command Syntax (Continued)
Command Description
match precedence Specifies to match the precedence value represented by the ToS1
byte in the IP header. Use this match when you are creating a set
of policy actions that affect priority and queuing, such as voice
and video. Make sure that the ToS byte has been assigned at the
source for this to function correctly.
match dscp Specifies to match the IETF2-defined DSCP3 value in the IP
header. Like the precedence match criteria cited previously, this
should be used when assigning actions that will affect priority
and queuing.
match rtp Specifies to match an RTP4 UDP5 port. This matching criterion
will allow you to set priority and queue settings for video in a
priority map.
match tunnel-group Specifies to match security-related tunnel groups. Use this if you
would like to match a VPN6 group of remote uses and force its
traffic into a priority map for inspection, IPS7, and so on.
match flow Specifies to match every flow based on a unique IP destination
address. This augments the match tunnel-group command, and
must be used with the tunnel-group command.
match default-inspection-traffic Specifies to match default traffic for the inspect commands. This
is used on the global interface and through the default policies.
You can also use it to match the default match criteria, so that
you can add additional actions via a policy map. It would be
easier to just modify the default policy map instead of creating a
new one.
1 ToS = Type of Service
2 IETF = Internet Engineering Task Force
3 DSCP = Differentiated Services Code Point
4 RTP = Real-Time Transport Protocol
5 UDP = User Datagram Protocol
6 VPN = virtual private network
7 IPS = Intrusion Protection Services
Command Description
match precedence Specifies to match the precedence value represented by the ToS1
byte in the IP header. Use this match when you are creating a set
of policy actions that affect priority and queuing, such as voice
and video. Make sure that the ToS byte has been assigned at the
source for this to function correctly.
match dscp Specifies to match the IETF2-defined DSCP3 value in the IP
header. Like the precedence match criteria cited previously, this
should be used when assigning actions that will affect priority
and queuing.
match rtp Specifies to match an RTP4 UDP5 port. This matching criterion
will allow you to set priority and queue settings for video in a
priority map.
match tunnel-group Specifies to match security-related tunnel groups. Use this if you
would like to match a VPN6 group of remote uses and force its
traffic into a priority map for inspection, IPS7, and so on.
match flow Specifies to match every flow based on a unique IP destination
address. This augments the match tunnel-group command, and
must be used with the tunnel-group command.
match default-inspection-traffic Specifies to match default traffic for the inspect commands. This
is used on the global interface and through the default policies.
You can also use it to match the default match criteria, so that
you can add additional actions via a policy map. It would be
easier to just modify the default policy map instead of creating a
new one.
NOTE You cannot assign the class map class-default, as it is a default catch-all class map
assigned to the global policy map. You can remove the default class map, although it is not
recommended. To do so, use the following commands in sequence:
pix(config)# no service-policy asa_global_fw_policy global
pix(config)# no policy-map asa_global_fw_policy
pix(config)# no class-map inspection_default
Step 1: Create a Class Map
You must assign a name to the class map. This name must be unique and should be intuitive
to the content it will be matching. Use the class-map command to create and assign a name
to a class map. To disable the command, use the no form of this command:
class-map class-map_name
When this command has been executed, it will enter the class map configuration mode.
Setting the different match criteria, as well as creating a description of the class map, can be
done in this mode. Table 8-2 provides a list of available commands.
Table 8-2 match Command Syntax
Command Description
description Specifies a description for the class-map command.
match any Specifies that all traffic is to be matched. This can be used to
catch all traffic flowing through an interface, regardless of the
content, type, or destination.
match access-list Specifies the name of an access list to be used as match criteria.
This can be used when a specific destination or source requires
special attention, as well as a unique set of policy actions. Using
access to the Internet falls under this category.
match port Specifies to match traffic using a TCP/UDP destination port. Use
this to assign a traffic class to a port not already specified by the
default port lists. Additionally, you can use this match type to
reassign matching for a known port, such as FTP, to a new port
location, such as 10234 instead of 21.
Class Map:
Internet
Class Map:
Voice
Class Map:
Inspect_Default
Match all traffic
through all
interfaces
Policy Map:
outside_interface
Policy Map:
Global Policy
Match using
Internet ACL
Match on
dscp cs5
Apply the following
actions to Internet
class-map
inspect IPS
Apply the following
actions to voice
class-map Priority
Apply the following
actions to
Inspect_Defaultmap:
Inspect
Service Policy:
Outside Interface
Service Policy:
Global Interface
match Command Syntax (Continued)
Command Description
match precedence Specifies to match the precedence value represented by the ToS1
byte in the IP header. Use this match when you are creating a set
of policy actions that affect priority and queuing, such as voice
and video. Make sure that the ToS byte has been assigned at the
source for this to function correctly.
match dscp Specifies to match the IETF2-defined DSCP3 value in the IP
header. Like the precedence match criteria cited previously, this
should be used when assigning actions that will affect priority
and queuing.
match rtp Specifies to match an RTP4 UDP5 port. This matching criterion
will allow you to set priority and queue settings for video in a
priority map.
match tunnel-group Specifies to match security-related tunnel groups. Use this if you
would like to match a VPN6 group of remote uses and force its
traffic into a priority map for inspection, IPS7, and so on.
match flow Specifies to match every flow based on a unique IP destination
address. This augments the match tunnel-group command, and
must be used with the tunnel-group command.
match default-inspection-traffic Specifies to match default traffic for the inspect commands. This
is used on the global interface and through the default policies.
You can also use it to match the default match criteria, so that
you can add additional actions via a policy map. It would be
easier to just modify the default policy map instead of creating a
new one.
1 ToS = Type of Service
2 IETF = Internet Engineering Task Force
3 DSCP = Differentiated Services Code Point
4 RTP = Real-Time Transport Protocol
5 UDP = User Datagram Protocol
6 VPN = virtual private network
7 IPS = Intrusion Protection Services
Command Description
match precedence Specifies to match the precedence value represented by the ToS1
byte in the IP header. Use this match when you are creating a set
of policy actions that affect priority and queuing, such as voice
and video. Make sure that the ToS byte has been assigned at the
source for this to function correctly.
match dscp Specifies to match the IETF2-defined DSCP3 value in the IP
header. Like the precedence match criteria cited previously, this
should be used when assigning actions that will affect priority
and queuing.
match rtp Specifies to match an RTP4 UDP5 port. This matching criterion
will allow you to set priority and queue settings for video in a
priority map.
match tunnel-group Specifies to match security-related tunnel groups. Use this if you
would like to match a VPN6 group of remote uses and force its
traffic into a priority map for inspection, IPS7, and so on.
match flow Specifies to match every flow based on a unique IP destination
address. This augments the match tunnel-group command, and
must be used with the tunnel-group command.
match default-inspection-traffic Specifies to match default traffic for the inspect commands. This
is used on the global interface and through the default policies.
You can also use it to match the default match criteria, so that
you can add additional actions via a policy map. It would be
easier to just modify the default policy map instead of creating a
new one.
NOTE You cannot assign the class map class-default, as it is a default catch-all class map
assigned to the global policy map. You can remove the default class map, although it is not
recommended. To do so, use the following commands in sequence:
pix(config)# no service-policy asa_global_fw_policy global
pix(config)# no policy-map asa_global_fw_policy
pix(config)# no class-map inspection_default
Traffic Flow Matching
Traffic Flow Matching
One of the essential features of an MPF is the granularity in which a security administrator
can inspect traffic flow. Class maps allow a security administrator to segregate the network
traffic flow within the network at the packet level. Each packet is identified for its content
and matched to attributes listed in the class map using the match command. The matched
traffic becomes a new traffic class. The class map representing the traffic class will then be
assigned to a policy map, which will apply actions (policies) to matched traffic. Creating a
class map requires two steps:
Step 1 Create a class map.
Step 2 Define class map matches.
Figure 8-1 illustrates how you can use class maps to inspect traffic flow.
One of the essential features of an MPF is the granularity in which a security administrator
can inspect traffic flow. Class maps allow a security administrator to segregate the network
traffic flow within the network at the packet level. Each packet is identified for its content
and matched to attributes listed in the class map using the match command. The matched
traffic becomes a new traffic class. The class map representing the traffic class will then be
assigned to a policy map, which will apply actions (policies) to matched traffic. Creating a
class map requires two steps:
Step 1 Create a class map.
Step 2 Define class map matches.
Figure 8-1 illustrates how you can use class maps to inspect traffic flow.
Modular Policy Framework Overview
Modular Policy Framework Overview
Today, more and more corporations are becoming active on the Internet, resulting in an everincreasing
need for a more granular means to configure network security policies. Therefore,
a security administrator needs to manipulate and control the flow of traffic in pieces and with
more flexibility. Rate limiting and prioritizing voice traffic, and deep packet inspecting of
untrusted traffic flows, are just some of the responsibilities of today’s security administrator.
With Security Appliance software version 7.0, this functionality has been enabled through
Modular Policy Framework (MPF). An MPF gives the security administrator the tools to
segment traffic flows into traffic classes and to assign one or more actions to each traffic class.
Traditional policy maps only allowed actions to be assigned to the total traffic flow on the
Security Appliance, whereas with an MPF, HTTP traffic can have a policy separate from
H.323 or ICMP.
Today, more and more corporations are becoming active on the Internet, resulting in an everincreasing
need for a more granular means to configure network security policies. Therefore,
a security administrator needs to manipulate and control the flow of traffic in pieces and with
more flexibility. Rate limiting and prioritizing voice traffic, and deep packet inspecting of
untrusted traffic flows, are just some of the responsibilities of today’s security administrator.
With Security Appliance software version 7.0, this functionality has been enabled through
Modular Policy Framework (MPF). An MPF gives the security administrator the tools to
segment traffic flows into traffic classes and to assign one or more actions to each traffic class.
Traditional policy maps only allowed actions to be assigned to the total traffic flow on the
Security Appliance, whereas with an MPF, HTTP traffic can have a policy separate from
H.323 or ICMP.
Foundation Summary
The “Foundation Summary” provides a convenient review of many key concepts in this
chapter. If you are already comfortable with the topics in this chapter, this summary can help
you recall a few details. If you just read this chapter, this review should help solidify some
key facts. If you are doing your final preparation before the exam, this summary provides a
convenient way to review the day before the exam.
Rules or translations have to be put in place to allow data traffic to and from hosts in a
network. Rules are usually made up of a static nat command and access list. The static nat
command identifies the subnet or host to which connections will be permitted to go. Access
lists are then configured to identify and permit the type of traffic to the subnet or host
identified by the static command.
The object grouping feature enables you to group objects such as hosts (servers and clients),
services, and networks and apply security policies and rules to the group. The four types of
object groups are these:
■ network
■ protocol
■ service
■ icmp-type
The Cisco Security Appliance supports several popular multimedia applications. Its
application inspection function dynamically opens and closes UDP ports for secure
multimedia connections. Popular multimedia applications such as RealPlayer and Microsoft
NetMeeting are supported by Cisco Security Appliance.
chapter. If you are already comfortable with the topics in this chapter, this summary can help
you recall a few details. If you just read this chapter, this review should help solidify some
key facts. If you are doing your final preparation before the exam, this summary provides a
convenient way to review the day before the exam.
Rules or translations have to be put in place to allow data traffic to and from hosts in a
network. Rules are usually made up of a static nat command and access list. The static nat
command identifies the subnet or host to which connections will be permitted to go. Access
lists are then configured to identify and permit the type of traffic to the subnet or host
identified by the static command.
The object grouping feature enables you to group objects such as hosts (servers and clients),
services, and networks and apply security policies and rules to the group. The four types of
object groups are these:
■ network
■ protocol
■ service
■ icmp-type
The Cisco Security Appliance supports several popular multimedia applications. Its
application inspection function dynamically opens and closes UDP ports for secure
multimedia connections. Popular multimedia applications such as RealPlayer and Microsoft
NetMeeting are supported by Cisco Security Appliance.
Simple Mail Transfer Protocol
Simple Mail Transfer Protocol
Simple Mail Transfer Protocol (SMTP) packets are closely monitored. An SMTP server
responds to client requests with numeric reply codes and optional human-readable strings.
SMTP application inspection controls and restricts the commands that the user can use as
well as the messages that the server returns. SMTP inspection performs these primary tasks:
■ Monitors the SMTP command-response sequence.
■ Permits only 7 of the 14 SMTP commands (HELO, MAIL, RCPT, DATA, RSET, NOOP,
and QUIT).
■ With ESMTP inspection, an additional eight commands are supported (AUTH, DATA,
EHLO, ETRN, SAML, SEND, SOML, and VRFY).
■ Generates an audit trail. Audit record 108002 is generated when an invalid character
embedded in the mail address is replaced.
Simple Mail Transfer Protocol (SMTP) packets are closely monitored. An SMTP server
responds to client requests with numeric reply codes and optional human-readable strings.
SMTP application inspection controls and restricts the commands that the user can use as
well as the messages that the server returns. SMTP inspection performs these primary tasks:
■ Monitors the SMTP command-response sequence.
■ Permits only 7 of the 14 SMTP commands (HELO, MAIL, RCPT, DATA, RSET, NOOP,
and QUIT).
■ With ESMTP inspection, an additional eight commands are supported (AUTH, DATA,
EHLO, ETRN, SAML, SEND, SOML, and VRFY).
■ Generates an audit trail. Audit record 108002 is generated when an invalid character
embedded in the mail address is replaced.
DNS
DNS
DNS uses a UDP connection. This makes DNS queries subject to generic UDP handling based
on activity timeouts. DNS, therefore, requires application inspection. As soon as the first
response is received for a DNS query, the UDP connection is terminated. This is known as
DNS guard and is discussed further in Chapter 19, “IPS and Advanced Protocol Handling.”
The DNS inspection task includes the following:
■ Compares the ID of the DNS reply to the ID of the DNS query.
■ Translates the DNS A record.
■ Confirms the length of the DNS packet is less than the maximum length specified by the
user. Otherwise, the packet is dropped.
DNS uses a UDP connection. This makes DNS queries subject to generic UDP handling based
on activity timeouts. DNS, therefore, requires application inspection. As soon as the first
response is received for a DNS query, the UDP connection is terminated. This is known as
DNS guard and is discussed further in Chapter 19, “IPS and Advanced Protocol Handling.”
The DNS inspection task includes the following:
■ Compares the ID of the DNS reply to the ID of the DNS query.
■ Translates the DNS A record.
■ Confirms the length of the DNS packet is less than the maximum length specified by the
user. Otherwise, the packet is dropped.
FTP
FTP
The FTP application inspection inspects FTP sessions and performs four tasks:
■ Prepares a dynamic secondary data connection
■ Tracks the ftp command-response sequence
■ Generates an audit trail
■ Translates the embedded IP address using NAT
FTP application inspection prepares secondary channels for FTP data transfer. The channels
are allocated in response to a file upload, a file download, or a directory listing event, and
they must be prenegotiated. The port is negotiated through the PORT or PASV (227)
commands.
You can use the inspect ftp command in a policy map to inspect the default port assignment
for FTP. The command syntax is as follows:
I [no] inspect ftp [strict]
The strict option prevents web browsers from sending embedded commands in FTP requests.
Each ftp command must be acknowledged before a new command is allowed. Connections
sending embedded commands are dropped. The strict option lets only the server generate the
PASV reply command (227) and lets only the client generate the PORT command. The PASV
reply and PORT commands are checked to ensure that they do not appear in an error string.
If you disable FTP fixups with the no inspect ftp command, inbound FTP is disabled. If you
have FTP servers using ports other than port 20 and 21, you need to use the class-map
command to identify these other traffic flows with their different FTP port numbers.
The FTP application inspection inspects FTP sessions and performs four tasks:
■ Prepares a dynamic secondary data connection
■ Tracks the ftp command-response sequence
■ Generates an audit trail
■ Translates the embedded IP address using NAT
FTP application inspection prepares secondary channels for FTP data transfer. The channels
are allocated in response to a file upload, a file download, or a directory listing event, and
they must be prenegotiated. The port is negotiated through the PORT or PASV (227)
commands.
You can use the inspect ftp command in a policy map to inspect the default port assignment
for FTP. The command syntax is as follows:
I [no] inspect ftp [strict]
The strict option prevents web browsers from sending embedded commands in FTP requests.
Each ftp command must be acknowledged before a new command is allowed. Connections
sending embedded commands are dropped. The strict option lets only the server generate the
PASV reply command (227) and lets only the client generate the PORT command. The PASV
reply and PORT commands are checked to ensure that they do not appear in an error string.
If you disable FTP fixups with the no inspect ftp command, inbound FTP is disabled. If you
have FTP servers using ports other than port 20 and 21, you need to use the class-map
command to identify these other traffic flows with their different FTP port numbers.
Advanced Protocol Handling
Advanced Protocol Handling
Some applications require special handling by the Cisco Security Appliance application
inspection function. These types of applications typically embed IP addressing information
in the user data packet or open secondary channels on dynamically assigned ports. The
application inspection function works with NAT to help identify the location of embedded
addressing information.
In addition to identifying embedded addressing information, the application inspection
function monitors sessions to determine the port numbers for secondary channels. Many
protocols open secondary TCP or UDP ports to improve performance. The initial session on
a well-known port is used to negotiate dynamically assigned port numbers. The application
inspection function monitors these sessions, identifies the dynamic port assignments, and
permits data exchange on these ports for the duration of the specific session. Multimedia
applications and FTP applications exhibit this kind of behavior.
Some applications require special handling by the Cisco Security Appliance application
inspection function. These types of applications typically embed IP addressing information
in the user data packet or open secondary channels on dynamically assigned ports. The
application inspection function works with NAT to help identify the location of embedded
addressing information.
In addition to identifying embedded addressing information, the application inspection
function monitors sessions to determine the port numbers for secondary channels. Many
protocols open secondary TCP or UDP ports to improve performance. The initial session on
a well-known port is used to negotiate dynamically assigned port numbers. The application
inspection function monitors these sessions, identifies the dynamic port assignments, and
permits data exchange on these ports for the duration of the specific session. Multimedia
applications and FTP applications exhibit this kind of behavior.
ACL Logging
ACL Logging
The ACL logging feature lets you log the number of permits or denies of a flow during a
specific period of time. A flow is defined by protocol, source IP address, source port,
destination IP address, and destination port. When a flow is permitted or denied, the system
checks to see if the flow already exists in the system. If not, an initial syslog message with a
hit count of 1 for the flow is generated. The flow entry is then created and the hit count for
the flow is incremented every time the flow is permitted or denied. The command syntax to
enable logging of the number of permits or denies of a flow by an ACL entry is as follows:
access-list acl-id [log [level] [interval seconds] | [disable|default]]
For an existing flow, a syslog message is generated at the end of each configurable interval to
report the nonzero hit count for the flow in the current interval. After the syslog message is
generated, the hit count for the flow is reset to 0 for the next interval. If there is no hit
recorded during the interval, the flow is deleted and no syslog message is generated. Large
numbers of flows may concurrently exist at any point in time. To prevent unlimited
consumption of memory and central processing unit (CPU) resources, a limit is placed on the
number of concurrent deny flows. When the limit is reached, no new deny flow will be
created until the existing deny flows expire. To specify the maximum number of concurrent
deny flows that can be created, enter the following command:
access-list deny-flow-max num-of-flows
The deny-flow-max keyword specifies the maximum number of concurrent deny flows that
can be created. New values for this option go into effect immediately. The default is set for
4096 flows allowed.
When the maximum number of flows has been reached, a syslog message (106101) is
generated. By default, this message is repeated once every 300 seconds.
The syslog message generated for the ACL entry has the following format:
106101: access-list ->
hit-cnt (first hit|n-second interval)
Advanced Protocol Handling
Some applications require special handling by the Cisco Security Appliance application
inspection function. These types of applications typically embed IP addressing information
in the user data packet or open secondary channels on dynamically assigned ports. The
application inspection function works with NAT to help identify the location of embedded
addressing information.
In addition to identifying embedded addressing information, the application inspection
function monitors sessions to determine the port numbers for secondary channels. Many
protocols open secondary TCP or UDP ports to improve performance. The initial session on
a well-known port is used to negotiate dynamically assigned port numbers. The application
inspection function monitors these sessions, identifies the dynamic port assignments, and
permits data exchange on these ports for the duration of the specific session. Multimedia
applications and FTP applications exhibit this kind of behavior.
Table 7-4 syslog Format Description
Field Description
Displays whether the flow is permitted or denied.
Displays the protocol type: tcp, udp, icmp, or an IP protocol number.
Displays the interface name (as configured by the nameif command) for
the source or destination of the logged flow. This can include logical
(virtual LAN) interfaces.
Displays the source IP address of the logged flow.
Displays the destination IP address of the logged flow.
Displays the source port of the logged flow (TCP or UDP). For ICMP, this
field is 0.
Displays the destination port of the logged flow (TCP or UDP). For ICMP,
this field is icmp-type.
Displays the number of times this flow was permitted or denied by the
ACL entry in the configured time interval. The value is 1 when the first
syslog message is generated for the flow.
first hit Displays the first message generated for this flow.
n-second interval Displays the interval over which the hit count is accumulated
The ACL logging feature lets you log the number of permits or denies of a flow during a
specific period of time. A flow is defined by protocol, source IP address, source port,
destination IP address, and destination port. When a flow is permitted or denied, the system
checks to see if the flow already exists in the system. If not, an initial syslog message with a
hit count of 1 for the flow is generated. The flow entry is then created and the hit count for
the flow is incremented every time the flow is permitted or denied. The command syntax to
enable logging of the number of permits or denies of a flow by an ACL entry is as follows:
access-list acl-id [log [level] [interval seconds] | [disable|default]]
For an existing flow, a syslog message is generated at the end of each configurable interval to
report the nonzero hit count for the flow in the current interval. After the syslog message is
generated, the hit count for the flow is reset to 0 for the next interval. If there is no hit
recorded during the interval, the flow is deleted and no syslog message is generated. Large
numbers of flows may concurrently exist at any point in time. To prevent unlimited
consumption of memory and central processing unit (CPU) resources, a limit is placed on the
number of concurrent deny flows. When the limit is reached, no new deny flow will be
created until the existing deny flows expire. To specify the maximum number of concurrent
deny flows that can be created, enter the following command:
access-list deny-flow-max num-of-flows
The deny-flow-max keyword specifies the maximum number of concurrent deny flows that
can be created. New values for this option go into effect immediately. The default is set for
4096 flows allowed.
When the maximum number of flows has been reached, a syslog message (106101) is
generated. By default, this message is repeated once every 300 seconds.
The syslog message generated for the ACL entry has the following format:
106101: access-list
Advanced Protocol Handling
Some applications require special handling by the Cisco Security Appliance application
inspection function. These types of applications typically embed IP addressing information
in the user data packet or open secondary channels on dynamically assigned ports. The
application inspection function works with NAT to help identify the location of embedded
addressing information.
In addition to identifying embedded addressing information, the application inspection
function monitors sessions to determine the port numbers for secondary channels. Many
protocols open secondary TCP or UDP ports to improve performance. The initial session on
a well-known port is used to negotiate dynamically assigned port numbers. The application
inspection function monitors these sessions, identifies the dynamic port assignments, and
permits data exchange on these ports for the duration of the specific session. Multimedia
applications and FTP applications exhibit this kind of behavior.
Table 7-4 syslog Format Description
Field Description
the source or destination of the logged flow. This can include logical
(virtual LAN) interfaces.
field is 0.
this field is icmp-type.
ACL entry in the configured time interval. The value is 1 when the first
syslog message is generated for the flow.
first hit Displays the first message generated for this flow.
n-second interval Displays the interval over which the hit count is accumulated
icmp-type Object Type
icmp-type Object Type
Internet Control Message Protocol (ICMP) object groups can be created to group certain
types of ICMP messages. For example, ICMP messages of ECHO-REQUEST, ECHOREPLY,
and DESTINATION-UNREACHABLE with numerical type values of 8, 0, and 3,
respectively, can be grouped as shown in Example 7-9.
Grouping ICMP Messages
pix(config)# object-group icmp-type icmp-test
pix(config-icmp-type)# icmp-object 0
pix(config-icmp-type)# icmp-object 3
pix(config-icmp-type)# icmp-object 8
Nesting Object Groups
You can add an object group within an object group. The object-group command allows
logical grouping of the same type of objects andicmp-type Object Type construction of hierarchical object groups
for structured configuration. To nest an object group within another object group, use the
group-object command. Example 7-10 illustrates the use of nested object groups.
Configuring Nested Object Groups
pixfirewall(config)# object-group network web-servers
pixfirewall(config-network)# description web servers
pixfirewall(config-network)# network-object host 192.168.1.12
pixfirewall(config-network)# network-object host 192.168.1.14
pixfirewall(config-network)# exit
pixfirewall(config)# object-group network Public-servers
pixfirewall(config-network)# description Public servers
pixfirewall(config-network)# network-object host 192.168.1.18
pixfirewall(config-network)# group-object web-servers
pixfirewall(config-network)# exit
Internet Control Message Protocol (ICMP) object groups can be created to group certain
types of ICMP messages. For example, ICMP messages of ECHO-REQUEST, ECHOREPLY,
and DESTINATION-UNREACHABLE with numerical type values of 8, 0, and 3,
respectively, can be grouped as shown in Example 7-9.
Grouping ICMP Messages
pix(config)# object-group icmp-type icmp-test
pix(config-icmp-type)# icmp-object 0
pix(config-icmp-type)# icmp-object 3
pix(config-icmp-type)# icmp-object 8
Nesting Object Groups
You can add an object group within an object group. The object-group command allows
logical grouping of the same type of objects andicmp-type Object Type construction of hierarchical object groups
for structured configuration. To nest an object group within another object group, use the
group-object command. Example 7-10 illustrates the use of nested object groups.
Configuring Nested Object Groups
pixfirewall(config)# object-group network web-servers
pixfirewall(config-network)# description web servers
pixfirewall(config-network)# network-object host 192.168.1.12
pixfirewall(config-network)# network-object host 192.168.1.14
pixfirewall(config-network)# exit
pixfirewall(config)# object-group network Public-servers
pixfirewall(config-network)# description Public servers
pixfirewall(config-network)# network-object host 192.168.1.18
pixfirewall(config-network)# group-object web-servers
pixfirewall(config-network)# exit
service Object Type
Example 7-7 Creating a New Protocol Object Group
pixfw(config)#object-group protocol grp-citrix
pixfw(config-protocol)#protocol-object tcp
pixfw(config-protocol)#protocol-object 1494
pixfw(config-protocol)#exit
service Object Type
The service object type identifies port numbers that can be grouped. This is particularly
useful when you are managing an application. The syntax for service object-type is
[no] object-group service obj-grp-id tcp | udp | tcp-udp
As soon as you are in the service subcommand, the command port-object eq service adds a
single TCP or UDP port number to the service object group. The port-object range beginservice
end-service command adds a range of TCP or UDP port numbers to the service object
group. Example 7-8 shows how to use object-group service subcommand mode to create a
new port (service) object group.
pixfw(config)#object-group protocol grp-citrix
pixfw(config-protocol)#protocol-object tcp
pixfw(config-protocol)#protocol-object 1494
pixfw(config-protocol)#exit
service Object Type
The service object type identifies port numbers that can be grouped. This is particularly
useful when you are managing an application. The syntax for service object-type is
[no] object-group service obj-grp-id tcp | udp | tcp-udp
As soon as you are in the service subcommand, the command port-object eq service adds a
single TCP or UDP port number to the service object group. The port-object range beginservice
end-service command adds a range of TCP or UDP port numbers to the service object
group. Example 7-8 shows how to use object-group service subcommand mode to create a
new port (service) object group.
network Object Type
network Object Type
The network object type is used to group hosts and subnets. Server and client hosts can be
grouped by functions. For example, mail servers, web servers, or a group of client hosts that
have special privileges on the network can be grouped accordingly.
Example 7-5 shows a web servers object group.
Configuring an Object Group
pixfirewall(config)#object-group network web-servers
pixfirewall(config-network)#description Public web servers
pixfirewall(config-network)#network-object host 192.168.1.12
pixfirewall(config-network)#network-object host 192.168.1.14
pixfirewall(config-network)# exit
pixfirewall(config)#access-list 102 permit tcp any object-group web-servers eq www
pixfirewall(config)#access-group 102 in interface outside
Notice that when you enter the object-group command, the system enters the appropriate
subcommand mode for the type of object you are configuring. In this case, you see the confignetwork
subcommand prompt. The network-object host subcommand adds the host to the
network object group. The description is optional, but it is helpful to include it.
NOTE It is also possible to use a name instead of an IP address when defining the
network host. For example:
pixfw(config)# object-group network mis-ftp-servers
pixfw(config-network)#network-object host 10.10.100.154
pixfw(config-network)#network-object host 10.10.100.155
pixfw(config-network)#network-object host 10.10.100.156
pixfw(config-network)#exit
To display the configured object group, use the show object-group command, as shown in
Example 7-6.
Displaying Configured Object Groups
pix(config)# show object-group
object-group network web-servers
description: Public web servers
network-object host 192.168.1.12
network-object host 192.168.1.14
The network object type is used to group hosts and subnets. Server and client hosts can be
grouped by functions. For example, mail servers, web servers, or a group of client hosts that
have special privileges on the network can be grouped accordingly.
Example 7-5 shows a web servers object group.
Configuring an Object Group
pixfirewall(config)#object-group network web-servers
pixfirewall(config-network)#description Public web servers
pixfirewall(config-network)#network-object host 192.168.1.12
pixfirewall(config-network)#network-object host 192.168.1.14
pixfirewall(config-network)# exit
pixfirewall(config)#access-list 102 permit tcp any object-group web-servers eq www
pixfirewall(config)#access-group 102 in interface outside
Notice that when you enter the object-group command, the system enters the appropriate
subcommand mode for the type of object you are configuring. In this case, you see the confignetwork
subcommand prompt. The network-object host subcommand adds the host to the
network object group. The description is optional, but it is helpful to include it.
NOTE It is also possible to use a name instead of an IP address when defining the
network host. For example:
pixfw(config)# object-group network mis-ftp-servers
pixfw(config-network)#network-object host 10.10.100.154
pixfw(config-network)#network-object host 10.10.100.155
pixfw(config-network)#network-object host 10.10.100.156
pixfw(config-network)#exit
To display the configured object group, use the show object-group command, as shown in
Example 7-6.
Displaying Configured Object Groups
pix(config)# show object-group
object-group network web-servers
description: Public web servers
network-object host 192.168.1.12
network-object host 192.168.1.14
Object Grouping
Object Grouping
Object grouping allows you to group objects such as hosts (servers and clients), services, and
networks and apply security policies and rules to the group. Object grouping lets you apply access
rules to logical groups of objects. When you apply an access list to an object group, the command
affects all objects defined in the group. Object grouping provides a way to reduce the number of
access rules required to describe complex security policies. This in turn reduces the time spent
configuring and troubleshooting access rules in large or complex networks.
The syntax for creating object groups is as follows:
[no] object-group object-type grp-id
Use the first parameter, object-type, to identify the type of object group you want to
configure. There are four options:
■ network
■ protocol
■ service
■ icmp-type
Replace grp-id with a descriptive name for the group.
Object grouping allows you to group objects such as hosts (servers and clients), services, and
networks and apply security policies and rules to the group. Object grouping lets you apply access
rules to logical groups of objects. When you apply an access list to an object group, the command
affects all objects defined in the group. Object grouping provides a way to reduce the number of
access rules required to describe complex security policies. This in turn reduces the time spent
configuring and troubleshooting access rules in large or complex networks.
The syntax for creating object groups is as follows:
[no] object-group object-type grp-id
Use the first parameter, object-type, to identify the type of object group you want to
configure. There are four options:
■ network
■ protocol
■ service
■ icmp-type
Replace grp-id with a descriptive name for the group.
Organizing and Managing ACE
Organizing and Managing ACE
It is quite common to have several access lists with several access-list elements in them on a
Cisco Security Appliance. To deal with this sometimes becomes arduous, especially in the
following situations:
■ When attempting to identify the reason for each ACE in the access list because no
descriptions or comments are included for software releases earlier than version 6.3
■ When removing a single ACE from an access list at the command line on software earlier
than version 6.3, which becomes a several-step process
Configuring a remark or comment allows you and other administrators to understand and
identify access-list entries. Cisco Security Appliances lets you include comments about entries
in any access control list (ACL). A remark can be up to 100 characters and can precede or
follow an access-list command. The following is the syntax for configuring an access-list
remark:
access-list acl-id remark text
The ACL remark can be placed before or after an access-list command statement, but it
should be placed in a consistent position so that it is clear which remark describes which
access-list command. For example, it would be confusing to have some remarks before the
associated access-list commands and some remarks after the associated access-list
commands. Example 7-3 shows a sample configuration on how to create comments
for ACEs.
In addition to adding remarks to access lists, version 6.3 and later add numbering to accesslist
elements. Each ACE and remark has an associated line number. Line numbers can then
be used to insert or delete elements at any position in an access list. These numbers are
maintained internally in increasing order starting from 1. The line numbers are always
maintained in increasing order, with an individual line number for each ACE.
Example 7-3 Configuring Comments for ACEs
Pixfw(config)#access-list 115 remark Allow network engineering group to telnet
PixfW(config)#access-list 115 permit tcp 192.168.1.0 255.255.255.224 host
10.10.100.20 telnet
PixfW(config)#access-list 115 remark Allowsales group to login
PixfW(config)#access-list 115 permit tcp 192.168.3.0 255.255.255.224 host
10.10.100.12
NOTE All ACEs resulting from a single object group access-list command statement have
a single line number. Consequently, you cannot insert an ACE in the middle of objectgroup
ACEs.
It is quite common to have several access lists with several access-list elements in them on a
Cisco Security Appliance. To deal with this sometimes becomes arduous, especially in the
following situations:
■ When attempting to identify the reason for each ACE in the access list because no
descriptions or comments are included for software releases earlier than version 6.3
■ When removing a single ACE from an access list at the command line on software earlier
than version 6.3, which becomes a several-step process
Configuring a remark or comment allows you and other administrators to understand and
identify access-list entries. Cisco Security Appliances lets you include comments about entries
in any access control list (ACL). A remark can be up to 100 characters and can precede or
follow an access-list command. The following is the syntax for configuring an access-list
remark:
access-list acl-id remark text
The ACL remark can be placed before or after an access-list command statement, but it
should be placed in a consistent position so that it is clear which remark describes which
access-list command. For example, it would be confusing to have some remarks before the
associated access-list commands and some remarks after the associated access-list
commands. Example 7-3 shows a sample configuration on how to create comments
for ACEs.
In addition to adding remarks to access lists, version 6.3 and later add numbering to accesslist
elements. Each ACE and remark has an associated line number. Line numbers can then
be used to insert or delete elements at any position in an access list. These numbers are
maintained internally in increasing order starting from 1. The line numbers are always
maintained in increasing order, with an individual line number for each ACE.
Example 7-3 Configuring Comments for ACEs
Pixfw(config)#access-list 115 remark Allow network engineering group to telnet
PixfW(config)#access-list 115 permit tcp 192.168.1.0 255.255.255.224 host
10.10.100.20 telnet
PixfW(config)#access-list 115 remark Allowsales group to login
PixfW(config)#access-list 115 permit tcp 192.168.3.0 255.255.255.224 host
10.10.100.12
NOTE All ACEs resulting from a single object group access-list command statement have
a single line number. Consequently, you cannot insert an ACE in the middle of objectgroup
ACEs.
Subscribe to:
Posts (Atom)