Configuring the Cisco Security Appliance to Send Syslog Messages to a Log
Server
Configuring a Security Appliance to send logging information to a server helps you collect
and maintain data that can later be used for forensic and data traffic analysis. The Security
Appliance syslog messages are usually sent to a syslog server or servers. The Security
Appliance uses UDP port 514 by default to send syslog messages to a syslog server. The
syntax for configuring the Security Appliance Firewall to send syslog messages to a syslog
server is as follows:
Pixfirewall(config)#Logging host [interface] ip_address [tcp[/port] | udp[/port]]
[format emblem]
The variables [interface] and ip-address are replaced with the name of the interface on which
the syslog resides and the Internet Protocol (IP) address of the syslog server, respectively. The
Cisco Security Appliance supports the EMBLEM format. EMBLEM syslog format is designed
to be consistent with the Cisco IOS Software format and is more compatible with CiscoWorks
management applications, such as Resource Manager Essentials (RME) syslog analyzer. Use
the option format emblem to send messages to the specified server in EMBLEM format.
The following steps show you how to configure a Security Appliance to send syslog messages:
Step 1 Designate a host to receive the messages with the logging host
command:
Pixfirewall(config)#logging host inside 10.1.1.10
NOTE This option is available only for UDP syslog messages, used by the RME syslog
analyzer.
260 Chapter 10: Syslog and the Cisco Security Appliance
You can specify additional servers so that if one goes offline, another is
available to receive messages.
Step 2 Set the logging level with the logging trap command:
Pixfirewall(config)#logging trap informational
If needed, set the logging facility command to a value other than its
default of 20. Most UNIX systems expect the messages to arrive at
facility 20.
Step 3 Start sending messages with the logging on command. To disable
sending messages, use the no logging command.
Step 4 To view your logging setting, enter show logging.
Centrally managing several Cisco Security Appliances can be challenging if you cannot
identify the origin of a particular message that is sent to the central log server. The Security
Appliance supports defining a unique device ID for log messages sent to a syslog server. If
several Security Appliances are configured to send their syslog messages to a single syslog
server, a unique identification can be configured so the message source can be identified. To
enable this option, use the following command:
logging device-id {hostname | ipaddress if_name | string text}
Table 10-4 gives a description of the parameters of the logging device-id command.
NOTE In the event that all syslog servers are offline, the Cisco Security Appliance stores
up to 100 messages in its memory. Subsequent messages that arrive overwrite the buffer
starting from the first line. PIX buffer logging is enabled by the command logging buffered
level.
Table 10-4 logging device-id Command Parameters
Parameter Description
hostname The name of the Security Appliance
ipaddress Specifies to use the IP address of the specified Security Appliance interface to
uniquely identify the syslog messages from the PIX Firewall
if-name The name of the interface with the IP address that is used to uniquely identify
the syslog messages from the Security Appliance
string text Specifies the text string to uniquely identify the syslog messages from the
Security Appliance
Configuring the ASDM to View Logging 261
When this feature is enabled, the message will include the specified device ID (either the
hostname or IP address of the specified interface—even if the message comes from another
interface—or a string) in messages sent to a syslog server. The Cisco Security Appliance will
insert the specified device ID into all non-EMBLEM-format syslog messages.
To disable this feature, use the following command:
no logging device-id
Configuring SNMP
Sending Syslog Messages to a Telnet Session
Sending Syslog Messages to a Telnet Session
Remotely troubleshooting or viewing real-time Security Appliance traffic patterns can be
done by configuring the PIX to send logging information to a Telnet session. The logging
monitor command configures the Security Appliance to send syslog messages to Telnet
sessions. For example, after logging into configuration mode, enter the following:
Pixfirewall (config)#logging monitor 6
Pixfirewall(config)#terminal monitor
In this example, syslog messages 0 to 6, or emergency to informational, are sent to a Telnet
session. To disable logging to Telnet, you use the no logging monitor command.
The terminal monitor displays messages directly to the Telnet session. You can disable the
direct display of messages by entering the terminal no monitor command. A Telnet session
sometimes is lost in busy networks when the logging monitor command is used.
Remotely troubleshooting or viewing real-time Security Appliance traffic patterns can be
done by configuring the PIX to send logging information to a Telnet session. The logging
monitor command configures the Security Appliance to send syslog messages to Telnet
sessions. For example, after logging into configuration mode, enter the following:
Pixfirewall (config)#logging monitor 6
Pixfirewall(config)#terminal monitor
In this example, syslog messages 0 to 6, or emergency to informational, are sent to a Telnet
session. To disable logging to Telnet, you use the no logging monitor command.
The terminal monitor displays messages directly to the Telnet session. You can disable the
direct display of messages by entering the terminal no monitor command. A Telnet session
sometimes is lost in busy networks when the logging monitor command is used.
Configuring Syslog Messages at the Console
Configuring Syslog Messages at the Console
Configuring logging on the console interface is useful when you are troubleshooting or
observing traffic patterns directly from a Security Appliance. This gives you real-time
information about what is happening on the Security Appliance. To configure logging at the
Security Appliance console interface, use the logging console command as follows. After
logging into configuration mode, enter the following:
Pixfw(config)#logging on
Pixfw(config)#logging console 5
The 5 indicates the logging level. In this case, it is logging notification. From the console, you
can see the logs in real time.
Configuring logging on the console interface is useful when you are troubleshooting or
observing traffic patterns directly from a Security Appliance. This gives you real-time
information about what is happening on the Security Appliance. To configure logging at the
Security Appliance console interface, use the logging console command as follows. After
logging into configuration mode, enter the following:
Pixfw(config)#logging on
Pixfw(config)#logging console 5
The 5 indicates the logging level. In this case, it is logging notification. From the console, you
can see the logs in real time.
Configuring the ASDM to View Logging
Configuring the ASDM to View Logging
The ASDM Log panel, shown in Figure 10-1, allows you to view syslog messages that are
captured in the ASDM Log buffer in the Security Appliance memory. You may select the level
of syslog messages you want to view. When you view the ASDM Log, all the buffered syslog
messages at and below the logging level you choose are displayed.
loggin device -id n Sets the device ID that will be logged with a syslog
message.
logging host [interface] ip_address Specifies the host that receives the syslog messages.
[protocol/ port] A Cisco Security Appliance can send messages across
UDP or TCP (which you specify by setting the protocol
variable). The default UDP port is 514. The default
TCP port is 1470.
logging history severity_level Sets the logging level for SNMP traps.
logging queue msg_count Specifies how many syslog messages can appear in the
message queue while waiting for processing. The
default is 512 messages. Use the show logging queue
command to view queue statistics.
logging timestamp Specifies that each message sent to the syslog server
should include a timestamp to indicate when the event
occurred.
logging trap n Sets the logging level for syslog messages.
show logging disabled Displays a complete list of disabled syslog messages.
show logging Lists the current syslog messages and which logging
command options are enabled.
logging standby Lets the failover standby unit send syslog messages.
Table 10-3 logging Command Parameters (Continued)
Command Description
Configuring the ASDM to View Logging 257
Figure 10-1 ASDM Log Viewer Screen
The ASDM logging panel has the following fields:
■ Logging Level—Enables you to choose the level of syslog messages to view.
To view the logs using the PDM interface, click the View button shown in Figure 10-1. Figure
10-2 shows a sample output of logs viewed from the PDM logging panel.
■ Buffer Limit—Sets the maximum number of log messages that will display. The default
for this value is 1000.
258 Chapter 10: Syslog and the Cisco Security Appliance
Figure 10-2 Sample ASDM Logging Output
ASDM is discussed in further detail in Chapter 15, “Adaptive Security Device Manager.”
The ASDM Log panel, shown in Figure 10-1, allows you to view syslog messages that are
captured in the ASDM Log buffer in the Security Appliance memory. You may select the level
of syslog messages you want to view. When you view the ASDM Log, all the buffered syslog
messages at and below the logging level you choose are displayed.
loggin device -id n Sets the device ID that will be logged with a syslog
message.
logging host [interface] ip_address Specifies the host that receives the syslog messages.
[protocol/ port] A Cisco Security Appliance can send messages across
UDP or TCP (which you specify by setting the protocol
variable). The default UDP port is 514. The default
TCP port is 1470.
logging history severity_level Sets the logging level for SNMP traps.
logging queue msg_count Specifies how many syslog messages can appear in the
message queue while waiting for processing. The
default is 512 messages. Use the show logging queue
command to view queue statistics.
logging timestamp Specifies that each message sent to the syslog server
should include a timestamp to indicate when the event
occurred.
logging trap n Sets the logging level for syslog messages.
show logging disabled Displays a complete list of disabled syslog messages.
show logging Lists the current syslog messages and which logging
command options are enabled.
logging standby Lets the failover standby unit send syslog messages.
Table 10-3 logging Command Parameters (Continued)
Command Description
Configuring the ASDM to View Logging 257
Figure 10-1 ASDM Log Viewer Screen
The ASDM logging panel has the following fields:
■ Logging Level—Enables you to choose the level of syslog messages to view.
To view the logs using the PDM interface, click the View button shown in Figure 10-1. Figure
10-2 shows a sample output of logs viewed from the PDM logging panel.
■ Buffer Limit—Sets the maximum number of log messages that will display. The default
for this value is 1000.
258 Chapter 10: Syslog and the Cisco Security Appliance
Figure 10-2 Sample ASDM Logging Output
ASDM is discussed in further detail in Chapter 15, “Adaptive Security Device Manager.”
Configuring Syslog on a Cisco Security Appliance
Configuring Syslog on a Cisco Security Appliance
The logging command is used to configure logging on the PIX Firewall. Logging is disabled
by default. Table 10-3 describes the parameters of the logging command.
Table 10-3 logging Command Parameters
Command Description
logging on Enables the transmission of syslog messages to all
output locations. You can disable sending syslog
messages with the no logging on command.
no logging message n Allows you to disable specific syslog messages. Use the
logging message message_number command to resume
logging of specific disabled messages.
logging buffered n Stores syslog messages in the Cisco Security Appliance
so that you can view them with the show logging
command. Cisco Systems recommends that you use this
command to view syslog messages when the PIX
Seecurity Appliance is in use on a network.
clear logging Clears the message buffer created with the logging
buffered command.
clear logging message Reenables all disabled syslog messages.
logging console n Displays syslog messages on a Security Appliance
console as they occur. Use this command when you are
debugging problems or when there is minimal load on
the network. Do not use this command when the
network is busy because it can reduce the Security
Appliance performance.
logging monitor n Displays syslog messages when you access the Security
Appliance console with Telnet.
continues
256 Chapter 10: Syslog and the Cisco Security Appliance
Configuring the ASDM to View Logging
The ASDM Log panel, shown in Figure 10-1, allows you to view syslog messages that are
captured in the ASDM Log buffer in the Security Appliance memory. You may select the level
of syslog messages you want to view. When you view the ASDM Log, all the buffered syslog
messages at and below the logging level you choose are displayed.
loggin device -id n Sets the device ID that will be logged with a syslog
message.
logging host [interface] ip_address Specifies the host that receives the syslog messages.
[protocol/ port] A Cisco Security Appliance can send messages across
UDP or TCP (which you specify by setting the protocol
variable). The default UDP port is 514. The default
TCP port is 1470.
logging history severity_level Sets the logging level for SNMP traps.
logging queue msg_count Specifies how many syslog messages can appear in the
message queue while waiting for processing. The
default is 512 messages. Use the show logging queue
command to view queue statistics.
logging timestamp Specifies that each message sent to the syslog server
should include a timestamp to indicate when the event
occurred.
logging trap n Sets the logging level for syslog messages.
show logging disabled Displays a complete list of disabled syslog messages.
show logging Lists the current syslog messages and which logging
command options are enabled.
logging standby Lets the failover standby unit send syslog messages.
The logging command is used to configure logging on the PIX Firewall. Logging is disabled
by default. Table 10-3 describes the parameters of the logging command.
Table 10-3 logging Command Parameters
Command Description
logging on Enables the transmission of syslog messages to all
output locations. You can disable sending syslog
messages with the no logging on command.
no logging message n Allows you to disable specific syslog messages. Use the
logging message message_number command to resume
logging of specific disabled messages.
logging buffered n Stores syslog messages in the Cisco Security Appliance
so that you can view them with the show logging
command. Cisco Systems recommends that you use this
command to view syslog messages when the PIX
Seecurity Appliance is in use on a network.
clear logging Clears the message buffer created with the logging
buffered command.
clear logging message Reenables all disabled syslog messages.
logging console n Displays syslog messages on a Security Appliance
console as they occur. Use this command when you are
debugging problems or when there is minimal load on
the network. Do not use this command when the
network is busy because it can reduce the Security
Appliance performance.
logging monitor n Displays syslog messages when you access the Security
Appliance console with Telnet.
continues
256 Chapter 10: Syslog and the Cisco Security Appliance
Configuring the ASDM to View Logging
The ASDM Log panel, shown in Figure 10-1, allows you to view syslog messages that are
captured in the ASDM Log buffer in the Security Appliance memory. You may select the level
of syslog messages you want to view. When you view the ASDM Log, all the buffered syslog
messages at and below the logging level you choose are displayed.
loggin device -id n Sets the device ID that will be logged with a syslog
message.
logging host [interface] ip_address Specifies the host that receives the syslog messages.
[protocol/ port] A Cisco Security Appliance can send messages across
UDP or TCP (which you specify by setting the protocol
variable). The default UDP port is 514. The default
TCP port is 1470.
logging history severity_level Sets the logging level for SNMP traps.
logging queue msg_count Specifies how many syslog messages can appear in the
message queue while waiting for processing. The
default is 512 messages. Use the show logging queue
command to view queue statistics.
logging timestamp Specifies that each message sent to the syslog server
should include a timestamp to indicate when the event
occurred.
logging trap n Sets the logging level for syslog messages.
show logging disabled Displays a complete list of disabled syslog messages.
show logging Lists the current syslog messages and which logging
command options are enabled.
logging standby Lets the failover standby unit send syslog messages.
How to Read System Log Messages
How to Read System Log Messages
System log messages received at a syslog server begin with a percent sign (%) and are
structured as follows:
%PIX-level-message-number: message-text
Example 10-1 Changing the Level of a Syslog Message
pixfirewall(config)#n
syslog 403503: default-level errors (enabled)
rpixfirewall(config)#logging message 403503 level 6
pixfirewall(config)#show logging message 403503
syslog 403503: default-level errors, current-level informational (enabled)
Configuring Syslog on a Cisco Security Appliance 255
■ PIX identifies the message facility code for messages generated by the Cisco Security
Appliance.
■ level reflects the severity of the condition described by the message. The lower the
number, the more serious the condition.
■ message-number is the numeric code that uniquely identifies the message.
■ message-text is a text string describing the condition. This portion of the message
sometimes includes IP addresses, port numbers, or usernames.
You can find more information on syslog messages at http://www.cisco.com/en/US/products/
sw/secursw/ps2120/products_system_message_guide_book09186a00801582a9.html.
System log messages received at a syslog server begin with a percent sign (%) and are
structured as follows:
%PIX-level-message-number: message-text
Example 10-1 Changing the Level of a Syslog Message
pixfirewall(config)#n
syslog 403503: default-level errors (enabled)
rpixfirewall(config)#logging message 403503 level 6
pixfirewall(config)#show logging message 403503
syslog 403503: default-level errors, current-level informational (enabled)
Configuring Syslog on a Cisco Security Appliance 255
■ PIX identifies the message facility code for messages generated by the Cisco Security
Appliance.
■ level reflects the severity of the condition described by the message. The lower the
number, the more serious the condition.
■ message-number is the numeric code that uniquely identifies the message.
■ message-text is a text string describing the condition. This portion of the message
sometimes includes IP addresses, port numbers, or usernames.
You can find more information on syslog messages at http://www.cisco.com/en/US/products/
sw/secursw/ps2120/products_system_message_guide_book09186a00801582a9.html.
How Log Messages Are Organized
How Log Messages Are Organized
Syslog messages are listed numerically by message code. Each message is followed by a brief
explanation and a recommended action. If several messages share the same explanation and
recommended action, the messages are presented together, followed by the common
explanation and recommended action.
The explanation of each message indicates what kind of event generated the message.
Possible events include the following:
■ Authentication, authorization, and accounting (AAA) events
■ Connection events (for example, connections denied by the PIX configuration or address
translation errors)
■ Failover events reported by one or both units of a failover pair
■ File Transfer Protocol (FTP)/Uniform Resource Locator (URL) events (for example,
successful file transfers or blocked Java applets)
■ Mail Guard/SNMP events
■ Security Appliance management events (for example, configuration events or Telnet
connections to the Security Appliance console port)
■ Routing errors
Syslog messages are listed numerically by message code. Each message is followed by a brief
explanation and a recommended action. If several messages share the same explanation and
recommended action, the messages are presented together, followed by the common
explanation and recommended action.
The explanation of each message indicates what kind of event generated the message.
Possible events include the following:
■ Authentication, authorization, and accounting (AAA) events
■ Connection events (for example, connections denied by the PIX configuration or address
translation errors)
■ Failover events reported by one or both units of a failover pair
■ File Transfer Protocol (FTP)/Uniform Resource Locator (URL) events (for example,
successful file transfers or blocked Java applets)
■ Mail Guard/SNMP events
■ Security Appliance management events (for example, configuration events or Telnet
connections to the Security Appliance console port)
■ Routing errors
cisco works
calismalar hizlanarak devam ediyor ing sitler üzerinde sürdürdüğümüz çalışmalar sonucunda en güncel bilgileri sizlerle palaşacağız.
Configuring the Cisco Security Appliance to Send Syslog Messages to a Log Server Configuring a Security Appliance to send logging information to a ser
Configuring the Cisco Security Appliance to Send Syslog Messages to a Log
Server
Configuring a Security Appliance to send logging information to a server helps you collect
and maintain data that can later be used for forensic and data traffic analysis. The Security
Appliance syslog messages are usually sent to a syslog server or servers. The Security
Appliance uses UDP port 514 by default to send syslog messages to a syslog server. The
syntax for configuring the Security Appliance Firewall to send syslog messages to a syslog
server is as follows:
Pixfirewall(config)#Logging host [interface] ip_address [tcp[/port] | udp[/port]]
[format emblem]
The variables [interface] and ip-address are replaced with the name of the interface on which
the syslog resides and the Internet Protocol (IP) address of the syslog server, respectively. The
Cisco Security Appliance supports the EMBLEM format. EMBLEM syslog format is designed
to be consistent with the Cisco IOS Software format and is more compatible with CiscoWorks
management applications, such as Resource Manager Essentials (RME) syslog analyzer. Use
the option format emblem to send messages to the specified server in EMBLEM format.
The following steps show you how to configure a Security Appliance to send syslog messages:
Step 1 Designate a host to receive the messages with the logging host
command:
Pixfirewall(config)#logging host inside 10.1.1.10
You can specify additional servers so that if one goes offline, another is
available to receive messages.
Step 2 Set the logging level with the logging trap command:
Pixfirewall(config)#logging trap informational
If needed, set the logging facility command to a value other than its
default of 20. Most UNIX systems expect the messages to arrive at
facility 20.
Step 3 Start sending messages with the logging on command. To disable
sending messages, use the no logging command.
Step 4 To view your logging setting, enter show logging.
Centrally managing several Cisco Security Appliances can be challenging if you cannot
identify the origin of a particular message that is sent to the central log server. The Security
Appliance supports defining a unique device ID for log messages sent to a syslog server. If
several Security Appliances are configured to send their syslog messages to a single syslog
server, a unique identification can be configured so the message source can be identified. To
enable this option, use the following command:
logging device-id {hostname | ipaddress if_name | string text}
logging device-id Command Parameters
Parameter Description
hostname The name of the Security Appliance
ipaddress Specifies to use the IP address of the specified Security Appliance interface to
uniquely identify the syslog messages from the PIX Firewall
if-name The name of the interface with the IP address that is used to uniquely identify
the syslog messages from the Security Appliance
string text Specifies the text string to uniquely identify the syslog messages from the
Security Appliance
When this feature is enabled, the message will include the specified device ID (either the
hostname or IP address of the specified interface—even if the message comes from another
interface—or a string) in messages sent to a syslog server. The Cisco Security Appliance will
insert the specified device ID into all non-EMBLEM-format syslog messages.
To disable this feature, use the following command:
no logging device-id
Server
Configuring a Security Appliance to send logging information to a server helps you collect
and maintain data that can later be used for forensic and data traffic analysis. The Security
Appliance syslog messages are usually sent to a syslog server or servers. The Security
Appliance uses UDP port 514 by default to send syslog messages to a syslog server. The
syntax for configuring the Security Appliance Firewall to send syslog messages to a syslog
server is as follows:
Pixfirewall(config)#Logging host [interface] ip_address [tcp[/port] | udp[/port]]
[format emblem]
The variables [interface] and ip-address are replaced with the name of the interface on which
the syslog resides and the Internet Protocol (IP) address of the syslog server, respectively. The
Cisco Security Appliance supports the EMBLEM format. EMBLEM syslog format is designed
to be consistent with the Cisco IOS Software format and is more compatible with CiscoWorks
management applications, such as Resource Manager Essentials (RME) syslog analyzer. Use
the option format emblem to send messages to the specified server in EMBLEM format.
The following steps show you how to configure a Security Appliance to send syslog messages:
Step 1 Designate a host to receive the messages with the logging host
command:
Pixfirewall(config)#logging host inside 10.1.1.10
You can specify additional servers so that if one goes offline, another is
available to receive messages.
Step 2 Set the logging level with the logging trap command:
Pixfirewall(config)#logging trap informational
If needed, set the logging facility command to a value other than its
default of 20. Most UNIX systems expect the messages to arrive at
facility 20.
Step 3 Start sending messages with the logging on command. To disable
sending messages, use the no logging command.
Step 4 To view your logging setting, enter show logging.
Centrally managing several Cisco Security Appliances can be challenging if you cannot
identify the origin of a particular message that is sent to the central log server. The Security
Appliance supports defining a unique device ID for log messages sent to a syslog server. If
several Security Appliances are configured to send their syslog messages to a single syslog
server, a unique identification can be configured so the message source can be identified. To
enable this option, use the following command:
logging device-id {hostname | ipaddress if_name | string text}
logging device-id Command Parameters
Parameter Description
hostname The name of the Security Appliance
ipaddress Specifies to use the IP address of the specified Security Appliance interface to
uniquely identify the syslog messages from the PIX Firewall
if-name The name of the interface with the IP address that is used to uniquely identify
the syslog messages from the Security Appliance
string text Specifies the text string to uniquely identify the syslog messages from the
Security Appliance
When this feature is enabled, the message will include the specified device ID (either the
hostname or IP address of the specified interface—even if the message comes from another
interface—or a string) in messages sent to a syslog server. The Cisco Security Appliance will
insert the specified device ID into all non-EMBLEM-format syslog messages.
To disable this feature, use the following command:
no logging device-id
Configuring the ASDM to View Logging
Configuring the ASDM to View Logging
The ASDM Log panel, shown in Figure 10-1, allows you to view syslog messages that are
captured in the ASDM Log buffer in the Security Appliance memory. You may select the level
of syslog messages you want to view. When you view the ASDM Log, all the buffered syslog
messages at and below the logging level you choose are displayed.
ASDM Log Viewer Screen
The ASDM logging panel has the following fields:
■ Logging Level—Enables you to choose the level of syslog messages to view.
To view the logs using the PDM interface, click the View button shown in Figure 10-1. Figure
10-2 shows a sample output of logs viewed from the PDM logging panel.
■ Buffer Limit—Sets the maximum number of log messages that will display. The default
for this value is 1000.
Configuring Syslog Messages at the Console
Configuring logging on the console interface is useful when you are troubleshooting or
observing traffic patterns directly from a Security Appliance. This gives you real-time
information about what is happening on the Security Appliance. To configure logging at the
Security Appliance console interface, use the logging console command as follows. After
logging into configuration mode, enter the following:
Pixfw(config)#logging on
Pixfw(config)#logging console 5
The 5 indicates the logging level. In this case, it is logging notification. From the console, you
can see the logs in real time.
Sending Syslog Messages to a Telnet Session
Remotely troubleshooting or viewing real-time Security Appliance traffic patterns can be
done by configuring the PIX to send logging information to a Telnet session. The logging
monitor command configures the Security Appliance to send syslog messages to Telnet
sessions. For example, after logging into configuration mode, enter the following:
Pixfirewall (config)#logging monitor 6
Pixfirewall(config)#terminal monitor
In this example, syslog messages 0 to 6, or emergency to informational, are sent to a Telnet
session. To disable logging to Telnet, you use the no logging monitor command.
The terminal monitor displays messages directly to the Telnet session. You can disable the
direct display of messages by entering the terminal no monitor command. A Telnet session
sometimes is lost in busy networks when the logging monitor command is used.
The ASDM Log panel, shown in Figure 10-1, allows you to view syslog messages that are
captured in the ASDM Log buffer in the Security Appliance memory. You may select the level
of syslog messages you want to view. When you view the ASDM Log, all the buffered syslog
messages at and below the logging level you choose are displayed.
ASDM Log Viewer Screen
The ASDM logging panel has the following fields:
■ Logging Level—Enables you to choose the level of syslog messages to view.
To view the logs using the PDM interface, click the View button shown in Figure 10-1. Figure
10-2 shows a sample output of logs viewed from the PDM logging panel.
■ Buffer Limit—Sets the maximum number of log messages that will display. The default
for this value is 1000.
Configuring Syslog Messages at the Console
Configuring logging on the console interface is useful when you are troubleshooting or
observing traffic patterns directly from a Security Appliance. This gives you real-time
information about what is happening on the Security Appliance. To configure logging at the
Security Appliance console interface, use the logging console command as follows. After
logging into configuration mode, enter the following:
Pixfw(config)#logging on
Pixfw(config)#logging console 5
The 5 indicates the logging level. In this case, it is logging notification. From the console, you
can see the logs in real time.
Sending Syslog Messages to a Telnet Session
Remotely troubleshooting or viewing real-time Security Appliance traffic patterns can be
done by configuring the PIX to send logging information to a Telnet session. The logging
monitor command configures the Security Appliance to send syslog messages to Telnet
sessions. For example, after logging into configuration mode, enter the following:
Pixfirewall (config)#logging monitor 6
Pixfirewall(config)#terminal monitor
In this example, syslog messages 0 to 6, or emergency to informational, are sent to a Telnet
session. To disable logging to Telnet, you use the no logging monitor command.
The terminal monitor displays messages directly to the Telnet session. You can disable the
direct display of messages by entering the terminal no monitor command. A Telnet session
sometimes is lost in busy networks when the logging monitor command is used.
logging Command Parameters (Continued)
loggin device -id n Sets the device ID that will be logged with a syslog
message.
logging host [interface] ip_address Specifies the host that receives the syslog messages.
[protocol/ port] A Cisco Security Appliance can send messages across
UDP or TCP (which you specify by setting the protocol
variable). The default UDP port is 514. The default
TCP port is 1470.
logging history severity_level Sets the logging level for SNMP traps.
logging queue msg_count Specifies how many syslog messages can appear in the
message queue while waiting for processing. The
default is 512 messages. Use the show logging queue
command to view queue statistics.
logging timestamp Specifies that each message sent to the syslog server
should include a timestamp to indicate when the event
occurred.
logging trap n Sets the logging level for syslog messages.
show logging disabled Displays a complete list of disabled syslog messages.
show logging Lists the current syslog messages and which logging
command options are enabled.
logging standby Lets the failover standby unit send syslog messages.
Table 10-3 logging Command Parameters (Continued)
message.
logging host [interface] ip_address Specifies the host that receives the syslog messages.
[protocol/ port] A Cisco Security Appliance can send messages across
UDP or TCP (which you specify by setting the protocol
variable). The default UDP port is 514. The default
TCP port is 1470.
logging history severity_level Sets the logging level for SNMP traps.
logging queue msg_count Specifies how many syslog messages can appear in the
message queue while waiting for processing. The
default is 512 messages. Use the show logging queue
command to view queue statistics.
logging timestamp Specifies that each message sent to the syslog server
should include a timestamp to indicate when the event
occurred.
logging trap n Sets the logging level for syslog messages.
show logging disabled Displays a complete list of disabled syslog messages.
show logging Lists the current syslog messages and which logging
command options are enabled.
logging standby Lets the failover standby unit send syslog messages.
Table 10-3 logging Command Parameters (Continued)
Configuring Syslog on a Cisco Security Appliance
Configuring Syslog on a Cisco Security Appliance
The logging command is used to configure logging on the PIX Firewall. Logging is disabled
by default. Table 10-3 describes the parameters of the logging command.
Table 10-3 logging Command Parameters
Command Description
logging on Enables the transmission of syslog messages to all
output locations. You can disable sending syslog
messages with the no logging on command.
no logging message n Allows you to disable specific syslog messages. Use the
logging message message_number command to resume
logging of specific disabled messages.
logging buffered n Stores syslog messages in the Cisco Security Appliance
so that you can view them with the show logging
command. Cisco Systems recommends that you use this
command to view syslog messages when the PIX
Seecurity Appliance is in use on a network.
clear logging Clears the message buffer created with the logging
buffered command.
clear logging message Reenables all disabled syslog messages.
logging console n Displays syslog messages on a Security Appliance
console as they occur. Use this command when you are
debugging problems or when there is minimal load on
the network. Do not use this command when the
network is busy because it can reduce the Security
Appliance performance.
logging monitor n Displays syslog messages when you access the Security
Appliance console with Telnet.
continues
The logging command is used to configure logging on the PIX Firewall. Logging is disabled
by default. Table 10-3 describes the parameters of the logging command.
Table 10-3 logging Command Parameters
Command Description
logging on Enables the transmission of syslog messages to all
output locations. You can disable sending syslog
messages with the no logging on command.
no logging message n Allows you to disable specific syslog messages. Use the
logging message message_number command to resume
logging of specific disabled messages.
logging buffered n Stores syslog messages in the Cisco Security Appliance
so that you can view them with the show logging
command. Cisco Systems recommends that you use this
command to view syslog messages when the PIX
Seecurity Appliance is in use on a network.
clear logging Clears the message buffer created with the logging
buffered command.
clear logging message Reenables all disabled syslog messages.
logging console n Displays syslog messages on a Security Appliance
console as they occur. Use this command when you are
debugging problems or when there is minimal load on
the network. Do not use this command when the
network is busy because it can reduce the Security
Appliance performance.
logging monitor n Displays syslog messages when you access the Security
Appliance console with Telnet.
continues
How to Read System Log Messages
How to Read System Log Messages
System log messages received at a syslog server begin with a percent sign (%) and are
structured as follows:
%PIX-level-message-number: message-text
■ PIX identifies the message facility code for messages generated by the Cisco Security
Appliance.
■ level reflects the severity of the condition described by the message. The lower the
number, the more serious the condition.
■ message-number is the numeric code that uniquely identifies the message.
■ message-text is a text string describing the condition. This portion of the message
sometimes includes IP addresses, port numbers, or usernames.
You can find more information on syslog messages at http://www.cisco.com/en/US/products/
sw/secursw/ps2120/products_system_message_guide_book09186a00801582a9.html.
System log messages received at a syslog server begin with a percent sign (%) and are
structured as follows:
%PIX-level-message-number: message-text
■ PIX identifies the message facility code for messages generated by the Cisco Security
Appliance.
■ level reflects the severity of the condition described by the message. The lower the
number, the more serious the condition.
■ message-number is the numeric code that uniquely identifies the message.
■ message-text is a text string describing the condition. This portion of the message
sometimes includes IP addresses, port numbers, or usernames.
You can find more information on syslog messages at http://www.cisco.com/en/US/products/
sw/secursw/ps2120/products_system_message_guide_book09186a00801582a9.html.
How Log Messages Are Organized
How Log Messages Are Organized
Syslog messages are listed numerically by message code. Each message is followed by a brief
explanation and a recommended action. If several messages share the same explanation and
recommended action, the messages are presented together, followed by the common
explanation and recommended action.
The explanation of each message indicates what kind of event generated the message.
Possible events include the following:
■ Authentication, authorization, and accounting (AAA) events
■ Connection events (for example, connections denied by the PIX configuration or address
translation errors)
■ Failover events reported by one or both units of a failover pair
■ File Transfer Protocol (FTP)/Uniform Resource Locator (URL) events (for example,
successful file transfers or blocked Java applets)
■ Mail Guard/SNMP events
■ Security Appliance management events (for example, configuration events or Telnet
connections to the Security Appliance console port)
■ Routing errors
Syslog messages are listed numerically by message code. Each message is followed by a brief
explanation and a recommended action. If several messages share the same explanation and
recommended action, the messages are presented together, followed by the common
explanation and recommended action.
The explanation of each message indicates what kind of event generated the message.
Possible events include the following:
■ Authentication, authorization, and accounting (AAA) events
■ Connection events (for example, connections denied by the PIX configuration or address
translation errors)
■ Failover events reported by one or both units of a failover pair
■ File Transfer Protocol (FTP)/Uniform Resource Locator (URL) events (for example,
successful file transfers or blocked Java applets)
■ Mail Guard/SNMP events
■ Security Appliance management events (for example, configuration events or Telnet
connections to the Security Appliance console port)
■ Routing errors
Static Routes
Static Routes
Static routes are manually configured routes that do not frequently change. They essentially
direct your Security Appliance to send traffic destined for a specific network to a specific
router that has connectivity to the destination network. Static routes are perhaps best
explained by using a network example. Figure 11-1 illustrates a simple network
configuration with hosts on both the 10.10.10.0 and 10.10.20.0 networks.
Static routes are manually configured routes that do not frequently change. They essentially
direct your Security Appliance to send traffic destined for a specific network to a specific
router that has connectivity to the destination network. Static routes are perhaps best
explained by using a network example. Figure 11-1 illustrates a simple network
configuration with hosts on both the 10.10.10.0 and 10.10.20.0 networks.
IP Routing
IP Routing
At the IP layer, your Cisco Security Appliance routes traffic based on the IP addresses in the
network traffic. It does not provide all the functionality of a router, but it does enable you to
define the following two types of routes:
■ Static routes
■ Dynamic routes
At the IP layer, your Cisco Security Appliance routes traffic based on the IP addresses in the
network traffic. It does not provide all the functionality of a router, but it does enable you to
define the following two types of routes:
■ Static routes
■ Dynamic routes
Managing VLANs
Managing VLANs
After you create your logical interfaces, you also need to assign the following parameters to
each logical interface:
■ Interface name
■ Security level
■ IP address
Table 11-6 interface Command Parameters
Parameter Description
hardware-id Specifies the network interface on which the command will be applied (such
as Ethernet0).
subinterface-num The subinterface identifier that will be assigned for this logical interface,
which can be between 1 and 4,294,967,293.
mapped-name In multiple-context mode, enter the mapped name if it was assigned using the
allocate-interface command.
shutdown Keyword indicating that the interface should be administratively shut down.
NOTE You do not need to assign a VLAN to the physical interface to assign logical
interfaces to an interface.
IP Routing 277
Using the nameif interface command, you can assign an interface name to a logical interface.
The syntax for the nameif command is as follows:
nameif interface-name
The interface-name parameter for the nameif command is the name to be assigned to the
specified interface.
Using the security-level interface command, you can assign a security level to a logical
interface. The syntax for the security-level command is as follows:
security-level security-level
The security-level parameter is the security level for the specified interface in the range from
0 to 100, with 0 being the least trusted interface and 100 being the most trusted interface.
Finally, you need to complete your logical interface configuration by assigning an IP address
to the logical interface. To assign an IP address to an interface, you use the ip address
command. The syntax for this command is as follows:
ip address ip-address
After you create your logical interfaces, you also need to assign the following parameters to
each logical interface:
■ Interface name
■ Security level
■ IP address
Table 11-6 interface Command Parameters
Parameter Description
hardware-id Specifies the network interface on which the command will be applied (such
as Ethernet0).
subinterface-num The subinterface identifier that will be assigned for this logical interface,
which can be between 1 and 4,294,967,293.
mapped-name In multiple-context mode, enter the mapped name if it was assigned using the
allocate-interface command.
shutdown Keyword indicating that the interface should be administratively shut down.
NOTE You do not need to assign a VLAN to the physical interface to assign logical
interfaces to an interface.
IP Routing 277
Using the nameif interface command, you can assign an interface name to a logical interface.
The syntax for the nameif command is as follows:
nameif interface-name
The interface-name parameter for the nameif command is the name to be assigned to the
specified interface.
Using the security-level interface command, you can assign a security level to a logical
interface. The syntax for the security-level command is as follows:
security-level security-level
The security-level parameter is the security level for the specified interface in the range from
0 to 100, with 0 being the least trusted interface and 100 being the most trusted interface.
Finally, you need to complete your logical interface configuration by assigning an IP address
to the logical interface. To assign an IP address to an interface, you use the ip address
command. The syntax for this command is as follows:
ip address ip-address
Maximum Interfaces for Unrestricted License
Maximum Interfaces for Unrestricted License
Cisco Secure PIX Model Total Interfaces Physical Interfaces Logical Interfaces
501 2 2 Not supported
506E 2 2 Not supported
515E 10 6 25
525 12 8 100
535 24 10 150
Table 11-4 Maximum Interfaces for ASA Security Appliances Base License
Cisco ASA Security Model Physical Interfaces Logical Interfaces
5510 5 0
5520 5 25
5540 5 100
Table 11-5 Maximum Interfaces for ASA Security Appliances Security Plus
Cisco ASA Security Model Physical Interfaces Logical Interfaces
5510 5 10
5520 5 25
5540 5 100
NOTE The maximum number of logical interfaces that you can use is equal to the total
number of interfaces available minus the total number of physical interfaces that you
currently have configured on your PIX Firewall.
Cisco Secure PIX Model Total Interfaces Physical Interfaces Logical Interfaces
501 2 2 Not supported
506E 2 2 Not supported
515E 10 6 25
525 12 8 100
535 24 10 150
Table 11-4 Maximum Interfaces for ASA Security Appliances Base License
Cisco ASA Security Model Physical Interfaces Logical Interfaces
5510 5 0
5520 5 25
5540 5 100
Table 11-5 Maximum Interfaces for ASA Security Appliances Security Plus
Cisco ASA Security Model Physical Interfaces Logical Interfaces
5510 5 10
5520 5 25
5540 5 100
NOTE The maximum number of logical interfaces that you can use is equal to the total
number of interfaces available minus the total number of physical interfaces that you
currently have configured on your PIX Firewall.
Maximum Interfaces for Restricted License
Maximum Interfaces for Restricted License
Cisco Secure PIX Model Total Interfaces Physical Interfaces Logical Interfaces
515E 5 3 10
525 8 6 25
535 10 8 50
NOTE VLANs are not supported on the PIX 501. The PIX 506/506E support 802.1q
trunking with the introduction of PIX OS 6.3.4
Cisco Secure PIX Model Total Interfaces Physical Interfaces Logical Interfaces
515E 5 3 10
525 8 6 25
535 10 8 50
NOTE VLANs are not supported on the PIX 501. The PIX 506/506E support 802.1q
trunking with the introduction of PIX OS 6.3.4
Understanding Logical Interfaces
Your Security Appliance has a limited number of physical interfaces. This limits the number
of Layer 3 networks to which the Security Appliance can be directly connected. If you use
VLANs to segment your network into smaller broadcast domains, each of these VLANs
represents a different Layer 3 network. By using logical interfaces, you can accommodate
multiple VLANs by using trunk lines on your switch ports and configuring multiple logical
interfaces on a single physical interface on your Security Appliance. Logical interfaces
overcome the physical interface limitation by enabling a single physical interface to handle
multiple logical interfaces.
Table 11-2 shows the maximum number of interfaces allowed using a PIX Firewall restricted
license, while Table 11-3 shows the maximum number of interfaces allowed for a PIX
Firewall unrestricted license.
Table 11-4 shows the maximum number of interfaces allowed using an ASA Security
Appliance base license, while Table 11-5 shows the maximum number of interfaces allowed
for an ASA Security Appliance Security Plus license.
of Layer 3 networks to which the Security Appliance can be directly connected. If you use
VLANs to segment your network into smaller broadcast domains, each of these VLANs
represents a different Layer 3 network. By using logical interfaces, you can accommodate
multiple VLANs by using trunk lines on your switch ports and configuring multiple logical
interfaces on a single physical interface on your Security Appliance. Logical interfaces
overcome the physical interface limitation by enabling a single physical interface to handle
multiple logical interfaces.
Table 11-2 shows the maximum number of interfaces allowed using a PIX Firewall restricted
license, while Table 11-3 shows the maximum number of interfaces allowed for a PIX
Firewall unrestricted license.
Table 11-4 shows the maximum number of interfaces allowed using an ASA Security
Appliance base license, while Table 11-5 shows the maximum number of interfaces allowed
for an ASA Security Appliance Security Plus license.
Understanding Trunk Ports
Understanding Trunk Ports
Usually, you configure a switch as a member of a specific VLAN. This automatically
associates all of the regular Ethernet traffic received on that port with that VLAN.
Sometimes, however, you may want a single port to receive traffic from multiple VLANs.
A switch port that accepts traffic from multiple VLANs is known as a trunk port.
To differentiate between the different VLANs, each packet is tagged with a specific VLAN
identifier. This identifier informs the switch to which VLAN the traffic needs to be forwarded.
By using trunk lines on your switch, your Security Appliance can send and receive traffic
from multiple VLANs using only a single physical interface.
Usually, you configure a switch as a member of a specific VLAN. This automatically
associates all of the regular Ethernet traffic received on that port with that VLAN.
Sometimes, however, you may want a single port to receive traffic from multiple VLANs.
A switch port that accepts traffic from multiple VLANs is known as a trunk port.
To differentiate between the different VLANs, each packet is tagged with a specific VLAN
identifier. This identifier informs the switch to which VLAN the traffic needs to be forwarded.
By using trunk lines on your switch, your Security Appliance can send and receive traffic
from multiple VLANs using only a single physical interface.
Understanding VLANs
Understanding VLANs
At the Ethernet layer, you can partition your network using VLANs. These VLANs limit the
scope of broadcast traffic on your network because each VLAN represents an individual
broadcast domain. By dividing your switched network using VLANs, you improve the
security of your network by limiting the scope of broadcast traffic that is vital for the
operation of your network, such as Address Resolution Protocol (ARP) traffic and Dynamic
Host Configuration Protocol (DHCP) traffic.
At the Ethernet layer, you can partition your network using VLANs. These VLANs limit the
scope of broadcast traffic on your network because each VLAN represents an individual
broadcast domain. By dividing your switched network using VLANs, you improve the
security of your network by limiting the scope of broadcast traffic that is vital for the
operation of your network, such as Address Resolution Protocol (ARP) traffic and Dynamic
Host Configuration Protocol (DHCP) traffic.
Ethernet VLAN Tagging
Ethernet VLAN Tagging
To pass traffic between the different VLANs on your switched network, Ethernet packets can
be tagged with a VLAN identifier that indicates the VLAN to which the traffic belongs.
Ethernet tagging enables you to pass traffic for different VLANs across the same Layer 2
interface. The following sections explain how to use Ethernet VLAN tagging with your Cisco
Security Appliance.
To pass traffic between the different VLANs on your switched network, Ethernet packets can
be tagged with a VLAN identifier that indicates the VLAN to which the traffic belongs.
Ethernet tagging enables you to pass traffic for different VLANs across the same Layer 2
interface. The following sections explain how to use Ethernet VLAN tagging with your Cisco
Security Appliance.
General Routing Principles
General Routing Principles
Although your Cisco Security Appliance is not a router, it does need to provide certain
routing and switching functionality. Whenever your Security Appliance processes valid
traffic, it must determine which interface provides the correct path for the destination
network. It may also have to tag the traffic for the appropriate Virtual LAN (VLAN). Not
only can your Security Appliance route valid traffic, you can also configure it to forward
multicast traffic. Sending multicast traffic to a multicast broadcast address enables multiple
systems to receive a data stream that otherwise would have to be sent to each individual
system.
This chapter focuses on the following three features that enable your Cisco Security
Appliance to effectively route and switch traffic:
■ Ethernet VLAN tagging
■ IP routing
■ Multicast routing
Although your Cisco Security Appliance is not a router, it does need to provide certain
routing and switching functionality. Whenever your Security Appliance processes valid
traffic, it must determine which interface provides the correct path for the destination
network. It may also have to tag the traffic for the appropriate Virtual LAN (VLAN). Not
only can your Security Appliance route valid traffic, you can also configure it to forward
multicast traffic. Sending multicast traffic to a multicast broadcast address enables multiple
systems to receive a data stream that otherwise would have to be sent to each individual
system.
This chapter focuses on the following three features that enable your Cisco Security
Appliance to effectively route and switch traffic:
■ Ethernet VLAN tagging
■ IP routing
■ Multicast routing
Changing Syslog Message Levels
Changing Syslog Message Levels
PIX Firewall version 6.3 gives you the option to modify the level at which a specific syslog
message is issued and to disable specific syslog messages. This feature provides you with more
flexibility because you can specify which message you are logging and at what level. To
change the logging level for all syslog servers, enter the following command syntax:
logging message syslog_id [level levelid]
To change the level of a specific syslog message, enter the following command syntax:
logging message syslog_id level levelid
The variables syslog_id and levelid represent the numeric identifier and severity level assigned
to the syslog message, respectively, as shown in Table 10-2.
PIX Firewall version 6.3 gives you the option to modify the level at which a specific syslog
message is issued and to disable specific syslog messages. This feature provides you with more
flexibility because you can specify which message you are logging and at what level. To
change the logging level for all syslog servers, enter the following command syntax:
logging message syslog_id [level levelid]
To change the level of a specific syslog message, enter the following command syntax:
logging message syslog_id level levelid
The variables syslog_id and levelid represent the numeric identifier and severity level assigned
to the syslog message, respectively, as shown in Table 10-2.
Logging Levels
Logging Levels
Different severity levels are attached to incoming messages. You can think of these levels as
indicating the type of message. A Security Appliance can be configured to send messages at
different levels. Table 10-2 lists these levels from highest to lowest importance.
How Syslog Works 253
Many of the logging commands require that you specify a severity level threshold to indicate
which syslog messages can be sent to the output locations. The lower the level number, the
more severe the syslog message. The default severity level is 3 (error). During configuration,
you can specify the severity level as either a number or a keyword, as described in Table 10-2.
The level you specify causes the Cisco Security Appliance Firewall to send the messages of
that level and below to the output location. For example, if you specify severity level 3
(error), a Security Appliance, such as the PIX, sends severity level 0 (emergency), 1 (alert), 2
(critical), and 3 (error) messages to the output location.
Changing Syslog Message Levels
PIX Firewall version 6.3 gives you the option to modify the level at which a specific syslog
message is issued and to disable specific syslog messages. This feature provides you with more
flexibility because you can specify which message you are logging and at what level. To
change the logging level for all syslog servers, enter the following command syntax:
logging message syslog_id [level levelid]
To change the level of a specific syslog message, enter the following command syntax:
logging message syslog_id level levelid
The variables syslog_id and levelid represent the numeric identifier and severity level assigned
to the syslog message, respectively, as shown in Table 10-2.
Table 10-2 Logging Severity Levels
Level/Keyword Numeric Code System Condition
Emergency 0 System unusable message
Alert 1 Take immediate action
Critical 2 Critical condition
Error 3 Error message
Warning 4 Warning message
Notification 5 Normal but significant condition
Informational 6 Information message
Debug 7 Debug message, log FTP commands, and WWW URLs
Different severity levels are attached to incoming messages. You can think of these levels as
indicating the type of message. A Security Appliance can be configured to send messages at
different levels. Table 10-2 lists these levels from highest to lowest importance.
How Syslog Works 253
Many of the logging commands require that you specify a severity level threshold to indicate
which syslog messages can be sent to the output locations. The lower the level number, the
more severe the syslog message. The default severity level is 3 (error). During configuration,
you can specify the severity level as either a number or a keyword, as described in Table 10-2.
The level you specify causes the Cisco Security Appliance Firewall to send the messages of
that level and below to the output location. For example, if you specify severity level 3
(error), a Security Appliance, such as the PIX, sends severity level 0 (emergency), 1 (alert), 2
(critical), and 3 (error) messages to the output location.
Changing Syslog Message Levels
PIX Firewall version 6.3 gives you the option to modify the level at which a specific syslog
message is issued and to disable specific syslog messages. This feature provides you with more
flexibility because you can specify which message you are logging and at what level. To
change the logging level for all syslog servers, enter the following command syntax:
logging message syslog_id [level levelid]
To change the level of a specific syslog message, enter the following command syntax:
logging message syslog_id level levelid
The variables syslog_id and levelid represent the numeric identifier and severity level assigned
to the syslog message, respectively, as shown in Table 10-2.
Table 10-2 Logging Severity Levels
Level/Keyword Numeric Code System Condition
Emergency 0 System unusable message
Alert 1 Take immediate action
Critical 2 Critical condition
Error 3 Error message
Warning 4 Warning message
Notification 5 Normal but significant condition
Informational 6 Information message
Debug 7 Debug message, log FTP commands, and WWW URLs
Logging Facilities
Logging Facilities
When syslog messages are sent to a server, it is important to indicate through which pipe the
Security Appliance will send the messages. The single syslog service, syslogd, can be thought
of as having multiple pipes. It uses the pipes to decide where to send incoming information
based on the pipe through which the information arrives. Syslogd is a daemon/service that
runs on UNIX machines. In this analogy, the logging facilities are the pipes by which syslogd
decides where to send information it receives—that is, to which file to write.
Eight logging facilities (16 through 23) are commonly used for syslog on the Cisco Security
Appliance. On the syslog server, the facility numbers have a corresponding identification—
local0 to local7. The following are the facility numbers and their corresponding syslog
identification:
■ local0 (16)
■ local1 (17)
■ local2 (18)
■ local3 (19)
■ local4 (20)
■ local5 (21)
■ local6 (22)
■ local7 (23)
The default facility is local4 (20). To change the default logging facility on the Security
Appliance, you use the logging facility facility command. The following command shows the
logging facility changed to 21:
Pix(config)# logging facility 21
When syslog messages are sent to a server, it is important to indicate through which pipe the
Security Appliance will send the messages. The single syslog service, syslogd, can be thought
of as having multiple pipes. It uses the pipes to decide where to send incoming information
based on the pipe through which the information arrives. Syslogd is a daemon/service that
runs on UNIX machines. In this analogy, the logging facilities are the pipes by which syslogd
decides where to send information it receives—that is, to which file to write.
Eight logging facilities (16 through 23) are commonly used for syslog on the Cisco Security
Appliance. On the syslog server, the facility numbers have a corresponding identification—
local0 to local7. The following are the facility numbers and their corresponding syslog
identification:
■ local0 (16)
■ local1 (17)
■ local2 (18)
■ local3 (19)
■ local4 (20)
■ local5 (21)
■ local6 (22)
■ local7 (23)
The default facility is local4 (20). To change the default logging facility on the Security
Appliance, you use the logging facility facility command. The following command shows the
logging facility changed to 21:
Pix(config)# logging facility 21
How Syslog Works
How Syslog Works
The syslog message facility in a Cisco Security Appliance is a useful means to view
troubleshooting messages and to watch for network events such as attacks and denials of
service. The Cisco Security Appliance reports on events and activities using syslog messages,
which report on the following:
■ System status—When the Cisco Security Appliance reboots or a connection by Telnet or
the console is made or disconnected
■ Accounting—The number of bytes transferred per connection
■ Security—Dropped User Datagram Protocol (UDP) packets and denied Transmission
Control Protocol (TCP) connections
■ Resources—Notification of connection and translation slot depletion
It is important to become familiar with the logging process and logging command parameters
on a Security Appliance before you dive in and start configuring the Cisco Security Appliance
for logging. Syslog messages can be sent to several different output destinations on or off the
Security Appliance unit:
■ ASDM logging—Logging messages can be sent to the Adaptive Security Device Manager
(ASDM).
■ Console—Syslog messages can be configured to be sent to the console interface, where
the security administrator (you) can view the messages in real time as they happen when
you are connected to the console interface.
■ Internal memory buffer—Syslog messages can be sent to the buffer.
■ Telnet console—Syslog messages also can be configured to be sent to Telnet sessions.
This configuration helps you remotely administer and troubleshoot Security Appliance
units without being physically present at the location of the firewall.
■ Syslog servers—This type of configuration is particularly useful for storing syslog
messages for analysis on performance, trends, and packet activities on the Security
Appliance unit. Syslog messages are sent to UNIX servers/workstations running a syslog
daemon or to Windows servers running PIX Firewall Syslog Server (PFSS).
■ SNMP management station—Syslog traps can be configured to be sent to an SNMP
management station.
The syslog message facility in a Cisco Security Appliance is a useful means to view
troubleshooting messages and to watch for network events such as attacks and denials of
service. The Cisco Security Appliance reports on events and activities using syslog messages,
which report on the following:
■ System status—When the Cisco Security Appliance reboots or a connection by Telnet or
the console is made or disconnected
■ Accounting—The number of bytes transferred per connection
■ Security—Dropped User Datagram Protocol (UDP) packets and denied Transmission
Control Protocol (TCP) connections
■ Resources—Notification of connection and translation slot depletion
It is important to become familiar with the logging process and logging command parameters
on a Security Appliance before you dive in and start configuring the Cisco Security Appliance
for logging. Syslog messages can be sent to several different output destinations on or off the
Security Appliance unit:
■ ASDM logging—Logging messages can be sent to the Adaptive Security Device Manager
(ASDM).
■ Console—Syslog messages can be configured to be sent to the console interface, where
the security administrator (you) can view the messages in real time as they happen when
you are connected to the console interface.
■ Internal memory buffer—Syslog messages can be sent to the buffer.
■ Telnet console—Syslog messages also can be configured to be sent to Telnet sessions.
This configuration helps you remotely administer and troubleshoot Security Appliance
units without being physically present at the location of the firewall.
■ Syslog servers—This type of configuration is particularly useful for storing syslog
messages for analysis on performance, trends, and packet activities on the Security
Appliance unit. Syslog messages are sent to UNIX servers/workstations running a syslog
daemon or to Windows servers running PIX Firewall Syslog Server (PFSS).
■ SNMP management station—Syslog traps can be configured to be sent to an SNMP
management station.
Managing Security Contexts
Managing Security Contexts
Security contexts can be accessed on two levels. A security administrator can log into the
admin context or system execution space. This will allow the security administrator access
to the configuration of all configured contexts, as well as the ability to create new contexts.
Additionally, users can be set up as security administrators for specific contexts. When users
logs into the Security Appliance, they will be able to see only the security context to which
they have been assigned. Within that context, they can change the configuration file
information and can monitor the context.
Security contexts can be accessed on two levels. A security administrator can log into the
admin context or system execution space. This will allow the security administrator access
to the configuration of all configured contexts, as well as the ability to create new contexts.
Additionally, users can be set up as security administrators for specific contexts. When users
logs into the Security Appliance, they will be able to see only the security context to which
they have been assigned. Within that context, they can change the configuration file
information and can monitor the context.
Uploading a Configuration Using the config-url Command
Uploading a Configuration Using the config-url Command
To enable a security context, you must specify a configuration file. The config-url command
is used in context-configuration mode to specify where to find the configuration file for the
context:
config-url url
The url argument assigns the context configuration URL. All remote URLs must be accessible
from the admin context:
■ disk0:/[path/]filename—This option is only available for the ASA platform and indicates
the Flash memory DIMM.
■ disk1:/[path/]filename—This option is only available for the ASA platform and indicates
the Flash memory card.
■ flash:/[path/]—This option indicates the Flash memory DIMM.
■ http[s]://[user[:password]@]server[:port]/[path/]filename — This option indicates the
HTTP or HTTPS server from which to download.
■ tftp://[user[:password]@]server[:port]/[path/]filename—This option indicates the TFTP
server from which to download.
■ ftp://[user[:password]@]server[:port]/[path/]filename[;type=xx]—This option indicates
the FTP server from which to download.
type can be one of the following:
— Ap—ASCII passive mode
— An—ASCII normal mode
— Ip—(Default) Binary passive mode
— In—Binary normal mode
The configuration file can be stored in several locations:
■ Disk0/flash—Security Appliance’s Flash filesystem
■ disk1—Security Appliance’s compact Flash
■ tftp—TFTP server
■ ftp—FTP server
■ http(s)—WebServer (read only)
The admin context must reside on the local Flash memory DIMM. Configuring a config-url
on a context will cause the context to immediately attempt to retrieve the configuration file.
Make sure all interfaces have been allocated to a context with mapped names before the
config-url command is executed. If a config-url has been configured on a security context
before any interfaces for that context have been assigned mapped names, the newly acquired
context configuration may fail commands referencing the missing interfaces. If the context
cannot retrieve the requested context configuration, the system will create an empty context
configuration file that can be manually configured from the Security Appliance commandline
interface (CLI).
After a context configuration file
has been assigned and loaded into the context, a security
administrator might need to move the remote configuration file to a different location.
Changing the config-url to take the move into consideration can be done by reentering the
234 Chapter 9: Security Contexts
config-url command. By reentering the config-url, the context will immediately attempt to
download the new configuration file and merge it with the current running configuration for
that context. The merge will only add new configurations to the running configuration. To
avoid this, a security administrator can clear the running configuration, though doing so will
disrupt any communications through the context until the new configuration file is acquired.
To enable a security context, you must specify a configuration file. The config-url command
is used in context-configuration mode to specify where to find the configuration file for the
context:
config-url url
The url argument assigns the context configuration URL. All remote URLs must be accessible
from the admin context:
■ disk0:/[path/]filename—This option is only available for the ASA platform and indicates
the Flash memory DIMM.
■ disk1:/[path/]filename—This option is only available for the ASA platform and indicates
the Flash memory card.
■ flash:/[path/]—This option indicates the Flash memory DIMM.
■ http[s]://[user[:password]@]server[:port]/[path/]filename — This option indicates the
HTTP or HTTPS server from which to download.
■ tftp://[user[:password]@]server[:port]/[path/]filename—This option indicates the TFTP
server from which to download.
■ ftp://[user[:password]@]server[:port]/[path/]filename[;type=xx]—This option indicates
the FTP server from which to download.
type can be one of the following:
— Ap—ASCII passive mode
— An—ASCII normal mode
— Ip—(Default) Binary passive mode
— In—Binary normal mode
The configuration file can be stored in several locations:
■ Disk0/flash—Security Appliance’s Flash filesystem
■ disk1—Security Appliance’s compact Flash
■ tftp—TFTP server
■ ftp—FTP server
■ http(s)—WebServer (read only)
The admin context must reside on the local Flash memory DIMM. Configuring a config-url
on a context will cause the context to immediately attempt to retrieve the configuration file.
Make sure all interfaces have been allocated to a context with mapped names before the
config-url command is executed. If a config-url has been configured on a security context
before any interfaces for that context have been assigned mapped names, the newly acquired
context configuration may fail commands referencing the missing interfaces. If the context
cannot retrieve the requested context configuration, the system will create an empty context
configuration file that can be manually configured from the Security Appliance commandline
interface (CLI).
After a context configuration file
has been assigned and loaded into the context, a security
administrator might need to move the remote configuration file to a different location.
Changing the config-url to take the move into consideration can be done by reentering the
234 Chapter 9: Security Contexts
config-url command. By reentering the config-url, the context will immediately attempt to
download the new configuration file and merge it with the current running configuration for
that context. The merge will only add new configurations to the running configuration. To
avoid this, a security administrator can clear the running configuration, though doing so will
disrupt any communications through the context until the new configuration file is acquired.
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.
Subscribe to:
Posts (Atom)