Cisco ASA 5500 Series Configuration Guide using the CLI, 8.4 and 8.6

DCERPC Overview

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. Since a client may attempt multiple connections to the server port returned by EPM, multiple use of pinholes are allowed, which have user configurable timeouts.

Note DCERPC inspection only supports communication between the EPM and clients to open pinholes through theASA. Clients using RPC communication that does not use the EPM is not supported with DCERPC inspection.

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.

To create a DCERPC inspection policy map, perform the following steps:

Step 1 Create a DCERPC inspection policy map, enter the following command:

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:

Step 3 To configure parameters that affect the inspection engine, perform the following steps:

a. To enter parameters configuration mode, enter the following command:

b. To configure the timeout for DCERPC pinholes and override the global system pinhole timeout of two minutes, enter the following command:

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:

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.

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 46-1).

Figure 46-1 GPRS Tunneling Protocol

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.

GTP does not include any inherent security or encryption of user data, but using GTP with the ASA 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.

Configuring a GTP Inspection Policy Map for Additional Inspection Control

If you want to enforce additional parameters on GTP traffic, create and configure a GTP map. If you do not specify a map with the inspect gtp command, the ASA 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

To create and configure a GTP map, perform the following steps. You can then apply the GTP map when you enable GTP inspection according to the “Configuring Application Layer Protocol Inspection” section.

Step 1 Create a GTP inspection policy map, enter the following command:

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:

Step 3 To match an Access Point name, enter the following command:

Step 4 To match a message ID, enter the following command:

Where the message_id is an alphanumeric identifier between 1 and 255. The lower_range is lower range of message IDs. The upper_range is the upper range of message IDs.

Step 5 To match a message length, enter the following command:

Where the min_length and max_length are both between 1 and 65536. The length specified by this command is the sum of the GTP header and the rest of the message, which is the payload of the UDP packet.

Step 6 To match the version, enter the following command:

Where the version_id is between 0and 255. The lower_range is lower range of versions. The upper_range is the upper range of versions.

Step 7 To configure parameters that affect the inspection engine, perform the following steps:

a. To enter parameters configuration mode, enter the following command:

The mnc network_code argument is a two or three-digit value identifying the network code.

By default, the security appliance does not check for valid MCC/MNC combinations. This command is used for IMSI Prefix filtering. The MCC and MNC in the IMSI of the received packet is compared with the MCC/MNC configured with this command and is dropped if it does not match.

This command must be used to enable IMSI Prefix filtering. You can configure multiple instances to specify permitted MCC and MNC combinations. By default, the ASA does not check the validity of MNC and MCC combinations, so you must verify the validity of the combinations configured. To find more information about MCC and MNC codes, see the ITU E.212 recommendation, Identification Plan for Land Mobile Stations.

b. To allow invalid GTP packets or packets that otherwise would fail parsing and be dropped, enter the following command:

By default, all invalid packets or packets that failed, during parsing, are dropped.

c. To enable support for GSN pooling, use the permit response command.

If the ASA performs GTP inspection, by default the ASA 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 ASA 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 a object group that the responding GSN is permitted to send a GTP response to, the ASA permits the response.

d. To create an object to represent the pool of load-balancing GSNs, perform the following steps:

Use the object-group command to define a new network object group representing the pool of load-balancing GSNs.

For example, the following command creates an object group named gsnpool32:

e. Use the network-object command to specify the load-balancing GSNs. You can do so with one network-object command per GSN, using the host keyword. You can also using network-object command to identify whole networks containing GSNs that perform load balancing.

For example, the following commands create three network objects representing individual hosts:

f. To create an object to represent the SGSN that the load-balancing GSNs are permitted to respond to, perform the following steps:

a. Use the object-group command to define a new network object group that will represent the SGSN that sends GTP requests to the GSN pool.

For example, the following command creates an object group named sgsn32:

b. Use the network-object command with the host keyword to identify the SGSN.

For example, the following command creates a network objects representing the SGSN:

g. To allow GTP responses from any GSN in the network object representing the GSN pool, defined in c., d , to the network object representing the SGSN, defined in c., f., enter the following commands:

For example, the following command permits GTP responses from any host in the object group named gsnpool32 to the host in the object group named sgsn32:

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 but you can identify multiple individual IP addresses, one per network-object command, instead of identifying whole networks. The example then modifies a GTP map to permit responses from the GSN pool to the SGSN.

h. To specify the maximum number of GTP requests that will be queued waiting for a response, enter the following command:

where the max_requests argument sets the maximum number of GTP requests that will be queued waiting for a response, from 1 to 4294967295. The default is 200.

When the limit has been reached and a new request arrives, the request that has been in the queue for the longest time is removed. The Error Indication, the Version Not Supported and the SGSN Context Acknowledge messages are not considered as requests and do not enter the request queue to wait for a response.

i. To change the inactivity timers for a GTP session, enter the following command:

Enter this command separately for each timeout.

The gsn keyword specifies the period of inactivity after which a GSN will be removed.

The pdp-context keyword specifies the maximum period of time allowed before beginning to receive the PDP context.

The request keyword specifies the maximum period of time allowed before beginning to receive the GTP message.

The signaling keyword specifies the period of inactivity after which the GTP signaling will be removed.

The tunnel keyword specifies the period of inactivity after which the GTP tunnel will be torn down.

The hh : mm : ss argument is the timeout where hh specifies the hour, mm specifies the minutes, and ss specifies the seconds. The value 0 means never tear down.

j. To specify the maximum number of GTP tunnels allowed to be active on the ASA, enter the following command:

where the max_tunnels argument is the maximum number of tunnels allowed, from 1 to 4294967295. The default is 500.

New requests will be dropped once the number of tunnels specified by this command is reached.

The following example shows how to limit the number of tunnels in the network:

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 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:

You can use the vertical bar (|) to filter the display. Type ?| for more display filtering options.

The following is sample GSN output from the show service-policy inspect gtp statistics gsn command:

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:

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:

RADIUS Accounting Inspection Overview

One of the well known problems is the over-billing attack in GPRS networks. The over-billing attack can cause consumers anger and frustration by being billed for services that they have not used. In this case, a malicious attacker sets up a connection to a server and obtains an IP address from the SGSN. When the attacker ends the call, the malicious server will still send packets to it, which gets dropped by the GGSN, but the connection from the server remains active. The IP address assigned to the malicious attacker gets released and reassigned to a legitimate user who will then get billed for services that the attacker will use.

RADIUS accounting inspection prevents this type of attack by ensuring the traffic seen by the GGSN is legitimate. With the RADIUS accounting feature properly configured, the security appliance tears down a connection based on matching the Framed IP attribute in the Radius Accounting Request Start message with the Radius Accounting Request Stop message. When the Stop message is seen with the matching IP address in the Framed IP attribute, the security appliance looks for all connections with the source matching the IP address.

You have the option to configure a secret pre-shared key with the RADIUS server so the security appliance can validate the message. If the shared secret is not configured, the security appliance does not need to validate the source of the message and will only check that the source IP address is one of the configured addresses allowed to send the RADIUS messages.

Note When using RADIUS accounting inspection with GPRS enabled, theASA checks for the 3GPP-Session-Stop-Indicator in the Accounting Request STOP messages to properly handle secondary PDP contexts. Specifically, the ASA requires that the Accounting Request STOP messages include the 3GPP-SGSN-Address attribute before it will temrinate the user sessions and all associated connections. Some third-party GGSNs might not send this attribute by default.

Configuring a RADIUS Inspection Policy Map for Additional Inspection Control

In order to use this feature, the radius-accounting-map will need to be specified in the policy-map type management and then applied to the service-policy using the new control-plane keyword to specify that this traffic is for to-the-box inspection.

The following example shows the complete set of commands in context to properly configure this feature:

Step 1 Configure the class map and the port:

Step 2 Create the policy map, and configure the parameters for RADIUS accounting inspection using the parameter command to access the proper mode to configure the attributes, host, and key.

Step 3 Configure the service policy and control-plane keywords.

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 ASA can deny SNMP versions 1, 2, 2c, or 3. You control the versions permitted by creating an SNMP map.

You then apply the SNMP map when you enable SNMP inspection according to the “Configuring Application Layer Protocol Inspection” section.

Configuring an SNMP Inspection Policy Map for Additional Inspection Control

To create an SNMP inspection policy map, perform the following steps:

Step 1 To create an SNMP map, enter the following command:

where map_name is the name of the SNMP map. The CLI enters SNMP map configuration mode.

Step 2 To specify the versions of SNMP to deny, enter the following command for each version:

where version is 1, 2, 2c, or 3.

The following example denies SNMP Versions 1 and 2: