GTP Profile

You can configure multiple GTP profiles within the GTP menu. GTP profiles concern GTP activity flowing through the unit. These GTP profiles are then applied to a security policy.

GTP profile configuration settings

The following are GTP profile configuration settings in Security Profiles > GTP Profiles.

GTP Profile Lists each GTP profile that you have created. On this page, you can edit, delete or create a new GTP profile.

Creates a new GTP profile. When you select Create New, you are Create New automatically redirected to the New page.

Edit      Modifies settings within a GTP profile in the list. When you select Edit, you are automatically redirected to Edit page.

 

Removes a GTP profile from the list. To remove multiple GTP profiles from within the list, on the GTP Profile page, in each of the rows of the profiles you want removed, select the Delete check box and then select Delete. To remove all GTP profiles from within the list, on the GTP Profile page, select the check box in the check box column and then select Delete.
Name                                     The name of the GTP profile.
Displays the number of times the object is referenced to other objects. For example, av_1 profile is applied to a security policy; on the Profile page (Security Profiles > Antivirus > Profiles), 1 appears in Ref. . To view the location of the referenced object, select the number in Ref., and the Object Usage window appears displaying the various locations of the referenced object. To view more information about how the object is being used, use one of the following icons that is available within the Object Usage window: • View the list page for these objects – automatically redirects you to Ref. the list page where the object is referenced at. • Edit this object – modifies settings within that particular setting that the object is referenced with. For example, av_1 profile is referenced with a security policy and so, when this icon is selected, the user is redirected to the Edit Policy page. • View the details for this object – table, similar to the log viewer table, contains information about what settings are configured within that particular setting that the object is referenced with. For example, av_1 profile is referenced with a security policy, and that security policy’s settings appear within the table.
New GTP Profile Provides settings for configuring a GTP profile.
Name                                     Enter a name for the GTP profile.
General Settings                    Configure general options for the GTP profile.
Message Type Filtering          Configure filtering for messages.
APN Filtering                          Configure filtering options for APN.
Basic Filtering                        Configure filtering options for IMSI.
Advanced Filtering	Configure advanced filtering options.
IE removal policy	Configure IE removal policy options.
Encapsulated IP Traffic Filtering	Configure filtering options for encapsulated IP traffic.
Encapsulated Non-IP End User Address Filtering	Configure filtering options for encapsulated non-IP end user addresses.
Protocol Anomaly	Configure protocol anomaly options.
Anti-Overbilling	Configure anti-overbilling options.
Log	Configure log options.

General settings options

The following are mostly house keeping options that appear in the General Settings area of the GTP configuration page.

General Settings section of the New GTP Profile

GTP-in-GTP                            Select Allow to enable GTP packets to be allowed to contain GTP packets, or a GTP tunnel inside another GTP tunnel. To block all GTP-in-GTP packets, select Deny.

Enter the shortest possible message length in bytes. Normally this is controlled by the protocol, and will vary for different message types. If a packet is smaller than this limit, it is discarded as it is likely malformed and Minimum Message Length a potential security risk. The default minimum message length is 0 bytes.

Maximum Message Length      Enter the maximum allowed length of a GTP packet in bytes. A GTP packet contains three headers and corresponding parts GTP, UDP, and IP. If a packet is larger than the maximum transmission unit (MTU) size, it is fragmented to be delivered in multiple packets. This is inefficient, resource intensive, and may cause problems with some applications. By default the maximum message length is 1452 bytes.

 

General Settings section of the New GTP Profile

Enter the maximum number of tunnels allowed open at one time. For additional GTP tunnels to be opened, existing tunnels must first be closed. This feature can help prevent a form of denial of service attack on your network. This attack involves opening more tunnels than the network can Tunnel Limit handle and consuming all the network resources doing so. By limiting the number of tunnels at any one time, this form of attack will be avoided. The tunnel limiting applies to the Handover Group, and Authorized SGSNs and GGSNs.

Tunnel Timeout                      Enter the maximum number of seconds that a GTP tunnel is allowed to remain active. After the timeout the unit deletes GTP tunnels that have stopped processing data. A GTP tunnel may hang for various reasons. For example, during the GTP tunnel tear-down stage, the “delete pdap context response” message may get lost. By setting a timeout value, you can configure the FortiOS Carrier firewall to remove the hanging tunnels. The default is 86400 seconds, or 24 hours.

Enter the number of packets per second to limit the traffic rate to protect the GSNs from possible Denial of Service (DoS) attacks. The default limit of 0 does not limit the message rate. GTP DoS attacks can include: Control plane message rate limit • Border gateway bandwidth saturation: A malicious operator can connect to your GRX and generate high traffic towards your Border Gateway to consume all the bandwidth. • GTP flood: A GSN can be flooded by illegitimate traffic

Handover Group           Select the allowed list of IP addresses allowed to take over a GTP session when the mobile device moves locations. Handover is a fundamental feature of GPRS/UMTS, which enables subscribers to seamlessly move from one area of coverage to another with no interruption of active sessions. Session hijacking can come from the SGSN or the GGSN, where a fraudulent GSN can intercept another GSN and redirect traffic to it. This can be exploited to hijack GTP tunnels or cause a denial of service. When the handover group is defined it acts like a white list with an implicit default deny at the end — the GTP address must be in the group or the GTP message will be blocked. This stops handover requests from untrusted GSNs.

General Settings section of the New GTP Profile

Use Authorized SGSNs to only allow authorized SGSNs to send packets through the unit and to block unauthorized SGSNs. Go to Firewall Objects > Address > Addresses and add the IP addresses of the authorized SGSNs to a firewall address or address group. Then set Authorized SGSNs Authorized SGSNs to this firewall address or address group. You can use Authorized SGSNs to allow packets from SGSNs that have a roaming agreement with your organization.

Authorized GGSNs                 Use Authorized GGSNs to only allow authorized GGSNs to send packets through the unit and to block unauthorized GGSNs. Go to Firewall Objects > Address > Addresses and add the IP addresses of the authorized GGSNs to a firewall address or address group. Then set Authorized GGSNs to this firewall address or address group. You can use Authorized GGSNs to allow packets from SGSNs that have a roaming agreement with your organization.

Message type filtering options

On the New GTP Profile page, you can select to allow or deny the different types of GTP messages, which is referred to as message type filtering. You must expand the Message Type Filtering section to access the settings.

The messages types include Path Management, Tunnel Management, Location Management, Mobility Management, MBMS, and GTP-U and Charging Management messages.

For enhanced security, Fortinet best practices dictate that you set Unknown Message Action to deny. This will block all unknown GTP message types, some of which may be malicious.

To configure message type filter options, expand Message Type Filtering in the GTP profile.

APN filtering options

An Access Point Name (APN) is an Information Element (IE) included in the header of a GTP packet. It provides information on how to reach a network.

An APN has the following format:

<network_id>[.mnc<mnc_int>.mcc<mcc_int>.gprs] Where:

• <network_id> is a network identifier or name that identifies the name of a network, for example, com

or internet.

• [.mnc<mnc_int>.mcc<mcc_int>.gprs] is the optional operator identifier that uniquely identifies the operator’s PLMN, for example mcc456.gprs.

Combining these two examples results in a complete APN of internet.mnc123.mcc456.gprs.

By default, the unit permits all APNs. However, you can configure APN filtering to restrict roaming subscribers’ access to external networks.

APN filtering applies only to the GTP create pdp request messages. The unit inspects GTP packets for both APN and selected modes. If both parameters match and APN filter entry, the unit applies the filter to the traffic.

Additionally, the unit can filter GTP packets based on the combination of an IMSI prefix and an APN.

APN Filtering
Enable APN Filter	Select to enable APN filtering.
Default APN Action	Select the default action for APN filtering. If you select Allow, all sessions are allowed except those blocked by individual APN filters. If you select Deny, all sessions are blocked except those allowed by individual APN filters.
Value	The APN to be filtered.
Mode	The type of mode chosen that indicates where the APN originated and whether the Home Location Register (HLR) has verified the user subscription:
Action	The type of action that will be taken.
Edit	Modifies the settings within the filter. When you select Edit, the Edit window appears, which allows you to modify the settings of the APN.
Delete	Removes the APN from the list within the table, in the APN Filtering section.
Add APN	Adds a new APN filter to the list. When you select Add APN, the New window appears, which allows you to configure the APN settings.
New APN page
Value	Enter an APN to be filtered. You can include wild cards to match multiple APNs. For example, the value internet* would match all APNs that being with internet.
Mode	Select one or more of the available modes to indicate where the APN originated and whether the Home Location Register (HLR) has verified the user subscription.
Mobile Station provided		MS-provided APN, subscription not verified, indicates that the mobile station (MS) provided the APN and that the HLR did not verify the user’s subscription to the network.
Network provided		Network-provided APN, subscription not verified, indicates that the network provided a default APN because the MS did not specify one, and that the HLR did not verify the user’s subscription to the network.
Subscription Verified		MS or Network-provided APN, subscription verified, indicates that the MS or the network provided the APN and that the HLR verified the user’s subscription to the network
Action		Select Allow or Deny.

Basic filtering options

The International Mobile Station Identity (IMSI) is used by a GPRS Support Node (GSN) to identify a mobile station. Three elements make up every IMSI:

l the mobile country code (MCC) l the mobile network code (MNC) l the mobile subscriber identification number (MSIN).

The subscriber’s home network—the public land mobile network (PLMN)—is identified by the IMSI prefix, formed by combining the MCC and MNC.

By default, the unit allows all IMSIs. You can add IMSI prefixes to deny GTP traffic coming from non-roaming partners. Any GTP packets with IMSI prefixes not matching the prefixes you set will be dropped. GTP Create pdp request messages are filtered and only IMSI prefixes matching the ones you set are permitted. Each GTP profile can have up to 1000 IMSI prefixes set.

An IMSI prefix and an APN can be used together to filter GTP packets if you set an IMSI filter entry with a nonempty APN.

IMSI Filtering section of the New GTP Profile
Enable IMSI Filter                      Select to enable IMSI filtering.
Default IMSI Action Select the default action for IMSI filtering. If you select Allow, all sessions are allowed except those blocked by individual IMSI filters. If you select Deny, all sessions are blocked except those allowed by individual IMSI filters.
APN                                          The APN that is part of the IMSI that will be filtered.
MCC-MNC	The MCC-MNC part of the IMSI that will be filtered.
Mode	The type of mode that indicates where the APN originated and whether the Home Location Register (HLR) has verified the user subscription.
Action	The type of action that will be taken.
Edit	Modifies settings to an IMSI filter. When you select Edit, the Edit window appears, which allows you to modify the IMSI filter’s settings.
Delete	Removes an IMSI filter from within the table, in the IMSI Filtering section.
Add IMSI	Adds a new IMSI filter to the list. When you select Add IMSI, the New window appears, which allows you to configure IMSI filter settings.
New IMSI page
APN	Enter the APN part of the IMSI to be filtered.
MCC-MNC	Enter the MCC-MCC part of the IMSI to be filtered.
Mode	Select one or more of the available modes to indicate where the APN originated and whether the Home Location Register (HLR) has verified the user subscription.
Mobile Station provided	MS-provided APN, subscription not verified, indicates that the mobile station (MS) provided the APN and that the HLR did not verify the user’s subscription to the network.
Network provided	Network-provided APN, subscription not verified, indicates that the network provided a default APN because the MS did not specify one, and that the HLR did not verify the user’s subscription to the network.
Subscription Verified	MS or Network-provided APN, subscription verified, indicates that the MS or the network provided the APN and that the HLR verified the user’s subscription to the network
Action	Select Allow or Deny.

Advanced filtering options

The FortiOS Carrier firewall supports advanced filtering against the attributes RAT, RAI, ULI, APN restriction, and IMEI-SV in GTP to block specific harmful GPRS traffic and GPRS roaming traffic. The following table shows some of the GTP context requests and responses that the firewall supports.

Attributes supported by FortiCarrier firewalls

	GTP Create PDP Context Request	GTP Create PDP Context Response	GTP Update PDP GTP Update PDP Con- Context text Request Response
APN	yes	yes	–
APN Restriction	yes	–	–	yes
IMEI-SV	yes	–	–	–
IMSI	yes	–	yes	–
RAI	yes	–	yes	–
RAT	yes	–	yes	–
ULI	yes	–	yes	–

When editing a GTP profile, select Advanced Filtering > Create New to create and add a rule. When the rule matches traffic it will either allow or deny that traffic as selected in the rule.

Advanced Filtering
Enable	Select to enable advanced filtering.
Default Action	Select the default action for advanced filtering. If you select Allow, all sessions are allowed except those blocked by individual advanced filters. If you select Deny, all sessions are blocked except those allowed by individual advanced filters.
Messages	The messages, for example, Create PDP Context Request.
APN Restriction	The APN restriction.
RAT Type	The RAT types associated with that filter.
ULI	The ULI pattern.
RAI	The RAI pattern.
IMEI	The IMEI pattern.
Action	The action that will be taken.
Edit	Modifies the filter’s settings. When you select Edit, the Edit window appears, which allows you to modify the filter’s settings.

 

Delete	Removes a filter from the list.
Add	Adds a filter to the list. When you select Add, the New window appears, which allows you to configure settings for messages, APN, IMSI, MSISDN, RAT type, ULI, RAI, IMEI patterns as well as the type of action.
New Filtering page
Messages	The PDP content messages this profile will match.
Create PDP Context Request	Select to allow create PDP context requests.
Create PDP Context Response	Select to allow create PDP context responses.
Update PDP Context Request	Select to allow update PDP context requests.
Update PDP Context Response	Select to allow update PDP context responses.
APN	Enter the APN.
APN Mode	Select an APN mode as one or more of •  Mobile Station provided •  Network provided •  Subscription provided This field is only available when an APN has been entered.
Mobile Station provided	MS-provided PAN, subscription not verified, indicates that the mobile station (MS) provided the APN and that the HLR did not verify the user’s subscription to the network.
Network provided	Network-provided APN, subscription not verified, indicates that the network provided a default APN because the MS did not specify one, and that the HLR did no verify the user’s subscription to the network.
Subscription verified	MS or Network-provided APN, subscription verified, indicates that the MS or the network provided the APN and that the HLR verified the user’s subscription to the network.
APN Restriction	Select the type of restriction that you want. You can choose all of the types, or one of the types. You cannot choose multiple types. Types include: •  all •  Public-1 •  Public-2 •  Private-1 •  Private-2
IMSI	Enter the IMSI.
MSISDN	Enter the MSISDN.
RAT Type	Optionally select the RAT type as any combination of the following: •  Any •  UTRAN •  GERAN •  Wifi •  GAN •  HSPA Some RAT types are GTPv1 specific.
ULI pattern	Enter the ULI pattern.
RAI pattern	Enter the RAI pattern.
IMEI pattern	Enter the IMEI pattern.
Action	Select either Allow or Deny.

Adding an advanced filtering rule

When adding a rule, use the following formats:

• Prefix, for example, range 31* for MCC matches MCC from 310 to 319. l Range, for example, range 310-319 for MCC matches MCC from 310 to 319.
• Mobile Country Code (MCC) consists of three digits. The MCC identifies the country of domicile of the mobile subscriber.
• Mobile Network Code (MNC) consists of two or three digits for GSM/UMTS applications. The MNC identifies the home PLMN of the mobile subscriber. The length of the MNC (two or three digits) depends on the value of the MCC. Best practices dictate not to mix two and three digit MNC codes within a single MCC area. l Location Area Code (LAC) is a fixed length code (of 2 octets) identifying a location area within a PLMN. This part of the location area identification can be coded using a full hexadecimal representation except for the following reserved hexadecimal values: 0000 and FFFE. These reserved values are used in some special cases when no valid LAI exists in the MS (see 3GPP TS 24.008, 3GPP TS 31.102 and 3GPP TS 51.011).
• Routing Area Code (RAC) of a fixed length code (of 1 octet) identifies a routing area within a location. l CI or SAC of a fixed length of 2 octets can be coded using a full hexadecimal expression.
• Type Allocation Code (TAC) has a length of 8 digits.
• Serial Number (SNR) is an individual serial number identifying each equipment within each TAC. SNR has a length of 6 digits. l Software Version Number (SVN) identifies the software version number of the mobile equipment. SVN has a length of 2 digits.

GTP Configuration

The GTP (GPRS Tunneling Protocol) is one of the major mobile core protocols used since to transfer data in the core mobile network. Mobility and data are exploding and this trend will continue with VoLTE, 5G, and the Internet of Things (IoT). The role of GTP in mobile networks will continue to remain critical.

With the mobile network ever growing importance as the communication channel for data rich application on mobile devices, connected intelligent devices and the IoT, comes the growing potential for attacks on the mobile infrastructure.

Introduction to GTP

GTP as a Potential Attack Vector

GTP’s role in transferring data in the core mobile infrastructure makes it a potential ideal attack vector. To understand the security features for GTP we need to understand the risks that might compromise this protocol. The business impact might varies in-between the different attacks from Denial of Service (DoS) attacks that hinders the capability of performing a legitimate operation due to resource starvation (for example – not being able to charge the customer for GPRS traffic use due to denial of service attack on the Charging GW) to remote compromise attacks that allows the hacker to have remote control of a critical device (for example – take control over a GGSN).

GTP-based attacks may have a wide range of business impact, based on the attacked devices’ vulnerability, ranging from service unavailability, compromise customer information, and gaining control over infrastructure elements, just to give a few examples.

Listed below are the main categories of GTP-based attacks:

• Protocol anomaly attacks are packets and packets formats that should not be expected on the GTP protocol. These can include malformed packets, reserved packets’ fields and types, etc.
• Infrastructure attacks are attempts to connect to restricted core elements, such as the GGSN, SGSN, PGW, etc. l Overbilling attacks results in customers charged for traffic they did not use or the opposite of not paying for the used traffic.

Protecting Against GTP-Based Attacks: The Carrier Grade GTP Firewall

With the evolution of the mobile network so has GTP evolved. The awareness to the potential of GTP-based attacks has led mobile core vendors to harden their software to better deal with a potential attack. Alongside this evolution, network security vendors, such as Fortinet, has led the way in providing specific GTP aware firewalls to secure and protect the different versions of the GTP protocol from potential attacks.

A GTP firewall should be placed where GTP traffic and session originate and terminate, as shown in the below diagram, and has to inspect both the GTP-C (Control Plane) and GTP-U (Data Plane) packets that, together, constitute the GPRS Tunneling Protocol.

The GTP firewall in both cases is placed in line between the SGSN / SGW and the GGSN / PGW which are the initiator and terminator of the GTP traffic. One of the main roles of GTP firewall is also to be able to support the roaming between different versions of GTP without interrupting the service.

The GTP firewall must be carrier grade in its ability to scale and provide high availability without impact its ability to provide effective protection.

FortiGate with FortiCarrier – The Leading GTP Firewall

FortiGate is Fortinet’s physical security platform, built specifically for high performance and scalability with the utilization of specialized FortiASIC technology. Fortinet Content Processors (CP) and Network Processors (NP) enable, offloading CPU intensive tasks and allowing the FortiGate to provide carrier grade performance and scalability. Utilizing the power of the FortiGate platform, FortiOS, Fortinet’s security Operating System, provides threat intelligence and advanced functionalities to provide effective security, ranging from Carrier Grade NAT (CGNAT), firewalling, IPSec, etc.

FortiCarrier is the part of FortiOS which was specifically designed to provide security for specific carriers and mobile operators’ protocols and requirements, such as awareness and security for GTP. The wide range of FortiGate platforms with FortiOS and FortiCarrier enables mobile operators to cost effectively secure their mobile network against GTP-based attacks, while ensuring unparalleled performance, availability and security effectiveness.

GPRS network common interfaces

There are interfaces for each connection on the GPRS network. An interface is an established standard form of communication between two devices. Consider a TCP/IP network. In addition to the transport protocol (TCP) there are other protocols on that network that describe how devices can expect communications to be organized, just like GPRS interfaces.

GPRS network common interfaces

Interfaces between devices on the network

There are a series of interfaces that define how different devices on the carrier network communicate with each other. There interfaces are called Ga to Gz, and each one defines how a specific pair of devices will communicate. For example Gb is the interface between the base station and the SGSN, and Gn is one possible interface between the SGSN and GGSN.

The SGSN and GGSN keep track of the CDR information and forward it to the Charging Data Function (CDF) using the Gr interface between the SGSN and home location register (HLR), Gs interface between the SGSN and MSC (VLR), Gx interface between the GGSN and the Charging Rules Function (CRF), Gy between the GGSN and online charging system (OCS), and finally Gz which is the off-line (CDR-based) charging interface between the GSN and the CG that uses GTP’.

Each of these interfaces on the GPRS network is has a name in the format of Gx where x is a letter of the alphabet that determines what part of the network the interface is used in. It is common for network diagrams of GPRS networks to include the interface name on connections between devices.

GPRS network interfaces, their roles, and billing

Name	Device connections that use Traffic Protocol this interface                          used		Its role or how it affects billing
Ga	CDR and GSN (SGSNs and GGSNs)	GTP‘ – GTP modified to include CDR role	CDR have the accounting records, that are compiled in the GSN and then sent to the Charging Gateway (CG)
Gb	MS and SGSN	Frame Relay or IP	When an IP address moves to a new MS, the old MS may continue to use and bill that IP address.
Gi	GGSN and public data networks (PDNs)	IP based	This is the connection to the Internet. If the GTP tunnel is deleted without notifying the Gi interface, the connection may remain open incurring additional charges. FortiOS Carrier adds this interface to a firewall. See Anti-overbilling with FortiOS Carrier.
Gn	SGSN and external SGSNs and internal GGSNs	GTP	When the GTP tunnel is deleted, need to inform other interfaces immediately to prevent misuse of connections remaining
Gp	Internal SGSN and external GGSNs	GTP	open. FortiOS Carrier adds this interface to a firewall.
Gz	GSN (SGSN and GGSN) and the charging gateway (CG)	GTP‘	Used for the offline charging interface. Ga is used for online charging.

GPRS network common interfaces

Corporate customers may have a direct connection to the Gi interface for higher security. The Gi interface is normally an IP network, though a tunnelling protocol such as GRE or IPsec may be used instead.

 

Introduction to GTP

GTP basic concepts

GPRS currently supports data rates from 9.6 kbps to more than 100 kbps, and is best suited for burst forms of traffic. GPRS involves both radio and wired components. The mobile phone sends the message to a base station unit (radio based), and the base station unit sends the message to the carrier network and eventually the Internet (wired carrier network).

The network system then either sends the message back to a base station and to the destination mobile unit, or forwards the message to the proper carrier’s network where it gets routed to the mobile unit.

PDP Context

The packet data protocol (PDP) context is a connection between a mobile station and the end address that goes through the SGSN and GGSN. It includes identifying information about the mobile customer used by each server or device to properly forward the call data to the next hop in the carrier network, typically using a GTP tunnel between the SGSN and GGSN.

When a mobile customer has an active voice or data connection open, both the SGSN and GGSN have the PDP context information for that customer and session.

When a mobile phone attempts to communicate with an address on an external packet network, either an IP or X.25 address, the mobile station that phone is connected to opens a PDP context through the SGSN and GGSN to the end address. Before any traffic is sent, the PDP context must first be activated.

The information included in the PDP context includes the customer’s IP address, the IMSI number of the mobile handset, and the tunnel endpoint ID for both the SGSN and GGSN. The ID is a unique number, much like a session ID on a TCP/IP firewall. All this information ensures a uniquely identifiable connection is made.

Since one mobile device may have multiple connections open at one time, such as data connections to different Internet services and voice connections to different locations, there may be more than one PDP context with the same IP address making the extra identifying information required.

The endpoint that the mobile phone is connecting to only knows about the GGSN — the rest of the GPRS connection is masked by the GGSN.

Along the PDP context path, communication is accomplished in using three different protocols.

l The connection between the Mobile Station and SGSN uses the SM protocol. l Between SGSN and GGSN GTP is used. l Between GGSN and the endpoint either IP or X.25 is used.

FortiOS Carrier is concerned with the SGSN to GGSN part of the PDP context — the part that uses GTP.

For more about PDP context, see Tunnel Management Messages.

Creating a PDP context

While FortiOS Carrier is concerned mostly with the SGSN to GGSN part of the PDP Context, knowing the steps involved in creating a PDP context helps understand the role each device, protocol, and message type plays.

Both mobile stations and GGSNs can create PDP contexts.

A Mobile Station creates a PDP context

1. The Mobile Station (MS) sends a PDP activation request message to the SGSN including the MS PDP address, and APN.
2. Optionally, security functions may be performed to authenticate the MS.
3. The SGSN determines the GGSN address by using the APN identifier.
4. The SGSN creates a down link GTP tunnel to send IP packets between the GGSN and SGSN.
5. The GGSN creates an entry in its PDP context table to deliver IP packets between the SGSN and the external packet switching network.
6. The GGSN creates an uplink GTP tunnel to route IP-PDU from SGSN to GGSN.
7. The GGSN then sends back to the SGSN the result of the PDP context creation and if necessary the MS PDP address.
8. The SGSN sends an Activate PDP context accept message to the MS by returning negotiated the PDP context information and if necessary the MS PDP address.
9. Now traffic can pass from the MS to the external network endpoint.

A GGSN creates a PDP context

1. The network receives an IP packet from an external network.
2. The GGSN checks if the PDP Context has already been created.
3. If not, the GGSN sends a PDU notification request to the SGSN in order to initiate a PDP context activation.
4. The GGSN retrieves the IP address of the appropriate SGSN address by interrogating the HLR from the IMSI identifier of the MS.
5. The SGSN sends to the MS a request to activate the indicated PDP context.
6. The PDP context activation procedure follows the one initiated by the MS. See “A Mobile Station creates a PDP context”.
7. When the PDP context is activated, the IP packet can be sent from the GGSN to the MS.

Terminating a PDP context

A PDP context remains open until it is terminated. To terminate the PDP context an MS sends a Deactivate PDP context message to the SGSN, which then sends a Delete PDP Context message to the GGSN.

When the SGSN receives a PDP context deletion acknowledgment from the GGSN, the SGSN confirms to the MS the PDP context deactivation. The PDP can be terminated by the SGSN or GGSN as well with a slight variation of the order of the messages passed.

When the PDP Context is terminated, the tunnel it was using is deleted as well. If this is not completed in a timely manner, it is possible for someone else to start using the tunnel before it is deleted. This hijacking will result in the original customer being over billed for the extra usage. Anti-overbilling helps prevent this. See Configuring Anti-overbilling in FortiOS Carrier.

GPRS security

The GPRS network has some built-in security in the form of GPRS authentication. However this is minimal, and is not sufficient for carrier network security needs. A GTP firewall, such as FortiOS Carrier, is required to secure the Gi, Gn, and Gp interfaces.

GPRS authentication

GPRS authentication is handled by the SGSN to prevent unauthorized GPRS calls from reaching the GSM network beyond the SGSN (the base station system, and mobile station). Authentication is accomplished using some of the customer’s information with a random number and uses two algorithms to create ciphers that then allow authentication for that customer.

User identity confidentiality ensures that customer information stays between the mobile station and the SGSN — no identifying information goes past the SGSN. Past that point other numbers are used to identify the customer and their connection on the network.

Periodically the SGSN may request identity information from the mobile station to compare to what is on record, using the IMEI number.

Call confidentiality is achieved through the use of a cipher, similar to the GPRS authentication described earlier. The cipher is applied between the mobile station and the SGSN. Essentially a cipher mask is XORd with each outgoing frame, and the receiving side XORs with its own cipher to result in the original frame and data.

Parts of a GTPv1 network

A sample GTP network consists of the end handset sender, the sender’s mobile station, the carrier’s network including the SGSN and GGSN, the receiver’s mobile station, and the receiver handset.

When a handset moves from one mobile station and SGSN to another, the handset’s connection to the Internet is preserved because the tunnel the handset has to the Internet using GTP tracks the user’s location and information. For example, the handset could move from one cell to another, or between countries.

The parts of a GPRS network can be separated into the following groups according to the roles of the devices:

• Radio access to the GPRS network is accomplished by mobile phones and mobile stations (MS).
• Transport the GPRS packets across the GPRS network is accomplished by SGSNs and GGSNs, both local and remote, by delivering packets to the external services. l Billing and records are handled by CDF, CFR, HLR, and VLR devices.

GPRS networks also rely on access points and PDP contexts as central parts of the communication structure. These are not actual devices, but they are still critical .

These devices, their roles, neighboring devices, the interfaces and protocols they use are outlined in the following table.

Carrier network showing the interfaces used (GTPv1)

Devices on a GTPv1 network

Device role	Neighboring Devices	Interfaces used	Protocols used
Mobile Users	Mobile Stations (MS)	Radio Access Technology (RAT)
Mobile Stations (MS)	Mobile Users, SGSN	Gb	IP, Frame Relay
SGSN (local)	MS, SGSN (local or remote), GGSN (local and remote), CDR, CFR, HLR, VLR	Ga, Gb, Gn, Gp, Gz	IP, Frame Relay, GTP, GTP’
SGSN (remote)	SGSN (local)	Gn	GTP
GGSN (local)	SGSN (local or remote), GGSN (local and remote), CDR, CFR, HLR, VLR	Ga, Gi, Gn, Gp, Gz	IP, GTP, GTP’
GGSN (remote)	SGSN (local), WAP gateway, Internet, other external services	Gi, Gp	IP, GTPv1
CDR, CFR	SGSN (local), GGSN (local)	Ga, Gz	GTP’
HLR, VLR	SGSN (local), GGSN (local)	Ga, Gz	GTP’

Radio access

For a mobile phone to access the GPRS core network, it must first connect to a mobile station. This is a cellular tower that is connected to the carrier network.

How the mobile phone connects to the mobile station (MS) is determined by what Radio Access Technologies (RATs) are supported by the MS.

Transport

Transport protocols move data along the carrier network between radio access and the Internet or other carrier networks.

FortiOS Carrier should be present where information enters the Carrier network, to ensure the information entering is correct and not malicious. This means a Carrier-enabled FortiGate unit intercepts the data coming from the SGSN or foreign networks destined for the SSGN or GGSN onto the network, and after the GGSN as the data is leaving the network.

GTP

GPRS Tunnelling Protocol (GTP) is a group of IP-based communications protocols used to carry General Packet

Radio Service (GPRS) within Global System for Mobile Communications (GSM) and Universal Mobile Telecommunications System (UMTS) networks. It allows carriers to transport actual cellular packets over a network via tunneling. This tunneling allows users to move between SGSNs and still maintain connection to the Internet through the GGSN.

GTP has three versions version 0, 1, and 2. GTP1 and GTP2 are supported by FortiOS Carrier. The only GTP commands that are common to all forms of GTP are the echo request/response commands that allow GSNs to verify up to once every 60 seconds that neighboring GSNs are alive.

GTPv0

There have been three versions of GTP to date. The original version of GTP (version 0) has the following differences from version GTPv1.

l the tunnel identification is not random l there are options for transporting X.25 l the fixed port number 3386 is used for all functions, not just charging l optionally TCP is allowed as a transport instead of UDP l not all message types are supported in version 0

GTPv1

On a GPRS network, Packet Data Protocol (PDP) context is a data structure used by both the Serving GPRS Support Node (SGSN) and the Gateway GPRS Support Node (GGSN). The PDP context contains the subscribers information including their access point, IP address, IMSI number, and their tunnel endpoint ID for each of the

SGSN and GGSN.

The Serving GPRS Support Node (SGSN) is responsible for the delivery of data packets from and to the mobile stations within its geographical service area. Its tasks include packet routing and transfer, mobility management

(attach/detach and location management), logical link management, and authentication and charging functions.

The location register of the SGSN stores location information (e.g., current cell, current VLR) and user profiles (e.g., IMSI, address(es) used in the packet data network) of all GPRS users registered with this SGSN.

GTPv1-C

GTPv1-C refers to the control layer of the GPRS Transmission network. This part of the protocol deals with network related traffic.

FortiOS Carrier handles GTPv1-C in GTPv1 by using the Tunnel Endpoint IDentifier (TEID), IP address and a Network layer Service Access Point Identifier (NSAPI), sometimes called the application identifier, as an integer value that is part of the PDP context header information used to identify a unique PDP context in a mobile station, and SGSN.

For more information on GTPv1-C, see GTP-C messages.

GTPv1-U

GTPv1-U is defined in 3GPP TS 29.281 and refers to the user layer of the GPRS Tunneling network. This part of the protocol deals with user related traffic, user tunnels, and user administration issues.

A GTPv1-U tunnel is identified by a TEID, an IP address, and a UDP port number. This information uniquely identifies the limb of a GTPv1 PDP context. The IP address and the UDP port number define a UDP/IP path, a connectionless path between two endpoints (i.e. SGSN or GGSN). The TEID identifies the tunnel endpoint in the receiving GTPv1-U protocol entity; it allows for the multiplexing and demultiplexing of GTP tunnels on a UDP/IP path between a given GSN-GSN pair. For more information on GTPv1-U, see GTP-U messages.

The GTP core network consists of one or more SGSNs and GGSNs.

GGSN

The Gateway GPRS Support Node (GGSN) connects the GPRS network on one side via the SGSN to outside networks such as the Internet. These outside networks are called packet data networks (PDNs). The GGSN acts as an edge router between the two different networks — the GGSN forwards incoming packets from the external PDN to the addressed SGSN and the GGSN also forwards outgoing packets to the external PDN. the GGSN also converts the packets from the GPRS packets with SGSN to the external packets, such as IP or X.25.

SGSN

The Serving GPRS Support Node (SGSN) connects the GPRS network to GTPv1 compatible mobile stations, and mobile units (such as UTRAN and ETRAN) on one side and to the gateway node (GGSN), which leads to external networks, on the other side. Each SGSN has a geographical area, and mobile phones in that area connect to the GPRS network through this SGSN. The SGSN also maintains a location register that contains customer’s location and user profiles until they connect through a different SGSN at which time the customer information is moved to the new SGSN. This information is used for packet routing and transfer, mobility management also known as location management, logical link management, and authentication and billing functions.

GTPv2

GTPv2, defined in 3GPP TS 29.274, is dramatically different from GTPv1, defined in 3GPP TS 29.060. Where in

GTPv1 the tunnel is between the SGSN and the GGSN, in GTPv2 The SGSN is between the MME and the LTE Serving Gateway (S-GW), beyond which is the PDN gateway (P-GW). Even tunnel management messages have changed significantly.

Network diagram for GTPv2

Device roles on a GTPv2 network

Device role	Neighboring Devices	Interfaces used	Protocols used
Mobile Users	Mobile Stations (MS)	Radio Access Technology (RAT)	—
GTPv1 Mobile Stations (MS)	Mobile Users, SGSN	Gb	IP, Frame Relay
GTPv2 Mobile Stations (MS)	Mobile Users, MME	???	IP, Frame Relay
SGSN (local)	GTPv1 MS, SGSN, S-GW	???	IP, Frame Relay, GTPv1, GTP’
S-GW	SGSN, MME, P-GW	???	IP, GTPv2, GTP’
P-GW	S-GW, Internet, other external services	???	IP, GTPv2

GTPv2-C

GTPv2-C is the control layer messaging for GTPv2. It is used by LTE mobile stations, SGSN units for backwards compatibility, and SGWs that are the gateway to other networks. The messaging is very different from GTPv1. GTPv2-C is required to communicate with the Mobility Management Entity (MME) to create, change and delete EPS bearers when handover events happen, and to create Forwarding tunnels. The protocol is also used to communicate with the Serving Gateway (SGW) which has the S-GW and PDN-GW interfaces, and the Serving GPRS Support Node (SGSN).

MME

MME essentially fills the role of the SGSN in a GTPv1 network — it is how the mobile stations gain access to the

Carrier network. GTPv2 supports different mobile stations than GTPv1, so MME handles the GTPv2 MSes and SGSN handles the GTPv1 MSes

 

GPRS network common interfaces

Billing and records

A major part of the GPRS network is devoted to billing. Customer billing requires enough information to identify the customer, and then billing specific information such as connection locations and times, as well as amount of data transferred. A modified form of GTP called GTP’ is used for billing. The home location records and visitor location records store information about customers that is critical to billing.

GTP’ (GTP prime)

GTP is used to handle tunnels of user traffic between SGSNs and GGSNs. However for billing purposes, other devices that are not supported by GTP are required. GTP’ (GTP prime) is a modified form of GTP and is used to communicate with these devices such as the Charging Data Function (CDF) that communicates billing information to the Charging Gateway Function (CGF). In most cases, GTP‘ transports user records from many individual network elements, such as the GGSNs, to a centralism computer which then delivers the charging data more conveniently to the network operator’s billing center, often through the CGF. The core network sends charging information to the CGF, typically including PDP context activation times and the quantity of data which the end user has transferred.

GTP’ is used by the Ga and Gz interfaces to transfer billing information. GTP’ uses registered UDP/TCP port 3386. GTP’ defines a different header, additional messages, field values, as well as a synchronization protocol to avoid losing or duplicating CDRs on CGF or SGSN/GGSN failure. Transferred CDRs are encoded in ASN.1.

HLR

The Home Location Register (HLR) is a central database that contains details of each mobile phone subscriber that is authorized to use the GSM core network. There can be several logical, and physical, HLRs per public land mobile network (PLMN), though one international mobile subscriber identity (IMSI)/MSISDN pair can be associated with only one logical HLR (which can span several physical nodes) at a time. The HLRs store details of every SIM card issued by the mobile phone operator. Each SIM has a unique identifier called an IMSI which is the primary key to each HLR record.

VLR

The Visitor Location Register (VLR) is a database which stores information about all the mobile devices that are currently under the jurisdiction of the Mobile Switching Center which it serves. Of all the information the VLR stores about each Mobile Station, the most important is the current Location Area Identity (LAI). This information is vital in the call setup process.

Whenever an MSC detects a new MS in its network, in addition to creating a new record in the VLR, it also updates the HLR of the mobile subscriber, informing it of the new location of that MS.

For more information on GTP‘, see GTP-U and Charging Management Messages.

MMS DLP archiving

You can use DLP archiving to collect and view historical logs that have been archived to a FortiAnalyzer unit or the

FortiGuard Analysis and Management service. DLP archiving is available for FortiAnalyzer when you add a FortiAnalyzer unit to the FortiOS Carrier configuration. The FortiGuard Analysis and Management server becomes available when you subscribe to the FortiGuard Analysis and Management Service.

You can configure full DLP archiving and summary DLP archiving. Full DLP archiving includes all content, for example, full email DLP archiving includes complete email messages and attachments. Summary DLP archiving includes just the meta data about the content, for example, email message summary records include only the email header.

You can archive MM1, MM3, MM4, and MM7 content.

Configuring MMS DLP archiving

Select DLP archive options to archive MM1, MM3, MM4, and MM7 sessions. For each protocol you can archive just session metadata (Summary), or metadata and a copy of the associated file or message (Full).

In addition to MMS protection profile DLP archive options you can:

• Archive MM1 and MM7 message floods l Archive MM1 and MM7 duplicate messages
• Select DLP archiving for carrier endpoint patterns in a Carrier Endpoint List and select the Carrier Endpoint Block option in the MMS Scanning section of an MMS Protection Profile

FortiOS Carrier only allows one sixteenth of its memory for transferring content archive files. For example, for Carrier-enabled FortiGate units with 128 MB RAM, only 8 MB of memory is used when transferring content archive files. Best practices dictate to not enable full content archiving if antivirus scanning is also configured because of these memory constraints.

To configure MMS DLP archiving – web-based manager

1. Go to Security Profiles > MMS Profile.
2. Select Create New or select the Edit icon beside an existing profile.
3. Expand MMS Bulk AntiSpam Detection > Content Archive.
4. Complete the fields as described in DLP Archive options.
5. Select OK.

Viewing DLP archives

You can view DLP archives from the Carrier-enabled FortiGate unit web-based manager. Archives are historical logs that are stored on a log device that supports archiving, such as a FortiAnalyzer unit.

These logs are accessed from either Log & Report > DLP Archive or if you subscribed to the FortiCloud service, you can view log archives from there.

The DLP Archive menu is only visible if one of the following is true.

• You have configured the FortiGate unit for remote logging and archiving to a FortiAnalyzer unit.
• You have subscribed to FortiCloud.

The following tabs are available when you are viewing DLP archives for one of these protocols.

• E-mail to view POP3, IMAP, SMTP, POP3S, IMAPS, SMTPS, and spam email archives. l Web to view HTTP and HTTPS archives. l FTP to view FTP archives.
• IM to view AIM, ICQ, MSN, and Yahoo! archives. l MMS to view MMS archives. l VoIP to view session control (SIP, SIMPLE and SCCP) archives.

If you need to view log archives in Raw format, select Raw beside the Column Settings icon.

 

MMS content-based Antispam protection

Expand MMS Scanning and select Content Filter in an MMS protection profile to create content filter black/white lists that block or allow MMS messages based on the content of the message.

Overview

A school computer lab may block age-inappropriate content. A place of business may block unproductive content. A public access internet cafe may block offensive and graphic content. Each installation has its own requirements for what content needs to be blocked, and in what language.

FortiOS Carrier provides the ability to create custom local dictionaries, black lists, and white lists in multiple languages enables you to protect your customers from malicious content around the world.

Configurable dictionary

You can create a dictionary of configurable terms and phrases using the CLI. The text of MMS messages will be searched for these terms and phrases. Add content filter lists that contain content that you want to match in MMS messages. For every match found, a score is added. If enough matches are found to set the total score above the configured threshold, the MMS message is blocked.

You can add words, phrases, wild cards and Perl regular expressions to create content patterns that match content in MMS messages. For more on wildcard and regular expressions, see Using wildcards and Perl regular expressions in the UTM guide.

For each pattern you can select Block or Exempt.

• Block adds an antispam black list pattern. A match with a block pattern blocks a message depending on the score of the pattern and the content filter threshold.
• Exempt adds an antispam white list pattern. A match with an exempt pattern allows the message to proceed through the FortiOS Carrier unit, even if other content patterns in the same content filter list would block it.

If a pattern contains a single word, the FortiOS Carrier unit searches for the word in MMS messages. If the pattern contains a phrase, the FortiOS Carrier unit searches for all of the words in the phrase. If the pattern contains a phrase in quotation marks, the FortiOS Carrier unit searches for the whole phrase.

You can create patterns with Simplified Chinese, Traditional Chinese, Cyrillic, French, Japanese, Korean, Spanish, Thai, or Western character sets.

Black listing

Black listing is the practice of banning entries on the list. For example if an IP address continuously sends viruses, it may be added to the black list. That means any computers that consult that list will not communicate with that IP address.

Sometimes computers or devices can be added to black lists for a temporary problem, such as a virus that is removed when notified. However, as a rule short of contacting the administrator in person to manually be removed form the black list, users have to wait and they generally will be removed after a period without problem.

White listing

White listing is the practice of adding all critical IP addresses to a list, such as company email and web servers. Then if those servers become infected and start sending spam or viruses, those servers are not blocked. This allows the critical traffic through, even if there might be some malicious traffic as well. Blocking all traffic from your company servers would halt company productivity.

Scores and thresholds

Each content pattern includes a score. When a MMS message is matched with a pattern the score is recorded. If a message matches more than one pattern or matches the same pattern more than once, the score for the message increases. When the total score for a message equals or exceeds the threshold the message is blocked.

The default score for a content filter list entry is 10 and the default threshold is 10. This means that by default a message is blocked by a single match. You can change the scores and threshold so that messages can only be blocked if there are multiple matches. For example, you may only want to block messages that contain the phrase “example” if it appears twice. To do this, add the “example” pattern, set action to block and score to 5. Keep the threshold at 10. If “example” is found twice or more in a message the score adds up 10 (or more) and the message is blocked.

Configuring content-based antispam protection

To apply content-based antispam protection – CLI

config webfilter content edit <filter_table_number> set name <filter_table_name> config entries

edit <phrase or regexp you want to block> set action {block | exempt} set lang <phrase language> set pattern-type {wildcard | regexp} set score <phrase score> set status {enable | disable}

end

end

Configuring sender notifications

When someone on the MMS network sends an MMS message that is blocked, in most cases you will notify the sender. Typically an administrator is notified in addition to the sender so action can be taken if required. There are two types of sender notifications available in FortiOS Carrier: MMS notifications, and Replacement Messages.

MMS notifications

MMS notifications to senders are configured in Security Profiles > MMS Profile, under MMS Notifications.

In this section you can configure up to four different notification recipients for any combination of MM1/3/4/7 protocol MMS messages. Also for MM7 messages the message type can be submit.REQ or deliver.REQ.

Useful settings include:

l delay in message based on notification type l limit on notifications per second to prevent a flood l schedules for notifications l log in details for MM7 messages.

For more information on MMS notifications, see Notifying message flood senders and receivers and MMS

Notifications.

Replacement messages

Replacement messages are features common to both FortiOS and FortiOS Carrier, however FortiOS Carrier has additional messages for the MMS traffic.

While each MMS protocol has its own different rec placement messages, the one common to all MMS protocols is the MMS blocked content replacement message. This is the message that the receiver of the message sees when their content is blocked.

Sender notifications and logging

In most cases you will notify the sender that they are causing problems on the network — either by sending malware content, flooding the network, or some other unwanted activity. The notification assumes the sender is unaware of their activity and will stop or correct it when notified.

However, senders who are notified may use this information to circumvent administration’s precautions. For example if flood notification is set to 1000 messages per minute, a notified user may simply reduce their message to 990 messages per minute if this flood is intentional. For this reason, not all problems include sender notifications.

There are two methods of notifying senders:

• MMS notifications l Replacement messages

And three details to consider for logging and notifying administrators:

• Logging and reporting l MMS logging options l SNMP

MMS notifications

MMS notifications enable you to customize notifications for many different situations and differently for all the supported MMS message protocols — MM1, MM3, MM4, and MM7.

MMS notification types include:

l Content Filter l File Block l Carrier Endpoint Block l Flood l Duplicate l MMS Content Checksum l Virus Scan

Day of Week, Window start time and Window Duration define what days and what time of day alert notifications will be sent. This allows you to control what alerts are sent on weekends. It also lets you control when to start sending notifications each day. This can be useful if system maintenance is performed at the same time each night — you might want to start alert notifications after maintenance has completed. Another reason to limit the time alert messages are sent could be to limit message traffic to business hours.

Notifications screen for FortiOS Carrier MMS Profile

For MMS Notification options, see MMS Notifications.

Replacement messages

FortiGate units send replacement messages when messages or content is blocked, quarantined, or otherwise diverted from the receiver. In it’s place a message is sent to notify the receiver what happened.

With FortiOS Carrier MMS replacement messages, send and receive message types are supported separately and receive their own custom replacement messages. This allows the network to potentially notify both the sender and receiver of the problem.

For example the replacement message MM1 send-req file block message is sent to the device that sent one or more files that were banned. The default message that is sent is This device has sent %%NUM_ MSG%% messages containing banned files in the last %%DURATION%% hours. The two variables are replaced by the appropriate values.

Replacement messages are not as detailed or specific as MMS notifications, but they are also not as complicated to configure. They are also useful when content has been removed from an MMS message that was still delivered.

Logging and reporting

With each virus infection, or file block, a syslog message is generated. The format of this syslog message is similar to:

2005-09-22 19:15:47 deviceid=FGT5001ABCDEF1234 logid=0211060ABC type=virus subtype=infected level=warning src=10.1.2.3 dst=10.2.3.4 srcintf=port1 dstintf=port2 service=mm1 status=blocked from=”<sending MSISDN>” to=”<receiving MSISDN>” file=”eicar.com.txt” virus=”EICAR_TEST_FILE” msg=”The file eicar.com.txt is infected with EICAR_TEST_FILE. ref

http://www.fortinet.com/VirusEncyclopedia/search/encyclopediaSearch.do?method=quickSea rchDirectly&virusName=EICAR_TEST_FILE”

Note that the from and to fields are samples and not real values.

MMS logging options

You can enable logging in an MMS protection profile to write event log messages when the MMS protection profile options that you have enabled perform an action. For example, if you enable MMS antivirus protection, you could also use the MMS protection profile logging options to write an event log message every time a virus is detected.

To record these log messages you must first configure how the FortiOS Carrier unit stores log messages.

To configure MMS content archiving, go to Security Profiles > MMS Profile. Select Create New or select the Edit icon beside an existing profile. Expand MMS Bulk AntiSpam Detection > Logging. Complete the fields as described in the following table and select OK. For more a detailed list of options, see Logging.

SNMP

A simple SNMP trap will be generated to inform the operators’ alerting system that a virus has been detected. This SNMP trap could contain the sending and receiving MSISDN, however the initial solution would reflect the current behavior, i.e. only the fact that a virus has been detected will be communicated.

Employing MMS Security features

FortiOS Carrier includes all the Security features of FortiOS with extra features specific to MMS carrier networks.

This section includes:

Why scan MMS messages for viruses and malware?

The requirement for scanning MM1 content comes from the fact that MMS is an increasingly popular technique for propagating malware between mobile devices.

Example: COMMWARRIOR

This is a virus for Series 60 type cell phones, such as Nokia, operating Symbian OS version 6 [or higher]. The object of the virus is to spread to other phones using Bluetooth and MMS as transport avenues. The targets are selected from the contact list of the infected phone and also sought via Bluetooth searching for other Bluetoothenabled devices (phones, printers, gaming devices etc.) in the proximity of the infected phone.

This virus is more than a proof of concept – it has proven successfully its ability to migrate from a zoo collection to being in-the-wild. Currently, this virus is being reported in over 18 different countries around Europe, Asia and North America.

When the virus first infects a cell phone, a prompt is displayed asking the recipient if they want to install “Caribe”. Symptoms of an infected phone may include rapid battery power loss due to constant efforts by the virus to spread to other phones via a Bluetooth seek-and-connect outreach.

The following variants among others are currently scanned by the FortiOS Carrier devices, in addition to more signatures that cover all known threats.

l SymbOS/COMWAR.V10B!WORM

• Aliases: SymbOS.Commwarrior.B, SymbOS/Commwar.B, SymbOS/Commwar.B!wm, SymbOS/Commwar.B-net,

SymbOS/Commwarrior.b!sis, SymbOS/Comwar.B, SymbOS/Comwar.B!wm, SymbOS/Comwar.B-wm, SYMBOS_

COMWAR.B, SymbOS/Comwar.1.0.B!wormSYMBOS/COMWAR.V10B.SP!WORM [Spanish version] l First Discovered In The Wild: July 04, 2007 l Impact Level: 1 l Virus Class: Worm l Virus Name Size: 23,320 l SymbOS/Commwar.A!worm

• Aliases: Commwarrior-A, SymbOS.Commwarrior.A [NAV], SymbOS/Commwar.A-net, SymbOS/Commwar_

ezboot.A-ne, SymbOS/Comwar.A, SymbOS/Comwar.A-wm, SYMBOS_COMWAR.A [Trend]

• First Discovered In The Wild: May 16 2005 l Impact Level: 1 l Virus Class: Worm l Virus Name Size: 27,936 l SymbOS/Commwarriie.C-wm l Aliases: None l First Discovered In The Wild: Oct 17 2005 l Impact Level: 1 l Virus Class: File Virus l Virus Name Size: None

For the latest list of threats Fortinet devices detect, visit the FortiGuard Center.

MMS virus scanning

You can use MMS virus scanning to scan content contained within MMS messages for viruses. FortiOS Carrier virus scanning can be applied to the MM1, MM3, MM4, and MM7 interfaces to detect and remove content containing viruses at many points in an MMS network. Perhaps the most useful interface to apply virus scanning would be the MM1 interface to block viruses sent by mobile users before they get into the service provider network.

To go to MMS virus scanning, go to Security Profiles MMS Profile, select an existing or create a new profile, and expand MMS Scanning. See MMS scanning options.

This section includes:

l MMS virus monitoring l MMS virus scanning blocks messages (not just attachments) l Scanning MM1 retrieval messages l Configuring MMS virus scanning l Removing or replacing blocked messages l Carrier Endpoint Block l MMS Content Checksum l Passing or blocking fragmented messages l Client comforting l Server comforting l Handling oversized MMS messages

MMS virus monitoring

To enable MMS virus monitoring, expand MMS Scanning and enable Monitor only for the selected MMS types.

This feature causes the FortiOS Carrier unit to record log messages when MMS scanning options find a virus, match a file name, or match content using any of the other MMS scanning options. Selecting this option enables reporting on viruses and other problems in MMS traffic without affecting users.

MMS virus scanning blocks messages (not just attachments)

To enable MMS virus scanning, expand MMS Scanning and enable Virus Scan for the selected MMS types.

Because MM1 and MM7 use HTTP, the oversize limits for HTTP and the HTTP antivirus port configurations also apply to MM1 and MM7 scanning. See

MM3 and MM4 use SMTP and the oversize limits for SMTP and the SMTP antivirus port configurations also apply to MM3 and MM4 scanning.

The message contents will be scanned for viruses, matched against the file extension blocking lists and scanned for banned words. All these items will be configured via the standard GUI interfaces available for the other protocols and will be controlled at the protection profile level with new options specifically for the MM1 messages.

The FortiOS Carrier unit extracts the sender’s Mobile Subscriber Integrated Services Digital Network Number (MSISDN) from the HTTP headers if available. The POST payload will be sent to the scan units which will parse the MMS content and scan each message data section. If any part of the data is to be blocked, the proxy will be informed, the connection to the MMSC will be reset and the Carrier-enabled FortiGate unit will return an HTTP 200 OK message with an m-send-conf payload to the client to prevent a retry. Finally the appropriate logging, alert, and replacement message events will be triggered.

For client notification, the x-mms-response-status and x-mms-response-text fields can also be customized as required.

Scanning MM1 retrieval messages

To scan MM1 retrieval messages, expand MMS Scanning and select Scan MM1 message retrieval.

Select to scan message retrievals that use MM1. If you enable Virus Scan for all MMS interfaces, messages are also scanned while being sent. In this case, you can disable MM1 message retrieval scanning to improve performance.

Configuring MMS virus scanning

To configure MMS virus scanning, expand MMS Scanning and enable Virus Scan.

Once applied to a security policy, the MMS protection profile will then perform virus scans on all traffic accepted by that policy.

Removing or replacing blocked messages

To remove blocked messages, expand MMS Scanning and select Remove Blocked for the selected MMS types.

Select Remove Blocked remove blocked content from each protocol and replace it with the replacement message. If FortiOS Carrier is to preserve the length of the message when removing blocked content, as may occur when billing is affected by the length of the message, select Constant.

If you only want to monitor blocked content, select Monitor Only.

Carrier Endpoint Block

A carrier endpoint defines a specific client on the carrier network. Typically the client IP address is used to identify the client, however on a carrier network this may be impractical when the client is using a mobile device. Other identifying information such as the MSIDSN number is used instead.

This information can be used to block a specific endpoint on the network. Reasons for blocking may include clients whose accounts have expired, clients from another carrier, clients who have sent malicious content (phishing, exploits, viruses, etc), or other violations of terms of use.

Enabling carrier endpoint blocking

To enable carrier endpoint blocking you first need to create a carrier endpoint filter list, and then enable it.

To enable carrier endpoint blocking – web-based manager

1. Create a carrier endpoint filter list.
2. Go to Security Profiles > MMS Profile.
3. Select Create New, or select an existing profile to edit and select Edit.
4. Expand MMS Scanning.
5. Select one or more types of MMS messaging to enable endpoint blocking on.
6. Select the carrier endpoint filter list to use in matching the endpoints to be blocked.

Create a carrier endpoint filter list

A carrier endpoint filter list contains one or more carrier endpoints to match. When used in MMS scanning entries in the filter list that are matched are blocked.

You can configure multiple filter lists for different purposes and groups of clients, such as blocking clients, clients with different levels of service agreements, and clients from other carriers. See Carrier endpoint filter lists configuration settings.

To create a carrier endpoint filter list – web-based manager

1. Go to Security Profiles > Carrier Endpoint Filter Lists.
2. Select Create New.
3. Enter a descriptive name for the filter list, such as blocked_clients or CountryX_clients, and select OK.
4. Select Create New to add one or more entries to the list.
5. Select OK to return to display the list of filter lists.

Configuring endpoint filter list entries

For each single endpoint or group of endpoints have part of their identifying information in common, you create an entry in the endpoint filter list.

For example a blocked_clients filter list may include entries for single endpoints added as each one needs to be blocked and a group of clients from a country that does not allow certain services.

To configure an endpoint filter list entry – web-based manager

1. Select Create New.
2. Enter the following information and select OK.

Name	Name of endpoint filter list. Select this name in an MMS protection profile.
Comments	Optional description of the endpoint filter list.
Check/Uncheck All	Select the check box to enable all endpoint patterns in the MMS filter list. Clear the check box to disable all entries on the MMS filter list. You can also select or clear individual check boxes to enable or disable individual endpoint patterns.
Pattern	The pattern that FortiOS Carrier uses to match with endpoints. The pattern can be a single endpoint or consist of wildcards or Perl regular expressions that will match more than one endpoint. For more on wildcard and regular expressions, see Using wildcards and Perl regular expressions in the UTM guide.
Action		Select the action taken by FortiOS Carrier for messages from a carrier endpoint that matches the endpoint pattern: None – No action is taken. Block – MMS messages from the endpoint are not delivered and FortiOS Carrier records a log message. Exempt from mass MMS – MMS messages from the endpoint are delivered and are exempt from mass MMS filtering. Mass MMS filtering is configured in MMS protection profiles and is also called MMS Bulk Email Filtering and includes MMS message flood protection and MMS duplicate message detection. A valid use of mass MMS would be when a service provider notifies customers of a system-wide event such as a shutdown. Exempt from all scanning – MMS messages from the endpoint are delivered and are exempt from all MMS protection profile scanning.
Content Archive		MMS messages from the endpoint are delivered, the message content is DLP archived according to MMS DLP archive settings. Content archiving is also called DLP archiving.
Intercept		MMS messages from the endpoint are delivered. Based on the quarantine configuration, attached files may be removed and quarantined.
Pattern Type		The pattern type: Wildcard, Regular Expression, or Single Endpoint.
Enable		Select to enable this endpoint filter pattern.

Blocking network access based on endpoints

You can use endpoint IP filtering to block traffic from source IP addresses associated with endpoints. You can also configure FortiOS Carrier to record log messages whenever endpoint IP filtering blocks traffic. Endpoint IP filtering blocks traffic at the IP level, before the traffic is accepted by a security policy.

To configure endpoint IP filtering, go to Security Profiles > IP Filter and add endpoints to the IP filter list. For each endpoint you can enable or disable both blocking traffic and logging blocked traffic.

FortiOS Carrier looks in the current user context list for the endpoints in the IP filter list and extracts the source IP addresses for these endpoints. Then any communication session with a source IP address that matches one of these IP addresses is blocked at the IP level, before the communication session is accepted by a security policy.

FortiOS Carrier dynamically updates the list of IP addresses to block as the user context list changes. Only these updated IP addresses are blocked by endpoint IP filtering.

For information about the carrier endpoints and the user context list, including how entries are added to and removed from this list.

MMS Content Checksum

The MMS content checksum feature attempts to match checksums of known malicious MMS messages, and on a successful match it will be blocked. The checksums are applied to each part of the message—attached files and message body have separate checksums. These checksums are created with CRC-32, the same method as FortiAnalyzer checksums.

For example, if an MMS message contains a browser exploit in the message body, you can add the checksum for that message body to the list, and future occurrences of that exact message will be blocked. Content will be replaced by the content checksum block notification replacement message for that type of MMS message, and if it is enabled the event will be logged.

One possible implementation would to configure all .sis files to be intercepted. When one is found to be infected or malicious it would be added to the MMS content checksum list.

To use this feature a list of one or more malicious checksums must be created and then the feature is enabled using that list. For a detailed list of options, see MMS Content Checksum.

To configure an MMS content checksum list

1. Go to Security Profiles > MMS Content Checksum.
2. Select Create New.
3. Enter a name for the list of checksums, and select OK. You are taken to the edit screen for that new list.
4. Select Create New to add a checksum.
5. Enter the Name and Checksum, and select OK. The checksum is added to the list.

To add more checksums to the list, repeat steps 4 and 5.

To remove a checksum from the list you can either delete the checksum or simply disable it and leave it in the list.

To enable MMS content checksums, expand MMS Scanning and select MMS Content Checksum for the selected MMS types. Select the checksum list to match.

Passing or blocking fragmented messages

Select to pass fragmented MM3 and MM4 messages. Fragmented MMS messages cannot be scanned for viruses. If you do not select these options, fragmented MM3 and MM4 message are blocked.

The Interval is the time in seconds before client comforting starts after the download has begun, and the time between sending subsequent data.

The Amount is the number of bytes sent by client or server comforting at each interval.

Client comforting

In general, client comting is available for for MM1 and MM7 messaging and provides a visual display of progress for web page loading or HTTP or FTP file downloads. Client comforting does this by sending the first few packets of the file or web page being downloaded to the client at configured time intervals so that the client is not aware that the download has been delayed. The client is the web browser or FTP client. Without client comforting, clients and their users have no indication that the download has started until the Carrier-enabled FortiGate unit has completely buffered and scanned the download. During this delay users may cancel or repeatedly retry the transfer, thinking it has failed.

The appearance of a client comforting message (for example, a progress bar) is client-dependent. In some instances, there will be no visual client comforting cue.

During client comforting, if the file being downloaded is found to be infected, then the Carrier-enabled FortiGate unit caches the URL and drops the connection. The client does not receive any notification of what happened because the download to the client had already started. Instead the download stops, and the user is left with a partially downloaded file.

If the user tries to download the same file again within a short period of time, then the cached URL is matched and the download is blocked. The client receives the Infection cache message replacement message as a notification that the download has been blocked. The number of URLs in the cache is limited by the size of the cache.

Client comforting can send unscanned (and therefore potentially infected) content to the client. Only enable client comforting if you are prepared to accept this risk. Keeping the client comforting interval high and the amount low will reduce the amount of potentially infected data that is downloaded.

MM1 and MM7 client comforting steps

Since MM1 and MM7 messages use HTTP, MM1 and MM7 client comforting operates like HTTP client comforting.

The following steps show how client comforting works for a download of a 1 Mbyte file with the client comforting interval set to 20 seconds and the client comforting amount set to 512 bytes.

1. The client requests the file.
2. The Carrier-enabled FortiGate unit buffers the file from the server. The connection is slow, so after 20 seconds about one half of the file has been buffered.
3. The Carrier-enabled FortiGate unit continues buffering the file from the server, and also sends 512 bytes to the client.
4. After 20 more seconds, the FortiGate unit sends the next 512 bytes of the buffered file to the client.
5. When the file has been completely buffered, the client has received the following amount of data: ca * (T/ci) bytes == 512 * (40/20) == 512 * 2 == 1024 bytes,

where ca is the client comforting amount, T is the buffering time and ci is the client comforting interval.

6. If the file does not contain a virus, the Carrier-enabled FortiGate unit sends the rest of the file to the client. If the file is infected, the FortiGate closes the data connection but cannot send a message to the client. Server comforting

Server comforting can be selected for each protocol.

Similar to client comforting, you can use server comforting to prevent server connection timeouts that can occur while waiting for FortiOS Carrier to buffer and scan large POST requests from slow clients.

The Interval is the time in seconds before client and server comforting starts after the download has begun, and the time between sending subsequent data.

The Amount is the number of bytes sent by client or server comforting at each interval.

Handling oversized MMS messages

Select Block or Pass for files and email messages exceeding configured thresholds for each protocol.

The oversize threshold refers to the final size of the message, including attachments, after encoding by the client. Clients can use a variety of encoding types; some result in larger file sizes than the original attachment. As a result, a file may be blocked or logged as oversized even if the attachment is several megabytes smaller than the oversize threshold.

MM1 sample messages

Internet Protocol, Src Addr: 10.128.206.202 (10.128.206.202), Dst Addr: 10.129.192.190 (10.129.192.190)

Transmission Control Protocol, Src Port: 34322 (34322), Dst Port: http (80), Seq: 1, Ack: 1, Len: 1380

Source port: 34322 (34322)

Destination port: http (80)

Header length: 20 bytes

Flags: 0x0010 (ACK)

Window size: 24840

Checksum: 0x63c1 (correct)

HTTP proxy

Hypertext Transfer Protocol

POST / HTTP/1.1\r\n

Request Method: POST

Request URI: /

Request Version: HTTP/1.1

Host: 10.129.192.190\r\n

Accept: */*, application/vnd.wap.sic,application/vnd.wap.mms-message,text/xhdml,image/mng,image/x-mng,video/mng,video/x-mng,image/bmp\r\n

Accept-Charset: utf-8,*\r\n

Accept-Language: en\r\n

Content-Length: 25902\r\n

Content-Type: application/vnd.wap.mms-message\r\n

User-Agent: Nokia7650/1.0 SymbianOS/6.1 Series60/0.9 Profile/MIDP-1.0

Configuration/CLDC-1.0 UP.Link/6.2.1\r\n x-up-devcap-charset: utf-8\r\n x-up-devcap-max-pdu: 102400\r\n x-up-uplink: magh-ip.mi.vas.omnitel.it\r\n

x-wap-profile: “http://nds.nokia.com/uaprof/N7650r200.xml”\r\n x-up-subno: 1046428312-826\r\n x-up-calling-line-id: 393475171234\r\n x-up-forwarded-for: 10.211.4.12\r\n x-forwarded-for: 10.211.4.12\r\n Via: 1.1 magh-ip.mi.vas.omnitel.it\r\n

\r\n

Scan engine

MMS Message Encapsulation, Type: m-send-req

X-Mms-Message-Type: m-send-req (0x80)

X-Mms-Transaction-ID: 1458481935

X-Mms-MMS-Version: 1.0

From: <insert address>

To: 3475171234/TYPE=PLMN

X-Mms-Message-Class: Personal (0x80)

X-Mms-Expiry: 21600.000000000 seconds

X-Mms-Priority: Normal (0x81)

X-Mms-Delivery-Report: No (0x81)

X-Mms-Read-Report: No (0x81)

Content-Type: application/vnd.wap.multipart.related; start=<1822989907>; type=application/smil

Start: <1822989907>

Type: application/smil

Data (Post)

Multipart body

Part: 1, content-type: text/plain

Content-Type: text/plain; charset=iso-10646-ucs-2; name=Ciao.txt

Charset: iso-10646-ucs-2

Name: Ciao.txt

Headers

Content-Location: Ciao.txt

Line-based text data: text/plain

\377\376C\000i\000a\000o\000 [Unreassembled Packet: MMSE]