SMS Firewall

Solution Description

Version 3.0
Contents
1. INTRODUCTION .................................................................................................................................. 3
1.1. PURPOSE OF AN SMS FIREWALL................................................................................................................... 4
1.1.1. SMS Security ......................................................................................................................................... 4
1.1.2. A2P Monetisation................................................................................................................................. 4
2. SYSTEM CAPABILITIES....................................................................................................................... 5
2.1. FIREWALL POLICIES ....................................................................................................................................... 5
2.2. FIREWALL RULES ........................................................................................................................................... 5
2.3. MESSAGE TAGGING ....................................................................................................................................... 7
2.4. BACKUP AND RESTORE ................................................................................................................................. 8
2.5. SMS ANALYSIS ............................................................................................................................................. 9
2.6. PRE-CONFIGURED RULES .............................................................................................................................. 11
2.7. MULTI-TENANCY .......................................................................................................................................... 12
2.8. SMS HOME ROUTING .................................................................................................................................. 13
3. NETWORK IMPLEMENTATION.......................................................................................................... 14
3.1. NETWORK INTEGRATION .............................................................................................................................. 14
3.2. SYSTEM COMPONENTS ................................................................................................................................ 15
3.3. SMPP INTERCEPTION OVER SS7 ................................................................................................................. 15
3.4. MESSAGE INTERCEPTION ............................................................................................................................. 16
3.4.1. Basic SMS Message Flow ................................................................................................................. 16
3.4.2. STP Configuration .......................................................................................................................... 17
3.4.3. Intercepted SMS Message Flow ................................................................................................. 17
3.5. SMS FIREWALL REDUNDANCY ..................................................................................................................... 18
4. FIREWALL ANALYTICS ...................................................................................................................... 19
4.1. POST PROCESSING ...................................................................................................................................... 19
4.2. TRAFFIC OVERVIEW .................................................................................................................................... 20
4.3. ACTIONS ...................................................................................................................................................... 21
4.4. ACTIONS PER NETWORK ............................................................................................................................. 22
4.5. MESSAGE TYPES PER NETWORK................................................................................................................. 22
4.6. MESSAGE LOGS .......................................................................................................................................... 23
5. SYSTEM MONITORING & DIAGNOSTICS........................................................................................ 24
5.1. NORTHBOUND INTERFACES ........................................................................................................................ 24
5.2. MONITORING AND ALARMS ......................................................................................................................... 25
5.2.1. Alarms.............................................................................................................................................. 25
5.2.2. Cluster Diagnostics ....................................................................................................................... 26
5.2.3. Service Monitoring ........................................................................................................................ 27
5.2.4. Server Diagnostics ........................................................................................................................ 27
5.2.5. Firewall Diagnostics ..................................................................................................................... 28
5.2.6. ALERT LOGS ........................................................................................................................................... 28
5.2.7. AUDIT LOGS ........................................................................................................................................... 29
6. STANDARDS COMPLIANCE ............................................................................................................. 30
7. REFERENCES ..................................................................................................................................... 30

2
1. Introduction
Cellusys SMS Firewall is an industry recognised Tier 1 product that defends a mobile network
from all SMS-based messaging attacks and provides full protection and control over all
messaging on the network. It is built of the same engine/platform that is used for the Cellusys
Signalling Firewall, meaning that all the latest technologies and features are available to the
SMS Firewall also.

SMS are terminated on a customer network using various routes and technologies:

• International SMS arrives via international providers/gateways and national off-net

SMS from other national MNOs arrive over SS7 interconnect links. These can be either
TDM or Sigtran based.
• Enterprise messaging arrives over SMPP connections connected to the customers SMS
Gateway or SMS. These SMPP connections can be for either international enterprise
or from enterprise incorporated in the home country.
• SMS can both originate and terminate from the customer network. This includes
legitimate person-to-person messaging as well as illegitimate simbox/simfarm sources.

SMS Firewall is deployed at the network border to intercept messaging on interconnect links.
Internal messaging can also be protected depending on customer needs. This is depicted
below:

Figure 1: Sources of SMS

3
 1.1. Purpose of an SMS Firewall
There are two main purposes for the installation of an SMS Firewall. Cellusys SMS Firewall
addresses both of these needs.

1.1.1. SMS Security

SMS Security is a requirement in any network to prevent against network and subscriber abuse
and fraud. SMS vulnerabilities are outlined in the GSMA documents IR.70: SMS Fraud and IR.71:
SMS Fraud Prevention. The threats described in these documents are outlined below:

Threats What Happens Risk to the Operator

SMS Spamming Unwanted SMS messages are delivered Irritated subscribers, degraded
to subscribers. performance, blamed for relay!
SMS Flooding Remote system sends massive numbers Overload in the Signalling Network, home
of messages targeting subscribers and network incurs relay operator costs!
nodes.
SMS Faking Foreign system illegally uses identity if Home operator cannot collect termination
SMSC. fees!
SMS Spoofing Messages sent illegally by simulating Subscribers wrongfully billed for unsent
subscribers in a roaming situation. messages and perhaps unwanted
content!
SMS Scanning Foreign system floods the target network SMSC will be forced to send SMS from
with MO ForwardSM messages in order to foreign systems and home operator
find an unsecure SMSC. cannot collect fees!

In addition to the threat groups above, the operator may have other threats related to
message parameters, such as SMS content (viruses and smishing) SMS Phishing - contacting
an SMS user, often with false credentials, and attempting to glean personal details (like credit
card number) or trick them into responding to a premium number or accessing a website which
infects the phone with a virus. Critically, 2-factor authentication using SMS as the
authentication medium is being used by more and more enterprises for security purposes.
Abusing the SMS protocol can leave subscribers vulnerable to account hijacking and/or
unauthorised access.

1.1.2. A2P Monetisation

A2P Monetisation is the business strategy of classifying SMS into two categories. A2P
(Application-to-Person) and P2P (Person-to-Person) SMS. Enterprise sending traffic to Home
Network subscribers (i.e. A2P SMS) have to pay a higher rate for SMS termination. The purpose
of the SMS Firewall is to detect and block A2P SMS traffic that is being sent into the Home
network over a grey-route (i.e. a cheaper route designed for P2P traffic). Thus, ensuring that
all A2P SMS is terminated over official routes.

Figure 2: A2P Revenue Lost with no SMS Firewall deployment

4
2. System Capabilities
2.1. Firewall Policies
Cellusys SMS Firewall allows configuration of a complex set of policies covering all security
threats to a mobile network. A policy is a term used for a list of rules. When an SMS is received
by the Firewall, it will match all Rules in a Policy starting with the first rule, then second rule,
third rule etc. As such, rules have a priority order.

A policy can be created for SMS terminating on the network over SS7 or SMPP. As such, the
following message types are supported on the Firewall:

• SS7 MAP SRI-SM (Send Routing Information for Short Message)

• SS7 MAP MO_ForwardSM (Mobile Originated Forward Short Message)
• SS7 MAP MT_ForwardSM (Mobile Terminated Forward Short Message)
• SMPP SubmitSM (Submit Short Message)
• SMPP DeliverSM (Deliver Short Message)

Note: SMS Firewall is fully compliant with SMPP v3.4 and MAP 3GPP TS 29.002-Rel12. All
phases of MAP are supported (Phase 1,2,2+).

2.2.Firewall Rules
An individual rule is comprised of multiple parts:

• Name/Description: Used for rule management on the Web GUI

• Criteria: Identification traits of the SMS being targeted in the rule
• Action: What action to perform on the SMS that match the criteria in this rule.

Rule Criteria – A rule can contain to multiple criterion with “AND” logic and “OR” logic
supported. In order to match the rule, all criteria must be true when evaluating the message.
Cross comparison of message parameters from the same or different layers is supported.

After selecting a message parameter as a criterion, the user can specify a value to match. This
value can be an entire address, a prefix of an address, a range of numbers or an uploaded list
of values. Regular Expression matching is also supported for advanced matching cases. Each
message is enriched with helpful parameters by the Firewall also (i.e. source country, source
network, destination country, destination network etc).

Figure 3: Screenshot of adding a criterion

5
All messaging layers are supported and every parameter is available to the rules system. This
covers every parameter available in M3UA, MTP3, SCCP, TCAP, MAP, SM-TP and SMPP. While
the list below is not exhaustive, it highlights just some of the criteria that would be commonly
used in rule matching:

Source Destination SCCP TCAP MAP SM-TP SMPP

Country Country Calling Party OpCodeMAP MSISDN Sender ID SenderID

Message
Network Network Called Party IMSI Recipient
Content

Service Type of Destination

Centre Number Address

Type of
Protocol ID
Number

Data Coding
Scheme

SMS Content

Figure 4: Sample Criteria (not exhaustive)

Actions – are performed on messages that match all criteria in a given rule. It is an instruction
to the SMS Firewall of what to do with the message that has matched. Below is a list of actions
that are available on the Firewall:

• Continue/Monitor: Take no action / monitor message, and check the remaining rules.
• Pass: Deliver the message and do not process any more rules.
• Drop: The message is removed from the network.
• Drop with positive acknowledgement: Fake acknowledgement sent to SMS sender.
• Drop with negative acknowledgement: With configurable error code and error reason.
• Modify message: Change a value in the message.
o E.g. Change Sender ID, change SMSC address, modify message content.

Additionally, the user can also add the following optional actions:

• Log message to the database or CDR file for later analysis.

• Send alert: SNMP and/or Email is sent to a configurable user or group

Rate limiters to ensure message throughput can be controlled based on source global title,
sender ID, or any other parameter. For example, one rule can ensure that no single Global
Title can send more than 50 messages per second into the network.

External Queries – are supported to ensure the messages that are arriving into the network
are coming from a valid roaming subscriber and is not spoofed. SMS Firewall creates and
sends MAP messages to the HLR to determine additional subscriber information. ATI, SRI-SM
and SRI-LCS messages can be used for this query. This is commonly known as a Location
Verification Check.

Lists – SMS Firewall allows for CSV file uploads to match against large numbers of values
without the need for duplicating rules. List download to CSV files is also supported.

6
 2.3. Message Tagging
SMS Firewall allows for “tagging” of messages as they pass through the system. Tagging is a
means of classification that can add one or multiple “tags” to a message. Some examples of
tags that might be added are as follows:

• “International” – If the SMS is arriving from an external country

• “National” – If the SMS is arriving from another MNO in the same country
• “Enterprise” – If the message has been received from an SMPP source
• “A2P” or “P2P” – If the message has been determined as A2P or P2P

The ability to add tags is performed as a Rule “action”. If an SMS has a certain characteristic
then a tag can be applied. For example, if the TON (Type of Number) is alphanumeric then a
tag called “alpha-sender” can be added to the message. Tags are used in two different
ways:

• In rule matching. It is possible to add a criterion that checks for the presence of a tag.
For example, if the tag “alpha-sender” is present, then add the tag “A2P”. Then a
subsequent rule may check if the tag “A2P” is present and the source is not an A2P
approved route, then a Rule action of Drop can be applied. Rules can be chained
together so that a single message can match multiple rules and have many
categories/tags added before deciding to allow or drop a message.
• For filtering reports. It is possible to filter the reports of the system by tag. For example,
it is possible to view all SMS received by country/network and filter out only messages
with the “alpha-sender” tag (or any other defined tag).

Tags are completely custom and user generated. There is no limit to the number of tags that
can be created. A tag does not change the underlying SS7 or SMPP message – it is simply
“meta-information” that exists for the lifetime of message processing through the firewall.

7
 2.4. Backup and Restore
A complete backup of all rules is created each time a configuration change is made to a policy,
rule or list. These backups are timestamped and can be viewed on the Web GUI. An authorised
user can view all backups and rollback to any previous configuration point should any issues
with the current ruleset occur.

This feature is particularly useful if a logical error is made by an end user after updating a rule
and SMS are unintentionally blocked. Should such a scenario occur, it is possible to roll back
to a previous configuration point before this error was introduced.

Figure 5: Backup and Restore Web GUI

8
 2.5.SMS Analysis
The SMS Analysis solution is an embedded software module that can optionally be activated
on the SMS Firewall solution. This module focuses on SMS content analysis for identifying /
classifying / blocking categories of messages such as A2P, P2P and Spam.

This module includes very advanced analytics and reporting capabilities that can show a
breakdown of SMS arriving into the Home Network based on enterprise sender, sender ID,
country and network etc.

The A2P SMS Analysis will deliver two high level abilities:

SMS Content Analysis –This module will scan the content of all SMS passing through the
Firewall and produce SMS "Signatures" when there a multiple SMS containing the same /
similar content. The information contained within an individual signature is as follows:

• SMS Message Content (and variations if any).

• Count of SMS matching the content pattern.
• Count & List of Sender IDs matching this content pattern.
• Count & Sample list of Receivers of the SMS.
• Message Type of the SMS (e.g. MO / MT / SMPP).

Figure 6: Example Message Signature

9
Each Signature can be "tagged" with either "A2P", "P2P", or "Spam". A tag is meta-information
that is attached to the signature. If a future occurrence of an SMS arrives at the Firewall that
is similar to a defined signature, then the tag is automatically added. All messages that have
an A2P tag (and arrive over a non-approved route) can be dropped. Additionally, each
signature can have extra "tags" applied to it to sub classify the message. Examples include
“Facebook”, “Google”, “one_time_password” etc.

Figure 7: Sample Message Signature Classification

A2P Analysis Reports –Typically, this section of the module is used to identify the enterprise
sending the A2P SMS (i.e. Facebook, Google, Uber, etc.). Based on these additional tags, the
A2P Analysis module can provide in depth reporting on A2P SMS arriving into the operator’s
network. A high-level overview of the data available in the report is as follows:

• Breakdown of A2P vs P2P traffic arriving into the network.

• Of the A2P traffic, a breakdown of the sending enterprise (i.e. Viber, WhatsApp etc.).
• Sender IDs used in the A2P SMS.
• Source Countries / Networks of these SMS.
• Source SCCP Calling GTs (i.e. sending SMSC addresses) of these SMS.
• Timeline of when these SMS arrived into the network.
• Any custom tag that is applied in the rules section.

The main benefit of this report is its ability to add "filters" to the data. The report is fully
interactive so clicking on any metric will apply a filter. Some examples of how data is exposed
as below:

• Clicking of "Facebook" will show all the countries/networks/SMSCs that sent this traffic,
along with the sender ID's used.
• Clicking on an SMSC address will show all the enterprises sending SMS from this SMSC
as well as the Sender ID's used.
• Clicking on a SenderID (e.g. Facebook) will show all enterprises using this shortcode
(e.g. using local SMPP connections as a grey-route.)

10
 2.6.Pre-configured Rules
As part of the deployment of the SMS Firewall, Cellusys will install the system with two
preconfigured Policies. These Policies can be enabled, disabled, and/or modified as per
customer needs. The two Policies provided are listed below:

SMS Security Policy – This policy will contain countermeasures outlined in the GSM IR.70 and
IR.71 documents to protect the network against spam, faking, spoofing etc. A summary of some
of the rules/checks included in this Policy are outlined below:

• SRISM Layer Consistency Check (SCCP/MAP)

• MT_ForwardSM Layer Consistency Check (SCCP/MAP)
• MT_ForwardSM from external SMSC with SM-RP-OA of HPMN
• MT_ForwardSM with no IMSI present
• MO_ForwardSM Layer Consistency Check (SCCP/MAP)
• MO_ForwardSM from HPMN subscriber with foreign SMSC destination
• MO_ForwardSM received to HPMN SMSC from foreign subscriber (IMSI)
• MO_ForwardSM received to HPMN SMSC from foreign subscriber (MSISDN)
• Roaming MO_ForwardSM Location Verification Check

It is common for a customer to have network specific exceptions to certain checks which is
catered for in the Firewall with the management of whitelists/permit-lists. These lists can be
added/modified via the Web GUI or via a CSV file upload/download section of the system.

A2P Monetisation Policy – This Policy will contain a structured approach to detecting and
blocking A2P SMS messages that are arriving into the network over a grey-route. It will classify
SMS based on SenderID, Source, and most importantly based on SMS Content (using the SMS
Analysis module). The Policy will check the SMS against the following rules in order:

Identify Classify/Tag SMS if Classify/Tag SMS if Classify/Tag SMS if

Country/Network sent via an sender ID is sender ID is a
of SMS receiver approved route alphanumeric short-code

Classify/Tag SMS if Block SMS from Allow SMS destined

Allow SMS from
receiver is an known grey-route for Inbound
approved routes
Inbound Roamer Global Titles Roamers

Apply Message Block SMS from Block SMS based

Block SMS from
Signature Detection alphanumeric on presence of A2P
short-code senders
/ Classification senders SMS content

Figure 8: A2P Monetisation Policy (High Level)

11
 2.7. Multi-Tenancy
SMS Firewall can be deployed in a multi-tenant environment. This allows for one physical
deployment and for multiple virtual instances of the Firewall exist. The only requirement from
a technical standpoint is that the SMS for all tenants should pass via the SMS Firewall. There
are two common scenarios where multi-tenancy is typically used:

HPMN with MVNO – If the HPMN has one or multiple MVNOs deployed and shares core
network resources, then it is possible to deploy SMS Firewall and create multiple tenants.

Signalling/SMS Hub – A Signalling Provider/Aggregator provides interconnectivity to multiple

MNOs where SMS messages will pass through the core network of the provider. A single
deployment of SMS Firewall can intercept the SMS for all these MNOs and provide multiple
tenant accounts for virtual SMS Firewall instances.

With any multi-tenant deployment there will be one account that is considered to be the
“super-user” account. For the purposes of this example we’ll assume the HPMN is the super-
user. The HPMN can create a tenant account, in this case the MVNO, and configure the
identification criteria for traffic ownership. Identification criteria can be anything that the HPMN
desires, some examples including CgPA/CdPA ranges, IMSI ranges, etc. The below diagram
assumes identification via a SCCP CdPA range:

Figure 9: Multi-Tenancy High Level View

It will appear to each tenant as if a separate SMS Firewall system has been deployed
specifically for them. Each tenant will be able to enact rules on traffic that belongs to them
only. There will be a separate login / Web GUI / reporting access for each tenant. There is no
limit to the number of tenants that can be created on the SMS Firewall.

12
 2.8.SMS Home Routing
SMS Home Routing can optionally be deployed alongside SMS Firewall. Some networks may
not have need for the SMS Home Routing module as this may already be deployed in another
network element (e.g. SMSC). Cellusys provides SMS Home Routing according to 3GPP TR
23.840 in Transparent mode. It supports TCAP Handshaking on MT submission, 3GPP TS
33.200 compliant. There are configuration options to exclude certain sources / range of
sources from the SMS Home Routing Process.

From a high-level SMS Home Routing provides 2 main benefits to an MNO:

• If a foreign network is sending an SMS to a roaming HPMN subscriber, SMS Home

Routing will force the MT-FSM via the SMS Firewall for scanning and protection before
the SMS is delivered to the subscriber. Without SMS Home Routing, the foreign network
can send MT-FSM messages directly to the roaming subscriber without inspection by
the HPMN.
• If a foreign network is sending a message to a HPMN subscriber (at home or roaming),
then the foreign SMSC will issue an SRISM message to discover routing details for SMS
delivery. The SMS Home Router will provide the foreign SMSC with fake IMSI and MSC
details so that no internal network or subscriber information will be leaked to foreign
parties.

Figure 10: SMS Home Routing Message Flow

13
3. Network Implementation
SMS Firewall is deployed on site in customer data centres. Both bare-metal and virtual
machines deployments are supported. Should the customer supply virtual machines for
Cellusys to deploy onto, they must meet minimum specifications supplied by Cellusys.

3.1. Network Integration

SMS Firewall will connect with the customer STPs over SIGTRAN M3UA. Based on the
dimensioning of links, traffic volumes and redundancy profile, the number and location of
Message Processor machines can be ascertained.

The Firewall nodes will sit on dedicated M3UA links behind the customer STPs. As the Firewall
does not support interception of TDM links directly, the TDM connections from external
sources to the customer STP is terminated at the STP and then forwarded to the Firewall over
SIGTRAN M3UA. This is achieved by the Firewalls acting as an M3UA endpoint and the
customer STPs configured to route traffic to the platform for analysis and policy enforcement.
Below is an architecture diagram representing generically how the system will be deployed.

Figure 11 Network Integration Overview

Cellusys systems integrate into the network core with a system called Access Platform (M3UA
ASP Endpoint). It is responsible for managing and maintaining the links to the operator for
message interception. The Access platform is responsible for sending and receiving messages
between the network and the SMS Home Router application. Each system is configured to
meet the operator’s network capacity requirements. The platform can be easily expanded for
future growth.

14
 3.2. System Components
There are two types of servers/machines used in the architecture of SMS Firewall. Central
Severs and Message Processors. This is true whether a bare-metal or virtual machine
deployment is selected.

Message Processors are deployed in the network core. They provide three functions:
• Access Platform for sending and receiving messages to/from the network.
• SMS Firewall Application for screening SMS messages.
• SMS Home Routing Application (optional).

All messaging from the SS7/SIGTRAN and/or SMPP network is relayed to the servers for
processing via the IP network. In the Access Platform, all MAP messages involved with SMS
transactions (MO, SRI-SM, MT) are intercepted and forwarded the cluster of Message
Processing Servers for processing. Message Processors can be easily added to the system to
increase capacity and performance.

Central Server machines are deployed in a cluster and provide multiple functions:
• Web based System Administration Interface
• Threat Analysis
• System Monitoring
• Database / Reporting

3.3. SMPP Interception over SS7

It is not strictly necessary to intercept SMPP traffic directly on SMPP links, but this is supported
by SMS Firewall if required. It is possible to capture SMPP traffic on the SMS Firewall via the
SS7 delivery leg of the SMS. This reduces the complexity of deployment. Below is a depiction
of such a setup.

Figure 12: SMPP SMS Capture over SS7

(1) SMPP Message is submitted to SMSC over SMPP

(2) SMSC issues a SRISM to determine recipient location
(3) SRISM is routed via STP to HLR (SRISRESP send back to SMSC)
(4) SMSC issues a MT-FSM to deliver SMS to recipient
(5) STP receives and sends MT-FSM to SMS Firewall
(6) SMS-FW returns MT-FSM to STP, then MT-FSM is delivered to destination MSC

15
 3.4. Message Interception
In order to describe how the SMS Firewall intercepts SMS messages from the core network,
we will first describe a normal message flow without the presence of a Firewall.

3.4.1. Basic SMS Message Flow

Figure 13 Basic SMS Message Flow

Ø Subscriber sends an SMS MO to the home SMSC. The SMSC acknowledges.

Ø The SMSC sends an SRI-SM to determine the location of the recipient. The HLR (from
the destination recipient's home network) responds with the location and IMSI of the
recipient.
Ø The SMSC forwards the SMS MT to the serving MSC of the recipient, where it is
transferred over the air to the recipient's handset. An acknowledgment is sent back to
the SMSC to confirm delivery.

Note: Optional TCAP handshaking for SMS MT may also be part of this message flow. SMS
Firewall fully supports TCAP Handshaking. This is relevant for SMS Home Routed Message
Flows.

16
 3.4.2. STP Configuration
In order to receive the SMS traffic from the customer STPs, there are required routing changes
on the STPs. Essentially, all SMS traffic, in addition to traffic that is addressed to the Firewall
must be routed to the Firewall. These changes are based on TCAP OpCode Routing** in
addition to SCCP Called Party routing. STP routing requirements are detailed in the table
below:

Message Type TCAP OpCode Source Destination

MO ForwardSM 46 Foreign MSC / SGSN Local SMSC

SRI-SM Request 45 Foreign SMSC Local HLR

MT ForwardSM 44/46 Foreign SMSC Local MSC / SGSN

NOTE: Messages where SCCP CdPA is SMS Firewall Global Title will be routed also

** Note: TCAP OpCode Routing is the preferred method of message interception, but many
other integration options are also available if the customer STP is not capable of this.

3.4.3. Intercepted SMS Message Flow

Implementing the routing changes above on the STP will result in all SMS-related messages
routed to the SMS Firewall system. These messages are then processed and forwarded on to
their original destination. This intercepted SMS message flow assumes SMS Home Routing is
not activated. If SMS Home Routing is activated, the message flow depicted in section 2.8 is
accurate. The major difference between the two setups is that response messages are
intercepted with SMS Home Routing. The diagram below shows the flow of messages via the
SMS Firewall system:

Figure 14: Intercepted SMS Message Flow

17
 3.5. SMS Firewall Redundancy
There are multiple layers of redundancy built into the system outlined in sections below:

Hardware Level:
• Dual Power Supplies
• Dual Network Interface Cards
• Dual Ethernet cables for Signalling Traffic
• Multiple HDD in RAID deployment

Deployment Level:
• Multiple Message Processors per site (N+1 redundancy per site)
• Message Processors operate independently of Central Servers
• Central Servers operate in an active-active cluster allowing for failures

Logical Level:
• Each SCTP connection utilises multi-homing
• Traffic interception on links is spread across all Message Processors

The customers STPs will be configured with a “primary” and a “secondary” route. Messages
will only be sent to the Firewall for processing if the Firewall is available. If the Firewall is not
available, then the message will be routed to the core network (with no security screening) to
ensure service continuity.

Figure 15: Message Processing Redundancy

18
4. Firewall Analytics
This chapter describes the process on generation of report data as well as some reports that
the system offers. This is not an exhaustive list of reports offered by the Firewall, rather a
smaller list to demonstrate its capabilities.

4.1. Post Processing

The Post Processor is a software module which runs of the Central Servers that performs
analysis on message logs after they have been processed by the Message Processors. It will
compare and analyse multiple messages within a single transaction as well as comparing
messages from multiple transactions from a single traffic source.

The purpose of the post processor is to perform stateful analysis which can be fed back into
the rules engine for actionable countermeasures against attacks. The Message Processors
process traffic on a per message basis. There is no multi-message stateful processing on the
Message Processor itself, and this results in a high performant firewall. The Post Processor
will perform the stateful analysis without affecting performance of the Message Processors.

Separating out stateful analysis on the Central Servers increases reliability of the Message
Processors as even if there is a failure in the Central Servers, the Message Processors will
continue to process traffic and provide security screening with the latest data set it received.

Figure 16: Post Processor Overview

From the diagram above, the blue arrows & text represent the actual SMS message being
processed and the orange arrows & text represent a copy of that message being processed.

When a Message Processor receives a message, it consults all the rules that are defined by
the user – in addition the Message Processor will check the SMS against defined SMS
Signatures for A2P and Spam identification. These SMS Signatures are stored in a cache in
Message Processor memory. There is a log created of the processed message before it is sent
back to the core network for delivery.

These logs are sent by all Message Processors to the Central Server cluster to be processed
by the Post Processor. The Post Processor will perform stateful checks and create SMS
Signatures to be pushed to the Message Processors as well as writing to the report DB which
is used the data source for showing reports on the Web GUI.

19
 4.2. Traffic Overview
The Firewalls report can be filtered by Firewall and Proxy Connection for more precise
information.
• Message Counts displays counts of messages received from and sent to source and
destination Proxy Connections.
• Source and Destination Latencies show the P50 / P95 / Maximum message latencies.
Source refers to the Source side of the Proxy Connection. Destination refers to the
Destination side of the Proxy Connection.
o Max latency shows that all messages at that time were processed within the
value shown when hovered over.
o The P95 latency shows that 95% of messages at that time were processed
within the time period shown.
o The P50 latency shows that 50% of messages at that time were processed
within the time period shown.
• Errors in decoding each of the message layers are graphed over time.
• Actions taken on messages can also be graphed and broken down by Firewall and
Proxy Connection using filters.
• A breakdown of the different message type passing through the firewalls

Figure 17: Traffic Overview Screenshot

20
 4.3. Actions
The Actions report can be filtered by Firewall, Policy, Rule, or Source. It gives a more fine-
grained analysis of the effects of each Policy on the messages passing through the Proxy
Connections.

• Allowed and Dropped message counts are displayed for the time period selected.
• Actions Taken totals and percentages over time are also graphed.
• Message counts broken down by Policy, Rule and Checks are also shown.
• All panels can be filtered by particular firewalls, policies, ruleset, rules, action and
external query type.

Figure 18: Actions Screenshot

21
 4.4. Actions Per Network
The Actions Per Network report can be filtered by Country and Network for more precise
information. Action counts (e.g. allow) are shown per country, network and network node.

Figure 19: Actions per Network Screenshot

4.5. Message Types Per Network

Similar to the Actions Per Network report, the Message Types Per Network report can be
filtered by Country and Network for more precise information. Message types are shown per
country, network and network node.

Figure 20: Message Types per Network Screenshot

22
 4.6. Message Logs
The Message Logs report can be filtered by Firewall, Proxy Connection, Policy and Rule for
more precise information.
• Pie charts show the split for countries and networks for source and destination.
• Rules and Checks matched charts are also shown
• Tags show the tags applied to messages over Proxy Connections, Loop Prevention
and Rules / Checks.
• Individual Message Logs are shown in a table. It is possible to click on one message
line at a time displaying all of the message parameters in table, JSON or raw format.
o The user can search for messages by a specific parameter for example Global
Title digits, one message log line should be expanded by clicking on the line
and finding the message parameter, e.g. sccp.udt.called-party-address.global-
title.digits and selecting the search icon alongside. The report will now filter by
the parameter value specified. The user can modify this value by expanding
the Filtering heading at the top of the page and selecting the edit icon and
modifying, in this case, the digits value and applying it.
o Message counts over time are shown.
o A breakdown of messages across Firewalls and the different types is also
shown.

Figure 21: Message Logs Screenshot

23
5. System Monitoring & Diagnostics
5.1. Northbound Interfaces
SMS Firewall can integrate into external systems of the customer. This is performed to allow
for server synchronisation, alerting and user interaction between the customer and SMS
Firewall.

For alerting purposes both SNMP v2c and SMTP/Email interfaces towards the network
monitoring system and email server are supported. This allows for configurable alerts to be
sent to individuals or groups of end users when an event of note is triggered in the system.

The primary method of interacting with SMS Firewall is via the Web User Interface. This
interface supports HTTPS for increased security. CSV file uploads and downloads is supported
for exporting reports and also for viewing/updating configuration on the rules system.

NTP server integration is performed to keep all servers in the SMS Firewall deployment in time
synchronisation to avoid unwanted technical issues that are timing related.

These interfaces are outlined in the diagram below.

Figure 22: SMS Firewall Northbound and Southbound Interfaces

24
 5.2.Monitoring and Alarms
SMS Firewall provides comprehensive monitoring of the cluster and individual nodes in the
cluster. Monitoring has various reports which give a visual representation of the health of the
server components and the processes running on them.

5.2.1. Alarms
Alarms and Traps are reported on the Web UI and are available both in SNMP or email alerts.
The alarms are discussed in a comprehensive Alarms Guide as part of the User
Documentation. The Alarms Guide contains such information as:

• Alarm ID: The ID of the SNMP trap which will be generated once triggered by an event.
• Severity: The severity of the event such as Critical, Major, Minor and Info.
• Alarm Name: The name given to a particular alert.
• Description: A brief description of what has caused the alert to occur.
• Problem / Error Alarm examples: The text which will be sent as an alert when there is
a problem with a server or process.
• Informational / Cleared Alarm examples: The text which will be sent when the server
or process has returned to normal operating conditions.
• Recommended Thresholds: Suggested thresholds used to trigger alarms. These will
either be Greater Than (GT) or Less Than (LT) depending on the particular alert.
• Action: What steps need to be followed to resolve the problem.

Figure 23: Add Page for new Custom Alert

25
 5.2.2. Cluster Diagnostics
Cluster diagnostics shows the current state of all servers in the cluster. This is useful for
monitoring System Load, Memory and Disk Status. Metrics are constantly updated with latest
values.

• System Load - This shows the average load on servers for the previous 1, 5 and 15
minutes. This metric is relevant to the number of cores in a server so on a single core
machine a load of 1 indicates it is operating at capacity.
• Memory & Swap (%) - This shows the total percentage of used RAM on each server. If
a server has swap configured this will also be displayed showing what percentage is
used.
• Disk I/O (IOPS) - This is the input and output of a disk per second which shows the
stress on each disk in a server.
• Disk Free (%) - This shows the percentage of space available on the hard disk of each
server and shows percentages for the root partition on each disk.
• Network Usage - This shows the amount of network traffic that is being sent and
received by each node in the cluster.

Figure 24: Cluster Diagnostics Screenshot

26
 5.2.3. Service Monitoring
Service monitoring shows the current status of processes running on the cluster. There are
multiple services required to perform all functions of the SMS Firewall and this report gives a
high-level view to see if all services are running. From the screenshot below, it is possible to
view services that are unavailable in a very visual way. This would be a starting point for
investigation of a system or user generated fault. Some of the services that are monitored
include:

• Web User Interface / Web Server

• Monitoring/Alerting Service
• Configuration/Analytics Database
• SMS Analysis etc.

Figure 25: Service Monitoring Screenshot

5.2.4. Server Diagnostics
The Server Diagnostics report shows a historical view for monitoring the hardware
performance of each server in the cluster. Time filters can be applied to show server health
for predefined or custom time periods. Hovering over any of the metrics will reveal more
details.

Figure 18: Server Diagnostics Screenshot

27
 5.2.5. Firewall Diagnostics
The Firewall diagnostics report is a historical view showing performance of individual
Signalling Firewall processes, with a focus on processing latencies and memory usage. It
shows resources being used by the pipeline along with P50, P95, P99 latencies and also traffic
and active messages. Individual firewalls can be selected using the dropdown in the Firewalls
section. The report can also be filtered by Proxy Connections. Time filters can be applied to
show latencies for predefined or custom time periods. Hovering over any of the metrics will
reveal further details

Figure 26: Firewall Diagnostics Screenshot

5.2.6. Alert Logs
The Alert Logs report can be filtered by Firewall for more precise information. It displays
graphs of alert severity, type and destinations, as well as detailed information for each alert
in a table, based on alerts configured which matched Loop Prevention or Rules.

Figure 27: AlertLogs Screenshot

28
 5.2.7. Audit Logs
The Audit Logs report shows the use of the Admin UI.
• Sync Requests, which show when configuration changes are pushed to the Firewalls
are shown over time.
• View, Add, Update and Delete requests are shown by configuration component.
• View, Add, Update and Delete requests are shown by user.
• Configuration Changes table shows the request modifications in detail. Each line can
be clicked on to show the full details in table, JSON or raw format.
• Audit Logs table shows all requests including views.

Figure 28: Audit Logs Screenshot

29
6. Standards Compliance
ü GSMA IR.70 v4.0, SMS SS7 Fraud
ü GSMA IR.71 v6.0, SMS SS7 Fraud Prevention
ü 3GPP TR 23.840 v7.1.0, Home Routing (Technical Specification Group Core Network
and Terminals; Study into routing of MT-SMs via the HPLMN; Rel-7)
ü ITU Q.704 (07/96), Specifications of Signalling System No. 7 – Message transfer part:
Signalling network functions and messages.
ü ITU Q.713 (03/01), Specifications of Signalling System No. 7 – Signalling connection
control part (SCCP): Signalling connection control part formats and codes.
ü ITU Q.773 (06/97), Specifications of Signalling System No. 7 – Transaction capabilities
application part (TCAP): Transactions capabilities formats and encoding.
ü 3GPP Technical Specification Group Core Network and Terminals; Mobile Application
Part (MAP) specification; Rel-8
ü 3GPP TS 23.040 Technical realization of the Short Message Service (SMS); Rel-12
ü SMPP Development Forum Short Message Peer to Peer Protocol Specification v3.4

7. References
Ø SCTP (RFC 4960)
o https://tools.ietf.org/html/rfc4960
Ø M3UA (RFC 4666)
o https://tools.ietf.org/html/rfc4666
Ø MTP3 (ITU-T Q.704)
o https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Q.704-199607-
I!!PDF-E&type=items
Ø SCCP (ITU-T Q.713)
o https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Q.713-199607-
S!!PDF-E&type=items
Ø TCAP (ITU-T Q.773)
o https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Q.773-199706-
I!!PDF-E&type=items
Ø TCAP Dialogue (ITU-T Q.773)
o https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Q.773-199706-
I!!PDF-E&type=items
Ø MAP (3GPP TS 29.002 Rel-12)
o http://www.etsi.org/deliver/etsi_ts/129000_129099/129002/12.06.00_60/ts_12
9002v120600p.pdf
Ø MAP Dialogue (3GPP TS 29.002 Rel-12)
o http://www.etsi.org/deliver/etsi_ts/129000_129099/129002/12.08.00_60/ts_12
9002v120800p.pdf
Ø SM TP (SM-TP TS 23.040 Rel-12)
o http://www.etsi.org/deliver/etsi_ts/123000_123099/123040/12.02.00_60/ts_12
3040v120200p.pdf

30