Applying Application Layer Protocol Inspection

CH A P T E R
21
Applying Application Layer Protocol Inspection
This chapter describes how to configure application layer protocol inspection. Inspection engines are
required for services that embed IP addressing information in the user data packet or that open secondary
channels on dynamically assigned ports. These protocols require the FWSM to perform a deep packet
inspection instead of passing the packet through the accelerated path (see the “Stateful Inspection
Overview” section on page 1-9 for more information about the accelerated path). As a result, inspection
engines can affect overall throughput.
Several common inspection engines are enabled on the FWSM by default, but you might need to enable
others depending on your network. This chapter includes the following sections:
•
Inspection Engine Overview, page 21-2
•
Configuring Application Inspection, page 21-6
•
CTIQBE Inspection, page 21-10
•
DCERPC Inspection, page 21-16
•
DNS Inspection, page 21-17
•
ESMTP Inspection, page 21-26
•
FTP Inspection, page 21-30
•
GTP Inspection, page 21-35
•
H.323 Inspection, page 21-47
•
HTTP Inspection, page 21-60
•
ICMP Inspection, page 21-64
•
ILS Inspection, page 21-64
•
MGCP Inspection, page 21-65
•
NetBIOS Inspection, page 21-72
•
PPTP Inspection, page 21-73
•
RSH Inspection, page 21-73
•
RTSP Inspection, page 21-73
•
SIP Inspection, page 21-76
•
Skinny (SCCP) Inspection, page 21-89
•
SMTP and Extended SMTP Inspection, page 21-94
•
SNMP Inspection, page 21-97
•
SQL*Net Inspection, page 21-99
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-1
Chapter 21
Applying Application Layer Protocol Inspection
Inspection Engine Overview
•
Sun RPC Inspection, page 21-99
•
TFTP Inspection, page 21-104
•
XDMCP Inspection, page 21-104
Inspection Engine Overview
This section includes the following topics:
•
When to Use Application Protocol Inspection, page 21-2
•
Inspection Limitations, page 21-3
•
Default Inspection Policy, page 21-4
When to Use Application Protocol Inspection
When a user establishes a connection, the FWSM checks the packet against access lists, creates an
address translation, and creates an entry for the session in the accelerated path, so that further packets
can bypass time-consuming checks. However, the accelerated path relies on predictable port numbers
and does not perform address translations inside a packet.
Many protocols open secondary TCP or UDP ports. The initial session on a well-known port is used to
negotiate dynamically-assigned port numbers.
Other applications embed an IP address in the packet that needs to match the source address that is
normally translated when it goes through the FWSM.
If you use applications like these, then you need to enable application inspection.
When you enable application inspection for a service that embeds IP addresses, the FWSM translates
embedded addresses and updates any checksum or other fields that are affected by the translation.
When you enable application inspection for a service that uses dynamically assigned ports, the FWSM
monitors sessions to identify the dynamic port assignments, and permits data exchange on these ports
for the duration of the specific session.
How Inspection Engines Work
As illustrated in Figure 21-2, the FWSM uses three databases for its basic operation:
•
Access lists—Used for authentication and authorization of connections based on specific networks,
hosts, and services (TCP/UDP port numbers).
•
Inspections—Contains a static, predefined set of application-level inspection functions.
•
Connections (XLATE and CONN tables)—Maintains state and other information about each
established connection. This information is used by the Adaptive Security Algorithm and
cut-through proxy to efficiently forward traffic within established sessions.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-2
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
Inspection Engine Overview
Figure 21-1
How Inspection Engines Work
ACL
2
Client
FWSM
6
7
5
3
XLATE
CONN
Server
4
Inspection
132875
1
In Figure 21-2, operations are numbered in the order they occur, and are described as follows:
1.
A TCP SYN packet arrives at the FWSM to establish a new connection.
2.
The FWSM checks the access list database to determine if the connection is permitted.
3.
The FWSM creates a new entry in the connection database (XLATE and CONN tables).
4.
The FWSM checks the Inspections database to determine if the connection requires
application-level inspection.
5.
After the application inspection engine completes any required operations for the packet, the FWSM
forwards the packet to the destination system.
6.
The destination system responds to the initial request.
7.
The FWSM receives the reply packet, looks up the connection in the connection database, and
forwards the packet because it belongs to an established session.
The default configuration of the FWSM includes a set of application inspection entries that associate
supported protocols with specific TCP or UDP port numbers and that identify any special handling
required.
Inspection Limitations
See the following limitations for application protocol inspection:
•
State information for multimedia sessions that require inspection are not passed over the state link
for stateful failover. The exception is GTP, which is replicated over the state link.
•
Some inspection engines do not support PAT, NAT, outside NAT, or NAT between same security
interfaces. See “Default Inspection Policy” for more information about NAT support.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-3
Chapter 21
Applying Application Layer Protocol Inspection
Inspection Engine Overview
•
If you configure PAT for traffic that is being inspected, the FWSM performs application inspection
on the translated port numbers rather than the real port numbers.
Service policies applying inspection to traffic with translated port numbers should use class maps
that identify traffic using the translated port numbers. For example, if you implement PAT to
translate ports 2727 and 2427 to port 1400, you should configure MGCP inspection to match traffic
sent to port 1400 rather than the well known ports 2427 and 2727.
•
When application inspection is enabled on the FWSM for TCP flows (especially for application
inspection of protocols like VoIP), the TCP sender segments the TCP packets based on the maximum
segment size (MSS) advertised by the TCP receiver. The FWSM reassembles the TCP segments,
performs the inspection, and transmits the packets to the TCP receiver based on its interface
maximum transmission unit (MTU) and not the MSS advertised by the TCP receiver.
For example, two SIP endpoints (Polycomm video conferencing units) advertise an MSS of 536
bytes. The FWSM proxies this connection and one video unit sends a H.245 setup message that is
761 bytes segmented into three packets. The FWSM reassembles these three segments and transmits
them to the endpoint as one single 761 data byte packet instead of honoring the 536 byte MSS and
resegmenting the message as appropriate.
To account for this limitation, you must perform the following actions on the FWSM:
– Increase the MSS on the TCP receiver.
– Lower the MTU on the FWSM interface.
– Only if possible, disable the advanced protocol inspection.
•
When application inspection is enabled for a protocol and another application utilizes the same port
as that inspected application protocol, the FWSM can exhibit unpredictable behavior (including
packet loss) when inspecting that application protocol. When this situation occurs, you should
disable the inspection engine for that application protocol.
Default Inspection Policy
By default, the configuration includes a policy that matches all default application inspection traffic and
applies inspection to the traffic on all interfaces (a global policy). Default application inspection traffic
includes traffic to the default ports for each protocol. You can only apply one global policy, so if you
want to alter the global policy, for example, to apply inspection to non-standard ports, or to add
inspections that are not enabled by default, you need to either edit the default policy or disable it and
apply a new one.
Table 21-1 lists all inspections supported, the default ports used in the default class map, and the
inspection engines that are on by default, shown in bold. This table also notes any NAT limitations.
Table 21-1
Supported Application Inspection Engines
Application1
Default Port NAT Limitations
Standards2
Comments
CTIQBE
TCP/2748
—
—
—
DCERPC
TCP/135
—
—
Supports the map and lookup operations
of the EPM for clients.
DNS over UDP
UDP/53
Only forward NAT.
RFC 1123
No PTR records are changed.
No NAT support is available for
name resolution through
WINS.
Default maximum packet length is 512
bytes.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-4
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
Inspection Engine Overview
Table 21-1
Supported Application Inspection Engines (continued)
Application1
Default Port NAT Limitations
Standards2
Comments
ESMTP
TCP/25
—
RFC 821, 1123
—
FTP
TCP/21
—
RFC 959
Default FTP inspection does not
enforce compliance with RFC
standards. To do so, configure the
inspect ftp command with the strict
keyword.
GTP
UDP/3386
(V0)
UDP/2123
(V1)
No NAT or PAT.
—
Requires a special license.
H.323
No NAT on same security
TCP/1720
UDP/1718 interfaces.
UDP (RAS)
No static PAT.
1718-1719
ITU-T H.323,
H.245, H225.0,
Q.931, Q.932
By default, both RAS and H.225
inspection are enabled.
HTTP
TCP/80
—
RFC 2616
Beware of MTU limitations stripping
ActiveX and Java. If the MTU is too
small to allow the Java or ActiveX tag to
be included in one packet, stripping
may not occur.
ICMP
—
—
—
All ICMP traffic is matched in the
default class map.
ICMP ERROR
—
—
—
All ICMP traffic is matched in the
default class map.
ILS (LDAP)
TCP/389
No PAT.
—
—
MGCP
UDP/2427,
2727
—
RFC 2705bis-05
—
NetBIOS
Datagram
Service / UDP
UDP/138
—
—
NetBIOS Name
Service / UDP
UDP/137
—
No WINS support.
PPTP
TCP/1723
—
RFC 2637
—
RSH
TCP/514
No PAT
Berkeley UNIX
—
RTSP
TCP/554
No outside NAT.
RFC 2326, 2327, No handling for HTTP cloaking.
1889
SIP
TCP/5060
UDP/5060
No outside NAT.
RFC 3261
—
SKINNY
(SCCP)
TCP/2000
No outside NAT.
—
Does not handle TFTP uploaded Cisco
IP Phone configurations under certain
circumstances.
SMTP
TCP/25
RFC 821, 1123
—
No NAT
No PAT
No NAT on same security
interfaces.
No NAT on same security
interfaces.
—
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-5
Chapter 21
Applying Application Layer Protocol Inspection
Configuring Application Inspection
Table 21-1
Supported Application Inspection Engines (continued)
Application1
Default Port NAT Limitations
Standards2
SNMP
UDP/161,
162
No NAT or PAT.
RFC 1155, 1157, v.2 RFC 1902-1908; v.3 RFC
1212, 1213, 1215 2570-2580.
SQL*Net
TCP/1521
—
—
v.1 and v.2.
SunRPC
UDP/111
TCP/111
No PAT.
—
The default class map includes UDP
port 111; if you want to enable Sun RPC
inspection for TCP port 111, you need
to create a new class map that matches
TCP port 111, add the class to the
policy, and then apply the inspect
sunrpc command to that class.
TFTP
TCP/69
UDP/69
Payload not NATed.
RFC 1530
—
WAAS
TCP
—
—
Enables the TCP option 33 parsing.
XDCMP
UDP/177
No NAT or PAT.
—
—
Payload not NATed.
Comments
1. Inspection engines that are enabled by default for the default port are in bold.
2. The FWSM is in compliance with these standards, but it does not enforce compliance on packets being inspected. For example, FTP commands are
supposed to be in a particular order, but the FWSM does not enforce the order.
The default policy configuration includes the following commands:
class-map inspection_default
match default-inspection-traffic
policy-map global_policy
class inspection_default
inspect dns maximum-length 512
inspect ftp
inspect h323 h225
inspect h323 ras
inspect netbios
inspect rsh
inspect skinny
inspect sqlnet
inspect sunrpc
inspect tftp
inspect sip
inspect xdmcp
service-policy global_policy global
Configuring Application Inspection
This feature uses Modular Policy Framework, so that implementing application inspection consists of
the following:
1.
Identifying traffic.
2.
Applying inspections to the traffic.
For some applications, you can perform special actions when you enable inspection.
3.
Activating inspections on an interface.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-6
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
Configuring Application Inspection
See Chapter 19, “Using Modular Policy Framework,” for more information about Modular Policy
Framework.
Inspection is enabled by default for some applications. See the “Default Inspection Policy” section on
page 21-4 section for more information. Use this section to modify your inspection policy.
To configure application inspection, perform the following steps:
Step 1
To identify the traffic to which you want to apply inspections, add a Layer 3/4 class map. See the
“Identifying Traffic (Layer 3/4 Class Map)” section on page 19-4 for detailed information.
The default Layer 3/4 class map for through traffic is called “inspection_default.” It matches traffic using
a special match command, match default-inspection-traffic, to match the default ports for each
application protocol.
You can specify a match access-list command along with the match default-inspection-traffic
command to narrow the matched traffic to specific IP addresses. Because the match
default-inspection-traffic command specifies the ports to match, any ports in the access list are ignored.
If you want to match non-standard ports, then you need to create a new class map for the non-standard
ports. See the “Default Inspection Policy” section on page 21-4 for the standard ports for each inspection
engine. You can combine multiple class maps in the same policy if desired, so you can create one class
map to match certain traffic, and another to match different traffic. However, if traffic matches a class
map that contains an inspection command, and then matches another class map that also has an
inspection command, only the first matching class is used. For example, SNMP matches the
inspection_default class. To enable SNMP inspection, enable SNMP inspection for the default class in
Step 5. Do not add another class that matches SNMP.
For example, to limit inspection to traffic from 10.1.1.0 to 192.168.1.0 using the default class map, enter
the following commands:
hostname(config)# access-list inspect extended permit ip 10.1.1.0 255.255.255.0
192.168.1.0 255.255.255.0
hostname(config)# class-map inspection_default
hostname(config-cmap)# match access-list inspect
View the entire class map using the following command:
hostname(config-cmap)# show running-config class-map inspection_default
!
class-map inspection_default
match default-inspection-traffic
match access-list inspect
!
To inspect FTP traffic on port 21 as well as 1056 (a non-standard port), create an access list that specifies
the ports, and assign it to a new class map:
hostname(config)# access-list ftp_inspect extended permit tcp any any eq 21
hostname(config)# access-list ftp_inspect extended permit tcp any any eq 1056
hostname(config)# class-map new_inspection
hostname(config-cmap)# match access-list ftp_inspect
Step 2
(Optional) Some inspection engines let you control additional parameters when you apply the inspection
to the traffic. See the following sections to configure either an inspection policy map or an application
map for your application. Both inspection policy maps and application maps let you customize the
inspection engine. Inspection policy maps use Modular Policy Framework commands like policy-map
type inspect, and others. Application maps use commands in the form protocol-map.
•
DCERPC—See the “Configuring a DCERPC Inspection Policy Map for Additional Inspection
Control” section on page 21-16.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-7
Chapter 21
Applying Application Layer Protocol Inspection
Configuring Application Inspection
Step 3
•
ESMTP—See the “Configuring an ESMTP Inspection Policy Map for Additional Inspection
Control” section on page 21-26.
•
FTP—See the “The request-command deny Command” section on page 21-31.
•
GTP—See the “GTP Maps and Commands” section on page 21-36.
•
H.323—See the “H.225 Map Commands” section on page 21-50.
•
HTTP—See the “Configuring an HTTP Inspection Policy Map for Additional Inspection Control”
section on page 21-60.
•
MGCP—See the “Configuring and Enabling MGCP Inspection” section on page 21-67.
•
SIP—See the “Configuring a SIP Inspection Policy Map for Additional Inspection Control” section
on page 21-78.
•
SNMP—See the “Enabling and Configuring SNMP Application Inspection” section on page 21-98.
To add or edit a Layer 3/4 policy map that sets the actions to take with the class map traffic, enter the
following command:
hostname(config)# policy-map name
hostname(config-pmap)#
The default policy map is called “global_policy.” This policy map includes the default inspections listed
in the “Default Inspection Policy” section on page 21-4. If you want to modify the default policy (for
example, to add or delete an inspection, or to identify an additional class map for your actions), then
enter global_policy as the name.
Step 4
To identify the class map from Step 1 to which you want to assign an action, enter the following
command:
hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)#
If you are editing the default policy map, it includes the inspection_default class map. You can edit the
actions for this class by entering inspection_default as the name. To add an additional class map to this
policy map, identify a different name. You can combine multiple class maps in the same policy if desired,
so you can create one class map to match certain traffic, and another to match different traffic. However,
if traffic matches a class map that contains an inspection command, and then matches another class map
that also has an inspection command, only the first matching class is used. For example, SNMP matches
the inspection_default class map.To enable SNMP inspection, enable SNMP inspection for the default
class in Step 5. Do not add another class that matches SNMP.
Step 5
Enable application inspection by entering the following command:
hostname(config-pmap-c)# inspect protocol
Table 21-2 lists the protocol values.
Table 21-2
Protocol Keywords
Keywords
Notes
ctiqbe
—
dcerpc [policy_map_name]
If you added a DCERPC inspection policy map according to
“Configuring a DCERPC Inspection Policy Map for
Additional Inspection Control” section on page 21-16,
identify the map name in this command.
dns [map_name]
—
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-8
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
Configuring Application Inspection
Table 21-2
Protocol Keywords (continued)
Keywords
Notes
esmtp [policy_map_name]
If you added an ESMTP inspection policy map according to
“Configuring an ESMTP Inspection Policy Map for
Additional Inspection Control” section on page 21-26,
identify the map name in this command.
ftp [strict [map_name]]
Use the strict keyword to increase the security of protected
networks by preventing web browsers from sending
embedded commands in FTP requests. See the “Using the
strict Option” section on page 21-30 for more information.
If you added an FTP application map according to “The
request-command deny Command” section on page 21-31,
identify the map name in this command.
gtp [map_name]
If you added a GTP application map according to the “GTP
Maps and Commands” section on page 21-36, identify the
map name in this command.
h323 h225 [map_name]
If you added an H.225 application map according to “H.225
Map Commands” section on page 21-50, identify the map
name in this command.
h323 ras [map_name]
—
http [policy_map_name]
If you added an HTTP inspection policy map according to
the “Configuring an HTTP Inspection Policy Map for
Additional Inspection Control” section on page 21-60,
identify the map name in this command.
icmp
—
icmp error
—
ils
—
mgcp [map_name]
If you added an MGCP inspection policy map according to
“Configuring and Enabling MGCP Inspection” section on
page 21-67, identify the map name in this command.
netbios
—
pptp
—
rsh
—
rtsp
—
sip [policy_map_name]
If you added a SIP inspection policy map according to
“Configuring a SIP Inspection Policy Map for Additional
Inspection Control” section on page 21-78, identify the map
name in this command.
skinny
—
snmp [map_name]
If you added an SNMP application map according to
“Enabling and Configuring SNMP Application Inspection”
section on page 21-98, identify the map name in this
command.
sqlnet
—
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-9
Chapter 21
Applying Application Layer Protocol Inspection
CTIQBE Inspection
Step 6
Table 21-2
Protocol Keywords (continued)
Keywords
Notes
sunrpc
The default class map includes UDP port 111; if you want to
enable Sun RPC inspection for TCP port 111, you need to
create a new class map that matches TCP port 111, add the
class to the policy, and then apply the inspect sunrpc
command to that class.
tftp
—
waas
—
xdmcp
—
To activate the policy map on one or more interfaces, enter the following command:
hostname(config)# service-policy policymap_name {global | interface interface_name}
Where global applies the policy map to all interfaces, and interface applies the policy to one interface.
By default, the default policy map, “global_policy,” is applied globally. Only one global policy is
allowed. You can override the global policy on an interface by applying a service policy to that interface.
You can only apply one policy map to each interface.
CTIQBE Inspection
This section describes how to enable CTIQBE application inspection and change the default port
configuration. This section includes the following topics:
•
CTIQBE Inspection Overview, page 21-10
•
Limitations and Restrictions, page 21-10
•
Enabling and Configuring CTIQBE Inspection, page 21-11
•
Verifying and Monitoring CTIQBE Inspection, page 21-12
•
CTIQBE Sample Configurations, page 21-13
CTIQBE Inspection Overview
The inspect ctiqbe command enables CTIQBE protocol inspection, which supports NAT, PAT, and
bidirectional NAT. This enables Cisco IP SoftPhone and other Cisco TAPI/JTAPI applications to work
successfully with Cisco CallManager for call setup across the FWSM.
TAPI and JTAPI are used by many Cisco VoIP applications. CTIQBE is used by Cisco TSP to
communicate with Cisco CallManager.
Limitations and Restrictions
The following summarizes limitations that apply when using CTIQBE application inspection:
•
CTIQBE application inspection does not support configurations with the alias command.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-10
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
CTIQBE Inspection
•
Stateful Failover of CTIQBE calls is not supported.
•
Entering the debug ctiqbe command may delay message transmission, which may have a
performance impact in a real-time environment. When you enable this debugging or logging and
Cisco IP SoftPhone seems unable to complete call setup through the FWSM, increase the timeout
values in the Cisco TSP settings on the system running Cisco IP SoftPhone.
The following summarizes special considerations when using CTIQBE application inspection in specific
scenarios:
•
If two Cisco IP SoftPhones are registered with different Cisco CallManagers, which are connected
to different interfaces of the FWSM, calls between these two phones fails.
•
When Cisco CallManager is located on the higher security interface compared to
Cisco IP SoftPhones, if NAT or outside NAT is required for the Cisco CallManager IP address, the
mapping must be static as Cisco IP SoftPhone requires the Cisco CallManager IP address to be
specified explicitly in its Cisco TSP configuration on the PC.
•
When using PAT or Outside PAT, if the Cisco CallManager IP address is to be translated, its TCP
port 2748 must be statically mapped to the same port of the PAT (interface) address for Cisco IP
SoftPhone registrations to succeed. The CTIQBE listening port (TCP 2748) is fixed and is not
user-configurable on Cisco CallManager, Cisco IP SoftPhone, or Cisco TSP.
Enabling and Configuring CTIQBE Inspection
To enable CTIQBE inspection or change the default port used for receiving CTIQBE traffic, perform the
following steps:
Step 1
Create a class map or modify an existing class map to identify CTIQBE traffic. Use the class-map
command to do so, as follows.
hostname(config)# class-map class_map_name
hostname(config-cmap)#
where class_map_name is the name of the traffic class. When you enter the class-map command, the
CLI enters class map configuration mode.
Step 2
Use the match port command to identify CTIQBE traffic, as follows:
hostname(config-cmap)# match port tcp eq 2748
Step 3
Create a policy map or modify an existing policy map that you want to use to apply the CTIQBE
inspection engine to FTP traffic. To do so, use the policy-map command, as follows.
hostname(config-cmap)# policy-map policy_map_name
hostname(config-pmap)#
where policy_map_name is the name of the policy map. The CLI enters the policy map configuration
mode and the prompt changes accordingly.
Step 4
Specify the class map, created in Step 1, that identifies the CTIQBE traffic. Use the class command to
do so, as follows.
hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)#
where class_map_name is the name of the class map you created in Step 1. The CLI enters the policy
map class configuration mode and the prompt changes accordingly.
Step 5
Enable CTIQBE application inspection.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-11
Chapter 21
Applying Application Layer Protocol Inspection
CTIQBE Inspection
hostname(config-pmap-c)# inspect ctiqbe
Step 6
Use the service-policy command to apply the policy map globally or to a specific interface, as follows:
hostname(config-pmap-c)# service-policy policy_map_name [global | interface interface_ID]
hostname(config)#
where policy_map_name is the policy map you configured in Step 3. If you want to apply the policy map
to traffic on all the interfaces, use the global option. If you want to apply the policy map to traffic on a
specific interface, use the interface interface_ID option, where interface_ID is the name assigned to the
interface with the nameif command.
The FWSM begins inspecting CTIQBE traffic, as specified.
Example 21-1 Enabling and Configuring CTIQBE Inspection
The following example creates a class map to match CTIQBE traffic on the default port (2748) and
enables CTIQBE inspection in the policy using the class matching CTIQBE traffic. The service policy
is then applied to the outside interface.
hostname(config)# class-map ctiqbe_port
hostname(config-cmap)# match port tcp eq 2748
hostname(config-cmap)# policy-map sample_policy
hostname(config-pmap)# class ctiqbe_port
hostname(config-pmap-c)# inspect ctiqbe
hostname(config-pmap-c)# service-policy sample_policy interface outside
hostname(config)#
Verifying and Monitoring CTIQBE Inspection
The show ctiqbe command displays information regarding the CTIQBE sessions established across the
FWSM. It shows information about the media connections allocated by the CTIQBE inspection engine.
The following is sample output from the show ctiqbe command under the following conditions. There
is only one active CTIQBE session setup across the FWSM. It is established between an internal CTI
device (for example, a Cisco IP SoftPhone) at local address 10.0.0.99 and an external Cisco CallManager
at 209.165.201.2, where TCP port 2748 is the Cisco CallManager. The heartbeat interval for the session
is 120 seconds.
hostname# # show ctiqbe
Total: 1
LOCAL
FOREIGN
STATE
HEARTBEAT
--------------------------------------------------------------1
10.0.0.99/1117 209.165.201.2/2748
1
120
---------------------------------------------RTP/RTCP: PAT xlates: mapped to 209.165.201.2(1028 - 1029)
---------------------------------------------MEDIA: Device ID 27
Call ID 0
Foreign 209.165.201.2
(1028 - 1029)
Local
209.165.201.3
(26822 - 26823)
----------------------------------------------
The CTI device has already registered with the CallManager. The device internal address and RTP
listening port is PATed to 209.165.201.2 UDP port 1028. Its RTCP listening port is PATed to UDP 1029.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-12
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
CTIQBE Inspection
The line beginning with RTP/RTCP: PAT xlates: appears only if an internal CTI device has registered
with an external CallManager and the CTI device address and ports are PATed to that external interface.
This line does not appear if the CallManager is located on an internal interface, or if the internal CTI
device address and ports are NATed to the same external interface that is used by the CallManager.
The output indicates a call has been established between this CTI device and another phone at
209.165.201.3. The RTP and RTCP listening ports of the other phone are UDP 26822 and 26823. The
other phone locates on the same interface as the CallManager because the FWSM does not maintain a
CTIQBE session record associated with the second phone and CallManager. The active call leg on the
CTI device side can be identified with Device ID 27 and Call ID 0.
The following is sample output from the show xlate debug command for these CTIBQE connections:
hostname# show xlate debug
3 in use, 3 most used
Flags: D - DNS, d - dump, I - identity, i - inside, n - no random,
r - portmap, s - static
TCP PAT from inside:10.0.0.99/1117 to outside:209.165.201.2/1025 flags ri idle 0:00:22
timeout 0:00:30
UDP PAT from inside:10.0.0.99/16908 to outside:209.165.201.2/1028 flags ri idle 0:00:00
timeout 0:04:10
UDP PAT from inside:10.0.0.99/16909 to outside:209.165.201.2/1029 flags ri idle 0:00:23
timeout 0:04:10
The show conn state ctiqbe command displays the status of CTIQBE connections. In the output, the
media connections allocated by the CTIQBE inspection engine are denoted by a ‘C’ flag. The following
is sample output from the show conn state ctiqbe command.
hostname# show conn state ctiqbe
1 in use, 10 most used
hostname# show conn state ctiqbe detail
1 in use, 10 most used
Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,
B - initial SYN from outside, C - CTIQBE media, D - DNS, d - dump,
E - outside back connection, F - outside FIN, f - inside FIN,
G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,
i - incomplete, J - GTP, j - GTP data, k - Skinny media,
M - SMTP data, m - SIP media, O - outbound data, P - inside back connection,
q - SQL*Net data, R - outside acknowledged FIN,
R - UDP RPC, r - inside acknowledged FIN, S - awaiting inside SYN,
s - awaiting outside SYN, T - SIP, t - SIP transient, U - up
CTIQBE Sample Configurations
The following figure shows a sample configuration for a single transparent firewall for Cisco IP
SoftPhone (Figure 21-2).
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-13
Chapter 21
Applying Application Layer Protocol Inspection
CTIQBE Inspection
Figure 21-2
Single Transparent Firewall for Cisco IP SoftPhone (Virtual Conference)
Single transparent with CTIQBE inspection
(with collaboration settings set to Virtual Conference Room)
Inside
Firewall
Service Module
(FWSM)
vlan50
PC
10.0.0.21/8
Outside
vlan100
PC
10.0.0.23/8
10.0.0.101/8
CallManager 3.3
191376
M
See the following configuration for this example:
firewall transparent
!
interface Vlan50
nameif inside
bridge-group 1
security-level 100
!
interface Vlan100
nameif outside
bridge-group 1
security-level 0
!
interface BVI1
ip address 10.0.0.30 255.0.0.0
!
access-list voice extended permit tcp any any eq ctiqbe
access-list voice extended permit tcp any any eq 1503
!
access-group voice in interface inside
access-group voice in interface outside
!
policy-map global_policy
class inspection_default
inspect ctiqbe
!
Note
TCP port 1503 must be allowed to pass through the security appliance for virtual conference room
collaboration to work with Cisco IP SoftPhone through the security appliance.
The following figure shows a sample configuration for a single transparent firewall for Cisco IP
SoftPhone with NetMeeting enabled (Figure 21-3). Cisco IP SoftPhone is configured with the
collaboration setting of NetMeeting.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-14
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
CTIQBE Inspection
Figure 21-3
Single Transparent Firewall for Cisco IP SoftPhone (Virtual Conference) with
NetMeeting
Single transparent with CTIQBE inspection
(with collaboration settings set to “NetMeeting”)
Firewall
Service Module
(FWSM)
vlan50
PC (Inside)
10.0.0.23/8
vlan100
PC (Outside)
10.0.0.21/8
10.0.0.101/8
CallManager 3.3
191375
M
See the following configuration for this example:
firewall transparent
!
interface Vlan50
nameif inside
bridge-group 1
security-level 100
!
interface Vlan100
nameif outside
bridge-group 1
security-level 0
!
interface BVI1
ip address 10.0.0.30 255.0.0.0
!
access-list voice extended permit tcp any any eq ctiqbe
access-list voice extended permit tcp any any eq h323
access-list voice extended permit tcp any any eq 1503
!
access-group voice in interface inside
access-group voice in interface outside
!
policy-map global_policy
class inspection_default
inspect ctiqbe
!
Note
To allow successful collaboration and application sharing, TCP ports 1503 and 1720 must be allowed to
pass through.
The following is sample output for the show conn detail command:
hostname# show conn detail
25 in use, 33 most used
Flags: A - awaiting inside ACK to SYN,a - awaiting outside ACK to SYN
B - initial SYN from outsideC - CTIQBE media, D - DNS, d - dump,
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-15
Chapter 21
Applying Application Layer Protocol Inspection
DCERPC Inspection
E - outside back connection, F - outside FIN, f - inside FIN,
G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,
i - incomplete, J - GTP, j - GTP data, k - Skinny media,
M - SMTP data, m - SIP media, O - outbound data, P - inside back connection,
q - SQL*Net data, R - outside acknowledged FIN,
R - UDP SUNRPC, r - inside acknowledged FIN, S - awaiting inside SYN,
s - awaiting outside SYN, T - SIP, t - SIP transient, U - up
Network Processor 1 connection
TCP out 10.0.0.101:2748 in 10.0.0.23:3598 idle 0:00:09 Bytes 103065 FLAGS - UOI
UDP out 10.0.0.21:30504 in 10.0.0.23:3650 idle 0:00:00 Bytes 4810406
FLAGS - C
UDP out 10.0.0.21:1436 in 10.0.0.23:19972 idle 0:00:00 Bytes 4813240
FLAGS - C
TCP out 10.0.0.21:1437 in 10.0.0.23:1720 idle 0:07:04 Bytes 1027 FLAGS - UBOIh
UDP out 10.0.0.21:49608 in 10.0.0.23:49608 idle 0:00:10 Bytes 241836
FLAGS - H
UDP out 10.0.0.21:49609 in 10.0.0.23:49609 idle 0:00:01 Bytes 17480
FLAGS - H
TCP out 10.0.0.21:1440 in 10.0.0.23:1503 idle 0:06:58 Bytes 4488 FLAGS - UBOI
TCP out 10.0.0.21:1441 in 10.0.0.23:1503 idle 0:04:50 Bytes 17888 FLAGS - UBOI
TCP out 10.0.0.21:1442 in 10.0.0.23:1503 idle 0:04:50 Bytes 471135 FLAGS - UBOI
Network Processor 2 connections
Multicast sessions:
Network Processor 1 connections
Network Processor 2 connections
IPv6 connections:
DCERPC Inspection
DCERPC is a protocol widely used by Microsoft distributed client and server applications that allows
software clients to execute programs on a server remotely.
This typically involves a client querying a server called the Endpoint Mapper listening on a well known
port number for the dynamically allocated network information of a required service. The client then sets
up a secondary connection to the server instance providing the service. The security appliance allows the
appropriate port number and network address and also applies NAT, if needed, for the secondary
connection.
DCERPC inspect maps inspect for native TCP communication between the EPM and client on well
known TCP port 135. Map and lookup operations of the EPM are supported for clients. Client and server
can be located in any security zone. The embedded server IP address and Port number are received from
the applicable EPM response messages. Because a client may attempt multiple connections to the server
port returned by EPM, multiple use of pinholes are allowed, which have user configurable timeouts.
Configuring a DCERPC Inspection Policy Map for Additional Inspection Control
To specify additional DCERPC inspection parameters, create a DCERPC inspection policy map. You can
then apply the inspection policy map when you enable DCERPC inspection according to the
“Configuring Application Inspection” section on page 21-6.
To create a DCERPC inspection policy map, perform the following steps:
Step 1
Create a DCERPC inspection policy map, enter the following command:
hostname(config)# policy-map type inspect dcerpc policy_map_name
hostname(config-pmap)#
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-16
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
DNS Inspection
Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration
mode.
Step 2
(Optional) To add a description to the policy map, enter the following command:
hostname(config-pmap)# description string
Step 3
To configure parameters that affect the inspection engine, perform the following steps:
a.
To enter parameters configuration mode, enter the following command:
hostname(config-pmap)# parameters
hostname(config-pmap-p)#
b.
To configure the timeout for DCERPC pinholes and override the global system pinhole timeout of
two minutes, enter the following command:
hostname(config-pmap-p)# timeout pinhole hh:mm:ss
Where the hh:mm:ss argument is the timeout for pinhole connections. Value is between 0:0:1 and
1193:0:0.
c.
To configure options for the endpoint mapper traffic, enter the following command:
hostname(config-pmap-p)# endpoint-mapper [epm-service-only] [lookup-operation
[timeout hh:mm:ss]]
Where the hh:mm:ss argument is the timeout for pinholes generated from the lookup operation. If
no timeout is configured for the lookup operation, the timeout pinhole command or the default is
used. The epm-service-only keyword enforces endpoint mapper service during binding so that only
its service traffic is processed. The lookup-operation keyword enables the lookup operation of the
endpoint mapper service.
The following example shows how to define a DCERPC inspection policy map with the timeout
configured for DCERPC pinholes.
hostname(config)# policy-map type inspect dcerpc dcerpc_map
hostname(config-pmap)# timeout pinhole 0:10:00
hostname(config)# class-map dcerpc
hostname(config-cmap)# match port tcp eq 135
hostname(config)# policy-map global-policy
hostname(config-pmap)# class dcerpc
hostname(config-pmap-c)# inspect dcerpc dcerpc-map
hostname(config)# service-policy global-policy global
DNS Inspection
This section describes how to manage DNS application inspection. This section includes the following
topics:
•
How DNS Application Inspection Works, page 21-18
•
How DNS Rewrite Works, page 21-18
•
Configuring DNS Rewrite, page 21-19
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-17
Chapter 21
Applying Application Layer Protocol Inspection
DNS Inspection
•
Configuring DNS Inspection, page 21-24
•
Verifying and Monitoring DNS Inspection, page 21-25
•
DNS Guard, page 21-26
How DNS Application Inspection Works
The FWSM tears down the DNS session associated with a DNS query as soon as the DNS reply is
forwarded by the FWSM. The FWSM also monitors the message exchange to ensure that the ID of the
DNS reply matches the ID of the DNS query.
When DNS inspection is enabled, which is the default, the FWSM performs the following additional
tasks:
•
Translates the DNS record based on the configuration completed using the alias, static and nat
commands (DNS Rewrite). Translation only applies to the A-record in the DNS reply; therefore,
DNS Rewrite does not affect reverse lookups, which request the PTR record.
Note
DNS Rewrite is not applicable for PAT because multiple PAT rules are applicable for each
A-record and the PAT rule to use is ambiguous.
•
Enforces the maximum DNS message length (the default is 512 bytes and the maximum length is
65535 bytes). The FWSM performs reassembly as needed to verify that the packet length is less than
the maximum length configured. The FWSM drops the packet if it exceeds the maximum length.
Note
If you enter the inspect dns command without the maximum-length option, the DNS packet
size is not checked.
•
Enforces a domain-name length of 255 bytes and a label length of 63 bytes.
•
Verifies the integrity of the domain-name referred to by the pointer if compression pointers are
encountered in the DNS message.
•
Checks to see if a compression pointer loop exists.
A single connection is created for multiple DNS sessions, as long as they are between the same two
hosts, and the sessions have the same 5-tuple (source/destination IP address, source/destination port, and
protocol). DNS identification is tracked by app_id, and the idle timer for each app_id runs
independently.
Because the app_id expires independently, a legitimate DNS response can only pass through the FWSM
within a limited period of time and there is no resource build-up. However, if you enter the show conn
command, you will see the idle timer of a DNS connection being reset by a new DNS session. This is
due to the nature of the shared DNS connection and is by design.
How DNS Rewrite Works
When DNS inspection is enabled, DNS Rewrite provides full support for NAT of DNS messages
originating from any interface.
If a client on an inside network requests DNS resolution of an inside address from a DNS server on an
outside interface, the DNS A-record is translated correctly. If the DNS inspection engine is disabled, the
A-record is not translated.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-18
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
DNS Inspection
As long as DNS inspection remains enabled, you can configure DNS Rewrite using the alias, static, or
nat commands. For details about the configuration required see the “Configuring DNS Rewrite” section
on page 21-19.
DNS Rewrite performs two functions:
•
Translating a public address (the routable or “mapped” address) in a DNS reply to a private address
(the “real” address) when the DNS client is on a private interface.
•
Translating a private address to a public address when the DNS client is on the public interface.
In Figure 21-4, the DNS server resides on the external (ISP) network. On the FWSM, a static command
maps the real address of the web server (192.168.100.1) to the ISP-assigned address (209.165.201.5).
When a web client on the inside interface attempts to access the web server with the URL
http://server.example.com, the host running the web client sends a DNS request to the DNS server to
resolve the IP address of the web server. The FWSM translates the non-routable source address in the IP
header and forwards the request to the ISP network on its outside interface. When the DNS reply is
returned, the FWSM applies address translation not only to the destination address, but also to the
embedded IP address of the web server, which is contained in the A-record in the DNS reply. As a result,
the web client on the inside network gets the correct address for connecting to the web server on the
inside network. For the exact NAT and DNS configuration for this example, see Example 21-2. For
configuration instructions for scenarios similar to this one, see the “Configuring DNS Rewrite with Two
NAT Zones” section on page 21-21.
Figure 21-4
DNS Rewrite with Two NAT Zones
DNS server
server.example.com IN A 209.165.200.225
Web server
server.example.com
192.168.100.1
ISP Internet
Web client
http://server.example.com
192.168.100.2
132972
FWSM
192.168.100.1IN A 209.165.200.225
DNS Rewrite also works if the client making the DNS request is on a DMZ network and the DNS server
is on an inside interface. For an illustration and configuration instructions for this scenario, see the “DNS
Rewrite with Three NAT Zones” section on page 21-22.
Configuring DNS Rewrite
You configure DNS Rewrite using the alias, static, or nat commands. The alias and static command can
be used interchangeably; however, we recommend using the static command for new deployments
because it is more precise and unambiguous. Also, DNS Rewrite is optional when using the static
command.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-19
Chapter 21
Applying Application Layer Protocol Inspection
DNS Inspection
This section describes how to use the alias and static commands to configure DNS Rewrite. It provides
configuration procedures for using the static command in a simple scenario and in a more complex
scenario. Using the nat command is similar to using the static command except that DNS Rewrite is
based on dynamic translation instead of a static mapping.
This section includes the following topics:
•
Using the Alias Command for DNS Rewrite, page 21-20
•
Using the Static Command for DNS Rewrite, page 21-20
•
Configuring DNS Rewrite with Two NAT Zones, page 21-21
•
DNS Rewrite with Three NAT Zones, page 21-22
•
Configuring DNS Rewrite with Three NAT Zones, page 21-23
For detailed syntax and additional functions for the alias, nat, and static command, see the appropriate
command page in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services
Module Command Reference.
Using the Alias Command for DNS Rewrite
The alias command causes the FWSM to translate addresses on an IP network residing on any interface
into addresses on another IP network connected through a different interface. The syntax for this
command is as follows.
hostname(config)# alias (inside) mapped-address real-address
The following example specifies that the real address (192.168.100.10) on any interface except the inside
interface will be translated to the mapped address (209.165.200.225) on the inside interface. Notice that
the location of 192.168.100.10 is not precisely defined.
hostname(config)# alias (inside) 209.165.200.225 192.168.100.10
Note
If you use the alias command to configure DNS Rewrite, proxy ARP will be performed for the mapped
address. To prevent this, disable Proxy ARP by entering the sysopt noproxyarp internal_interface
command after entering the alias command.
Using the Static Command for DNS Rewrite
The static command causes addresses on an IP network residing on a specific interface to be translated
into addresses on another IP network on a different interface. The syntax for this command is as follows.
hostname(config)# static (inside,outside) mapped-address real-address dns
The following example specifies that the address 192.168.100.10 on the inside interface is translated into
209.165.201.5 on the outside interface:
hostname(config)# static (inside,outside) 209.165.200.225 192.168.100.10 dns
Note
Using the nat command is similar to using the static command except that DNS Rewrite is based on
dynamic translation instead of a static mapping.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-20
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
DNS Inspection
Configuring DNS Rewrite with Two NAT Zones
To implement a DNS Rewrite scenario similar to the one shown in Figure 21-4, perform the following
steps:
Step 1
Create a static translation for the web server, as follows:
hostname(config)# static (inside,outside) mapped-address real-address netmask
255.255.255.255 dns
where the arguments are as follows:
Step 2
•
inside—The name of the inside interface of the FWSM.
•
outside—The name of the outside interface of the FWSM.
•
mapped-address—The translated IP address of the web server.
•
real-address—The real IP address of the web server.
Create an access list that permits traffic to the port that the web server listens to for HTTP requests.
hostname(config)# access-list acl-name permit tcp any host mapped-address eq port
where the arguments are as follows:
acl-name—The name you give the access-list.
mapped-address—The translated IP address of the web server.
port—The TCP port that the web server listens to for HTTP requests.
Step 3
Apply the access list created in Step 2 to the outside interface. To do so, use the access-group command,
as follows.
hostname(config)# access-group acl-name in interface outside
Step 4
If DNS inspection is disabled or if you want to change the maximum DNS packet length, configure DNS
inspection. DNS application inspection is enabled by default with a maximum DNS packet length of 512
bytes. For configuration instructions, see the “Configuring DNS Inspection” section on page 21-24.
Step 5
On the public DNS server, add an A-record for the web server, such as:
domain-qualified-hostname. IN A mapped-address
where domain-qualified-hostname is the hostname with a domain suffix, as in server.example.com. The
period after the hostname is important. mapped-address is the translated IP address of the web server.
The following example configures the FWSM for the scenario shown in Figure 21-4. It assumes DNS
inspection is already enabled.
Example 21-2 DNS Rewrite with Two NAT Zones
hostname(config)# static (inside,outside) 209.165.200.225 192.168.100.1 netmask
255.255.255.255 dns
hostname(config)# access-list 101 permit tcp any host 209.165.200.225 eq www
hostname(config)# access-group 101 in interface outside
This configuration requires the following A-record on the DNS server:
server.example.com. IN A 209.165.200.225
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-21
Chapter 21
Applying Application Layer Protocol Inspection
DNS Inspection
DNS Rewrite with Three NAT Zones
Figure 21-5 illustrates a more complex scenario: how DNS inspection allows NAT to operate
transparently with a DNS server with minimal configuration. For configuration instructions for scenarios
like this one, see the “Configuring DNS Rewrite with Three NAT Zones” section on page 21-23.
Figure 21-5
DNS Rewrite with Three NAT Zones
DNS server
server.example.com IN A 209.165.200.225
Outside
Web server
192.168.100.10
FWSM
DMZ
192.168.100.1
Inside
10.10.10.1
Web client
10.10.10.25
132973
10.99.99.2
In Figure 21-5, a web server, server.example.com, has the real address 192.168.100.10 on the DMZ
interface of the FWSM. A web client with the IP address 10.10.10.25 is on the inside interface and a
public DNS server is on the outside interface. The site NAT policies are as follows:
•
The outside DNS server holds the authoritative address record for server.example.com.
•
Hosts on the outside network can contact the web server with the domain name server.example.com
through the outside DNS server or with the IP address 209.165.200.225.
•
Clients on the inside network can access the web server with the domain name server.example.com
through the outside DNS server or with the IP address 192.168.100.10.
When a host or client on any interface accesses the DMZ web server, it queries the public DNS server
for the A-record of server.example.com. The DNS server returns the A-record showing that
server.example.com binds to address 209.165.200.225.
When a web client on the outside network attempts to access http://server.example.com, the sequence of
events is as follows:
1.
The host running the web client sends the DNS server a request for the IP address of
server.example.com.
2.
The DNS server responds with the IP address 209.165.200.225 in the reply.
3.
The web client sends its HTTP request to 209.165.200.225.
4.
The packet from the outside host reaches the FWSM at the outside interface.
5.
The static rule translates the address 209.165.200.225 to 192.168.100.10 and the FWSM directs the
packet to the web server on the DMZ.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-22
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
DNS Inspection
When a web client on the inside network attempts to access http://server.example.com, the sequence of
events is as follows:
1.
The host running the web client sends the DNS server a request for the IP address of
server.example.com.
2.
The DNS server responds with the IP address 209.165.200.225 in the reply.
3.
The FWSM receives the DNS reply and submits it to the DNS application inspection engine.
4.
The DNS application inspection engine does the following:
a. Searches for any NAT rule to undo the translation of the embedded A-record address
“[outside]:209.165.200.5”. In this example, it finds the following static configuration.
static (dmz,outside) 209.165.200.225 192.168.100.10 dns
b. Uses the static rule to rewrite the A-record as follows because the dns option is included:
[outside]:209.165.200.225 --> [dmz]:192.168.100.10
Note
If the dns option were not included with the static command, DNS Rewrite would not
be performed and other processing for the packet continues.
c. Searches for any NAT to translate the web server address, [dmz]:192.168.100.10, when
communicating with the inside web client.
No NAT rule is applicable, so application inspection completes.
If a NAT rule (nat or static) were applicable, the dns option must also be specified. If the dns
option were not specified, the A-record rewrite in step b would be reverted and other processing
for the packet continues.
5.
The FWSM sends the HTTP request to server.example.com on the DMZ interface.
Configuring DNS Rewrite with Three NAT Zones
To enable the NAT policies for the scenario in Figure 21-5, perform the following steps:
Step 1
Create a static translation for the web server on the DMZ network, as follows:
hostname(config)# static (dmz,outside) mapped-address real-address dns
where the arguments are as follows:
Step 2
•
dmz—The name of the DMZ interface of the FWSM.
•
outside—The name of the outside interface of the FWSM.
•
mapped-address—The translated IP address of the web server.
•
real-address—The real IP address of the web server.
Create an access list that permits traffic to the port that the web server listens to for HTTP requests.
hostname(config)# access-list acl-name permit tcp any host mapped-address eq port
where the arguments are as follows:
acl-name—The name you give the access-list.
mapped-address—The translated IP address of the web server.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-23
Chapter 21
Applying Application Layer Protocol Inspection
DNS Inspection
port—The TCP port that the web server listens to for HTTP requests.
Step 3
Apply the access list created in Step 2 to the outside interface. To do so, use the access-group command,
as follows:
hostname(config)# access-group acl-name in interface outside
Step 4
If DNS inspection is disabled or if you want to change the maximum DNS packet length, configure DNS
inspection. DNS application inspection is enabled by default with a maximum DNS packet length of 512
bytes. For configuration instructions, see the “Configuring DNS Inspection” section on page 21-24.
Step 5
On the public DNS server, add an A-record for the web server, such as:
domain-qualified-hostname. IN A mapped-address
where domain-qualified-hostname is the hostname with a domain suffix, as in server.example.com. The
period after the hostname is important. mapped-address is the translated IP address of the web server.
The following example configures the FWSM for the scenario shown in Figure 21-5. It assumes DNS
inspection is already enabled.
Example 21-3 DNS Rewrite with Three NAT Zones
hostname(config)# static (dmz,outside) 209.165.200.225 192.168.100.10 dns
hostname(config)# access-list 101 permit tcp any host 209.165.200.225 eq www
hostname(config)# access-group 101 in interface outside
This configuration requires the following A-record on the DNS server:
server.example.com. IN A 209.165.200.225
Configuring DNS Inspection
DNS inspection is enabled by default.
To enable DNS inspection (if it has been previously disabled) or to change the default port used for
receiving DNS traffic, perform the following steps:
Step 1
Create a class map or modify an existing class map to identify DNS traffic. Use the class-map command
to do so, as follows.
hostname(config)# class-map class_map_name
hostname(config-cmap)#
where class_map_name is the name of the traffic class. When you enter the class-map command, the
CLI enters class map configuration mode.
Step 2
Use the match port command to identify DNS traffic. The default port for DNS is UDP port 53.
hostname(config-cmap)# match port udp eq 53
Step 3
Create a policy map or modify an existing policy map that you want to use to apply the DNS inspection
engine to FTP traffic. To do so, use the policy-map command, as follows.
hostname(config-cmap)# policy-map policy_map_name
hostname(config-pmap)#
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-24
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
DNS Inspection
where policy_map_name is the name of the policy map. The CLI enters the policy map configuration
mode and the prompt changes accordingly.
Step 4
Enable DNS application inspection. To do so, use the inspect dns command, as follows.
hostname(config-pmap-c)# inspect dns [maximum-length max-pkt-length]
To change the maximum DNS packet length from the default (512), use the maximum-length argument
and replace max-pkt-length with a numeric value. Longer packets are dropped. To disable checking the
DNS packet length, enter the inspect dns command without the maximum-length keyword.
Step 5
Use the service-policy command to apply the policy map globally or to a specific interface, as follows:
hostname(config-pmap-c)# service-policy policy_map_name [global | interface interface_ID]
hostname(config)#
where policy_map_name is the policy map you configured in Step 3. If you want to apply the policy map
to traffic on all the interfaces, use the global option. If you want to apply the policy map to traffic on a
specific interface, use the interface interface_ID option, where interface_ID is the name assigned to the
interface with the nameif command.
The FWSM begins inspecting DNS traffic, as specified.
Example 21-4 Enabling and Configuring DNS Inspection
The following example creates a class map to match DNS traffic on the default port (53), and enables
DNS inspection in the sample_policy policy map, and applies DNS inspection to the outside interface.
hostname(config)# class-map dns_port
hostname(config-cmap)# match port udp eq 53
hostname(config-cmap)# policy-map sample_policy
hostname(config-pmap)# class dns_port
hostname(config-pmap-c)# inspect dns maximum-length 1500
hostname(config-pmap-c)# service-policy sample_policy interface outside
Verifying and Monitoring DNS Inspection
To view information about the current DNS connections, enter the following command:
hostname# show conn
For connections using a DNS server, the source port of the connection may be replaced by the IP address
of DNS server in the show conn command output.
A single connection is created for multiple DNS sessions, as long as they are between the same two
hosts, and the sessions have the same 5-tuple (source/destination IP address, source/destination port, and
protocol). DNS identification is tracked by app_id, and the idle timer for each app_id runs independently.
Because the app_id expires independently, a legitimate DNS response can only pass through the FWSM
within a limited period of time and there is no resource build-up. However, when you enter the show
conn command, you see the idle timer of a DNS connection being reset by a new DNS session. This is
due to the nature of the shared DNS connection and is by design.
To display the statistics for DNS application inspection, enter the show service-policy command. The
following is sample output from the show service-policy command.
hostname# show service-policy
Interface outside:
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-25
Chapter 21
Applying Application Layer Protocol Inspection
ESMTP Inspection
Service-policy: sample_policy
Class-map: dns_port
Inspect: dns maximum-length 1500, packet 0, drop 0, reset-drop 0
DNS Guard
When a client sends a DNS request to an external DNS server, only the first response is accepted by the
FWSM. All additional responses from other DNS servers are dropped by the FWSM.
After the client issues a DNS request, a dynamic hole allows UDP packets to return from the DNS server.
When the FWSM receives a response from the first DNS server, the connection that was created in the
accelerated path is dropped so that subsequent responses from other DNS servers are dropped by the
FWSM. The UDP DNS connection is deleted immediately rather than marking the connection for
deletion.
The FWSM creates a session-lookup key based on the source and destination IP address along with the
protocol and the DNS ID instead of the source and destination ports.
If the DNS client and DNS server use TCP for DNS, the connection is cleared like a normal TCP
connection.
However, if clients receive DNS responses from multiple DNS servers, you can disable the default DNS
behavior on a per context basis. When DNS Guard is disabled, a response from the first DNS server does
not delete the connection and the connection is treated as a normal UDP connection.
DNS Guard is enabled by default.
To disable DNS Guard, enter the following commands:
hostname(config)# no dns-guard
hostname(config)# show running-config | inc dns-guard
no dns-guard
hostname(config)#
ESMTP Inspection
ESMTP inspection detects attacks, including spam, phising, malformed message attacks, buffer
overflow/underflow attacks. It also provides support for application security and protocol conformance,
which enforce the sanity of the ESMTP messages as well as detect several attacks, block
senders/receivers, and block mail relay.
Configuring an ESMTP Inspection Policy Map for Additional Inspection Control
To specify actions when a message violates a parameter, create an ESMTP inspection policy map. You
can then apply the inspection policy map when you enable ESMTP inspection according to the
“Configuring Application Inspection” section on page 21-6.
To create an ESMTP inspection policy map, perform the following steps:
Step 1
(Optional) Add one or more regular expressions for use in traffic matching commands according to the
“Creating a Regular Expression” section on page 19-11. See the types of text you can match in the match
commands described in Step 3.
Step 2
(Optional) Create one or more regular expression class maps to group regular expressions according to
the “Creating a Regular Expression Class Map” section on page 19-14.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-26
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
ESMTP Inspection
Step 3
Create an ESMTP inspection policy map, enter the following command:
hostname(config)# policy-map type inspect esmtp policy_map_name
hostname(config-pmap)#
Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration
mode.
Step 4
(Optional) To add a description to the policy map, enter the following command:
hostname(config-pmap)# description string
Step 5
To apply actions to matching traffic, perform the following steps.
a.
Specify traffic directly in the policy map using one of the match commands described in Step 3. If
you use a match not command, then any traffic that does not match the criterion in the match not
command has the action applied.
b.
Specify the action you want to perform on the matching traffic by entering the following command:
hostname(config-pmap-c)# {[drop [send-protocol-error] |
drop-connection [send-protocol-error]| mask | reset] [log] | rate-limit message_rate}
Not all options are available for each match or class command. See the CLI help or the Catalyst
6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference for
the exact options available.
The drop keyword drops all packets that match.
The send-protocol-error keyword sends a protocol error message.
The drop-connection keyword drops the packet and closes the connection.
The mask keyword masks out the matching portion of the packet.
The reset keyword drops the packet, closes the connection, and sends a TCP reset to the server
and/or client.
The log keyword, which you can use alone or with one of the other keywords, sends a system log
message.
The rate-limit message_rate argument limits the rate of messages.
You can specify multiple class or match commands in the policy map. For information about the order
of class and match commands, see the “Defining Actions in an Inspection Policy Map” section on
page 19-7.
Step 6
To configure parameters that affect the inspection engine, perform the following steps:
a.
To enter parameters configuration mode, enter the following command:
hostname(config-pmap)# parameters
hostname(config-pmap-p)#
b.
To configure a local domain name, enter the following command:
hostname(config-pmap-p)# mail-relay domain-name action [drop-connection | log]]
Where the drop-connection action closes the connection. The log action sends a system log
message when this policy map matches traffic.
c.
To enforce banner obfuscation, enter the following command:
hostname(config-pmap-p)# mask-banner
d.
(Optional) To detect special characters in sender or receiver email addresses, enter the following
command:
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-27
Chapter 21
Applying Application Layer Protocol Inspection
ESMTP Inspection
hostname(config-pmap-p)# special-character action [drop-connection | log]]
Using this command detects pipe (|), backquote (`) and null characters.
e.
(Optional) To match the body length or body line length, enter the following command:
hostname(config-pmap-p)# match body [line] length gt length
Where length is the length of the message body or the length of a line in the message body.
f.
(Optional) To match an ESMTP command verb, enter the following command:
hostname(config-pmap-p)# match cmd verb verb
Where verb is any of the following ESMTP commands:
AUTH|DATA|EHLO|ETRN||HELO|HELP|MAIL|NOOP|QUIT|RCPT|RSET|SAML|SOML|VRFY
g.
(Optional) To match the number of recipient addresses, enter the following command:
hostname(config-pmap-p)# match cmd RCPT count gt count
Where count is the number of recipient addresses.
h.
(Optional) To match the command line length, enter the following command:
hostname(config-pmap-p)# match cmd line length gt length
Where length is the command line length.
i.
(Optional) To match the ehlo-reply-parameters, enter the following command:
hostname(config-pmap-p)# match ehlo-reply-parameter extensions
Where extensions are the ESMTP service extensions sent by the server in response to the EHLO
message from the client. These extensions are implemented as a new command or as parameters to
an existing command. extensions can be any of the following.
8bitmime|binarymime|checkpoint|dsn|ecode|etrn|others|pipelining|size|vrfy
j.
(Optional) To match the header length or header line length, enter the following command:
hostname(config-pmap-p)# match header [line] length gt length
Where length is the number of characters in the header or line.
k.
(Optional) To match the header to-fields count, enter the following command:
hostname(config-pmap-p)# match header to-fields count gt count
Where count is the number of recipients in the to-field of the header.
l.
(Optional) To match the number of invalid recipients, enter the following command:
hostname(config-pmap-p)# match invalid-recipients count gt count
Where count is the number of invalid recipients.
m.
(Optional) To match the type of MIME encoding scheme used, enter the following command:
hostname(config-pmap-p)# match mime encoding [7bit|8bit|base64|binary|others|
quoted-printable]
n.
(Optional) To match the MIME filename length, enter the following command:
hostname(config-pmap-p)# match mime filename length gt length
Where length is the length of the filename in the range 1 to 1000.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-28
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
ESMTP Inspection
o.
(Optional) To match the MIME file type, enter the following command:
hostname(config-pmap-p)# match mime filetype regex [name | class name]
Where name or class name is the regular expression that matches a file type or a class map. The
regular expression used to match a class map can select multiple file types.
p.
(Optional) To match a sender address, enter the following command:
hostname(config-pmap-p)# match sender-address regex [name | class name]
Where name or class name is the regular expression that matches a sender address or a class map.
The regular expression used to match a class map can select multiple sender addresses.
q.
(Optional) To match the length of a sender’s address, enter the following command:
hostname(config-pmap-p)# match sender-address length gt length
Where length is the number of characters in the sender’s address.
The following example shows how to define an ESMTP inspection policy map.
hostname(config)# regex user1 “user1@cisco.com”
hostname(config)# regex user2 “user2@cisco.com”
hostname(config)# regex user3 “user3@cisco.com”
hostname(config)# class-map type regex senders_black_list
hostname(config-cmap)# description “Regular expressions to filter out undesired senders”
hostname(config-cmap)# match regex user1
hostname(config-cmap)# match regex user2
hostname(config-cmap)# match regex user3
hostname(config)# policy-map type inspect esmtp advanced_esmtp_map
hostname(config-pmap)# match sender-address regex class senders_black_list
hostname(config-pmap-c)# drop-connection log
hostname(config)# policy-map outside_policy
hostname(config-pmap)# class inspection_default
hostname(config-pmap-c)# inspect esmtp advanced_esmtp_map
hostname(config)# service-policy outside_policy interface outside
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-29
Chapter 21
Applying Application Layer Protocol Inspection
FTP Inspection
FTP Inspection
This section describes how the FTP inspection engine works and how you can change its configuration.
This section includes the following topics:
•
FTP Inspection Overview, page 21-30
•
Using the strict Option, page 21-30
•
The request-command deny Command, page 21-31
•
Configuring FTP Inspection, page 21-32
•
Verifying and Monitoring FTP Inspection, page 21-34
FTP Inspection Overview
The FTP application inspection inspects the FTP sessions and performs four tasks:
•
Prepares dynamic secondary data connection
•
Tracks ftp command-response sequence
•
Generates an audit trail
•
NATs embedded IP address
FTP application inspection prepares secondary channels for FTP data transfer. Ports for these channels
are negotiated through PORT or PASV commands. The channels are allocated in response to a file
upload, a file download, or a directory listing event.
Note
If you disable FTP inspection engines with the no inspect ftp command, outbound users can start
connections only in passive mode, and all inbound FTP is disabled.
Using the strict Option
Using the strict option with the inspect ftp command increases the security of protected networks by
preventing web browsers from sending embedded commands in FTP requests.
Tip
To specify FTP commands that are not permitted to pass through the FWSM, create an FTP map and
enter the request-command deny command in FTP map configuration mode.
After you enable the strict option on an interface, FTP inspection enforces the following behavior:
Caution
•
An FTP command must be acknowledged before the FWSM allows a new command.
•
The FWSM drops connections that send embedded commands.
•
The 227 and PORT commands are checked to ensure they do not appear in an error string.
Using the strict option may cause the failure of FTP clients that are not strictly compliant with FTP
RFCs.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-30
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
FTP Inspection
If the strict option is enabled, each ftp command and response sequence is tracked for the following
anomalous activity:
•
Truncated command—Number of commas in the PORT and PASV reply command is checked to see
if it is five. If it is not five, then the PORT command is assumed to be truncated and the TCP
connection is closed.
•
Incorrect command—Checks the ftp command to see if it ends with <CR><LF> characters, as
required by the RFC. If it does not, the connection is closed.
•
Size of RETR and STOR commands—These are checked against a fixed constant. If the size is
greater, then an error message is logged and the connection is closed.
•
Command spoofing—The PORT command should always be sent from the client. The TCP
connection is denied if a PORT command is sent from the server.
•
Reply spoofing—PASV reply command (227) should always be sent from the server. The TCP
connection is denied if a PASV reply command is sent from the client. This prevents the security
hole when the user executes “227 xxxxx a1, a2, a3, a4, p1, p2.”
•
TCP stream editing—The FWSM closes the connection if it detects TCP stream editing.
•
Invalid port negotiation—The negotiated dynamic port value is checked to see if it is less than 1024.
As port numbers in the range from 1 to 1024 are reserved for well-known connections, if the
negotiated port falls in this range, then the TCP connection is freed.
•
Command pipelining—The number of characters present after the port numbers in the PORT and
PASV reply command is cross checked with a constant value of 8. If it is more than 8, then the TCP
connection is closed.
•
The FWSM replaces the FTP server response to the SYST command with a series of Xs to prevent
the server from revealing its system type to FTP clients. To override this default behavior, use the
no mask-syst-reply command in FTP map configuration mode.
The request-command deny Command
The request-command deny command lets you control which FTP commands the FWSM allows for
FTP traffic through the FWSM. This command is available in FTP map configuration mode; therefore,
to make use of it, you must create an FTP map and use that map when you enable FTP inspection, per
“Configuring FTP Inspection” section on page 21-32.
Table 21-3 lists the FTP commands that you can disallow by using the request-command deny
command.
.
Table 21-3
FTP Map request-command deny Options
request-command deny Option
Purpose
appe
Disallows the command that appends to a file.
cdup
Disallows the command that changes to the parent directory of the
current working directory.
dele
Disallows the command that deletes a file on the server.
get
Disallows the client command for retrieving a file from the server.
help
Disallows the command that provides help information.
mkd
Disallows the command that makes a directory on the server.
put
Disallows the client command for sending a file to the server.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-31
Chapter 21
Applying Application Layer Protocol Inspection
FTP Inspection
Table 21-3
FTP Map request-command deny Options (continued)
request-command deny Option
Purpose
rmd
Disallows the command that deletes a directory on the server.
rnfr
Disallows the command that specifies rename-from filename.
rnto
Disallows the command that specifies rename-to filename.
site
Disallows the command that are specific to the server system.
Usually used for remote administration.
stou
Disallows the command that stores a file using a unique filename.
Configuring FTP Inspection
FTP application inspection is enabled default, so you only need to perform the procedures in this section
if you want to change the default FTP configuration, in any of the following ways:
•
Enable the strict option.
•
Identify specific FTP commands that are not permitted to pass through the FWSM.
•
Change the default port number.
To configure FTP inspection, perform the following steps:
Step 1
Determine the ports to which FTP servers behind your FWSM listen. The default FTP port is TCP port
21; however, alternate ports are often used as a simple means to thwart attacks. To ensure that all FTP
traffic is inspected, check your FTP servers for use of ports other than TCP port 21.
Step 2
Create a class map or modify an existing class map to identify FTP traffic. Use the class-map command
to do so, as follows.
hostname(config)# class-map class_map_name
hostname(config-cmap)#
where class_map_name is the name of the traffic class. When you enter the class-map command, the
CLI enters class map configuration mode.
Step 3
Identify traffic sent to the FTP ports you determined in Step 1. To do so, use a match port or match
access-list command.
If you need to identify two or more non-contiguous ports, create an access list with the access-list
extended command, add an ACE to match each port, and then use the match access-list command. The
following commands show how to use an access list to identify multiple TCP ports with an access list.
hostname(config)# access-list acl-name any any tcp eq port_number_1
hostname(config)# access-list acl-name any any tcp eq port_number_2
hostname(config)# class-map class_map_name
hostname(config-cmap)# match access-list acl-name
If you need to identify a single port, use the match port command, as follows:
hostname(config-cmap)# match port tcp port_number
where port_number is the only TCP port listened to by FTP servers behind the FWSM.
If you need to identify a range of contiguous ports for a single protocol, use match port command with
the range keyword, as follows:
hostname(config-cmap)# match port tcp range begin_port_number end_port_number
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-32
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
FTP Inspection
where begin_port_number is the lowest port in the range of FTP ports and end_port_number is the
highest port.
Step 4
(Optional) If you want FTP inspection to do the following:
•
Allow FTP servers to reveal their system type to FTP clients.
•
Limit the allowed FTP commands.
then create and configure an FTP map. To do so, perform the following steps.
a.
Create an FTP map that contains the additional parameters of FTP inspection. Use the ftp-map
command to do so, as follows.
hostname(config-cmap)# ftp-map map_name
hostname(config-ftp-map)#
where map_name is the name of the FTP map. The CLI enters FTP map configuration mode.
b.
(Optional) If you want to allow FTP servers from revealing their system type to FTP clients in
responses to SYST messages, use the no form of the mask-syst-reply command, as follows:
hostname(config-ftp-map)# no mask-syst-reply
hostname(config-ftp-map)#
Note
c.
By default, when FTP inspection is enabled, responses to SYST messages are masked. If you
disable SYST response masking, you can reenable it with the mask-syst-response command.
(Optional) If you want to disallow specific FTP commands, use the request-command deny
command and specify each FTP command that you want to disallow, as follows:
hostname(config-ftp-map)# request-command deny ftp_command [ftp_command...]
hostname(config-ftp-map)#
where ftp_command with one or more FTP commands that you want to restrict. See Table 21-3 for
a list of the FTP commands that you can restrict.
Step 5
Create a policy map or modify an existing policy map that you want to use to apply the FTP inspection
engine to FTP traffic. To do so, use the policy-map command, as follows.
hostname(config-cmap)# policy-map policy_map_name
hostname(config-pmap)#
where policy_map_name is the name of the policy map. The CLI enters the policy map configuration
mode and the prompt changes accordingly.
Step 6
Specify the class map, created in Step 2, that identifies the FTP traffic. Use the class command to do so,
as follows.
hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)#
where class_map_name is the name of the class map you created in Step 2. The CLI enters the policy
map class configuration mode and the prompt changes accordingly.
Step 7
Enable FTP application inspection with the options you want. To do so, do one of the following.
•
If you want to enable strict FTP inspection, use the inspect ftp command with the strict keyword,
as follows:
hostname(config-pmap-c)# inspect ftp strict
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-33
Chapter 21
Applying Application Layer Protocol Inspection
FTP Inspection
•
If you want to enable strict FTP inspection with an optional FTP map you may have configured in
Step 4, use the inspect ftp command with the strict keyword and the FTP map name, as follows:
hostname(config-pmap-c)# inspect ftp strict ftp_map_name
•
If you want to revert to default FTP inspection, use the inspect ftp command with no keywords, as
follows:
hostname(config-pmap-c)# inspect ftp
Step 8
Use the service-policy command to apply the policy map globally or to a specific interface, as follows:
hostname(config-pmap-c)# service-policy policy_map_name [global | interface interface_ID]
hostname(config)#
where policy_map_name is the policy map you configured in Step 5. If you want to apply the policy map
to traffic on all the interfaces, use the global option. If you want to apply the policy map to traffic on a
specific interface, use the interface interface_ID option, where interface_ID is the name assigned to the
interface with the nameif command.
The FWSM begins inspecting FTP traffic, as specified.
The following example shows how to identify FTP traffic, define a FTP map, define a policy, and apply
the policy to the outside interface.
Example 21-5 Enabling and Configuring Strict FTP Inspection
hostname(config)# class-map ftp_port
hostname(config-cmap)# match port tcp eq 21
hostname(config-cmap)# ftp-map sample_map
hostname(config-ftp-map)# request-command deny put stou appe
hostname(config-ftp-map)# policy-map sample_policy
hostname(config-pmap)# class ftp_port
hostname(config-pmap-c)# inspect ftp strict sample_map
hostname(config-pmap-c)# service-policy sample_policy interface outside
Verifying and Monitoring FTP Inspection
FTP application inspection generates the following log messages:
•
An Audit record 302002 is generated for each file that is retrieved or uploaded.
•
The FTP command is checked to see if it is RETR or STOR and the retrieve and store commands
are logged.
•
The username is obtained by looking up a table providing the IP address.
•
The username, source IP address, destination IP address, NAT address, and the file operation are
logged.
•
Audit record 201005 is generated if the secondary dynamic channel preparation failed due to
memory shortage.
In conjunction with NAT, the FTP application inspection translates the IP address within the application
payload. This is described in detail in RFC 959.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-34
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
GTP Inspection
GTP Inspection
This section describes how the GTP inspection engine works and how you can change its configuration.
This section includes the following topics:
Note
•
GTP Inspection Overview, page 21-35
•
GTP Maps and Commands, page 21-36
•
Enabling and Configuring GTP Inspection, page 21-37
•
Verifying and Monitoring GTP Inspection, page 21-39
•
GGSN Load Balancing, page 21-40
•
GTP Sample Configuration, page 21-41
GTP inspection requires a special license. If you enter GTP-related commands on a FWSM without the
required license, the FWSM displays an error message.
GTP Inspection Overview
GPRS provides uninterrupted connectivity for mobile subscribers between GSM networks and corporate
networks or the Internet. The GGSN is the interface between the GPRS wireless data network and other
networks. The SGSN performs mobility, data session management, and data compression (See
Figure 21-6).
Figure 21-6
GPRS Tunneling Protocol
Internet
Home PLMN
MS
SGSN
Gn
GGSN Gi
Corporate
network 2
Gp
Corporate
network 1
Roaming partner
(visited PLMN)
119935
GRX
The UMTS is the commercial convergence of fixed-line telephony, mobile, Internet and computer
technology. UTRAN is the networking protocol used for implementing wireless networks in this system.
GTP allows multi-protocol packets to be tunneled through a UMTS/GPRS backbone between a GGSN,
an SGSN and the UTRAN.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-35
Chapter 21
Applying Application Layer Protocol Inspection
GTP Inspection
GTP does not include any inherent security or encryption of user data, but using GTP with the FWSM
helps protect your network against these risks.
The SGSN is logically connected to a GGSN using GTP. GTP allows multiprotocol packets to be
tunneled through the GPRS backbone between GSNs. GTP provides a tunnel control and management
protocol that allows the SGSN to provide GPRS network access for a mobile station by creating,
modifying and deleting tunnels. GTP uses a tunneling mechanism to provide a service for carrying user
data packets.
Note
When using GTP with failover, if a GTP connection is established and the active unit fails before data
is transmitted over the tunnel, the GTP data connection (with a “j” flag set) is not replicated to the
standby unit. This occurs because the active unit does not replicate embryonic connections to the standby
unit.
The GGSN load balancing feature allows any GSN belonging to a GSN pool to respond to an SGSN
request to achieve load balancing on the GGSNs.
GTP Maps and Commands
You can enforce additional inspection parameters on GTP traffic. The gtp-map command lets you
specify a set of such parameters. When you enable GTP inspection with the inspect gtp command, you
have the option of specifying a GTP map.
If you do not specify a map with the inspect gtp command, the FWSM uses the default GTP map, which
is preconfigured with the following default values:
•
request-queue 200
•
timeout gsn 0:30:00
•
timeout pdp-context 0:30:00
•
timeout request 0:01:00
•
timeout signaling 0:30:00
•
timeout tunnel 0:01:00
•
tunnel-limit 500
Table 21-4 summarizes the commands that you use to configure GTP inspection parameters. These
commands are available in GTP map configuration mode. For the detailed syntax of each command, see
the applicable command page in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall
Services Module Command Reference.
Table 21-4
GTP Map Configuration Commands
Command
Description
description
Specifies the GTP configuration map description.
drop
Specifies the message ID, APN, or GTP version to drop.
mcc
Specifies the three-digit Mobile Country Code (000 - 999).
One-digit or two-digit entries will be prefixes with 0s.
message-length
Specifies the message length min and max.
permit errors
Permits packets with errors or different GTP versions.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-36
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
GTP Inspection
Table 21-4
GTP Map Configuration Commands
Command
Description
permit response
Specifies an object group allowed to receive responses from another
object group.
request-queue
Specifies the maximum requests allowed in the queue.
timeout (gtp-map)
Specifies the idle timeout for the GSN, PDP context, requests,
signaling connections, and tunnels.
tunnel-limit
Specifies the maximum number of tunnels allowed.
Enabling and Configuring GTP Inspection
GTP application inspection is disabled by default, so you need to complete the procedures described in
this section to enable GTP inspection.
Note
GTP inspection requires a special license. If you enter GTP-related commands on a FWSM without the
required license, the FWSM displays an error message.
To enable or change GTP configuration, perform the following steps:
Step 1
Define an access list with ACEs that identify the ports required for GTP traffic. The standard ports are
UDP ports 2123 and 3386. To create the access list, use the access-list extended command once for each
ACE, as follows.
hostname(config)# access-list acl-name permit {udp | tcp} any any eq port
where acl-name is the name you assign to the access list and port is the GTP port that the ACE identifies.
Step 2
Create a class map or modify an existing class map to identify GTP traffic. Use the class-map command
to do so, as follows.
hostname(config)# class-map class_map_name
hostname(config-cmap)#
where class_map_name is the name of the traffic class. When you enter the class-map command, the
CLI enters class map configuration mode.
Step 3
Use a match access-list command to identify GTP traffic with the access list you created in Step 1.
hostname(config-cmap)# match access-list acl-name
Step 4
(Optional) If you want to enforce additional parameters on GTP traffic, create and configure a GTP map.
For more information about GTP maps and the default values enforced if you do not specify GTP map,
see “GTP Maps and Commands” section on page 21-36. To create and configure a GTP map, perform
the following steps.
a.
Create a GTP map that will contain the additional parameters of GTP inspection. Use the gtp-map
command to do so, as follows.
hostname(config-cmap)# gtp-map map_name
hostname(config-gtp-map)#
where map_name is the name of the GTP map. The CLI enters GTP map configuration mode.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-37
Chapter 21
Applying Application Layer Protocol Inspection
GTP Inspection
b.
Step 5
Configure GTP inspection parameters. To do so, use the GTP map configuration mode commands
that you want to enforce. For a list of commands, see Table 21-4.
Create a policy map or modify an existing policy map that you want to use to apply the GTP inspection
engine to GTP traffic. To do so, use the policy-map command, as follows.
hostname(config-cmap)# policy-map policy_map_name
hostname(config-pmap)#
where policy_map_name is the name of the policy map. The CLI enters the policy map configuration
mode and the prompt changes accordingly.
Step 6
Specify the class map, created in Step 2, that identifies the GTP traffic. Use the class command to do so,
as follows.
hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)#
where class_map_name is the name of the class map you created in Step 2. The CLI enters the policy
map class configuration mode and the prompt changes accordingly.
Step 7
Enable GTP application inspection. To do so, use the inspect gtp command, as follows:
hostname(config-pmap-c)# inspect gtp [map_name]
hostname(config-pmap-c)#
where map_name is the GTP map that you may have created in optional Step 4.
Step 8
Use the service-policy command to apply the policy map globally or to a specific interface, as follows:
hostname(config-pmap-c)# service-policy policy_map_name [global | interface interface_ID]
hostname(config)#
where policy_map_name is the policy map you configured in Step 5. If you want to apply the policy map
to traffic on all the interfaces, use the global option. If you want to apply the policy map to traffic on a
specific interface, use the interface interface_ID option, where interface_ID is the name assigned to the
interface with the nameif command.
The FWSM begins inspecting GTP traffic, as specified.
Example 21-6 shows how to use access lists to identify GTP traffic, define a GTP map, define a policy,
and apply the policy to the outside interface.
Example 21-6 Enabling and Configuring GTP Inspection
hostname(config)# access-list gtp_acl permit udp any any eq 3386
hostname(config)# access-list gtp_acl permit udp any any eq 2123
hostname(config)# class-map gtp-traffic
hostname(config-cmap)# match access-list gtp_acl
hostname(config-cmap)# gtp-map sample_map
hostname(config-gtp-map)# request-queue 300
hostname(config-gtp-map)# permit mcc 111 mnc 222
hostname(config-gtp-map)# message-length min 20 max 300
hostname(config-gtp-map)# drop message 20
hostname(config-gtp-map)# tunnel-limit 10000
hostname(config)# policy-map sample_policy
hostname(config-pmap)# class gtp-traffic
hostname(config-pmap-c)# inspect gtp sample_map
hostname(config)# service-policy sample_policy outside
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-38
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
GTP Inspection
Verifying and Monitoring GTP Inspection
To display GTP configuration, enter the show service-policy inspect gtp command in privileged EXEC
mode. For the detailed syntax for this command, see the command page in the Catalyst 6500 Series
Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.
Use the show service-policy inspect gtp statistics command to show the statistics for GTP inspection.
The following is sample output from the show service-policy inspect gtp statistics command.
hostname# show service-policy inspect gtp statistics
GPRS GTP Statistics:
version_not_support
0
msg_too_short
unknown_msg
0
unexpected_sig_msg
unexpected_data_msg
0
ie_duplicated
mandatory_ie_missing
0
mandatory_ie_incorrect
optional_ie_incorrect
0
ie_unknown
ie_out_of_order
0
ie_unexpected
total_forwarded
0
total_dropped
signalling_msg_dropped
0
data_msg_dropped
signalling_msg_forwarded
0
data_msg_forwarded
total created_pdp
0
total deleted_pdp
total created_pdpmcb
0
total deleted_pdpmcb
pdp_non_existent
0
0
0
0
0
0
0
0
0
0
0
0
You can use the vertical bar (|) to filter the display. Type ?| for more display filtering options.
Use the show service-policy inspect gtp pdp-context command to display PDP context-related
information. The following is sample output from the show service-policy inspect gtp pdp-context
command.
hostname# show service-policy inspect gtp pdp-context detail
1 in use, 1 most used, timeout 0:00:00
Version TID
v1
1234567890123425
MS Addr
10.0.1.1
user_name (IMSI): 214365870921435
primary pdp: Y
sgsn_addr_signal:
10.0.0.2
ggsn_addr_signal:
10.1.1.1
sgsn control teid:
0x000001d1
ggsn control teid:
0x6306ffa0
seq_tpdu_up:
0
signal_sequence:
0
upstream_signal_flow:
0
downstream_signal_flow:
0
RAupdate_flow:
0
SGSN Addr
Idle
10.0.0.2 0:00:13
MS address:
nsapi: 2
sgsn_addr_data:
ggsn_addr_data:
sgsn data teid:
ggsn data teid:
seq_tpdu_down:
APN
gprs.example.com
10.5.1.1
10.0.0.2
10.1.1.1
0x000001d3
0x6305f9fc
0
upstream_data_flow:
downstream_data_flow:
0
0
The PDP context is identified by the tunnel ID, which is a combination of the values for IMSI and
NSAPI. A GTP tunnel is defined by two associated PDP contexts in different GSN nodes and is
identified with a Tunnel ID. A GTP tunnel is necessary to forward packets between an external packet
data network and a MS user.
You can use the vertical bar (|) to filter the display, as in the following example:
hostname# show service-policy gtp statistics | grep gsn
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-39
Chapter 21
Applying Application Layer Protocol Inspection
GTP Inspection
GGSN Load Balancing
GGSN load balancing (GSN pooling) allows any GSN the belongs to a GSN pool to respond to an SGSN
request to achieve load balancing on the GGSN. To enable support for GNS pooling, use the permit
response command.
If the security appliance performs GTP inspection, by default the security appliance drops GTP
responses from GSNs that were not specified in the GTP request. This situation occurs when you use
load balancing among a pool of GSNs to provide efficiency and scalability of GPRS.
You can enable support for GSN pooling by using the permit response command. This command
configures the security appliance to allow responses from any of a designated set of GSNs, regardless of
the GSN to which a GTP request was sent. You identify the pool of load-balancing GSNs as a network
object. Likewise, you identify the SGSN as a network object. If the GSN responding belongs to the same
object group as the GSN that the GTP request was sent to, and if the SGSN is in an object group that the
responding GSN is permitted to send a GTP response to, the security appliance permits the response.
To create an object to represent the pool of load-balancing GSNs, perform the following steps:
Step 1
Define a new network object group representing the pool of load-balancing GSNs. To do so, use the
object-group command.
hostname(config)# object-group network GSN-pool-name
hostname(config)#
where GSN-pool-name is the object group name for GGSNs.
Step 2
Specify the load-balancing GSNs using the network-object command. You can configure one
network-object command per GSN using the host keyword. You can also specify a network containing
GSNs that perform load balancing.
hostname(config)# network-object host IP-address
hostname(config)#
where IP-address is the IP address of the host.
Step 3
Create an object to represent the SGSN that the load-balancing GSNs are permitted to respond to. To do
so, use the object-group command.
a.
Define an SGSN network object group that sends GTP requests to the GSN pool. To do so, use the
object-group command.
hostname(config)# object-group network SGSN-name
hostname(config)#
where SGSN-name is the SGSN network object group name.
b.
Identify the SGSN. To do so, use the network-object command:
hostname(config)# network-object host IP-address
hostname(config)#
where IP-address is the SGSN.
Step 4
Allow GTP responses, from any GSN in the network object representing the GSN pool, to the network
object representing the SGSN. To do so, use the gtp-map and permit responses commands.
hostname(config)# gtp-map map_name
hostname(config-gtp-map)# permit response to-object-group SGSN-name from-object-group
GSN-pool-name
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-40
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
GTP Inspection
where map-name is the name of the gtp map, SGSN-name is the name of the SGSN created in Step 3,
and GSN-pool-name is the name of the GSN pool created in Step 1.
The following example shows how to support GSN pooling by defining network objects for the GSN
pool and the SGSN. An entire Class C network is defined as the GSN pool in this case, but you can
identify multiple individual IP addresses as well. The GTP map is configured to permit responses from
the GSN pool to the SGSN.
Example 21-7 Enabling and Configuring GGSN Load Balancing
hostname(config)# object-group network GGSNS
hostname(config-network)# network-object 10.1.1.0 255.255.255.0
hostname(config)# object-group network SGSNS
hostname(config-network)# network-object hjost 192.168.1.1
hostname(config)# gtp-map GTPMAP
hostname(config-gtp-map)# permit response to-object-group SGSNS from-object-group GGSNS
For additional GGSN load balancing information and configurations, refer to the Cisco GGSN Release
7.0 Configuration Guide and the Cisco MultiProcessor WAN Module User Guide.
GTP Sample Configuration
Figure 21-7 shows a sample GTP inspection configuration.
Figure 21-7
GTP Inspection Setup
Catalyst 6500
FWSM module
MWAM module
IOS SLB
GGSN 1
10.1.1.2
GGSN 2
10.2.1.29
10.1.1.3
SLB
SGSN
209.1.1.41/24 209.1.1.31/24
10.3.1.41/24
MSFC
FWSM
outside
inside
Slot 4
MWAM
GGSN 3
10.1.1.4
Slot 9
SGSN
simulator
10.1.1.5
191992
GGSN 4
Sample configuration of SLB (IOS SLB, MSFC used), GGSN (MWAM module used) and FWSM. SLB
and MWAM configuration on supervisor/MSFC.
The MWAM is a Cisco IOS application module that you can install in the Cisco Catalyst 6500 Series
switch. Each MWAM contains three processor complexes, with two CPUs each and Each CPU can be
used to run an independent IOS image. Several Cisco mobile wireless applications are supported. This
sample configuration runs Cisco Gateway GPRS Support (General Packet Radio Service Packet Gateway
application).
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-41
Chapter 21
Applying Application Layer Protocol Inspection
GTP Inspection
See the following documentation for installation and configuration of the MWAM module on the Cisco
Catalyst 6500 Series switch.
http://www.cisco.com/en/US/docs/wireless/mwam/user/guide/install.html
The following configuration explains the config requirements for MWAM module as well as how to
configure a gateway GPRS support node (GGSN) to support load balancing functions using the Cisco
IOS software Server Load Balancing (SLB) feature.
See the following documentation for configuration of load balancing on GGSNs:
http://www.cisco.com/en/US/docs/ios/12_4/12_4y/12_4_22ye/ggsn9_0/cfg/ggsnslb.html
As per Figure 21-6, two GGSNs (GGSN1 and GGSN2) are configured on the MWAM module:
firewall multiple-vlan-interfaces
firewall module 4 vlan-group 1
firewall module 10 vlan-group 1
firewall vlan-group 1 3-40,44,84,115,119,172,200-202,400-500,800-900
mwam module 9 port 1 allowed-vlan 1,3-40,44,84,172,200-202,400-500,800-900
mwam module 9 port 2 allowed-vlan 1,3-40,44,84,172,200-202,400-500,800-900
mwam module 9 port 3 allowed-vlan 1,3-40,44,84,172,200-202,400-500,800-900
ip subnet-zero
!
no ip domain-lookup
ip slb timers gtp gsn 40000
ip slb probe PING ping
!
ip slb serverfarm GGSN-POOL
nat server
probe PING
!
real 10.4.1.32
weight 1
inservice
!
real 10.4.1.33
weight 1
inservice
!
ip slb serverfarm TGGSN-POOL
nat server
probe PING
!
real 10.4.1.34
faildetect numconns 2
inservice
!
real 10.4.1.35
faildetect numconns 2
inservice
!
ip slb vserver GTP-V0
virtual 10.2.1.29 udp 3386 service gtp
serverfarm GGSN-POOL
inservice
!
ip slb vserver GTP-V1
virtual 10.2.1.29 udp 2123 service gtp
serverfarm GGSN-POOL
inservice
!
ip slb vserver TGTP-V0
virtual 10.2.1.28 udp 3386 service gtp
serverfarm TGGSN-POOL
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-42
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
GTP Inspection
inservice
!
ip slb vserver TGTP-V1
virtual 10.2.1.28 udp 2123 service gtp
serverfarm TGGSN-POOL
inservice
!
ip slb dfp password 7 13061E010803
agent 10.1.1.2 1111 30 0 10
agent 10.1.1.3 1111 30 0 10
agent 10.1.1.4 1111 30 0 10
agent 10.1.1.5 1111 30 0 10
!
GGSN1 is configured as follows:
hostname# show running config
Building configuration...
Current configuration : 1460 bytes
!
! Last configuration change at 21:33:19 UTC Wed Dec 13 2006
! NVRAM config last updated at 01:54:40 UTC Sat Nov 18 2006
!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
service gprs ggsn
!
hostname GGSN2ADCTX
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
!
resource policy
!
ip subnet-zero
ip dfp agent gprs
port 1111
password cisco
inservice
!
ip cef
no ip domain lookup
ip domain name cisco.com
no ip dhcp use vrf connected
!
interface GigabitEthernet0/0
no ip address
!
interface GigabitEthernet0/0.1
!
interface GigabitEthernet0/0.8
encapsulation dot1Q 8
ip address 10.1.1.2 255.255.255.0
no snmp trap link-status
!
interface Virtual-Template1
ip address 10.4.1.32 255.255.255.0
encapsulation gtp
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-43
Chapter 21
Applying Application Layer Protocol Inspection
GTP Inspection
gprs access-point-list gtp-test
!
ip local pool localpool1 10.1.1.101 10.1.1.110
ip local pool localpool11 10.7.3.3 10.7.3.255
ip classless
ip route 0.0.0.0 0.0.0.0 10.1.1.1
!
no ip http server
!
gprs access-point-list gtp-test
access-point 1
access-point-name sj-gtp.cisco.com
ip-address-pool local localpool11
!
control-plane
!
line con 0
line vty 0
no login
line vty 1 4
login
line vty 5 15
login
!
end
GGSN3 is configured as follows:
hostname# show running-config
Building configuration...
Current configuration : 1533 bytes
!
! Last configuration change at 21:33:47 UTC Wed Dec 13 2006
! NVRAM config last updated at 01:56:07 UTC Sat Nov 18 2006
!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
service gprs ggsn
!
hostname GGSN3ADCTX
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
!
resource policy
!
ip subnet-zero
ip dfp agent gprs
port 1111
password cisco
inservice
!
ip cef
no ip domain lookup
ip domain name cisco.com
no ip dhcp use vrf connected
!
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-44
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
GTP Inspection
interface GigabitEthernet0/0
no ip address
!
interface GigabitEthernet0/0.3
!
interface GigabitEthernet0/0.8
encapsulation dot1Q 8
ip address 10.4.1.3 255.255.255.0
no snmp trap link-status
!
interface Virtual-Template1
ip address 10.1.1.33 255.255.255.0
encapsulation gtp
gprs access-point-list gtp-test
!
ip local pool localpool2 10.1.1.111 10.1.1.120
ip local pool localpool22 10.8.4.4 10.8.4.254
ip classless
ip route 0.0.0.0 0.0.0.0 10.1.1.1
!
no ip http server
!
gprs maximum-pdp-context-allowed 50000
gprs qos default-response requested
gprs access-point-list gtp-test
access-point 1
access-point-name sj-gtp.cisco.com
ip-address-pool local localpool22
!
control-plane
!
line con 0
line vty 0
no login
line vty 1 4
login
line vty 5 15
login
!
!
end
The FWSM configuration for load balancing the GGSNs is as follows:
FWSM Version 3.2(0)45 <context>
!
hostname admin
domain-name cisco.com
enable password 9jNfZuG3TC5tCVH0 encrypted
no names
!
interface Vlan172
nameif mgmt
security-level 100
ip address 172.21.64.35 255.255.255.128 standby 172.21.64.36
!
interface Vlan5
nameif inside
security-level 100
ip address 10.2.1.41 255.255.255.0 standby 10.2.1.40
!
interface Vlan9
nameif outside
security-level 0
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-45
Chapter 21
Applying Application Layer Protocol Inspection
GTP Inspection
ip address 209.165.201.41 255.255.255.0 standby 209.165.201.40
!
passwd 2KFQnbNIdI.2KYOU encrypted
same-security-traffic permit inter-interface
object-group network GGSNS ================================configured object group to
define GGSNs
network-object host 10.4.1.32
network-object host 10.4.1.33
object-group network SGSNS =================================configured object group to
define SGSNs
network-object host 10.5.1.1
object-group network servers
network-object 10.2.1.0 255.255.255.0
network-object host 10.6.1.25
network-object host 10.6.1.26
network-object host 10.6.1.27
network-object host 10.4.1.32
network-object host 10.4.1.33
object-group network clients
network-object 10.6.1.0 255.255.255.0
network-object host 10.5.1.1
access-list gtpacl extended permit udp any any eq 2123
access-list gtpacl extended permit udp any any eq 3386
access-list gtpacl extended permit icmp any any
access-list gtpacl extended permit udp any any
access-list gtpacl extended permit tcp any any eq www
access-list gtpacl extended permit tcp any any eq ftp
access-list gtpacl extended permit tcp any any eq telnet
access-list gtpacl extended permit tcp any any eq ssh
access-list 112 extended permit tcp object-group servers object-group clients eq www
access-list 112 extended permit tcp object-group servers object-group clients eq https
access-list 112 extended permit tcp object-group servers object-group clients eq ftp
access-list 112 extended permit tcp object-group servers object-group clients eq telnet
access-list 112 extended permit udp object-group servers object-group clients eq 3386
access-list 112 extended permit udp object-group servers object-group clients eq 2123
access-list 112 extended permit tcp object-group servers object-group clients eq ssh
!
gtp-map GTPMAP ============================================================configured GTP
map to include the permit response cli
permit response to-object-group SGSNS from-object-group GGSNS
permit errors
!
pager lines 24
logging enable
logging timestamp
logging buffered debugging
mtu mgmt 1500
mtu inside 1500
mtu outside 1500
monitor-interface inside
monitor-interface outside
icmp permit any mgmt
icmp permit any inside
icmp permit any outside
asdm history enable
arp timeout 14400
nat-control
no xlate-bypass
static (outside,inside) 10.5.1.1 10.5.1.1 netmask 255.255.255.255
static (inside,outside) 10.4.1.31 10.4.1.31 netmask 255.255.255.255
static (inside,outside) 10.4.1.32 10.4.1.32 netmask 255.255.255.255
static (inside,outside) 10.4.1.33 10.4.1.33 netmask 255.255.255.255
access-group OO in interface mgmt
access-group 111 in interface outside per-user-override
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-46
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
H.323 Inspection
route inside 10.4.1.32 255.255.255.255 10.1.1.2 1
route inside 10.4.1.33 255.255.255.255 10.1.1.3 1
route outside 10.5.1.1 255.255.255.255 209.165.201.31 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00
timeout mgcp-pat 0:05:00 sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect
0:02:00
timeout uauth 0:05:00 absolute
username cisco password 3USUcOPFUiMCO4Jk encrypted
no snmp-server location
no snmp-server contact
telnet timeout 5
ssh 171.69.42.198 255.255.255.255 mgmt
ssh timeout 5
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map global_policy
class inspection_default
inspect dns maximum-length 512
inspect ftp
inspect h323 h225
inspect h323 ras
inspect http
inspect netbios
inspect rsh
inspect rtsp
inspect skinny
inspect smtp
inspect sunrpc
inspect tftp
inspect xdmcp
inspect icmp
inspect gtp GTPMAP =========================================attached the GTP map to gtp
inspection in service policy
!
service-policy global_policy global
Cryptochecksum:3b1c3373e908cb9163d9aa1387478fa4
: end
H.323 Inspection
This section describes how to enable H.323 application inspection and change the default port
configuration. This section includes the following topics:
•
H.323 Inspection Overview, page 21-48
•
How H.323 Works, page 21-48
•
Limitations and Restrictions, page 21-49
•
Enabling and Configuring H.323 Inspection, page 21-51
•
Topologies Requiring H.225 Configuration, page 21-50
•
H.225 Map Commands, page 21-50
•
Enabling and Configuring H.323 Inspection, page 21-51
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-47
Chapter 21
Applying Application Layer Protocol Inspection
H.323 Inspection
•
Configuring H.323 and H.225 Timeout Values, page 21-53
•
Verifying and Monitoring H.323 Inspection, page 21-53
•
H.323 GUP Support, page 21-55
•
H.323 Sample Configuration, page 21-57
H.323 Inspection Overview
H.323 inspection provides support for H.323 compliant applications such as Cisco CallManager and
VocalTec Gatekeeper. H.323 is a suite of protocols defined by the International Telecommunication
Union for multimedia conferences over LANs. The FWSM supports H.323 through Version 4, including
the H.323 v3 feature Multiple Calls on One Call Signaling Channel. The H.323 Gatekeeper Update
Protocol inspection is also supported. Because GUP is a Cisco proprietary protocol, H.323-GUP
inspection is relevant only in topologies where the Cisco Gatekeeper devices are employed.
With H.323 inspection enabled, the FWSM supports multiple calls on the same call signaling channel, a
feature introduced with H.323 Version 3. This feature reduces call setup time and reduces the use of ports
on the FWSM.
The two major functions of H.323 inspection are as follows:
•
NAT the necessary embedded IPv4 addresses in the H.225 and H.245 messages. Because H.323
messages are encoded in PER encoding format, the FWSM uses an ASN.1 decoder to decode the
H.323 messages.
•
Dynamically allocate the negotiated H.245 and RTP/RTCP connections.
How H.323 Works
The H.323 protocols collectively may use up to two TCP connection and four to six UDP connections.
FastConnect uses only one TCP connection. RAS uses a single UDP connection for registration,
admissions, and status.
An H.323 client may initially establish a TCP connection to an H.323 server using TCP port 1720 to
request Q.931 call setup. As part of the call setup process, the H.323 terminal supplies a port number to
the client to use for an H.245 TCP connection. In environments where H.323 gatekeeper is in use, the
initial packet is transmitted using UDP.
H.323 inspection monitors the Q.931 TCP connection to determine the H.245 port number. If the H.323
terminals are not using FastConnect, the FWSM dynamically allocates the H.245 connection based on
the inspection of the H.225 messages.
Within each H.245 message, the H.323 endpoints exchange port numbers that are used for subsequent
UDP data streams. H.323 inspection inspects the H.245 messages to identify these ports and dynamically
creates connections for the media exchange. RTP uses the negotiated port number, while RTCP uses the
next higher port number.
The H.323 control channel handles H.225 and H.245 and H.323 RAS. H.323 inspection uses the
following ports.
•
UDP port 1718—Gate Keeper Discovery
•
UDP port 1719—RAS
•
TCP port 1720—Control Port
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-48
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
H.323 Inspection
You must permit traffic for the well-known H.323 port 1720 for the H.225 call signaling; however, the
H.245 signaling ports are negotiated between the endpoints in the H.225 signaling. When an H.323
gatekeeper is used, the FWSM opens an H.225 connection based on inspection of the ACF message.
After inspecting the H.225 messages, the FWSM opens the H.245 channel and then inspects traffic sent
over the H.245 channel as well. All H.245 messages passing through the FWSM undergo H.245
application inspection, which NATs embedded IP addresses and opens the media channels negotiated in
H.245 messages.
The H.323 ITU standard requires that a TPKT header, defining the length of the message, precede the
H.225 and H.245, before being passed on to the reliable connection. Because the TPKT header does not
necessarily need to be sent in the same TCP packet as H.225 and H.245 messages, the FWSM must
remember the TPKT length to process and decode the messages properly. For each connection, the
FWSM keeps a record that contains the TPKT length for the next expected message.
If the FWSM needs to perform NAT on IP addresses in messages, it changes the checksum, the UUIE
length, and the TPKT, if it is included in the TCP packet with the H.225 message. If the TPKT is sent in
a separate TCP packet, the FWSM proxy ACKs that TPKT and appends a new TPKT to the H.245
message with the new length.
Note
The FWSM does not support TCP options in the Proxy ACK for the TPKT.
Each UDP connection with a packet going through H.323 inspection is marked as an H.323 connection
and times out with the H.323 timeout as configured with the timeout command.
Limitations and Restrictions
Some of the known issues and limitations of H.323 application inspection are as follows:
•
Static PAT may not properly translate IP addresses embedded in optional fields within H.323
messages. If you experience this kind of problem, do not use static PAT with H.323.
•
When a NetMeeting client registers with an H.323 gatekeeper and tries to call an H.323 gateway that
is also registered with the H.323 gatekeeper, the connection is established but no voice is heard in
either direction. This problem is unrelated to the FWSM.
•
If you configure a network static address where the network static address is the same as a
third-party netmask and address, then any outbound H.323 connection fails.
•
Dynamic NAT (PAT) is not supported for H.323-GUP inspection.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-49
Chapter 21
Applying Application Layer Protocol Inspection
H.323 Inspection
Topologies Requiring H.225 Configuration
Some additional H.225 configuration may be required in a topology where call control happens between
H.323 endpoints connecting through an FWSM (see Figure 21-8).
Figure 21-8
Topology Requiring H.225 Configuration
PGW
EISUP
IP Core
HSI
10.10.15.11
10.10.212.1
H.323
10.10.212.0
Cisco Catalyst 6000
FWSM 3.1
NAT enabled
H.245
10.10.25.5
M
CCM IPCC
M
CME
133000
10.3.6.1
In this topology, call signaling occurs between the Cisco CallManager and the HSI on one side of the
FWSM and between the HSI and the Cisco CallManager endpoint on the other side. Afterwards, call
control happens directly between the Cisco CallManager and the Cisco CallManager endpoint. When
the HSI and one endpoint is on a network protected by the FWSM and the other endpoint is on another
network, the call control may not go through without additional H.225 configuration.
The FWSM is not aware of the existence of the Cisco CallManager in this topology. With only the packet
flows that happen through the security appliance, the FWSM cannot open a proper pinhole to allow such
a call to be successful. For this reason, some additional H.225 configuration is required in this scenario.
To provide the necessary configuration, you identify an HSI and its associated endpoints within an HSI
group. After this configuration is completed, when the FWSM sees the HSI as one of the communicating
hosts in an H.225 connection, it opens H.245 holes between the endpoints in the HSI group. The actual
H.245 connection will match one of these pinholes and will go through properly.
H.225 Map Commands
The H.225 map allows the FWSM to open dynamic, port-specific pinholes for an H.245 connection when
an HSI is involved in H.225 call-signalling. The H.225 map provides information about the HSI and its
associated endpoints, which is required to establish this connection without compromising the security
of the network protected by the FWSM.
The h225-map command lets you create an H.225 map. One H225 map can contain a maximum of five
HSI groups. Table 21-5 lists the commands available in H.225 map configuration mode.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-50
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
H.323 Inspection
Table 21-5
H.225 Configuration Commands
Command
Configuration mode
Description
hsi-group
H.225 map
configuration mode
Defines an HSI group and enables HSI group configuration
mode. Each HSI group can contain a maximum of ten
endpoints.
hsi
HSI group
configuration mode
Identifies the HSI.
endpoint
HSI group
configuration mode
Identifies one or more endpoints within the HSI group.
Enabling and Configuring H.323 Inspection
H.323 inspection is enabled by default.
To enable H.323 inspection, including the optional use of an H.225 map, perform the following steps:
Step 1
To define an access list with ACEs that identify the ports required for H.323 traffic, enter the following
command for each ACE:
hostname(config)# access-list acl-name permit {udp | tcp} any any eq port
where acl-name is the name you assign to the access list and port is the H.323 port that the ACE
identifies.
The standard ports are UDP ports 1718 and 1719 and TCP port 1720.
Step 2
Create a class map or modify an existing class map to identify H.323 traffic. Use the class-map
command to do so, as follows.
hostname(config)# class-map class_map_name
hostname(config-cmap)#
where class_map_name is the name of the traffic class. When you enter the class-map command, the
CLI enters class map configuration mode.
Step 3
Use a match access-list command to identify H.323 traffic with the access list you created in Step 1.
hostname(config-cmap)# match access-list acl-name
Step 4
(Optional) If required by your network topology, configure an H.225 map. For more information about
whether your network requires an H.225 map, see the “Topologies Requiring H.225 Configuration”
section on page 21-50. To create and configure an H.225 map, perform the following steps.
a.
Create an H.225 map.
hostname(config)# h225-map map_name
hostname(config-h225-map)#
The system enters H.225 map configuration mode and the CLI prompt changes accordingly.
b.
Identify an HSI group. To do so, use the hsi-group command, as follows.
hostname(config-h225-map)# hsi-group group_ID
hostname(config-h225-map-hsi-grp)#
where group_ID is a number, from 0 to 2147483647, that identifies the HSI group.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-51
Chapter 21
Applying Application Layer Protocol Inspection
H.323 Inspection
Note
The maximum number of HSI groups allowed per H.225 map is five.
The system enters HSI group configuration mode and the CLI prompt changes accordingly.
c.
Define an HSI for the group.
hostname(config-h225-map-hsi-grp)# hsi ip_address
where ip_address is the addresses of the HSI.
d.
Define up to ten endpoints. To do so, use the endpoint command once per endpoint, as follows.
hostname(config-h225-map-hsi-grp)# endpoint ip_address interface
where interface with the interface on the FWSM that is connected to the endpoint and ip_address is
the addresses of the endpoint.
e.
Step 5
If you need to create additional HSI groups, repeat step b. through d.
Create a policy map or modify an existing policy map that you want to use to apply the H.323 inspection
engine to H.323 traffic. To do so, use the policy-map command, as follows.
hostname(config-cmap)# policy-map policy_map_name
hostname(config-pmap)#
where policy_map_name is the name of the policy map. The CLI enters the policy map configuration
mode and the prompt changes accordingly.
Step 6
Specify the class map, created in Step 2, that identifies the H.323 traffic. Use the class command to do
so, as follows.
hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)#
where class_map_name is the name of the class map you created in Step 2. The CLI enters the policy
map class configuration mode and the prompt changes accordingly.
Step 7
Enable H.323 application inspection. To do so, use the inspect h323 command, as follows.
hostname(config-pmap-c)# inspect h323 [h225 map_name]
hostname(config-pmap-c)#
where map_name is the H.225 map that you may have created in optional Step 4.
Step 8
Use the service-policy command to apply the policy map globally or to a specific interface, as follows:
hostname(config-pmap-c)# service-policy policy_map_name [global | interface interface_ID]
hostname(config)#
where policy_map_name is the policy map you configured in Step 5. If you want to apply the policy map
to traffic on all the interfaces, use the global option. If you want to apply the policy map to traffic on a
specific interface, use the interface interface_ID option, where interface_ID is the name assigned to the
interface with the nameif command.
The FWSM begins inspecting H.323 traffic, as specified.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-52
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
H.323 Inspection
Example 21-8 Configuring H.323 Inspection without an H.225 Map
You enable the H.323 inspection engine as shown in the following example, which creates a class map
to match H.323 traffic on the default port (1720). The service policy is then applied to the outside
interface.
hostname(config)# access-list h323_acl permit udp any
hostname(config)# access-list h323_acl permit udp any
hostname(config)# access-list h323_acl permit tcp any
hostname(config)# class-map h323-traffic
hostname(config-cmap)# match access-list h323_acl
hostname(config-cmap)# policy-map sample_policy
hostname(config-pmap)# class h323_port
hostname(config-pmap-c)# inspect h323 ras
hostname(config-pmap-c)# inspect h323 h225
hostname(config-pmap-c)# service-policy sample_policy
hostname(config)#
any eq 1718
any eq 1719
any eq 1720
interface outside
Example 21-9 includes an H.225 map with two HSI groups, as part of the overall H.323 configuration.
Example 21-9 Configuring H.323 Inspection with an H.225 Map
hostname(config)# access-list h323_acl permit udp any any eq 1718
hostname(config)# access-list h323_acl permit udp any any eq 1719
hostname(config)# access-list h323_acl permit tcp any any eq 1720
hostname(config)# class-map h323-traffic
hostname(config-cmap)# match access-list h323_acl
hostname(config-cmap)# h225-map sample_map
hostname(config-h225-map)# hsi-group 1
hostname(config-h225-map-hsi-grp)# hsi 10.10.15.11
hostname(config-h225-map-hsi-grp)# endpoint 10.3.6.1 inside
hostname(config-h225-map-hsi-grp)# endpoint 10.10.25.5 outside
hostname(config-h225-map-hsi-grp)# policy-map sample_policy
hostname(config-pmap)# class h323_port
hostname(config-pmap-c)# inspect h323 ras
hostname(config-pmap-c)# inspect h323 h225 sample_map
hostname(config-pmap-c)# service-policy sample_policy interface outside
hostname(config)#
Configuring H.323 and H.225 Timeout Values
To configure the idle time after which an H.225 signalling connection is closed, use the timeout h225
command. The default for H.225 timeout is one hour.
To configure the idle time after which an H.323 control connection is closed, use the timeout h323
command. The default is five minutes.
Verifying and Monitoring H.323 Inspection
This section describes how to display information about H.323 sessions. This section includes the
following topics:
•
Monitoring H.225 Sessions, page 21-54
•
Monitoring H.245 Sessions, page 21-54
•
Monitoring H.323 RAS Sessions, page 21-55
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-53
Chapter 21
Applying Application Layer Protocol Inspection
H.323 Inspection
Monitoring H.225 Sessions
The show h225 command displays information for H.225 sessions established across the FWSM. Along
with the debug h323 h225 event, debug h323 h245 event, and show local-host commands, this
command is used for troubleshooting H.323 inspection engine issues.
Before entering the show h225, show h245, or show h323-ras commands, we recommend that you
configure the pager command. If there are a lot of session records and the pager command is not
configured, it may take a while for the show command output to reach its end. If there is an abnormally
large number of connections, check that the sessions are timing out based on the default timeout values
or the values set by you. If they are not, then there is a problem that needs to be investigated.
The following is sample output from the show h225 command:
hostname# show h225
Total H.323 Calls: 1
1 Concurrent Call(s) for
Local:
10.130.56.3/1040
1. CRV 9861
Local:
10.130.56.3/1040
0 Concurrent Call(s) for
Local:
10.130.56.4/1050
Foreign: 172.30.254.203/1720
Foreign: 172.30.254.203/1720
Foreign: 172.30.254.205/1720
This output indicates that there is currently 1 active H.323 call going through the FWSM between the
local endpoint 10.130.56.3 and foreign host 172.30.254.203, and for these particular endpoints, there is
1 concurrent call between them, with a CRV for that call of 9861.
For the local endpoint 10.130.56.4 and foreign host 172.30.254.205, there are 0 concurrent calls. This
means that there is no active call between the endpoints even though the H.225 session still exists. This
could happen if, at the time of the show h225 command, the call has already ended but the H.225 session
has not yet been deleted. Alternately, it could mean that the two endpoints still have a TCP connection
opened between them because they set “maintainConnection” to TRUE, so the session is kept open until
they set it to FALSE again, or until the session times out based on the H.225 timeout value in your
configuration.
Monitoring H.245 Sessions
The show h245 command displays information for H.245 sessions established across the FWSM by
endpoints using slow start. Slow start is when the two endpoints of a call open another TCP control
channel for H.245. Fast start is where the H.245 messages are exchanged as part of the H.225 messages
on the H.225 control channel.) Along with the debug h323 h245 event, debug h323 h225 event, and
show local-host commands, this command is used for troubleshooting H.323 inspection engine issues.
The following is sample output from the show h245 command:
hostname# show h245
Total: 1
LOCAL
TPKT
FOREIGN
TPKT
1
10.130.56.3/1041
0
172.30.254.203/1245
0
MEDIA: LCN 258 Foreign 172.30.254.203 RTP 49608 RTCP 49609
Local
10.130.56.3 RTP 49608 RTCP 49609
MEDIA: LCN 259 Foreign 172.30.254.203 RTP 49606 RTCP 49607
Local
10.130.56.3 RTP 49606 RTCP 49607
There is currently one H.245 control session active across the FWSM. The local endpoint is 10.130.56.3,
and we are expecting the next packet from this endpoint to have a TPKT header because the TPKT value
is 0. The TKTP header is a 4-byte header preceding each H.225/H.245 message. It gives the length of
the message, including the 4-byte header. The foreign host endpoint is 172.30.254.203, and we are
expecting the next packet from this endpoint to have a TPKT header because the TPKT value is 0.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-54
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
H.323 Inspection
The media negotiated between these endpoints have an LCN of 258 with the foreign RTP IP address/port
pair of 172.30.254.203/49608 and an RTCP IP address/port of 172.30.254.203/49609 with a local RTP
IP address/port pair of 10.130.56.3/49608 and an RTCP port of 49609.
The second LCN of 259 has a foreign RTP IP address/port pair of 172.30.254.203/49606 and an RTCP
IP address/port pair of 172.30.254.203/49607 with a local RTP IP address/port pair of
10.130.56.3/49606 and RTCP port of 49607.
Monitoring H.323 RAS Sessions
The show h323-ras command displays information for H.323 RAS sessions established across the
FWSM between a gatekeeper and its H.323 endpoint. Along with the debug h323 ras event and show
local-host commands, this command is used for troubleshooting H.323 RAS inspection engine issues.
The show h323-ras command displays connection information for troubleshooting H.323 inspection
engine issues. The following is sample output from the show h323-ras command.
hostname# show h323-ras
Total: 1
GK
Caller
172.30.254.214 10.130.56.14
This output shows that there is one active registration between the gatekeeper 172.30.254.214 and its
client 10.130.56.14.
H.323 GUP Support
The H.323-GUP feature is used for creation of the secondary channel for the H.323-GUP connection
from the H.323-RAS connection, and for translation (NAT) of the embedded addresses in the GUP
messages. It enables Gatekeepers to communicate with each other through the firewall.
You do not need to enable H.323-GUP explicitly. To utilize this feature, enable H.323-RAS inspection
with the appropriate access list (allowing UDP port 1719).
Limitations:
•
H.323-GUP inspection is relevant only in topologies where the Cisco Gatekeeper devices are
employed because GUP is a Cisco proprietary protocol.
•
Dynamic NAT and dynamic PAT are not supported in H.323 GUP inspection.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-55
Chapter 21
Applying Application Layer Protocol Inspection
H.323 Inspection
H.323 GUP Configuration
Figure 21-9 illustrates an H.323 inspection topology configured with H.323 GUP support.
Figure 21-9
H.323 Inspection Configuration with H.323 GUP Support
Inside
H.323 zone
Outside
Firewall Service Module
(FWSM)
In Gatekeeper
RAS message on UDP 1719
Gatekeeper
GUP session
vlan50
Gateway
191374
Gateway
vlan100
Analog phone
Analog phone
The following configuration applies to Figure 21-9.
firewall transparent
hostname FWSM
!
interface Vlan50
nameif inside
bridge-group 1
security-level 100
!
interface Vlan100
nameif outside
bridge-group 1
security-level 0
!
interface BVI1
ip address 10.0.0.8 255.255.255.0
!
access-list h323-gup-permit extended permit udp any any eq 1719
access-group h323-gup-permit in interface inside
access-group h323-gup-permit in interface outside
Note
RAS inspection should be turned on for interfaces through which the gatekeeper running GUP protocol
is reachable. In this example, RAS inspection is turned on for both inside and outside interfaces.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-56
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
H.323 Inspection
Outside gatekeeper configuration (GK):
gatekeeper
zone local GK cisco.com 10.0.0.6
zone cluster local gup-cluster GK
element inGK 10.0.0.7 1719
Inside gatekeeper configuration (inGK):
gatekeeper
zone local inGK cisco.com 10.0.0.7
zone cluster local gup-cluster inGK
element GK 10.0.0.6 1719
When the H.323 GUP session is established in this configuration, the following is output from the show
h323 gup command:
hostname(config)# show h323 gup
No.
1
LOCAL
inside:10.0.0.7/15970
FOREIGN
Outside:209.165.201.6/22754
The following output from the show conn command shows the secondary channel established between
the H.323 Gatekeepers and the H.323 GUP connections marked with the flag n.
hostname(config)# show conn
3 in use, 37 most used
Network Processor 1 connection
UDP out 209.165.201.6:1719 in 10.0.0.7:1719 idle 0:00:45 Bytes 672
FLAGS - H
TCP out 209.165.201.6:22754 in 10.0.0.7:15970 idle 0:00:04 Bytes 1188 FLAGS - UBIn
Network Processor 2 connections
Multicast sessions:
Network Processor 1 connection
Network Processor 2 connections
IPv6 connections:
H.323 Sample Configuration
Figure 21-10 shows a sample configuration for H.323 inspection.
4085550100
H.323 Inspection Setup
R2
R1
vlan 100
Analog
phone
Cisco 3745
H.323 Gateway
outside
209.100.100.2
inside
10.100.100.2
Firewall Service Module
(FWSM)
4085550199
vlan 50
Cisco 3745
H.323 Gateway
Analog
phone
191991
Figure 21-10
Cisco 3745
Gatekeeper
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-57
Chapter 21
Applying Application Layer Protocol Inspection
H.323 Inspection
Configuration of the IOS H.323 Gateway (Router R2) on the outside interface:
hostname(config)#hostname R2
hostname(config)#interface FastEthernet0/1
hostname(config-if)# ip address 209.165.201.1 255.0.0.0
hostname(config-if)#no shut
hostname(config-if)#exit
hostname(config)#ip route 10.0.0.0 255.0.0.0 209.165.201.2
hostname(config)#voice-port 1/0/0
hostname(config-voiceport)#no shut
hostname(config-voiceport)#exit
hostname(config)#gateway
hostname(config-gateway)#
hostname(config-gateway)#exit
hostname(config)#ip cef
hostname(config)#int f0/1
hostname(config-if)#h323-gateway voip interface
hostname(config-if)#h323-gateway voip id inGK ipaddr 10.0.0.6
hostname(config-if)#h323-gateway voip h323-id R2
Configure dial peer to forward voice calls to destination number 408555010991 using the H.323
protocol:
hostname(config)#dial-peer voice 101 voip
hostname(config-dial-peer)#destination-pattern 40855501099
hostname(config-dial-peer)#session target ras
hostname(config-dial-peer)#exit
Configure dial peer to forward voice calls to 4085550100 to voice port 1/0/0 in router R2:
hostname(config)#dial-peer voice 102 pots
hostname(config-dial-peer)#destination-pattern 4085550100
hostname(config-dial-peer)#port 1/0/0
hostname(config-dial-peer)#exit
hostname(config)#exit
Configuration of the IOS H.323 gateway (router R1) on the inside interface:
hostname(config)#hostname R1
hostname(config)#interface FastEthernet0/1
hostname(config-if)# ip address 10.100.100.1 255.0.0.0
hostname(config-if)#no shut
hostname(config-if)#ip route 209.165.201.0 255.0.0.0 10.100.100.2
hostname(config)#
hostname(config)#voice-port 3/0/0
hostname(config-voiceport)#no shut
hostname(config-voiceport)#exit
hostname(config)#gateway
hostname(config-gateway)#exit
hostname(config)#ip cef
hostname(config)#int fastethernet0/1
hostname(config-if)#h323-gateway voip interface
hostname(config-if)#h323-gateway voip id inGK ipaddr 10.0.0.6
hostname(config-if)#h323-gateway voip h323-id R1
hostname(config-if)#exit
Forward all voice calls destined to 4085550100 using the H.323 protocol:
hostname(config)#dial-peer voice 101 voip
hostname(config-dial-peer)#destination-pattern 4085550100
hostname(config-dial-peer)#session target ras
Forward all voice calls destined to 4085550199 to voice port 3/0/0:
hostname(config)#dial-peer voice 102 pots
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-58
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
H.323 Inspection
hostname(config-dial-peer)#destination-pattern 4085550199
hostname(config-dial-peer)#port 3/0/0
hostname(config-dial-peer)#^Z
Configuration of the IOS H.323 Gatekeeper (router inGK) on the inside interface:
hostname(config)#hostname inGK
hostname(config)#interface FastEthernet0/1
hostname(config-if)# ip address 10.0.0.6 255.0.0.0
hostname(config-if)#no shut
hostname(config-if)#exit
hostname(config)#gatekeeper
hostname(config-gk)#zone local inGK cisco.com 10.0.0.6
hostname(config-gk)#no shut
hostname(config)#
hostname(config)#ip route 209.165.201.0 255.0.0.0 10.100.100.2
Configuration of the FWSM for H.323 inspection:
hostname# config t
hostname(config)# interface Vlan100
hostname(config-if)# nameif outside
hostname(config-if)# security-level 0
hostname(config-if)# ip address 209.165.201.2 255.0.0.0
hostname(config-if)#
hostname(config-if)# interface Vlan50
hostname(config-if)# nameif inside
hostname(config-if)# security-level 100
hostname(config-if)# ip address 10.100.100.2 255.0.0.0
hostname(config-if)#
hostname(config-if)# access-list voice extended permit udp any any eq 1719
hostname(config)# access-list voice extended permit tcp any any eq h323
hostname(config)#
hostname(config)# access-group voice in interface outside
hostname(config)# access-group voice in interface inside
hostname(config)#
hostname(config)# policy-map global_policy
hostname(config-pmap)# class inspection_default
hostname(config-pmap-c)# inspect h323 h225
hostname(config-pmap-c)#
inspect h323 ras
hostname(config-pmap-c)#
Output of show conn shows H.323 media connections and control (connections flagged by h and output
of show h225):
FWSM/admin# show conn
4 in use, 7 most used
Network Processor 1 connections
UDP out 209.165.201.1:52906 in 10.0.0.6:1719 idle 0:00:07 Bytes 5162
FLAGS - H
TCP out 209.165.201.1:1720 in 10.100.100.1:12139 idle 0:00:54 Bytes 1307 FLAGS - UOIh
UDP out 209.165.201.1:19253 in 10.100.100.1:17815 idle 0:00:03 Bytes 13012
FLAGS - H
UDP out 209.165.201.1:19252 in 10.100.100.1:17814 idle 0:00:00 Bytes 1370400
FLAGS - H
Network Processor 2 connections
Multicast sessions:
Network Processor 1 connections
Network Processor 2 connections
IPv6 connections:
FWSM/admin# show h225
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-59
Chapter 21
Applying Application Layer Protocol Inspection
HTTP Inspection
Total: 1
1 Concurrent Call(s) for
Local: 10.100.100.1/12139 Foreign: 209.165.201.1/1720
0 CRV: 2
Local: 10.100.100.1/12139 TPKT: 211
Foreign: 209.165.201.1/1720
TPKT: 113
HTTP Inspection
This section describes how the HTTP inspection engine works and how you can change its configuration.
This section includes the following topics:
•
HTTP Inspection Overview, page 21-60
•
Configuring an HTTP Inspection Policy Map for Additional Inspection Control, page 21-60
HTTP Inspection Overview
Use the HTTP inspection engine to protect against specific attacks and other threats that may be
associated with HTTP traffic. HTTP inspection performs several functions.
•
Enhanced HTTP inspection
•
Java and ActiveX filtering
The second feature is configured in conjunction with the filter command. For more information about
filtering, see Chapter 17, “Applying Filtering Services.”
Note
The no inspect http command also disables the filter url command.
The enhanced HTTP inspection feature, which is also known as an application firewall and is available
when you configure an HTTP map (see “Configuring an HTTP Inspection Policy Map for Additional
Inspection Control”), can help prevent attackers from using HTTP messages for circumventing network
security policy. It verifies the following for all HTTP messages.
•
Conformance to RFC 2616
•
Use of RFC-defined methods only.
•
Compliance with the additional criteria.
Configuring an HTTP Inspection Policy Map for Additional Inspection Control
To specify actions when a message violates a parameter, create an HTTP inspection policy map. You can
then apply the inspection policy map when you enable HTTP inspection according to the “Configuring
Application Inspection” section on page 21-6.
Note
When you enable HTTP inspection with an inspection policy map, strict HTTP inspection with the action
reset and log is enabled by default. You can change the actions performed in response to inspection
failure, but you cannot disable strict inspection as long as the inspection policy map remains enabled.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-60
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
HTTP Inspection
To create an HTTP inspection policy map, perform the following steps:
Step 1
(Optional) Add one or more regular expressions for use in traffic matching commands according to the
“Creating a Regular Expression” section on page 19-11. See the types of text you can match in the match
commands described in Step 3.
Step 2
(Optional) Create one or more regular expression class maps to group regular expressions according to
the “Creating a Regular Expression Class Map” section on page 19-14.
Step 3
(Optional) Create an HTTP inspection class map by performing the following steps.
A class map groups multiple traffic matches. Traffic must match all of the match commands to match
the class map. You can alternatively identify match commands directly in the policy map. The difference
between creating a class map and defining the traffic match directly in the inspection policy map is that
the class map lets you create more complex match criteria, and you can reuse class maps.
To specify traffic that should not match the class map, use the match not command. For example, if the
match not command specifies the string “example.com,” then any traffic that includes “example.com”
does not match the class map.
For the traffic that you identify in this class map, you can specify actions such as drop, drop-connection,
reset, mask, set the rate limit, and/or log the connection in the inspection policy map.
If you want to perform different actions for each match command, you should identify the traffic directly
in the policy map.
a.
Create the class map by entering the following command:
hostname(config)# class-map type inspect http [match-all | match-any] class_map_name
hostname(config-cmap)#
Where class_map_name is the name of the class map. The match-all keyword is the default, and
specifies that traffic must match all criteria to match the class map. The match-any keyword
specifies that the traffic matches the class map if it matches at least one of the criteria. The CLI
enters class-map configuration mode, where you can enter one or more match commands.
b.
(Optional) To add a description to the class map, enter the following command:
hostname(config-cmap)# description string
c.
(Optional) To match traffic with a content-type field in the HTTP response that does not match the
accept field in the corresponding HTTP request message, enter the following command:
hostname(config-cmap)# match [not] req-resp content-type mismatch
d.
(Optional) To match text found in the HTTP request message arguments, enter the following
command:
hostname(config-cmap)# match [not] request args regex [regex_name | class
regex_class_name]
Where the regex_name is the regular expression you created in Step 1. The class regex_class_name
is the regular expression class map you created in Step 2.
e.
(Optional) To match text found in the HTTP request message body or to match traffic that exceeds
the maximum HTTP request message body length, enter the following command:
hostname(config-cmap)# match [not] request body {regex [regex_name | class
regex_class_name] | length gt max_bytes}
Where the regex regex_name argument is the regular expression you created in Step 1. The class
regex_class_name is the regular expression class map you created in Step 2. The length gt
max_bytes is the maximum message body length in bytes.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-61
Chapter 21
Applying Application Layer Protocol Inspection
HTTP Inspection
f.
(Optional) To match text found in the HTTP request message header, or to restrict the count or length
of the header, enter the following command:
hostname(config-cmap)# match [not] request header {[field]
[regex [regex_name | class regex_class_name]] |
[length gt max_length_bytes | count gt max_count_bytes]}
Where the field is the predefined message header keyword. The regex regex_name argument is the
regular expression you created in Step 1. The class regex_class_name is the regular expression class
map you created in Step 2. The length gt max_bytes is the maximum message body length in bytes.
The count gt max_count is the maximum number of header fields.
g.
(Optional) To match text found in the HTTP request message method, enter the following command:
hostname(config-cmap)# match [not] request method {[method] |
[regex [regex_name | class regex_class_name]]
Where the method is the predefined message method keyword. The regex regex_name argument is
the regular expression you created in Step 1. The class regex_class_name is the regular expression
class map you created in Step 2.
h.
(Optional) To match text found in the HTTP request message URI, enter the following command:
hostname(config-cmap)# match [not] request uri {regex [regex_name | class
regex_class_name] | length gt max_bytes}
Where the regex regex_name argument is the regular expression you created in Step 1. The class
regex_class_name is the regular expression class map you created in Step 2. The length gt
max_bytes is the maximum message body length in bytes.
i.
(Optional) To match text found in the HTTP response message body, or to comment out Java applet
and Active X object tags in order to filter them, enter the following command:
hostname(config-cmap)# match [not] response body {[active-x] | [java-applet] |
[regex [regex_name | class regex_class_name]] | length gt max_bytes}
Where the regex regex_name argument is the regular expression you created in Step 1. The class
regex_class_name is the regular expression class map you created in Step 2. The length gt
max_bytes is the maximum message body length in bytes.
j.
(Optional) To match text found in the HTTP response message header, or to restrict the count or
length of the header, enter the following command:
hostname(config-cmap)# match [not] response header {[field]
[regex [regex_name | class regex_class_name]] |
[length gt max_length_bytes | count gt max_count]}
Where the field is the predefined message header keyword. The regex regex_name argument is the
regular expression you created in Step 1. The class regex_class_name is the regular expression class
map you created in Step 2. The length gt max_bytes is the maximum message body length in bytes.
The count gt max_count is the maximum number of header fields.
k.
(Optional) To match text found in the HTTP response message status line, enter the following
command:
hostname(config-cmap)# match [not] response status-line {regex [regex_name | class
regex_class_name]}
Where the regex regex_name argument is the regular expression you created in Step 1. The class
regex_class_name is the regular expression class map you created in Step 2.
Step 4
Create an HTTP inspection policy map, enter the following command:
hostname(config)# policy-map type inspect http policy_map_name
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-62
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
HTTP Inspection
hostname(config-pmap)#
Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration
mode.
Step 5
(Optional) To add a description to the policy map, enter the following command:
hostname(config-pmap)# description string
Step 6
To apply actions to matching traffic, perform the following steps.
a.
Specify the traffic on which you want to perform actions using one of the following methods:
•
Specify the HTTP class map that you created in Step 3 by entering the following command:
hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)#
•
b.
Specify traffic directly in the policy map using one of the match commands described in Step 3.
If you use a match not command, then any traffic that does not match the criterion in the match
not command has the action applied.
Specify the action you want to perform on the matching traffic by entering the following command:
hostname(config-pmap-c)# {[drop-connection [send-protocol-error]| reset] [log]}
Not all options are available for each match or class command. See the CLI help or the Catalyst
6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference for
the exact options available.
The drop-connection keyword drops the packet and closes the connection.
The reset keyword drops the packet, closes the connection, and sends a TCP reset to the server
and/or client.
The log keyword, which you can use alone or with one of the other keywords, sends a system log
message.
You can specify multiple class or match commands in the policy map. For information about the order
of class and match commands, see the “Defining Actions in an Inspection Policy Map” section on
page 19-7.
Step 7
To configure parameters that affect the inspection engine, perform the following steps:
a.
To enter parameters configuration mode, enter the following command:
hostname(config-pmap)# parameters
hostname(config-pmap-p)#
b.
To check for HTTP protocol violations, enter the following command:
hostname(config-pmap-p)# protocol-violation [action [drop-connection | reset | log]]
Where the drop-connection action closes the connection. The reset action closes the connection
and sends a TCP reset to the client. The log action sends a system log message when this policy map
matches traffic.
c.
To enforce banner obfuscation, enter the following command:
hostname(config-pmap-p)# mask-banner
The mask-banner command is the default when policy-map type inspect is configured, however
no mask-banner can be entered to change the default.
d.
To substitute a string for the server header field, enter the following command:
hostname(config-pmap-p)# spoof-server string
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-63
Chapter 21
Applying Application Layer Protocol Inspection
ICMP Inspection
Where the string argument is the string to substitute for the server header field. Note: WebVPN
streams are not subject to the spoof-server command.
The following example shows how to define an HTTP inspection policy map that will allow and log any
HTTP connection that attempts to access “www\.example.com/.*\.asp" or
"www\.example[0-9][0-9]\.com" with methods "GET" or "PUT." All other URL/Method combinations
will be silently allowed.
hostname(config)#
hostname(config)#
hostname(config)#
hostname(config)#
regex
regex
regex
regex
url1 “www\.example.com/.*\.asp”
url2 “www\.example[0-9][0-9]\.com”
get “GET”
put “PUT”
hostname(config)# class-map type regex match-any url_to_log
hostname(config-cmap)# match regex url1
hostname(config-cmap)# match regex url2
hostname(config-cmap)# exit
hostname(config)# class-map type regex match-any methods_to_log
hostname(config-cmap)# match regex get
hostname(config-cmap)# match regex put
hostname(config-cmap)# exit
hostname(config)# class-map type inspect http http_url_policy
hostname(config-cmap)# match request uri regex class url_to_log
hostname(config-cmap)# match request method regex class methods_to_log
hostname(config-cmap)# exit
hostname(config)# policy-map type inspect http http_policy
hostname(config-pmap)# class http_url_policy
hostname(config-pmap-c)# log
ICMP Inspection
ICMP inspection is disabled by default.
For information about ICMP inspection, see the inspect icmp and inspect icmp error command pages
in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command
Reference.
ILS Inspection
ILS inspection is disabled by default.
For information about ILS inspection, see the inspect ils command page in the Catalyst 6500 Series
Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-64
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
MGCP Inspection
MGCP Inspection
This section describes how to enable and configure MGCP application inspection and change the default
port configuration. This section includes the following topics:
•
MGCP Inspection Overview, page 21-65
•
Configuring MGCP Call Agents and Gateways, page 21-67
•
Configuring and Enabling MGCP Inspection, page 21-67
•
Configuring MGCP Timeout Values, page 21-69
•
Verifying and Monitoring MGCP Inspection, page 21-69
•
MGCP Sample Configuration, page 21-70
MGCP Inspection Overview
MGCP is a master/slave protocol used to control media gateways from external call control elements
called media gateway controllers or call agents. A media gateway is typically a network element that
provides conversion between the audio signals carried on telephone circuits and data packets carried over
the Internet or over other packet networks. Using NAT and PAT with MGCP lets you support a large
number of devices on an internal network with a limited set of external (global) addresses. Examples of
media gateways are as follows.
•
Trunking gateways that interface between the telephone network and a VoIP network. Such
gateways typically manage a large number of digital circuits.
•
Residential gateways that provide a traditional analog (RJ11) interface to a VoIP network. Examples
of residential gateways include cable modem/cable set-top boxes, xDSL devices, broad-band
wireless devices.
•
Business gateways that provide a traditional digital PBX interface or an integrated soft PBX
interface to a VoIP network.
MGCP messages are transmitted over UDP. A response is sent back to the source (IP address and UDP
port number) of the command, but the response may not arrive from the same address as the command
was sent to. This can happen when multiple call agents are being used in a failover configuration and the
call agent that received the command has passed control to a backup call agent, which then sends the
response. Figure 21-11 illustrates how NAT can be used with MGCP.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-65
Chapter 21
Applying Application Layer Protocol Inspection
MGCP Inspection
Figure 21-11
Using NAT with MGCP
To PSTN
Cisco
PGW 2200
M
H.323
M
M
Cisco
CallManager
209.165.201.10
209.165.201.11
209.165.201.1
Gateway is told
to send its media
to 209.165.200.231
(public address
of the IP Phone)
209.165.200.231
MGCP
SCCP
RTP to 10.0.0.76
from 209.165.200.231
209.165.200.231
GW
GW
IP
IP
IP
10.0.0.76
Branch offices
119936
RTP to 209.165.201.1
from 209.165.200.231
MGCP endpoints are physical or virtual sources and destinations for data. Media gateways contain
endpoints on which the call agent can create, modify and delete connections to establish and control
media sessions with other multimedia endpoints. Also, the call agent can instruct the endpoints to detect
certain events and generate signals. The endpoints automatically communicate changes in service state
to the call agent.
MGCP transactions are composed of a command and a mandatory response. There are eight types of
commands.
•
CreateConnection
•
ModifyConnection
•
DeleteConnection
•
NotificationRequest
•
Notify
•
AuditEndpoint
•
AuditConnection
•
RestartInProgress
The first four commands are sent by the call agent to the gateway. The Notify command is sent by the
gateway to the call agent. The gateway may also send a DeleteConnection command. The registration of
the MGCP gateway with the call agent is achieved by the RestartInProgress command. The
AuditEndpoint and the AuditConnection commands are sent by the call agent to the gateway.
All commands are composed of a Command header, optionally followed by a session description. All
responses are composed of a Response header, optionally followed by a session description.
To use MGCP, you usually need to configure inspection for traffic sent to two ports:
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-66
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
MGCP Inspection
Note
•
The port on which the gateway receives commands from the call agent. Gateways usually listen to
UDP port 2427.
•
The port on which the call agent receives commands from the gateway. Call agents usually listen to
UDP port 2727.
MGCP inspection does not support the use of different IP addresses for MGCP signaling and RTP data.
A common and recommended practice is to send RTP data from a resilient IP address, such as a loopback
or virtual IP address; however, the FWSM requires the RTP data to come from the same address as
MGCP signalling.
Configuring MGCP Call Agents and Gateways
Use the call-agent command to specify a group of call agents that can manage one or more gateways.
The call agent group information is used to open connections for the call agents in the group (other than
the one a gateway sends a command to) so that any of the call agents can send the response. Call agents
with the same group_id belong to the same group. A call agent may belong to more than one group. The
group_id option is a number from 0 to 4294967295. The ip_address option specifies the IP address of
the call agent.
To specify a group of call agents, enter the call-agent command in MGCP map configuration mode,
which is accessible by entering the mgcp-map command in global configuration mode.
Note
Using call agents to control the MGCP gateways does not restrict calls between the gateways. For
example, the FWSM does not deny voice calls based on the call agent or gateway IP addresses configured
by using the mgcp-map command. The gateways can make voice calls even when they are not
configured by using the mgcp-map command.
Use the gateway command to specify which group of call agents are managing a particular gateway. The
IP address of the gateway is specified with the ip_address option. The group_id option is a number from
0 to 4294967295 that must correspond with the group_id of the call agents that are managing the
gateway. A gateway may only belong to one group.
Note
MGCP call agents send AUEP messages to determine if MGCP end points are present. This establishes
a flow through the FWSM and allows MGCP end points to register with the call agent.
Configuring and Enabling MGCP Inspection
To enable and configure MGCP application inspection, perform the following steps:
Step 1
Define an access list with ACEs that identify the two ports required for receiving MGCP traffic. The
standard ports are UDP ports 2427 and 2727. To create the access list, use the access-list extended
command, as follows:
hostname(config)# access-list acl-name permit udp any any eq port-1
hostname(config)# access-list acl-name permit udp any any eq port-2
where acl-name is the name you assign to the access list, port-1 is the first MGCP port and port-2 is the
second MGCP port.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-67
Chapter 21
Applying Application Layer Protocol Inspection
MGCP Inspection
Step 2
Create a class map or modify an existing class map to identify MGCP traffic. Use the class-map
command to do so, as follows.
hostname(config)# class-map class_map_name
hostname(config-cmap)#
where class_map_name is the name of the traffic class. When you enter the class-map command, the
CLI enters class map configuration mode.
Step 3
Use a match access-list command to identify MGCP traffic with the access list you created in Step 1.
hostname(config-cmap)# match access-list acl-name
Step 4
(Optional) If the network has multiple call agents and gateways for which the FWSM has to open
pinholes, create an MGCP map. To do so, perform the following steps.
a.
Create an MGCP map by using the mgcp-map command. The mgcp-map command lets you create
parameters for MGCP inspection. Use the mgcp-map command as follows.
hostname(config-cmap)# mgcp-map map_name
hostname(config-mgcp-map)#
where map_name is the name of the MGCP map. The system enters MGCP map configuration mode
and the CLI prompt changes accordingly.
b.
Configure the call agents. To do so, use the call-agent command once per call agent, as follows.
hostname(config-mgcp-map)# call-agent ip_address group_id
c.
Configure the gateways. To do so, use the gateway command once per gateway, as follows.
hostname(config-mgcp-map)# gateway ip_address group_id
d.
(Optional) If you want to change the maximum number of commands allowed in the MGCP
command queue, use the command-queue command, as follows:
hostname(config-mgcp-map)# command-queue command_limit
Step 5
Create a policy map or modify an existing policy map that you want to use to apply the MGCP inspection
engine to MGCP traffic. To do so, use the policy-map command, as follows.
hostname(config-cmap)# policy-map policy_map_name
hostname(config-pmap)#
where policy_map_name is the name of the policy map. The CLI enters the policy map configuration
mode and the prompt changes accordingly.
Step 6
Specify the class map, created in Step 2, that identifies the MGCP traffic. Use the class command to do
so, as follows.
hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)#
where class_map_name is the name of the class map you created in Step 2. The CLI enters the policy
map class configuration mode and the prompt changes accordingly.
Step 7
Enable MGCP application inspection. To do so, use the inspect mgcp command, as follows.
hostname(config-pmap-c)# inspect mgcp [map_name]
hostname(config-pmap-c)#
where map_name is the MGCP map that you may have created in optional Step 4.
Step 8
Use the service-policy command to apply the policy map globally or to a specific interface, as follows:
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-68
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
MGCP Inspection
hostname(config-pmap-c)# service-policy policy_map_name [global | interface interface_ID]
hostname(config)#
where policy_map_name is the policy map you configured in Step 5. If you want to apply the policy map
to traffic on all the interfaces, use the global option. If you want to apply the policy map to traffic on a
specific interface, use the interface interface_ID option, where interface_ID is the name assigned to the
interface with the nameif command.
The FWSM begins inspecting MGCP traffic, as specified.
Example 21-10 shows how to identify MGCP traffic, define a MGCP map, define a policy, and apply the
policy to the outside interface. This creates a class map to match MGCP traffic on the default ports (2427
and 2727). This configuration allows call agents 10.10.11.5 and 10.10.11.6 to control gateway
10.10.10.115, and allows call agents 10.10.11.7 and 10.10.11.8 to control both gateways 10.10.10.116
and 10.10.10.117. The maximum number of MGCP commands that can be queued is 150. The service
policy is then applied to the outside interface.
Example 21-10 Enabling and Configuring MGCP Inspection
hostname(config)# access-list mgcp_acl permit udp any any eq 2427
hostname(config)# access-list mgcp_acl permit udp any any eq 2727
hostname(config)# class-map mgcp-traffic
hostname(config-cmap)# match access-list mgcp_acl
hostname(config-cmap)# mgcp-map sample_map
hostname(config-mgcp-map)# call-agent 10.10.11.5 101
hostname(config-mgcp-map)# call-agent 10.10.11.6 101
hostname(config-mgcp-map)# call-agent 10.10.11.7 102
hostname(config-mgcp-map)# call-agent 10.10.11.8 102
hostname(config-mgcp-map)# gateway 10.10.10.115 101
hostname(config-mgcp-map)# gateway 10.10.10.116 102
hostname(config-mgcp-map)# gateway 10.10.10.117 102
hostname(config-mgcp-map)# command-queue 150
hostname(config-mgcp-map)# policy-map sample_policy
hostname(config-pmap)# class mgcp_port
hostname(config-pmap-c)# inspect mgcp sample_map
hostname(config-pmap-c)# service-policy sample_policy interface outside
Configuring MGCP Timeout Values
The timeout mgcp command lets you set the interval for inactivity after which an MGCP media
connection is closed. The default is five minutes.
The timeout mgcp-pat command lets you set the timeout for PAT xlates. Because MGCP does not have
a keepalive mechanism, if you use non-Cisco MGCP gateways (call agents), the PAT xlates are torn
down after the default timeout interval, which is 30 seconds.
Verifying and Monitoring MGCP Inspection
The show mgcp commands command lists the number of MGCP commands in the command queue. The
show mgcp sessions command lists the number of existing MGCP sessions. The detail option includes
additional information about each command (or session) in the output. The following is sample output
from the show mgcp commands command.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-69
Chapter 21
Applying Application Layer Protocol Inspection
MGCP Inspection
hostname# show mgcp commands
1 in use, 1 most used, 200 maximum allowed
CRCX, gateway IP: host-pc-2, transaction ID: 2052, idle: 0:00:07
The following is sample output from the show mgcp commands detail command:
hostname# show mgcp commands detail
1 in use, 1 most used, 200 maximum allowed
CRCX, idle: 0:00:10
Gateway IP
host-pc-2
Transaction ID 2052
Endpoint name
aaln/1
Call ID
9876543210abcdef
Connection ID
Media IP
192.168.5.7
Media port
6058
The following is sample output from the show mgcp sessions command:
hostname# show mgcp sessions
1 in use, 1 most used
Gateway IP host-pc-2, connection ID 6789af54c9, active 0:00:11
The following is sample output from the show mgcp sessions detail command:
hostname# show mgcp sessions detail
1 in use, 1 most used
Session active 0:00:14
Gateway IP
host-pc-2
Call ID
9876543210abcdef
Connection ID
6789af54c9
Endpoint name
aaln/1
Media lcl port 6166
Media rmt IP
192.168.5.7
Media rmt port 6058
MGCP Sample Configuration
Figure 21-12 shows a sample configuration for MGCP inspection:
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-70
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
MGCP Inspection
Figure 21-12
MGCP Inspection Setup
CallManager
M
10.0.0.210
vlan 90
10.0.0.254
CallManager
FXS
IP
Voice port
port 3/0/0
vlan 50
f0/1
inside
10.100.100.2
Cisco 3745
IOS MGCP
Gateway
outside
209.165.201.2
R2
vlan 100
f0/1
Firewall Service Module
(FWSM)
Cisco 3745
IOS MGCP
Gateway
Voice port
port 1/0/0
191988
R1
See the following configuration for this example:
hostname(config)# interface Vlan100
hostname(config-if)# nameif outside
hostname(config-if)# security-level 0
hostname(config-if)# ip address 209.165.201.2 255.0.0.0
hostname(config-if)# !
hostname(config-if)# interface Vlan50
hostname(config-if)# nameif inside
hostname(config-if)# security-level 100
hostname(config-if)# ip address 10.100.100.2 255.0.0.0
hostname(config-if)# !
hostname(config-if)# interface Vlan90
hostname(config-if)# nameif callmgr
hostname(config-if)# security-level 75
hostname(config-if)# ip address 10.0.0.254 255.0.0.0
TFTP port is enabled so that IOS MGCP gateway can download configuration files from the Cisco
CallManager. MGCP control protocol over UDP port 2427 is enabled for pass through. MGCP backup
port TCP 2428 is enabled.
hostname(config-if)# access-list mgcp extended permit udp any host 10.0.0.210 eq 2428
hostname(config)# access-list mgcp extended permit udp any any eq 2427
hostname(config)# access-list mgcp extended permit udp any any eq tftp
Apply the above access lists on the inside and outside interfaces for incoming traffic:
hostname(config)# access-group mgcp in interface outside
hostname(config)# access-group mgcp in interface inside
Configure call agent (IP address of the Cisco CallManager) and the IP address of the IOS MGCP gateway
in an MGCP map:
hostname(config)# mgcp-map
hostname(config-mgcp-map)#
hostname(config-mgcp-map)#
hostname(config-mgcp-map)#
hostname(config-mgcp-map)#
hostname(config-mgcp-map)#
mgcp-inspect
call-agent 15.0.0.210 101
gateway 10.100.100.1 101
gateway 209.165.201.1 101
command-queue 150
exit
Apply MGCP inspection with MGCP map:
hostname(config)# policy-map global_policy
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-71
Chapter 21
Applying Application Layer Protocol Inspection
NetBIOS Inspection
hostname(config-pmap)# class inspection_default
hostname(config-pmap-c)# inspect mgcp mgcp-inspect
Output of show conn in admin context, which shows the connections established between IOS MGCP
gateways and call agents:
hostname(config)# show conn
6in use, 48 most used
Network Processor 1 connections
Network Processor 2 connections
UDP out 15.0.0.210:2427 in 10.100.100.1:2427 idle 0:00:04 Bytes 5790 FLAGS - g
UDP out 209.165.201.1:2427 in 10.0.0.210:2427 idle 0:00:00 Bytes 8221 FLAGS - g
UDP out 209.165.201.1:18199 in 10.100.100.1:19247 idle 0:00:03 Bytes 14080 FLAGS - g
UDP out 209.165.201.1:18199 in 10.100.100.1:19246 idle 0:00:00 Bytes 4030838 FLAGS - g
TCP out 10.0.0.210:2428 in 10.100.100.1:12695 idle 0:00:04 Bytes 1346 FLAGS - UOI
TCP out 209.165.201.1:15954 in 10.0.0.210:2428 idle 0:00:00 Bytes 1346 FLAGS - UBOI
Multicast sessions:
Network Processor 1 connections
Network Processor 2 connections
IPV6 connections:
IOS MGCP gateway configuration of router R2:
hostname(config)# interface FastEthernet 0/1
hostname(config-if)# ip address 209.165.201.1 255.0.0.0
hostname(config-if)# no shut
hostname(config-if)# ip host FWSM-CCM-14 10.0.0.210
hostname(config-if)# exit
hostname(config)# ip route 10.0.0.0 255.0.0.0 209.165.201.2
hostname(config)# mgcp
hostname(config)# mgcp call-agent FWSM-CCM-14
hostname(config)# mgcp dtmf-relay voip codec all mode out-of-band
hostname(config)# ccm-manager mgcp
hostname(config)# ccm-manager config server 10.0.0.210
hostname(config)# ccm-manager config
hostname(config)# dial-peer voice 100 pots
hostname(config-dial-peer)# application mgcpapp
hostname(config-dial-peer)# port 1/0/0
hostname(config-dial-peer)# no shut
IOS MGCP gateway configuration of router R1:
hostname(config)# interface FastEthernet 0/1
hostname(config-if)# ip address 10.100.100.1 255.0.0.0
hostname(config-if)# no shut
hostname(config-if)# exit
hostname(config)# ip route 10.0.0.0 255.0.0.0 10.100.100.2
hostname(config)# ccm-manager mgcp
hostname(config)# ccm-manager music-on-hold
hostname(config)# ccm-manager config server 10.0.0.210
hostname(config)# ccm-manager config
hostname(config)# mgcp
hostname(config)# mgcp call-agent FWSM-CCM-14
hostname(config)# mgcp dtmf-relay voip codec all mode out-of-band
hostname(config)# dial-peer voice 101 pots
hostname(config-dial-peer)# application mgcpapp
hostname(config-dial-peer)# port 3/0/0
NetBIOS Inspection
NetBIOS inspection is enabled by default.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-72
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
PPTP Inspection
For information about NetBIOS inspection, see the inspect netbios command page in the Catalyst 6500
Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.
PPTP Inspection
PPTP inspection is disabled by default.
For information about PPTP inspection, see the inspect pptp command page in the Catalyst 6500 Series
Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.
RSH Inspection
RSH inspection is enabled by default.
For information about RSH inspection, see the inspect rsh command page in the Catalyst 6500 Series
Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.
RTSP Inspection
This section describes how to enable RTSP application inspection and change the default port
configuration. This section includes the following topics:
•
RTSP Inspection Overview, page 21-73
•
Using RealPlayer, page 21-74
•
Restrictions and Limitations, page 21-74
•
Enabling and Configuring RTSP Inspection, page 21-74
RTSP Inspection Overview
You control RTSP application inspection with the inspect rtsp command, available in policy map class
configuration mode. This command is disabled by default. The inspect rtsp command lets the FWSM
pass RTSP packets. RTSP is used by RealAudio, RealNetworks, Apple QuickTime 4, RealPlayer, and
Cisco IP/TV connections.
Note
For Cisco IP/TV, use RTSP TCP port 554 and TCP 8554.
RTSP applications use the well-known port 554 with TCP (rarely UDP) as a control channel. The FWSM
supports TCP only, in conformity with RFC 2326. This TCP control channel is used to negotiate the data
channels that is used to transmit audio/video traffic, depending on the transport mode that is configured
on the client.
The supported RDT transports are: rtp/avp, rtp/avp/udp, x-real-rdt, x-real-rdt/udp, and x-pn-tng/udp.
The FWSM parses SETUP response messages with a status code of 200. If the response message is
travelling inbound, the server is outside relative to the FWSM and dynamic channels need to be opened
for connections coming inbound from the server. If the response message is outbound, then the FWSM
does not need to open dynamic channels.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-73
Chapter 21
Applying Application Layer Protocol Inspection
RTSP Inspection
Because RFC 2326 does not require that the client and server ports must be in the SETUP response
message, the FWSM keeps state and remembers the client ports in the SETUP message. QuickTime
places the client ports in the SETUP message and then the server responds with only the server ports.
RTSP inspection supports PAT. It does not support dual-NAT, however. Also, the FWSM cannot
recognize HTTP cloaking, which hides RTSP messages in the HTTP messages.
Using RealPlayer
When using RealPlayer, it is important to properly configure transport mode. For the FWSM, add an
access-list command from the server to the client or vice versa. For RealPlayer, change transport mode
by choosing Options > Preferences > Transport > RTSP Settings.
If using TCP mode on the RealPlayer, check the Use TCP to Connect to Server and Attempt to use
TCP for all content check boxes. On the FWSM, there is no need to configure the inspection engine.
If using UDP mode on the RealPlayer, check the Use TCP to Connect to Server and Attempt to use
UDP for static content check boxes, and for live content not available via Multicast. On the FWSM,
add an inspect rtsp port command.
Restrictions and Limitations
The following restrictions apply to RTSP inspection:
•
The FWSM does not support multicast RTSP or RTSP messages over UDP.
•
The FWSM does not have the ability to recognize HTTP cloaking, which hides RTSP messages in
the HTTP messages.
•
The FWSM cannot perform NAT on RTSP messages because the embedded IP addresses are
contained in the SDP files as part of HTTP or RTSP messages. Packets could be fragmented and
FWSM cannot perform NAT on fragmented packets.
•
With Cisco IP/TV, the number of NATs the FWSM performs on the SDP part of the message is
proportional to the number of program listings in the Content Manager (each program listing can
have at least six embedded IP addresses).
•
You can configure NAT for Apple QuickTime 4 or RealPlayer. Cisco IP/TV only works with NAT
if the Viewer and Content Manager are on the outside network and the server is on the inside
network.
Enabling and Configuring RTSP Inspection
To enable or configure RTSP application inspection, perform the following steps:
Step 1
Determine the ports receiving RTSP SETUP messages behind the FWSM. The default ports are TCP
ports 554 and 8554.
Step 2
Create an access list to identify the RTSP SETUP messages. Use the access-list extended command to
do so, adding an ACE to match each port, as follows.
hostname(config)# access-list acl-name any any tcp eq port_number
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-74
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
RTSP Inspection
Tip
If you allow RTSP SETUP messages on one port only or on a contiguous range or ports, you can skip
creating the access list and, in Step 4, use the match port command instead of the match access-list
command.
Step 3
Create a class map or modify an existing class map to identify RTSP traffic. Use the class-map command
to do so, as follows.
hostname(config)# class-map class_map_name
hostname(config-cmap)#
where class_map_name is the name of the traffic class. When you enter the class-map command, the
CLI enters class map configuration mode.
Step 4
Identify traffic sent to the RTSP ports you determined in Step 1. To do so, use a match access-list
command, as follows.
hostname(config-cmap)# match access-list acl-name
Step 5
Create a policy map or modify an existing policy map that you want to use to apply the RTSP inspection
engine to RTSP traffic. To do so, use the policy-map command, as follows.
hostname(config-cmap)# policy-map policy_map_name
hostname(config-pmap)#
where policy_map_name is the name of the policy map. The CLI enters the policy map configuration
mode and the prompt changes accordingly.
Step 6
Specify the class map, created in Step 3, that identifies the RTSP traffic. Use the class command to do
so, as follows.
hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)#
where class_map_name is the name of the class map you created. The CLI enters the policy map class
configuration mode and the prompt changes accordingly.
Step 7
Enable RTSP application inspection. To do so, use the inspect rtsp command, as follows.
hostname(config-pmap-c)# inspect rtsp
hostname(config-pmap-c)#
Step 8
Use the service-policy command to apply the policy map globally or to a specific interface, as follows:
hostname(config-pmap-c)# service-policy policy_map_name [global | interface interface_ID]
hostname(config)#
where policy_map_name is the policy map you configured in Step 5. If you want to apply the policy map
to traffic on all the interfaces, use the global option. If you want to apply the policy map to traffic on a
specific interface, use the interface interface_ID option, where interface_ID is the name assigned to the
interface with the nameif command.
The FWSM begins inspecting RTSP traffic, as specified.
Example 21-11 shows how to enable the RTSP inspection engine RTSP traffic on the default ports (554
and 8554). The service policy is then applied to the outside interface.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-75
Chapter 21
Applying Application Layer Protocol Inspection
SIP Inspection
Example 21-11 Enabling and Configuring RTSP Inspection
hostname(config)# access-list rtsp_acl permit tcp any any eq 554
hostname(config)# access-list rtsp_acl permit tcp any any eq 8554
hostname(config)# class-map rtsp-traffic
hostname(config-cmap)# match access-list rtsp_acl
hostname(config-cmap)# policy-map sample_policy
hostname(config-pmap)# class rtsp_port
hostname(config-pmap-c)# inspect rtsp
hostname(config-pmap-c)# service-policy sample_policy interface outside
SIP Inspection
This section describes how to enable SIP application inspection and change the default port
configuration. This section includes the following topics:
•
SIP Inspection Overview, page 21-76
•
SIP Instant Messaging, page 21-77
•
IP Address Privacy, page 21-78
•
Configuring a SIP Inspection Policy Map for Additional Inspection Control, page 21-78
•
Configuring SIP Timeout Values, page 21-82
•
SIP Inspection Enhancement, page 21-82
•
Verifying and Monitoring SIP Inspection, page 21-86
•
SIP Sample Configuration, page 21-87
SIP Inspection Overview
SIP, as defined by the IETF, enables call handling sessions, particularly two-party audio conferences, or
“calls.” SIP works with SDP for call signalling. SDP specifies the ports for the media stream. Using SIP,
the FWSM can support any SIP VoIP gateways and VoIP proxy servers. SIP and SDP are defined in the
following RFCs.
•
SIP: Session Initiation Protocol, RFC 2543
•
SDP: Session Description Protocol, RFC 2327
Supporting SIP calls through the FWSM requires inspection of signaling messages for the media
connection addresses, media ports, and embryonic connections for the media. While SIP signalling is
sent over a well-known destination port (UDP/TCP 5060), the media streams use dynamically allocated
ports. Also, SIP embeds IP addresses in the user-data portion of the IP packet and SIP inspection applies
NAT for these embedded IP addresses.
The following limitations and restrictions apply when using PAT with SIP:
•
If a remote endpoint tries to register with a SIP proxy on a network protected by the FWSM, the
registration fails under very specific conditions, as follows:
– PAT is configured for the remote endpoint.
– The SIP registrar server is on the outside network.
– The port is missing in the contact field in the REGISTER message sent by the endpoint to the
proxy server.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-76
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
SIP Inspection
•
If a SIP device transmits a packet in which the SDP portion has an IP address in the owner/creator
field (o=) that is different than the IP address in the connection field (c=), the IP address in the o=
field may not be properly translated. This is due to a limitation in the SIP protocol, which does not
provide a port value in the o= field.
SIP Instant Messaging
Instant Messaging refers to the transfer of messages between users in near real-time. SIP supports the
Chat feature on Windows XP using Windows Messenger RTC Client version 4.7.0105 only. The
MESSAGE/INFO methods and 202 Accept response are used to support IM as defined in the following
RFCs.
•
Session Initiation Protocol (SIP)-Specific Event Notification, RFC 3265
•
Session Initiation Protocol (SIP) Extension for Instant Messaging, RFC 3428
MESSAGE/INFO requests can come in at any time after registration/subscription. For example, two
users can be online at any time, but not chat for hours. Therefore, the SIP inspection engine opens
pinholes that time out according to the configured SIP timeout value. This value must be configured at
least five minutes longer than the subscription duration. The subscription duration is defined in the
Contact Expires value and is typically 30 minutes.
Because MESSAGE/INFO requests are typically sent using a dynamically allocated port other than port
5060, they are required to go through the SIP inspection engine.
Note
Only the Chat feature is currently supported. Whiteboard, File Transfer, and Application Sharing are not
supported. RTC Client 5.0 is not supported.
SIP inspection NATs the SIP text-based messages, recalculates the content length for the SDP portion of
the message, and recalculates the packet length and checksum. It dynamically opens media connections
for ports specified in the SDP portion of the SIP message as address/ports on which the endpoint should
listen.
SIP inspection has a database with indices CALL_ID/FROM/TO from the SIP payload. These indices
identify the call, the source, and the destination. This database contains the media addresses and media
ports found in the SDP media information fields and the media type. There can be multiple media
addresses and ports for a session. The FWSM opens RTP/RTCP connections between the two endpoints
using these media addresses/ports.
The well-known port 5060 must be used on the initial call setup (INVITE) message; however, subsequent
messages may not have this port number. The SIP inspection engine opens signaling connection
pinholes, and marks these connections as SIP connections. This is done for the messages to reach the
SIP application and be NATed.
As a call is set up, the SIP session is in the “transient” state until the media address and media port is
received from the called endpoint in a Response message indicating the RTP port the called endpoint
listens on. If there is a failure to receive the response messages within one minute, the signaling
connection is torn down.
Once the final handshake is made, the call state is moved to active and the signaling connection remains
until a BYE message is received.
If an inside endpoint initiates a call to an outside endpoint, a media hole is opened to the outside interface
to allow RTP/RTCP UDP packets to flow to the inside endpoint media address and media port specified
in the INVITE message from the inside endpoint. Unsolicited RTP/RTCP UDP packets to an inside
interface does not traverse the FWSM, unless the FWSM configuration specifically allows it.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-77
Chapter 21
Applying Application Layer Protocol Inspection
SIP Inspection
IP Address Privacy
When IP Address Privacy is enabled, if any two SIP endpoints participating in an IP phone call or instant
messaging session use the same internal firewall interface to contact their SIP proxy server on an
external firewall interface, all SIP signaling messages go through the SIP proxy server.
IP Address Privacy can be enabled when SIP over TCP or UDP application inspection is enabled. By
default, this feature is disabled. If IP Address Privacy is enabled, the FWSM does not translate internal
and external host IP addresses embedded in the TCP or UDP payload of inbound SIP traffic, ignoring
translation rules for those IP addresses.
You control whether this feature is enabled by using the ip-address-privacy command in SIP map
configuration mode.
Configuring a SIP Inspection Policy Map for Additional Inspection Control
To specify actions when a message violates a parameter, create a SIP inspection policy map. You can
then apply the inspection policy map when you enable SIP inspection according to the “Configuring
Application Inspection” section on page 21-6.
To create a SIP inspection policy map, perform the following steps:
Step 1
(Optional) Add one or more regular expressions for use in traffic matching commands according to the
“Creating a Regular Expression” section on page 19-11. See the types of text you can match in the match
commands described in Step 3.
Step 2
(Optional) Create one or more regular expression class maps to group regular expressions according to
the “Creating a Regular Expression Class Map” section on page 19-14.s
Step 3
(Optional) Create a SIP inspection class map by performing the following steps.
A class map groups multiple traffic matches. Traffic must match all of the match commands to match
the class map if match-all is specified. Traffic must match any one of the match commands to match the
class map if the match-any keyword is used.
You can alternatively identify match commands directly in the policy map. The difference between
creating a class map and defining the traffic match directly in the inspection policy map is that the class
map lets you create more complex match criteria, and you can reuse class maps.
To specify traffic that should not match the class map, use the match not command. For example, if the
match not command specifies the string “example.com,” then any traffic that includes “example.com”
does not match the class map.
For the traffic that you identify in this class map, you can specify actions such as drop-connection, reset,
drop, drop-connection log, reset log, and/or log the connection in the inspection policy map.
If you want to perform different actions for each match command, you should identify the traffic directly
in the policy map.
a.
Create the class map by entering the following command:
hostname(config)# class-map type inspect sip [match-all | match-any] class_map_name
hostname(config-cmap)#
Where the class_map_name is the name of the class map. The name can be a string up to 40
characters. The match-all keyword is the default, and specifies that traffic must match all criteria to
match the class map if match-all is specified. The match-any keyword specifies that the traffic
matches the class map if any of the match commands in the class map is matched.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-78
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
SIP Inspection
The CLI enters class-map configuration mode, where you can enter one or more match commands.
b.
(Optional) To add a description to the class map, enter the following command:
hostname(config-cmap)# description string
Where string is the description of the class map (up to 200 characters).
c.
(Optional) To match a called party, as specified in the To header or Contact header, enter the
following command:
hostname(config-cmap)# match [not] called-party regex {class class_name | regex_name}
Where the regex regex_name argument is the regular expression you created in Step 1. The class
regex_class_name is the regular expression class map you created in Step 2.
d.
(Optional) To match a calling party, as specified in the From header, enter the following command:
hostname(config-cmap)# match [not] calling-party regex {class class_name | regex_name}
Where the regex regex_name argument is the regular expression you created in Step 1. The class
regex_class_name is the regular expression class map you created in Step 2.
e.
(Optional) To match a content length in the SIP header, enter the following command:
hostname(config-cmap)# match [not] content length gt length
Where length is the number of bytes the content length is greater than. 0 to 65536.
f.
(Optional) To match an SDP content type or regular expression, enter the following command:
hostname(config-cmap)# match [not] content type {sdp | regex {class class_name |
regex_name}}
Where the regex regex_name argument is the regular expression you created in Step 1. The class
regex_class_name is the regular expression class map you created in Step 2.
g.
(Optional) To match a SIP IM subscriber, enter the following command:
hostname(config-cmap)# match [not] im-subscriber regex {class class_name | regex_name}
Where the regex regex_name argument is the regular expression you created in Step 1. The class
regex_class_name is the regular expression class map you created in Step 2.
h.
(Optional) To match a SIP via header, enter the following command:
hostname(config-cmap)# match [not] message-path regex {class class_name | regex_name}
Where the regex regex_name argument is the regular expression you created in Step 1. The class
regex_class_name is the regular expression class map you created in Step 2.
i.
(Optional) To match a SIP request method, enter the following command:
hostname(config-cmap)# match [not] request-method method
Where method is the type of method to match (ack, bye, cancel, info, invite, message, notify,
options, prack, refer, register, subscribe, unknown, update).
j.
(Optional) To match the requester of a third-party registration by matching the From header in SIP
REGISTER messages, enter the following command. This command only matches the requestor
when the contents of the To and From fields in a SIP REGISTER message are different.
hostname(config-cmap)# match [not] third-party-registration regex {class class_name |
regex_name}
Where the regex regex_name argument is the regular expression you created in Step 1. The class
regex_class_name is the regular expression class map you created in Step 2.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-79
Chapter 21
Applying Application Layer Protocol Inspection
SIP Inspection
k.
(Optional) To match an URI in the SIP headers, enter the following command:
hostname(config-cmap)# match [not] uri {sip | tel} length gt length
Where length is the number of bytes the URI is greater than. 0 to 65536.
Step 4
Create a SIP inspection policy map, enter the following command:
hostname(config)# policy-map type inspect sip policy_map_name
hostname(config-pmap)#
Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration
mode.
Step 5
(Optional) To add a description to the policy map, enter the following command:
hostname(config-pmap)# description string
The string for the description can contain up to 200 characters.
Step 6
To apply actions to matching traffic, perform the following steps.
a.
(Optional) Specify the traffic on which you want to perform actions using one of the following
methods:
•
Specify the SIP class map that you created in Step 3 by entering the following command:
hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)#
•
b.
Specify traffic directly in the policy map using one of the match commands described in Step 3.
If you use a match not command, then any traffic that does not match the criterion in the match
not command has the action applied.
Specify the action you want to perform on the matching traffic by entering the following command:
hostname(config-pmap-c)# {[drop | drop-connection | mask | reset] [log]}
Not all options are available for each match or class command. See the CLI help or the Catalyst
6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference for
the exact options available.
The drop keyword drops all packets that match.
The drop-connection keyword drops the packet and closes the connection.
The mask keyword masks out the matching portion of the packet.
The reset keyword drops the packet, closes the connection, and sends a TCP reset to the server
and/or client.
The log keyword, which you can use alone or with one of the other keywords, sends a system log
message.
You can specify multiple class or match commands in the policy map. For information about the order
of class and match commands, see the “Defining Actions in an Inspection Policy Map” section on
page 19-7.
Step 7
(Optional) To configure parameters that affect the inspection engine, perform the following steps:
a.
To enter parameters configuration mode, enter the following command:
hostname(config-pmap)# parameters
hostname(config-pmap-p)#
b.
To enable or disable instant messaging, enter the following command. Instant messaging is enabled
by default.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-80
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
SIP Inspection
hostname(config-pmap-p)# im
c.
To enable or disable IP address privacy, enter the following command:
hostname(config-pmap-p)# ip-address-privacy
d.
To enable check on Max-forwards header field being 0 (which cannot be 0 before reaching the
destination), enter the following command:
hostname(config-pmap-p)# max-forwards-validation action {drop | drop-connection |
reset | log} [log]
e.
To enable check on RTP packets flowing on the pinholes for protocol conformance, enter the
following command:
hostname(config-pmap-p)# rtp-conformance [enforce-payloadtype]
Where the enforce-payloadtype keyword enforces the payload type to be audio or video based on
the signaling exchange.
f.
To identify the Server and User-Agent header fields, which expose the software version of either a
server or an endpoint, enter the following command:
hostname(config-pmap-p)# software-version action {mask | log} [log]
Where the mask keyword removes the SIP header containing the software version and the Alert-Info
and Call-Info header fields in the SIP messages.
g.
To enable state checking validation, enter the following command:
hostname(config-pmap-p)# state-checking action {drop | drop-connection | reset | log}
[log]
h.
To enable strict verification of the header fields in the SIP messages according to RFC 3261, enter
the following command:
hostname(config-pmap-p)# strict-header-validation action {drop | drop-connection |
reset | log} [log]
Note
To send a TCP reset from the universal access concentrator (UAC) to the user agent server (UAS)
when there is a violation in SIP message header, you must configure the service resetinbound
command in addition to entering the reset log keywords for the strict-header-validation
command.
When the security level is different on the inside and outside interfaces, the reset is sent to the
inside host only. To send the reset to the outside, you must configure the service resetinbound
command and enter the reset log keywords for the strict-header-validation command.
i.
To allow non SIP traffic using the well-known SIP signaling port, enter the following command.
Allowing non SIP traffic using the well-known SIP signaling port is enabled by default.
hostname(config-pmap-p)# traffic-non-sip
j.
To identify the presence of SIP headers such as the Alert-Info and Call-Info header fields in SIP
messages, enter the following command:
hostname(config-pmap-p)# uri-non-sip action {mask | log} [log]
The following example shows how to disable instant messaging over SIP:
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-81
Chapter 21
Applying Application Layer Protocol Inspection
SIP Inspection
hostname(config)# policy-map type inspect sip mymap
hostname(config-pmap)# parameters
hostname(config-pmap-p)# no im
hostname(config)# policy-map global_policy
hostname(config-pmap)# class inspection_default
hostname(config-pmap-c)# no inspect sip
hostname(config-pmap-c)# inspect sip mymap
hostname(config)# service-policy global_policy global
Configuring SIP Timeout Values
The media connections are torn down within two minutes after the connection becomes idle. This is,
however, a configurable timeout and can be set for a shorter or longer period of time. To configure the
timeout for the SIP control connection, use the following command:
hostname(config)# timeout sip hh:mm:ss
This command configures the idle timeout after which a SIP control connection is closed.
To configure the timeout for the SIP disconnect, use the following command:
hostname(config)# timeout sip_disconnect hh:mm:ss
This command configures the idle timeout after which SIP media is deleted and media xlates are closed.
Range is from 1 to 10 minutes.
To configure the timeout for the SIP invite, use the following command:
hostname(config)# timeout sip_invite hh:mm:ss
In the absence of the EXPIRE field in the SIP header, this command configures the idle timeout after
which pinholes for provisional responses and media xlates are closed. Range is from 1 to 30 minutes.
Default is 30 minutes.
To configure the timeout for the SIP media timer, use the following command:
hostname(config)# timeout sip_media hh:mm:ss
This command modifies the SIP media idle timer, which determines the time after which the SIP
RTP/RTCP connections are torn down due to inactivity. This command overrides the UDP inactivity
timeout timeout udp command for SIP media connections only. Default timeout value is 2 minutes.
Minimum timeout value is 1 minute. Maximum timeout value is 1193 hours. Value 0 causes SIP media
connections not to timeout.
SIP Inspection Enhancement
The SIP inspection enhancement removes media connections after receiving 200 OK for the BYE SIP
message, 200 OK for the CANCEL SIP message, and 200 OK for 4xx/5xx/6xx SIP messages, instead of
waiting for the idle timeout.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-82
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
SIP Inspection
Figure 21-13
Media Connection Clear on BYE Message
Firewall Service Module
(FWSM)
UAC
UAC
INVITE
100 Trying
180 ringing
200 OK
RTP
Timer
Media CONN entry
generate on FWSM
BYE
CONN entry deletes on receipt
of 200 OK or after SIP disconnect
timer expires, whichever is earlier.
Media CONN entry
existing time
191377
200 OK
In Figure 21-13, when 200 OK is not received for the BYE message, media connections are removed
after the timeout sip-disconnect occurs.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-83
Chapter 21
Applying Application Layer Protocol Inspection
SIP Inspection
Figure 21-14
Media Connection Clear on CANCEL Message
Firewall Service Module
(FWSM)
UAC
UAC
INVITE
100 Trying
180 ringing with SDP
Media CONN entry
generate on FWSM
200 OK
CONN entry deletes on receipt
of 200 OK or after SIP disconnect
timer expires, whichever is earlier.
Media CONN entry
existing time
191378
Timer
CANCEL
In Figure 21-14, the media connection is cleared after 200 OK is received for the CANCEL message. If
200 OK is not received for the CANCEL SIP message, the media connection is cleared after the timeout
sip-disconnect occurs.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-84
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
SIP Inspection
Figure 21-15
Media Connection Clear on 4xx/5xx/6xx SIP Messages
Firewall Service Module
(FWSM)
UAC
UAC
INVITE
100 Trying
180 ringing with SDP
200 OK
Media CONN entry
generate on FWSM
4XX response
Media CONN entry is
tear down after receiving
Error(4xx-6xx) response
Media CONN entry
existing time
191379
ACK
In Figure 21-15, the media connections are cleared immediately when 200 OK is received in response
for 4xx/5xx/6xx SIP messages. If 200 OK is not received, the media connection is cleared after the
timeout sip-disconnect occurs.
It is possible to extend the timeout for provisional responses. The timeout for pinholes receiving 1xx/2xx
responses is configurable, or configured based on the EXPIRE field. When the EXPIRE field exists in
the SIP INVITE message, and is less than 30 minutes, the timeout for pinholes for receiving 1xx/2xx
responses is set to the EXPIRE field value. If the EXPIRE field value in the SIP INVITE header is greater
than 30 minutes, the timeout for provisional responses is set to 30 minutes. In the absence of the EXPIRE
field in the SIP INVITE message, the timeout for provisional responses is set to the value configured
using the timeout sip-invite command.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-85
Chapter 21
Applying Application Layer Protocol Inspection
SIP Inspection
Extending Timeout for Provisional Responses
UAC
UAC
INVITE
Pin hole for 100
Trying, media xlate
and SIP session
are kept open for
configured timeout
INVITE
100 Trying
180 ringing
Pin hole for 180
Trying and 200 OK
kept open for
configured timeout
191380
Figure 21-16
Restrictions include:
•
SIP media connections are not cleared when 200 OK is received for the BYE message, CANCEL
message, or 4xx/5xx/6xx SIP message for those SIP sessions established prior to failover. SIP
sessions established after failover are cleared.
•
Pinholes opened for SIP responses are not cleared along with SIP media connections when 200 OK
is received for the BYE SIP message, CANCEL SIP message, or 4xx/5xx/6xx SIP message. Instead,
pinhole connections are cleared eventually due to timeout.
Verifying and Monitoring SIP Inspection
The show sip command assists in troubleshooting SIP inspection engine issues and is described with the
inspect protocol sip udp 5060 command. The show timeout sip command displays the timeout value
of the designated protocol.
The show sip command displays information for SIP sessions established across the FWSM. Along with
the debug sip, show local-host, and show service-policy inspect sip commands, this command is used
for troubleshooting SIP inspection engine issues.
Note
We recommend that you configure the pager command before entering the show sip command. If there
are a lot of SIP session records and the pager command is not configured, it takes a while for the show
sip command output to reach its end.
The following is sample output from the show sip command:
hostname# show sip
Total: 2
call-id c3943000-960ca-2e43-228f@10.130.56.44
state Call init, idle 0:00:01
call-id c3943000-860ca-7e1f-11f7@10.130.56.45
state Active, idle 0:00:06
This sample shows two active SIP sessions on the FWSM (as shown in the Total field). Each call-id
represents a call.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-86
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
SIP Inspection
The first session, with the call-id c3943000-960ca-2e43-228f@10.130.56.44, is in the state Call Init,
which means the session is still in call setup. Call setup is not complete until a final response to the call
has been received. For instance, the caller has already sent the INVITE, and maybe received a 100
Response, but has not yet seen the 200 OK, so the call setup is not complete yet. Any non-1xx response
message is considered a final response. This session has been idle for 1 second.
The second session is in the state Active, in which call setup is complete and the endpoints are
exchanging media. This session has been idle for 6 seconds.
SIP Sample Configuration
Figure 21-17 shows a sample configuration for SIP inspection:
Figure 21-17
SIP IP Address Privacy Setup
inside
4085550100
IP
outside
CallManager
vlan 150
vlan 50
4085550199
IP
10.2.0.10 209.165.201.5
209.165.201.1
FWSM
M
209.165.201.100
191990
209.165.201.115
209.165.201.118
See the following configuration for this example:
hostname(config)# interface Vlan12
hostname(config-if)# nameif outside
hostname(config-if)# security-level 0
hostname(config-if)# ip address 10.2.0.10 255.0.0.0
hostname(config-if)# !
Vlan 12 is an outside Vlan that routes all packets to 10.x.x.x network back to the FWSM with the next
hop IP address set to 10.2.0.10. This is done by configuring policy-based routing at the up-stream router.
hostname(config-if)#
hostname(config-if)#
hostname(config-if)#
hostname(config-if)#
interface Vlan50
nameif inside
security-level 100
ip address 10.100.100.7 255.255.255.0
The two phones 4085550100 and 4085550199 are used in the same 209.165.201.0 subnet.
hostname(config)# access-list voice extended permit udp
hostname(config)# access-list voice extended permit tcp
hostname(config)# access-list voice extended permit udp
hostname(config)# !
hostname(config)# sip-map privacy
hostname(config-if)# ip-address-privacy
hostname(config)# !
hostname(config)# nat-control
hostname(config)# static (inside, outside) 10.3.100.115
255.255.255.255
hostname(config)# static (inside, outside) 10.3.100.118
255.255.255.255
any any eq sip
any any eq sip
any any eq tftp
209.165.201.115 netmask
209.165.201.118 netmask
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-87
Chapter 21
Applying Application Layer Protocol Inspection
SIP Inspection
Each phone IP address is translated to an external dummy IP address that is not in a network connected
to the FWSM. The translated IP address should not be in a network connected to the FWSM.
hostname(config)# access-group voice in interface outside
hostname(config)# access-group voice in interface inside
hostname(config)# route outside 10.3.0.0 255.0.0.0 10.2.0.5 1
Configure route to10.3.0.0 via 10.2.0.5 (IP address of the next hop router):
hostname(config)# route outside 209.165.201.0 255.0.0.0 10.2.0.5 1
hostname(config)# !
hostname(config)# policy-map global_policy
hostname(config-pmap)# class inspection_default
hostname(config-pmap-c)# inspect dns maximum-length 512
hostname(config-pmap-c)# inspect ftp
hostname(config-pmap-c)# inspect h323 h225
hostname(config-pmap-c)# inspect h323 ras
hostname(config-pmap-c)# inspect rsh
hostname(config-pmap-c)# inspect smtp
hostname(config-pmap-c)# inspect sqlnet
hostname(config-pmap-c)# inspect skinny
hostname(config-pmap-c)# inspect sunrpc
hostname(config-pmap-c)# inspect xdmcp
hostname(config-pmap-c)# inspect netbios
hostname(config-pmap-c)# inspect tftp
hostname(config-pmap-c)# inspect sip privacy
Router configuration:
hostname(config)# interface GigabitEthernet0/2
hostname(config-if)# ip address 10.2.0.5 255.0.0.0
hostname(config-if)# ip policy route-map privacy
hostname(config-if)# duplex auto
hostname(config-if)# speed auto
hostname(config-if)# media-type rj45
hostname(config-if)# no negotiation auto
hostname(config-if)# !
hostname(config)# interface GigabitEthernet0/3
hostname(config-if)# ip address 209.165.201.1 255.0.0.0
hostname(config-if)# duplex auto
hostname(config-if)# speed auto
hostname(config-if)# media-type rj45
hostname(config-if)# no negotiation auto
hostname(config-if)# !
hostname(config-if)# ip route 10.3.0.0 255.0.0.0 10.2.0.10
hostname(config-if)# ip route 50.0.0.0 255.0.0.0 12.0.0.10
Configured route to 10.3.0.0 and 209.165.201.0 reachable via 10.2.0.10 (IP address of FWSM).
hostname(config)# access-list 10 permit ip any 10.3.0.0 0.255.255.255
hostname(config)# !
hostname(config)# route-map privacy permit 10
hostname(config-if)# match ip address 100
hostname(config-if)# set ip next-hop 10.2.0.10
Route map is configured to capture any packets destined for 10.3.0.0 network to be sent to 10.2.0.10 (IP
address of FWSM).
The show conn output at the FWSM shows that voice traffic is getting switched via the FWSM module
and hiding each phone IP address. RTP traffic is not switched via the same subnet. Instead it is getting
routed via the FWSM.
hostname(config)# show conn
6 in use, 28 most used
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-88
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
Skinny (SCCP) Inspection
Network Processor 1 connections
UDP out 209.165.201.100:5060 in 209.165.201.118:5060 idle 0:00:21 Bytes 67358 FLAGS - T
UDP out 10.3.100.115:16384 in 209.165.201.118:16384 idle 0:00:00 Bytes 6042324 FLAGS - m
UDP out 209.165.201.100:0 in 209.165.201.118:5060 idle 0:00:21 Bytes 18 FLAGS - t
Network Processor 2 connections
UDP out 209.165.201.100:5060 in 209.165.201.115:5060 idle 0:00:25 Bytes 80181 FLAGS - T
UDP out 10.3.100.118:16384 in 209.165.201.115:16384 idle 0:00:00 Bytes 6047556 FLAGS - m
UDP out 209.165.201.100:0 in 209.165.201.115:5060 idle 0:00:25 Bytes 33 FLAGS - t
Multicast sessions:
Network Processor 1 connections
Network Processor 2 connections
IPv6 connections:
hostname(config)# show xlate
2 in use, 2 most used
Global 30.100.100.115 Local 209.165.201.115
Global 30.100.100.118 Local 209.165.201.118
Skinny (SCCP) Inspection
This section describes how to enable SCCP application inspection and change the default port
configuration. This section includes the following topics:
•
SCCP Inspection Overview, page 21-89
•
Supporting Cisco IP Phones, page 21-90
•
Restrictions and Limitations, page 21-90
•
Configuring and Enabling SCCP Inspection, page 21-90
•
Verifying and Monitoring SCCP Inspection, page 21-92
•
SCCP (Skinny) Sample Configuration, page 21-93
SCCP Inspection Overview
Skinny (SCCP) is a simplified protocol used in VoIP networks. Cisco IP Phones using SCCP can coexist
in an H.323 environment. When used with Cisco CallManager, the SCCP client can interoperate with
H.323 compliant terminals. The FWSM supports all versions through Version 17 including:
•
Registrations of SCCP version 17 phones.
•
SCCP version 17 media related messages for opening up pinholes for video/audio streams.
The following actions are not supported:
•
Registrations of endpoints that have IPv6 addresses. The Register messages are dropped and a debug
message is generated.
•
If IPv6 messages are embedded in the SCCP messages, they are not NATed or PATed; they are left
untranslated.
The FWSM supports PAT and NAT for SCCP. PAT is necessary if you have more IP phones than global
IP addresses for the IP phones to use. By supporting NAT and PAT of SCCP Signaling packets, Skinny
application inspection ensures that all SCCP signalling and media packets can traverse the FWSM.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-89
Chapter 21
Applying Application Layer Protocol Inspection
Skinny (SCCP) Inspection
Normal traffic between Cisco CallManager and Cisco IP Phones uses SCCP and is handled by SCCP
inspection without any special configuration. The FWSM also supports DHCP options 150 and 66,
which it accomplishes by sending the location of a TFTP server to Cisco IP Phones and other DHCP
clients. Cisco IP Phones might also include DHCP option 3 in their requests, which sets the default route.
For more information, see the “Using Cisco IP Phones with a DHCP Server” section on page 8-38.
Supporting Cisco IP Phones
In topologies where Cisco CallManager is located on the higher security interface with respect to the
Cisco IP Phones, if NAT is required for the Cisco CallManager IP address, the mapping must be static
because a Cisco IP Phone requires the Cisco CallManager IP address to be specified explicitly in its
configuration. A static identity entry allows the Cisco CallManager on the higher security interface to
accept registrations from the Cisco IP Phones. Cisco IP Phones require access to a TFTP server to
download the configuration information they need to connect to the Cisco CallManager server.
When the Cisco IP Phones are on a lower security interface compared to the TFTP server, you must use
an access list to connect to the protected TFTP server on UDP port 69. While you do need a static identity
entry for the TFTP server, this does not have to be an identity static entry. When you use NAT, a static
identity entry maps to the same IP address. When you use PAT, it maps to the same IP address and port.
When the Cisco IP Phones are on a higher security interface compared to the TFTP server and
Cisco CallManager, no access list or static identity entry is required to allow the Cisco IP Phones to
initiate the connection.
Restrictions and Limitations
The following are limitations that apply to the current version of PAT and NAT support for SCCP:
•
PAT does not work with configurations containing the alias command.
•
Outside NAT or PAT is not supported.
If the address of an internal Cisco CallManager is configured for NAT or PAT to a different IP address
or port, registrations for external Cisco IP Phones fail because the FWSM currently does not support
NAT or PAT for the file content transferred over TFTP. Although the FWSM supports NAT of TFTP
messages and opens a pinhole for the TFTP file, the FWSM cannot translate the Cisco CallManager IP
address and port embedded in the Cisco IP Phone configuration files that are transferred by TFTP during
phone registration.
The following is not supported for SCCP version 17 phones:
Note
•
Registrations of endpoints that have IPv6 addresses. The Register messages are dropped and a debug
message is generated.
•
If IPv6 messages are embedded in the SCCP messages, they are not NATed or PATed; they are left
untranslated.
The FWSM supports stateful failover of SCCP calls except for calls that are in the middle of call setup.
Configuring and Enabling SCCP Inspection
SCCP inspection is enabled by default.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-90
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
Skinny (SCCP) Inspection
To enable SCCP inspection or change the default port used for receiving SCCP traffic, perform the
following steps:
Step 1
Name the traffic class by entering the following command in global configuration mode:
hostname(config)# class-map class_map_name
Replace class_map_name with the name of the traffic class, for example:
hostname(config)# class-map sccp_port
When you enter the class-map command, the CLI enters the class map configuration mode, and the
prompt changes, as in the following example:
hostname(config-cmap)#
Step 2
In the class map configuration mode, define the match command, as in the following example:
hostname(config-cmap)# match port tcp eq 2000
hostname(config-cmap)# exit
hostname(config)#
To assign a range of continuous ports, enter the range keyword, as in the following example:
hostname(config-cmap)# match port tcp range 2000-2010
To assign more than one non-contiguous port for SCCP inspection, enter the access-list extended
command and define an ACE to match each port. Then enter the match command to associate the access
lists with the SCCP traffic class.
Step 3
Name the policy map by entering the following command:
hostname(config)# policy-map policy_map_name
Replace policy_map_name with the name of the policy map, as in the following example:
hostname(config)# policy-map sample_policy
The CLI enters the policy map configuration mode and the prompt changes accordingly, as follows:
hostname(config-pmap)#
Step 4
Specify the traffic class defined in Step 1 to be included in the policy map by entering the following
command:
hostname(config-pmap)# class class_map_name
For example, the following command assigns the sccp_port traffic class to the current policy map:
hostname(config-pmap)# class sccp_port
The CLI enters the policy map class configuration mode and the prompt changes accordingly, as follows:
hostname(config-pmap-c)#
Step 5
(Optional) To change the default port used by the FWSM for receiving SCCP traffic, enter the following
command:
hostname(config-pmap-c)# inspect skinny
Step 6
Return to policy map configuration mode by entering the following command:
hostname(config-pmap-c)# exit
hostname(config-pmap)#
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-91
Chapter 21
Applying Application Layer Protocol Inspection
Skinny (SCCP) Inspection
Step 7
Return to global configuration mode by entering the following command:
hostname(config-pmap)# exit
hostname(config)#
Step 8
Apply the policy map globally or to a specific interface by entering the following command:
hostname(config)# service-policy policy_map_name [global | interface interface_ID
Replace policy_map_name with the policy map you configured in Step 3, and identify all the interfaces
with the global option or a specific interface using the name assigned with the nameif command.
For example, the following command applies the sample_policy to the outside interface:
hostname(config)# service-policy sample_policy interface outside
The following command applies the sample_policy to the all the FWSM interfaces:
hostname(config)# service-policy sample_policy global
You enable the SCCP inspection engine as shown in Example 21-12, which creates a class map to match
SCCP traffic on the default port (2000). The service policy is then applied to the outside interface.
Example 21-12 Enabling SCCP Application Inspection
hostname(config)# class-map sccp_port
hostname(config-cmap)# match port tcp eq 2000
hostname(config-cmap)# exit
hostname(config)# policy-map sample_policy
hostname(config-pmap)# class sccp_port
hostname(config-pmap-c)# inspect skinny
hostname(config-pmap-c)# exit
hostname(config)# service-policy sample_policy interface outside
Verifying and Monitoring SCCP Inspection
The show skinny command assists in troubleshooting SCCP (Skinny) inspection engine issues. The
following is sample output from the show skinny command under the following conditions. There are
two active Skinny sessions set up across the FWSM. The first one is an audio connection established
between an internal Cisco IP Phone at local address 10.0.0.11 and an external Cisco CallManager at
172.18.1.33. TCP port 2000 is the CallManager. The second one is a video connection established
between another internal Cisco IP Phone at local address 10.0.0.22 and the same Cisco CallManager.
hostname# show skinny
LOCAL
FOREIGN
STATE
--------------------------------------------------------------1
10.0.0.11/52238
172.18.1.33/2000
1
AUDIO 10.0.0.11/22948
172.18.1.22/20798
2
10.0.0.22/52232
172.18.1.33/2000
1
VIDEO 10.0.0.22/20798
172.18.1.11/22948
The output indicates that a call has been established between two internal Cisco IP Phones. The RTP
listening ports of the first and second phones are UDP 22948 and 20798 respectively.
The following is sample output from the show xlate debug command for these Skinny connections:
hostname# show xlate debug
2 in use, 2 most used
Flags: D - DNS, d - dump, I - identity, i - inside, n - no random,
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-92
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
Skinny (SCCP) Inspection
r - portmap, s - static
NAT from inside:10.0.0.11 to outside:172.18.1.11 flags si idle 0:00:16 timeout 0:05:00
NAT from inside:10.0.0.22 to outside:172.18.1.22 flags si idle 0:00:14 timeout 0:05:00
SCCP (Skinny) Sample Configuration
Figure 21-18 shows a sample configuration for SCCP (Skinny) inspection:
Figure 21-18
SCCP (Skinny) Inspection Setup
CallManager
M
209.165.201.210
vlan 90
209.165.201.254
CallManager
Cisco 7960
Skinny phone
vlan 50
inside
10.100.100.2
outside
209.165.201.2
vlan 100
FireWall Service module
(FWSM)
IP
Cisco 7960
Skinny phone
191989
IP
See the following configuration for this example:
hostname(config)# interface Vlan100
hostname(config-if)# nameif outside
hostname(config-if)# security-level 0
hostname(config-if)# ip address 209.165.201.2 255.0.0.0
hostname(config-if)# !
hostname(config-if)# interface Vlan50
hostname(config-if)# nameif inside
hostname(config-if)# security-level 100
hostname(config-if)# ip address 10.100.100.2 255.0.0.0
hostname(config-if)# !
hostname(config-if)# interface Vlan90
hostname(config-if)# nameif callmgr
hostname(config-if)# security-level 75
hostname(config-if)# ip address 209.165.201.254 255.0.0.0
TFTP port is enabled for the IP address of the CallManager so that phones on the inside and outside can
download configuration files from the CallManager for initial setup. TCP Port 2000 is enabled for the
IP address of the CallManager so that skinny signaling can pass the module between the phone and the
CallManager through firewall module.
hostname(config-if)# access-list voice extended permit udp any host 209.165.201.210 eq
tftp
hostname(config)# access-list voice extended permit tcp any host 209.165.201.210 eq 2000
Apply the above access lists on the inside and outside interfaces for incoming traffic:
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-93
Chapter 21
Applying Application Layer Protocol Inspection
SMTP and Extended SMTP Inspection
hostname(config)# access-group voice in interface outside
hostname(config)# access-group voice in interface inside
Configure SCCP (Skinny) inspection:
hostname(config)# policy-map global_policy
hostname(config-pmap)# class inspection_default
hostname(config-pmap-c)# inspect skinny
Output of show skinny when Skinny phone call through the firewall module is active:
hostname(config)# show skinny
LOCAL
FOREIGN
STATE
--------------------------------------------------------------------1
10.0.0.2/49723
209.165.201.210/2000
1
AUDIO
209.165.201.2/24002
209.165.201.211/19212
2
209.165.201.210/2000
209.165.201.211/49692
1
AUDIO
10.0.0.2/24002
209.165.201.211/19212
Output of show conn when there is one active phone call between Skinny phones, each reachable
through inside and outside interfaces. Skinny connections are marked by a k flag.
hostname(config)# show conn
3 in use, 26 most used
Network Processor 1 connections
TCP out 209.165.201.210:2000 in 10.0.0.2:49723 idle 0:00:07 Bytes 10232 FLAGS - UOI
Network Processor 2 connections
TCP out 209.165.201.211:49692 in 209.165.201.210:49723 idle 0:00:27 Bytes 12394 FLAGS UBOI
UDP out 209.165.201.211:19212 in 10.0.0.2:24002 idle 0:00:00 Bytes 3575654 FLAGS - K
Multicast sessions:
Network Processor 1 connections
Network Processor 2 connections
IPV6 connections:
SMTP and Extended SMTP Inspection
This section describes how to enable SMTP and ESMTP application inspection and change the default
port configuration. This section includes the following topics:
•
SMTP and Extended SMTP Inspection Overview, page 21-94
•
Configuring and Enabling SMTP and Extended SMTP Application Inspection, page 21-96
SMTP and Extended SMTP Inspection Overview
The FWSM supports application inspection for SMTP and ESMTP. Application inspection for these
protocols protects against attacks by restricting the types of SMTP or ESMTP commands that can pass
through the FWSM and by adding monitoring capabilities.
ESMTP is an enhancement to the SMTP protocol and is similar to SMTP. For convenience, the term
SMTP is used in this document to refer to both SMTP and ESMTP. The application inspection process
for ESMTP includes support for SMTP sessions. Most commands used in an ESMTP session are the
same as those used in an SMTP session but an ESMTP session is considerably faster and offers more
options related to reliability and security, such as delivery status notification.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-94
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
SMTP and Extended SMTP Inspection
The inspect smtp command supports seven RFC 821 commands (DATA, HELO, MAIL, NOOP, QUIT,
RCPT, RSET). The inspect esmtp command supports those seven commands and supports the following
extended SMTP commands: AUTH, HELP, EHLO, ETRN, SAML, SEND, SOML and VRFY.
Other SMTP or ESMTP commands and private extensions to ESMTP and are not supported.
Unsupported commands are translated into Xs, which are rejected by the SMTP server protected by the
FWSM. This results in a message such as “500 Command unknown: 'XXX'.” Incomplete commands are
discarded.
SMTP application inspection, as enabled by the inspect smtp command, occurs in fast path processing;
therefore, it occurs on one of the three network processors on the FWSM. ESMTP application
inspection, as enabled by the inspect esmtp command, occurs in control plane path processing;
therefore, it occurs on the single, general purpose processor on the FWSM.
Note
If a policy map contains both the inspect smtp command and the inspect esmtp command, only the first
command listed in the policy map is applied to matching traffic.
Inspection changes the characters in the server SMTP banner to asterisks except for the “2”, “0”, “0”
characters. Carriage return (CR) and linefeed (LF) characters are ignored.
With SMTP inspection enabled, a Telnet session used for interactive SMTP may hang if the following
rules are not observed: SMTP commands must be at least four characters in length; must be terminated
with carriage return and line feed; and must wait for a response before issuing the next reply.
An SMTP server responds to client requests with numeric reply codes and optional human-readable
strings. SMTP application inspection controls and reduces the commands that the user can use as well
as the messages that the server returns. SMTP inspection performs three primary tasks:
•
Restricts SMTP requests to seven basic SMTP commands and eight extended commands.
•
Monitors the SMTP command-response sequence.
•
Generates an audit trail—Audit record 108002 is generated when invalid character embedded in the
mail address is replaced. For more information, see RFC 821.
SMTP inspection monitors the command and response sequence for the following anomalous signatures:
Note
•
Truncated commands.
•
Incorrect command termination (not terminated with <CR><LR>).
•
The MAIL and RCPT commands specify who are the sender and the receiver of the mail. Mail
addresses are scanned for strange characters. The pipeline character (|) is deleted (changed to a blank
space) and “<” ‚”>” are only allowed if they are used to define a mail address (“>” must be preceded
by “<”).
•
Unexpected transition by the SMTP server.
•
For unknown commands, the FWSM changes all the characters in the packet to X. In this case, the
server generates an error code to the client. Because of the change in the packed, the TCP checksum
has to be recalculated or adjusted.
•
TCP stream editing.
•
Command pipelining.
FWSM supports SMTP and Extended SMTP Inspection for inbound traffic only; namely, FWSM
supports inspection of traffic from a lower security level to a higher security level.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-95
Chapter 21
Applying Application Layer Protocol Inspection
SMTP and Extended SMTP Inspection
Configuring and Enabling SMTP and Extended SMTP Application Inspection
SMTP inspection is enabled by default.
To enable SMTP or extended SMTP inspection, perform the following steps:
Step 1
Determine the ports that SMTP servers behind the FWSM listen to for SMTP traffic. The default port is
TCP port 25 but your SMTP servers may be configured to listen to other ports.
Step 2
Create a class map or modify an existing class map to identify SMTP traffic. Use the class-map
command to do so, as follows:
hostname(config)# class-map class_map_name
hostname(config-cmap)#
where class_map_name is the name of the traffic class. When you enter the class-map command, the
CLI enters class map configuration mode.
Step 3
Use a match command to identify traffic sent to the SMTP ports you determined in Step 1.
If the port mapper process listens to a single port, you can use the match port command to identify
traffic sent to that port, as follows:
hostname(config-cmap)# match port tcp eq port_number
where port_number is the port to which the port mapper process listens. If you need to assign a range of
contiguous ports, use the range keyword, as in the following example:
hostname(config-cmap)# match port tcp range begin_port_number end_port_number
Tip
Step 4
To identify two or more non-contiguous ports, enter the access-list extended command and
define an ACE to match each port. Then, rather than the match port command, use the match
access-list command to associate the access list with the SMTP traffic class.
Create a policy map that you want to use to apply the SMTP inspection engine to the SMTP traffic. To
do so, use the policy-map command, as follows:
hostname(config-cmap)# policy-map policy_map_name
hostname(config-pmap)#
where policy_map_name is the name of the policy map. The CLI enters the policy map configuration
mode and the prompt changes accordingly.
Step 5
Specify the class map, created in Step 2, that identifies the SMTP traffic. Use the class command to do
so, as follows:
hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)#
where class_map_name is the name of the class map you created in Step 2. The CLI enters the policy
map class configuration mode and the prompt changes accordingly.
Step 6
Do one of the following:
a.
To enable extended SMTP application inspection, enter the following command:
hostname(config-pmap-c)# inspect esmtp
b.
To enable SMTP application inspection, enter the following command:
hostname(config-pmap-c)# inspect smtp
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-96
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
SNMP Inspection
Note
Step 7
For information about the differences between the inspect smtp and inspect esmtp commands,
see the “SMTP and Extended SMTP Inspection Overview” section on page 21-94.
Use the service-policy command to apply the policy map globally or to a specific interface, as follows:
hostname(config-pmap-c)# service-policy policy_map_name [global | interface interface_ID]
hostname(config)#
where policy_map_name is the policy map you configured in Step 4. If you want to apply the policy map
to traffic on all the interfaces, use the global option. If you want to apply the policy map to traffic on a
specific interface, use the interface interface_ID option, where interface_ID is the name assigned to the
interface with the nameif command.
The FWSM begins inspecting SMTP traffic, as specified.
Example 21-13 Configuring and Enabling ESMTP Inspection
hostname(config)# class-map smtp_port
hostname(config-cmap)# match port tcp eq 25
hostname(config-cmap)# policy-map sample_policy
hostname(config-pmap)# class smtp_port
hostname(config-pmap-c)# inspect esmtp
hostname(config-pmap-c)# service-policy sample_policy interface outside
hostname(config)#
SNMP Inspection
This section describes how to enable SNMP application inspection and change the default port
configuration. This section includes the following topics:
•
SNMP Inspection Overview, page 21-97
•
Enabling and Configuring SNMP Application Inspection, page 21-98
SNMP Inspection Overview
SNMP application inspection lets you restrict SNMP traffic to a specific version of SNMP. Earlier
versions of SNMP are less secure; therefore, denying certain SNMP versions may be required by your
security policy. The FWSM can deny SNMP versions 1, 2, 2c, or 3. You control the versions permitted
by using the deny version command in SNMP map configuration mode.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-97
Chapter 21
Applying Application Layer Protocol Inspection
SNMP Inspection
Enabling and Configuring SNMP Application Inspection
To change the default configuration for SNMP inspection, perform the following steps:
Step 1
Determine the ports that network devices behind the FWSM listen to for SNMP traffic. The default ports
are TCP ports 161 and 162.
Step 2
Create a class map or modify an existing class map to identify SNMP traffic. Use the class-map
command to do so, as follows:
hostname(config)# class-map class_map_name
hostname(config-cmap)#
where class_map_name is the name of the traffic class. When you enter the class-map command, the
CLI enters class map configuration mode.
Step 3
Use a match command to identify traffic sent to the SNMP ports you determined in Step 1.
If you need to assign a range of contiguous ports, use the range keyword, as in the following example:
hostname(config-cmap)# match port tcp range begin_port_number end_port_number
where begin_port_number is the lowest port in the range of SNMP ports and end_port_number is the
highest port.
Tip
Step 4
To identify two or more non-contiguous ports, enter the access-list extended command and
define an ACE to match each port. Then, rather than the match port command, use the match
access-list command to associate the access list with the SNMP traffic class.
Create an SNMP map that will contain the parameters of SNMP inspection. Use the snmp-map
command to do so, as follows:
hostname(config-cmap)# snmp-map map_name
hostname(config-snmp-map)#
where map_name is the name of the SNMP map. The CLI enters SNMP map configuration mode.
Step 5
Specify the versions of SNMP permitted by the SNMP map. To do so, use the deny version command
to disallow the versions that you do not want to permit, as follows:
hostname(config-snmp-map)# deny version version
hostname(config-snmp-map)#
where version with an SNMP version that you want to restrict. Valid values of version are 1, 2, 2c, and
3. You can enter as many deny version commands as needed.
Step 6
Create a policy map or modify an existing policy map that you want to use to apply the SNMP inspection
engine to the SNMP traffic. To do so, use the policy-map command, as follows:
hostname(config-cmap)# policy-map policy_map_name
hostname(config-pmap)#
where policy_map_name is the name of the policy map. The CLI enters the policy map configuration
mode and the prompt changes accordingly.
Step 7
Specify the class map, created in Step 2, that identifies the SNMP traffic. Use the class command to do
so, as follows:
hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)#
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-98
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
SQL*Net Inspection
where class_map_name is the name of the class map you created in Step 2. The CLI enters the policy
map class configuration mode and the prompt changes accordingly.
Step 8
Enable SNMP application inspection. To do so, use the inspect snmp command, as follows:
hostname(config-pmap-c)# inspect snmp snmp_map_name
hostname(config-pmap-c)#
where snmp_map_name is the SNMP map that you created in Step 4.
Step 9
Use the service-policy command to apply the policy map globally or to a specific interface, as follows:
hostname(config-pmap-c)# service-policy policy_map_name [global | interface interface_ID]
hostname(config)#
where policy_map_name is the policy map you configured in Step 6. If you want to apply the policy map
to traffic on all the interfaces, use the global option. If you want to apply the policy map to traffic on a
specific interface, use the interface interface_ID option, where interface_ID is the name assigned to the
interface with the nameif command.
The FWSM begins inspecting SNMP traffic, as specified.
Example 21-14 enables SNMP application inspection on traffic sent to TCP ports 161 and 162 from the
outside interface:
Example 21-14 Configuring SNMP Application Inspection
hostname(config)# class-map snmp_port
hostname(config-cmap)# match port tcp range 161 162
hostname(config-cmap)# snmp-map sample_map
hostname(config-snmp-map)# deny version 1
hostname(config-snmp-map)# deny version 2
hostname(config-snmp-map)# policy-map sample_policy
hostname(config-pmap)# class snmp_port
hostname(config-pmap-c)# inspect snmp sample_map
hostname(config-pmap-c)# service-policy sample_policy interface outside
hostname(config)#
SQL*Net Inspection
SQL*Net inspection is enabled by default.
For information about SQL*Net inspection, see the inspect sqlnet command page in the Catalyst 6500
Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.
Sun RPC Inspection
This section describes how to enable Sun RPC application inspection, change the default port
configuration, and manage the Sun RPC service table. This section includes the following topics:
•
Sun RPC Inspection Overview, page 21-100
•
Enabling and Configuring Sun RPC Inspection, page 21-100
•
Managing Sun RPC Services, page 21-102
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-99
Chapter 21
Applying Application Layer Protocol Inspection
Sun RPC Inspection
•
Verifying and Monitoring Sun RPC Inspection, page 21-103
Sun RPC Inspection Overview
To enable Sun RPC application inspection or to change the ports to which the FWSM listens, use the
inspect sunrpc command in policy map class configuration mode, which is accessible by using the class
command within policy map configuration mode. To remove the configuration, use the no form of this
command.
The inspect sunrpc command enables or disables application inspection for the Sun RPC protocol. Sun
RPC is used by NFS and NIS. Sun RPC services can run on any port. When a client attempts to access
an Sun RPC service on a server, it must learn the port that service is running on. It does this by querying
the port mapper process, usually rpcbind, on the well-known port of 111.
The client sends the Sun RPC program number of the service and the port mapper process responds with
the port number of the service. The client sends its Sun RPC queries to the server, specifying the port
identified by the port mapper process. When the server replies, the FWSM intercepts this packet and
opens both embryonic TCP and UDP connections on that port.
Note
Sun RPC Inspection is not supported with the XLATE BYPASS feature because Sun RPC Inspection
relies on XLATES for functionality and the XLATE BYPASS feature can prevent Sun RPC Inspection
from functioning correctly. For more information about the xlate-bypass command, see the Catalyst
6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.
Note
NAT or PAT of Sun RPC payload information is not supported.
Enabling and Configuring Sun RPC Inspection
Sun RPC inspection is enabled by default.
Note
To enable or configure Sun RPC inspection over UDP, you do not have to define a separate traffic class
or a new policy map. You simply add the inspect sunrpc command into a policy map whose traffic class
is defined by the default traffic class. An example of this configuration is shown in Example 21-16 on
page 21-102.
To enable Sun RPC inspection or change the default port used for receiving Sun RPC traffic using TCP,
perform the following steps:
Step 1
Determine the port or ports that the port mapper process listens to. While this is most often port 111, it
can differ between operating systems and implementations.
Step 2
Create a class map or modify an existing class map to identify Sun RPC traffic. Use the class-map
command to do so, as follows:
hostname(config)# class-map class_map_name
hostname(config-cmap)#
where class_map_name is the name of the traffic class. When you enter the class-map command, the
CLI enters class map configuration mode.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-100
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
Sun RPC Inspection
Step 3
Use a match command to identify traffic sent to the port or ports that you determined in Step 1.
If the port mapper process listens to a single port, you can use the match port command to identify
traffic sent to that port, as follows:
hostname(config-cmap)# match port tcp eq port_number
where port_number is the port to which the port mapper process listens. If you need to assign a range of
contiguous ports, use the range keyword, as in the following example:
hostname(config-cmap)# match port tcp range begin_port_number end_port_number
Tip
Step 4
To identify two or more non-contiguous ports, enter the access-list extended command and
define an ACE to match each port. Then, rather than the match port command, use the match
access-list command to associate the access list with the Sun RPC traffic class.
Create a policy map or modify an existing policy map that you want to use to apply the Sun RPC
inspection engine to the Sun RPC traffic. To do so, use the policy-map command, as follows:
hostname(config-cmap)# policy-map policy_map_name
hostname(config-pmap)#
where policy_map_name is the name of the policy map. The CLI enters the policy map configuration
mode and the prompt changes accordingly.
Step 5
Specify the class map, created in Step 2, that identifies the Sun RPC traffic. Use the class command to
do so, as follows:
hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)#
where class_map_name is the name of the class map you created in Step 2. The CLI enters the policy
map class configuration mode and the prompt changes accordingly.
Step 6
Enable Sun RPC application inspection. To do so, enter the following command:
hostname(config-pmap-c)# inspect sunrpc
hostname(config-pmap-c)#
Step 7
Use the service-policy command to apply the policy map globally or to a specific interface, as follows:
hostname(config-pmap-c)# service-policy policy_map_name [global | interface interface_ID]
hostname(config)#
where policy_map_name is the policy map you configured in Step 4. If you want to apply the policy map
to traffic on all the interfaces, use the global option. If you want to apply the policy map to traffic on a
specific interface, use the interface interface_ID option, where interface_ID is the name assigned to the
interface with the nameif command.
The FWSM begins inspecting Sun RPC traffic, as specified.
Example 21-15 Enabling and Configuring TCP-based Sun RPC Inspection
The following example enables Sun RPC application inspection on traffic sent to TCP port 111 from the
outside interface:
hostname(config)# class-map sunrpc_port
hostname(config-cmap)# match port tcp eq 111
hostname(config-cmap)# policy-map sample_policy
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-101
Chapter 21
Applying Application Layer Protocol Inspection
Sun RPC Inspection
hostname(config-pmap)# class sunrpc_port
hostname(config-pmap-c)# inspect sunrpc
hostname(config-pmap-c)# service-policy sample_policy interface outside
hostname(config)#
Example 21-16 enables Sun RPC over UDP, which you do by adding the inspect sunrpc command to a
policy map that applies actions to the default traffic class:
Example 21-16 Enabling and Configuring UDP-based Sun RPC Inspection
hostname(config)# policy-map asa_global_fw_policy
hostname(config-pmap)# class inspection_default
hostname(config-pmap-c)# inspect sunrpc
hostname(config-pmap-c)#
Managing Sun RPC Services
The FWSM maintains a Sun RPC services table to control established Sun RPC sessions. To create
entries in the Sun RPC services table, use the sunrpc-server command in global configuration mode.
You can use the sunrpc-server command to specify the timeout after which the FWSM closes a pinhole
opened by Sun RPC application inspection. For example, to create a timeout of 30 minutes for the Sun
RPC server with the IP address 192.168.100.2, enter the following command:
hostname(config)# sunrpc-server inside 192.168.100.2 255.255.255.255 service 100003
protocol tcp 111 timeout 00:30:00
This command specifies that the pinhole that was opened by Sun RPC application inspection will be
closed after 30 minutes. In this example, the Sun RPC server is on the inside interface using TCP port
111. You can also specify UDP, a different port number, or a range of ports. To specify a range of ports,
separate the starting and ending port numbers in the range with a hyphen (for example, 111-113).
The service type identifies the mapping between a specific service type and the port number used for the
service. To determine the service type, which in this example is 100003, use the sunrpcinfo command
at the UNIX or Linux command line on the Sun RPC server machine.
To clear the Sun RPC configuration, enter the following command.
hostname(config)# clear configure sunrpc-server
This removes the configuration performed using the sunrpc-server command. The sunrpc-server
command allows pinholes to be created with a specified timeout.
To clear the active Sun RPC services, enter the following command:
hostname(config)# clear sunrpc-server active
This clears the pinholes open because Sun RPC application inspection enabled the traffic based on
service requests to the port mapper service.
Note
FWSM does not support fragmented Sun RPC traffic at the application layer. Pinholes are opened only
for ports that appear in the first fragment.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-102
OL-16083-01
Chapter 21
Applying Application Layer Protocol Inspection
Sun RPC Inspection
Verifying and Monitoring Sun RPC Inspection
The sample output in this section is for a Sun RPC server with an IP address of 192.168.100.2 on the
inside interface and a Sun RPC client with an IP address of 209.165.201.5 on the outside interface.
To view information about the current Sun RPC connections, enter the show conn command. The
following is sample output from the show conn command:
hostname# show conn
15 in use, 21 most used
UDP out 209.165.200.5:800 in 192.168.100.2:2049 idle 0:00:04 flags UDP out 209.165.200.5:714 in 192.168.100.2:111 idle 0:00:04 flags UDP out 209.165.200.5:712 in 192.168.100.2:647 idle 0:00:05 flags UDP out 192.168.100.2:0 in 209.168.201.5:714 idle 0:00:05 flags i
hostname(config)#
To display the information about the Sun RPC service table configuration, enter the show
running-config sunrpc-server command. The following is sample output from the show
running-config sunrpc-server command:
hostname(config)# show running-config sunrpc-server
sunrpc-server inside 192.168.100.2 255.255.255.255 service 100003 protocol UDP port 111
timeout 0:30:00
sunrpc-server inside 192.168.100.2 255.255.255.255 service 100005 protocol UDP port 111
timeout 0:30:00
This output shows that a timeout interval of 30 minutes is configured on UDP port 111 for the Sun RPC
server with the IP address 192.168.100.2 on the inside interface.
To display the pinholes open for Sun RPC services, enter the show sunrpc-server active command. The
following is sample output from show sunrpc-server active command:
hostname# show sunrpc-server active
LOCAL FOREIGN SERVICE TIMEOUT
----------------------------------------------1 209.165.201.5/0 192.168.100.2/2049 100003 0:30:00
2 209.165.201.5/0 192.168.100.2/2049 100003 0:30:00
3 209.165.201.5/0 192.168.100.2/647 100005 0:30:00
4 209.165.201.5/0 192.168.100.2/650 100005 0:30:00
The entry in the LOCAL column shows the IP address of the client or server on the inside interface, while
the value in the FOREIGN column shows the IP address of the client or server on the outside interface.
To view information about the Sun RPC services running on a Sun RPC server, enter the rpcinfo -p
command from the Linux or UNIX server command line. The following is sample output from the
rpcinfo -p command:
sunrpcserver:~ # rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 632 status
100024 1 tcp 635 status
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100021 1 udp 32771 nlockmgr
100021 3 udp 32771 nlockmgr
100021 4 udp 32771 nlockmgr
100021 1 tcp 32852 nlockmgr
100021 3 tcp 32852 nlockmgr
100021 4 tcp 32852 nlockmgr
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
OL-16083-01
21-103
Chapter 21
Applying Application Layer Protocol Inspection
TFTP Inspection
100005
100005
100005
100005
100005
100005
1
1
2
2
3
3
udp
tcp
udp
tcp
udp
tcp
647
650
647
650
647
650
mountd
mountd
mountd
mountd
mountd
mountd
In this output, port 647 corresponds to the mountd daemon running over UDP. The mountd process
would more commonly be using port 32780, but it uses TCP port 650 in this example.
TFTP Inspection
TFTP inspection is enabled by default.
For information about TFTP inspection, see the inspect tftp command page in the Catalyst 6500 Series
Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.
XDMCP Inspection
XDMCP inspection is enabled by default; however, the XDMCP inspection engine is dependent upon
proper configuration of the established command.
For information about XDMCP inspection, see the established and inspect pptp and command pages
in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command
Reference.
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI
21-104
OL-16083-01