Categories
Business security voip

SBCs – Maintaining Your Network’s VoIP Security

Session Border Controllers (SBCs) can greatly enhance VoIP security, all but eliminating toll fraud while also maintaining voice connectivity.

Trefor.net welcomes VoIP Week contributor Simon Horton, the Director of Sales, EU for Sangoma.

The term SBC (short for Session Border Controller) is liberally used in the VoIP industry today, but from my travels around the telecom channel it’s clear that there is significant misunderstanding and distrust on the role played by SBCs and when they are required.

The uptake of Enterprise Session Border Controllers or E-SBCs is being driven by the rise of SIP trunking in the UK. The number of ISDN channels (the traditional way of connecting enterprise to the telephone network, using dedicated copper wire) is shrinking at about the same rate as SIP trunking is growing, so assuming that the market size is static my conclusion is that all of the folks leaving ISDN are going to SIP trunking. In addition to the cost benefit, flexibility, and disaster recovery capabilities of SIP trunking, the proliferation of good quality and value connectivity (e.g., leased lines, EFM) is enabling the market growth.

Why SIP is more inherently risky

In the days of legacy TDM connections (Time Division Multiplexing, or the copper wire) phone calls took place on approved equipment connected to private networks run by the telco. Nothing else was connected or could be connected. Contrast this situation with SIP, where the connection could be across a public network or a network shared with data derived from multiple devices. In addition, calls can be placed and terminated across a wide range of devices such as IP-phones, smart phones, desktops, etc.

SIP deconstructed

Before examining how SBCs can help a typical enterprise it’s worth explaining that SIP consists of two main parts. First, there is the SIP protocol that sets up the call and conveys information about that call. Second, there is the media that carries the voice in RTP packets. Both of these streams need to be considered in order to maintain security.

Attacking the SIP protocol could allow a hacker to gain access to passwords and allow an unwanted intruder to spoof calls and allow toll fraud, a hot topic in our industry today. There are other ways that SIP can be disrupted as well. Denial of Service (DoS) attacks can cause packet overload situations where the legitimate SIP messages cannot be processed and hence calls will not progress.

Media can often be tapped into and heard using tools that are readily available on the internet. The media ports can also be subjected to DoS attacks that can disrupt the audio.

The role of the SBC

The E-SBC sits at the edge of the enterprise network and manages all the voice connections made with SIP. SBCs are very feature rich and there is a lot of information out there discussing the many roles and functions that these flexible devices can perform. The SBC will be able to deal with disruptive DoS attacks by dropping packets at the network level before they become a problem. Encryption is also possible so that media and the call setup messages cannot be tracked. In addition, toll fraud is made much harder with the addition of policy control that allows only certain patterns of traffic to proceed as well as only allowing known users and IP addresses to make and receive calls.

Why not a firewall?

Traditional firewalls are great for protecting data networks, but typically they provide inadequate protection for SIP. Firewalls cannot prevent some of the threats identified here as they are not constructed with an intimate knowledge of SIP. Remember those two parts of SIP we discussed earlier? Well, the average firewall cannot tie the two of those together; this is a key component of the SBC so that only the necessary connections are allowed through the edge of the network. A typical firewall also cannot delve deep within the SIP message, ensure its legitimacy, and if necessary drop it quickly before it gets to the IP-PBX and cause damage.

Summary

The recommended best practice is to install an SBC wherever there is a change in SIP network or wherever the WAN connections join the SIP network. A correctly configured SBC can provide piece of mind in that the possibility for toll fraud is eliminated and that voice connectivity will be maintained regardless of whatever else may be happening.

Categories
Engineer UC voip

S3 SBC, rhymes with VoIP, Securitee – Session Border Controller @Genband @Timico

Trefor DaviesYesterday I wrote about our new mobile VoIP App for the iPhone. This included a link to a press release issued by Genband, our VoIP infrastructure partner.

That release covered more than just the mobile VoIP iPhone App. It is a bit of an overall solution release but an important bit covers our acquisition of the Genband S3 Session Border Controller.

The SBC has been a bit of a controversial beast in the world of purist VoIP engineering. It’s purpose is to manage VoIP sessions across different networks. In its earliest incarnation it was used to convert VoIP signalling from the old H323 video conferencing protocol (also used for just voice in older VoIP services) to the more modern and up and coming SIP (Session Initiation Protocol) or perhaps to a variant of MGCP (Media Gateway Control Protocol). As a “border controller” it also grew in functionality as a device used to manage the security of a network.

The conceptual problem of the SBC amongst the early VoIP pioneers was that it operated as a “back to back user agent”. In other words it effectively terminated a signalling stream on input  and started it up again on output. This meant that in the “open internet” it would not necessarily be possible to trace a VoIP signalling packet from end to end as you might be able to do with other non-voice packets using tools such as tracert, the outcome being that it would be harder to debug problematic services.

This was at a time when the theory stated that all VoIP calls would be free heralding the end of the telco and paid phone calls as we know it. This Utopian scenario was underwritten by companies such as Skype who appeared to offer free phone calls to all. Of course to be confirmed and adopted by the general scientific base, theories need proving in practice and even the virulently successful Skype ended up demonstrating that it has to pay for its infrastructure somehow by starting to charge for some of its services.

The growth of the VoIP market1 has also stimulated the growth of a VoIP security sector. There was initially an element of playing on the fears of people entering uncharted technical territories. The fact that VoIP is designed to operate on the DNS based internet2 and functions in a similar way to email and web browsing opens up opportunities for fraudulent activity in the same way that we have become accustomed to such happenings in our general web use. Email SPAM is replaced with VoIP SPIT (computer generated SPAM for Internet Telephony bombarding the world with automated sales messages).  The use of a crawler ploughing through blocks of IP addresses looking for open networks to penetrate is replaced with a search for exposed network based iPBXs that can be exploited for financial gain.

There are many precautions that can be taken to remove vulnerabilities from a VoIP network but if you are serious at security you will want to use a Session Border controller.

A VoIP network, at least if it is to be usable by business, needs managing to maintain its quality and reliability and the SBC plays an integral role in this. The SBC today, far from being the object of criticism of the VoIP network engineer, is the demesne of the grown up Internet Telephony Service Provider. Think of it as a super security tool that secures your network and cements the quality of the service it supports.

Looking at it parochially I’ve been wanting an SBC “to play with” for years, ever since we started our hosted VoIP service. We put a lot of effort into the management of security of our VoIP users but the Genband S3 SBC, covered in the press release, allows us to take this to new heights.

The Genband S3 effectively acts as a VoIP firewall. It manages network access using real-time and aggregated admission control policies. It can, for example, spot and prevent the SPIT attacks referred to earlier.  It will also help Timico as a service provider to control the quality of the VoIP service with capabilities such as the automatic monitoring of network bandwidth rates and capacity.

From Timico’s perspective as a voice carrier the Genband S3 will allow us to hook up with many more interconnect partners because as a border controller it allows us to manage interoperability with different carrier’s kit. The SBC will also provide us with the flexibility to fine tune routes based on both cost effectiveness and quality. For example if a specific route begins to suffer from poor call completion rates the S3 will detect this and intelligently reroute traffic to that destination via a different interconnect partner. The S3 is also hugely compatible with our Genband A2 VoIP platform and will scale to 25,000 concurrent calls that effectively supports a subscriber base of over 250,000 users.

The S3 is relatively new to Genband. It came with the acquisition of NexTone, one of the market’s original and leading SBC vendors. This has brought with it a maturity and pedigree of user base that is not only reflected in its functionality but will quickly help Timico cement our position as one of the leading VoIP providers to the business market. Bit of marketing blurb there but it is actually based on solid engineering principles.

If anyone wants to chat more about our new S3 SBC drop me a line, call or hook up with me via @tref on Twitter.

Ciao.

1 note there will come a time when we don’t talk about it as a VoIP market. It won’t be long before we have to simply describe the world as a communications market which contains a subset known as the old fashioned telecommunications network as championed by the ITU (another story in itself).

2 It still doesn’t fully merge with the domain name system as this would rely on every ISP supporting VoIP on its DNS servers. The principle of domain based routing is still the same for VoIP as for regular web traffic.