Configuring GTP on FortiOS Carrier
Configuring GTP support on FortiOS Carrier involves configuring a number of areas of features.
GTP support on the Carrier-enabled FortiGate unit
The FortiCarrier unit needs to have access to all traffic entering and exiting the carrier network for scanning, filtering, and logging purposes. This promotes one of two configurations — hub and spoke, or bookend.
A hub and spoke configuration with the Carrier-enabled FortiGate unit at the hub and the other GPRS devices on the spokes is possible for smaller networks where a lower bandwidth allows you to divide one unit into multiple virtual domains to fill multiple roles on the carrier network. It can be difficult with a single FortiOS Carrier as the hub to ensure all possible entry points to the carrier network are properly protected from potential attacks such as relayed network attacks.
A bookend configuration uses two Carrier-enabled FortiGate units to protect the carrier network between them with high bandwidth traffic. One unit handles traffic from mobile stations, SGSNs, and foreign carriers. The other handles GGSN and data network traffic. Together they ensure the network is secure.
The Carrier-enabled FortiGate unit can access all traffic on the network. It can also verify traffic between devices, and verify that the proper GPRS interface is being used. For example there is no reason for a Gn interface to be used to communicate with a mobile station — the mobile station will not know what to do with the data — so that traffic is blocked.
When you are configuring your Carrier-enabled FortiGate unit’s GTP profile, you must first configure the APN. It is critical to GTP communications — no traffic will flow without the APN.
The Carrier-enabled FortiGate unit does more than just forward and route GTP packets over the network. It also performs:
l GTP support on the Carrier-enabled FortiGate unit l GTP support on the Carrier-enabled FortiGate unit l GTP support on the Carrier-enabled FortiGate unit l GTP support on the Carrier-enabled FortiGate unit l GTP support on the Carrier-enabled FortiGate unit
Packet sanity checking
The FortiOS Carrier firewall checks the following items to determine if a packet confirms to the UDP and GTP standards:
l GTP release version number — must be 0, 1, or 2 l Settings of predefined bits l Protocol type l UDP packet length
If the packet in question does not confirm to the standards, the FortiOS Carrier firewall drops the packet, so that the malformed or forged traffic will not be processed.
GTP stateful inspection
Apart from the static inspection (checking the packet header), the FortiOS Carrier firewall performs stateful inspection.
Stateful inspection provides enhanced security by keeping track of communications sessions and packets over a period of time. Both incoming and outgoing packets are examined. Outgoing packets that request specific types of incoming packets are tracked; only those incoming packets constituting a proper response are allowed through the firewall.
The FortiOS Carrier firewall can also index the GTP tunnels to keep track of them.
Using the enhanced Carrier traffic policy, the FortiOS Carrier firewall can block unwanted encapsulated traffic in GTP tunnels, such as infrastructure attacks. Infrastructure attacks involve attempts by an attacker to connect to restricted machines, such as GSN devices, network management systems, or mobile stations. If these attempts to connect are detected, they are to be flagged immediately by the firewall .
Protocol anomaly detection and prevention
The FortiOS Carrier firewall detects and optionally drops protocol anomalies according to GTP standards and specific tunnel states. Protocol anomaly attacks involve malformed or corrupt packets that typically fall outside of protocol specifications. These packets are not seen on a production network. Protocol anomaly attacks exploit poor programming practices when decoding packets, and are typically used to maliciously impair system performance or elevate privileges.
FortiOS Carrier also detects IP address spoofing inside GTP data channel.
See Protocol anomaly detection and prevention.
HA
FortiOS Carrier active-passive HA provides failover protection for the GTP tunnels. This means that an activepassive cluster can provide FortiOS Carrier firewall services even when one of the cluster units encounters a problem that would result in complete loss of connectivity for a stand-alone FortiOS Carrier firewall. This failover protection provides a backup mechanism that can be used to reduce the risk of unexpected downtime, especially for mission-critical environments.
FortiOS HA synchs TCP sessions by default, but UDP sessions are not synchronized by default. However synchronizing a session is only part of the solution if the goal is to continue GTP processing on a synchronized session after a HA switch. For that to be successful we also need to synch the GTP tunnel state. So, once the master completes tunnel setup then the GTP tunnel is synchronized to the slave.
GTP traffic will only flow without interruption on a HA switch if bidirectional GTP policies have been configured: an internal (GTP server) to external (all) UDP port GTP policy, and an external (all) to internal (GTP server) UDP port GTP policy. If either policy is missing then traffic may be interrupted until traffic flows in the opposite direction.
For more information on HA in FortiOS, see the High Availability (HA) Guide or the FortiOS Administration Guide.
Virtual domain support
FortiOS Carrier is suited to both large and smaller carriers. A single Carrier-enabled FortiGate unit can serve either one large carrier, or several smaller ones through virtual domains. As with any FortiGate unit, Carrierenabled units have the ability to split their resources into multiple virtual units. This allows smaller carriers to use just the resources that they need without wasting the extra. For more information on HA in FortiOS, see the Virtual Domains (VDOMs) Guide.
Configuring General Settings on the Carrier-enabled FortiGate unit
To configure the GTP General Settings, go to Security Profiles > GTP Profile, and edit a GTP profile. Expand General Settings to configure settings. See General settings options.
GTP Monitor Mode
The monitor-mode setting is part of the GTP profile. The setting shows on all GTP profiles and works for all GTP versions.
When this setting is enabled, if a GTP packet is to be dropped due to a GTP deny case such as: l GTP_DENY l GTP_RATE_LIMIT l GTP_STATE_INVALID l GTP_TUNNEL_LIMIT
instead of being dropped, it will be forwarded and logged with the original deny log message and a “-monitor” suffix (e.g., state-invalid-monitor).
This setting is found in the CLI.
config firewall gtp edit profile_name …
set monitor-mode [disable*|enable] …
end
end
Configuring Encapsulated Filtering in FortiOS Carrier
Encapsulated traffic on the GPRS network can come in a number of forms as it includes traffic that is “wrapped up” in another protocol. This detail is important for firewalls because it requires “unwrapping” to properly scan the data inside. If encapsulated packets are treated as regular packets, that inside layer will never be scanned and may allow malicious data into your network.
On Carrier-enabled FortiGate units, GTP related encapsulated filtering falls under encapsulated IP traffic filtering, and encapsulated non-IP end user address filtering.
Configuring Encapsulated IP Traffic Filtering
Generally there are a very limited number of IP addresses that are allowed to encapsulate GPRS traffic. For example GTP tunnels are a valid type of encapsulation when used properly. This is the GTP tunnel which uses the Gp or Gn interfaces between SGSNs and GGSNs. However, a GTP tunnel within a GTP tunnel is not accessible — FortiOS Carrier will either block or forward the traffic, but is not able to open it for inspection.
The ability to filter GTP sessions is based on information contained in the data stream and provides operators with a powerful mechanism to control data flows within their infrastructure. You can also configure IP filtering rules to filter encapsulated IP traffic from Mobile Stations.
To configure the Encapsulated IP Traffic Filtering, go to Security Profiles > GTP Profile, and edit a GTP profile. Expand Encapsulated IP Traffic Filtering to configure settings. See Encapsulated IP traffic filtering options.
When to use encapsulated IP traffic filtering
The following are the typical cases that need encapsulated IP traffic filtering:
Mobile station IP pools
In a well-designed network, best practices dictate that the mobile station address pool is to be completely separate from the GPRS network infrastructure range of addresses. Encapsulated IP packets originating from a mobile station will not contain source or destination addresses that fall within the address range of GPRS infrastructures. In addition, traffic originating from the users handset will not have destination/source IP addresses that fall within any Network Management System (NMS) or Charging Gateway (CG) networks.
Communication between mobile stations
Mobile stations on the same GPRS network are not able to communicate with other mobile stations. Best practices dictate that packets containing both source and destination addresses within the mobile station’s range of addresses are to be dropped.
Direct mobile device or internet attacks
It may be possible for attackers to wrap attack traffic in GTP protocols and submit the resulting GTP traffic directly to a GPRS network element from their mobile stations or a node on the Internet. It is possible that the receiving SGSN or GGSN would then strip off the GTP header and attempt to route the underlying attack. This underlying attack could have any destination address and would probably have a source address spoofed as if it were valid from that PLMN.
Relayed network attacks
Depending on the destination the attack could be directly routed, such as to another node of the PLMN, or re wrapped in GTP for transmission to any destination on the Internet outside the PLMN depending on the routing table of the GSN enlisted as the unwitting relay.
The relayed attack could have any source or destination addresses and could be any of numerous IP network attacks, such as an attack to hijack a PDP context, or a direct attack against a management interface of a GSN or other device within the PLMN. Best practices dictate that any IP traffic originating on the Internet or from an MS with a destination address within the PLMN is to be filtered.
