project title: enhanced network security for … network security for seamless service ... the...

Deliverable D7.2.1 Dissemination Level: RE 317888-NEMESYS

October 2014 1

SEVENTH FRAMEWORK PROGRAMME

Trustworthy ICT

Project Title:

Enhanced Network Security for Seamless Service Provisioning in the Smart Mobile Ecosystem

Grant Agreement No: 317888, Specific Targeted Research Project (STREP)

DELIVERABLE

D7.2.1: Analysis of attacks against the core network infrastructure

Deliverable No. D7.2.1

Work package No.

WP7 Work package Title

Scenarios development, validation and eval-uation

Task No. T7.2 Task Title Analysis of attacks against the core mobile network infrastructure

Lead Beneficiary CERTH/ITI

Dissemination Level R

Nature of Deliverable PU

Delivery Date 20 November 2014

Status Final

File Name NEMESYS_Deliverable_D7.2.1.pdf

Project Start Date 01 November 2012

Project Duration 36 Months


October 2014 2

Authors List

Author’s Name Partner E-mail Address

Leading Author / Editor

Dimitrios Tzovaras CERTH [email protected]

Co-Authors

Omer H. Abdelrahman ICL [email protected]

Gokce Gorbil ICL [email protected]

Madalina Baltatu TIIT [email protected]

Bhargava Shastry TUB [email protected]

Reviewers List

Reviewer’s Name Partner E-mail Address

Dario Lombardo TIIT [email protected]

Max Suraev TUB [email protected]


October 2014 3

Abstract

The anomaly detection algorithms and the visualization and analysis tools developed in NEMESYS will be evaluated and validated using mobile network simulation exper-iments and test-bed experiments on a controlled small-scale mobile network virtual testing environment. This document presents an overview of the NEMESYS mobile network test-bed, and describes the test-bed experiments that will be conducted in order to quantify the impact of attacks against the core network. The specification and design of the experiments were guided by the use cases identified in WP1 and also by a review of the common and important security threats that mobile networks face. The results of these experiments will be provided in D7.2.2.


October 2014 4

Table of Contents

1 Introduction ........................................................................................................... 8

2 The Mobile Network Test-bed ............................................................................... 8

2.1 Hardware components of the test-bed .......................................................... 8

2.2 Test-bed specifications and architecture ...................................................... 10

3 Security Threats and Related Test-bed Functionalities ....................................... 12

3.1 Required functionalities related to attacks against mobile users ................ 12

3.2 Required functionalities related to attacks against the core network ......... 12

4 Test-bed Experiments .......................................................................................... 13

4.1 Experiment objectives ................................................................................... 14

4.2 Experiment 1: Normal usage from one base station .................................... 14

4.2.1 Scenario and parameters ....................................................................... 14

4.2.2 Network components of interest .......................................................... 15

4.2.3 Required data traces .............................................................................. 15

4.2.4 Notes ...................................................................................................... 16

4.3 Experiment 2: CFU flood from one base station ........................................... 16




4.3.4 Notes ...................................................................................................... 17

4.4 Experiment 3: CFU flood from a compromised femtocell ............................ 17




4.4.4 Notes ...................................................................................................... 17

4.5 Experiment 4: CFU flood from a botnet ........................................................ 17




4.5.4 Notes ...................................................................................................... 18

4.6 Experiment 5: Authentication based DoS attack .......................................... 18




4.6.4 Notes ...................................................................................................... 19

4.7 Experiment 6: PDP context activation/deactivation based DoS attack ........ 19





October 2014 5

4.7.4 Notes ...................................................................................................... 20

5 Conclusions and Future Work .............................................................................. 20

6 References ........................................................................................................... 22

Annex I - Sample configuration OsmoBTS file ............................................................. 23

Annex II - Sample configuration of an OpenBSC file .................................................... 24


October 2014 6

List of Figures

Figure 1: The test-bed consists of open hardware software-defined radio (SDR) transceivers and open source GSM stack from Osmocom project. .............................. 9

Figure 2: Physical representation of the test-bed ......................................................... 9

Figure 3: High level view of the GSM architecture ...................................................... 10

Figure 4: Typical GSM architecture, as described in the initial version of GSM standards...................................................................................................................... 10

Figure 5: Logical representation of the GSM variant implemented TUB testbed ....... 11


October 2014 7

List of Abbreviations

AUC Authentication Center

BTS Base Transceiver Station

BS Base Station

BSS Base Station Subsystem

BSC Base Station Controller

Cell_PCH Cell Paging Channel

CFU Call Forwarding Unconditional

DoS Denial of Service

DDoS Distributed Denial of Service

EIR Equipment Identity Register

GGSN Gateway GPRS Support Node

HLR Home Location Register

IMEI International Mobile Station Equipment Identity

IMSI International mobile subscriber identity

LCR Linux Call Router

MSC Mobile Switching Center

NSS Network Subsystem

RNC Radio Network Controller

SDR Software Defined Radio

UHD Universal hardware driver

VLR Visiting Location Register


October 2014 8

1 Introduction

The evaluation and validation of the technologies developed in NEMESYS constitutes an important task. In order to achieve this goal, we have developed a virtual mobile network test-bed that allows us to closely control the parameters of the network and other operational settings, and enables us to execute the types of attacks that we have identified to be the most relevant and important. The mobile network test-bed runs real networking software and hardware that is typically used by mobile network operators. These experiments aim to quantify the impact of attacks on vari-ous network components using a small-scale mobile network setup that is similar to commercial mobile networks.

Our evaluation and validation activities also includes significant work on mobile net-work simulations since simulation is a useful and cost-effective research tool that allows the study of large-scale effects, which would be impossible to replicate oth-erwise. However, it is important to validate the various assumptions made during our simulation studies by running experiments on actual networking equipment and software. These test-bed experiments will help us improve our simulation experi-ments by enabling us to fine-tune our simulation models and parameters based on observations from the test-bed.

One of the NEMESYS partners, TI-IT, has a large-scale mobile network test-bed that closely follows the 3GPP standards and the setup of a commercial network, but the test-bed lacks the flexibility to allow the integration of new components. We will therefore aim to utilize the TI-IT test-bed in order to collect measurements from normal and infected smartphones. However, in order to evaluate attacks against the core network, we have developed a small-scale mobile network test-bed using an open source architecture, which is described in the next section.

2 The Mobile Network Test-bed

2.1 Hardware components of the test-bed

The small-scale mobile network test-bed we have developed consists of open source hardware, UmTRX, which serves as a dual channel wide-band software Defined Ra-dio (SDR) transceiver. Figure 1 shows the SDR transceiver, where the power supply plug, the Ethernet cable going towards a laptop with software driving the device, and two antennae connected to the UmTRX can be clearly seen. The unplugged inputs are for external reference clock source and other auxiliary purposes that are not necessary for the operation of the test-bed.

Another SDR component is USRP B210. Both are abstracted via UHD (Universal Hardware Driver) interface from Gnuradio project so they look similar from the core network point of view. The SDR components and a laptop are the only hardware components of the experimental test-bed – all the core network functionality is im-plemented in software running on the general-purpose laptop.


October 2014 9

Figure 1: The test-bed consists of open hardware software-defined radio (SDR) transceivers and open source GSM stack from Osmocom project.

Figure 2: Physical representation of the test-bed


October 2014 10

2.2 Test-bed specifications and architecture

The current test-bed includes two SDR transceivers capable of delivering up to 15 half-rate channels for voice calls and SMS. The core network software is running on top of GNU/Linux OS on a regular PC. An overview of the GSM architecture is pre-sented in the following diagram:

Figure 3: High level view of the GSM architecture

The network is largely comprised of two parts: BSS (Base Station Subsystem) and NSS (Network Subsystem). Note that the illustrated case is the general roaming scenario where a mobile phone is not necessary connected to its home network – that is why there is a connection between the NSS and the home network operator's Home Lo-cation Register (HLR) and Authentication Center (AuC). Equivalent components of course exist in the operator's own network.

Figure 4: Typical GSM architecture, as described in the initial version of GSM standards

Nowadays, thanks to advances in hardware and software development over the past years since the inception of GSM, many of those logically separate components are


October 2014 11

merged together as a single hardware or software component implementing neces-sary functionality. For instance HLR, Visiting Location Register (VLR), Equipment Identity Register (EIR) and AuC are often implemented as a single component, espe-cially in case of small mobile network operators, because all of them are essentially databases answering queries regarding various properties of mobile network sub-scribers.

Figure 5: Logical representation of the GSM variant implemented TUB testbed

The NEMESYS testbed follows a minimalist approach, using only SDR transceivers (UmTRX and USRP B210) and a regular laptop as hardware components. The trans-ceivers are connected to the computer via usb3, and each has its own assigned IP address. The software components running on the laptop are as follows. The trans-ceivers are driven by OsmoTRX software which abstracts them from the rest of the system. It implements layer 1 functionalities such as multiplexing, modulation and radio synchronisation. OsmoTRX is connected to OsmoBTS software which imple-ments the Base Transceiver Station (see ETSI TR 121 905 for detailed glossary). In turn, OsmoBTS is connected via the Abis protocol over IP to OpenBSC which imple-ments the remaining components of the mobile network, providing a network-in-the-box solution. Specifically, the OpenBSC provides functionality for the Base Sta-tion Controller (BSC), Mobile Switching Center (MSC) and HLR, in addition to acting as a gateway for external networks.

The HLR, VLR and AuC are implemented as SQLite database managed by OpenBSC. A sample configuration file for OpenBSC can be found in Annex II which includes, in addition to various network-wide parameters and timings, detailed channel alloca-tion on a per BTS basis.

Call routing and test call service are handled by a Linux Call Router (LCR) which is connected to OpenBSC over MNCC protocol. Thus external networks are represent-ed by the LCR which also implements extra services like “echo test” and “music on hold”. This adds flexibility into call processing on the testbed and allows for easier troubleshooting of an overall setup without the need to connect to actual operator's backbone network.

Network traffic collection is performed using GSMTAP protocol, while data from in-ternally-embedded components (such as the HLR) is obtained by analysing logs pro-duced by the software.


October 2014 12

3 Security Threats and Related Test-bed Functionalities

Deliverable D1.1 [1] provides a detailed description and taxonomy of the threat landscape that mobile devices and mobile networks faced from 2011 until now, and gives an insight into how mobile malware and threats against cellular networks are expected to evolve in the near future. Based on the relevant use cases we have iden-tified in WP1 and on our initial review of the mobile threat landscape, we have speci-fied the functionalities that need to be supported by the test-bed and identified the relevant and important attacks against the core network, which are discussed below.

3.1 Required functionalities related to attacks against mobile users

During 2013 and the first half of 2014 the growth of mobile traffic has steadily con-tinued, together with the growth of mobile malware [4], [5]. Based on our review of the mobile security threats in WP1 and recent observations in 2013 and the first half of 2014, we observe that the main functionalities implemented by mobile malware are remote access and botnets, stealing of private information, and premium SMS sending and SMS spam [3]. Therefore, the main threats at mobile devices are con-firmed to be represented by:

Mobile botnets, where the victim mobile devices are remotely controlled by a Command & Control server which can use them to launch further attacks against other mobile devices and the core network.

Premium SMS and call diallers, where the infected devices are used to send premium SMS and make premium calls without the user’s knowledge.

Spyware, where personal and device information is exfiltrated from the vic-tim’s device.

Therefore, we can assert that the attacks proposed in Use Case 1 and presented in detail in Deliverable 1.2 [2] are highly relevant for experimentation within our test-bed. In order to be able to capture data relevant to use case 1 and related attacks against mobile users, our test-bed setup includes components which monitor and interpret the http traffic generated and received by the mobile devices (e.g. see ex-periment #4 in Table 1). We will include the SMS detection capability in the light-weight malware detection module on the phone.

3.2 Required functionalities related to attacks against the core net-work

As far as the core mobile network threat landscape is concerned, deliverable D1.1 [1] shows that the most significant real world impact is observed with applications or malware that consume network bandwidth with excessive signalling activity, which provoke signalling storms and denial-of-service (DoS) conditions. High signalling ac-tivity may not always be due to mobile malware, and non-malicious but poorly de-signed applications may also cause a high signalling load on the mobile network. In any case, signalling storms are due to the vulnerabilities of the control-plane proto-cols, which can be deliberately exploited by attackers.

For example, NSN Smart Labs describe about how recent OTT (over-the-top content) service outages in cloud services provided by Google affected the radio access net-


October 2014 13

works of mobile operators by generating an unexpectedly high signalling load. It is also mentioned that NSN Smart Labs provides consultation to mobile network opera-tors to help guard against network outages caused by signalling overloads [6], [7]. Early work from NSN Labs [8] reports on smartphone behaviour in the network, fo-cusing on signalling load generated by smartphones and apps, and the effect of net-work configuration parameters such as the Cell_PCH state and fast dormancy on sig-nalling load. Nokia, Qualcomm and Apple are explicitly mentioned to be aware of such issues and that they are actively working on addressing them. These issues are described and analysed in detail in deliverable D4.1 of the project [11], which pro-poses a solution to reduce them based on anomaly detection for the signalling pro-tocols used in the mobile networks.

In another work from 2012 [9], Huawei presented a tool able to assess the network friendliness of smartphone applications, which includes metrics on signalling con-sumption and connection consumption among other things. The white paper also discusses the importance of looking at the signalling load generated by an applica-tion in order to assess its network friendliness.

DoCoMo and Verizon Wireless, reported in Rethink Wireless (30 January 2012) [10], an expert discusses how NTT DoCoMo has requested the help of Google in address-ing service outages in its network in Japan due to signalling load generated by a pop-ular Android VoIP application. It is reported that similar issues have been raised by Verizon Wireless.

During 2014 Telecom Italia also experienced some minor disruption conditions of a server due to poor programming of Android applications that inquire the user’s cred-it. These applications generated a lot of unnecessary traffic and, therefore, also sig-nalling traffic.

In conclusion, we can state that the objective of Use Case 2 (Detection of signalling based attacks against mobile network) [2] is to be considered highly significant for experimentation within the test-bed. Therefore, the test-bed setup includes compo-nents which are able to monitor and interpret the signalling traffic produced by the mobile devices which participate in the experiment (e.g. see the experiments in Ta-ble 1).

4 Test-bed Experiments

In this section, we present a description of the major experiments that will be con-ducted on the NEMESYS test-bed. These experiments will be conducted on either the small-scale test-bed or the more realistic and comprehensive TI-IT test-bed, depend-ing on the capabilities and availability of the test-beds. We will present the evalua-tion of the NEMESYS technologies in the proposed experiments in D7.2.2.

We would like to note that due to the limitations of the test-bed, it is not possible to conduct experiments on realistic distributed DoS-type attacks since they require a large number of mobile devices and/or a 3GPP standards-compliant signalling load generator that is able to emulate a large number of mobile devices. However, exper-iments on the test-bed can provide realistic measurements regarding the throttling effect of the wireless medium and the interactions between malware and remote


October 2014 14

servers which can then be used to drive more realistic simulation experiments in T7.3.

4.1 Experiment objectives

These experiments aim to:

Examine the feasibility of the attacks against real network components.

Study how the network degrades as attack parameters change (e.g., rate of in-

coming packets).

Use the generated data for the visualisation of signalling attacks on core network

components.

Use the generated data to evaluate the integrated NEMESYS solution, in identify-

ing threats against the mobile network and the end users (will be presented in

D7.2.2).

In order to meet these objectives, we have designed the following experiment sce-narios on signalling attacks against the core network, which are listed in Table 1 and described below.

Table 1: Experiment scenarios on signaling attacks against the core network

# Experiment Network

Generation Network

plane

1 Normal usage from one base station (base case) 2G Control-plane

2 CFU flood from one base station 2G Control-plane

3 CFU flood from a compromised femtocell 2G Control-plane

4 CFU flood from a botnet 2G Control-plane

5 Authentication based DoS attack 3G/4G

Control-plane & User-plane

6 PDP context activation/deactivation based DoS attack 3G/4G

Control-plane & User-plane

4.2 Experiment 1: Normal usage from one base station

4.2.1 Scenario and parameters

This scenario will provide a base case for comparison against attack scenarios and allow us to observe the network under normal conditions. A number of non-malicious mobile devices will be registered in the network and monitored.

The parameters, as outlined in the table below, indicate that three separate experi-ment instances are needed. Each one will have a different percentage of normal us-ers registered in the HLR (meaning that their IMSI is contained in the database). The total number of active users should be equal to the maximum number of users that can use the network simultaneously, for OsmoBTS base station. The distribution of users in the normal usage experiment is defined in the table that follows:


October 2014 15

Parameter Percentage of active users

Normal active users 100%

Active users (calls) 70%

Active users (internet) 30%

Attacking active users 0%

4.2.2 Network components of interest

The table below lists the components that should be included in the network infra-structure used for the experiment:

Component Role in the attack

MSC\HLR -

SGSN -

GGSN -

The column “Role in the attack” is empty since in this scenario we do not have an attack.

4.2.3 Required data traces

The data listed below should be collected during the experiment:

Aggregated statistics for each component’s CPU and memory utilization and load

in time (time series)

Each component’s throughput for every type of signalling message (the number

of signalling requests per second that where successfully processed) in time

(time series)

For each component the number of dropped incoming requests, if any (time se-

ries)

The overall rate of incoming & outgoing signalling requests for each component

The rate of incoming & outgoing signalling messages for each component, per

signalling message type

The incoming & outgoing traffic for each component (pcap files)

The incoming & outgoing traffic for each user (pcap files) collected from both the

mobile devices and from the NITB (for messages that allow their attribution to a

particular mobile device)

The overall rate of outgoing signalling requests for each end-user

The rate of outgoing signalling requests for each end-user per signalling message

type

The following details for the network architecture and the configuration of the com-ponents should also be provided:

Details of the experiments (e.g. number of malicious and non-malicious devices,

etc.)

Specifications of all components used in the experiment


October 2014 16

4.2.4 Notes

1. We assume that each user corresponds to one mobile device.

2. The exact duration of each experiment instance needs to be determined, so as

the network reaches a stable condition (e.g., until a stable tps is reached, until a

component ceases to respond, etc.).

3. Apart from the “components of interest”, it is possible that other intermediate

components will be required for each experiment. In such case, traces from these

components are welcome but not necessary (unless indicated otherwise).

4.3 Experiment 2: CFU flood from one base station


This experiment aims to quantify the impact of control-plane flooding attacks on normal traffic and network components. The attacker infects a number of mobile devices which he can fully control. He coordinates an attack which exploits the in-sert/delete call forwarding signalling requests [16]. By identifying the number of re-quests needed to degrade the HLR’s throughput beyond a certain point, we aim to realistically estimate the number of infected devices that an adversary would require to cause problems in the network (e.g., DDoS) [13]. The total number of active users should be equal to the maximum number of users that can use the network simulta-neously, for the OsmoBTS base station.

The distribution of users in this experiment is defined in the following table:

Parameter Percentage of active users or value





Signalling requests per second per attacker 1/4.7 req/sec

Note that the parameters are expressed as either a percentage or a rate. Also note that the rate of one signaling request every 4.7 seconds for each attacker is the maximum rate for the successful transition of signaling commands [13].




MSC\HLR Attacked component

SGSN Intermediate component

GGSN Intermediate component


The data required from this experiment is the same as defined in Sec. 4.2.3.


October 2014 17

4.3.4 Notes

The additional considerations for this experiment are as defined in Sec. 4.2.4.

4.4 Experiment 3: CFU flood from a compromised femtocell


This experiment aims to quantify the impact of control-plane flood attacks on normal traffic and network components. We assume that the attacker uses a compromised femtocell, but in reality we use a normal base station to represent the compromised femtocell in this experiment. The attacker launches an attack which exploits the in-sert/delete call forwarding signalling requests. In this case all the users that are reg-istered to the femtocell participate in the attack. The total number of active users should be equal to the maximum number of users that can use the network simulta-neously, for the OsmoBTS base station.

















4.4.4 Notes


4.5 Experiment 4: CFU flood from a botnet


This experiment aims to quantify the impact of control-plane flood attacks on normal traffic and network components. The attacker uses a botnet comprised of infected


October 2014 18

devices to launch a DDoS attack against the HLR. This DDoS attack exploits the in-sert/delete call forwarding signalling requests to overload the core network.

It should be noted that in this experiment, the mobile malware detector (developed by HIS) is installed in all the mobile devices which are infected with the correspond-ing malware. The mobile malware detector will monitor the devices for suspicious activity and finally identify the botnet.

The total number of active users should be equal to the maximum number of users that can use the network simultaneously, for the OsmoBTS base station.

















4.5.4 Notes


4.6 Experiment 5: Authentication based DoS attack


Several attacks that exploit the authentication and key agreement (AKA) procedure to cause increased load in the HLR/AuC/HSS have been proposed. All these attacks take advantage of the fact that the generation of the Authentication Vectors (AV) by the AuC is a procedure that consumes significant computational resources. Hence, they find different ways to generate numerous IMSI attach requests (or other re-quests that result in the initiation of an AKA). Please note that in this experiment, we prefer the caching of multiple AVs in the MSC/SGSN to be disabled in order to im-prove the effectiveness of the DoS attack with the limited resources available to us in the test-bed [14][15].


October 2014 19












HLR Sends requests to the AuC

AuC Attacked component

MSC/SGSN Intermediate component

RNC Intermediate component



4.6.4 Notes


4.7 Experiment 6: PDP context activation/deactivation based DoS at-tack


In mobile networks, each user is associated one or more PDP contexts for data traf-fic, which are activated and deactivated as necessary by the network depending on the network configuration and the data activity of the user. In this experiment, we consider a malware or otherwise malicious user that exploits the PDP context activa-tion and deactivation procedure in order to load the SGSN and the GGSN. One of the objectives of this experiment is to observe how the number of simultaneously active PDP contexts per user affects the growth of the load on the core network compo-nents.


October 2014 20







Number of simultaneously active PDP con-texts per user

1 to max (as defined by operator)

PDP context configuration PDP context related configuration similar to those used in commercial networks




SGSN Attacked component

GGSN Attacked component


In addition to the data as defined in Sec. 4.2.3, we require the following information from this experiment:

The number of PDP-context activation/deactivation messages in time (time se-

ries)

The configuration of the PDP context related components in the network

4.7.4 Notes


5 Conclusions and Future Work

The NEMESYS project is developing a suite of security tools to protect both mobile users and the mobile network against malware and other security threats. The vali-dation and evaluation of these tools is performed in WP7 and involves experiments in a realistic mobile network test-bed and simulation studies. This document pre-sents the NEMESYS networking test-bed, which is based on open source software and hardware and provides the basic functionalities of an operational mobile net-work. We have described a set of experiments to be conducted on this test-bed, which will provide us with realistic data traces collected from real network compo-nents and enable us to analyse the impact of control-plane attacks on the network. One of the expected outcomes from these experiments is the identification of physi-cal limitations that may throttle such DoS attacks, such as limitations due to the wireless medium and battery life. We will report on the outcomes of the described experiments in D7.2.2. We expect that the data collected from these experiments, together with the data collected from other NEMESYS components such as the hon-eyclient and the honeypot, will provide useful insights into the different threats and


October 2014 21

attacks that mobile users and networks face today and will face in the future. We will also employ the results of these experiments in order to further develop accurate simulation models and to select the appropriate parameters in our simulation stud-ies as part of WP7.


October 2014 22

6 References

1. NEMESYS Project, Deliverable D1.1 “State-of-the-Art for security threats and at-tacks against mobile devices & analysis of current practices”.

2. NEMESYS Project, Deliverable 1.2, “Use case analysis and user scenarios”.

3. NEMESYS Project, Deliverable 2.3, “Lightweight Malware Detector”.

4. Fortinet, 2014 Threat Landscape Report, http://www.fortinet.com/sites/default/files/whitepapers/Threat-Landscape-2014.pdf

5. Kaspersky Lab, IT Threat Evolution Q2 2014, https://securelist.com/files/2014/08/KL_Q2_IT_Threat_evolution_EN.pdf

6. OTT service blackouts trigger signaling overload in mobile networks, https://blog.networks.nokia.com/mobile-networks/2013/09/16/ott-service-blackouts-trigger-signalling-overload-in-mobile-networks/

7. NSN Smart Labs, reported in ITWire (14 June 2011):

8. Angry Birds + Android + ads = network overload, http://www.itwire.com/business-it-news/networking/47823-angry-birds-android-ads-network-overload

9. Understanding Smartphone Behaviour in the Network, http://www.nokiasiemensnetworks.com/sites/default/files/document/Smart_Lab_WhitePaper_27012011_low-res.pdf

10. Huawei white paper (05 July 2012): “Analyzing the Network Friendliness of Mo-bile Appli-cations”, www.huawei.com/ilink/en/download/HW_146595

11. DoCoMo demands Google's help with signalling storm, http://www.rethink-wireless.com/2012/01/30/docomo-demands-googles-signalling-storm.htm

12. NEMESYS Project, Deliverable D4.1, “Anomaly detection based on signaling pro-tocols”.

13. Traynor, P., Lin, M., Ongtang, M., Rao, V., Jaeger, T., McDaniel, P., & La Porta, T. (2009, November). On cellular botnets: measuring the impact of malicious devic-es on a cellular network core. In Proceedings of the 16th ACM conference on Computer and communications security (pp. 223-234). ACM.

14. Kambourakis, Georgios, et al. "DoS attacks exploiting signaling in UMTS and IMS." Computer Communications 34.3 (2011): 226-235.

15. Xenakis, Christos, and Christoforos Ntantogian. "An advanced persistent threat in 3G networks: Attacking the home network from roaming networks."Computers & Security 40 (2014): 84-94.

16. European Telecommunications Standards Institute (ETSI), “ETSI TS 100 543: Digi-tal cellular telecommunications system (Phase 2+); Call Forwarding (CF) supple-mentary services”, 1997


October 2014 23

Annex I - Sample configuration OsmoBTS file

In this file the assumption is that the BTS runs on the same host as the core network

hence the 127.0.0.1 address is used. The “trx 0” entry refers to OsmoTRX software

instance.

bts 0

band DCS1800

ipa unit-id 1801 0

oml remote-ip 127.0.0.1

rtp bind-ip 127.0.0.1

rtp jitter-buffer 0

paging lifetime 0

gsmtap-sapi bcch

gsmtap-sapi ccch

gsmtap-sapi rach

gsmtap-sapi agch

gsmtap-sapi pch

gsmtap-sapi sdcch

gsmtap-sapi pacch

gsmtap-sapi pdtch

gsmtap-sapi sacch

fn-advance 20

ms-power-loop -10

timing-advance-loop

trx 0

rxgain 0

power 0


October 2014 24

Annex II - Sample configuration of an OpenBSC file e1_input

e1_line 0 driver ipa

e1_line 0 port 0

network

network country code 901

mobile network code 70

short name Nemesys

long name Nemesys

auth policy accept-all

location updating reject cause 13

encryption a5 0

neci 1

paging any use tch 0

rrlp mode ms-based

mm info 1

handover 0

handover window rxlev averaging 10

handover window rxqual averaging 1

handover window rxlev neighbor averaging 10

handover power budget interval 6

handover power budget hysteresis 3

handover maximum distance 9999

timer t3101 10

timer t3103 0

timer t3105 0

timer t3107 0

timer t3109 0

timer t3111 0

timer t3113 60

timer t3115 0

timer t3117 0

timer t3119 0

timer t3122 10

timer t3141 0

dtx-used 0

subscriber-keep-in-ram 0

bts 0

type sysmobts

band DCS1800

cell_identity 0

location_area_code 1

training_sequence_code 7

base_station_id_code 63


October 2014 25

ms max power 0

cell reselection hysteresis 4

rxlev access min 0

periodic location update 30

channel allocator descending

rach tx integer 9

rach max transmission 7

channel-descrption attach 1

channel-descrption bs-pa-mfrms 5

channel-descrption bs-ag-blks-res 1

ip.access unit_id 1801 0

oml ip.access stream_id 255 line 0

neighbor-list mode automatic

trx 0

rf_locked 0

arfcn 871

nominal power 0

max_power_red 0

rsl e1 tei 0

timeslot 0

phys_chan_config CCCH+SDCCH4

hopping enabled 0

timeslot 1

phys_chan_config TCH/F

hopping enabled 0

timeslot 2


hopping enabled 0

timeslot 3


hopping enabled 0

timeslot 4


hopping enabled 0

timeslot 5


hopping enabled 0

timeslot 6


hopping enabled 0

timeslot 7


hopping enabled 0

project title: enhanced network security for … network security for seamless service ... the...

Documents