securing real time communications how sbcs protect your business n.
Skip this Video
Loading SlideShow in 5 Seconds..
Securing Real-Time Communications: How SBCs Protect Your Business PowerPoint Presentation
Download Presentation
Securing Real-Time Communications: How SBCs Protect Your Business

Loading in 2 Seconds...

play fullscreen
1 / 33

Securing Real-Time Communications: How SBCs Protect Your Business - PowerPoint PPT Presentation

  • Uploaded on

Securing Real-Time Communications: How SBCs Protect Your Business . Patrick McNeil, Product Security Lead Hendrik Scholz, Product Manager.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Securing Real-Time Communications: How SBCs Protect Your Business' - decker

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
securing real time communications how sbcs protect your business
Securing Real-Time Communications:How SBCs Protect Your Business

Patrick McNeil, Product Security Lead

Hendrik Scholz, Product Manager


The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

program agenda
Program Agenda
  • What is a Session Border Controller (SBC)?
  • Security Threats
  • Debunking misconceptions
  • Best Practices

“Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a logical entity that receives a request and processes it as a user agent server (UAS). In order to determine how the request should be answered, it acts as a user agent client (UAC) and generates requests.”

sbcs create a service demarcation
SBCs create a service demarcation

Service Provider Network

  • Stop Denial of Service attacks (flooding, fuzzing)
  • Hide topology
  • Encrypt endpoint communications if needed
  • Highly available
  • Provide normalization / interoperability
  • Secure management


Enterprise Data Network

See RFC5853 for a full description of SBC requirements

methods of access and abuse
Methods of Access and Abuse

GSMA Fraud Forum Categories

pbx compromise
PBX Compromise

Common methodology enables fraud and theft of service

  • Scan wide IP range looking for SIP servers
  • Call attempt to probe for systems allowing unauthenticated calls
  • Brute-force user credential guessing (if required)
  • Call attempts to known number or “burner phone” to find dial-out prefix


Cracked line registered and used for IRSF or wholesale fraud

INVITE sip:100@

REGISTER sip: 100@

Password: 100, 101, 102, etc.

INVITE sip:7817966920@

INVITE sip:97817966920@

outbound line scanning
Outbound line scanning

65 seconds between successful break-in and abuse

voicemail compromise
Voicemail Compromise

Voicemail features used for fraud

  • Fraudsters manually dial passcodes until successful
  • Abused voicemail features
    • Call-through – new call originating from voicemail system
    • Call-back – leave voicemail with spoofed origination number and have the system ‘call back’
    • Call-forwarding – all calls forwarded to IRSF or wholesale number

Password: 100




international revenue sharing fraud
International Revenue Sharing Fraud

Using a compromised PBX or voicemail system

  • Fraudster registers revenue-share number
    • Profits from each inbound call to number, e.g. paid weekly
    • Foreign country operator provides equipment, makes prosecution/blocking difficult
  • Fraudster directs traffic to revenue-share number
    • Inflates traffic from PBXes, voicemail systems
    • Wangiri scam

1st Compromise System Credentials

3rd PBX routes calls to fraudster in expensive foreign market

2nd Make calls using cracked credentials

wholesale fraud
Wholesale Fraud

Using a compromised PBX or voicemail system

  • Fraudster uses compromised system to forward traffic between two valid service providers for attractive rates, usually advertised on wholesale marketplace websites
  • Revenue paid to fraudster by operators who route calls to the fraudulent trunk; Paid daily or weekly, valid subscriber billed monthly

Valid Operator



Valid Operator

service overload vs denial of service
Service overload vs Denial of Service


  • Overload – Consumption of total capacity of one or more components in a system, thereby creating a “bottleneck” that impacts service.
    • Can be accidental due to outage, misconfiguration, poor engineering, or unforeseen usage spike
  • Denial of Service (DoS) – targeted overload where disruption of service is primary motivation
    • May distract from another attack
  • Attacks can be at different layers
    • Application - correctly signaled calls over the trusted call path
    • Transport - invalid format or state attacks – SIP floods, fuzzing, encryption renegotiation, TCP SYN, ICMP, etc.
service overload
Service overload

Challenge – overload differentiation vs DoS

  • What is an attack and what is just an unexpected overload? Some normal or accidental occurrences may look like attacks
    • ‘Manhattan reboots’ scenario – recovery from a power outage creates avalanche of legitimate calls (alarm systems, backup modems, etc)
    • Misconfigured automation, call forwarding, or bad contact center rule
    • Mass calling event - radio station contest, phone voting for TV program
denial of service
Denial of Service

Real attacks

  • Application layer DoS attacks
    • Sometimes called Telephony DoS (TDoS)
    • Usually floods of calls to specific numbers with spoofed origination
    • Blocking difficult in network of trusted service provider peers since calls come in multiple trunks
    • Against business targets - usually automated, a few ‘social’ attacks
    • Against individuals – payday scams
      • Threats and extortion against individuals with an outstanding loan during business hours, to business number
      • May be coupled with fake call to police to nearby address
      • Loan information purchased from Internet clearinghouses
      • Manually conducted using a cheap labor pool
some of the misconceptions
Some of the misconceptions

Fabricated problems and incomplete solutions

  • “NULL packets” used for Denial of Service
  • TDoS easily stopped with <insert product here>
  • Fuzzing billed as “top violation” but not seen frequently
  • The long list of threats
null packets used for dos
“NULL packets” used for DoS

Keep-alives cast as malicious “NULL packets”

  • “NULL packets”
    • Empty messages used to keep NAT bindings and firewall pinholes open
    • Sent every few seconds to minutes
  • Content
    • “\r\n\r\n” via UDP – no response required, easily filtered
    • Ping-Pong game (via TCP) (RFC 5626)
    • STUN (RFC 5389) based mechanism
  • Impact
    • No attack but required for proper network operation


Ping CRLF “\r\n\r\n”

Pong CRLF “\r\n”

fuzzing as a top violation
Fuzzing as a “top violation”

Fuzzing: Syntactically or semantically invalid messages

  • Fuzzing requires lots of messages so it is very “noisy”
  • Easily detected and stopped with message thresholds and syntax enforcement
  • In reality, after fingerprinting target service, fuzzing done offline with test equipment to determine vulnerabilities
  • Attacks will be targeted and precise
  • Edge security device needs to inspect messaging and enforce RFC defined format
  • Monitoring behind edge will only see normalized traffic
tdos easily stopped with insert product here
TDoS easily stopped with <insert product here>

Oversimplification of the problem

  • Solutions relying on premise-based equipment can only limit number or rate of calls to protect core equipment, but cannot stop the attack.
  • Circuit capacity can always be overwhelmed, even if stopped at your edge.
  • From number changes – multiple actors or adaptation to evade filters
  • Solutions that tear down calls based on audio identification - another call gets established immediately afterwards
  • Some solutions placed behind edge equipment (e.g. SBC, proxy)
    • Equipment has to deal with attacks
detecting and stopping tdos
Detecting and stopping TDoS

Placement of <insert product here> into live network

  • Monitoring systems often placed on private/core side of network
    • Cannot see attacks blocked by edge devices (SBC, proxy)
    • Cannot prevent the attack on edge devices
  • Chicken-Egg problem when placing monitoring in front + in-line
    • Monitoring becomes active component subject to attacks
    • Monitoring has to support all VoIP features or it will degrade service
    • Monitoring effectively becomes SBC, proxy
the long list of threats
The long list of threats

Restating the problem to generate fear, uncertainty and doubt

address the root causes
Address the root causes


Threats are related








DoS / Overload

  • Most vendor “threats” further enumerate or restate a single issue many ways
  • Many threats can be eliminated through best practices vs. complicated products
  • If attack tools used are understood, some specific mitigations can be designed

Stack Finger-print


Recon Scan


Serv. Finger-print







Media Inject.



at the edge sbc
At the edge SBC

Inspect, Block, and Limit with an SBC

    • Inspect & block invalid messages with IP & SIP format inspection, thresholds & blacklisting by trust level on per IP basis, rate limitations, access control lists, known attack tool signatures, etc. Enforced at the SBC hardware level by specialized ASICs.
    • Next protect against floods of ‘valid’ calls. Understand that all valid looking messages will make it to internal services if thresholds are not applied.
    • Call admission controls for number of valid calls to services interface and next-hop downstream (or upstream)
    • Message rate limitation by SIP method to limit call setups also by interface and next-hop
  • Local routing tables for routing based on SIP message or dial-plan
    • Blacklist from known fraudulent number prefixes if business model allows. Blacklist should include prefixes outside of valid dial-plan and contact country codes (if possible). Known fraudulent numbers are available through CFCA or GSMA membership.
    • Where possible, blacklist all, and whitelist known from numbers (ex: contact center transfers)
real time call analysis at the edge palladion
Real-time call analysis at the edge - Palladion

Use call analysis software to identify potential attacks

  • Traditional fraud detection systems are CDR based after the fact which yields long reaction times
  • Watch real-time SIP signaling for patterns to identify start of TDoS and fraud with Palladion real-time communications monitoring software.
    • Overall call volume
    • Time of day distribution
    • Calling patterns by geography
    • Inbound or outbound call ratio changes
  • Traffic collection from SBC or COTS server based probe
  • Look at traffic before normalization/removal of attacks.
  • Scale monitoring to allow analysis of floods (‘wire speed’)
at the service
At the service

Harden and limit unnecessary services

  • Follow vendor hardening guidelines
  • Don’t put PBX admin interface on the Internet
  • Don’t use three digit extensions (default for SIPVicious); Consider five or more digits
  • Limit (or eliminate) voice features that aren’t used like call forwarding, voicemail callback, and dialing out from voicemail
  • Block international dialing when possible, or limit dial-plan scope
  • Delete or administratively disable unused extensions
  • Audit user passwords by trying to crack them
  • Use TLS/SRTP with mutual certificate authentication over untrusted links
stopping tdos with your peers providers
Stopping TDoS with your peers / providers

Understand the threat profile

  • Have tools for identifying and blacklisting IP(s) and/or phone numbers conducting TDoS (SBCs & comm. monitoring software)
  • Expect attack adaptation to evade your filters.
  • Have clear escalation contacts for responding to attacks (DoS or TDoS). Blocking IP(s) or phone numbers will only last so long, and you need to move prevention to a prior hop.
  • Understand how your service provider deals with nuisance calls vs TDoS. Nuisance calls may require a police report.
  • Place value on business reputation. Deal with providers, peers and interconnect carriers who can articulate what they’re doing (or planning on doing) to identify and shut down TDoS sources on their network.