Securing UMTS/LTE Networks

Carrier Security includes a variety of measures to protect UMTS Universal Mobile Telephone System, a third generation service (part of the IMT-2000 vision) that is expected to enable cellular service providers to deliver high-value broadband information, commerce and entertainment services to mobile users via fixed, wireless and satellite networks./LTE Long Term Evolution - a standard for wireless broadband communication for mobile devices and data terminals, based on the GSM/EDGE and UMTS/HSPA technologies. It increases the capacity and speed using a different radio interface together with core network improvements. networks from possible attack. The GPRS General Packet Radio System, a non-voice value-added service for faster data transactions over a mobile telephone network, designed for deployment on GSM and TDMA-based mobile networks. GPRS overlays a packet-based air interface on the existing switched network. Tunneling Protocol (GTP GPRS Tunnel Protocol.), the communications protocol of mobile networks, was designed without regard to security, and so any security scheme for GPRS/UMTS networks must account for the GTP protocol. Carrier Security thus enforces a security policy Collection of rules that control network traffic and enforce organization guidelines for data protection and access to resources with packet inspection. that is GTP-aware, capable of identifying and rejecting malicious data or attempts to misuse the protocol, and even inspect GTP-encapsulated data packets.

Additional security measures can be deployed at the Gn Interface between two GSNs within the same PLMN., Go, S1. S11 interface. By deploying a Security Gateway Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources. with advanced cellular network capabilities at the Gn and/or Go S1, s11 interface, the following additional security is available:

• at the Gn/S5 interface:

  • APN Access Point Name - the identifier of an external packet data network. based security policy

• at the Go interface:

  • GSM Global System for Mobile Communications (originally Groupe Speciale Mobile, hence the acronym) - a second generation time-division mobile network standard.-SIP aware firewall security over IPv4 or IPv6

  • SCTP Stream Control Transmission Protocol, SCTP was defined as a transport protocol for SS7 messages to be transmitted over IP networks. and Diameter An authentication, authorization and accounting protocol that has many features not included in the legacy RADIUS protocol. aware firewall security

This chapter presents the various protections that Carrier Security provides for UMTS/LTE networks, and is divided into the following sections:

• GTP Protocol Security covers how Carrier Security scans GTP communications for abuse of the protocol, and includes a summary of the Overbilling attack and the protection that Carrier Security provides.

• GTP-Aware Security Policy covers the principles of establishing a Security Policy that can selectively allow the various signaling messages within GTP, as well as the addresses from which the communications originate.

• Intra-Tunnel Inspection covers how Carrier Security inspects mobile user traffic encapsulated by GTP.

• Configuring Security explains how to create a basic Security Policy and configure the security features available with Carrier Security.

GTP Protocol Security

Carrier Security inspects all GTP tunnel fields in the context of both the packet and the tunnel, which allows the definition and enforcement of a granular, GTP-specific Security Policy that protects both network assets and subscribers from possible attack. Carrier Security secures the GTP protocol in the following ways.

• GTP protocol enforcement ensures the legitimate use of the GTP protocol, protecting GSN GPRS Support Node. servers from harmful traffic. The Carrier Security parser verifies that each GTP message contains the correct set of Information Elements (IE Information Element - a group of information which may be included within a signaling message or data flow.) in the proper sequence.

• GTP Stateful Inspection ensures that only legitimate GTP traffic passes through the gateway. For example, data packets (G-PDUs) and PDP Packet Data Protocol - a network protocol used by an external packet data network (usually IP). update messages are allowed only for open PDP contexts/sessions. Carrier Security detects any tampering with the state and rejects such traffic.

• PDP context/session timelines are strictly verified, and operations on unestablished or deleted contexts are disallowed.

Understanding the Overbilling Attack

The Overbilling attack targets a cellular operator's network, reputation, and bottom line. The attack takes advantage of a weakness in the architecture of GPRS networks where previously used IP addresses are reassigned to other devices. The attack takes place as follows:

1. Attacker connects to cellular network as a legitimate subscriber.

2. An SGSN Serving GSN - a GPRS Support Node./SGW Serving Gateway - a LTE support node. assigns the mobile device an IP address.

3. Attacker uses a malicious server to continuously send packets to the address assigned in step 2.

4. Attacker ends the GPRS connection and the PDP context Information sets held in MS and GSNs for a specific PDP address./session is deleted.

5. The malicious server ignores TCP FIN packets and continues to send packets to the address assigned in step 2.

6. An innocent subscriber requests service and the SGSN/SGW reassigns the original IP address.

7. The data traffic that the malicious server is sending to that address is charged to the new device's account, without the knowledge of its owner. The device ignores the traffic as noise, but its owner is charged for the time-slots occupied.

8. Attacker repeats the process, adding IP addresses to the attack each time a new one is assigned.

When invoices are distributed, the company is attacked again by irate customers who claim they didn't use this bandwidth. The net effect of this attack is inflated receivables estimates, a swamped customer/billing center, loss of customer loyalty, and great aggravation for the customer. The attacker in this way compromises the cellular provider's good name.

The Check Point Solution to the Overbilling Attack

This attack was officially reported to the GSM Association in 2002, and the Carrier Security solution is the GSMA-approved Enabling Overbilling Attack Protection solution.

Briefly, Carrier Security protects GPRS networks from Overbilling attacks in this way:

• Carrier Security is deployed on the Gn/S5 interface, and a standard Security Gateway is on the Gi Reference point between GPRS and an external packet data network./SGi interface.

• Whenever a GTP tunnel is deactivated, Carrier Security notifies the Security Gateway on the Gi/SGi interface to block all packets belonging to connections of the de-activated tunnel. Thus the packets sent by the malicious server are stopped at the Security Gateway, and no further steps need to be taken.

GTP-Aware Security Policy

Carrier Security provides the ability to define a single GTP-aware Security Policy using Check Point's intuitive GUI tools. The next section describes how you can use GSN address filtering, GTP Tunnel In GTP version 0 GTP tunnel is defined by two associated PDP Contexts in different GSN nodes and is identified with a Tunnel ID. (1) In GTP version 1/2, a GTP tunnel in the GTP-C plane is defined for all PDP Contexts/sessions with the same PDP address and APN (for Tunnel Management messages), or for each MS (for messages not related to Tunnel Management). A GTP tunnel is identified in each node with a TEID, an IP address and a UDP port number. (2) In GTPv1 GTP tunnel in the GTP-U plane is defined for each PDP Context in the GSNs. While in GTPv2 a bearer is used. (3) In GTP version 2, a GTP-C tunnel is defined for all PDP sessions with same PDP address and TEID,For GTP-U plane traffic a Bearer is created. (4) In all versions, a GTP tunnel is necessary to forward packets between an external packet data network and an MS user., Path, and Mobility Management signaling messages to create a GPRS Security Policy.

GSN Address Filtering

The ability of Carrier Security to identify the various aspects of GTP traffic allows for the enforcement of security rules in a granular manner. One such capability is the ability to enforce the creation and update of PDP contexts/sessions by defined GSN addresses.

• PDP context/session creation is enforced according to directional security rules that identify the range of SGSN/SGW addresses that are allowed to create tunnels.

• PDP context/session updates, redirection and handover are enforced according to directional security rules. In addition, Carrier Security strictly enforces SGSN/SGW handovers and GSN redirections according to predefined address ranges and sets (Handover Groups).

GTP Message Type Filtering

GTP Message Type Filtering refers to the gateway's ability to allow only those message types categorized by an interface profile. Each interface profile represents a list of message types to enforce (accept or drop actions).

You can select an interface profile for a particular service. For example if you select an interface profile named "S8" that includes message types: 1, 2, 3, 4, 5 and then enforce a DROP action for this service, all of the message types are dropped.

There is also an option to set a "Custom" message type field. Use this field to manually input message types that you want to accept or drop.

Note that:

• GTP Message Type Filtering supports GTPv1 and GTPv2 only.

• "Any" is the default option - when selected, the relevant service matches any message type.

• The Gateway enforces control message types after it establishes a GTP tunnel. If according to the service an incoming message type does not have permission to perform actions on the GTP tunnel, the gateway does not match the packet.

GTP Tunnel Management / User Traffic

Carrier Security recognizes and can control the access of GTP Tunnel management services to your network. You can build simple security rules to allow all GTP user traffic on your network, or opt for a more refined policy through the various customizations possible with Carrier Security. The following sections discuss the various ways you can secure user traffic on your UMTS/LTE network.

Tunnel Management and User Traffic Service

Tunnel management services are those parts of the GTP protocol that carry the actual user traffic - voice, data, for example. Carrier Security allows you to build security rules to allow this traffic within your network. Use these services to enable communication between incoming traffic and your GSNs. Tunnel management services on Carrier Security are predefined as:

• gtp_v0_default, which addresses message types defined in 3GPP TS 09.60.

• gtp_v1_default, which addresses message types defined in 3GPP TS 29.060.

• gtp_v2_default, which addresses message types defined in 3GPP TS 29.274.

For more information about using tunnel management services in security rules, see: Creating Security Rules with GTP Services

GTP Service Filters

You can be more selective than simply allowing all tunnel traffic, however. You can build security rules to more precisely select which user traffic can cross the firewall. Through the use of GTP-aware filters, Carrier Security provides the ability to limit the creation of PDP contexts/sessions to traffic that matches specific parameters that you define. You can set up a GTP service filter that matches traffic by:

• APN

• IMSI International Mobile Subscriber Identity - a user's unique ID in GSM/GPRS networks. (MCC, MNC) Prefix

• MS-ISDN Mobile Station International ISDN Number - the standard international telephone number used to identify a given subscriber. Prefix

• APN Selection Mode

• LDAP Group

• Radio Access Technology

• GTP Message Type

As cellular operators tend to sort their LDAP databases by either IMSI or MS Mobile Station - a portable device that connects subscribers to a wireless network, for example a cellular phone or a laptop with a cellular modem.-ISDN, Carrier Security can identify whether a user belongs to a specific LDAP group by IMSI or MS-ISDN prefix.

By customizing the pre-defined user traffic services gtp_v0_default, gtp_v1_default, gtp_v2_default, or creating new customized services, you can build a logical "AND" argument to choose what specific characteristics to match, and then configure a security rule Set of traffic parameters and other conditions in a Rule Base (Security Policy) that cause specified actions to be taken for a communication session. to accept this specific class of user traffic. While predefined GTP services are provided with Carrier Security, it is recommended that you create new services for customization.

For configuration information, see: Customizing GTP Services

End User PDU Protections

Carrier Security protects the integrity of Protocol Data Units (PDUs).

• Sequence Number Validation - Carrier Security verifies PDU Protocol Data Unit - a packet. sequence numbers for both signaling and user traffic. For configuration information, seeGTP PDU Integrity Tests

• Flow Labels Validation - In GTP ver. 0, when two GTP tunnels are open on one device, they have the same tunnel ID. To distinguish between tunnels, Carrier Security adds packet flow labels to the tunnel ID. To secure this solution, Carrier Security can validate that the flow labels assigned belong to packets of a similar flow.

• Multiple GGSN/PGW Interface Support - GTP ver. 1/2 allows xGSNs to reply to PDP context/sessions requests from a different interface than the one to which the request was sent. This capability, useful for load balancing, can make a system vulnerable to Session Hijacking. Carrier Security is able to protect against Session Hijacking through the use of Handover Groups. For configuration information, see Secure Connectivity Features

End User Address Modes

Carrier Security can be configured to block PDP context creations from MSs with static IP addresses.

For configuration information, see Allow usage of static IP address in Secure Connectivity Features

IPv6 T-PDU Security

Carrier Security enforces the proper use of IPv6 T-PDUs encapsulated inside IPv4 GTP G-PDUs. The IPv6 End User Address Information Element in the Create PDP Context/session message is inspected and allowed upon proper validation. The IPv6 End User address in the T-PDU An original packet from an MS or a network node in an external packet data network. is then tested for GTP Anti-Spoofing. For more information, see: GTP Address Anti-Spoofing

Carrier Security also supports End User Address Mode IPv4v6 that can hold two IP address types at the same time (one IPv4 and one IPv6).

Session Hijacking Protection through GSN Handover Groups

When an SGSN/SGW sends data to a GGSN Gateway GSN (GPRS Support Node)./PGW Packet Data Network Gateway - an LTE support node. and awaits a reply, an unprotected GPRS/UMTS network may become exposed to what is known as Session Hijacking. Session Hijacking is a type of attack that involves eavesdropping on an established communications session and assuming the identity of an authenticated user. It can occur during handover, redirection, and by permitting "unknown" GGSNs/PGWs to reply to SGSN/SGW-initiated communications.

Handover, which enables subscribers to seamlessly move from one area to another with no interruption of active sessions, is a fundamental feature of UMTS/LTE. But this ability to move from SGSN/SGW to SGSN/SGW can expose the cellular operator to Session Hijacking. In GTP, a GGSN/PGW will relinquish control of a tunnel to any device from which it receives a PDP context/session update request message. This can be exploited to hijack GTP tunnels or cause a Denial of Service (DoS).

Redirection, which enables load sharing among xGSNs, is also vulnerable to Session Hijacking. In some GTP signaling messages, a malicious xGSN can redirect the handling of subsequent messages to another device by inserting that device's IP address in the message.

A cellular operator may choose to set up multiple GGSNs, and the GTP protocol allows a GGSN/PGW other than the one that received an SGSN/SGW message to reply to that message. This practice can leave a network vulnerable to Session Hijacking, where a malicious GGSN/PGW responds to an SGSN/SGW message before the real GGSN/PGW can respond. Because the SGSN/SGW has been configured to allow any response, it directs traffic to the malicious GGSN/PGW.

Check Point's Solution - Handover Groups

To protect against this threat, Carrier Security uses Handover Groups, sets of IP addresses among which handovers are allowed. Handover Groups typically consist of the IP addresses of a UMTS/LTE operator's GSNs.

Carrier Security strictly enforces Handover Groups, allowing handover and redirection only within the group. In addition, tunneled and signaling packets are matched according to tunnel ID against a tunnel internal state table. Improper use of GTP signaling is blocked and logged. For configuration information, see Creating a GSN Handover Group

Deactivating Session Hijacking Protection

The Session Hijacking protection is turned on by default. You can deactivate it with one command.

To deactivate the Session Hijacking protection, run this command on the Security Gateway in the Expert mode:

fw ctl set int gtp_allow_ho_bypass 1

To activate the Session Hijacking protection again, run this command on the Security Gateway in the Expert mode:

fw ctl set int gtp_allow_ho_bypass 0

To permanently disable the Session Hijacking protection, add this line to the $FWDIR/boot/modules/fwkern.conf file and reboot:

gtp_allow_ho_bypass=1

GTP Path Management Message Support

According to the protocol specification 3GPP, a path is a UDP/IP connection used to multiplex GTP tunnels between GPRS network resources, such as from one xGSN to another. The GTP signaling messages that maintain the GPRS tunnels are known as Path Management. Carrier Security allows you to build security rules to allow this traffic within your GPRS network. Use these services to enable communication among your xGSNs.

Path management services on Carrier Security are predefined as:

• gtp_v0_path_mgmt, which addresses message types defined in 3GPP TS 09.60.

• gtp_v1_path_mgmt, which addresses message types defined in 3GPP TS 29.060.

• gtp_v2_path_mgmt, which addresses message types defined in 3GPP TS 29.274.

For more information about using path management services in security rules, see xCreating Security Rules with GTP Services

Use these Carrier Security features to protect your network from various attempts to abuse Path Management signaling messages:

• GTP Echo Stateful Inspection - ensures that there is a matching echo request in the log before allowing an echo response packet through the Security Gateway.

• Limit Echo Rate - The GTP protocol states that "an echo request shall not be sent more often than every 60 seconds per path." If desired, you can enforce echo requests as the protocol specifies, or to whatever interval you want. Carrier Security can be configured to restrict the echo rate per GTP path or allow GTP echo exchange only between GSNs with an active PDP context.

• Limit Echo Retransmissions- ensure that more than a defined amount of echo messages will not be sent on the same path.

• GTP signal packet rate limit enforcement -can be configured to limit the rate of signaling PDU to prevent signaling flooding or Denial of Service (DoS) attacks.

• GTP HO packets rate limit enforcement - can be configured to limit the rate of signaling packets from handover group to prevent flooding or Denial of Service (DoS) attacks.

For configuration information of Path Management, see: Limiting Signaling Rates

GTP Mobility Management Message Support

Mobility Management messages are the control plane messages as defined in 3GPP TS 23.060 and 3GPP TS 24.008. They are sent between SGSNs during the GPRS Attach and Inter SGSN Routing Update procedures in GTPv1 while in GTPv2 they are handled by the MME Mobility management element - in charge of mobility management in GTPv2. Carrier Security enforces protocol integrity and security policy for mobility management messages. Carrier Security also allows you to isolate these messages within GTP packets and permit them access to your network nodes, while denying access to other types of GTP traffic. This capability can be used to enhance network security by allowing only mobility management GTP message traffic between xGSNs.

Carrier Security allows you to build security rules to allow this traffic within your GPRS network. Use these services to enable mobility management communications among your xGSNs. Mobility Management services on Carrier Security are predefined as:

• gtp_mm_v0_default, which addresses message types defined in 3GPP TS 09.60

• gtp_mm_v1_default, which addresses message types defined in 3GPP TS 29.060

• gtp_mm_v2_default, which addresses message types defined in 3GPP TS 29.274

See Creating Security Rules with GTP Services

For more information about using path management services in security rules, see Creating Security Rules with GTP Services.

GTP MS Info Change Reporting Message Support

The Location Change Reporting messages defined here are control plane messages used in accordance with 3GPP TS 23.060 [4], section 15.1.1a, and 3GPP TS 23.203 [39].

Note - The 3GPP defines this service only on the GTPv1 protocol.

MS Info Change Reporting service does not exist by default in SmartConsole Check Point GUI application used to manage a Check Point environment - configure Security Policies, configure devices, monitor products and events, install updates, and so on.. It is necessary to manually define it.

To define the MS Info Change Reporting service in SmartConsole:

1. From the Services tree, right-click Other > New Other.

   The Other Services Properties window opens.

2. In Name, enter:

   gtp_v1_ms_info

3. In IP Protocol, enter:

   17

4. Click Advanced.

   The Advanced Other Service Properties window opens.

5. In the Match field, copy this text:

   (dport = GTP_C_V1_PORT,GTP_MSGTYPE = 0x80) or (sport = GTP_C_V1_PORT,GTP_MSGTYPE = 0x81),gtp_get_ver(sr8, 3),sr8 = 1,set r_mflags (r_mflags | MFLAGS_UDP_REPLY),set r_mhandler &gtp_code,((set sr3 0, get <conn, 5> from gtp_paths to sr3) or record <conn,5; r_crule, 0> in gtp_paths)

6. Select Accept Replies.

7. Keep the defaults of other options.

8. Click OK.

   The Other Service Properties window opens.

9. Click OK.

   The gtp_v1_ms_info service is now defined and can be used in the Rule Base All rules configured in a given Security Policy. Synonym: Rulebase.. By default, the gateway applies stateful inspection on MS Info messages. Stateful inspection can be disabled by setting a kernel variable.

To Enable or Disable Stateful Inspection on MS Info Messages:

1. On the Carrier Security Gateway, edit this file:

   $FWDIR/boot/modules/fwkern.conf

2. If the file does not exist, create it:

   touch $FWDIR/boot/modules/fwkern.conf

3. Add one of these lines:

   Line	Meaning
   gtp_enforce_ms_info_state=0	Disable stateful inspection on MS Info messages
   gtp_enforce_ms_info_state=1	Enable stateful inspection on MS Info messages

4. Save the changes in the file and exit the editor.

5. Reboot the Security Gateway.

For more details about kernel parameters, see sk26202.

Dynamic Configuration of New GTP Messages and Information Elements

Carrier Security is aware of all commercially used 3GPP Release-13.3.0 GTP messages and Information Elements. It is however possible that new GTP messages (from 3GPP Release-13.3.0 and higher) and new GTP Information Elements will be used by GSN equipment in the future, and that these messages and Information Elements will not be known to Carrier Security "out of the box". Another scenario is when GSN equipment is using different release versions than the version Carrier Security supports. To expedite support for these innovations/mismatches, new GTP messages and Information Elements can be defined on the Carrier Security management station.

Intra-Tunnel Inspection

One of the fundamental features of GTP is to encapsulate underlying (also known as end user or subscriber) protocols within the UMTS/LTE backbone network. User data is tunneled between GSNs, which means the data payload is encapsulated inside a GTP packet. Carrier Security can inspect the GTP traffic and enforce a Security Policy based on the encapsulated protocols. The following sections deal with the ability of Carrier Security to secure the GPRS network from malicious tunneled data.

GTP Address Anti-Spoofing

Spoofing is the act of impersonating an end user IP address, usually for malicious purposes. Carrier Security enforces the proper use of end user IP addresses for IPv4 and IPv6 end user headers in tunneled GTP packets (G-PDUs). During tunnel establishment, the end user's IP address is exchanged. Carrier Security verifies that all G-PDUs that are exchanged using this tunnel use a matching IP address as the user side IP address.

During PDP context/session establishment, an end user IP address is exchanged. This address is stored in the state information table of the tunnel, and is used by the MS in the subsequent G-PDUs. In the GTP dynamic mode, this IP address is allocated by the GGSN/PGW and is sent back in the create PDP context/session reply. In the static mode the subscriber has a constant (static) IP address. In this case the MS sends this IP address to the SGSN/SGW, who in turn sends it to the GGSN/PGW in the create PDP context/session request.

Carrier Security can be configured to inspect each G-PDU A user data message, comprising a G-PDU and a GTP header. on a specific tunnel for malicious use of the end user IP address. For configuration information, see GTP Intra Tunnel Inspection and Enforcement.

GTP Address Anti-Spoofing for IPv4

In IPv4, the end user IP address in the tunneled IP packet's header is compared to the tunnel's established end user IP address. If the addresses are different, the packet is dropped and logged.

GTP Address Anti-Spoofing for IPv6

In IPv6, the end user IP address in the tunneled IP packet's header is compared to the tunnel's established end user IP address. Carrier Security allows the following IPv6 address scenarios:

• The prefix of the IPv6 address equals the tunnel's established end user IPv6 prefix.

• If the IPv6 address is a Link local address and its identifier equals the tunnel's established end user IPv6 identifier.

In addition, Carrier Security allows the following IPv6 address types.

• An unspecified address :: (0::0) in T-PDUs originating from an SGSN.

• A Multicast IPv6 address in T-PDUs originating from a GGSN.

If an IPv6 address appears in any other form, the packet is dropped and logged.

Block GTP in GTP

An SGSN converts mobile user traffic to encapsulated GTP when passing the data to a GGSN. This encapsulation can be exploited by an attacker, whereby a mobile user injects a forged GTP packet, which is in turn encapsulated by the SGSN. This packet could contain an instruction to the GGSN, such as to disconnect users. Carrier Security can detect and block GTP encapsulated inside GTP.

For configuration information, see: GTP Intra Tunnel Inspection and Enforcement.

MS to Gn/S5 Network Policy Enforcement

If the IP addresses of the servers on an unprotected Gn/S5 network were to become known to a potential attacker, a Mobile User could exploit the fact that the GGSN/PGW will route back to the Gn/S5 network T-PDU packets with a destination address of the Gn/S5 network, and initiate a Telnet session or other forms of unauthorized communications to attack the system. While some GGSNs/PGWs are capable of blocking this type of attack, others are not.

Carrier Security can be configured to deny any attempt by a Mobile User to send data to the Gn/S5 network. This is an extension of the Block GTP in GTP feature, i.e., disabling additional potential attacks.

MS to Gn network traffic is blocked by creating an APN object to represent the Gn/S5 network and then blocking all user traffic from IP addresses belonging to real APNs destined for the Gn/S5 network. For configuration instructions, see Blocking MS to Gn/S5 Network Traffic

APN Domain End User Address Enforcement

An Access Point Name (APN) provides routing information for SGSNs/SGWs and GGSNs/PGWs. The APN, which is written as a string, contains the identity of the external service requested (the Operator ID) by the MS, and routing information (the Network ID). The two IDs are written something like this:

Operator ID: MNC1234.MCC5678.gprs

Network ID: example.net

Check Point has taken APNs a step further, integrating support of domains with APNs. A domain, consisting of addresses, IP subnets, address ranges or groups thereof, may be configured on an APN object. APN Domains specify the range of IP addresses that are assigned to MSs upon connecting to an APN. For example, you can create one APN called Content_Servers that assigns a range of IP addresses from 10.1.1.1 to 10.1.10.255, and another called Internet, that assigns from a range of 192.168.1.1 to 192.168.10.255.

You can also use APN objects to define rules that specify things like: from which networks PDP contexts/sessions for enterprise APNs may be created, or to grant the CEO sole access to a specific APN, or to accept Handovers only between specified networks.

When a PDP context/session is created in which the exchanged end user IP address does not belong to the configured domain, the context will be dropped and logged.

Wildcard APN Matching

To further enhance the ability to define and include certain APN addresses in security rules, Carrier Security allows the use of wildcards in APN matching. For example, you can create an APN object called *.example.gprs that will match APN object strings like 123.example.gprs and abc.example.gprs.

For configuration information, see:

• Creating an APN Object

• GTP Intra Tunnel Inspection and Enforcement

MS to MS Policy Enforcement

Carrier Security can be configured to prevent undesirable traffic between two end users (MSs) simultaneously connected to a PLMN Public Land Mobile Network.. There are two variations of this capability: the ability to block intra-tunnel traffic between MSs of the same APN, and the ability to block user plane traffic between MSs of different APNs.

It is possible to enforce the correct use of server side IP addresses in tunneled GTP packets (G-PDU). Server side IP addresses refer to the IP address in the G‑PDU header not belonging to the mobile subscriber, but to the server (host) with which the MS is communicating. For G-PDUs traveling from the SGSN/SGW to the GGSN/PGW, the destination IP address of the G-PDU if considered to be the server side address. For G-PDUs traveling from the GGSN/PGW to the SGSN/SGW, the source IP address of the G-PDU is the server side address.

Each G-PDU is inspected for malicious use of server side IP address. The server side IP address in the tunneled IP packet's header is compared to the relevant predefined APN address domains, and if the address is found to be in one of those disallowed domains for this tunnel, then the packet is dropped and logged.

Note the following:

• MSs that are connected using tunnels of APNs that are configured to block non-desirable MS to MS traffic are protected.

• APN domains that are searched for possible violation of the inter-APN enforcement are global (all defined APN domains, except the one in whose context we are currently inspecting), and therefore they are not dependent on the current APN context.

• Only local APNs need to be defined in the system for the purpose of this feature. This feature does not require configuration of roaming providers' APNs. The reason for this is that packets of PDP contexts belonging to roaming operators' APNs should never connect to the local GGSN.

• Configuration of only local APNs will not interfere with visiting MS traffic since GTP tunnels used by such users belong to external operator APNs.

For more information on configuring APN objects, see: GTP Intra Tunnel Inspection and Enforcement.

Mobile Subscriber Traffic Security

Mobile Subscriber Traffic Security, sometimes referred to as Full Intra Tunnel Inspection, enables real Security Gateway filtering for T-PDU traffic (i.e., decapsulated G-PDU). T-PDU traffic can now be processed by the Security Gateway inspection engine. This protection is selectable per GTP service, and effectively enables the following security measures for Mobile User traffic:

• Security Gateway Policy, including optional Anti-Spoofing protection.

• IPS Check Point Software Blade on a Security Gateway that inspects and analyzes packets and data for numerous types of risks (Intrusion Prevention System). protections.

• Application protections.

• Event Logging and Reporting. An IMSI field, which indicates which mobile user is linked to a logged event, can be added to every log generated, thereby eliminating reliance on End User IP address for identification.

This feature works by first passing the G-PDU through the regular GTP engine. If the G-PDU matches a GTP service where Mobile Security Traffic filtering has been enabled, the G-PDU is decapsulated and then analyzed with the security measures listed above. If the decapsulated packet is dropped, the outer packet will be dropped as well.

Mobile Subscriber Traffic Security can be enforced per GTP service. This means that a Security Policy can be implemented that inspects traffic from certain partners, and not from others. Intra Tunnel Inspection is fully supported, however, only with IPv4 in environments with unfragmented external (G-PDU) and internal (T-PDU) packets, and without overlapping IP addresses.

This is a very powerful feature - enabling true and full intra tunnel inspection for user traffic at the Gn, Gp Interface between two GSNs in different PLMNs. The Gp interface allows support of GPRS network services across areas served by the co-operating GPRS PLMNs. or S5/S8 The interface between SGW to PGW on the HPLMN and between PLMNs interfaces. To enable these protections on GTP services, see Customizing GTP Services.

Configuring Security

This configuration information refers only to the cellular network features provided by Carrier Security.

For information about configuring other aspects of Check Point software, refer to the applicable documentation.

You should have:

1. Installed:

   • Management Server Check Point Single-Domain Security Management Server or a Multi-Domain Security Management Server.

   • SmartConsole GUI

   • Carrier Security Gateway

2. Opened SmartConsole and connected to the Management Server.

The initial configuration of Carrier Security involves:

• Creating GSN Objects

• Creating a GSN Handover Group

• Setting up a Security Policy

Follow these steps to set up basic security. To customize your security policy, see: Enforcing a More Granular GTP Security Policy.

Creating GSN Objects

Use SmartConsole to create objects representing your GSNs and the GSNs of your roaming partners.

Note - To create GSN objects for your roaming partners, you should obtain a list of their IP addresses.

1. For the Home PLMN, define a Host object for an xGSN.

2. In the Network Objects tree, right click on Nodes, and select New > Host.

3. Enter an identifying name and the xGSN's IP address.

4. Repeat for each SGSN/SGW and GGSN/PGW on your network.

5. For the roaming partners, define a Host object for an xGSN.

   • If the GSN has a single IP address, right click on Nodes, and select New > Host. Enter an identifying name and the xGSN's IP address. Repeat for each roaming partner SGSN/SGW and GGSN/PGW.

   • If the GSN has a range of IP addresses or subnets, right click on Network Objects, and select New > Address Range. Enter an identifying name and define subnets or IP address ranges to represent the packets coming from or intended for the GSN. Repeat for each roaming partner SGSN/SGW and GGSN/PGW.

Creating a GSN Handover Group

GSN Handover Groups prevent Session Hijacking and enable secure handover, redirection, and multiple GGSN interface support on Carrier Security. You should create Handover Groups for your own GSNs, and for your roaming partners' GSNs. Typically there will be one GGSN/PGW Handover Group and one SGSN/SGW Handover Group for each operator.

After you define your Handover Groups, include them as source and destination addresses in the rule base in order to allow handover, redirection, and multiple GGSN/PGW interface support for the GSNs that you included in the Handover Groups.

To define a GSN Handover Group:

1. In the Network Objects tree, right click on Groups, and select New Groups > GSN Handover Group.

2. Give the group a name, such as SG_Home_HG, where SG stands for SGSN/SGW.

3. Add the appropriate GSN objects you created in Creating GSN Objects.

4. To rate limit signaling packet from the GSN handover group select Enforce GTP signal packet rate limit from this group and enter an integer value (in PDU/sec).

To simplify the Security Policy rule base, it is recommended that you:

• Define a group consisting of your entire home PLMN GSNs.

• For each of your partner networks, define two groups:

• one consisting of all of its SGSNs/SGWs or IP address ranges as appropriate

• one consisting of all of its GGSNs/PGWs or IP address ranges as appropriate

Configuring GSN Handover Group Limits

You can specify tunnel limits, for GTP handover groups. A newly created tunnel counts against the limit for handover groups on both sides of the tunnel.

To configure GSN handover group limits:

1. Connect with Database Tool (GuiDBEdit Tool) (sk13009) to the Management Server.

2. Search for gtp_groups_limit_enabled and set the value to true.

   Search for gtp_group_percentage_limit and set the value to an integer that defines the percentage (0 - 100) of the tunnel capacity assigned to all handover groups.

   The default value is 0 (unlimited).

   This percentage applies to all groups for which no limit is defined explicitly.

3. Search for gtp_tunnels_limit.

   This parameter is the maximum number of GTP tunnels that a handover group can create. Set this limit to make sure that one group does not take too much of the GTP tunnel allowance.

4. Search for gtp_tunnel_group_limit in each handover group.

   This value is an integer that defines the maximum number of tunnels that can be open for the specified group. The default value is 0 (not defined).

   The explicitly defined gtp_tunnel_group_limit has precedence over the gtp_groups_percentage_limit definition.

Creating Security Rules with GTP Services

Allow GTP traffic on your network by creating rules using GTP services. There are six pre-defined GTP related services in Carrier Security:

• Path management - gtp_v0_path_mgmt and gtp_v1_path_mgmt (User Defined services) or V2.

• Tunnel management - gtp_v0_default, gtp_v1_default and gtp_v2_default (Tunnel services and User traffic).

  You can use these predefined defaults or create a custom GTP service.

• Mobility management - gtp_mm_v0_default and gtp_mm_v1_default (Mobile User services).

Creating a new GT Tunnel Management Service

This service does not include path management

To create a new GTPv2 Service

1. In SmartConsole, open the Object Explorer.

2. Click > New > Service > GTP.

3. Enter a name for the new service.

4. On the General page, select a GTP version: V0, V1, or V2.

5. If you selected the V2 Additional service, select one or more service types:

   • Trace Management

   • CS Fallback and SRVCC

   • Restoration and Recovery

For the Home PLMN

1. Create a Tunnel Management rule to restrict tunnels and user traffic on your network to your GGSNs from only your SGSNs.

2. Create a Path Management rule to enable path management services between SGSNs and GGSNs.

   Note - Use the GSN Handover Groups you created in Creating a GSN Handover Group as the Source and Destination objects in the security rules.

The next table depicts a basic security policy consisting of these two rules:

Basic Security Policy

To enable Mobility Management between SGSNs, the rule should look something like this:

Mobility Management Rule

For Roaming Partners

1. Add an inbound roaming traffic Tunnel Management rule to allow mobile subscribers to my network to connect from partners' SGSNs to my GGSNs.

2. Add an outbound roaming traffic Tunnel Management rule to allow mobile subscribers of my roaming partners' networks to connect to their GGSNs through my local SGSNs.

3. Add a Path Management rule to enable those services over both networks.

4. Add a reverse rule to accept PDUs from the GGSN to the SGSN on a previously established PDP context even if these PDUs are sent over ports that do not match the ports of the established PDP context.

   Roaming partner security rules should look something like this:

   Roaming Partner Rules:

   Source	Destination	VPN	Services & Applications	Action	Track	Install On	Comment
   PartnerA_HG	GG_Home_HG	Any	gtp_v0_default gtp_v1_default gtp_v2_default	Accept	Log	Policy Targets	Roaming for my users on partner's networks
   SG_Home_HG	PartnerA_HG	Any	gtp_v0_default gtp_v1_default gtp_v2_default	Accept	Log	Policy Targets	Roaming for partners' users on my network
   PartnerA_HG   SG_Home_HG   GG_Home_HG	PartnerA_HG   GG_Home_HG   SG_Home_HG	Any	gtp_v0_path_mgmt gtp_v1_path_mgmt gtp_v2_path_mgmt	Accept	Log	Policy Targets	Path management across networks

   Notes: Under Service, specify either the GTP service, as appropriate to the partner GSN. In rules with a GTP service, the Reject action rejects the connection and sends the subscriber a "User Not Authenticated" PDU. GTP-U messages cannot match GTPv2 services in Firewall rules. You must also include the GTPv1 service in the rule to match GTP-U messages.

5. Install the Security Policy on the Carrier Security Gateways.

To further refine your Security Policy, see: Enforcing a More Granular GTP Security Policy

Enabling Overbilling Attack Protection

Protection against Overbilling attacks can be implemented quickly and simply on networks with both a Carrier Security Gateway and a Security Gateway on the Gi interface.

Carrier Security resolves the vulnerability inherent in the GTP protocol by sending a clean state message to the Security Gateway whenever a PDP context is deleted. Configuration of this feature differs between systems where the Gi/SGi and Carrier Security Gateways are managed by the same management server, and those managed by different management servers.

If the SGi and Carrier Security Gateways are managed by One Management Server

To protect your UMTS/LTE network from an Overbilling attack, do the following:

1. Create an Overbilling Group object:

   1. From the Network Object tree, right click on Group, then select New Groups > Simple Group.

   2. Name the group (e.g., overb_gw_group).

   3. Select and add to the group the gateways that will receive the clean state message whenever a PDP context is deleted.

   4. Click OK.

2. Enable Overbilling attack protection:

   1. From the Network Object tree, double click the Gateway object of a Carrier Security Gateway.

   2. Select the Carrier Security tab.

   3. Check the Send "clean state" request on each GTP tunnel Deactivation property.

   4. Select as the Target the group you created in step 1.

   5. Repeat for each Carrier Security Gateway.

      Define a rule allowing FW1_sam traffic from the Carrier Security cluster Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing. IP address to the Gi/SGi Gateways/Members.

      Source	Destination	Service	Action
      Carrier Security Gateway	Security Gateway	FW1_sam	Accept

3. Install the security policy on each Security Gateway.

If the Gi/SGi and Carrier Security Gateways are managed by Different Management Servers

Enabling Overbilling protection in environments with multiple management servers is a more complicated procedure. You must make modifications to the management and gateways for both Security Gateways and Carrier Security, including:

• Add a rule to the rule base that allows SAM traffic from the Carrier Security Gateway to the Security Gateway.

• Set SAM traffic to use SSL.

• Establish a trust relationship between the gateways.

• Follow the steps below precisely, and then test the solution according the instructions in Testing Overbilling Protection.

On the Carrier Security Management Server

On the Management Server, use SmartConsole to define each Gi Member as an Externally Managed Gateway.

1. Enter the IP address for the object, and select the Firewall option.

   There is no need to define the exact topology of each externally managed Gi Gateway/Member. In the case of a Gi cluster, the IP address used should be the unique IP of the Cluster Member Security Gateway that is part of a cluster., and not the IP address of the cluster itself.

2. Add the Gi members into the Overbilling group.

On the Carrier Security Gateways

1. Set SAM to use SSL on Carrier Security Gateways by updating the file $CPDIR/conf/sic_policy.conf.

   1. Use a text editor to open the file, and search for the line [Outbound rules].

   2. Insert a new line with this format:

   ANY ; "DN" ; ANY ; sam ; ssl

   "DN" is the unique name of each Gi Gateway/Member, as it appears in the Gi SmartConsole, on the main page of the Gi object.

   For example, if the name of the Gi management is gi-mgmt, and the name of one of the Gi Gateways/Members is gi-mod1, the DN would be something like "CN=gi-mod1,O=gi-mgmt..7au2cw".

   And so, the line in sic_policy.conf would look like:

   ANY ; "CN=gi-mod1,O=gi-mgmt..7au2cw" ; ANY ; sam ; ssl

   Note - The double quotes in the line are mandatory. Be sure to use double quotes ("), and not single quotes (') when writing the line in sic_policy.conf.

   For every additional Gi gateway/Member you wish to use, add additional lines below the lines you have just added. Be sure to use the correct DN for each new Gi gateway.

2. Establish a trust relationship between Security Gateways by running this command on each Carrier Security Gateway/Member:

   fw putkey -ssl -p [<secret>] [<IP address of Gi gateway/Member>]

   [<secret>] is any string that will be used in the first authentication between the Carrier Security and the Gi/SGi Gateways. The string used here must match the string used in the "fw putkey" command which you run on the Gi/SGi Gateway/Member.

   For additional Gi/SGi Gateways/Members, run the "fw putkey" command again with the IP address of that member.

   Make sure that in all cases you use the unique IP address of each cluster member, and not the IP address of the cluster itself.

3. Run cpstop and cpstart on all Carrier Security Gateways/Members on which you have edited sic_policy.conf for the changes to take effect.

On the Gi/SGi Management

1. Define a node object using the IP address of the Carrier Security cluster. Note that you need to use the Carrier Security cluster IP address associated with the interface facing the Gi Gateway/Cluster.

2. Define a rule allowing FW1_sam traffic from the Carrier Security cluster IP address to the Gi Gateways/Members.

   Source	Destination	Service	Action
   Carrier Security Gateway	Security Gateway	FW1_sam	Accept

3. Install the policy on the Carrier Security members.

On the Gi/SGi Gateways:

1. Set SAM to use SSL on Security Gateways by updating the file $CPDIR/conf/sic_policy.conf.

   1. Use a text editor to open the file, and search for the line [Inbound rules].

   2. Insert a new line with this format:

   ANY ; "DN" ; ANY ; sam ; ssl

   "DN" is the unique name of each Carrier Security Gateway/Member, as it appears in the Carrier Security SmartConsole, on the main page of the Carrier Security Security Gateway / Cluster object.

   For example, if the name of the Management Server is "gx-mgmt", and the name of one of the GX Gateways/Members is "gx-mod1", the DN would be something like "CN=gx-mod1,O=gx-mgmt..7au2cw".

   And so, the line in sic_policy.conf would look like:

   ANY ; "CN=gx-mod1,O=gx-mgmt..7au2cw" ; ANY ; sam ; ssl

   Note - The double quotes in the line are mandatory. Be sure to use double quotes ("), and not single quotes (') when writing the line in sic_policy.conf.

   For every additional Carrier Security Gateway/Member, add additional lines below the previous lines you've added. Be sure to use the correct DN for each new Carrier Security Gateway.

2. Establish a trust relationship between Security Gateways by running this command on each Gi Gateway/Member:

   fw putkey -ssl -p [<secret>] [<IP address of Carrier Security Gateway/Member>]

   Where [<secret>] is any string that will be used in the first authentication between the Carrier Security and the Gi Gateways. The string used here must match the string used in the "fw putkey" command which you run on the Carrier Security Gateway/Member.

   For additional Carrier Security Gateways/Members, run the "fw putkey" command again with the IP address of that member.

   Make sure that in all cases you use the unique IP address of each member, and not the IP address of the shared cluster.

3. Run cpstop and cpstart on all Gi/SGi Gateways/Members on which you have edited sic_policy.conf for the changes to take effect.

Testing Overbilling Protection

Enabling Overbilling protection for a clustered environment is complex, and is prone to mistakes. It is therefore highly recommended to perform several tests to make sure the configuration was done correctly.

1. Delete a GTP tunnel. On the CS Circuit Switched; opposite of packet switched. management, examine the logs and verify that the GTP tunnel deletion was done through a specific Carrier Security member.

2. On the Gi/SGi management, verify that there is a log from each Gi/SGi Gateway/Member reporting that a SAM rule has been added.

3. Delete a GTP tunnel through the other CS members. In most cases, you will need to perform a failover in the CS cluster.

4. Again verify that there is a log from each Gi Gateway/Member reporting that a SAM rule has been added.

Disabling Broadcast Inspection

When you create a tunnel GTP tunnel, there is an exchange of Create PDP context (GTPv1) or Create Session (GTPv2) messages. During this exchange, the mobile subscriber PDP address The MS's address in the external packet data network, also called End User IP address. (IP address used to access the PDN Packet Data Network - a network that carries user data in packets (for example, Internet and X.25)) is set.

By default, GTP inspection makes sure that a PDP address is not a broadcast address. Because some customers use an IP network from one class, but work with it as if it was from a different class. This can cause the use of broadcast IP addresses from the original class, which are dropped by broadcast inspection. You must disable broadcast inspection to resolve this issue.

To disable PDP address broadcast Inspection for the current session (until reboot), run:

fw ctl set int gtp_check_eu_broadcast_address 0

To permanently disable PDP address broadcast inspection, add this line to the $FWDIR/boot/modules/fwkern.conf file: gtp_check_eu_broadcast_address=0

Enforcing a More Granular GTP Security Policy

Through the use of GTP service filters and APN objects, you can create security rules that allow GTP traffic only within the parameters that you specify. GTP-aware filters provide the ability to limit the creation of PDP contexts to traffic that matches specific parameters that you define.

Customizing GTP Services

Carrier Security allows you to build your own GTP service filters, which can provide a more granular GTP security policy. When you create a new GTP service, you can set exactly which prefixes or other identifiers to allow onto your network. While you can modify the pre-defined GTP services gtp_v0_default and gtp_v1_default, it is recommended that you create a new service. As such, the following GTP customization example begins with the steps required to create a new service.

To define a new GTP service:

1. In SmartConsole open Objects > Object Explorer.

2. Click New > Service > GTP

3. On the General page:

   1. Give the new GTP service filter a name.

      Note - The port numbers of the GTP services cannot be modified.

   2. For GTP Message Filtering, select an Interface Profile.

      GTP Message Filtering Specifies GTP interface profile which defines associated control messages that match this service. You can create a custom profile or manually customize a service to filter specific message types.

   3. Select Actions.

      • Allow usage of static IP addresses for mobile subscribers with pre-assigned IP addresses. While IP addresses are usually allocated by the GGSN, some users may have static, pre-assigned IP addresses. The default is to allow such paths. When this option is set, PDP context activation will be enabled in static mode as well.

      • Apply Access Policy on user traffic causes all mobile user traffic encapsulated in G-PDUs to be inspected by FireWall and IPS stateful inspection. This prevents GTP-U acceleration and requires consideration when allocating CPU cores for CoreXL instances and SND.

      • Add IMSI field to logs generated by user traffic inserts the value in the IMSI field for any log generated by mobile user data, linking the log to the mobile user.

4. Click Advanced.

   For parameter, specify a value or select Any.

   • IMSI Prefix specifies a subscriber identity prefix. The subscriber identity prefix is usually of the form Country and Operator, for example, 23477 (where 234 is the MCC and 77 is the MNC).

   • Access Point Name specifies an APN object. An example of an APN is internet.mnc55.mcc243.gprs, or example.com. For APN configuration information, see Creating an APN Object

   • Selection Mode specifies a selection mode indicating the origin of the APN that appears in the PDP context request.

   • MS-ISDN specifies an MS-ISDN prefix (for example, 447788).

   • LDAP group specifies an LDAP group, sorted by two main attributes.

     According to MS-ISDN or IMSI identifies whether a user belongs to a specific LDAP group by IMSI or MS-ISDN.

5. Click Radio Access Technology.

   Specify which radio types a request has to match. You can customize the service to perform these actions on matching GTP traffic.

6. Click Additional Services.

   On the General page, if you selected V2 as the version, select one or more of these additional service types:

   • Trace Management

   • CS Fallback and SRVCC

   • Restoration and Recovery

   Add a rule in the rule base using this service and make sure the rule is above all other GTP-based rules.

Creating an APN Object

It is possible to control which end user IP addresses can access your network by enforcing APN domains. This is useful in environments where some or all of the local APNs have a pre-defined unique domain of end user IP addresses. To create an APN object:

1. In SmartConsole open Objects > Object Explorer.

2. Click New > Network Object> More > Access Point Name.

   The APN Properties window shows.
   

3. Name the APN.

4. Specify an APN string that identifies the APN, for example internet.mnc55.mcc243.gprs, or example.com.

5. Define a GTP service that is restricted to the APN you defined in the previous step. Define the new GTP service in the GTP Service Properties window and set its properties in the Advanced GTP Service Properties window. If the end user's IP address does not match the APN string, then PDP context create response or request messages are dropped with the error message IP is not in the APN domain.

To match more than one string to an APN rule:

1. Create an APN.

2. Include a wildcard in its name, such as *.example.gprs. An APN with this name will match strings with names like 123.example.gprs and abc.example.gprs. Supported wildcards are:

   Wildcard	Explanation
   *	any number of any characters
   ?	any 1 character

Using APNs in a Security Policy

Suppose two APNs are defined in this way:

APN End User Domain example

G-PDUs encapsulated in PDP-contexts using APN_Jamaica with server IPs from the range 10.1.1.0/24 or 20.1.1.0/24 will be dropped.

No restriction will be placed on G-PDUs belonging to APN_Spain. Specifically, a packet sent from a server to an MS with source IP 10.1.1.4 and destination IP 20.1.1.7 is allowed.

For more information on configuring APNs, see: GTP Intra Tunnel Inspection and Enforcement.

Blocking MS to Gn/S5 Network Traffic

To deny MS to Gn/S5 traffic:

1. Define an APN object for the Gn/S5 network (the APN string value in this case in not important).

2. Enable the property Enforce End User Domain and select the domain with the range of IP addresses of the Gn/S5 network you want to protect.

3. Enable the property Block MS to MS traffic between this and other APN End User domains on this and all other APNs defined.

GTP Intra Tunnel Inspection and Enforcement

Defining Access Using APN Objects

To define Intra Tunnel enforcement by end user domain:

1. Create an APN object as detailed in "Creating an APN Object", or edit an existing APN object.

2. Enable Enforce End User Domain to block user traffic that is outside a range of defined IP addresses.

3. Choose the relevant End User Domain from the drop down list.

4. Enable Block MS to MS traffic between this and other APN End User domains to drop and log intra-tunnel traffic between two MSs with IP addresses other than the ones specified in this APN End User Domain drop-down list.

5. Enable Block MS to MS traffic within this APN domain to drop and log intra-tunnel traffic between two MSs with IP addresses that match the addresses specified in this APN End User Domain drop-down list.

For conceptual information, see: APN Domain End User Address Enforcement.

Enforce GTP Anti-Spoofing

GTP Anti-Spoofing drops G-PDUs that do not use the end user IP address agreed upon in the PDP context activation process. The setting Enforce GTP Anti-Spoofing is located in the Carrier Security tab of the Global Properties window. Its default setting is enabled.

Block GTP in GTP

Block GTP in GTP drops GTP packets encapsulated inside GTP tunnels. The setting is located in the Carrier Security tab of the Global Properties window, and enabled by default.

GTP PDU Integrity Tests

These GTP PDU Integrity checks are available on the Carrier Security tab of the Global Properties window:

• Verify Flow Labels checks that each packet's flow label matches the flow labels defined by GTP signaling. This option is relevant for GTP version 0 only. The default setting is unchecked.

• G-PDU seq number check with a maximum deviation of a value set here. Sequence checking is enforced, but an out-of-sequence G‑PDU is accepted if the difference between its sequence number and the expected sequence number is less than or equal to the maximum deviation. The default setting is unchecked.

  The following related parameters take effect only if G-PDU sequence number check with a maximum deviation of is enabled, and can be configured using the Database Tool (GuiDBEdit Tool) (see sk13009):

  • gtp_sequence_deviation_drop - Drop all out-of-sequence packets. The default setting is FALSE.

  • gtp_sequence_deviation_alert - Generate a log when an out-of-sequence packet is encountered. The default setting is TRUE.

  Note - GTP PDU Integrity Tests are not supported in accelerated mode.

Secure Connectivity Features

The following features are concerned with connectivity:

• Allow GGSN Replies From Multiple Interfaces - for GTP signaling replies from an IP address different from the IP address to which the requests are sent. The default setting is checked.

  When this option is enabled, be sure to protect against Session Hijacking through the use of Handover Groups. For information on setting up Handover Groups, see Creating a GSN Handover Group

• Enable Reverse Connections (for Gateways below version R80) - accepts PDUs from the GGSN to the SGSN on a previously established PDP context even if these PDUs are sent over ports that do not match the ports of the established PDP context.

  This is available for the following PDUs:

  • G-PDUs.

  • Delete PDP context/sessions requests.

  • GTP version 1 update PDP context requests.

  • GTP version 2 update/delete bearer.

  • GTP error indication message.

    The default setting is enabled.

These features are located in the Other section of the Carrier Security tab in Global Properties.

To enable such connections on Security Gateways that run R80.20 and higher, manually configure a reverse rule such as this:

Limiting Signaling Rates

• Allow one GTP Echo on each path every x seconds sets the interval at which GTP Echo requests are allowed per path. Echo requests exceeding this rate will be dropped and logged. You can disable the signaling rate limit, and thereby accept all Echo requests, by entering 0. The default setting is 1.

• GTP Signaling rate limit sampling interval sets the interval for signal packet rate sampling. The default setting is 1 second.

• Enforce GTP Signal packet rate limit to host sets the number of PDUs allowed per second. PDU traffic exceeding this rate will be dropped and logged. This feature protects local GSNs from Denial of Service attacks by restricting the signaling rate that can be sent to a local GSN. Configure this rate on the Carrier Security page of each GSN network object. If checked, GTP signaling PDUs destined to this GSN above the specified rate are blocked and dropped. The default rate is 2048.

  Consider the following example: The rate limit sampling interval is set to the default rate of 1 second and the network object has enforced a GTP signal packet rate limit of the default of 2048 PDU per second. Then sampling will occur once per second and will allow 2048 signaling PDUs between two successive samplings.

  The following related parameters can be set using the Database Tool (GuiDBEdit Tool) (see sk13009):

  • gtp_rate_limit_drop drops packets that exceed the configured rate. The default value is TRUE.

  • gtp_rate_limit_alert issues an alert when packets exceed the configured rate. The default value is TRUE.

  • Enforce GTP Signal packet rate limit from GSN handover group sets the number of PDUs allowed per second from a GSN handover group object. And protects the network core from flooding.

Using FW SAM to Close PDP Contexts/sessions

For more information about the "fw sam" command on Security Gateway, see the R81 CLI Reference Guide > Chapter Security Gateway Commands > Section fw > Section fw sam.

Carrier Security Content Filter Arguments (<key=val>) for the "fw sam" Command

Note - Key names and their values are case sensitive.

Key	Value	Meaning
service	gtp	Service of 'gtp' indicates that the request applies only to connections that go through the gtp tunnel between the SGSN and the GGSN machines. All Carrier Security requests must include this argument.
imsi	String of numbers	International Mobile Subscriber Identity, a unique number identifying a particular mobile subscriber which comprises the MCC (Mobile Country Code), MNC (Mobile Network Code) and MSIN (Mobile Subscriber Identification Number.
msisdn	String of numbers	Mobile Subscriber phone number.
apn	String of up to 115 characters	Access Point Name.
tunl_dst	Dotted decimal IP address	Destination IP address of the tunneled connection
tunl_dport	Short integer represented as string	Destination port of the tunneled connection
tunl_proto	Short integer represented as string	Destination protocol of the tunneled connection

The next table lists the different types of Carrier Security requests, each represented with a certain combination of key=value pairs.

Carrier Security request types

Note - It is not possible to monitor the Carrier Security requests for the "-M" option. Key names and their values are case sensitive.

Request Type	Includes	Notes
Destination Network Request	APN
User Identification	IMSI and/or MSISDN
User to Destination	1) IMSI and/or MSISDN 2) One or more of the following destination arguments: APN All of these tunneled connection arguments together: tunl_dst, tunl_dport and tunl_proto	The three tunneled connection arguments of tunl_dst, tunl_dport, and tunl_proto, must come together. The Carrier Security Gateway does not close open tunnels. Therefore, a request that includes tunl_dst, tunl_dport, and tunl_proto may not be used with "-J" and "-I" options.

These examples demonstrate the use of the generic criteria for sending a Carrier Security request:

Scenario	Example FW SAM command
APN only	fw sam -f monica-gx -I generic service=gtp apn=test.com
IMSI (and/or MSISDN) only	fw sam -f monica-gx -I generic service=gtp imsi=055123456 (for MSISDN: msisdn= 380561234567)
IMSI (and/or MSISDN) and APN:	fw sam -f monica-gx -I generic service=gtp apn=test.com imsi=055123456
IMSI (and/or MSISDN) and 3-tunnel connection arguments	fw sam -f monica-gx -i generic service=gtp imsi=055123456 tunl_dst=10.100.100.1 tunl_dport=80 tunl_proto=6 This call inhibits connections on Carrier Security object monica-gx from a user with IMSI number 051123456 connecting over HTTP to server 10.100.100.1

Carrier Security SAM request to deal with unusable GTP tunnels

You can use a special SAM request in the event that one or more GTP tunnels are suspected to be hanging. This can occur due to connectivity failure between SGSNs and GGSNs when waiting for these tunnels to expire is not an option.

Note - Carrier Security deletes tunnels automatically after the default time out value of 90,000 seconds (25 hours).

When you try to delete such tunnels using regular SAM requests, the Carrier Security module sends Delete PDP Context request messages to the SGSNs and GGSNs related to the specific tunnel, which may not be answered due to connectivity failure. Thus, theses tunnels will not be deleted.

To delete these tunnels without sending the Delete PDP Context requests, a global variable has to be set before initiating the special SAM request, and afterwards - unset.

To delete unusable tunnels, run these commands in the Expert mode on the Carrier Security Command Line:

1. fw ctl set int allow_sam_delete_gtp_tunnels 1

2. fw sam -f monica-gx -t 1 -J generic service=gtp imsi=055123456

   (or any other combination as described in the table above)

3. fw ctl set int allow_sam_delete_gtp_tunnels 0

Adding Support for New GTP Messages and Information Elements

New TLV Information Elements and/or GTP Message Types can be added to the list of messages recognized by Carrier Security, thereby allowing them to pass through the firewall.

To define the new Elements or Types, add the relevant line(s) to the end of file $FWDIR/lib/gtp.def on the Management Server:

gtp_additional_types = {new GTPv0/1 Message Types};   gtpv2_ignore_messages = { new GTPv2 message types};   gtp_additional_elements = {new Information Elements};   gtpv2_ignore_elements = {new gtpv2 information elements};

Each line should list the ID (number) of the additional Message Types and/or Information Elements, respectively.

For example: if you define the following:

gtp_additional_types = {71, 72, 73};   gtp_additional_elements = {239, 240, 241};

the Message Types 71, 72 and 73 and Information Elements 239, 240 and 241 will be allowed to pass through the system when GTP version is 0/1, for GTPv2 use the other tables.

As long as their GTP headers are valid, the new Message Types will pass irrespective of their content. The new Information Elements defined may be included in any Message Type, and can appear in any location in the sequence of Information Elements in the message. You may add just new Message Types, or just new Informational Elements, or both for each of the versions.

Adjusting Settings with Database Tool (GuiDBEdit Tool)

There are a number of settings within Carrier Security that do not have a Graphical User Interface Well standardized point in the GPRS standard that typically has multivendor capability; opposite of reference point.. The value of these properties may be changed using the Database Tool (GuiDBEdit Tool) (see sk13009). Global settings are detailed in the next table:

Global Settings

Property	Meaning	Default
gtp_sequence_deviation_drop	If T-PDU sequence number check with a maximum deviation of is enabled, drop out-of-sequence packets.	FALSE
gtp_sequence_deviation_alert	If T-PDU sequence number check with a maximum deviation of is checked, a log will be generated when an out-of-sequence packet is encountered.	TRUE
gtp_allow_recreate_pdpc	When a Create PDP Context arrives at the Carrier Security Gateway and the tunnel already exists, the question whether this new Create should be allowed depends on whether the Carrier Security Gateway is configured to be strict or open with regard to this scenario. For GTP Version 1/2, a tunnel is composed of four TEIDs. If any one of the four TEIDs of a new create attempt is already in use (for the same GSNs pair), this will be considered a recreate. If gtp_allow_recreate_pdpc is set to open, the recreate is allowed. The Create Log generated for the new tunnel will include a remark in the info field stating "reusing TEID Tunnel End Point Identification - The GTP version 1 uni-directional tunnel identifier.".	OPEN
gtp_rate_limit_drop	A packet exceeding the allowed rate is dropped by default. To accept such packets, change the property's value to FALSE.	TRUE
gtp_rate_limit_alert	If a packet exceeds the allowed rate, a log is issued. To cancel such logs, change the property's value to FALSE.	TRUE
gtp_chk_hdr_len	If TRUE, Carrier Security verifies the length written in the GTP header.	TRUE
gtp_delete_upon_error	If TRUE, an error on a tunnel causes the tunnel to be deleted from the Carrier Security tables.	FALSE
gtp_echo_requires_path_in_use	If TRUE, Carrier Security verifies that at least one tunnel between the SGSN and GGSN participating in the echo is established.	FALSE
gtp_loggrace	Carrier Security eliminates similar logs indicating error each gtp_loggrace seconds.	10
gtp_max_req_retransmit	Only gtp_max_req_retransmit retransmissions of the same request are allowed.	5
gtp_monitor_mode	If TRUE, Carrier Security will not drop any GTP traffic even if it was evaluated as malicious, illegal, etc. The CS logging system will however log the intended drop as it would in regular operation mode. This enables the operator to realize the impact of CS on the system without actually enforcing that impact.	FALSE
gtp_log_additional_fields	If TRUE, additional Information Elements are added to the logs of GTP traffic.	FALSE

Settings per Gateway

Property	Meaning	Default
gtp_pending_hashsize	Sets the hash size of the gtp_pending kernel table, which is used to store pending GTP signaling requests. This value must be a power of 2.	65536
gtp_pending_limit	Sets the maximum number of entries stored in the gtp_pending kernel table.	25000
gtp_pending_timeout	Sets the timeout of entries in the gtp_pending kernel table.	40 seconds
gtp_sam_close_upon_delete	A Boolean parameter used to enable sending a delete PDP context request message to GSNs when a tunnel is deleted using the SAM API or when PDP contexts expire. Enabled automatically when the CS Overbilling protection is in use.	FALSE
gtp_tunnels_hashsize	Sets the hash size of the gtp_tunnels kernel table, which is used for storing active PDP contexts. This value must be a power of 2.	65536
gtp_tunnels_limit	Sets the maximum number of entries stored in the gtp_tunnels kernel table.	50000
gtp_tunnels_timeout	Sets the timeout of entries in the gtp_tunnels kernel table.	90000 seconds