These materials are 2016 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.

Transcription

1

2

3 Securing Real Time Communications Sonus Special Edition by Lawrence C. Miller and Walter Kenrich

4 Securing Real Time Communications For Dummies, Sonus Special Edition Published by John Wiley & Sons, Inc. 111 River St. Hoboken, NJ Copyright 2016 by John Wiley & Sons, Inc. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without the prior written permission of the Publisher. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) , fax (201) , or online at Trademarks: Wiley, For Dummies, the Dummies Man logo, The Dummies Way, Dummies.com, Making Everything Easier, and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries, and may not be used without written permission. Sonus and the Sonus logo are registered trademarks of Sonus. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc., is not associated with any product or vendor mentioned in this book. LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL WARRANTIES, INCLUDING WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE. NO WARRANTY MAY BE CREATED OR EXTENDED BY SALES OR PROMOTIONAL MATERIALS. THE ADVICE AND STRATEGIES CONTAINED HEREIN MAY NOT BE SUITABLE FOR EVERY SITUATION. THIS WORK IS SOLD WITH THE UNDERSTANDING THAT THE PUBLISHER IS NOT ENGAGED IN RENDERING LEGAL, ACCOUNTING, OR OTHER PROFESSIONAL SERVICES. IF PROFESSIONAL ASSISTANCE IS REQUIRED, THE SERVICES OF A COMPETENT PROFESSIONAL PERSON SHOULD BE SOUGHT. NEITHER THE PUBLISHER NOR THE AUTHOR SHALL BE LIABLE FOR DAMAGES ARISING HEREFROM. THE FACT THAT AN ORGANIZATION OR WEBSITE IS REFERRED TO IN THIS WORK AS A CITATION AND/OR A POTENTIAL SOURCE OF FURTHER INFORMATION DOES NOT MEAN THAT THE AUTHOR OR THE PUBLISHER ENDORSES THE INFORMATION THE ORGANIZATION OR WEBSITE MAY PROVIDE OR RECOMMENDATIONS IT MAY MAKE. FURTHER, READERS SHOULD BE AWARE THAT INTERNET WEBSITES LISTED IN THIS WORK MAY HAVE CHANGED OR DISAPPEARED BETWEEN WHEN THIS WORK WAS WRITTEN AND WHEN IT IS READ. For general information on our other products and services, or how to create a custom For Dummies book for your business or organization, please contact our Business Development Department in the U.S. at , contact info@dummies.biz, or visit For information about licensing the For Dummies brand for products or services, contact Branded Rights&Licenses@Wiley.com. ISBN: (pbk); ISBN: (ebk) Manufactured in the United States of America Publisher s Acknowledgments Some of the people who helped bring this book to market include the following: Project Editor: Carrie A. Burchfield Editorial Manager: Rev Mengle Acquisitions Editor: Katie Mohr Business Development Representative: Sue Blessing Production Editor: Siddique Shaik

5 Table of Contents Introduction... 1 About This Book... 1 Foolish Assumptions... 2 Icons Used in This Book... 2 Beyond the Book... 3 Where to Go from Here... 3 Chapter 1: Recognizing Current Trends in Real-Time Communications... 5 Shifting Business from Circuit-Switched Voice to SIP Communications... 5 Remote Worker Use Cases and BYOD Are Pervasive... 6 RTC Increases Productivity and Risk... 7 Chapter 2: Understanding the Threat Landscape in RTC... 9 RTC Attacks Are on the Rise... 9 RTC Threats Are Rapidly Evolving Denial of Service (DoS) Toll fraud Identity theft Exposing New Attack Vectors with RTC Linux and COTS Porous firewalls RTC traffic flows signaling and media Chapter 3: Securing Real-Time Communications Encrypting RTC Signaling and Media Complying with Regulatory Requirements Looking at the Cost of No Security In RTC Chapter 4: Understanding Why a Firewall Can t Secure RTC Understanding the Role of Firewalls and SBCs Comparing Firewalls and SBCs... 29

6 iv Securing Real-Time Communications For Dummies, Sonus Special Edition Chapter 5: Looking to the Future in Securing RTC New Strategic Approaches to RTC Security Are Needed Multi-layered Security in the Network Firewall and SBC sharing contextual awareness SDN to augment multi-layer security Chapter 6: Ten Ways SBCs Secure RTC B2BUA/Network Topology Hiding DoS and DDoS Defense (Policers) Encryption (Media) Encryption (Signaling) Toll Fraud Protection Malformed Packet Protection Call Admission Control/Overload Controls NAT Traversal (Remote Workers) Endpoint Registration Full SIP Session State Awareness... 44

7 Introduction Recent high profile cyberattacks have many organizations understandably focusing their security efforts on preventing data breaches. While ensuring data security is indeed a top priority, enterprises must not become complacent in securing their mission critical, real time communications (RTC) applications, systems, and networks including voice over IP (VoIP) and unified communications (UC) which can be directly targeted as an attack objective in itself, or to exploit a new attack vector into other applications, systems, and networks, in order to effect a data breach. With the convergence of data and telephony networks and the ubiquity of RTC (including VoIP, UC, and mobile phones), hacking has come full circle as telephony attacks are on the rise or, more correctly, re rise. As a consequence, enterprises must revisit their RTC security posture using a holistic approach, to ensure the integrity and availability of these applications and systems, as well as the confidentiality and privacy of sensitive data on converged networks and data center infrastructures. About This Book Securing Real Time Communications For Dummies, Sonus Special Edition, consists of six short chapters that explore Current trends in RTC, including the shift to session initiation protocol (SIP), enterprise mobility, and VoIP and UC (Chapter 1) The modern security threat landscape, specifically denial of service (DoS) and telephony denial of service (TDoS), toll fraud, identity fraud, and new attack vectors exposed by RTC (Chapter 2) How to secure RTC, including encrypting VoIP signaling and media, addressing specific security use case scenarios, understanding application reachability issues, and meeting regulatory compliance requirements (Chapter 3)

8 2 Securing Real-Time Communications For Dummies, Sonus Special Edition The differences between firewalls and session border controllers (SBCs) (Chapter 4) Emerging trends in securing RTC (Chapter 5) Key capabilities that an SBC brings to the fight in securing RTC (Chapter 6) Foolish Assumptions It s been said that most assumptions have outlived their uselessness, but I ll assume a few things nonetheless! Mainly, I assume that you are an IT security or network professional, such as an engineer, manager, decision influencer, or decision maker. As such, this book is written primarily for technical readers working for a large enterprise or service provider. If any of these assumptions describe you, then this book is for you! If none of these assumptions describe you, keep reading anyway. It s a great book, and when you finish reading it, you ll know enough about securing RTC to be dangerous! Icons Used in This Book Throughout this book, I occasionally use special icons to call attention to important information. Here s what to expect: This icon points out information that you should commit to your non volatile memory, your gray matter, or your noggin along with anniversaries and birthdays! You won t find a map of the human genome here, but if you seek to attain the seventh level of NERD vana, perk up! This icon explains the jargon beneath the jargon and is the stuff legends well, nerds are made of! Thank you for reading, hope you enjoy the book, please take care of your writers! Seriously, this icon points out helpful suggestions and useful nuggets of information.

9 Introduction 3 This icon points out the stuff your mother warned you about. Okay, probably not. But you should take heed nonetheless you might just save yourself some time and frustration! Beyond the Book There s only so much I can cover in 48 short pages, so if you find yourself at the end of this book, thinking gosh, this was an amazing book; where can I learn more? just go to Where to Go from Here With my apologies to Lewis Carroll, Alice, and the Cheshire cat: Would you tell me, please, which way I ought to go from here? That depends a good deal on where you want to get to, said the Cat err, the Dummies Man. I don t much care where..., said Alice. Then it doesn t matter which way you go! That s certainly true of Securing Real Time Communications For Dummies, Sonus Special Edition, which, like Alice in Wonderland, is also destined to become a timeless classic! If you don t know where you re going, any chapter will get you there but Chapter 1 might be a good place to start! However, if you see a particular topic that piques your interest, feel free to jump ahead to that chapter. Each chapter is written to stand on its own, so feel free to start reading anywhere and skip around to your heart s content! Read this book in any order that suits you (though I don t recommend upside down or backwards). I promise you won t get lost falling down the rabbit hole!

10 4 Securing Real-Time Communications For Dummies, Sonus Special Edition

11 Chapter 1 Recognizing Current Trends in Real Time Communications In This Chapter Evolving from legacy phone systems to SIP enabled telephony Enabling the digital workplace Addressing increased risk in RTC environments In this chapter, I describe some of the current trends in real time communications (RTC) and their security implications. Shifting Business from Circuit Switched Voice to SIP Communications For many decades, enterprise telephony systems were primarily comprised of legacy time division multiplexing (TDM), circuit switched private branch exchanges (PBXs). These monolithic systems were costly to acquire and maintain, often proprietary, difficult to scale, and compared to the features and functionality of modern RTC systems and applications provided little more than dial tone to a desk phone.

12 6 Securing Real-Time Communications For Dummies, Sonus Special Edition Many modern RTC systems use standard server and networking hardware components, are built on open source software, can be massively scaled with on premises, private and public cloud deployment options, and provide robust features and functionality, such as video and web conferencing, instant messaging, presence, unified messaging, collaboration tools, and mobility. Session initiation protocol (SIP) is a key enabling standard for RTC (see Figure 1 1). Over the past 20 years, SIP has matured considerably and has largely become the standard in service provider and enterprise communications networks. Figure 1-1: SIP enables new services and modalities for RTC and exposes new security risks. Today, enterprises have largely replaced their aging, legacy TDM switches with SIP enabled voice over IP (VoIP) and unified communications (UC) systems that provide unmatched business value, innovation, and flexibility in RTC. Remote Worker Use Cases and BYOD Are Pervasive The modern digital workplace is another key trend with several implications for RTC. As defined by Gartner, a digital workplace

13 Chapter 1: Recognizing Current Trends in Real Time Communications 7 Enables new and more effective ways of working: RTC enables geographically dispersed teams to communicate and collaborate more effectively with voice, video and web conferencing, instant messaging and more, from practically anywhere and on any device. Improves engagement and agility: The workplace has become decentralized, with employees increasingly working offsite rather than being tethered to a desk. For example, many employees now routinely work from home, in a vehicle, on an airplane, at a hotel or coffee shop, or while visiting a customer or client. This mobility improves enables greater responsiveness by keeping employees, partners, clients, and customers connected. Exploits consumer oriented styles and technologies: Bring your own device (BYOD) policies in which employees are permitted to use their personal mobile devices and installed apps for work related purposes have also become more common in the workplace. These personal technologies drive higher productivity by allowing employees to use the devices and apps they re most familiar with to get their work done more efficiently. Remote/mobile worker and BYOD scenarios provide one of the strongest use cases for RTC, allowing businesses to adopt virtual user models, optimize office space and be more responsive to customers. The challenge is to enable RTC in a secure environment. As endpoints, such as tablets and mobile phones, move farther from the core network, it becomes harder to control authorized access to the network. Additionally, a great deal of the RTC traffic traverses the public Internet, and is often accessed via unsecure public WiFi connections. Remote and mobile worker productivity is reliant on this access, but the associated security risks must be fully understood and properly addressed. RTC Increases Productivity and Risk There was a time when IT and security managers rarely lost sleep over the threat of a potential attack against their voice communications systems and networks, but the migration from legacy TDM to RTC systems and networks changed all

14 8 Securing Real-Time Communications For Dummies, Sonus Special Edition that. Today, attacks targeting RTC systems, networks, and applications are as real and increasingly prevalent as attacks targeting data systems, networks, and applications in the modern threat landscape. SIP enabled, IP based voice communications have ushered in a new era in RTC, enabling organizations to achieve significant benefits with converged voice and data networks, including Lower costs through lower CAPEX investment in data center and network infrastructure, as well as lower OPEX for recurring telco services Increased bandwidth capacity and higher utilization, resulting in better overall performance of voice and data networks However, as organizations move to RTC to realize benefits such as these, a new threat emerges: the introduction of IP based attacks, network intrusions, and information theft through RTC. The security stakes are especially high for enterprises, as compromised customer data can generate stiff penalties and losses totaling several millions of dollars. As enterprises implement and increasingly rely on RTC, they must also enforce RTC security. Enterprises must protect their network boundaries against internal security risks (for example, employees and partners) and external security threats and attacks (for example, cybercriminals). Enterprises must balance security requirements with realtime network performance to protect their systems and data.

15 Chapter 2 Understanding the Threat Landscape in RTC In This Chapter Recognizing threat actors and their tools and motivations Looking at evolving RTC threats Discovering new attack vectors in RTC This chapter explores the real time communications (RTC) threat landscape, including the different threat actors, the tools they use, and their motivations, as well as different RTC threats and new attack vectors introduced by RTC. RTC Attacks Are on the Rise The proliferation of enterprise RTC voice over IP (VoIP) and unified communications (UC) and the widespread and rapidly growing availability of surreptitious tools for intercepting IP packets and cracking code, make it increasingly easy for attackers to target RTC. For example, attackers can freely download network protocol analyzers to capture and interpret VoIP calls, record media streams, and intercept instant messaging (IM) communications. Other tools, such as UCSniff, can be used to identify, record, and replay VoIP conversations or IP videoconferencing sessions. SIP sniffing software is readily available on the Internet, which makes securing RTC particularly challenging.

16 10 Securing Real-Time Communications For Dummies, Sonus Special Edition The roster of potential attackers is expanding too. Organized criminal groups have found the Internet to be a profitable avenue from which to mount high tech fraud, identity theft, and extortion schemes. In fact, cybercrime has become so lucrative that a cottage industry of global hackers for hire selling their services on a contract basis has been created. Rogue nations are also increasingly involved in cyberespionage, cyberterrorism, and cyberattacks against defense, government, and private industry targets. Finally, hacktivists motivated by political or social causes often target high profile organizations. Denial of service (DoS) attacks, in particular, are a favorite tactic used by hacktivists to draw publicity and/or notoriety to their various causes. RTC Threats Are Rapidly Evolving There are many variants of RTC threats (see Figure 2 1); however, the most common threats for RTC attacks are as follows: Denial of service (DoS) attacks, including distributed denial of service (DDoS) and telephony denial of service (TDOS) Toll fraud, including number harvesting, spam over Internet telephony (SPIT), and spam over instant messaging (SPIM) Identity theft, including caller ID spoofing, eavesdropping, and call hijacking Call hijacking is another form of identity theft that can be used to redirect a call session or text message to a different number. In addition to call hijacking against organizations, individual users can be targeted. For example, call hijacking scenarios commonly redirect a call intended for the victim s bank to a criminal organization in order to fraudulently collect financial information.

17 Chapter 2: Understanding the Threat Landscape in RTC 11 Figure 2-1: RTC threats are rapidly evolving. Denial of Service (DoS) Denial of Service (DoS) attacks were virtually non existent in legacy circuit switched time division multiplexing (TDM) telephony systems, which operated as monolithic systems on isolated voice networks much like a castle protected by a moat and towering walls. However, as I discuss in Chapter 1, such legacy systems are costly, and lack the scalability, innovation, and functionality that modern enterprises require. Unfortunately, DoS attacks have new and specific applications in RTC. For example, an attacker can disrupt a target organization s communications infrastructure: At the desktop level, by crashing endpoints (such as phones and desktop PCs) At the gateway level, by taking out the network nodes that provide the interface between an enterprise VoIP environment and the outside world At the network level, by directly targeting an enterprise IP private branch exchange (PBX) using SIP or other protocols to crash the session manager with an endless flood of session requests An attacker s motivation for a DoS attack may include extortion (demanding a ransom payment from the victim organization to suspend the attack) or other financial gain

18 12 Securing Real-Time Communications For Dummies, Sonus Special Edition (cybercriminals are sometimes paid to target a specific organization), as well as publicity for a political or social cause. Attackers often plan the timing of their attacks in order to maximize financial damage. For example, online retailers might be targeted during the heavy traffic of holiday shopping seasons. Beyond lost revenue, financial losses often include the cost of responding to and remediating an attack, expenses related to customer support and public relations, and, in some cases, litigation and civil penalties. With media attention largely focused on cyberattacks involving data theft, DoS attacks may seem irrelevant and rare, but the frequency and impact of these attacks may surprise you. According to research by the Ponemon Institute and security content delivery network (CDN) Incapsula, DoS and DDoS attacks, in general Are increasing 100 percent year over year (YoY) Targeted one in two companies in 2015 Hit the average company four times per year, costing an estimated total of $1.5 million Cost an average of $40,000 per hour last at least five days in 20 percent of attacks, which can be devastating for many businesses DDoS attacks are often used as smokescreens by attackers to spread malware or take control of other systems in the background. One example of a DDoS attack against RTC is a SIP registration flood, in which millions of TCP/UDP packets flood the SIP/UC ports on a SIP trunk (see Figure 2 2). SIP trunks are typically created over multiprotocol label switching (MPLS) or over the top (OTT) networks, which themselves introduce additional security risks. To stop a SIP registration flood attack, you need to differentiate good registrations from bad ones. Although it may be possible to create a rule on a firewall in your data center to block bad registrations, the attack may still succeed because the bandwidth on your SIP trunk can be overwhelmed with attack traffic before it reaches the firewall.

19 Chapter 2: Understanding the Threat Landscape in RTC 13 Figure 2-2: A SIP registration flood is one example of a DDoS attack against RTC. Ideally, you need to stop the DoS attack traffic at the farthest edge of your network. A session border controller (SBC, discussed in Chapter 4) can detect an RTC DoS/DDoS attack and block that traffic from disrupting the valid RTC traffic. DDoS attacks aren t unique to RTC. However, it s important to know that in addition to source IP addresses, the source telephone numbers or SIP uniform resource identifiers (URI) identifying users, are also relevant in DDoS attacks against RTC. More sophisticated DDoS attacks use multiple IP and SIP level sources to further complicate the task of determining and filtering out unwanted traffic. Like IP based data attacks, RTC is vulnerable to DoS attacks from the IP layer and up. However, RTC is also vulnerable to specific types of DoS attacks telephony DoS (TDoS) that target the telephony application itself. TDoS attacks differ from other types of DoS attacks in that they involve RTC sessions, rather than various packets at different protocol layers. TDoS attacks typically target the RTC layer protocols such as session initiation protocol (SIP), for example, by sending large volumes of SIP messages that require complex parsing or state information to be held, resulting in resource consumption (see Figure 2 3). Another form of TDoS simply requires the attacker to direct high call volumes to a server, either consuming all of the server s resources, or preventing legitimate users from accessing a specific number by flooding it with bogus traffic and keeping sessions active for extended durations. TDoS attacks are usually automated, but can also involve large groups of individuals organized through social networking.

20 14 Securing Real-Time Communications For Dummies, Sonus Special Edition Figure 2-3: TDoS attacks target RTC sessions directly. TDoS attacks are very hard to detect and mitigate. Mitigation involves quickly detecting and determining which calls are part of an attack, and terminating those calls to provide bandwidth and resources for legitimate users. Network equipment, such as a firewall, which is not part of the call session cannot stop a TDoS attack it can only provide alerts. Toll fraud Toll fraud is one of the oldest forms of computer crime. Toll fraud involves a malicious user gaining unauthorized access to voice services on a service provider or enterprise network, for example, to make international calls or use other toll services. In other cases, a cybercriminal might gain access to special classes of numbers to extract revenue, such as repeatedly calling a duplicitous premium rate number (perhaps a psychic hotline ) that the cybercriminal operates. The global impact of toll fraud has soared to more than $46.3 billion annually, or slightly more than 2 percent of all global telecom revenues, according to a recent Communications Fraud Control Association (CFCA) Global Fraud Loss survey. To put that into perspective, credit card fraud was around $14 billion dollars over the same period. More ominously, toll fraud losses are growing at a faster rate than global telecommunications revenue. Dial Through fraud (DTF) is the most damaging form of toll fraud, in which an IP PBX is compromised in such a way that an attacker using a robocall generator can dial in to the PBX, get a dial tone, then hairpin dial out to an international premium number to generate fraudulent revenue that is charged to the target enterprise (see Figure 2 4).

21 Chapter 2: Understanding the Threat Landscape in RTC 15 Figure 2-4: An example of DTF. Attackers may use DTF themselves to generate revenue directly, or they may sell access to the compromised PBX to other cybercriminals to generate calls. DTF calls are usually short and variable in duration, and are usually generated outside of normal business hours to avoid detection. Other examples of toll fraud involve opening a connection for a voice call, but instead streaming high definition, compressed video, essentially defrauding the interconnect network out of the higher rates typically charged for video traffic. Number harvesting schemes, in which cybercriminals collect and sell phone numbers to other cybercriminals, may be used for identity fraud, or to perpetrate SPIT and SPIM campaigns. SPIT involves sending prerecorded, unsolicited messages to an RTC endpoint. Because SIP acknowledges the presence of an RTC endpoint, dialer programs can transmit SPIT with a high probability of a recipient picking up the call. Other risks associated with SPIT include denial of service and unauthorized use of network bandwidth. In the same vein, SPIM involves sending unsolicited instant messages to SIP endpoints, particularly PCs and mobile phones. In addition to the risks associated with SPIT, SPIM (like spam) can be used to transmit malware to a SIP endpoint. Current methods of countering SPIT and SPIM are similar to those employed against spam: it s practically impossible to prevent it, you can only attempt to filter it and thereby limit its impact.

22 16 Securing Real-Time Communications For Dummies, Sonus Special Edition Identity theft Identity theft is a common objective in many types of cyberattacks, and RTC attacks are no exception. In addition to defrauding an individual, a compromised identity can be used to allow an attacker to gain unauthorized access to enterprise RTC services (among others), or to prevent the legitimate use of these services by an authorized user. A cyberattack can exploit vulnerabilities in various RTC protocols, such as SIP, for the purpose of identity theft. Some examples include caller ID spoofing, media access control (MAC) spoofing, IP spoofing, and call control/proxy/trivial file transfer protocol (TFTP) spoofing. Freely available tools, such as MacMakeUp and Nemesis, can be downloaded from the Internet to help an attacker spoof an identity. A spoofed identity allows a cybercriminal to impersonate a legitimate user in an RTC session. There are many well established authentication and encryption protocols available to secure RTC signaling and media. However, these protocols aren t always used by enterprises, leaving the user and the service open to identity theft. Thus, in some cases, a simple packet capture may be all that s needed for an attacker to gain unauthorized access to an organization s RTC environment. Although authentication may help to prevent illicit access to RTC services, without encryption it doesn t prevent certain signaling injection attacks. These types of attacks may be used in DoS attacks or for toll fraud, as well as for identity theft, for example, by eavesdropping on calls or accessing voice mails and messaging to collect sensitive data. Vishing is the VoIP enabled form of phishing. As effective a tool as phishing is for cybercriminals, it is absolutely amazing how willing people are to disclose personal information to a live voice on the other end of a phone. Many legitimate U.S. businesses knowingly outsource their customer service to call centers staffed by prison inmates! Although such call centers are closely monitored and do not knowingly engage in identity fraud, this example illustrates the point that people will often implicitly trust a live person on the other end of a call. To exploit this false sense of security, many criminal organizations are known to set up their own call centers to extract information from hapless victims.

23 Chapter 2: Understanding the Threat Landscape in RTC 17 Exposing New Attack Vectors with RTC Hacking into RTC sessions requires that the malicious party intercept signaling and/or media flowing between two endpoints at any of several points along the communications path. Several potential points of attack or attack vectors exist in RTC sessions, including UC application servers Call control elements, such as PBXs and automatic call distributors (ACDs) Session layer servers and proxies, such as SBCs Transport and network layer elements, such as routers Link layer elements, such as Ethernet switches and wireless LANs Endpoints, such as desktop and laptop PCs, mobile devices, IP phones and videoconferencing terminals In addition to traditional network attack methods such as infecting an endpoint with malware to establish administratorlevel remote access man in the middle attack techniques, in which certain packets are selectively altered between two endpoints in a voice, video, or instant messaging stream, may be used. Modifying, disrupting, or lowering the quality of IP communications in this manner can have a variety of adverse effects on the enterprise. For example, an attacker can modify or discard critical financial transactions, disrupt business operations, or reduce the quality of the customer experience. Some common attack vectors that RTC exposes include Linux and COTS, porous firewalls, and RTC traffic flows. Linux and COTS Unlike legacy circuit switched TDM PBXs that were often comprised of proprietary hardware and software, many RTC systems use open source Linux operating systems and commercial off the shelf (COTS) software running on commodity hardware, such as Intel based servers. Thus, RTC systems

24 18 Securing Real-Time Communications For Dummies, Sonus Special Edition expose many of the same attack vectors as any other server in an enterprise network, and need to be patched and safeguarded accordingly. If compromised, these systems can be used not only to attack RTC services, but also as a platform for lateral movement throughout the enterprise network. Porous firewalls RTC protocols, such as SIP, session description protocol (SDP), and real time transport protocol (RTP), are designed to require multiple source and destination sockets (IP and port combinations) during an RTC session. Given the number of users in a typical enterprise or carrier network, it is not uncommon for thousands of firewall holes to be opened in order to support RTC services. Not only does this give an attacker ample attack vectors to target RTC servers, but also it provides an opportunity to flood common network segments with traffic that could hinder or knock out other enterprise systems and services. For example, enterprises using SIP for remote user connectivity typically configure their perimeter firewalls to forward SIP traffic (port 5060) to an internal IP PBX. Using this forwarding rule, an attacker can send fuzzed (or malformed) messages with embedded shell code to a vulnerable endpoint (such as a softphone installed on a laptop computer) via the IP PBX, which treats the fuzzed message as a new call and forwards it to the endpoint. When the endpoint receives the fuzzed message it executes the embedded shell code, causing the endpoint to connect back to the attacker s computer over port 80. Enterprise firewalls typically allow outgoing connections to port 80, as this is the standard port for web traffic (hypertext transfer protocol, or HTTP). Once the connection back to the attacker is established, the attacker can get take control of the victim s endpoint, access any data stored on the endpoint, and probe the network for other vulnerabilities (see Figure 2 5). More than 50 percent of all cyberattacks will be SIP based in 2016, and the annual cost of SIP attacks alone is estimated at $11.7 billion, according to CFCA, the SIP Forum, and Telecom Reseller.

25 Chapter 2: Understanding the Threat Landscape in RTC 19 Figure 2-5: SIP sessions create dynamic firewall rules (or holes ) that can be used for network penetration by an attacker. RTC traffic flows signaling and media It isn t uncommon for network administrators to assume RTC protocols are inherently secure. After all, you need specialized codec algorithms to make sense of an RTP flow, for example. However, this notion of security is false. For example, it s well known that it s possible to embed attacks, such as SQL injections, into SIP headers that can cause servers to crash, corrupt data, or allow unauthorized access to an attacker. An attacker can also embed malware in a SIP or RTP signaling or media stream to infect an RTC endpoint on the network. Finally, an RTC media session can be used by an attacker to exfiltrate (or steal) sensitive data from a network using RTP, for example, as a covert channel.

26 20 Securing Real-Time Communications For Dummies, Sonus Special Edition

27 Chapter 3 Securing Real Time Communications In This Chapter Securing RTC signaling and media with encryption Maintaining regulatory compliance Seeing how no security costs you in RTC In this chapter, you learn about the role of encryption in securing real time communications (RTC), as well as regulatory compliance issues. Encrypting RTC Signaling and Media To protect voice networks against the widest possible range of attacks, an enterprise RTC security strategy should protect both the endpoint and the media itself. This can be achieved through a holistic security approach that includes Virtual private networks (VPNs) to logically separate voice and data traffic on the common IP network Border security elements such as session border controllers (SBCs) to provide call admission control (CAC) and protect against denial of service (DoS) attacks Signaling and media encryption of RTC sessions, including those sessions stored on voice messaging and call recording systems

28 22 Securing Real-Time Communications For Dummies, Sonus Special Edition While many enterprises have implemented VPN and border security technologies to protect their IP based data networks, the encryption of RTC signaling and media is a unique consideration that has grown in importance with the advent of more pervasive RTC implementations in the enterprise. The encryption of RTC signaling and media mitigates a number of IP based threats including Passive monitoring and recording Packet decryption and modification Service or bandwidth theft Endpoint impersonation Denial of service (DoS) Escalation of network user privileges Because signaling and media use different protocols with unique properties and constraints, RTC networks employ Transport Layer Security (TLS) and/or IPsec (IP Security) for signaling encryption and Secure Real time Transport Protocol (SRTP) for encrypting RTP media. TLS and IPsec provide bilateral endpoint authentication and secure transport of signaling information using advanced cryptography. SRTP provides encryption (and decryption) of the RTP media used in RTC applications (such as conferencing and instant messaging). TLS, IPsec, and SRTP encryption enable enterprises to secure RTC communications by performing three key functions: Endpoint authentication: This supports the use of digital signatures (which may be proprietary or verified by a trusted third party) and pre shared, secret based authentication to verify the identity of session endpoints. Message integrity: This ensures that media and signaling messages have not been altered or replayed between endpoints. Privacy: Encrypted messages can only be viewed by authorized endpoints, mitigating information/service theft and satisfying both regulatory and corporate requirements for private communications.

29 Chapter 3: Securing Real Time Communications 23 However, deploying TLS, IPsec, and SRTP encryption in the enterprise may increase call latency. Therefore, signaling and media encryption must be thoughtfully integrated into the IP network traffic flow to prevent added network latency or decreased performance under load. Enterprises must weigh several considerations before they deploy RTC encryption in their network: Session performance: Remember that encryption requires additional processing of signaling and media. Extra hops to a separate encryption device in the network or an SBC that performs encryption from the main CPU can add unwanted latency to RTC sessions or compromise call handling capacity. Therefore, it s important to find an encryption solution that has minimal impact on session capacity and network performance. While enterprises should consider implementing security solutions such as standalone SBCs, they should be aware that SBCs without dedicated encryption hardware will normally encrypt traffic at the expense of session performance. Multimedia support: As RTC initiatives grow, enterprises will be required to handle a variety of multimedia sessions including voice, video, instant messaging (IM), and collaboration apps. To reduce cost and network complexity, enterprises should look for an SBC that has robust transcoding capabilities and supports multiple media types. Encryption standards: Simply put, some encryption standards are more accepted/effective than others. Your RTC security solution needs to use the latest encryption/ decryption methods to ensure broad network and RTC interoperability in the future. Disaster/failover recovery: Network equipment failures, fiber cuts, and natural disasters happen despite the best precautions. Enterprise security systems need to be prepared for this reality with a backup/failover plan for all aspects of security including RTC session encryption. This can best be achieved by deploying SBCs in redundant, paired configurations. Centralized policy management: To reduce human error and operational costs, a central management console for encryption policies in the network is both desirable and essential.

30 24 Securing Real-Time Communications For Dummies, Sonus Special Edition Complying with Regulatory Requirements There are myriad regulatory requirements for data security and privacy that are applicable in various industries and regions throughout the world (see the sidebar, The cost of no security in real time communications ). In RTC environment, voice, video, and other media is another form of IPbased data in the network that must also be safeguarded. Eavesdropping, or the unauthorized interception of RTC traffic between endpoints, can be a major security and privacy threat for organizations. An RTC session can be tapped by compromising the network anywhere along the data route. Moreover, it s possible to remotely activate conferencing or handset/headset microphones on compromised endpoints. Eavesdropping can be implemented using SIP proxy impersonation or registration hijacking. To counter the eavesdropping threat, enterprises and service provider should encrypt media signaling in their RTC environments. Session replication for recording is another common use case that can be impacted by regulatory requirements. Organizations that record RTC sessions, either for the purpose of regulatory compliance directly, or for quality control purposes in a call center, must be able to replicate all SIP signaling and media to a recording server(s), as well as to the intended recipient. Organizations must also be able to replicate all or only selective sessions and store recorded media in an encrypted format on a secure server. Looking at the Cost of No Security In RTC Most businesses understand the risks posed by attacks on the data side of the network: stolen credit card numbers, compromised passwords, denial of service, financial fraud and identity theft, among others. Those same risks apply to real time communications as well, though they may manifest themselves as different threats, such as eavesdropping, telephony

31 Chapter 3: Securing Real Time Communications 25 denial of service (TDoS) attacks, and automatic number identification (ANI) spoofing targeting call centers. These real time communications threats can be as destructive as data threats, consuming valuable resources, driving down revenue, and damaging brand equity. The most serious risk in a VoIP network that isn t properly secured is the potential exposure of confidential, sensitive, private, or otherwise protected information, including Private data and personally identifiable information, or PII (for example, names, addresses, birthdates, and Social Security numbers) Financial data (for example, credit or debit card numbers and banking or financial account information) Protected health information, or PHI (for example, physical examinations, lab tests, diagnosis, and prescription records) Sensitive company information (for example, sales data, marketing plans, research and development, intellectual property, trade secrets, and new product details) An enterprise security breach can result in financial penalties and other consequences for the organization. For example, a single security incident in a credit card processing environment can result in multimillion dollar fines and other liabilities, due to losses from fraud and theft. Other costs can include reissuing credit cards, communicating the breach to customers, and mandatory credit monitoring services. In some cases, a business may have its card processing privileges suspended or revoked. Noncompliance with federal and industry security regulations can cost enterprises millions of dollars in fines, legal fees, damages and lost revenue. Some regulations and industry standards that address VoIP security requirements include Gramm Leach Bliley Act (GLBA): Applicable to any public company involved in financial services (such as banking, credit, securities and insurance); relevant VoIP/ UC issues for GLBA include preventing unauthorized VoIP packet interception and decryption, and securing internal wireless networks and communications over public wireless networks.

32 26 Securing Real-Time Communications For Dummies, Sonus Special Edition Health Insurance Portability and Accountability Act (HIPAA): Applicable to any organization that handles medical records or other protected health information (PHI); relevant VoIP/UC issues for HIPAA include securing authorized internal and external access to patient data. Sarbanes Oxley (SOX) Act: Applicable to public companies; relevant VoIP/UC issues for SOX include maintaining VoIP usage logs and tracking administrative changes, and implementing strong authentication policies to prevent unauthorized system use. Federal Information Security Management Act (FISMA): Applicable to any federal agency, contractor, or company/organization that uses or operates an information system on behalf of a federal agency; relevant VoIP/ UC issues for FISMA include System and Information Integrity (SI) requirements, implementing solutions to remediate security flaws, providing security alerts and advisories, protecting against malicious code, detecting and preventing network intrusions and malware, and maintaining application and information integrity. Payment Card Industry Data Security Standard (PCI DSS): Applicable to any organization that issues, accepts, or processes VISA, MasterCard, American Express, Diners Club, or Discover credit or debit cards; relevant VoIP/UC issues for PCI DSS include protecting cardholder data and sensitive information shared between employees and/or customers (for example, in a call center) over VoIP calls or UC sessions, protecting stored information stored on voice messaging or call recording systems (for example, for call center quality control purposes), and tracking and monitoring access to network resources and cardholder data.

33 Chapter 4 Understanding Why a Firewall Can t Secure RTC In This Chapter Defining the role of firewalls and SBCs in RTC security Recognizing different capabilities in firewalls and SBCs In this chapter, you learn about the role of session border controllers (SBC) in real time communications (RTC), and why a firewall alone isn t enough to secure real time communications. Understanding the Role of Firewalls and SBCs Firewalls are designed to protect data networks and services from external threats and attacks. In a typical network configuration, a router forwards IP packets to servers and endpoints through a firewall that connects a trusted (internal) network to an untrusted (external) network. The firewall determines which connection are permitted to and from the server or endpoint based on a statically configured rule base that allows or blocks specific port connections that correspond to specific source and destination IP address combinations. Different firewall types include static or dynamic packet filtering firewalls, stateful inspection firewalls, proxy servers, application firewalls, and next generation firewalls (NGFWs).

34 28 Securing Real-Time Communications For Dummies, Sonus Special Edition The most commonly deployed types of enterprise firewalls today are dynamic packet filtering and stateful inspection firewalls. However, NGFWs generally recognized to have superior security capabilities to other firewall types are increasingly being deployed in enterprise networks. SBCs are designed to create a secure RTC environment in which numerous devices across multiple networks interwork to create a seamless user experience. An SBC s main function is to deliver session initiation protocol (SIP) trunking for enterprises and interconnection to other service providers (see Figure 4 1). Figure 4-1: The primary function of an SBC is to provide SIP trunking for enterprises and interconnection between service providers. SBCs can also support the hosting of business voice over IP (VoIP) services in delivering an RTC environment of linked media and voice communications. VoIP based RTC services present a packet based, IP solution that supports concurrent voice and data in a very efficient and cost effective manner over high speed mobile data connections. Enterprises and service providers can also leverage SBCs (along with policy engines) to improve the security of their networks. SBCs prevent unauthorized access to the RTC environment, while policy engines ensure that any unauthorized access doesn t lead to stolen, completed calls to high cost locations.

35 Chapter 4: Understanding Why a Firewall Can t Secure RTC 29 Other SBC functions include SIP session management and interworking Denial of service (DoS) and distributed denial of service (DDoS) protection Protocol interworking Call detail record (CDR) and billing IP multimedia subsystem (IMS) and SIP application support Rich communication suite (RCS) and IP exchange (IPX) support WebRTC and RTC support Policy and routing enforcement Media services (transcoding and transrating) Encryption, using Transport Layer Security and IP Security (TLS/IPSeC) and Secure Real Time Transport Protocol (SRTP) Comparing Firewalls and SBCs Firewalls and SBCs provide different security functions in a converged IP data and RTC network. Table 4 1 provides a summary comparison of key firewall and SBC functionality and capabilities. Table 4-1 Firewall Maintains single session through firewall Fully state aware at Open Systems Interconnection (OSI) model layers 3 (network) and 4 (transport) only (except application firewalls, proxy servers, and NGFWs) Firewalls versus SBCs SBC Implements a SIP back to back user agent (B2BUA) for complete session control Fully state aware at OSI layers 2 (data link) through 7 (application) (continued)

36 30 Securing Real-Time Communications For Dummies, Sonus Special Edition Table 4-1 (continued) Firewall Inspects and modifies only application layer addresses (such as SIP and session description protocol or SDP, and others) Unable to terminate, initiate, re initiate signaling and SDP Typically only supports static access control lists (ACLs) Not able to decode encrypted SIP signaling and/or media SBC Inspects and modifies any application layer header info (such as SIP, SDP, and others) Can terminate, initiate, re initiate signaling and SDP Supports static and dynamic ACLs Able to decode RTC encryption (IPSec/TLS and SRTP When developing an RTC security strategy, you should consider four key RTC threat vectors: UC as a delivery mechanism for malware and/or spyware Denial of service along two vectors, each of which compromises UC such that the service is interrupted or suspended: Network layer denial of service: Network layer packet floods and replays attacks to overload UC elements and take away from good put processing Application layer denial of service: Protocol aware attacks to crash the UC stack (for example, malformed SIP packets, illegal headers, out of order messages, and others) Theft of service Identity management Tables 4 2 and 4 3 outline the capabilities of NGFWs and SBCs, respectively, in protecting RTC networks against these different attack vectors.

37 Chapter 4: Understanding Why a Firewall Can t Secure RTC 31 Table 4-2 Security Domain Malware and spyware [strong] RTC denial of service (DoS) [weak] Theft of service [weak] Identity management [modest] NGFW Scorecard for RTC Security Capabilities In depth signature library, scanning, and pattern matching on the payload Note: Encryption of SIP and RTP media flows is becoming increasingly common in RTC and compromises the strengths of NGFWs as signatures become obscured. Network: Requires deep SIP awareness to track port numbers, user datagram protocol (UDP) service types, stream activity/inactivity, and bandwidth requirements Application: Requires full stack parsing, validation, and session state to protect downstream RTC elements Requires knowledge and state around RTC user identity via SIP registration parsing and state caching (not implemented in NGFW) Requires understanding of negotiated services (such as audio, video, and collaboration) and tight management of per session bandwidth utilization Can effectively identify RTC applications and whether they should be allowed into the network (for example, a go/no go policy decision) The challenge is understanding the validity of the identity as it relates to the RTC service (for example, is the user trusted and allowed to invoke the service).

38 32 Securing Real-Time Communications For Dummies, Sonus Special Edition Table 4-3 Security Domain Malware and spyware [weak] Denial of service (DoS) [strong] SBC Scorecard for RTC Security Capabilities No in depth signature library, scanning, and pattern matching on the payload This is a primary security function in an SBC with full SIP awareness, full call state awareness, and session awareness from beginning to end of call. Theft of service [strong] Identity management [strong] DOS requires full stack and session state knowledge to protect downstream UC elements (such as phones, PBX, the UC stack itself, and others). This is a primary security function in an SBC with full SIP awareness, full call state awareness, and session awareness from beginning to end of call. An SBC understands the negotiated services (for example, audio/video/ collaboration) and provides tight management of per session bandwidth utilization. Tracks the multiple states of authentication as RTC users advance from untrusted, through known but not validated, to fully trusted states Strong understanding of the validity of user identity in the context of the RTC stack

39 Chapter 5 Looking to the Future in Securing RTC In This Chapter Recognizing the widening vulnerability gap Countering RTC threats with a multilayer security stack In this chapter, you explore the need for a comprehensive security strategy to address the widening vulnerability gap in enterprise and service provider networks, and you look to the future of network security: the multi layered security stack. New Strategic Approaches to RTC Security Are Needed Security organizations, in general, aren t innovating fast enough. As a consequence, the following happens: Existing controls are ineffective against new threats, and new controls aren t being developed and deployed in a timely manner. The internal network can t be trusted due to the proliferation of mobile bring your own device (BYOD) and cloud computing trends that blur the border between the internal and external network and introduce pervasive vulnerabilities throughout the network.

40 34 Securing Real-Time Communications For Dummies, Sonus Special Edition In contrast, attackers are rapidly and continuously evolving their tactics and becoming increasingly sophisticated, lured by easier targets such as BYOD mobile devices and apps and the increasing value of sensitive information such as medical or healthcare information and credit card data. This polarization between security innovation and attacker innovation is creating an ever widening vulnerability gap, as seen in Figure 5 1. Figure 5-1: New strategic approaches to security are needed as the vulnerability gap continues to widen. Multi layered Security in the Network A multi layered security stack provides a new model for RTC network architectures, with a service delivery logic layer that defines where and when security will be applied in the network (see Figure 5 2).

41 Chapter 5: Looking to the Future in Securing RTC 35 Figure 5-2: A multi layered security model for the network. RTC services, such as voice and video, are applications that should be routed over a network via session border controllers (SBCs) with policy capabilities that, in turn, programmatically use the network as a security function. The idea here is that every RTC flow is metered. The higher application levels utilize the service delivery logic of the SBCs, via application programming interfaces (APIs), to push appropriate policies down through the network control interface and apply and enforce any security decisions for each RTC flow. The packet forwarding (or network) layer is an enabler to security policy: It can augment security in the service delivery layer by preventing a breach or attack with policies that are implemented at the transport layer. This is what a multi layered security approach is all about. The examples in the following sections demonstrate the multilayered security model in action. Firewall and SBC sharing contextual awareness As I describe in Chapter 4, neither a next generation firewall (NGFW) nor an SBC alone is sufficient to provide such a comprehensive enterprise security solution. However, an integrated NGFW and SBC solution provides coverage across all enterprise security domains, as shown in Table 5 1.

42 36 Securing Real-Time Communications For Dummies, Sonus Special Edition Table 5-1 NGFW and SBC Integrated Security Solution Security Domain Malware and Spyware Solution Description SBCs share decrypt keys with NGFWs to leverage full malware/spyware capabilities of NGFWs in encrypted sessions. DoS (network and application layers) and Theft of Service SBCs provides more granular visibility into application ID for RTC (for example, video, audio, and file transfer) to enable NGFWs to enforce more granular security actions/ scanning on RTC flows. SBCs share detailed port, addressing, and bandwidth information with NGFWs for more restrictive admission of RTC flows (that is, the attack surface is significantly reduced). SBCs shares threat information with NGFWs, enabling threats to be blocked by NGFWs beyond RTC services. Identity Management The RTC security enforcement point moves from the SBC to the NGFW, which can then apply policy and actions on a much broader scope. Sharing identity status (such as trusted, unknown, bad) enables broader policy controls. SBC identity state can be factored into other security actions by NGFWs. NGFW identity state can be factored into SBC call admission control (CAC) decisions. An integrated NGFW and SBC solution is accomplished by exchanging RTC context information between the NGFWs and SBCs deployed in an enterprise or service provider network. This integrated solution raises the trust level of RTC by enhancing the RTC awareness of the NGFW, which translates into A deeper level of RTC security at the NGFW A broader enforcement of security countermeasures when RTC is attacked

43 Chapter 5: Looking to the Future in Securing RTC 37 Consider the following example of toll fraud using IP address spoofing, illustrated in Figure 5 3: Figure 5-3: RTC security example IP address spoofing. 1. The attacker probes the target network by making a call with a spoofed IP address. The call appears normal to the firewall and is routed to the SBC. 2. The SBC asks the policy routing engine where to send the call and authorizes the session. 3. The application server provides the voice over IP (VoIP) service. 4. The call is routed back to the fraudulent destination, Nigeria in this example. 5. The initial toll fraud incident may go undetected because, in this example, the policy engine is configured to allow a small volume of calls to certain restricted countries. 6. As the toll fraud continues, the policy engine threshold is met, triggering a detection alert. 7. The policy engine responds by instructing the SBC not to accept future call attempts from the spoofed IP address. 8. The SBC prevents future calls from the spoofed IP address to the fraudulent destination.

44 38 Securing Real-Time Communications For Dummies, Sonus Special Edition 9. The policy engine predicts future toll fraud attempts using analytics gathered throughout the incident. 10. The policy engine instructs the firewall to modify its packet forwarding rules to block future requests that match the toll fraud heuristics. 11. The firewall prevents future toll fraud attacks by adding the source and destination IP addresses to a blacklist. SDN to augment multi layer security Another scenario uses software defined networking (SDN) to augment the multi layer security stack (see Figure 5 4). Figure 5-4: SDN augments multi layer security to raise the security trust level of RTC in the network. In this case, the underlying network is used as a security function. The network edge has a number of white box routers that are under SDN control. The SDN controller defines application flows such as per flow service level agreements (SLAs) and guaranteed bandwidth. In the multi layered security model, a security perimeter is created at the farthest egress/ingress point of the network. The higher level security delivery logic layer programmatically tells the SDN controller to implement a policy to move an internal rogue endpoint to a new flow or bit bucket, or to stop ingress traffic based on a predictive model of heuristic analytics.

45 Chapter 5: Looking to the Future in Securing RTC 39 In other words, the network is now metering based on the service delivery logic programmatically telling the SDN controller what policies to implement on every RTC flow. Access controls or network policing can be applied on a per flow basis. By coupling the service delivery logic (network policy and intrusion prevention logic) to the SDN controller, the security trust level of RTC in the network is increased as Every RTC flow is metered Data gathered by the network is fed into network analytics tools, which then configure the network automatically and optimize it for individual applications (that is, the higher level service delivery logic tells the SDN controller what to do in the network) The SDN controller augments a multi layer security network, enabling security at the transport level Consider the following example of a distributed denial of service (DDoS) attack using a session initiation protocol (SIP) registration flood, illustrated in Figure 5 5: Figure 5-5: Hosted network/cloud SBC integration with SDN enabled network control. 1. A DDoS attack floods the network with SIP registration messages from multiple sources. 2. The SBC at the service delivery logic layer detects the DDoS attack and SIP registration flood. 3. The SBC programmatically tells the SDN controller to respond to the DDoS attack, based on its detection and uses analytics to thwart future attacks.

46 40 Securing Real-Time Communications For Dummies, Sonus Special Edition 4. The SDN controller responds by modifying the packet forwarding rules at the edge of the network. 5. The SDN controller prevents the DDoS attack from succeeding at the network edge (or the security perimeter of a virtualized SBC in the cloud). In the same way that the SBC sends instructions to blacklist bad IP addresses (blacklists), it can also enable whitelist policies that ensure good traffic is always permitted to flow through the RTC infrastructure.

47 Chapter 6 Ten Ways SBCs Secure RTC In This Chapter Hiding the RTC network topology and preventing denial of service attacks Encrypting RTC media and signaling traffic Preventing toll fraud and malformed packets Managing performance and enabling remote access Registering endpoints and maintaining session state awareness Session border controllers (SBCs) play a critical role in securing enterprise real time communications (RTC). In this chapter, I outline ten key security capabilities of SBCs. B2BUA/Network Topology Hiding The SBC hides the network topology by acting as a back toback user agent (B2BUA), defined in Internet Engineering Task Force (IETF) Request for Comments (RFC) A B2BUA divides a session initiation protocol (SIP) session into two distinct segments: one between the endpoint and the SBC, the other between the SBC and the IP private branch exchange (PBX) or unified communications (UC) server. Trunk Groups are employed at the network edge to manage call admission, traffic controls, and other functions between the carrier network and the peering partner; consequently, all call signaling traffic is routed through the SBC. Similarly, real time transport protocol (RTP) relay allows media flows to be proxied through the SBC. Thus, the SBC translates IP addresses and ports for signaling and media

48 42 Securing Real-Time Communications For Dummies, Sonus Special Edition streams that traverse the system to hide the core network addressing schemes and translations. DoS and DDoS Defense (Policers) The SBC uses specialized hardware and policing software to deal with high traffic volumes and protect the core network from denial of service (DoS) and distributed denial of service (DDoS) attacks. Different policers include the following: Static blacklisting: IP addresses and/or network prefixes that are discarded on ingress Dynamic blacklisting: Designed to detect and block misbehaving endpoints for a configured period of time rather than prevent malicious attacks, for which the system employs other defense mechanisms Whitelisting: Static list of IP addresses and/or network prefixes that are allowed to access the SBC Micro flow policer: Allows registered endpoints through the SBC (primarily used in access scenarios) Unknown peer: Allows any unknown packet through the SBC up to the specified packet rate limit Encryption (Media) RTC traffic needs to be encrypted for privacy and regulatory compliance purposes. SBCs use secure RTP (SRTP) to encrypt media packets and all SRTP encrypted calls are routed through the SBC. SRTP can be used inside or outside the network. SRTP on one call leg is independent of its use on other legs of the same call, and is negotiated for each packet leg. SBCs without dedicated encryption hardware will normally encrypt traffic at the expense of RTC session performance. Encryption (Signaling) SIP signaling messages are plain text and relatively easy to intercept. SBCs use transport layer security (TLS) and IPsec to encrypt signaling traffic. TLS supports peer authentication,

49 Chapter 6: Ten Ways SBCs Secure RTC 43 confidentiality, and message integrity. IPSec supports cryptographic protection for non media IP packets using the management or packet interfaces. Toll Fraud Protection Toll fraud losses total more than $46 billion annually and exceed the rate of revenue growth for the telecommunications industry. Toll fraud schemes, such as dial through fraud (DTF), enable a cybercriminal to make free international calls (or sell international access to other cybercriminals) or auto dial premium numbers to run up fraudulent charges against the victim organization. SBCs can be configured to disable secondary dial tone sources in order to prevent toll fraud. Malformed Packet Protection An attacker may attempt to send malformed packets to cause an RTC application or service to crash, or exploit a vulnerability that provides unauthorized access. An SBC maintains full session state information and is therefore able to detect and respond to attempts to send malformed packets over the network. Call Admission Control/ Overload Controls Call admission control limits the number of RTC sessions that can be simultaneously active in order to prevent network overload. An overload can degrade the performance of other calls on the network, or crash an RTC environment in effect, a self inflicted denial of service. Overload threshold parameters can be configured on the SBC based on CPU and memory utilization. When a threshold is reached, the SBC adjusts the system call and registration acceptance rate up or down to maintain the target CPU usage configured for that level. This capability maximizes the system throughput without exceeding the desired CPU utilization threshold. During adaptive throttling, the SBC can assign

50 44 Securing Real-Time Communications For Dummies, Sonus Special Edition different preferences (priorities) to normal calls, emergency calls, and initial SIP registrations. NAT Traversal (Remote Workers) Enabling RTC for remote users behind firewalls performing network address translation (NAT) can be a challenge for enterprises. An SBC keeps firewall holes open by resetting the SIP registration interval to a value lower that the firewall port time to live (TTL) and caching SIP registrations by firewall IP and port assignment. Endpoint Registration The SIP Signaling Registration facility enables an SBC to relay SIP endpoint registration information between endpoints and the Registrar. The registration facility allows different expiration times on the untrusted versus trusted network. This can be used to reduce the registration refresh load on the registrars without sacrificing fast detection of failed endpoints. Full SIP Session State Awareness Full SIP session state awareness enables an SBC to initiate, reinitiate, maintain, or terminate RTC sessions, as necessary. RTC is only getting more complicated, and it s becoming increasingly difficult to capture and act on this information. SBCs can dynamically process the deep RTC requirements associated with SIP statefulness, including parsing and inferring the following: Active and changing port numbers UDP service types Stream activity/inactivity Bandwidth requirements In short, SBCs provide full SIP stack and session state knowledge to protect downstream UC elements (such as phones, PBX, the UC stack itself, and more) against DOS attacks.

51

52