IN DEGREE PROJECT ELECTRICAL ENGINEERING,SECOND CYCLE, 30 CREDITS

, STOCKHOLM SWEDEN 2016

A reverse proxy for VoIPOr how to improve security in a ToIP network

GUILLAUME DHAINAUT

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF ELECTRICAL ENGINEERING

KTH Royal Institute of TechnologyMaster’s Programme in Network Services and Systems - ANSSI

Guillaume Dhainaut921006-5950dhainaut@kth.se

A reverse proxy for VoIPOr how to improve security in a ToIP network

Master’s ThesisStockholm, February 24, 2016

Supervisors Pierre Lorinquer ANSSIFabien Allard ANSSI

Examiner Panagiotis Papadimitratos (papadim@kth.se) KTH

Abstract

The need for security is crucial in Telephony over IP (ToIP). Secure protocols havebeen designed as well as specific devices to fulfill that need. This master thesis examinesone of such devices called Session Border Controller (SBC), which can be compared toreverse proxies for ToIP. The idea is to apply message filters to increase security.

This thesis presents the reasons of SBC existence, based on the security weaknessesa ToIP network can show. These reasons are then used to establish a list of featureswhich can be expected from a SBC and discuss its ideal placement in a ToIP networkarchitecture. A test methodology for SBCs is established and used on the free softwareKamailio as an illustration. Following this test, improvements of this software, regardingthreats prevention and attacks detection, are presented and implemented.

Sammanfattning

Behovet av säkerhet är av avgörande betydelse i telefoni över IP (ToIP). Säkerhet-sprotokoll har utformats samt särskilda enheter för att uppfylla detta behov. Dettaexamensarbete undersöker en av sådana enheter som kallas Session Border Controller(SBC), vilket kan jämföras med omvända proxyservrar för ToIP. Tanken är att tillämpameddelandefilter för att öka säkerheten.

Denna avhandling presenterar orsakerna till SBC existens, baserat på de säkerhetssvagheter en ToIP nätverk kan visa. Dessa skäl används sedan för att upprätta en förteck-ning över egenskaper som kan förväntas av en SBC och diskutera dess ideal placering ien ToIP nätverksarkitektur . En testmetodik för SBC är etablerad och används på friprogramvara Kamailio som en illustration. Efter detta test, förbättringar av denna pro-gramvara, om hot förebyggande och attacker upptäcka, presenteras och genomförs.

i

Acknowledgements

This research was supported by ANSSI (French Network and Information Security Agency)in Paris. They offered me helps and materials. I owe my gratitude to Pierre Loriquer andFabien Allard which were my ANSSI supervisors and helped me throughout this thesisby giving me advice and idea.I would also like to thank Colin Chaigneau and Valentin Houchouas, my colleagues atANSSI, for their helps in areas of which they were experts.I am thankful to Panagiotis Papadimitratos, my supervisor at KTH, for his helpful adviceabout the report.Finally I thank Alice Tourtier for her help and support.

ii

Contents

1 Introduction 11.1 Goal of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 VoIP Technologies 32.1 SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.2 Elements of a SIP call establishment . . . . . . . . . . . . . . . . . 62.1.3 Exchange examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.4 Security Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Media session protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.1 Codecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.2 RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.3 SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.4 RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.5 SDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Other protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.1 VoIP protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.2 Service protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4 Unified Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Security on a ToIP infrastructure 193.1 Security issues in ToIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.1 Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.1.2 Common ToIP attacks . . . . . . . . . . . . . . . . . . . . . . . . . 213.1.3 How to make secure ToIP . . . . . . . . . . . . . . . . . . . . . . . 233.1.4 Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Session Border Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2.1 Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2.2 Differences with existing devices . . . . . . . . . . . . . . . . . . . . 29

4 SBC features 304.1 Internetworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.2 Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3 QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.4.1 Upstream protection . . . . . . . . . . . . . . . . . . . . . . . . . . 324.4.2 Common attack protection . . . . . . . . . . . . . . . . . . . . . . . 344.4.3 Downstream protection . . . . . . . . . . . . . . . . . . . . . . . . . 36

5 SBC Architecture integration 395.1 At the border of ToIP architecture . . . . . . . . . . . . . . . . . . . . . . 39

5.1.1 Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.1.2 Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2 At the Center of ToIP architecture . . . . . . . . . . . . . . . . . . . . . . 40

iii

5.2.1 Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.2.2 Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.3 Combination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6 SBC Security Test 426.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.1.1 Test environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.1.2 Features announced . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.1.3 Fuzzing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.1.4 Dos/Flood . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.1.5 TLS quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.1.6 Common SIP attacks . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.2 Test of Kamailio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.2.1 Test environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.2.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7 Improvements 527.1 Permissions module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.1.1 Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527.1.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.2 CDR analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.2.1 Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.2.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567.2.3 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

8 Conclusion and future work 608.1 Accomplished work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608.2 SBC conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

A Loop amplification Attack 66

B Kamailio configuration files 67

C Asterisk configuration files 70

iv

List of Figures

1 ITU-T protocol set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 VoIP IETF protocol set . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Example of a SIP INVITE message . . . . . . . . . . . . . . . . . . . . . . 54 SIP Registration process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 SIP Call process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 SIP Digest authentication example . . . . . . . . . . . . . . . . . . . . . . 107 RTP header as defined in RFC 3550 [1] . . . . . . . . . . . . . . . . . . . . 138 Example of a SDP description . . . . . . . . . . . . . . . . . . . . . . . . . 159 Example of DoS attack with INVITE messages . . . . . . . . . . . . . . . 2210 Security measures at the network level . . . . . . . . . . . . . . . . . . . . 2511 Example of SBC placement . . . . . . . . . . . . . . . . . . . . . . . . . . 2812 Use of a B2BUA to transcode audio flow . . . . . . . . . . . . . . . . . . . 2813 SBC action to allow high frequency registration . . . . . . . . . . . . . . . 3314 Internal architecture with a SBC at the border of the ToIP network . . . . 3915 VoIP flows with a SBC at the center . . . . . . . . . . . . . . . . . . . . . 4016 Internal architecture with two SBCs at the border and at the center of the

ToIP network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4117 Test environment of Kamailio . . . . . . . . . . . . . . . . . . . . . . . . . 4718 CPU and RAM usages versus message intensity during DoS attacks . . . . 4919 Learning period in time . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5520 Example of a user profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5721 Call hour distribution for a user . . . . . . . . . . . . . . . . . . . . . . . . 5822 Receiver Operating Characteristic for the call classifier . . . . . . . . . . . 5923 REGISTER messages of a loop amplification attack . . . . . . . . . . . . . 6624 Example of the flow of a SIP amplification attack from RFC 5393 [2] . . . 66

v

List of Tables

1 Main SIP request methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Main SIP response codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Main audio codecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Codecs understood by some SIP systems . . . . . . . . . . . . . . . . . . . 315 Overview of the security features . . . . . . . . . . . . . . . . . . . . . . . 436 Security features implemented in Kamailio . . . . . . . . . . . . . . . . . . 487 Kamailio DoS results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498 FPR and TPR results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

vi

Abbreviations and Acronyms

ANSSI French Network and Information Security AgencyB2BUA Back-to-Back User AgentCA Certificate AuthorityCAC Call Admission ControlCDR Call Detail RecordCoS Class of ServiceCPE Customer Premises EquipmentCPU Central Processing UnitCVE Common Vulnerabilities and ExposuresDHCP Dynamic Host Configuration ProtocolDNS Domain Name SystemDoS Denial of ServiceDDoS Distributed DoSDTLS Datagram Transport Layer SecurityDTMF Dual-Tone Multi-FrequencyERP Enterprise Resource PlanningFPR False Positive RatioFTP File Transfert ProtocolHTTP Hypertext Transfer ProtocolHTTPS HTTP SecureIAX Inter-Asterisk eXchangeICE Interactive Connectivity EstablishmentIETF Internet Engineering Task ForceIP Internet ProtocolIPBX Internet PBXIPsec Internet Protocol SecurityISDN Integrated Services Digital NetworkISUP Integrated Services Digital Network User PartITU International Telecommunication UnionITU-T ITU Telecommunication Standardization SectorLACK Lost Audio Packets SteganographyLAN Local Area NetworkLSB Least Significant BitMAC Media Access ControlMITM Man in the middleMIKEY Multimedia Internet KEYingMTU Maximum Transmission UnitNAT Network Address TranslatorNTP Network Time ProtocolOS Operating SystemPBX Private Branch ExchangePC Personal ComputerPKI Public Key InfrastructurePSTN Public Switched Telephone NetworkQoS Quality of Service

vii

RAM Random Access MemoryRFC Request for CommentsROC Receiver Operating CharacteristicRTCP RTP Control ProtocolRTD Round-Trip DelayRTP Real-time Transport ProtocolS/MIME Secure/Multipurpose Internet Mail ExtensionsSBC Session Border ControllerSDES SDP Security Description for Media StreamsSDP Session Description ProtocolSIP Session Initiation ProtocolSIPREC SIP RecordingSIPS SIP SecureSPIT Spam over Internet TelephonySRC Session Recording ClientSRS Session Recording ServerSRTP Secure Real-time Transport ProtocolSS7 Signalling System No. 7SSL Secure Sockets LayerSTUN Simple Traversal of UDP through NATTCP Transmission Control ProtocolTFTP Trivial FTPTLS Transport Layer SecurityToIP Telephony over IPTPR True Positive RatioTURN Traversal Using Relay NATUA User AgentUAC User Agent ClientUAS User Agent ServerUDP User Datagram ProtocolURI Uniform Resource IdentifierVLAN Virtual LANVM Virtual MachineVoIP Voice over IP

viii

1 Introduction

The concept of Voice over IP (VoIP) appeared in the early 90s. At that time, theInternet was emerging and people proposed the idea to make the phone calls pass throughthe Internet network. To do so, they could not reuse the old telephone systems but theyhad to develop new protocols to make the calls on top of the TCP/IP networks. We had towait until the end of the 90s to see instantiations of such protocols produced by IETF andITU-T, respectively SIP and H.323. Nowadays, the general public is used to proprietarysoftware such as Skype which is the incontestable leader with its 300 million users [3].Telephony over IP (ToIP) represents the whole system which use VoIP, including IPBXand phones.

Passing from the old Public Switched Telephone Network (PSTN) to ToIP bringsseveral benefits. First, it helps reducing the cost of each call, both for international callsand local calls. Then, the convergence of the telephony network and computer networkbrings other features such as video, data transfer or messaging, that can be used from anyconnected device like computers and smartphones. The adoption of this technology bythe market has been quite fast. For example, the penetration among US businesses haspassed from 12% in 2004 to 79% in 2013 [4]. Some experts predict that the VoIP marketwill continue to grow to reach $82.5 billion services revenue in 2018, against $69.6 billionin 2014 [5].

This evolution of telephony has also increased the crucial need for security. ToIPinherits the security issues of IP based systems in addition to its own vulnerabilities.Contrary to the old PSTN system, physical interaction is not needed anymore to attacka system and anyone connected to the Internet can exploit a vulnerability of the network,from spying, to spoofing and toll frauds. At the early days of ToIP, most companiesneglected security in their infrastructure because they were not aware of the risks involved.A report produced by the consultancy company Nettitude [6] shows that attacking a ToIPsystem is very attractive because of the money attackers can make (with toll fraud forexample). Nevertheless, with the increasing number of attacks, companies started tosecure their infrastructure, for example using secure versions of the protocols.

1.1 Goal of the thesis

This thesis will look at the security aspects of a ToIP network architecture inside acompany and specifically examine the security brought by the Session Border Controllers(SBCs). The main goals of this thesis are:

• To provide a state of the art of the security features offered by the SBC imple-mentations and to compare them to threats internal or external to an IP telephonyinfrastructure,

• To develop a method for SBC testing and experiment it on a free solution,

• To propose changes in existing solutions and implement some, as time permits.

Even if a focus will be given on security in this thesis, the other functions a SBC canprovide will also be briefly presented to cover all the aspects of a SBC. The objective isto give the readers an overview of the features that may be offered by a SBC. Indeed,

1

knowing what a SBC can actually do on a ToIP network will help to understand thecritical aspect of this new element.

1.2 Contribution

This thesis work explains why a SBC is needed inside a ToIP network. The securityprovided by the SBC is analyzed in regards of the threats and new SBC features arepresented. This thesis also gives a security test methodology for SBC and applies itto Kamailio [7] which is one of the most used SIP servers. This thesis also presentsimprovements on Kamailio to prevent toll fraud.

1.3 Outline

The thesis is organized and structured linearly. First, in Section 2, it will be describedhow ToIP actually works and give the necessary knowledge to understand the rest of thethesis. Then, in Section 3, the security issues a ToIP architecture might encounter willbe introduced by describing the risk associated along with the common attacks. Thispresentation will bring us to the introduction of the SBC inside our network. After,Section 4 will present the features we can expect from it and how it will improve ourwhole system, based on the problems shown before. The question of its integration inour infrastructure remains and we will reflect on it in the following Section 5. In Section6 a SBC test methodology will be created and used on the open-source SBC Kamailio.Finally in Section 7, some implementations of new features for SBCs will be presentedwith a permissions module and a program to detect suspicious calls.

2

2 VoIP Technologies

Some background knowledge about VoIP and security is necessary. In this section, theprotocols that are commonly used in VoIP will be presented. A VoIP ecosystem needs twoparts: the signaling part to establish the call between two users, and the media transportpart to carry the data from one user to the other once the session has been established.There are two sets of protocols mainly used today: the ITU-T set shown in Figure 1 andthe IETF set shown in Figure 2. Both use the same protocol for the media transport butthey differ on the signaling protocol used.

The ITU-T set is called H.323 and is composed of several different protocols for thesignaling part (H.225, H.245 and T.120). A large part of it comes from the protocol H.320,used in Integrated Services Digital Network (ISDN) which comes from the traditionaltelephony world. It made the transition easier and it explains why H.323 was the mainprotocol used in the early 2000’s. H.323 is a binary protocol and is complex by nature.

IP

TCP UDP

H.225(Q.931) H.245 T.120

Control Data

RTP/SRTP

RTCP

AudioVideo

Media

H.225(RAS)

Control

Figure 1: ITU-T protocol set

The IETF is inspired by the Internet protocols and is text-based. It is composed of theSession Initiation Protocol as a signaling protocol and the Real-Time Transport Protocol(RTP) as a media protocol. SIP is media agnostic, it can be used to establish any type ofsession whereas H.323 is restricted to voice and video and cannot be used to support thenew requirement of companies. SIP has become the main protocol used and almost allthe new VoIP architectures are made using the IETF set, whereas the number of H.323deployment is decreasing [8]. Consequently, this thesis will focus on the IETF set.

3

IP

UDP UDP/TCP

TLS

SIP

SDP

Signaling

RTP/SRTP

AudioVideo

RTCP

Media

Figure 2: VoIP IETF protocol set

SIP operates at the application layer and is agnostic of the transport layer used tocarry it. It can be used with UDP, TCP or TLS with no change in the messages. VoIPcommunications need very low delays to be close to real time and, at the beginning,most implementations used UDP to carry SIP. However, the improvement of the Internetconnection quality and the use of VoIP in mobile environments changed this habit andnow a lot of implementations use TCP to transport SIP messages whereas media messagesare still carried over UDP. During the first messages, the Session Description Protocol(SDP) is used inside SIP for exchanging the media parameters that will be used for theRTP session. When the session is established between the users with SIP, another setof protocols is used for the media part. The media flow is carried over RTP. RTP is aprotocol on top of UDP for real time transfer that provides helps for jitter compensation,packet loss and detection of out of sequence arrival. RTP is used in combination withRTCP which provides statistics and control information for the associated RTP session.

2.1 SIP

SIP is a signaling, presence and instant messaging protocol developed to set up, modify,and tear down multimedia sessions between two or more users. It is an open standardthat was defined in the RFC 3261 [9] and updated since by several other RFCs. It isa text-based protocol (in contrast to binary protocols), meaning that all the messagesexchanged are in text and that makes it really easier to read and understand. It reusesmany elements of the Hypertext Transfer Protocol (HTTP) and the Simple Mail TransferProtocol (SMTP). Indeed, like for HTTP, the messages can be classified into request andresponse messages. It also uses Uniform Resource Identifiers (URIs) to identify resourcesas SMTP. sip:guillaume@dhainaut.fr is an example of such URI.

2.1.1 Messages

The SIP messages include request messages and response messages. The first line ofa SIP request includes the name of the method that identifies the request and the firstline of the response message includes a number called response code. The main requestmethods are shown in Table 1 and the classes of response code are shown in Table 2.

4

SIP message DescriptionINVITE Used to establish media sessions between user agentsREGISTER Used to notify a SIP network of its current contact URI (IP address)BYE Used to terminate an established media sessionACK Used to acknowledge final responses to INVITE requestsCANCEL Used to terminate pending INVITE or call attemptOPTIONS Used to query a system about its capabilities

Table 1: Main SIP request methods

Code Description Action1xx Informational Indicates the status of the call prior to completion2xx Success The request has succeeded. The original sender must send an

ACK if it was for an INVITE3xx Redirection The client should retry the request to another server given in

the response4xx Client error Request has failed due to the client. It must retry with a

correct message following indications in the response5xx Server failure Request has failed due to the server. Client may try another

server6xx Global failure Request has failed. Client should not try again with this server

or any other

Table 2: Main SIP response codes

A full SIP message is shown below in Figure 3. It is first composed of a line withthe method or the response code, the user’s URI and the version of SIP. This first line isfollowed by several header fields and a body.

INVITE sip:usera@voip.com SIP/2.0Via: SIP/2.0/UDP 67.152.23.12:5060;branch=z9hG4bK8c4bMax-Forwards: 70From: "Bob" <sip:userb@test.com>;tag=7f795d7fe1To: <sip:usera@voip.com;user=phone>Call-ID: 50e333b9f136bf53CSeq: 25349 INVITEContact: "Bob" <sip:userb@67.152.23.12:5060;transport=udp>User-Agent: Ekiga/4.0.1Content-Type: application/sdpContent-Length: 618

(SDP not shown)

Figure 3: Example of a SIP INVITE message

Some header fields are mandatory (To, From, CSeq, Call-ID, Max-Forwards and Via)while the others are optional, even though they can be very useful. The main ones are:

5

• Via: Records the SIP route taken by a request and is used to route a response backto the originator

• To: Indicates the recipient of the request

• From: Indicates the originator of the request

• Max-Forwards: Indicates the maximum number of hops a SIP request may gothrough

• Call-ID: Must be unique and identifies a call between two users

• CSeq: Contains a decimal number that increases for each request

• Contact: Conveys a URI to identify the resource requested or the request originator

• User-Agent: Conveys information about the system originating the request

• Content-Type: Indicates the Internet media type in the message body

• Content-Length: Indicates the number of octets in the message body

There are more than 110 different SIP header fields defined in RFCs [10]. Anyone candefine a new SIP header if it is useful for his system and some headers have been createdby the main vendors to provide new features. However, the main problem with customheaders is the lack of interoperability between systems from different vendors.

2.1.2 Elements of a SIP call establishment

In this section the behavior of standard SIP elements and their role in a ToIP networkis examined.

User Agent

SIP-enabled end devices are called user agents (UAs). They can be separated into twocategories:

• A User Agent Client (UAC) is a logical entity that sends SIP requests

• A User Agent Server (UAS) is a logical entity that receives the requests and returnsSIP responses

Most SIP implementations behave as both client and server. They can send messages toestablish a call and at the same time they listen for any incoming call.

SIP Phones

SIP Phones are the very end points of calls. Their main tasks are to make calls andto receive calls. They can run on computer like Linphone, Ekiga or Skype (such softwareare called softphones), or separate IP phones with dedicated hardware like Cisco phones,Avaya phones or Mitel phones.

6

SIP Gateways

A SIP gateway is an application that interfaces a SIP network to a network usinganother signaling protocol such as the public switched telephone network (PSTN) or anetwork running with H.323. A gateway terminates the signaling path and can alsoterminate the media path. It can sometimes be decomposed into a media gateway (MG)for the media part and a media gateway controller (MGG) for the signaling part.

Proxy Servers

A SIP Proxy Server receives SIP requests from a user agent or another proxy andtransmits them. Just as a router forwards IP packets at the IP layer, a SIP proxy for-wards SIP messages at the application layer. A proxy is only allowed to modify messagesfollowing the limitations of the RFC 3261. A proxy server can also extend the securityby doing authentication (details in Section 2.1.4). Kamailio [7] is one of the most knownfree SIP proxy.

Registrar Servers

A Registrar Server accepts REGISTER requests from clients. When it receives amessage, it updates the location database to make the contact information from therequest available to the other SIP servers of the domains. A registration server usuallyrequires the authentication of the client sending the REGISTER.

Redirect Server

A Redirect Server responds but does not forward the request. It uses a database tolookup users and sends a 3xx response directing the client to contact another URI toreach the user.

Back-to-Back User Agent (B2BUA)

A Back-to-Back User Agent receives SIP requests, rewrites them and sends them outas new requests. Some B2BUAs behave like proxies but do not follow the same rulesas they can rewrite the From, Via, Contact and Call-ID headers. They divide the callinto two call legs so they can manage each side of the call. Since all flows pass througha B2BUA, it is aware of the state of every call and can perform call control to addnew features like voice messaging for example. The most famous free implementation ofB2BUA server is Asterisk [11] and it is used by more than one million communicationsystems [11]. FreeSWITCH [12] is another famous free implementation. In addition, theycan both act as an IPBX and a media gateway, and thus manage the entire ToIP of acompany.

7

2.1.3 Exchange examples

Now that the foundations of SIP have been described, as well as the elements of thenetwork and the messages exchanged, two important examples of SIP exchanges can bedescribed: the registration and the establishment of a call.

Registration

Figure 4 shows the registration process. The UAC sends a REGISTER message to theregistrar which responds with a 200 OK message. Each UAC has to register itself to aregistrar if it wants to receive calls. With this information, the SIP proxy can redirect thecall to the right IP address. If the UAC does not do it, when the SIP proxy will receivea call for it, the proxy will not be able to transmit the call. The registrar might ask theUAC to authenticate itself.

Alice Registrar

REGISTER

200 OK

Figure 4: SIP Registration process

Call Establishment

Figure 5 shows a call between Bob and Alice. She wants to call Bob who is registeredto another domain. First, she sends an INVITE message to her SIP proxy which willtransmit it to the proxy of Bob’s domain. After transmitting it, the SIP Proxy sendsa 100 Trying message to Alice to make her know that her message has been processed.When the second SIP Proxy receives the INVITE, it knows where to find Bob (becauseBob registered himself before) and transmits the INVITE to Bob. As for the first proxy,the second proxy responds with a 100 Trying message. Bob’s phone receives the INVITEand starts to ring. It sends a 180 Ringing message that will be transmitted back to Alice.When Bob picks up his phone, it sends a 200 OK response that will be again transmittedto Alice. She receives the 200 OK and sends in response an ACK to Bob through theproxies.

At this time the session is established, each machine of the user knows the IP address ofthe other. Thus, they can start to send audio or video between them with RTP protocol.When one wants to end the call by hanging up the phone, it sends a BYE message to theother that will respond with a 200 OK message to make the BYE originator knows thatthe message has been well received (with UDP the message might be lost). The processcan be much more complex in a production environment because of all the other elementson the way.

8

Alice calls

Alice SIP Proxy SIP Proxy Bob

INVITEINVITE

INVITE100 Trying100 Trying

180 Ringing180 Ringing

180 Ringing

Bob answers

200 OK200 OK

200 OK

ACKACK

ACK

Media Session (RTP)

BYE

200 OK

Figure 5: SIP Call process

2.1.4 Security Mechanisms

The telephony architecture in a company is a critical element that has to satisfy thefundamental concepts of security. SIP comes with some mechanisms to provide authenti-cation, confidentiality and integrity that have been defined since the RFC 3261 [9].

Authentication

Three methods have been described to provide authentication for SIP:

• Digest authentication: It is based on HTTP digest mode [9]. A SIP server or UAcan challenge another UA to resend a request proving knowledge of a shared secret,which is used to compute a MD5 hash of several parameters (from, to, method,nonce, realm) that will be send in a new message. An example of transaction isshown Figure 6 with a registration. The UAC sends a message, the UAS respondswith a 401 Unauthorized message or with a 407 Authentication Required messagewhich contains a nonce (to prevent replay attacks) and a realm (to identify thesystem being accessed) that will be used to compute the MD5 hash. The newmessage will be the same with a response header field containing the parametersand the hash. If the hash is correct the request will be processed by the UAS.This method only provides a way for the server to authenticate the client, not theopposite. The HTTP digest authentication is considered as weak and vulnerable[13] and some propositions of improvement have been made [14]. One should avoidto base his entire authentication system on it and use one of the other mechanismsbelow in addition.

9

• TLS client authentication: SIP can be used on top of TLS to employ the au-thentication process of TLS. If the X.509 server certificate is signed by a certificateauthority recognized by the client, the certificate can be used to authenticate thepublic key of the server and later to authenticate the server within the TLS hand-shake. The server can also request a client certificate for mutual authentication.However it is rare that the clients also have a certificate so the server can use thedigest authentication presented above once the TLS session has been established.

• Identity: Proposed in the RFC 4474 [15]. A new SIP header field, Identity, isinserted by a proxy server when forwarding a request. The proxy first authenticatesthe request to make sure it is being sent by the identity in the from header field. Ifso, some parts of the request are signed and the signature is included in the Identityheader field. An Identity-Info header field indicates the link to the certificate usedto sign the message. When a UA or a proxy receives a request it can get and checkthe certificate following the link in the Identity-Info and check the signature in theIdentity. If the signature is correct, the From URI is authenticated. As for TLS,Identity needs a PKI for the certificate management.

Alice Registrar

REGISTER

401 Unauthorized

REGISTER (with MD5 hash)

200 OK

Figure 6: SIP Digest authentication example

Confidentiality and integrity

The SIP messages are rarely sent directly from user to user and pass through interme-diates. These intermediates may want to change the SIP messages to sanitize them forexample. With the use of end to end encryption or entire message signature, messageswill not be alterable anymore by intermediates. As a user is not aware of all the ToIPelements on the path, it is strongly not recommend to use them. SIP provides threecommon ways to provide confidentiality and integrity:

• S/MIME: It permits to encrypt or sign the message body (usually SDP) in a user-to-user way. It was first designed for email sending but it has evolved, and now ithas been adapted for HTTP and SIP. It is based on certificates and thus requiresa Public Key Infrastructure (PKI). The messages are sent with the body encryptedwith the public key of the recipient and signed by the private key of the sender.The key exchange mechanism is described in the section 23.2 of the RFC 3261 [9].Even if S/MIME has been defined in a RFC, no implementation of it is widely

10

used today, probably because it requires the same system as TLS while offering lessadvantages. In addition, it does not protect the SIP headers of the messages anddoes not provide protections against replay attack or messages order modification.

• IPsec: The Encapsulating Security Payloads (ESP) protocol is the component ofIPsec used for confidentiality as the whole packet payload is encrypted. It operatesat the IP layer and provides a secure connection between two hosts. In most cases,IPsec is done directly by the OS or kernel layer: applications are unaware if theyare using IPsec or not. Thus, IPsec is often used to establish a secure canal betweendistant sites. Contrary to S/MIME, the protection is done at the network layer.Thus, all the application data are protected (integrity and confidentiality) and notonly the SIP payload.

• SIP over TLS: As for many other application protocols, it is possible to use TLS toauthenticate and protect the messages from a MITM. It operates between the appli-cation layer and the transport layer and can run on both TCP and UDP transportprotocol (DTLS), but is mainly used over TCP. The validation process of the cer-tificates is described in the RFC 5922 [16]. It provides confidentiality and integrityand works on a hop-by-hop basis. Most implementations use this solution.

2.2 Media session protocols

First, the audio or video flow encoding will be described. Then its transmission over thenetwork will be detailed, as well as the parameters exchange and the transport protocolsinvolved.

2.2.1 Codecs

Before thinking of sending the media flow through the network, a system first has todecide what it actually wants to send. The microphone or camera gives the system adigital signal that is quite large. Telephony works in real time so the signal needs to crossthe network as quickly as possible. To help speed up transmission, mathematical coders-decoders called codecs were built to encode a signal for transmission and then decode itfor viewing. The objective of these codecs is to reduce as much as possible the size ofthe signal while keeping the quality as good as possible with a computational complexitylow. This problematic is major for service providers and cloud companies as they needto satisfy a maximal number of users with the less resources. Thus they finance a lot ofresearch in this area to find better codecs.

With VoIP, the systems have to be sure that the endpoints of their media flow havethe decoders to read it. Before sending the media flow they have to agree on the codec touse. This capacity is given with the SDP protocol (described in Section 2.2.5) during thesignaling part of the call. Today, VoIP phones understand several codecs, to have at leastone in common with the other side, and to be able to choose the best codec dependingon the bandwidth available and the desired quality.

Table 4 shows the main audio codec used with their characteristics. The G.711 codecis very old and is the basic codec for most implementations. Even if two phones are verydifferent, a user can almost be sure that they will both support G.711. With the increase

11

of network transmission, data storage and video calls, several other interesting codecshave been developed. Some are free and can be used by anyone in his applications.

Codec Year BW (kHz) BR (kbps) Sampling(kHz) Patents Comment

G.711 1972 3.3 64 8 Not anymore Reference codecG.722 1988 7 48, 56, 64 7 Not anymore High qualityG.722.1 1999 7 24, 32 16 Royalty-free Lower complexityG.722.2 2003 7 6.60 to 23.85 16 Yes Lower bitrateG.7223.1 1995 3.3 5.3 and 6.3 8 Yes Required in H.323AMR 1999 3.2 4.75 to 12.2 8 Yes Standard speech codec GSM/UMTSG.726 1990 3.3 16, 24, 32, 40 8 Yes Used in international trunksG.729 1995 3.3 8 8 Yes Low bitrateG.719 2008 20 32 to 128 48 Yes High quality, flexible rate selectioniLBC 2004 3.3 13.33, 15.2 8 Open format Part of WebRTC projectOpus 2012 4 to 20 6 to 510 8 to 48 Open format Good quality with low complexity

Table 3: Main audio codecs

2.2.2 RTP

The VoIP system will encode the signal using one of the codec above to obtain thedata it is willing to send to the other party. However, sending it directly over UDP willbe too uncertain as there is no information at all about the packets sent. If there aresome loss or delay, the end user won’t be able to rebuild the flow. This is why VoIP needsan intermediary protocol to carry the media stream. The Real-time Transport Protocol(RTP) defined in the RFC 3550 [1] is a network protocol for delivering audio and videoover the network with facilities for jitter compensation and detection of out of sequencearrival in data. RTP works on top of UDP (and not TCP) because systems can toleratesome loss in the packets in favor of delay.

A RTP packet is composed of a header and a payload to carry the data. The RTPheader is shown in Figure 7. The headers have the following meanings:

• V: The version of the protocol, currently 2

• P: Indicates if there are padding bytes at the end of the RTP packet

• X: Indicates the presence of an extension header

• CC: Contains the number of contributing sources (CSRC) identifiers

• M: Marker for the application level

• PT: Indicates the RTP payload type

• Sequence number: Number to determine packet sequence and detect packet loss

• Timestamp: Indicates the Internet media type in the message body

• SSRC: Identifies the source of the stream, randomly chosen

• CSRC: List of contributing sources for a stream that has been generated frommultiple sources

12

• Extension header: Possibility to add new header fields

V P X CC M PT Sequence number

Timestamp

SSRC identifiers

CSRC identifiers...

Extension header...

0 2 3 4 8 9 16 31

Figure 7: RTP header as defined in RFC 3550 [1]

The encoded media signal is placed into the payload of the RTP packets. The sequencenumber ensures that the packets can be reordered and the timestamp ensures that a lossdoes not perturb the reconstitution of the media stream. The protocol is independentof the media it carries, that means that a new multimedia format can be transportedwith RTP just by defining a new RTP payload type. There is no security at all in RTP,everyone can see the flow and modify it. This is why a new protocol, SRTP, has beenbuilt based on RTP to provide the security services needed.

2.2.3 SRTP

The Secure Real-time Transport Protocol (SRTP) [17] is used to secure the exchangesmade with RTP. The header is in clear but the payload is encrypted. With a key exchangeprotocol, the two parts exchange a key from which will be derived the necessary keys forthe RTP and RTCP sessions. The RFC does not specify a key exchange protocol andseveral have been defined for this use:

• ZRTP (RFC 6189 [18]): A shared secret and the security parameters are exchangedusing Diffie–Hellman key exchange. Then each user has a Short AuthenticationString (SAS) that it can share to the other, orally, to check if they have the sameand no MITM has altered the key establishment. The ZRTP exchange uses thesame port as the RTP traffic that will follow.

• MIKEY (RFC 6189 [19]): This is a key management protocol designed to per-form key exchange and negotiate cryptographic parameters on behalf of multimediaapplications. The MIKEY messages are transported inside the SDP part of thesignaling exchanges, encoded in base64. Thus, it relies on the security of SIP (withTLS or IPsec) to provide security for RTP.

• DTLS-SRTP (RFC 6189 [20]): It used DTLS to exchange keys for the SRTP mediatransport. It is a very secure way to process because it does not rely on the securityof SIP and reuse the TLS protocol. But this requires a PKI contrary to ZRTP.

13

• SDES (RFC 6189 [21]): As for MIKEY, security parameters and keys are sent asan SDP attribute of the initial SIP messages.

Even though several mechanisms exist and have been implemented, SDES is the mostcommon way of doing SRTP today because of its simplicity. However, the security itprovides is based on the one provided for SIP. As the keys are sent in the SDP message,SIP needs to be encrypted and authenticated. This is the weakness of SDES, and thereason why one should prefer DTLS-SRTP for example.

2.2.4 RTCP

The RTP Control Protocol (RTCP) is an associated protocol of RTP. It has beendefined in RFC 3550 [1] and is primarily used to provide feedback on the quality of thedata distribution. Mainly, RTCP aims:

• To monitor the quality of services with information such as the packet counts, packetloss, delay variation or round-trip delay time.

• To carry a persistent transport-level identifier for an RTP source called the canonicalname or CNAME. The SSRC identifiers might change and the CNAME helps tokeep track of each participant. It can be used to associate multiple media streams(for example to synchronize audio and video).

• To keep track of the number of participants by looking at the RTCP packets received.

• To convey minimal session control information, for example participant identifica-tion to be displayed in the user interface.

RTP uses an even port number and RTCP uses the next odd port number. RTCP, asRTP, is independent of the underlying transport protocol. RTCP packets are transmittedperiodically, at a recommended minimum interval of 5 seconds. Several RTCP packetscan be combined in the same UDP datagram. RTCP has several types of messages:

• SR: Sender report for transmission and reception statistics from participants thatare active senders (i.e. who send media to the others)

• RR: Receiver report, for reception statistics from participants that are not activesenders

• SDES: Source description items, including CNAME

• BYE: Indicates end of participation

• APP: Application-specific functions

As RTP, RTCP has a secure version known as Secure RTCP (SRTCP), very similar toSRTP. It provides the same security features to RTCP as the one provided by SRTP toRTP.

14

2.2.5 SDP

To make the recipients know what the phone is sending with RTP, VoIP needs aprotocol to share the media parameters and make the users agree on them. The SessionDescription Protocol (SDP) have been created for that purpose. It has been defined inRFC 4566 [22] and is a format for describing media sessions such as transport addresses,transport protocols, port numbers and media details. It works in conjunction with SIPand is sent in the body of the initial SIP messages. As SDP is just a format for sessiondescription, it can also be transported via SAP, RTSP and HTTP. The SDP part of theSIP message is indicated with the value application/sdp in the header field Content-Type.

The form of each field is structured as <type>=<value>. The RFC insists on the factthat there should be no whitespace on either side of the “=”. A SDP session descriptionincludes the following media information:

• The type of media (video, audio...)

• The transport protocol (RTP/UDP/IP, H.320...)

• The format of the media (H.264 video, G.722 audio...)

• The remote address for media

• The remote transport port for media

A SDP description is shown below in Figure 8. It can be split into three parts: thesession description, the time description and the media description.

v=0o=MxSIP 0 1 IN IP4 192.168.51.38s=SIP Callc=IN IP4 192.168.51.38t=0 0m=audio 3000 RTP/AVP 0a=rtpmap:0 PCMU/8000a=rtpmap:18 G729/8000a=rtpmap:110 PCMU/16000a=rtpmap:111 PCMA/16000

Figure 8: Example of a SDP description

The SDP description is part of a SIP INVITE message to establish a call between twosoftphones. The meaning of the different types shown in the SDP message are:

• v: Protocol version number, currently 0

• o: Originator and session identifier. The format is:

<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>

• s: Session name

15

• c: Connection information for the media. The format is:

<nettype> <addrtype> <connection-address>

In figure 8, IN represents the Internet, IP4 means that the address used is an IPv4address and 192.168.51.38 is the IP address the receiver has to send the media flow.

• t: Time the session is active. The format is <start-time> <stop-time>. 0 in bothmeans that the session hasn’t started yet.

• m: Media name and transport address. The format is <media> <port> <proto> <fmt>.

• a: Media attributes line. The example is composed of the audio codecs proposedwith their characteristics.

SIP has two different ways of sending the SDP and making the two sides agree on theparameters the call will use:

• Early offer: In the first way, the call originator makes the first offer and the callrecipient chooses the parameters. The first INVITE contains the SDP offer and thecalled party chooses and responds in the following 200 OK message.

• Late offer: In the second way, the call recipient makes the first offer and the calloriginator chooses the parameters. The first INVITE contains no SDP part and thecalled party will make the offer in the 200 OK message. Then the calling party willchoose and respond in the following ACK.

2.3 Other protocols

The protocols presented before are not the only ones crossing through a ToIP network.First, there are some other VoIP protocols that systems can use. Then, the IP phonesoften offer services, like directories, using non VoIP protocols.

2.3.1 VoIP protocols

Some other protocols have been created for VoIP, some are proprietary and popularamong general public (like Skype and Teamspeak) whereas others are free and imple-mented in some open source project (like IAX and Jingle).

Skype and TeamSpeak

Skype [23] is the most popular VoIP software in the world. A lot of people use it tomake video calls or to call telephone numbers from the Internet. However, Skype uses itsown protocol called Skype protocol which has not been made publicly available.

TeamSpeak [24] is another proprietary VoIP software used to speak on a chat channellike for a telephonic conference call. It is mostly used by gamers for online multiplayergames. As for Skype the protocol hasn’t been made public (and remains secret).

16

Jingle and IAX2

Jingle [25] is an extension for Jabber to add VoIP features. Jabber is an open protocolbased on the XML language. It is decentralized and works in the same way as emailservices. It is very close to the protocol used by Google Talk and can also easily beconverted to SIP with specific gateways. There are a few clients and IPBX (like Asteriskor FreeSWITCH) that can use Jingle.

The Inter-Asterisk eXchange 2 (IAX2) is a protocol that can be used for any typeof streaming but is mainly designed to support audio calls. It has been designed by thecreators of the IPBX Asterisk and has been published in RFC 5456 [26]. It is supportedby Asterisk of course, but also by other IPBX and softphones. Compared to SIP, itminimizes the bandwidth used and provides a native way to traverse NAT. However, it isless flexible than SIP and new features have to be added in the protocol specification.

2.3.2 Service protocols

IP Phones, like the ones used in companies, are complex devices which offer a lotof features other than just VoIP. First, the whole boot process is quite complex andrequires several steps. When the phones boot they use DHCP to acquire an IP address,then they might use NTP to acquire the time used on the network. Then most of thecommercial phones download their configuration files using the Trivial File TransfertProtocol (TFTP), FTP, HTTP or HTTPS. Then, they might look to the upgrade serverin case of software upgrade, again with TFTP, FTP or HTTP(S). All these operationsmight require the use of the DNS protocol. At this point they can proceed to the SIPregistration and are ready to make and receive calls.

Secondly the phones can provide services and applications working remotely. Forexample, a lot of phones can use XML applications. These applications are running on aserver that receives HTTP(S) requests from the phones and responds with files using theXML format. It can be used for directories, calendars, speed dials, notes...

2.4 Unified Communications

Unified Communication is the new industry term used to describe the set of com-munication services intended for companies. It includes several products, with the aimto integrate them into one single software and interface that will manage everything, toincrease efficiency and ergonomy. This interface should be accessible from every devicesa company may have (smartphones, computers, tablets...). The main components are:

• Calendar: To manage meetings and deadlines

• Messaging: To send emails, SMS, fax, voicemail

• Telephony: To make audio and video calls directly with a physical phone or fromthe computer

• Conferencing: To schedule meetings, check the availability of the guests, makethe conference online with audio and video flows from everyone

• Presence: To know the presence state of a colleague (idle, in call, in meeting...)

17

• Collaboration: To work on a file from everywhere with several people at the sametime

• Data: To store the files online and access them from everywhere

This is a new business growing fast and several companies are working on solutions.VoIP occupies a key place in Unified Communication. It is still one of the major media ofcommunications used in companies and the flexibility of SIP allows the implementationof new features that will be integrated into the whole Unified Communication system.

18

3 Security on a ToIP infrastructure

Since the telephony has moved on IP networks, the attack surface has increased be-cause of its reachability. Before VoIP, when people were using analogical systems, theattack were mainly physical. Someone could have access to the wired line and installcopper straps to intercept the signal and listen to someone. This interception could altera little the quality of the call by adding some poor contacts which will lead to cracklingand even interference. However, to do this procedure the person needed a physical accessand the security measures to prevent it were pretty clear. There was also no authenti-cation and users could not be sure of the identity of the person who was calling them.Today, since ISDN and now SIP, all the devices are reachable from anywhere and theyhave evolved, they are computer with all the common security issues involved. The trafficpasses in the same cable as the others services and users do not have the control of allthe devices on the path. As for emails, the telephony infrastructure is a very criticalelement for companies. If someone gained access to a device on the network, he couldmake premium calls resulting to a huge bill for the company. No one is protected andevery company should be careful about it. One of the conceivable security step is to add aspecific device at the border of the ToIP network that will have the same role as firewall orreverse proxy for the traditional Internet services. Such devices are called Session BorderControllers (SBC). They will be presented in Section 3.2 after having a look at securityin ToIP in Section 3.1.

3.1 Security issues in ToIP

In the first part of this section, the security risks of ToIP will be showed along with therelated common attacks. Then, how to make ToIP as secure as possible will be discussed.Finally the limits of these actions will be explained.

3.1.1 Risks

Unavailability

An attacker could try to make the whole system unavailable. It can be done by findingbugs in devices, or more simple, by doing a DDoS attack on an infrastructure making theservers flooded by all these packets. The consequences will first be economical for thecompany. If the employees cannot make call anymore it will lower there productivity andeven prevent them to work. It can also be very harmful with emergency calls like forpolice officers and firefighters.

Corruption

If an attacker has a MITM position and has access to the media flow he could insert ordelete audio parts in the call. It can be used to give false information to someone. Indeed,the target will think these information are true because part of a certified conversationbetween him and the other. For example, a program of an attacker could change theanswering machine message of a bank, asking for the user account password after the

19

identification process of the beginning. The user is sure he is talking with the bankanswering machine so he won’t think of an attack here.

Non-confidentiality

This is one of the major risks. If someone can listen to all of the conversations of acompany because they are not using SRTP, it could compromise the whole company. Itcan also be used to steal user names, passwords and phone numbers. In the early daysof VoIP systems, no one was using SIPS and SRTP to secure the communication and itmade ToIP an attractive target for hackers.

Impersonation

An attacker could try to make calls pretending to be someone else. Indeed, if therecipient does not know the voice of the person, he will look at the name or numberwritten on the phone to identify the person calling. The main goal here is to ask forconfidential information or to make the recipient do a task for him.

Toll fraud

This is the major issue for small companies which do not have secret information anattacker might want to steal. The CFCA 2015 report about fraud loss [27] shows thatthe surveyed companies have lost more than 15 billion dollars with toll fraud. It can bedone with international calls or premium numbers calls. A classical way to do it is tohave access on a phone or the IPBX and use it to make automatic calls.

Harassing calls and SPIT

It is easier to generate automatic calls with VoIP than with traditional telephony.Everyone with a computer and a SIP trunk account can make or use a program to generatecalls to random numbers. These calls can play an advertisement, they are called Spamover Internet Telephony (SPIT) in this case, or harass someone. This problem is not yetcomparable with the email spam, however the increase of VoIP may induce the increaseof such behaviors. Researchers have been working on the SPAM detection, based on callfrequency, low call completion and low call duration average. Their works have beenpublished in the RFC 5039 [28].

Propagation

If an attacker gains access to any device of a ToIP infrastructure, it could be the entrydoor for all the IT infrastructure. From the server or the phone he controls, he couldtry to reach computers or other servers on the network. A company could have a perfectsecurity on the computer side of the infrastructure, it can be totally ruined if they do notapply the same security level in the ToIP infrastructure.

20

3.1.2 Common ToIP attacks

When an attacker wants to attack a ToIP infrastructure it has several known tech-niques to do it [29]. I will suppose that the basic protection with SIP digests is in place.Otherwise, anyone can pretend to be someone else intercepting every calls and making allthe calls he wants.

Banner grabbing

At the beginning of the attack, the attacker may want to gather information aboutthe targeted system, like the software running on the servers and phones. Using thisinformation with a Common Vulnerabilities and Exposures (CVE) can lead to securityissues. The SIP messages follow the model of the HTTP messages so there is a user-agentheader and a server header which carry the software used and its version. In addition,the SDP part has also a User-Agent field. Their utility can be discussed because the SIPprotocol is an open standard so, in theory, it’s not useful to know the recipient’s softwareto be able to communicate with him. An attacker could simply know the software bysending an INVITE message and looking at the fields in the response.

User enumeration

Then the attacker may want to list the users of the service, to impersonate them later,or to call them for SPIT. To find them, he can try to send REGISTER, INVITE orOPTIONS messages and look at the responses. The response will be different, regardingif he asks for a regular user or an unknown user. It can tell him if a user exists or not.

Password cracking

When the attacker has found some usernames, he can try to find their associated pass-word. He can do it by performing a brute-force attack (trying all the password possibili-ties) or better a dictionary attack (trying only the most likely). He will send REGISTERmessages, wait for the authentication query, and try a password in the response. If thepassword was not the right one, he will receive another authentication query. Otherwise,if the password was good, he will receive a 200 OK message. Once he found a goodpassword, he can use it to impersonate the user or to do toll fraud.

DoS

The most famous attack to make a system unavailable is a DoS attack. It consistson flooding the services in order to make them unavailable. This attack can saturate thenetwork links (volumetric attack) or make the server CPU reach 100%. The system will beunavailable for the legitimate users who will have their requests lost in the massive amountof flooding requests as shown below in Figure 9. There are several flooding techniques atevery layer.

The protection (excepted for the volumetric attacks) is to make a selection in thereceived packets in order that the server does not process every packet and keeps its

21

resources available. However, finding a way to do it efficiently is a very difficult problemand there are active researchers on this subject because most of the hosting providers wantto provide such protection. For the VoIP services, the most common way is to send a lotof INVITE messages. The server will process the message and it will consume resources,affecting its performances [30].

Attacker

INVITE

INVITE

millions of INVITE messages

INVITE

Figure 9: Example of DoS attack with INVITE messages

Illegitimate BYE

Another way to block VoIP for a domain is to send illegitimate BYE to close the calls.Indeed, if no security protocol have been used for SIP, there is no authentication betweenthe UAC Even if the messages pass through a proxy which authenticates the sender witha digest. A UAC will accept all messages on the condition of having the right identifiersfor the dialogue: the two tags and the call-id. Thus a MITM could want to stop theconversation by sending a BYE with the corresponding fields to both side of the call. Itcan be done to prevent someone or a company to make calls during a period of time.

Fuzzing

If an attacker finds a message that can crash the SIP stack of the devices, it willinstantly stop all the communications. The literature [31] proposes five categories ofmalformed packets:

• Incorrect Grammar

• Oversized Field Values

• Invalid Message or Field Name

• Redundant or Repetitive Header Field

22

• Invalid Semantic

The main goal of this attack is to crash the system, or exploit a software flaw such as abuffer overflow, to execute arbitrary codes.

Amplification

The SIP protocol has a vulnerability named “loop amplification attack”, shown in RFC5393 [2]. It can be leveraged to cause of small number of SIP requests to generate anextremely large number (up to 271) of messages. To achieve it, an attacker needs tworegistrar services and two addresses in each one. It limits the possible applications of thisattack. More details are given in Appendix A.

Steganography

Once an attacker took control of one device, he might want to transfer data outside,like calls logs, voice samples or documents from another computer of the company. To doit without being detected, he could want to hide it inside the RTP flow of a call. Callsin VoIP can use a quite high stable bandwidth that could allow an attacker to transmitdata. Several known techniques have been discovered by researchers:

• The Least Significant Bit (LSB) technique is a common way to do steganography.It consists of hiding data in the bits with the least importance so that the differenceis almost unnoticeable for a listener.

• The redundancy bits technique is similar to the previous one. Most codecs includeredundancy bits that can be used to check on the data received. Hiding data inthese bits is possible. If the transmission medium is good, the flow will fail theredundancy check at the recipient side but the audio will still be the same after thedecoding phase.

• The RTP extension header uses the possibility of adding RTP headers to hide thedata inside it.

• The LACK (Lost Audio Packets Steganography) technique hides the informationinto delay packets. If the packets have enough delay they will not be interpreted forthe audio restitution but still received by the recipient. These packets still belong tothe same media flow and to the conversation. Thus, they can pass some surveillancemechanism. At the end, the recipient can reconstitute the original data with all thedelayed packets.

These methods and others have been previously described in literature [32]. For example,a one hour call using G.711 audio codec consumes more than 200Mb of data. Using theLSB, an attacker can pass dozens of megabits of hidden data.

3.1.3 How to make secure ToIP

The risks for a ToIP architecture have been described in the previous part. A few ofthem were already present in the analogical telephony network but, again, the surface of

23

attack has increased. To prevent these attacks to happen, several measures have to betaken on both network level and system level.

Network Level

VoIP runs in top of the traditional IP network, so known protocols can be appliedto make the layers 1 to 4 secure. First, at the physical level, the equipments have to beprotected to prevent someone to get an access to it. That means that a company shouldnot put phones in public area of its buildings. They must have a good building securityto prevent a stranger to have access to some offices with VoIP systems. If someone canhave access to a phone he could modify the firmware to turn the phone into a spying tool.He could also make calls to premium numbers to make some dollars or make calls usingsomeone phone to spoof his identity. Then, the ToIP network and the computers networkhave to be separated to reduce the risks of propagation. It can be done physically orlogically with the use of separate VLANs. Using VLAN is easier and most companies usethis solution to separate ToIP. However, it is possible to jump from the computer VLAN tothe ToIP VLAN [33], making such protection not as secure as a physical separation. Witha dedicated network the computers of the company won’t be reachable with the phonesand reciprocally. However, such an approach might be quite difficult to apply with theUnified Communication systems used by some companies. Another difficulty with thisapproach is of course the cost of it. Some companies won’t pay the infrastructure cost toincrease security.

Then at the layer 2, 802.1X is necessary with mutual authentication such as EAP-TLS. It will prevent someone, who does not have a correct signed certificate, to plug hisown device into the network to infect other systems. Anti ARP-spoofing techniques mustalso be applied to prevent a user on the network to send spoofed ARP packets to receivethe RTP flow intended to someone else. This can simply be done with the use of staticARP tables but this does not scale to a large network. On the system OS, unsolicitedARP replies that might come from an attacker can just be ignored. The switches couldalso implement protection, based on the knowledge of the network given by the DHCPrequests/responses.

At the layer 3 IPsec can be used in some particular cases. For example if a companyhas several offices in different cities, they could use gateway in front of each network withIPSec to make secure tunnels between the places.

Then in the application level, SIP over TLS (SIPS) and SRTP/SRTCP are necessary.SIPS assures confidentiality, integrity and authentication for the SIP messages. If possible,the use of the dual authentication in TLS adds also authentication for the client. SRTPprevents eavesdropping, modification and replay of packets for the media flows. Thesetwo protocols are mandatory for a minimum security policy in ToIP systems. The use ofSRTCP is less critical than SRTP but it provides confidentiality, integrity and authentica-tion for the RTCP packets. In addition, if the phones use online XML services, they mustdo it with HTTPS and dual authentication (with TLS or just with digest authenticationon TLS). Figure 10 summarize the protocols and techniques presented.

24

Dedicated network, building securityLayer 1

802.1X, Anti DHCP-spoofing, Anti ARP-spoofingLayer 2

IPsecLayer 3

TLSLayer 5

HTTPS, SIPS, SRTPLayer 7

Figure 10: Security measures at the network level

System Level

Once the secure versions of the VoIP protocols are in place, the system has to beprotected against attacks that use the correct behavior of the secure protocols. The sys-tem administration best practices have to be followed. First, secure passwords (minimalnumber of characters, use of uppercase letters and symbols) must be used to preventsomeone from guessing it. Then, the systems must be upgraded to their last version toprevent someone to use known vulnerabilities that have been fixed since. In the infras-tructure, a backup system must be in place to prevent single points of failure. It canbe a redundancy of the IPBX and SIP servers. Then system hardening must be done toreduce the surface of vulnerability. Here, it will consist of disabling the services that arenot used and revoking the credentials that are not needed. The configuration must bedone very carefully on the servers because a bad configuration can induce vulnerabilities.Finally, the infrastructure has to be monitored to detect intrusion or strange behaviors.The network throughput can be watched for the whole system and per host, as well asthe state of the devices, the bills for the month or the number of calls made. Detectingan attack as early as possible will reduce its impact.

3.1.4 Limits

However, even if most of the suggestions above have been applied to the ToIP infras-tructure, some attackers could pass through these protections. It can be done because ofhuman factors or because of vulnerabilities in the protocols or in the running systems.Several scenarios are presented below to examine what could be done to prevent them tohappen.

IP Phones vulnerabilities

In the worst cases, the IP phones may be the target of attacks to gain a root access onthem or to change their firmware. Once this has been done, the attacker can do anythinghe wants with the phone. The system administration best practices described above makesuch attacks more difficult but there are always risks. For example, in 2013, it has beendiscovered [34] that some phones could be turned into spying microphones. This attack

25

required a physical access to the phone. Then, the serial port of the phone was usedto inject binary code that exploited a security vulnerability to change the firmware andinstall whatever the attacker wanted. With this kind of attack, the attacker will be ableto spy on every calls, to corrupt the RTP flow, to have access to the phone password,to make automatic calls to premium numbers, to turn the microphone on to spy on theemployees or to contaminate the other systems on the same network...

Even if the attacker cannot have a root access on the phone, he can change the config-uration files (using the web interface or by exploiting a vulnerability in the configurationdownloading) and do some serious damages. First, he could disable the use of TLS andchange the address of the SIP proxy. For example, he could put a B2BUA that willtransmit the messages to the right proxy. The user won’t see any change during a call butevery call will go through the attacker server that will see everything. The attacker couldalso disable the use of SRTP and add a media gateway for the RTP flow. A gateway thatwill belong to him of course. He could also change the address of the telephone directoryto give the user a false phone number and get some information from him. Finally, thiscan be used to modify the firmware server address and change the firmware, making theattack worse.

If the configuration file cannot be changed and the attacker cannot modify anything onthe phone, he can still use it to make manual phone calls to make money or impersonatethe phone owner.

IPBX vulnerabilities

As for the phones, the IPBX and other SIP servers are not immune. An IPBX canbe compromised and used to execute the same attacks as for a single phone above, butfor every phones at the same time. The IPBX might also have the SIP passwords or thevoicemail passwords in clear text so an attacker could have all of them in case the IPBXis compromise. These passwords could also be used by other services and the attackercan use them to propagate the attack. In addition, the IPBX is very critical and it isat the front line of the SIP messages, so if a single vulnerability in the parsing of theSIP messages is found, it can make the whole service unavailable. It happened with thesoftware based on OpenSER in 2009 [35], a single INVITE message with multiple “:” inthe via field could make all the system crash. The fix was out few days after but duringthe interval the systems based on OPENSIR were very vulnerable.

With the SIP protocol, every SIP router on the path puts its own IP address in a Viaheader. It is useful for routing back the messages but this is a confidentiality leak foroperators. They do not want anyone to know the IP address of the IPBX because it is agood way for keeping it away from attack. The SIP protocol does not give a direct wayto deal with this problem.

MITM threats

The security policy may be to use TLS and SRTP for every calls. However, the finalchoice depends on the two sides of the call. A ToIP infrastructure of a company canuse TLS for internal calls. There will be cases where an external destination cannot usethese protocols, because it does not want to or because these protocols have not beenimplemented. In this situation TLS will not be used and a MITM could intercept the

26

call. The fault could also be because of the phones, they can have a weak version of TLSor vulnerabilities in the implementation itself. Depending on the vulnerabilities, a MITMattack might be possible and someone could listen and modify the media flow.

DoS attack

An attacker could easily launch a DoS or a DDoS attack as explained in Section 3.1.2against some element of the infrastructure. It can be the IPBX directly or the phonesas they have less computational power and thus are easier to overload. A company canalready have a firewall in front of its ToIP network. However the firewall does not have afull SIP understanding and cannot implement complex rules.

In most of the cases above, upstream actions can be taken to limit the possibility foran attacker to achieve them. However, zero risk is not possible and the ToIP infrastruc-ture has to be ready in case someone succeed attacking it. Something else, downstream,is needed to reduce the impact of the attack and to keep a high level of security. Thisexpectation is one of the issue a Session Border Controller is supposed to fulfill.

3.2 Session Border Controller

With the industrialization of VoIP some new needs appeared. The extensibility of SIPhelps the vendors to implement new features easily, by adding new headers. However,a few of them, like the NAT traversal and the topology hiding, could not be answeredby the SIP protocol. Thus, vendors started to create a new device called Session BorderController (SBC) to fulfill these needs.

3.2.1 Principle

A SBC can first be seen as a reverse proxy for SIP based systems. A reverse proxy is adevice acting, on the server side, as an intermediate between any client and one or severalservers. Reverse proxies are often used for HTTP and can have security or optimizationfeatures for serving web pages. A SBC is originally placed at the border of the networkto interconnect two different ToIP networks and to protect the network from the outside.It can be seen as a toolbox that will add features in all domains of ToIP. It is presentfor a long time in operator infrastructures and is spreading in companies along with theincrease in the use of ToIP. The SBC market is growing fast, and has reached 271 millionin 2014 [36]. The most famous SBC vendors are Oracle ACME, Cisco, Alcatel-Lucentand AudioCodes [37]. An example of SBC placement is shown Figure 11.

27

Company A

SBC

ISP A SBCSBC ISP BSBC SBC

Company B

SBC

Figure 11: Example of SBC placement

A SBC is in the path of all SIP messages. When it receives a SIP packet, it passes itthrough a lot of processes and then transmits it to the other side. To have more flexibility,it has to act like a B2BUA (described in Section 2.1.2). It will divide each call into twocall legs to manage each side independently. The two users will think they are talkingto each other directly but they will talk to the SBC instead. On each side of the call,different parameters could have been chosen. For example, one side could use the iLBCcodec and the other the G.711 codec with the SBC at the middle which transcodes theaudio flow as shown in Figure 12.

Alice B2BUA Bob

INVITE (SDP iLBC)

100 TryingINVITE (SDP G.722)

100 Trying

180 Ringing180 Ringing

200 OK (SDP G.722)200 OK (SDP iLBC)

ACKACK

RTP (iLBC) RTP (G.722)

BYEBYE

200 OK200 OK

Figure 12: Use of a B2BUA to transcode audio flow

28

The SBC can modify the SIP messages before transmitting them in order to removesome fields or rewrite them. It can modify the SDP part to change the codec or the IP ad-dress written in it. It can use SRTP on one side and not in the other side. Fundamentally,a SBC sees and can modify everything, following the chosen security policy.

3.2.2 Differences with existing devices

Now that the principle of a SBC has been presented, it is logical to wonder if adevice already present in the ToIP infrastructure cannot achieve these features. A ToIPinfrastructure already has an IPBX, understanding SIP well, and a firewall, dedicated tosecurity.

Differences with an IPBX

The IPBX and the SBC act as a B2BUA but they do not have the same purpose atall. The IPBX is here, first, to assume the role of SIP Proxy as described in the RFC3261 [9] and it acts as a B2BUA to bring features like call forwarding, call transfer orvoicemail. In contrast, the SBC is a ToIP toolbox that can relieve some features from theIPBX, but above all, it brings features that can only be made at the border.

In addition, the SBC brings another level of abstraction for ToIP security. One of itsfirst role is to protect the IPBX that might be vulnerable, because not really thought forsecurity.

Differences with a firewall

Both firewall and SBC are in the border of the network, one could think that mergingthem will reduce the costs and complexity of the installation. First, on a security level,this is generally a bad idea to mix features and vulnerabilities. It will remove the higherlevel of security a SBC can add.

Then, even if a firewall can understand the SIP protocol, it can only block messagesdepending on criteria it received before. For example, it could block calls from domains,prevent REGISTER messages to come from the outside or open RTP port after seeingthe SDP part of the INVITE. In fact, rules are only used to know if it has to transmit themessage or not based on this particular message, independently of the others. The SBChas a full awareness of the SIP stack so it can really understand the whole conversationand apply smarter filter. Besides, applying filters is only a piece of what a SBC can doand all the other features like NAT traversal or protection against specific SIP attacks arefar beyond what a traditional firewall can do.

The SBC has some unique features that can only work at the border of the net-work. Thus, it cannot be replaced by an IPBX or a firewall and it is absolutely necessaryfor some companies. In the next section, the features offered by a SBC will be presentedwith more detail. A special attention will be given to the security features. After thatthe placement of the SBC in the ToIP architecture will be discussed in Section 5.

29

4 SBC features

The SBC offers a large range of features. First, it offers internetworking features toconnect networks working with different sets of protocols or to allow NAT traversal. Then,it offers QoS features to monitor the calls and to improve the global quality of the service.Moreover, it offers media features like transcoding, media recording or DTMF conversion.Finally, and not the least, it offers useful security features to protect ToIP network againstattackers. In this section every aspect on the SBC will be presented with a focus on thesecurity features. Some features are already present in several proprietary SBC whereasothers are suggestions that can improve the ToIP of a company and are new.

4.1 Internetworking

Most of the time, the SBC will be at the border of the network and will be the elementthat separates the VoIP network from the outside network. Thus, it can provide featuresto facilitate the connection:

Protocol conversion: It can convert protocols between the 2 networks it is between.The most used conversion are between the SDP early offer and SDP late offer, andbetween SIP and H.323.

SIP normalization: One might think that, because SIP is an open protocol that hasbeen defined in a RFC, there is no incompatibility problem between SIP implemen-tations. Unfortunately, this is not the case and some points in the protocol are notunderstood in the same way by the different developers. The SBC can easily rewritesome fields to make the message understandable by both sides.

NAT traversal: The SIP protocol has no option to deal with NAT. Some protocolscan be used. The most known methods are Session Traversal Utilities for NAT(STUN) [38], Traversal Using Relay NAT (TURN) [39] and Interactive ConnectivityEstablishment (ICE) [40]. However rely on these protocol is risky and the SBC canbring its own solution by rewritting the fields and transmitting the media flow.

Routing: The SBC can route the calls based on SIP attributes to improve the latency.It can choose the best path looking at the From and To headers, the codecs used orthe answer-seizure ratio [41].

4.2 Media

The SBC will see all the SIP traffic and then can decrypt any SRTP sessions actingas a media gateway between both users. Thus, it has access to the media flow to recordit or to modify it:

Transcoding: If the 2 sides of a call have no common codec, the SBC can use a differentcodec for each side and transcode the flow between each side. Table 4 has beenmade using the documentation of each system and device. It shows that, for thephones and softphones, the codecs understood are very disparate and some haveonly the G.711 codec to communicate, which is not the best codec for both quality

30

and bandwidth. Thus the use of a SBC can be very useful to overcome the codecproblem.

Device G.711 G.722 G.722.1 G.722.2 G.723.1 AMR G.726 G.729 G.719 iLBC OpusAndroid (mobile OS) X X XiOS (mobile OS) X X XCisco 7800 (phone) X X X XAlcatel-Lucent 4008 (phone) X XAastra 6739i (phone) X X XEkiga (softphone) X X X X X XLinphone (softphone) X X X X X XAsterisk (IPBX) X X X X X XFreeSWITCH (IPBX) X X X X X XCisco Cube (SBC) X X X X X X X XACME Packet 6300 (SBC) X X X X X X X XSonus (SBC) X X X X X X X X X

Table 4: Codecs understood by some SIP systems

Recording: Even though users do not like the idea of being listened to, there are severallegitimate reasons to record calls of a VoIP service [42]. SIPREC protocol is avery new protocol, still in the draft state for the IETF [43], which aims to give aframework to call recording between a Session Recording Client (SRC) and a SessionRecording Server (SRS). The SBC can act as a SRC and record calls. This featurewill strengthen the critical behavior of the SBC.

DTMF conversion: There are several ways of transmitted pressed keys on VoIP net-works [44]. Unfortunately some devices might not support the same techniques andwill not be able to use DTMF between them. The SBC could play the role of DTMFrelay to convert one way to another making DTMF works for both.

4.3 QoS

Everyone has experienced calls with very bad quality that were almost impossible tocontinue. A SBC can implement several mechanisms to improve the quality of the callspassing through it. It can be done with traditional QoS techniques, by modifying the flowwith some algorithms, or with rules to prevent a predictable bad situation:

Protocol efforts: The SBC can check the QoS fields in SIP messages. It can also havean internal prioritization mechanism based on the From and To fields.

Call Admission Control: Contrary to TCP/IP network, in case of congestion, it issimply better to reject the call and avoid customer dissatisfaction instead of puttingthe SIP messages in a buffer. A Call Admission Control (CAC) defines rules to knowif the SBC can let this new call being established or not. Criteria of interest canbe the number of call attempts per second or the maximal number of concurrentsessions.

Codec selection: It could be better to select the right codec depending on the availablebandwidth to avoid a bad quality call at the beginning of a call. The SBC couldknow the maximal bandwidth from the parameters or from estimations [45] andinfluence the codec chosen.

31

Speech Processing: The SBC can apply techniques to improve user experience. Thewidely used ones are echo cancellation [46], voice activity detection [47], and comfortnoise generation [48].

4.4 Security

Section 3 has shown that the needs for security in ToIP are very high and cover severaldomains. The SBC aims to provide protection against known attacks, enforcement of thesecurity policy and damage limitation in case of successful attack. This part will describeall the security measures that a SBC can support.

4.4.1 Upstream protection

First, the SBC could prevent an attacker to prepare an attack by enforcing internalsecurity policy.

High frequency registration

When a UA sends a REGISTER the server responds with a 200 OK containing anexpires header indicating the time window during which the binding will be considered asvalid. Setting a short period of time will help in the fight against identity spoofing. Duringthe time of the registration, someone could try to steal the IP address of a legitimate user(by ARP spoofing for example). If someone succeed in taking the IP address, he willreceive the calls destined to the user and could impersonate him. If the registration is fora short time, the IP address will not be of any use once this time is passed and it will limitthe damage. If a very short time has not been set in the expire header, this is because itwill consume more bandwidth and might overload the IPBX which has already a lot ofthings to do.

The SBC can be useful here by acting as a special relay for registration. It can controlthe registration timer in the middle: short timer for the endpoints and long timer for theIPBX. The long timer could be much longer than a regular service timer. The SBC keepsthe state of the registration like a regular registrar and sends the REGISTER to the IPBXas long as the registration for the phone is OK. If the associated phone changes its IPaddress or stop sending REGISTER, the SBC can send a REGISTER with an expires field0 which is equivalent to an "unregistered" method. Another advantage of this technique isto keep the NAT pinholes (bindings between public and private IP address and port) alivefor the phones. The process is shown below in Figure 13. The SBC keeps REGISTERmessages every 30s with Alice and transmits them only every 3600s to the IPBX.

32

Alice SBC IPBX

REGISTERexpires: 1800s REGISTER

expires: 3600s200 OK

expires: 3600s200 OKexpires: 30s

REGISTER

200 OKEvery 30s

REGISTER

200 OKEvery 3600s

Figure 13: SBC action to allow high frequency registration

Topology and identity hiding

Topology hiding is one of the key function of a SBC and is present since the beginningof the use of SBCs. The problem is simple: a company does not want to reveal its internalnetwork topology. That means that they want their servers and their IP addresses toremain secret from the outside world. As explained in Section 3.1.4, the servers, followingthe SIP protocol, will put their IP address in the VIA header, making the final recipientaware of all the IP addresses of the servers on the way. The solution to this problemlies in the use of a B2BUA. The SBC is at the border and will start a new call with theoutside hiding all the sensitive information from the original call.

In addition to topology hiding, a company might want to hide the information theirusers have put in the fields to provide anonymity. It can be done by rewriting the Contactheader, From header, Reply-To header and Call-Info header.

TLS and SRTP enforcement

The SBC is part of every call and must support SIP over TLS and SRTP to providesecurity for the entire network. The SBC can enforce the security policy by using TLSand SRTP with external hosts each time this is possible and even refuse the call if this isnot possible. However, even if the SBC is in charge of the security between the internalnetwork and the Internet, the use of secure protocols between the SBC and the phonesis important. The network is not immune against an internal MITM and a maximalprotection for the calls has to be applied. It can imply the use of an internal PKI insteadof just a certificate for the SBC. Moreover, the SBC will be in charge of security so its TLS

33

implementation must be carefully verified and security updates must be applied quicklyafter each discovered vulnerability.

In addition, the use of a SBC permits to manage carefully the cipher suites that willbe used on a single point instead of multiple points. Maybe the phones have an oldimplementation of TLS that uses non secure ciphers. The SBC can keep a list of thedesired ciphers and only agree on them to provide a more secure TLS connection. It canalso influence the key exchange protocol used by SRTP and force the use of DTLS-SRTP,which is the most secure way to proceed as described in Section 2.2.3.

4.4.2 Common attack protection

This section presents the protection a SBC can offer against the ToIP attacks thathave been described in 3.1.2.

Banner grabbing protection

The banner grabbing technique, used to gather information, could be the beginningof an attack. Most SIP implementations give to the user the possibility of disabling theuse of the User-Agent. However, the SBC could also perform this check and remove orrewrite headers when necessary.

SIP user enumeration protection

The user enumeration technique is explained in Section 3.1.2. The SBC is fully aware ofthe conversation and thus can detect that the response message gives to much information.Then it can modify the message to give the same information, whether the user existsor not. For example, it can always be configured to respond with a 401 Unauthorizedmessage.

Password cracking protection

Maybe the registrar has no security mechanism to detect if someone is trying too manypasswords. The SBC could count the number of REGISTER per time period. When thenumber of password attempts exceeds the limit fixed in the system, the IP address willbe blocked for a certain amount of time. The attacker will have no choice but too waitand it will greatly limit the number of attempts he will be able to make.

DoS protection

The DoS attacks are one of the most common attack as shown in Section 3.1.2 and thesystem needs to be prepared for such attack. The SBC might not be used in addition witha firewall and might be the one to assume the defense of the network. Beside protecting theSIP servers, the SBC is an attractive target and it has to protect itself. An attack couldcome from the inside and the SBC has to be ready to handle it. Two types of solutionsexist: the ones taken from the firewall techniques and the ToIP specific solutions.

34

The SBC can implement the classical solutions used by firewalls. First it can havea solution based on the IP addresses of the messages. This solution is very basic andwill not stand against spoofed IP addresses or attacks with thousands of attackers. Inaddition, the traffic can be classified in categories and different policies applied to them.The traffic can be separated in three categories [49]: the white, black and gray traffics.Several rules can be added to pass from one group to another: for example if a user sendsmore messages it can be blacklisted, the same if he sends malformed messages or tries todo unusual things. The sorting can be done with a hardware architecture to increase thecapacity.

Then, the use of a CAC for quality improvement, as explained in Section 4.3, can helpin case of such attacks. If too many messages are received, all the values used by theCAC will be quite high and all the new calls will be refused. Of course when a message isreceived it passes through the whole SIP stack of the SBC and that consumes resources,thus this solution will not stand in case of heavy attack.

Illegitimate BYE protection

The illegitimate BYE attack has been presented in Section 3.1.2. To prevent thisattack, TLS may be used to secure the communication and prevent a stranger to sendmessages.

Another way to detect a fake BYE is to look at the entire session instead of just theBYE. If after the BYE, the party supposed to have sent it continues to send RTP packets,it indicates the BYE wasn’t from him after all. This check can be done at the SBC levelby delaying the BYE transmission for a few ms. If the SBC was wrong and has droppeda licit BYE, it will be sent again to the SBC because its sender is expecting a 200 OKresponse from it.

SIP filtering

The SBC analyzes each packet before transmitting it to the internal network. It caneasily check all the fields in the SIP header and in the SDP part to see if it is compliantwith the standards. If an unknown or invalid field is detected, the SBC can rewrite ordrop packets sending back a 400 error message.

Thus, it could protect the phones from some malformed packet. However, the SIPstack of the SBC itself might also be vulnerable to fuzzing. The SBC is in the front lineof security mechanisms and its stack must be well verified.

Loop detection

The RFC 5393 [2] explained the problem shown in Section 3.1.2 and proposed as asolution the use of a new header field called Max-Breadth. Each server when it forks amessage into n messages will divide for each one the initial field value by n. Once thevalue reach 0, messages are not forked anymore. Thus, it limits the number of messagesexchanged at the same step and solve the problem. The RFC 7332 [50] extends thissolution to the B2BUA. There is almost no implementation of these RFCs in commercialand open-source software.

35

4.4.3 Downstream protection

Finally, once an attacker succeed in making one of the previous attack, the SBC cantake some measures to limit the damages the attacker will be able to make.

High Availability

The need for reliability is very huge with ToIP and the SBC can help us achievinga very low downtime. Every SBC administrator has to be aware that his SBC is a newpoint of failure in his infrastructure: if it crashes, his whole telephony will be down. Thus,for security reasons, the SBC must have redundancy to reduce the downtime in case oftrouble.

In addition, if the SBC is placed in a large ToIP network with a lot of calls, maybeone IPBX is not enough. In such case, more than one IPBX is needed and the solutionis to split the traffic between them. The traditional way of doing it is to statically assignfor each Customer Premises Equipment (CPE) the IP address and port of an IPBX. Ifit is done with a large number of CPE, on average all the servers will support the sameload. However this approach won’t work in every case:

• When a certain server is heavy loaded, others that have lighter traffic cannot sharethe overload. This happens commonly.

• To prevent overload it will be needed to overdimension the servers which will bewasteful because most of the time the servers will not be used.

To be fully efficient, a device in front of the IPBX that will split the traffic smartly betweenthem is needed. The SBC can assume this role efficiently. When it receives an INVITEfor a new call, it will choose one of the IPBX to handle the call following a distributionstrategy [49], such as:

• Round robin: The SBC transmits the requests to each server in turn. At the end,all the servers will receive the same number of requests and must have almost thesame load. It can be good if all the servers have the same capacity.

• Random select: It is similar to the round robin method. The server is selectedrandomly, so that all the servers receive the same amount of requests.

• Least busy: The SBC knows which calls are still active on which IPBX so it canselect the server with the least number of active sessions.

• Proportional Distribution: A distribution of the calls is made, giving to eachserver the percentage of the calls it must handle. Then the load balancer tries torespect this distribution.

Diversion protection

The SBC can have the knowledge of the ToIP infrastructure to detect suspicious IPaddresses in the header fields. It can analyze the Via header, Record-Route header,Contact header, o and c field in SDP to detect an IP that does not belong to the internal

36

network or is not the one expected. An attacker may use these fields to add a mediagateway to listen the call, to add a Record-Route header or a Via header to see the SIPtraffic or to start a call without passing through the SBC check. If an unexpected valueis detected in one of these fields, the SBC can remove it, putting a right value, or discardthe packet, returning a 400 Bad request message.

Call permissions

The SBC can enforce the security policy by preventing some calls from being estab-lished. It can block some numbers with a blacklist, block groups of users to interact witheach other and analyze the calls looking for anomalies.

The first need for the system is to block illegitimate calls towards internal users. Itcan simply be someone harassing employees or doing SPIT; or someone that has beendetected with the security mechanisms described in this section and who might be anattacker or at least a suspicious person. The easiest way to achieve it is to make a listof IP addresses or domains users should not talk with anymore. If the SBC receives acall from someone in the blacklist, it just drops it and if someone from the inside triesto call someone in the blacklist, it aborts the call and responds with a 403 Forbidden forexample. This security feature could also be used to block the premium numbers. Theybegin with the same prefixes and thus can be easily blocked to prevent toll fraud.

Then, the easiest solution to manage users is the group management. Users can beclassed in groups and each group will have permissions. In a company it can for examplebe a user group by department or a group by level of qualification. From these groupssome rules can be defined:

• A limit for the outgoing calls to the PSTN network. For example, the humanresources group and the secretaries group will have the possibility to make calls tothe outside whereas the trainee group will not have this right.

• A limit for the ingoing calls from numbers outside the company.

• A limit for the calls between some groups to prevent calls between users that haveno reason to talk to each other.

The IPBX could implement a solution but the SBC could perform the ultimate verifica-tion, thus adding a higher level of security in the ToIP system. An implementation ofthis feature is presented in Section 7.1.

Finally, the SBC sees every call from beginning to end. Thus, as for the IPBX, it canproduces the Call Detail Records (CDR). Then, it can use these CDR to detect suspiciouscalls from unexpected behaviors to raise alerts based on criteria it received before or toblock the calls. The feature is explored in details and implemented in Section 7.2.

Steganography protection

The steganography techniques used in VoIP calls have been described in Section 3.1.2.There are several ways to prevent steganography. First, steganalysis techniques can beused to detect the use of steganography. Most of these techniques can be detected moreor less successfully. For example the use of the LSB technique can be detect with a 100%

37

success rate [51] and the LACK technique could be detected by looking at the out of orderpackets.

However, each new technique needs its associated detection method and the systemis not sure that someone is not using a new undocumented one. Instead of relying ondetection algorithms, the system could simply transcode the media flow to another codec.The SBC feature described in Section 4.2 can be reused for this purpose. At worst, itcould lower the quality due to the hidden bytes that could tamper the conversion. If thetranscoding between two different codecs is not possible because of the endpoint phones,the signal could simply be resampled. In addition to it, the RTP header must be entirelyrewritten to remove hidden information that it may contain.

38

5 SBC Architecture integration

During the SBC introduction, it has been said that a SBC was a device placed atthe border of the company ToIP network. If the IPBX used by a company is not in itsnetwork, the border is the only place a SBC can be put. This can be the case if theadministrators have opted for an IPBX in the cloud or if the IPBX is on another site ofthe company. In the other case, if the IPBX is inside the company network, the placementof the SBC is a point that could improve security.

5.1 At the border of ToIP architecture

5.1.1 Presentation

Placing the SBC at the border of the ToIP network is the most common way to installit. Thus, it will achieve its internetworking, QoS, media and security functions. Thisconfiguration is described in the documentation of many SBC vendors. An example ofsuch infrastructure is shown below in Figure 14. The SBC is at the border, between theInternet and the internal ToIP network. The IPBX and the phones are behind it.

InternetInfrastructure

(DNS, DHCP, NTP...)

SBC

IPBX

Enterprise network

Figure 14: Internal architecture with a SBC at the border of the ToIP network

In case of external call, the phone sends its SIP messages to the IPBX that will treatthem and transmit the responses to the SBC. The SBC will pass the messages throughits internal processes and transmit them to the recipient. The SRTP flow passes directlythrough the SBC until the final recipient.

39

5.1.2 Limits

With this configuration, the SBC will handle very well security features for calls fromthe inside to the outside and conversely. However, the security will not be as good inthe other side of the SBC. Indeed internal calls and messages from internal devices to theIPBX will not pass through the SBC. This supposes that the internal network is secureand that the security features offered by the SBC are not needed in these cases. Thesolution to protect all of the calls is to place the SBC in front of the IPBX, at the centerof the network.

5.2 At the Center of ToIP architecture

5.2.1 Presentation

In this scenario, the SBC will be installed at the center, between the phones and theIPBX. Any call or message to the IPBX will pass through the SBC which will apply itssecurity functions to them. To make sure that no phone are talking directly to each other,bypassing the SBC, specific configuration such as private VLANs [52] can be configuredon the switches.

The VoIP flows are shown in Figure 15. The phone sends its SIP messages to the SBCwhich will transmit them to the IPBX. Then, the IPBX will respond back to the SBCwhich will transmit the messages to the right recipient. Note that the SRTP flow passesthrough the SBC.

InternetSIPS

SIPS

SIPS

SRTP

IPBX

SBC

SBC

Figure 15: VoIP flows with a SBC at the center

5.2.2 Limits

In this configuration, the SBC will handle well the security of the network for bothinternal and external calls. However, this will pose a problem for internetworking. In mostcases, the SBC won’t be at the border anymore. Indeed, numerous companies use a NATand it will be before the SBC when a message arrives. Thus, some features might not beworking. For example, this will be the case for NAT traversal and maybe for topologyhiding. In addition, several communication protocols will coexist on the network becausethe conversion will not be at the border anymore.

40

5.3 Combination

The optimal configuration for security and internetworking will be a mix of the pre-vious ones. The first one allowed internetworking features but had trouble with securitythat were corrected in the second configuration. With two SBCs, one at the center andone at the border, as shown in Figure 16, the advantages could be combined.

Internet InfrastructureNAT, DHCP...

SBCSBC

IPBX

Enterprise network

Figure 16: Internal architecture with two SBCs at the border and at the center of theToIP network

Obviously, this configuration will cost more money for the enterprise as it needs twoSBCs instead of one. However, it will allow them to enforce a coherent security policywithin the network and at its border.

41

6 SBC Security Test

Now that the main features expected from a SBC have been identified, the adequacy ofa solution with the requirements can be evaluated from a security perspective. To do so,I have first established a test methodology with the tests to be done and the informationsought. After defining the methodology, I have applied it to an example with Kamailio[7].

6.1 Methodology

6.1.1 Test environment

First, the SBC has to be put into a test environment. The environment must containat least a SIP server and two phones to make calls. The phones can be real IP phonesor softphones in order to ease the use of scripts. The SIP servers can be an IPBX likeAsterisk or a SIP Proxy like Kamailio. To examine the packets, it can be useful to havean access to the servers to execute a tcpdump or an access to the switch to activate portmirroring.

6.1.2 Features announced

First, a look can be taken at the datasheets of the SBC to know the features that havebeen implemented and to compare them with the ones expected. This will give a firstopinion of the SBC capacity. Table 5 summarizes the security features presented in theprevious part.

Feature PurposeHigh frequency registration Prevent identity spoofingTopology hiding Hide the internal network architectureIdentity hiding Hide user informationEncryption with TLS Protect signalizationConversion SIP ↔ SIPS Use TLS on the internal side if an external end-

point does not support itEncryption with SRTP Protect media flowConversion RTP ↔ SRTP Use SRTP on the internal side if an external end-

point does not support itForce the use of TLS Enforce security policyChoose the right cipher Block weak ciphers from being chosenForce the TLS version Block weak version of TLS from being usedRemove UA SIP field Prevent banner grabbingRemove the UA SDP field Prevent banner grabbingSIP user enumeration protection Prevent someone to discover existing extensionsPassword cracking protection Prevent password brute-forceIllegitimate BYE protection Prevent a MITM that would close callsDoS protection Prevent unavailabilityCall Admission Control Prevent DoS and improve quality

42

Sanitize SIP and SDP Protect the protocol stackLoop amplification detection RFC 7332 and 5393 to prevent amplification attackHigh Availability Prevent single points of failureDiversion protection Check the IP addresses in the SIP messagesBlacklisting Prevent harassmentRestrict external calls Prevent toll fraudPrevent call between users Enforce internal phone policyTranscoding Prevent Steganography

Table 5: Overview of the security features

6.1.3 Fuzzing

The SBC is a single point of failure in the ToIP network and it will be at the front lineof fuzzing attacks, as described in Section 3.1.2. Several tools have been created to testthe SIP implementations [53] [54]. However these tools are based on a few SIP messagesprepared in advance and already present in the software.

Thus, a more sophisticated fuzzer, like AFL [55], can be used. AFL is an intelligentfile-format fuzzer that will instrument the executable (either by specially compiling itor using binary analysis) to determine whether or not it’s hitting “new” code on eachexecution. AFL works with programs that take a file as input. Thus, to use AFL on aserver, the source code has to be modified to make it takes the SIP messages as a fileinstead of by the network interface. If an access to the source code is not possible but onlyto the binary, some tools can be tried like preeny [56], which takes the input file instead ofthe fuzzed program and transmit it to the program by the network interface. Both waysof launching AFL can be quite difficult depending on the tested program. However, AFLhas shown its efficiency in many cases [55].

6.1.4 Dos/Flood

The SBC will be at the front in case of Dos Attack at the SIP level, one of its jobscould be to reduce the effects of this attack (as explained in Section 4.4.2). Its reactionto attacks has to be tested: to know how many SIP messages it can handle by seconds,how it will react in case of heavy DoS attack, how many simultaneous calls it can manageand what will be the effects on them if someone DoS the SBC during a call.

The tools available to make that kind of attacks on SIP are rudimentary [57] and Ihave not found the appropriate tool for testing SBC DoS reaction. Thus, I have created aPython script, perfectible but sufficient, to validate the behavior of the SBC. The scripthas some interesting features. First, during the flood, it looks at the response from theserver and gives back the statistics to the user in real time. If wanted, a password canbe indicated to the application which will then respond to the authentication requestsfrom the server with it. If the password is right, this will make the server accepts the calland increase the resources used. A range of IP to spoof can also be specified to counterthe simple DoS protections that could be implemented in some SBCs. The program iscomposed of three threads: one to send the messages, one to listen the responses from theserver and eventually respond to it and one last to display the statistics in the prompt. To

43

increase the speed of the program, the IP spoofing is not made with scapy but by writingthe whole IP packet with the script. It can achieve up to 100 000 INVITE messages persecond without IP spoofing and 80 000 if the IP spoofing feature is enabled. The messageintensity of this application is good but could be improved by using a faster language.

During the tests, the softphone Ekiga [58] is used to have the network statistics of thecall to know the exact effect of the attack. It gives the lost packets, late packets, out oforder packets and the jitter buffer.

6.1.5 TLS quality

The use of TLS with SIP is a major part of the data protection. As the SBC willbe part of all the calls in both a client and server role for TLS, its TLS stack must becarefully managed. First, the solution must be configured to use only correct TLS versionand the weak SSLv2 and SSLv3 must be disabled. Then, the cipher suites used must beconscientiously chosen. The use of weak ciphers could break the encryption. Furthermore,the TLS stack must be updated to the last version to correct the known vulnerabilities.

A configuration audit can be executed with the helps of tools like TLS Prober [59],that detects the implementation of TLS and its version by sending a range of probes, andSSLScan [60] that gives the ciphers used by the server, classed in order of preference.

6.1.6 Common SIP attacks

Some attacks that are specific to VoIP and SIP systems can be tried to see if the SBCoffers some protection against them.

User Enumeration

Tools like SIPVicious [61] can be used to test the SBC reaction to extension enumera-tion. The program takes as input the range of numbers that need to be tested, the method(INVITE, REGISTER or OPTIONS) and the address of the server. Then, it returns alist of users the script thinks they exist

Secret brute-force

Once a valid user of the system is known, an attacker can try to guess his passwordby doing a brute-force attack or a dictionary attack, as explained in Section 3.1.2, withINVITE or REGISTER messages. If the SBC has no specific protection against thiskind of attack, it can be really fast. SIPcrack [62] can be used to crack SIP digests. Adictionary can be given to the program to speed up the cracking. For example, withKamailio on the same network, it can guess a six characters password in a few minutesdepending on its complexity and the dictionary used. If the attacker has the control of arouter on the way, he can fake the source IP address in order to avoid SBC protections.The IP router will see the response even if the message never goes back to the attackercomputer.

44

Banner grabbing

The information gathering protection can simply be done by looking at the content ofthe messages with a tool like Wireshark. However, to be more efficient, I have written aPython script which takes an IP address for input and return the user agent of the SIPsoftware running on the targeted system.

Illegitimate BYE

The SBC could implement some protections against Illegitimate BYE. I have writtena Python script which listens on the network for SIP messages. When it receives a SIPmessage, it extracts the parameters and sends a BYE to close the conversation.

Amplification attack

The amplification attack, explained in Section 3.1.2, could tear down any SIP proxythat does not have the protection against it. A simple python script has been writtenwhich, given the information about the users and the servers, will send the messages tostart the amplification loop.

6.2 Test of Kamailio

Many people use Kamailio as a SBC. One could argue whether Kamailio is a trueSBC or not. In fact it does not act like a B2BUA with a different call on each side ofit. Nevertheless, it supports a lot of features expected from a SBC like NAT traversal,topology hiding or SIP header modification. Kamailio has more than 200 modules, makingof it a very efficient SIP toolbox. I have not identified an open source SBC project. Ifsomeone wants a free SBC, he has to configure a SIP proxy like Kamailio or FreeSwitchto act like a SBC, even if it is not its first goal. Kamailio is one the most flexible freeSIP tools available. It is one of the two forks of the OpenSER project with OpenSIPS.However Kamailio is more used than OpenSIPS and the community is more active withit. This explains why Kamailio is sometimes chosen and configured as a SBC.

6.2.1 Test environment

The equipment available for the environment is composed of two computers, a CiscoSwitch and two IP Phones. On each computer, virtual machines (VMs) have been createdto simulate several computers and servers:

• On the first computer, three Debian are running: two are used as softphone withEkiga [58] and the last one is used to launch ToIP attacks. The softphones have1GB of RAM and one core at 3.40GHhz as CPU and the attack VM has 16GB ofRAM with 8 cores at 3.40GHz as CPU.

• The second computer has been split into two systems, running on Debian again.The first contains an Asterisk instance and the second a Kamailio instance. Eachone has 3.5GB of RAM and 5 cores at 2GHz as CPU. Kamailio and Asterisk have

45

been built from the last stable release available on their repository ([63] and [64]),thus the version used is 4.3.4 for Kamailio and version 13.6.0 for Asterisk.

• Each VM has been configured in bridge mode to avoid NAT problems.

The architecture is shown below in Figure 17. Kamailio is in front of Asterisk and betweenAsterisk and the phones.

First, Asterisk has been configured with a basic configuration. One context has beencreated with a few users in it. The configuration files used for the experiment are showin Appendix C. Then Kamailio had to be put in front of Asterisk and both configuredin order that every packet going to Kamailio is transmitted to Asterisk that will respondto Kamailio. The final user must not see other IP address than the one of Kamailio andeverything, including the media flow, has to pass through Kamailio. To make Asteriskrespond to Kamailio, the field outboundproxy has been added in the Asterisk SIP con-figuration file. For Kamailio it was much more difficult and the routing logic has beenbuilt from scratch. When Kamailio receives a request from a phone, it changes the IPaddress putting the one of Asterisk and transmits it to Asterisk. On the other way, itdoes the opposite by replacing the IP address of Asterisk by its own. Using the t_relay()function makes Kamailio aware of the state of the calls instead of just using the statelessforward() function. This difference allows the use of more sophisticated function in theconfiguration, to manage the RTP session for example. The rtpengine module makes theRTP flow passes through Kamailio with a few changes in the configuration. In addition,the topoh module hides the contact and Via information when Kamailio responds to thephone, hiding totally the existence of Asterisk behind. The full configuration file is shownin Appendix B. Finally, the support of TLS and SRTP has been added by creating a CAand certificates for Asterisk, Kamailio and the two IP phones. Then, the configuration ofthe phones and servers have been adapted to support SIPS and SRTP. Calls with TLSand SRTP are possible with the IP phones or just with SIP and RTP with the softphones.This will allow a deeper test of the system to be done.

In addition, the few services that will be used by the IP phones for configuration(HTTP server for configuration files download and NTP server to set the time on thephone) have been configured on the VM containing Kamailio.

46

IP phone IP phone Softphone Softphone

Kamailio

Asterisk

Figure 17: Test environment of Kamailio

Every packet, SIP as RTP, will go to Asterisk through Kamailio and the response willbe sent back through Kamailio. The phones will never talk directly nor have knowledgeof its existence. Kamailio will see everything.

6.2.2 Results

Features implemented

Kamailio has a very flexible configuration that mixes parameters and scripting lan-guage syntax. Some features can be obtained just by setting parameters while othersrequire a complex script in the routing logic. Table 6 below shows the security featuresimplemented in Kamailio. A feature is considered as implemented only if no programmingis needed, except a few lines in the routing part, to make it work.

Feature Present CommentHigh frequency registration No Not implementedTopology hiding Yes With topoh moduleIdentity hiding Yes By rewriting the message pseudo-variables in

the routing logicEncryption with TLS Yes With TLS moduleConversion SIP ↔ SIPS Yes With t_relay functions in TM moduleEncryption with SRTP Yes With rtpengine moduleConversion RTP ↔ SRTP Yes With flags in rtpengine moduleForce the user of TLS Yes With t_relay functions in TM moduleChoose the right cipher Yes With cipher_list parameter of TLS moduleForce the TLS version Yes With tls_method parameter of TLS module

47

Remove UA SIP field Yes With server_header parameterRemove the UA SDP field Yes With textops moduleUser enumeration protection Partial Simple only if authentication by KamailioPassword cracking protection Yes With pike module to block IP addressesIllegitimate BYE protection No Not implementedDoS protection Partial With pike moduleCall Admission Control Partial Possible to implement a few parameters in

configurationSanitize SIP and SDP Yes Does not transmit if packet not understood,

more checks with sanitize moduleLoop amplification detection Partial Only check its address in Via headersHigh Availability Yes With VRRP protocol [65]Diversion protection Yes Using textops and sdpops modules with

comparisons in the routing logicBlacklisting Yes With userblacklist moduleRestrict external calls Yes With permissions modulePrevent call between users Yes With permissions moduleTranscoding No Not yet implemented in rtpengine

Table 6: Security features implemented in Kamailio

Fuzzing

To use AFL on Kamailio, the main.c file had to be modified to change its behavior. In-stead of launching Kamailio process, it had to take a file as input and use the receive_msgfunction on it. The receive_msg function in receive.c is the function called first when amessage is received. It parses the message before transmitting it to the other processes.During the modification, only the unnecessary parts had to be removed, keeping all theparts regarding the environment initialization. Once the new main is ready, Kamailiocan be compiled using the afl-gcc compiler that will add some instructions required byAFL. Some classical SIP messages have been given to AFL as input. Then, AFL has beenstarted in master/slave mode to use all the core of the computer and make the fuzzingfaster.

After several days of test, AFL found some interesting messages supposed to crash Ka-mailio. Unfortunately, trying them against a running implementation of Kamailio showedthat they were only false positive. The test could be extended by adapting differently themain file or by doing it longer.

Flood

The SIP DoS script has been launched on the attack VM with Kamailio as the target.In order to test different attack intensities, the number of messages sent by second hasbeen varied. For each test, the RAM and CPU usages have been measured, as well as thenumber of message transmitted, the number of response sent back and if it was possibleto establish a call during the attack. The attacks last 60 seconds to gather enough data

48

to make the average. The CPU and RAM usages have been recorded every second duringthe attack to to average at the end. The results are shown in Table 7 and in Figure 18.

INVITE/s % CPU % RAM Transmitted Answered Call Call quality105 910 73.6 23.7 1.84% 0.23% No83 110 61.2 15.8 0.00095% 0.59% No65 990 78.6 17.4 0.00075% 3.77% No46 095 77.8 16.8 0.00090% 5.33% No26 760 63.2 16.6 0.0014% 7.75% No9 960 34.7 15.7 0.0049% 6.87% No5 050 52.99 16.0 0.0085% 31.6% No2 560 57.6 16.3 0.017% 40.6% Yes Perfect1 310 30.3 15.6 0.038% 31.0% Yes Perfect525 19.8 15.6 0.097% 34.5% Yes Perfect270 12.5 15.6 0.18% 41.3% Yes Perfect91 5.5 15.6 0.53% 100% Yes Perfect

Table 7: Kamailio DoS results

Figure 18: CPU and RAM usages versus message intensity during DoS attacks

First the results are not linear. One possible explanation is that Kamailio, dependingon the message intensity, launches some processes or not for the message, involving moreor less resources. Furthermore, the memory consumption remains the same during thewhole test regardless on the number of message received. In addition, looking at a pcaptrace, Kamailio seems to believe that the new INVITE messages are actually the old ones

49

and thus resent the same messages from Asterisk instead of transmitting them to Asteriskagain. A possible reason is that the IP addresses and the users in the INVITE are thesame and it explains why the transmitted rate remains low contrary to the answered rate.

Nevertheless, Kamailio has never reached 100% CPU usage and thus has never blockedthe whole system. The SIP services were down sometimes, but the other services runningon the server were still up. The media gateway process is handled by rtpengine binaryand not Kamailio. Thus the RTP flow continued to pass through the server even if nonew call could be established. Unfortunately, these results also show that an attackerdoes not need to have a huge botnet, nor computing power, to successfully prevent newcall from being established. Mainly because Kamailio has no specific mechanism againstit.

TLS

Kamailio TLS implementation is based on the OpenSSL package [66] which is themost used open-source implementation of the TLS protocol. Thus the vulnerabilities ofKamailio are the same as the OpenSSL ones. The choice of using a known cryptographiclibrary is a good idea because it avoids to build a new stack, and so limits the vulnerabilityrisks inherent in development. However, history has shown that vulnerabilities are stillpossible and several have been discovered the past few years [67]. The TLS vulnerabilitiesin Kamailio depends on the OpenSSL version used, the code in the TLS module and theconfiguration made by the administrator. In the test environment, the version of OpenSSLused is 1.0.1k from the Debian official packages. Asterisk works the same way as Kamailiowith TLS.

However, issues regarding the implementation of TLS in the phones were encountered.In fact they use an old custom version of OpenSSL with only a few ciphers available.From these ciphers, there are poor ones using:

• a anonymous Diffie-Hellman which is subject to MITM attacks [68]

• an export key which is by design short and can be broken easily [69]

• DES which uses only a 56-bit key [70]

• RC4 which is not considered as secured anymore and has been removed fromOpenSSL [71]

After removing the ciphers using them, only three ciphers remains that can be used.However, if a Diffie-Hellman key exchange protocol is chosen, the key generated by thephones will be too short and refused by the OpenSSL version of Kamailio because ofthis vulnerability discovered recently [72]. Thus, those ciphers can be removed and itremains only one cipher : TLS_RSA_WITH_AES_128_CBC_SHA. This cipher doesnot provide forward secrecy, which means that a leak of the private key compromises allthe previous TLS sessions. So, in the end, the problem with the infrastructure did notcome from the SBC but from the phones themselves. In a TLS exchange, this is the serverwhich decides and Kamailio has an option to choose the cipher suites that must be used.This is why having a good TLS implementation on the SBC is important.

50

Common attacks

As described in Section 6.2.2, Kamailio can protect the system from some attacks. Ifonly TLS and SRTP are used, some of these attacks are blocked but here the suppositionwill be made that the system works without any encryption. It could happen for externalcalls for example.

First, the user enumeration technique has been tried to discover the extensions onAsterisk. Asterisk has been configured not to provide protection against this attack, tolet Kamailio operate. The script has successfully detected all the Asterisk users. In factKamailio can protect the system against this, but only if it manages itself the authenti-cation. In this case, it will ask for the authentication before sending any indication in theresponse. If the authentication is managed by something else, like Asterisk, it cannot stopthe information leak from Asterisk easily. Maybe it is possible to do it in the configurationusing a small script. However, in this case, Asterisk has the option alwaysauthreject thatcan be set to Yes to make Asterisk behave like Kamailio, asking for the authenticationbefore. Secondly, the secret brute-force script has been launched with REGISTER tofind some passwords. If the pike module has been activated in Kamailio, the number ofmessages per extension per unit of time can be limited and an attacker will be blockedif he reaches the limit. As the attacker cannot spoof his IP address in this attack, thisprotection is efficient and is able to protect the system.

Then, the banner grabbing script has been executed to gather some information aboutthe system. The use of the server_header parameter and the textops module preventevery information to pass through. Thus, the script gathered no real information aboutthe system and it remains as a black box for the attacker.

The effect of the amplification attack is limited by the timeout parameters that Ka-mailio set for each request. However, the attack generates almost 300 000 SIP messagesbetween the two Kamailio proxies and thus can be used against Kamailio.

Finally, no protection against illegitimate BYE or steganography are implemented inKamailio so these attacks are possible without any restriction.

6.2.3 Conclusion

The previous parts have shown that Kamailio can offer a lot of features in differentdomains. Its domain of application remains in the comprehension of the SIP protocoland almost everything can be done regarding the SIP messages. It has also shown a goodresistance to fuzzing. However, it has not been conceived as a SBC, and thus does not offersome features that could be needed like transcoding or a more advanced DoS protection.Nevertheless, it can be enough for most of the companies if the ToIP administrators arewilling to spend enough time on the configuration.

51

7 Improvements

The two previous parts have shown the weaknesses of Kamailio and the features miss-ing in it. Several companies use Kamailio as a SBC because it is the open-source tool thatachieves most of the SBC expectation because of its flexibility. Thus, this is logically thesoftware we have chosen. From what could be implemented, the choice has been made tofocus the work on toll fraud because it is one of the major ToIP risk for companies. Thework on Kamailio has been divided on active and passive measures. For the active side,the permissions module of Kamailio has been improved to add the possibility of spec-ifying validity periods in rules. Then for the active side, a program to detect suspiciouscalls in a ToIP network based on log analysis has been written.

7.1 Permissions module

Kamailio has already a very old module to set up permissions between users to indicateif an employee has the right to call another employee [73]. Two files are needed, one todeny and the other to allow. In each file, rules can be set up with regular expressionsusing the syntax:

from_list [EXCEPT from_list] : req_uri_list [EXCEPT req_uri_list]

For example: “^sip:3677[0-9]” : “^sip:361[0-9]”. When a call is received, the sys-tem will look at the allow file to see if it matches one rule. If there is a match the call isthen allowed. Otherwise, it opens the deny file looking for a match. In case of a match,the call is not allowed.

However, this module can be improved to add more flexibility in the rules. It couldbe useful for some users, like companies, to specify a specific time for each rule. Forexample, a company could want to disable the possibility to call international numbersafter working hours, while keeping the possibility to call managers and colleagues. It willreduce the possibility of toll fraud during the night. Right now this is not possible to addsuch a rule in Kamailio, or at least not easily.

7.1.1 Logic

The best way to do it, was to start from the permissions module and to add thefeature in top of it. The new format of rules must be compatible with the old one to avoidtroubles during Kamailio upgrade. This syntax satisfies these requirements:

from_list [EXCEPT from_list] : req_uri_list [EXCEPT req_uri_list] :time_recurrence

If no time_recurrence parameter is specified and the rule uses the same syntax as before,the system will have to consider the rule as valid permanently. If a correct time recurrenceparameter is given, the rule will be valid only during the specified period. A syntax forthe time recurrence parameter has to be chosen. In the core of Kamailio there is alreadya library to specify time recurrence rules following the RFC 5545 [74].

52

The RFC 5545 defines a standard to share calendar data, named iCalendar. Thisstandard is used by many products like Google Calendar, Apple Calendar or Thunderbird.Among others, it gives a syntax to define recurrence rules. The library in Kamailio usesthis syntax which is almost the one in the RFC:

[startdate]|[duration]|[frequency]|[until]|[interval]|[byday]|[bymonthday]|[byyearday]|[byweekno]|[bymonth]

It is based on the part 3.3.10 of the RFC with the addition of a parameter duration de-fined in the part 3.3.6 of the RFC. In fact, the other parameters indicate an event with itsrepetition over time whereas the duration indicates how much time the event will stand.Of course, the duration must be shorter than the next repetition of the event. For ex-ample 20151006T103000|PT2H30M|weekly|20161006T103000|2|SA,SU defines arule from the 6th of October 2015 to the 6th of October 2016, one week out of two, theSaturday and Sunday, starting at 10:30 and during 2 hours 30 minutes.

7.1.2 Implementation

Kamailio is written in C for all parts. The module has two files of interest here,parse_config.c to parse the rule files and create the associated rules into the system, andrules.c to find a match among the rules. First, the structure of a rule in rules.h waschanged to include the new time recurrence parameter. Then, the parse_config.c wasmodified following the new rule syntax. The tmrec library was used to create the timerule from the string. To finish, the rules.c file was modified to add the comparison betweenthe time of the call and the time recurrence parameter during the research of a matchingrule. To achieve it, the functions included in the tmrec library were very useful.

Once the implementation is finished the module can be compiled and added intoKamailio, adapting the configuration file to include it. Two softphones has been configuredwith different users to test the accuracy of the rules defined in the files. As the mainmechanism of this improvement is the parsing of the recurrence rule, which relies uponexisting code, the tests were quite fast.

7.2 CDR analysis

In addition to the use of strict rules, for example with the permissions module above,the system can have a tool to analyze the call afterwards and to detect anomalies. Mostof the SBCs can produce Call Detail Records (CDRs) directly into a file or a database.The CDRs allow the administrators to keep an eye on the calls. As a border element, theSBC logs all the calls coming from the ToIP network without missing one. Once all thestatistics have been gathered, data analysis can be done to detect fraud and raise alerts.The objective is to ease the CDR analysis from the administrators by creating detectionalgorithms.

7.2.1 Logic

The idea is to cover the CDRs one by one, doing tests to classify each one. First,strict rules can be applied to classify a CDR. For example, too long calls can be loggedas well as the calls to premium numbers, the calls to dangerous international destinations

53

or just international destinations. Then, rules applying on the whole set of CDRs can beset. For example, if two calls from the same user have exactly the same duration, this isdoubtful and might indicates that the calls are automatically made. If a user makes toomany phone calls in a small time interval this can be considered as suspicious too.

In addition to these rules, the system can try to detect deviation of behavior for anemployee by using machine learning techniques. It has been showed that it was possible tobuild a profile for each employee and then quantify the deviation to compare it with a limit[75] [76]. They achieve a True Positive Ratio (TPR) of 90.23% and a False Positive Ratio(FPR) of 1.87%. These are quite good results and these works will be the foundations ofthe algorithm used by our system.

Make profiles

First, a user profile has to be defined. This tool will be used inside a company, thussome parameters will not be as pertinent outside this context. For a user, the averagenumber of calls per working hour, the mean duration, the percentage of calls made duringwork time, the percentage of calls made to international and the number of calls towardeach number will be kept. When a call is received, the program computes a coefficient forthe call based on what it knows for this user. For example, if a user, who has never madeinternational calls, starts calling someone in another country for 45 minutes at midnight,the system has to detect it. If the employee making the call is used to do calls like thisone, maybe it is a regular call and it does not have to raise an alert.

Now that the user profiles have been defined, the calls that will be added to this user’sprofile have to be detailed. The first idea is to learn, at the beginning, during a certainamount of time, and then to consider that enough data have been gathered to build theprofile of each user. The main problem with this technique is that it only learns at thebeginning. If an employee changes his behavior, because he is now working on somethingelse, his profile won’t be updated in consequence. To have an adaptive profile maker, thesystem has to learn from every call it receives. Learning from the new calls, it will seesuch changes of behavior. But still one problem remains: if the user changes its behavior,the old calls will still have an influence on the data. The best way will be to have amoving learning period. The system learns on a given time period and then it will move,removing from the data the old calls that are not in the learning period anymore andlearning from the new calls. The figure 19 illustrates the process. The learning periodmoves following the new calls.

The learning process has to be modified to take care of the users that take holidaysand are not here for a long time. When they will come back, there profile will be emptyand the system will have to wait again to fill the profiles and during this period it won’tdetect a thing. A minimal number of calls in the learning data can be set to addressthis issue. When a call has to be removed, because it is older than the beginning of themoving learning period, the program checks if there are still enough calls in the data, andif not, it keeps the call even though it should be deleted.

54

PresentTime

Past

Learning period

Figure 19: Learning period in time

Coefficient computation

The coefficient will be a multiplication of terms that will be computed depending onthe user profile. The multiplication in the process, instead of an addition [75], allows eachterm to have an impact depending on how strange the call is. For example, the term forthe international calls has to be greater for someone who never makes international callsthan for someone who is used to. The coefficient will be A ∗ B ∗ C ∗ D where A is theterm for the duration of the call, B the term for the hour of the call, C the term for theinternational calls and D the term for the call frequency. In each term, a dimensioningparameter Ki will be used.

For A this formula will be used:{A = K1 ∗ log2( duration

mean duration+ 1) if duration ≥ mean duration

A = K1 ∗ log2(mean durationduration

+ 1) if duration < mean duration

where duration is the duration of the current call and mean duration is the mean durationof the calls of this user. A log is used to avoid that this term gets a too important valuein case of a very long or very short call. The addition in the log is to avoid that the termapproaches 0 too closely.

For B and C these formulas will be used:{B = K2 ∗ (( 1

K2− a) ∗ rate_off_hour + a) if call not during working time, 1 otherwise

C = K3 ∗ (( 1K3− a) ∗ rate_international + a) if call is international, 1 otherwise

where rate_off_hour is the percentage of calls made by the user outside working hoursand rate_international is the percentage of calls made by the user to international des-tinations. A linear function has been chosen for these terms. If the call is very differentfrom the behavior of the user, the associate term can be up to three times. For example,if a user makes an international call for the first time (rate_international ' 0), B willbe three times greater than for a user who makes only international calls.

For D, the formula D = K4 ∗ log2( nb_calls

nb_calls_dest) will be used where nb_calls is the

total number of calls made by the user and nb_calls_dest is the number of calls madeby the user towards the destination of the current call. This coefficient is greater if theproportion of calls made towards the destination is small. Thus, it indicates that a callmade toward a new destination is more suspicious that a call made toward a colleaguethe employee is used to call.

55

At the end, the coefficient is compared to a limit. If it is greater than the limit itraises an alert, does not add the call to the profile of the user, and finally passes to thenext CDR.

7.2.2 Implementation

For the implementation, Python has been used. It is not the fastest programminglanguage but still it shows good performances and allows me to program quickly. As thealgorithm was still uncertain at the beginning, it was useful to be able to modify it rapidlyto see the results. It can be run into any server because it just needs the CDRs providedby a SBC or an IPBX. Nevertheless, if it needs to be integrated directly into an existingsoftware, it can be adapted into the software language.

The program is composed of two classes: the User class which contains the user profilesand the CDR class which contains the attributes of the Call. A CDR belongs to a userwhereas a user can have several CDRs with the relation types belong to and learning forthe CDRs in the learning period of the user. The User class has several methods, includingone method to update the CDRs in its learning period, and one method to update theprofile characteristics based on the CDR in the learning period.

When a call is received, a first test is made with the strict rules about the too longcalls, the destination or if the call has the same duration than another call in the learningperiod. After that, if the call passed these tests, the machine learning algorithm above isexecuted. Then, the CDRs in the learning period are updated and this CDR is added ifit is not suspicious. Finally, the user profile is recomputed. All the suspicious calls arekept and the program writes them into a log file with the reason of there guiltiness.

7.2.3 Tests

The algorithm has several undetermined coefficients that have to be dimensioned first.The problem remains that, to dimension them, a test set of CDRs composed of knownfraudulent calls is needed. Then, the program is launched over this test set and computesthe TPR and the FPR to measure the efficiency of the algorithm for a given set of pa-rameters. Unfortunately, CDRs are very sensitive data not easily findable on the Internetand I did not find any source. Thus, I tried to generate them myself.

Test set creation

A Python tool has been written to create users with different profiles and CDR ac-cording to these profiles. A user profile is first composed of a set of other users who are the“friends” of this user. These friends are the ones this user calls. To be realistic, it was notpossible just to choose a random recipient for each call because a user often calls the samepeople. The profile is also composed of probabilities to call international destinations, tocall during working hour, to make calls during weekends, the mean duration and the meanexcess (standard deviation) of the calls. For the recipient, one of the user’s friend is takenconsidering the probability of international calls. For the hour of the day, a Gaussiancentered on 15:00 with a sigma of 5:00 has been chosen. A value in working hours is takendepending on the probability given in the user profile, the day of the week being chosenwith the weekend probability of this user. For the duration, a chi squared distribution

56

has been considered. Such a distribution reflects the way calls are made: a lot of callscentered from 0 to twice the average deviation with a few longer calls still possible. TheGaussian could not be used because it was possible to have negative values, it was toomuch centered (more calls with a small duration are needed) and the probability to havea very long call was too small. Figure 20 shows a spider diagram of the profile of one userin the test set. The hour distribution is shown in Figure 21 with the reference Gaussianin green.

Once these “real CDRs” have been created, fake ones can be generated into them.For the fake ones, unusual properties are chosen: an unusual duration, an internationaldestination from the whole phone numbers set if the user makes more local calls (a localdestination in the opposite case) and the same to know if the call is made during workinghours or not. Then, all these fake CDRs are added into the list, and their “IDs” are keptin a separate file.

Figure 20: Example of a user profile

57

Figure 21: Call hour distribution for a user

Dimensioning

Now that the training set is ready, the goal is to find the best parameters for thealgorithm. To do so, the program will be run with parameter values and the FPR andTPR will be computed. The parameters that gave us the best results will be the betterones. Unfortunately, the program takes several minutes to process and it has at least 6parameters, so every possibilities cannot be tested. The time complexity of the operationwill be in power of 6 so a different technique has to be applied. As it was not the subjectof this whole master thesis, values giving good results will be considered as satisfying,even though they are not the optimal ones. If someone wants to implement this methodin its product, he will have to test if these values are still good in his case.

In order to find these values, a step by step process will be applied. At the first step,very different values for each parameter will be chosen. After this first computation,the program is launched again around the values that gave the best results before. Thesame process is repeated until satisfactory results are achieved. After several days ofcomputation, the following interesting results have been obtained:

K1 K2 K3 K4 a limit TPR FPR0.4 1.0 0.6 0.6 3 3.7 0.688 0.0460.3 0.7 0.5 0.6 3 3.5 0.539 0.0050.3 0.7 0.5 0.5 3 3.5 0.363 0.001

Table 8: FPR and TPR results

These results are satisfactory. The second line means that the program can detectmore than half fake calls while raising only one false alert every 200 regular calls. Of

58

course, along with more fake calls detected, the program will also have more false posi-tive. The Receiver Operating Characteristic (ROC curve) below in Figure 22 illustratesthe performance of the call classifier by representing the TPR and FPR for numerousparameters values. It shows that, for a few fake calls (almost 20%), the algorithm cannottell if they are fake or not. The algorithm is not adapted to detect them.

Figure 22: Receiver Operating Characteristic for the call classifier

The parameters can be chosen depending on the FPR and TPR required. Maybe asingle suspicious call cannot be missed and then a high TPR will be chosen, even thoughthe FPR could be higher. On the contrary, if the the administrator does not want tospend time on false positive alerts, a smaller FPR will be chosen along with a smallerTPR. These results seems good, however the tests was performed on generated CDRs andthis is the main limitation of these tests. This algorithm has to be confronted with realdata from companies to be improved.

59

8 Conclusion and future work

8.1 Accomplished work

In this thesis, a study of the security threats affecting a ToIP architecture have beendescribed and the Session Border Controller has been presented and characterized, basedon the responses to these vulnerabilities. First, its features have been described, based onthe vendors data sheets and original ideas. Then, its integration within a ToIP architecturehas been discussed in regards of the security requirements and a new proposition of designhas been proposed. A test protocol has been introduced and several tools have beendeveloped. It included a DoS program, and scripts to exploit common SIP vulnerabilities.The methodology has then been applied on the free software Kamailio. Kamailio has beenfirst configured as a SBC and integrated with Asterisk in a test environment. This modelwas new and can be reused in a company architecture. The tests have shown the qualityof Kamailio and how it can be improved.

From these possible improvements, two have been implemented. First, the possibilityof adding a time parameter in call permission rules has been added in the permissionsKamailio module. An administrator has now the ability to prevent calls between numbersbased on the time of day. Secondly, a threat detection tool has been written in Pythonto read the call logs produced by the SBC and raise alert in case of a suspicious call. Itis based on a machine learning algorithm that builds a profile for each user and then usesthis profile to detect behavior deviations in new calls. The tests have been conducted ongenerated data and have achieved good ratios (TPR at 0.69 with FPR at 0.046).

8.2 SBC conception

To finish this study on the SBC, a discussion can be started about the correct wayto conceive one. The SBC sees everything, signalization messages as media flows. If anattacker gains access to the administration interface, he will be able to use some regularfeatures to record calls, redirect them, or even establish calls. If he gains access to thewhole system with a root shell by finding vulnerabilities, he will be able to execute hisown scripts, and do everything he wants on ToIP with almost no limitation. As the SBCis the security device in the ToIP architecture, no other system could detect nor preventthe effects of such attack. Thus, the SBC is a very critical device and therefore needsparticular attention about security.

First, the hardware side can be examined. The SBC can be a specific device or animage that can be launched on a virtualization server. With a specific device, somefeatures can be done more efficiently like transcoding or DoS protection because they canrely on dedicated hardware instead of just the processor. However this configuration willbe at the same time less flexible than a virtual machine, and it will be harder and moreexpensive to achieve redundancy. The choice depends on each situation and on the needsof the client.

In addition, hardening must be done to reduce the surface of vulnerability. Thevendor can close the unused network ports or parameter strict rules in the firewall. Theadministration interface must be reachable through a separate dedicated network.

During the development, the software must be securely designed to reduce the impact

60

of a bug. A privilege separation model can be applied by separating the key SBC actionsbetween them. For example, the TLS part manages the private keys and thus is criticalfor confidentiality. A bug in a vulnerable element, like SIP parsing, must not lead toa private key leak. The same separation has to be applied between the most criticalelements of the SBC and for each part privileges have to be carefully chosen.

8.3 Future work

Even if Kamailio has been configured to work as a SBC, it was not really thoughtfor that and a few key features are missing. It goes from security features (CAC, loopamplification protection or DoS protection) or internetworking features (high frequencyregistration, protocol conversion) to media features (recording and transcoding). Imple-menting them requires a full knowledge of Kamailio internal structure and thus takestime. Once these features will be implemented, and the configuration eased, Kamailiowill be a real competitor to proprietary solutions.

The existing tools didn’t allow to perform all the proposed tests, thus I have writtennew attack scripts. Some are new while others bring new features to existing attacks.These scripts could be gathered in the same python program to simplify their use.

The work about threat detection using CDRs can be improved by using real data asinput to dimension the coefficients. Such data can only be obtained by a service providerand are the only way to really test the program. This way, its quality could be proven,and improvements may be found.

61

References

[1] R. Frederick V. Jacobson H. Schulzrinne, S. Casner. RFC 3550: RTP: A TransportProtocol for Real-Time Applications. 2003.

[2] A. Hawrylyshen B. Campen R. Sparks, S. Lawrence. RFC 5393: Addressing an Am-plification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies. 2008.

[3] Skype statistics. http://blogs.skype.com/2013/08/28/skype-celebrates-a-decade-of-meaningful-conversations/. Accessed: 2015-12-14.

[4] Instat. http://www.instat.com/. Accessed: 2015-12-16.

[5] Infonetics. http://www.infonetics.com/pr/2015/VoIP-UC-Services-Subs-Market-Highlights.asp. Accessed: 2016-01-06.

[6] Nettitude. VOIP Attacks On The Rise. 2015.

[7] Kamailio. http://www.kamailio.org/w/. Accessed: 2015-11-30.

[8] J. Kuthan U. Abend H. Schulzrinne D. Sisalem, J. Floroiu. SIP Security. Wiley,2009.

[9] G. Camarillo A. Johnston J. Peterson R. Sparks M. Handley J. Rosenberg,H. Schulzrinne and E. Schooler. RFC 3261: SIP: Session Initiation Protocol. 2002.

[10] SIP header fields. http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-2. Accessed: 2015-11-25.

[11] Asterisk. http://www.asterisk.org/. Accessed: 2015-11-30.

[12] Freeswitch. https://freeswitch.org/. Accessed: 2015-11-30.

[13] A. M. Hagalisletto and L. Strand. Formal modeling of authentication in SIP regis-tration. 2008.

[14] L. Strand and W. Leister. Improving SIP authentication. 2011.

[15] C. Jennings J. Peterson. RFC 4474: Enhancements for Authenticated Identity Man-agement in the Session Initiation Protocol (SIP). 2006.

[16] A. Jeffrey V. Gurbani. RFC 5922: Domain Certificates in the Session InitiationProtocol (SIP). 2010.

[17] M. Naslund E. Carrara K. Norrman M. Baugher, D. McGrew. RFC 3711: The SecureReal-time Transport Protocol (SRTP). 2004.

[18] J. Callas P. Zimmermann, A. Johnston. RFC 6189: ZRTP: Media Path Key Agree-ment for Unicast Secure RTP. 2004.

[19] F. Lindholm M. Naslund K. Norrman J. Arkko, E. Carrara. RFC 3830: MIKEY:Multimedia Internet KEYing. 2004.

62

[20] E. Rescorla B. Desruisseaux. RFC 5764: Datagram Transport Layer Security (DTLS)Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP).2010.

[21] D. Wing F. Andreasen, M. Baugher. RFC 4568: Session Description Protocol (SDP)Security Descriptions for Media Streams. 2006.

[22] C. Perkins M. Handley, V. Jacobson. RFC 4566: SDP: Session Description Protocol.2006.

[23] Skype. http://www.skype.com/fr/. Accessed: 2015-12-01.

[24] TeamSpeak. https://www.teamspeak.com/. Accessed: 2015-12-01.

[25] Jingle. http://xmpp.org/about-xmpp/technology-overview/jingle/. Accessed:2015-12-02.

[26] E. Guy F. Miller K. Shumard M. Spencer, B. Capouch. RFC 5456: IAX: Inter-Asterisk eXchange Version 2. 2010.

[27] Communications Fraud Control Association (CFCA). 2015 Global Fraud Loss Sur-vey. 2015.

[28] C. Jennings J. Rosenberg. RFC 5039:The Session Initiation Protocol (SIP) and Spam.2008.

[29] M. Collier and D. Endler. Hacking Exposed Unified Communications & VoIP: Secu-rity Secrets & Solutions. McGraw-Hill Osborne, 2014.

[30] M. Farooq Z. Rafique, A. Akbar. Evaluating DoS Attacks Against SIP-Based VoIPSystems. 2009.

[31] Eric Y. Chen and Mitsutaka Itoh. Scalable Detection of SIP Fuzzing Attacks. 2008.

[32] Wojciech Mazurczyk. VoIP Steganography and Its Detection – A Survey. 2013.

[33] VoIP Hopper. http://voiphopper.sourceforge.net/. Accessed: 2015-12-04.

[34] Vulnerabilities in Cisco IP phones. http://engineering.columbia.edu/seas-computer-scientists-find-vulnerabilities-cisco-voip-phones. Accessed:2015-12-07.

[35] M. Ali Akbar M. Zubair Rafique and Muddassar Farooq. Evaluating DoS AttacksAgainst SIP-Based VoIP Systems. 2009.

[36] SBC market growth. http://www.infonetics.com/pr/2015/4Q14-Enterprise-Session-Border-Controllers-Market-Highlights.asp. Accessed: 2015-12-07.

[37] SBC market statistics. http://www.infonetics.com/pr/2014/2Q14-Enterprise-Session-Border-Controllers-Market-Highlights.asp. Accessed: 2015-12-07.

[38] P. Matthews D. Wing J. Rosenberg, R. Mahy. RFC 5389: Session Traversal Utilitiesfor NAT (STUN). 2008.

63

[39] J. Rosenberg R. Mahy, P. Matthews. RFC 5766: Traversal Using Relays around NAT(TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN). 2010.

[40] J. Rosenberg. RFC 5245: Interactive Connectivity Establishment (ICE): A Protocolfor Network Address Translator (NAT) Traversal for Offer/Answer Protocols. 2010.

[41] Answer-seizure ratio. http://www.markholloway.com/blog/?p=1709. Accessed:2016-01-19.

[42] Call recording with SIPREC. https://andrewjprokop.wordpress.com/2014/02/26/call-recording-with-siprec/. Accessed: 2016-02-01.

[43] C. Eckel A. Johnston A. Hutton L. Portman, H. Lum. Session Recording Protocol.2015.

[44] Understanding SIP DTMF Options supported by CUCM. https://supportforums.cisco.com/blog/154706. Accessed: 2016-02-01.

[45] M. Murray K. Claffy R. Prasad, C. Dovrolis. Bandwidth Estimation: Metrics, Mea-surement Techniques, and Tools. 2003.

[46] Echo suppression and cancellation. https://en.wikipedia.org/wiki/Echo_suppression_and_cancellation. Accessed: 2016-02-01.

[47] H.S. Jamadagni M.C Chiranth R. Sah R. Prasad, A. Sangwan and V. Gaurav. Com-parison of Voice Activity Detection Algorithms for VoIP. 2002.

[48] Comfort noise. https://en.wikipedia.org/wiki/Comfort_noise. Accessed: 2016-02-01.

[49] Patrick Park. Voice over IP Security: Security best practices derived from deepanalysis of the lastest VoIP network threats. Cisco Press, 2009.

[50] A. H. Kaplan, V. Pascual. RFC 7332: Loop Detection Mechanisms for SessionInitiation Protocol (SIP) Back-to-Back User Agents (B2BUAs). 2014.

[51] Jana Dittmann Christian Kraetzer. Mel-Cepstrum Based Steganalysis for VoIP-Steganography. 2007.

[52] Private VLAN. https://en.wikipedia.org/wiki/Private_VLAN. Accessed: 2016-02-01.

[53] PROTOS. https://www.ee.oulu.fi/research/ouspg/PROTOS_Test-Suite_c07-sip. Accessed: 2015-11-25.

[54] VoIPER. http://voiper.sourceforge.net/. Accessed: 2015-11-25.

[55] AFL. http://lcamtuf.coredump.cx/afl/. Accessed: 2015-11-25.

[56] Preeny. https://github.com/zardus/preeny. Accessed: 2015-11-25.

[57] inviteflood. http://tools.kali.org/sniffingspoofing/inviteflood. Accessed:2016-01-20.

[58] Ekiga. http://ekiga.org/. Accessed: 2015-11-25.

64

[59] TLS Prober. https://github.com/WestpointLtd/tls_prober. Accessed: 2015-11-25.

[60] SSLScan. https://github.com/rbsec/sslscan. Accessed: 2016-01-20.

[61] SIPVicious. https://github.com/sandrogauci/sipvicious. Accessed: 2016-01-20.

[62] SIPcrack. http://manpages.ubuntu.com/manpages/natty/man1/sipcrack.1.html. Accessed: 2015-11-25.

[63] Kamailio repository. https://github.com/kamailio/kamailio. Accessed: 2015-12-22.

[64] Asterisk repository. https://gerrit.asterisk.org/. Accessed: 2015-12-22.

[65] VRRP with Kamailio. http://blog.unicsolution.com/2015/01/kamailio-high-availability-with.html. Accessed: 2016-01-20.

[66] OpenSSL. https://www.openssl.org/. Accessed: 2015-12-22.

[67] OpenSSL Vulnerabilities. https://www.openssl.org/news/vulnerabilities.html. Accessed: 2015-12-23.

[68] Anonymous Diffie-Hellman weakness. https://wiki.openssl.org/index.php/Diffie_Hellman. Accessed: 2016-01-20.

[69] Export keys weakness. https://en.wikipedia.org/wiki/FREAK. Accessed: 2016-01-20.

[70] Six ways to break DES. http://lasec.epfl.ch/memo/memo_des.shtml. Accessed:2016-01-20.

[71] Hacker Intelligence Initiative. Attacking SSL when using RC4. 2015.

[72] Z. Durumeric P. Gaudry M. Green J. Halderman N. Heninger D. Springall E.Thomé L. Valenta B. VanderSloot E. Wustrow S. Zanella-Béguelin P. ZimmermannD. Adrian, K. Bhargavan. Imperfect Forward Secrecy: How Diffie-Hellman Fails inPractice. 2015.

[73] Kamailio permissions module. http://kamailio.org/docs/modules/stable/modules/permissions.html. Accessed: 2015-11-30.

[74] D. McGrew. RFC 5545: Internet Calendaring and Scheduling Core Object Specifi-cation (iCalendar). 2009.

[75] T. Wiens A. Wiens and M. Massoth. A new Unsupervised User Profiling Approachfor Detecting Toll Fraud in VoIP Networks. 2014.

[76] T. Wiens A. Wiens and M. Massoth. Improvement of User Profiling, Call DestinationProfiling and Behavior Pattern Recognition Approaches for Telephony Toll FraudDetection. 2015.

65

A Loop amplification Attack

This attack has been described in details in RFC 5393 [2]. An attacker needs twoaccounts on two different registrars, for example a@R1, b@R1, a@R2, b@R2. Then hewill send the four REGISTER messages below in Figure 23.

REGISTER sip:P1 SIP/2.0To: <sip:a@P1>Contact: <sip:a@P2>, <sip:b@P2>

REGISTER sip:P1 SIP/2.0To: <sip:b@P1>Contact: <sip:a@P2>, <sip:b@P2>

REGISTER sip:P2 SIP/2.0To: <sip:a@P2>Contact: <sip:a@P1>, <sip:b@P1>

REGISTER sip:P2 SIP/2.0To: <sip:b@P2>Contact: <sip:a@P1>, <sip:b@P1>

Figure 23: REGISTER messages of a loop amplification attack

Once the REGISTER messages have been accepted the attacker will just send anINVITE message to one of the user, for example a@P1. It will fork the request into tworequests to a@P2 and b@P2 following the information given by the REGISTER messages.Then the call to a@P2 will be fork into two calls to a@P1 and b@P1 and the call to b@P2into a@P1 and b@P1. Then the process will continue and each step will double thenumber of messages between the two proxies until the Max-Forwards field reaches 0. Upto 271 messages can be generated from the single INVITE. The flow is shown below inFigure 24. The attack is difficult to setup because the attacker needs two accounts oneach server.

a@P1

a@P2 b@P2

a@P1 b@P1 a@P1b@P1

a@P2 b@P2 a@P2b@P2 a@P2b@P2a@P2 b@P2

Figure 24: Example of the flow of a SIP amplification attack from RFC 5393 [2]

66

B Kamailio configuration files

kamailio.cfg

#!KAMAILIO

####### Defined Values #########

#!define ASTERISK 192.0.2.42#!define WITH_TLS

####### Global Parameters #########

#!ifdef WITH_DEBUGdebug=4log_stderror=no#!elsedebug=2log_stderror=no#!endif

memdbg=5memlog=5log_facility=LOG_LOCAL0fork=yeschildren=2auto_aliases=noport=5060

####### Modules Section ########

mpath="/usr/local/lib/kamailio/modules"

loadmodule "tm.so"loadmodule "db_text.so"loadmodule "mi_fifo.so"loadmodule "kex.so"loadmodule "sl.so"loadmodule "rr.so"loadmodule "pv.so"loadmodule "maxfwd.so"loadmodule "textops.so"loadmodule "sdpops"loadmodule "siputils.so"loadmodule "xlog.so"loadmodule "sanity.so"loadmodule "ctl.so"loadmodule "cfg_rpc.so"loadmodule "mi_rpc.so"loadmodule "path.so"loadmodule "rtpengine.so"loadmodule "topoh"

#!ifdef WITH_DEBUGloadmodule "debugger.so"#!endif

67

# ----------------- setting module-specific parameters ---------------

modparam("mi_fifo", "fifo_name", "kamailio_fifo")

# add value to ;lr param to cope with most of the UAsmodparam("rr", "enable_full_lr", 1)# do not append from tag to the RR (no need for this script)modparam("rr", "append_fromtag", 0)modparam("path", "use_received", 1)

#Parameter for RTP Engine to do media gatewaymodparam("rtpengine", "rtpengine_sock", "udp:127.0.0.1:12221")

#Parameter for Topology hiding (to hide Asterisk)modparam("topoh", "mask_key", "hidenipbx")modparam("topoh", "mask_ip", "192.0.2.42")

#!ifdef WITH_TLSlisten=udp:192.0.2.42:5060listen=tls:192.0.2.42:5061enable_tls=yesloadmodule "tls.so"modparam("tls", "config", "tls.cfg")#!endif

#!ifdef WITH_DEBUG# ----- debugger params -----modparam("debugger", "cfgtrace", 1)#!endif

####### Routing Logic ########

route {

route(SBC_CHECK);

if (src_ip != ASTERISK){

# SIP request packet client->backendif ($op == 5061){

$du = "sips:192.0.2.43:5061";} else {

$du = "sip:192.0.2.43:5060";}add_path_received();route(RTPPROXY);

}else{

# SIP request packet backend->clientif ($op == 5061){

$fu = "sips:192.0.2.42:5061";} else {

$fu = "sip:192.0.2.42:5060";}

loose_route();route(RTPPROXY);

68

}t_relay();

}

#Check we want to do as a SBCroute[SBC_CHECK] {

#We check the fieldsif (!sanity_check()) {

exit;}

#We can add whatever check we want on the messages

return;}

route[RTPPROXY] {t_on_reply("1");rtpengine_manage("replace-origin");return;

}

#On the reponse messagesonreply_route[1] {

rtpengine_manage("replace-origin");return;

}

tls.cfg

[server:default]method = TLSv1verify_certificate = yesrequire_certificate = yesprivate_key = tls/key_kamailio.pemcertificate = tls/cert_kamailio.pemca_list = tls/CA.pem#The cipher list can be chosen depending on security policycipher_list = kRSA

[client:default]method = TLSv1verify_certificate = yesrequire_certificate = yesprivate_key = tls/key_kamailio.pemcertificate = tls/cert_kamailio.pemca_list = tls/CA.pem#The cipher list can be chosen depending on security policycipher_list = kRSA

69

C Asterisk configuration files

sip.conf

[general]outboundproxy = 192.0.2.42:5060defaultexpirey=1800dtmfmode=autoqualify=yesalwaysauthreject=yestlsenable=yestlsbindaddr=0.0.0.0tlscertfile=keys/asterisk.pemtlscafile=keys/ca.pemtlscipher=ALLtlsclientmethod=tlsv1

extensions.conf

[general]static=yeswriteprotect=noclearglobalvars=no

[Developper1]exten => _X.,1,Dial(SIP/${EXTEN}, 10)exten => _X.,20,Hangup()

[Developper2]exten => _X.,1,Dial(SIP/${EXTEN}, 10)exten => _X.,20,Hangup()

users.conf

[general]hasvoicemail = yeshassip = yeshasiax = yescallwaiting = yesthreewaycalling = yescallwaitingcallerid = yestransfer = yescanpark = yescancallforward = yescallreturn = yescallgroup = 1pickupgroup = 1

[Developper1]type=friendhost=dynamicdtmfmode=rfc2833disallow=allallow=alllanguage=frcontext = Developper1

70

[Developper2]type=friendhost=dynamicdtmfmode=rfc2833disallow=allallow=alllanguage=frcontext = Developper2transport=tls

[1100](Developper1)username=1100fullname = 1100secret=123456

[1101](Developper1)username=1101fullname = 1101secret=123456

[1200](Developper2)username=1200fullname = 1200secret=123456

[1201](Developper2)username=1201fullname = 1201secret=123456

71

TRITA TRITA-EE 2016:024

www.kth.se