SS7 Firewall

Flexible. Reliable. Powerfull.

FortWing SS7 Firewall delivers protection of mobile network's SS7 cores. Can be deployed per network or country-wide

The Problem

SS7 protocols have been designed and standardised in 1980s when the connected networks were treated as trusted parties of a closed and state controlled community of carriers.

By design, SS7 protocols do not have a build-in mechanisms for authentication and integrity protection. For decades, the security of SS7 system has been solely based on the concept of mutual trust between the interconnecting parties.

Getting access to the global SS7 network is easy and simple, especially with IP based SS7 (SIGTRAN) protocols; many operators offer access and provide GTs from their range. This opens the door for bad actors to potentially exploit the vulnerabilities and abuse this community of trust. Not surprisingly, many attacks have been detected and reported during recent years.

Typical SS7 Attacks

  • HLR Lookup: Identity collection
  • HLR/VLR Lookup: Location tracking
  • Manipulate HLR:
    • Fake location updates
    • Insert GT to fake serving MSC
    • Change forwarding
  • VLR, Subscriber profile manipulation:
    • Change CSI for eavesdropping
    • Remove O-CSI and prepaid subscription to call for free
    • Provision APN
    • Change MSISDN to avoid billing
    • Provision call forwarding for call interception:
    • Provision call forwarding for calling premium services
  • Voice Mail Box access with spoofing CLI
  • Subscriber Deny of Service
  • Terminating SMS with spoofed MSISDN
  • USSD abuse
  • Denial of service

The Recommendedations

Main standardisation bodies (3GPP Security Group SA3, ITU, ANSI, GSM Associtiation) work actively on introducing security related standards that may limit the risks and improve the situation. The industry is taking steps to coordinate, research and react to the reported vulnerabilities.

In summary, the implementation of specific security protection measures are recommended, including more stringent monitoring and special checking of the content of SS7 messages, filtering or firewall features on top of SS7 protocols embedded in the existing (e.g., STPs, HLRs) network nodes and the introduction of new nodes (SS7 firewalls) operating at the border of SS7 network of the operators and in the networks of the interconnecting carriers.

The Solution

SS7 Firewall is a full-featured solution brought by communication security expert Applicata. It follows the recommendations of the standardisation bodies and extends these with additional capabilities based on carefull analysis of cases in the practice of the telecommunidations operators. FortWing comes pre-configured with a full set of flexible rules. It implements industry standard interfaces and can be integrated effortlessly with the networks' configuration and monitoring systems.

FortWing SS7 Firewall provides extensive and powerfull capabilities for message parsing and checking, and the highest level of reliability. The system can be delivered in dual-resilient configuration; the live traffic is automatically preseved even with single-instance configurations.

SS7 Firewall Featrues & Benefits

SS7 Firewall. At. Glance.

Features

  • Covers GSMA Recommendations, including IR.82. “Security SS7 implementation on SS7 network guidelines v2.0” and GSMA PRD FS.07 “SS7 and SIGTRAN Network Security”
  • Supports GSMA Categories 1, 2, 3, 4 and 5 operations
  • Supports SMS-interworking, SMS-spoofing and SMS-faking filtering
  • Easy, flexible and dynamic rules configuration
  • Dual resilient configuration for service high availability
  • Automatic traffic bypass in case of service failure
  • Based on industry standard technologies: netconf, Intel dpdk
  • Model-driven (Yang) configuration and monitoring
  • Model-driven (Yang) automatic configuration and monitoring API generation
  • Model Driven Telemetry: Dial-In and Dial-Out gRPC/HTTP 2 streaming of telemetry data towards pipeline, Apache Kafka bus, Influx TICK stack, Prometheus, Elasticsearch, Splunk, or other dedicated gRPC clients/servers
  • Metrics extraction and transformation and streaming to TSDB consumers like InfluxDB or Prometheus
  • Configuration automatization support
  • High performance

Benefits

  • Introduces a new element at the most beneficial location
  • Minimal changes in network configuration and architecture
  • Minimal impact on other network elements
  • Low operating and maintenance costs
  • Rich filtering capabilities
  • Powerful network protection
  • Visibility of the signaling threats
  • Single or multiple network protection configurations
  • Country-wide protection configurations
  • Comes with pre-configured protection rules
  • Easy integration with the existing provisioning and monitoring systems in the network
  • Transparent mode of operation: the firewall configuration does not require local IP addresses, ports, point codes or global titles
  • Raw filtered messages
  • Reports
  • Round-the-clock support
  • Demo kit available

FortWing SS7 Firewall Deployment Alternatives

In-Network, At Network Border, Single Network, Country-Wide

The firewall can be deployed at network border or in the network, e.g., behind the STP node(s).
Deployments for protecting a single network or multiple networks, including country-wide deployments are possible.

In-Network Deployment
Network Border Deployment
Single Network Deployment
Country-wide Deployment

Message Processing Flow

The system applies the following message processing and filtering flow based on the configured message filtering rules.

SS7 Firewall receives, decodes and parces messages. A filtering rule associated with the corresponding operation is selected. Message parameters are compared with the conditions and checks configured for the selected filtering rule. If the conditions and checks are met then the action associated with the matching conditions is applied by the system. Allowed messages are sent in their original form while the denied messages are modified according to the configured action settings.

Filtering Rules

Message filtering is controlled by Filtering Rules. These are part of the system configuration.

The configuration, including the filtering rules, is described by Yang model. The system comes with an extensive set of pre-configured filtering rules that can be easily modified over the configuration interface if needed without restart.

Each filtering rule contains an ordered list of matching groups. Each matching group may contain multiple matching conditions and filtering checks. An action (deny or allow) is associated with a matching group. It is executed when the parameters of a message match all conditions and checks in the matching group.

A fragment from the Yang model of the system that describes the Filtering Rules is shown below.

Filtering Rules Checks

As part of the matching conditions SS7 Firewall is can apply a set of filtering checks.

The filtering checks implemented by SS7 Firewall cover the checks recommended by standardisations bodies.

Based on real-life scenarios extracted from the practice, SS7 Firewall implements additional filtering checks on the received messages. This results in a set of extremely powerful tools that ensure flexible and reliable network protection.

Filtering checks can also compare message parameters with some values in pre-configured tables or with values retrieved from the core network.

The table below lists some of the filtering checks included in the system. 

container ss7-operation-rules {
    list this-rule {
      key name;
      leaf name { type string;}
      leaf operation-name {
        type leafref {path /root/oper-data/oper/name;}
        mandatory true;
      }
      leaf operation-group {
        type leafref {path /root/oper-data/oper[name=current()/../oper-name/groups/name];}
        mandatory true;
      }
      list match {
        key expr-name;
        leaf expr-name {type string;}
        container sccp-address-mask {
          container cg-sccp-address-mask {uses sccp-address-mask-gr;}
          container cd-sccp-address-mask {uses sccp-address-mask-gr;}
        }
        uses imsi-mask {when /root/oper-data/has-imsi[name=current()/../oper-name];}
        uses msisdn-mask {when /root/oper-data/has-msisdn[name=current()/../oper-name];}
        …
      }
      container on-match {
        uses on-match-actions;
      }
    }   
  }
Filtering Check Description
OpCode, GgGT screening Block particular msg using white/blacklists
OpCode, GgGT, IMSI screening Block particular msg coming from abroad, which are targeting the home users (IMSI or IMSI blacklists) located in home network
VLR and Cg SCCP comparison Compares the current serving VLR address and the Calling SCCP address. Validation may use a prefix
IMSI and HLR comparison Compares IMSI and HLR (Calling SCCP address). Supports IMSI ranges and HLR ranges/whitelists. HLR validation may use a prefix
Current location check Compares with the previous location: analyses if it is physically possible to move from the previous country to this new one
hplmn Check if the message is sent to/from Home PLMN
vplmn Check if the message is sent to/from Visited PLMN
SCCP, SC Address, MSISDN, TP-xxx screening Used with SMS messages
SCCP, IMSI, RR-MMS, TP-xxx screening Used with SMS messages
... ...

High Availability Concept

Single and Dual Resilient Configurations

The product can be installed with a single instance or with two instances in dual resilient configuration.

Single Instance Configuration

Life traffic is automatically bypassed on hardware or software failures of single instance configuration

SS7 Firewall network interfaces supports Bypass mode for automatic traffic re-routing with firewall single node configurations in case of:

  • Power outage
  • Hardware failure
  • Software failure

SS7 Firewall is implemented as a transparent node. It does not have its own IP address, Point Code or Global Title. Accordingly, no reconfiguration is required at the remote ends in case of failure: the live traffic is automatically bypassed without breaking the live traffic flow. Normal operation is automatically restored when the hardware and software component are up again.

Dual Resilient Configuraion

Dual resilient configuration comprises two servers running the firewall system. Network interfaces operate in Normal-Disconnect modes.

When the first server is active its network interfaces operate in Normal mode and receive/send the traffic from/to carriers. The network interfaces of the second server operate in Disconnect mode simulating the interfaces do not exist. Therefore, no traffic is routed to this server. It runs in passive stand-by mode.

On first server failure, its network interfaces switch automatically to Disconnect mode. The traffic from/to carriers/network is no longer sent/received by this server. The network interfaces of the second server automatically switch to Normal mode. This server becomes active server now and starts receiving/sending the traffic from/to carriers/network.

Network Integration

The product supports the industry standards for network management.

The integration with the network configuration and monitoring systems can be easy and flawless.

Configuration Interface

SS7 Firewall follows Yang model-driven configuration. It is delivered with a configuration server that supports Netconf protocol. It also supports Tail-F Confd server and other commercial Netconf servers.

Netconf, Restconf, Web RPC protocols with various encodigs are supported. API modules with classes in Python, CPP and Golang can be generated automatically from the Yang model and can be used for simple and fast integration with the existing configuration systems.

Monitoring Interface

Operational data is MDT- and Yang model-driven. SS7 Firewall can produce gRPC based telemetry streams with this data towards systems like Influxdata TICK stack components, Cisco pipeline, Apache Kafka, and others. The telemetry data can be then forwarded to/scraped by downstream consumers like Prometheus, Elasticsearch, Splunk etc.

SS7 Firewall supports model-driven telemetry dial-out and dial-in gRPC messaging. As illustrated in the diagram, it can communicate with different peers, including Influxdata Telegraph, InfluxDB, Chronogrpaph or Kapacitor (TICK stack), Cisco pipeline and others.

SS7 Firewall streams the telemetry data to the corresponding gRPC servers or clients.
A prometheus instance can scrape Influxdata Telegraph or pipeline retrieving SS7 Firewall metrics. The metrics data can be visualised by an instance of Influxdata Chronograph, grafena, etc.


The gRPC clients and servers that communicate with SS7 Firewall may also communicate with other monitored nodes in the network, e.g., routers.

These may downstream FortWind and/or other telemetry to different datastores. kafka is shown in this example. In retrurn, kafka may stream some data to another downstream consumers which can also be used to supply data to prometheus or to other consumers