Introduction
It may now be considered as legacy but SS7 is still the main interconnect interface to communicate between operators.
Over the years, SS7 been targeted by fraudsters (e.g. identity theft, spoofing) and attacks (e.g. DoS). Every operator should make an effort to ensure that traffic passing/traversing their SS7 network is legitimate. Free from unwanted or malicious messages and identify abnormalities.
I had the opportunity to setup SS7 firewall solution (Mobile Application Part [MAP] layer of SS7 Protocol Stack) following the guidelines described by the GSMA’s FS.11
Next sections will give a high level implementation overview.
But before we proceed with the main topic. Let’s step back a bit and review the TCAP and MAP component of the SS7 Protocol stack.
Mobile Application Part (MAP) and Transaction Capability Application Part (TCAP)
TCAP and MAP are both contained in the UDT message of connectionless services of SCCP (Signalling Connection Control Part).
In every signaling message, it must be clear to which proceeding it is related and each is relation is referred to as transaction. The SCCP is used connectionless only, the signaling connections are controlled by the TCAP (Transaction Capabilities Application Part).
There are four TCAP message types:
Begin for the setup of a signaling connection(transaction)
End for the regular clear down of a transaction
Continue for the component transmission over an existing transaction
Abort for the disruption of a transaction due to irregularities. We distinguish between U-Abort (User-Abort) caused by the TCAP user and P-Abort (Provider- Abort caused by the TCAP transaction layer.
The TCAP message type is part of the transaction portion. Furthermore, the transaction portion contains the transaction identities (TID), which identify the transaction in the two affected network nodes. The TIDs can be understood as local addresses used by the network nodes to address the transaction.
The TCAP message Continue contains two transaction identities: one for the origination (OTID) and one for the destination (DTID). Of course, the message Begin only contains the transaction identity of the origination (OTID) since the partner identity is not known yet. The messages End for the regular and Abort for the irregular transaction clear down both contain the transaction identity of the destination (DTID) only.
In order to set up a transaction, one network node (A) sends to the other (B) the TCAP message Begin, thus delivering its own transaction identity. If Continue messages are required, the first Continue serves as an answer to the Begin; with this, B communicates its transaction identity to A. From now on, both sides can exchange Continue messages in an arbitrary sequence. From the point of view of the transaction control, it is not necessary that each Continue is answered by another Continue in the opposite direction; rather, it can happen that two or more Continue are sent in the same direction consecutively. The transaction is cleared down in such a way that one of the two sides (A or B) sends End or Abort to the partner side; there is no response. Sometimes, a transaction is cleared down locally (i.e. without End/Abort) if both sides know that the transaction is not needed any longer (pre- arranged end).
The shortest possible transaction consists of a Begin message from A to B which is answered immediately by an End or Abort from B to A (or by a local transaction cleardown). Begin contains the origination transaction identity only, End and Abort have the destination transaction identity only; as a consequence, no transaction identity of B is required. The transaction is identified by a single identification number (selected by A).
All TCAP messages with the exception of Abort can contain components where certain operations are requested from the partner side or where a reaction to a received operation request is transmitted.
There are four types of components:
Invoke for the request of an operation from the partner side.
ReturnResult(Last) for the transmission of the results of an executed operation which had been requested by the partner side previously
- Return Error for the transmission of errors which have happened during the execution of a requested operation
Reject for the rejection of a received component.
For the distinction of different operations within the same transaction, each operation obtains an invoke identifier which is selected by the requesting side and transmitted to the partner side in the Invoke component. The partner side repeats the invoke identifier in the reply components (Return Result (Last), Return Error or Reject).
It can happen that the reaction to an operation request consists of another request in the opposite direction, i.e. that an Invoke is answered with Invoke (as, in the daily conversation, a question is answered with a counter-question). In this case, the second Invoke contains besides its own invoke identifier the so-called linked identifier, i.e. the identifier of the previous Invoke. Thus, the second Invoke replaces an explicit acknowledgment of the original request (with Return Result (Last) or Return Error), and the linked identifier provides a relation between the two Invokes.
It should be pointed out that, with Reject, not only Invoke components can be rejected (e.g. due to an unknown operation code) but Return Result (Last) or Return Error components as well (e.g. due to an unknown invoke identifier).
A Reject component contains a problem code, which indicates the reason for the rejection. This problem code is defined in the TCAP. The components Invoke, Return Result (Last) and Return Error contain data of the TCAP user (i.e. MAP data with a GSM-PLMN). These data are:
with Invoke : the code of the operation to be executed and further parameters
with Return Result (Last): the code of the executed operation and the execution results
with Return Error: the sort of error the has happened.
The TCAP user is the Mobile Application Part (MAP). It defines the signaling functions which are concerned with information exchange related to the possibility for a mobile station to roam, retrieve information which services are allowed. It is also through MAP message where a roaming mobile station is provisioned on the fly i.e. activation or deletion of a particular service.
For an unprotected SS7 network, using MAP operations subscribers can be a target of DoS or spoofing or signalling flood.
Where and What to Monitor:
As defined, firewall is a security device – that come as a hardware or software that filter traffic and blocking such if it does not comply with the (firewall) rules. This same concept applies to SS7 Firewall.
Monitoring is best placed at the edge of the network e.g. nodes that receive external traffic which is often referred as the STP. Nowadays, every operators (or even MVNOs) have now employed STP to simplify signaling routes and integration of new network elements.
There’s a couple of decision to make, specially in an existing network.
Where do we plug the SS7 firewall?
It can be in front or behind the STP. Putting it in front of the STP is a daunting task to do. Existing interconnect has to be re-configured and re-integrated with new parameters (e.g. new point code) and signaling routes. For practicality, it is oftenly put behind the STP.
How do we proceed?
New generation STP includes by default some basic screening functions where you can set some conditions. e.g. an incoming (external) traffic from the interconnect links (national or international) it is first routed to the SS7 firewall for scrutiny. The firewall can be an external node or a software plug-in in the STP.
Traffic Monitoring
Now its time to setup perimeter monitoring. Before activating any rules, make sure you know your network traffic profile. Start by collecting traffic data for a few weeks.
MAP operations are divided into categories. We should be able to identify which operations are allowed by setting conditions based on the parameter/data contained in the TCAP payload e.g. IMSI –>own subscriber or inbound roamer ( not part of the HPLMN IMSI range)
Suspicious traffic behavior can be classified when
- SCCP Calling Party Address (CgPA) and SCCP Called Party Address (CdPA) GTs are part of the HPLMN GT range. This can be a possible case of spoofing.
MAP Category 1:
The following are packets which are widely regarded as unauthorised at interconnect level, and should not be sent between operators unless there is an explicit bilateral agreement between the operators to do so. Such as :
- Send Routing Info
- AnyTimeInterrogation
- Check IMEI
Map Category 2
Certain GSM-MAP packets are authorised to be received on interconnects between mobile operators and these include SS7 packets that should normally only be received from an inbound roamer’s home network. These require intra-packet logic to be applied to detect anomalies on packets either inbound or outbound. The following packets are worthy of monitoring and analysis on this basis:
- Insert Subscriber Data
- Delete Subscriber Data
- Reset
- Provide Subscriber Info
Map Category 3
This category is allowed at interconnect level but requires additional screening logic to detect anomalies.
- Update Location
- PurgeMS
- Restore Data
The GSMA FS.11 specification provide more detailed guidelines on how to implement/maintain rules by setting conditions base on the MAP information received at interconnect level. From here, you can analyze and decide to allow or drop the packet.
Here’s some rules and example of used cases:
CAT1 MAP Opcodes received at SS7 interconnect level unless an agreement between operator should be blocked.
5 : noteSubscriberDataModified
6 : resumeCallHandling
22: sendRoutingInfo
24: sendRoutingInfoForGprs
25: failureReport
43: checkIMEI
55: sendIdentification
58: sendIMSI
62: anyTimeSubscriptionInterrogation
65: anytimeModification
71: anyTimeInterrogation
83: provideSubscriberLocation
85: sendRoutingInfoForLCS
MAP Opcode that are allowed at SS7 Interconnect level but it should be intended to Inbound roaming only.
If IMSI=Own then it should be blocked
3 : Cancel Location
4 : Provide Roaming Number
70 : Provide Subscriber Info
8 : Delete Subscriber Data
7 : Insert subscriber data
Own GT range received at SS7 interconnect (Spoofing case) should be blocked
SRISM towards HLR Own GT + SCCP CLG GT = Foreign GT should be blocked. As STP routes HLR Own GT to HLR, SRISM is not blocked will result to Home router bypass. Anyway , all interrogations should always be subject for MNP check
Hope this short write-up on SS7 Firewall implementation gave an insight on how to start/built one and maybe help you formulate questions/clarifications when talking to a SS7 firewall vendors.
Feel free to drop a message anytime.
Although more than 20years working on Mobile Telecommunications – Core Network. Always wanting to learn and try new things.