In the Patton Security webinar, we explained the three key functionalities of an eSBC: Fraud Prevention, Survivability, and Quality of Service.

Some great questions came up at the Patton Security webinar today and we’d love to share the answers with all of you who may have the same questions! If you missed the webinar, don’t forget to check out the presentation slides here!

Should the eSBC be used with a firewall or replace the firewall?

Answer: The best practice is to put the eSBC on the edge of the network (in front of the firewall) so that it gets the first look at the voice traffic coming into the network.  This is where the back-to-back-user-agent and other VoIP security features can be most effective at detecting suspicious SIP messages, preventing DOS/DDOS attacks, and doing deep packet inspection.  So yes, the eSBC can be used with a Firewall, just don’t put it behind the firewall. I prefer to replace my existing firewall with the Patton eSBC since the eSBC has a built-in stateful firewall.

 

I already have a firewall, why do I need an eSBC?

Answer: Unfortunately, your firewall might not be as strong and reliable as you thought. For example, your firewall won’t protect you from potential hackers who commit toll fraud by hijacking a phone service and placing unauthorized long-distance calls. But an eSBC can!

 

Does the eSBC support transcoding.  For example, can it go between G.711 and G.722HD codecs?

Answer: Yes Patton eSBCs support transcoding as well as the G.722HD codec.  In order to do transcoding just be sure to choose a model that has transcoding listed as a feature.

There are several product families in the eSBC product line; SN5200, SN5300, SN5400, and SN5500.  Both the SN5400 and SN5500 product families support transcoding

 

What is the difference in the models as price increases?

Answer: The price of Patton’s eSBCs scale with the size of the deployment and the types of additional interfaces that may be required.  For example, you can get a pure eSBC with 4 simultaneous calls enabled for MSRP around $500. You can then add additional simultaneous calls for MRSP of $11.00 each.  

In another scenario you may have a need for FXS/FXO or PRI; those ports are available on some models, but are sold at a premium due to the additional hardware resources.  The hybrid eSBCs with that added TDM ports are all reasonably priced and eliminate the need for additional gateways in your network. Everything can be handled in one unit, with the same security policies.

Patton offers a wide variety of eSBC options to fit your business needs. The price point starts at as low as $500. Be sure to visit their product page or read more about how to choose a right eSBC! If you have more questions, call one of our VoIP experts at 1-800-398-8647 today!

We co-hosted a Security webinar Part I with Sangoma this Tuesday and our audience had a lot of questions regarding SBCs, VPN, dynamic IPs, PBX and other security issues. We would like to share the Q&A session with all of you who may have the same questions!

Also, don’t forget the Security Webinar Part II is coming on February 6th! Register early to save your seat!

1. For the session border controller if we have any IPS static do we need one? Then we wouldn’t have ports open to the entire world but only from specific?

Answer: This will protect you as long as your users do not have infected devices at that IP address. Putting a SBC into the equation ensures that only the traffic you want passes onto your network.

2. What if you use a VPN? Do you still need a SBC?

Answer: VPN will secure the device (in this case the IP phone), but you are still opening up ports for your SIP provider. You must also consider the fact that your user may connect an infected PC or Laptop to that phone, which would now have a secure connection directly to your LAN. The same thing applies if your users are using a softphone over VPN using an infected device.

3. If we use remote phones and they are on dynamic IP’s or travel then we should be using an SBC?

Answer: Absolutely.

4. I would imagine VPN from endpoints to PBX, like OpenVPN with the Sysadmin Pro module. So if I have FreePBX, Sysadmin Pro module with Sangoma phones running OpenVPN, what does adding the SBC get me? SIP trunks, like Bandwidth or Flowroute. The PBX is hosted.

Answer: VPN will secure the device (in this case the IP phone), but you are still opening up ports for your SIP provider. You must also consider the fact that your user may connect an infected PC or Laptop to that phone, which would now have a secure connection directly to your LAN. The same thing applies if your users are using a softphone over VPN using an infected device.

5. What if our phone system is cloud hosted. Do we need an SBC?

Answer: Yes. Since you would need to open ports on your firewall to allow SIP traffic thru to your phones.

6. If you are using HA do you need 2 SBCs?

Answer: Since the two PBXs are on the same network, you would only need 1 SBC.

7. What if the SBC fails in the field.  Do you need a hot-swappable or can you run the system without the SBC?

Answer: A system will run without it and hopefully your backup security strategies will protect you until you get another SBC deployed. If security is your number 1 priority you should have a backup if your budget allows for it.

More questions? Utilize the comment box below to ask our VoIP Experts or simply raise your phone to contact Brian Hyrek at bhyrek@voipsupply.com or 716-531-4318!

mobile-phone-1875813_1920VoIP security is a hot topic, and rightfully so. A compromised system can cost you $$$ in phone bills, so how do you prevent a breach? Well, the answer isn’t as complicated as you’d expect. There are a lot of opinions floating around on the subject, so let me address some truths and falsehoods that may be of importance when securing your VoIP system.

 

Fiction: You NEED a session border controller (SBC)

If you are a small business or are installing a VoIP system in your home, there is no need for an SBC. An SBC is a great device (or virtual appliance) because it masquerades your internal VoIP infrastructure. In basic terms, a SIP trunk from a provider terminates to the SBC, which then connects to your phone system via a SIP trunk.  The SBC acts as the middleman in the transaction. To an outsider, SIP header information sources from the SBC and not your internal equipment. Although an SBC is a great extra layer of security and reduces overall attack vectors, it’s not required to make VoIP reliably secure for the majority of small deployments. Terminating a SIP trunk directly to your phone system behind a hardware-based or virtual firewall provides the security that would be deemed required to keep you incurring fraudulent toll charges.

 

Fact: You NEED a firewall

On the same topic as above, if you are going to be using SIP trunks to talk to the outside world, you’ll need a hardware or virtual firewall appliance to secure what is allowed in and out. In addition to the basics of protecting SSH, Telnet, and HTTP/HTTPS access to your phone system, you should always restrict what IP addresses can communicate directly to the phone system when it comes to SIP, and IAX (if you use it). What that means is only allowing IP addresses from your SIP provider, any remote extensions, or remote branches. Never ever expose your system directly to the internet without some type of firewall in front of it.

 

Fiction: Remote extensions MUST use a VPN

This is not true but isn’t a bad idea. A VPN will allow you to bypass NAT, which is the culprit in most one-way audio issues. The trick here is to tell the phone system all of the local IP subnets that it will be talking SIP. You’ll find this to be configurable on just about every Asterisk based phone system. A VPN also allows you to encrypt your session if you’re worried about the NSA listening in. An alternative would be using TLS and SRTP without a VPN, but you’ll just lose the benefit of avoiding NAT. The best way to securely deploy remote extensions is to use either a VPN or TLS. If you’re not using a VPN, make sure to define your inside IP subnets (as mentioned before), as well as your external IP address. These are all also configurable on just about any Asterisk system. Make sure you port forward SIP and RTP in your firewall to your phone system and secure your inbound rules by source IP addresses. Every system is a little different, but most Asterisk systems use 5060 UDP (SIP), and 10000-20000 UDP (RTP).

 

Fact: VoIP is NOT set it and forget it technology

If you’re going to take on the task of managing an IP phone system in your IT infrastructure, you need to adopt the mindset of monitoring it. Especially if you have port 5060 open to the outside world, you need to be logging and enabling alerts. In the past, phone systems have been bolted to a wall in a closet that no one ever went into except the PBX vendor. Now your system is racked next to your switches and servers. For those of you who are FreePBX users, Sangoma has just started to release their RMS platform, which simplifies centralized remote monitoring of multiple FreePBX and PBXAct systems. Stay tuned for a review on this!

 

Fiction: Not using port forwarding makes your phone system more secure

This isn’t actually a common belief, but it comes from a post I recently read on Spiceworks. It was claimed that a system has been made more secure by not forwarding port 5060 UDP from the firewall to the actual PBX. If this configuration was actually working, it was a minor miracle. The fact is there are usually two components of sending SIP traffic through your firewall. There is a firewall rule, allowing the traffic, and a fixed NAT association with the protocol and a device within your network. As long as you’ve made appropriate rules allowing SIP to your system, the port forwarding is simply a mechanism to help keep consistent NAT associations. In general, SIP and NAT do not play well with each other. Pro TIP: when you experience one-way audio, always look at NAT first.

 

Fact: You do not need to restrict RTP traffic to specific source IP addresses

I bet you never thought of this one. If you have, bonus points. While you should ALWAYS restrict SIP traffic by source IP address, it’s not necessary to do so with RTP. RTP is simply a media stream and doesn’t have the capability of initiating a SIP session, or any kind of session. Dare I say, you can leave the RTP port range open on your firewall. However, it doesn’t really hurt anything to place a source IP restriction on it.

A website based in Russia is broadcasting live video streams from private cameras around the world says Simon Rice in his blog for the Information Commissioner’s Office in the UK.

Any camera-enabled device such as webcams, laptops, tablets, baby monitors, and cell phones are all at risk.

They’re gaining access just by using the camera’s default password that’s set up by the manufacturer which is easy enough to find anywhere.

Even we’re guilty of sharing this list from IP Video Market in this blog post way back when, but it was for nefarious purposes.

If you don’t want someone spying on you, Rice advises these three things:

  1. Change your default password!
  2. Review all available security settings on your camera.
  3. Secure any device that’s connected to the internet.

Read more here in his post, Is someone watching you right now? A warning as website targets insecure webcams.

And if you’re still not convinced you should protect yourself, check out this post on Gizmodo, A Creepy Website Is Streaming From 73,000 Private Security Cameras.

Via Information Commissioner’s Office Blog | Gizmodo

 

Asterisk VoIP Security

When I came across a blog on Huffington Post that called Asterisk out on the security of their open source VoIP platform I just had to know, is this true?

So I asked Asterisk (after I said “asked Asterisk” five times fast) and got this detailed response from David Duffet, Director of Worldwide Asterisk Community.

Duffett (@dduffett) explains that protecting your network is a not whole lot unlike fortifying your house against break-ins.

VoIP Supply: Who is the Asterisk VoIP platform designed for?

David Duffet: The Asterisk IP communications engine is for anyone that wants to create a flexible and powerful communications solution. Asterisk configuration is performed through a number of ascii text files, and this is why a number of pre-packaged IP PBX solutions based on Asterisk have become available that allow configuration via a web GUI.

VS: Why open source?

DD: When Mark Spencer (the creator of Asterisk and CTO of Digium) decided to make Asterisk an open source project, he did this in part to liberate the stodgy, closed world of telecoms, but also to allow (and encourage) contributions to Asterisk from people all over the world that are particularly keen to see Asterisk enhanced in specific directions (like conferencing and contact centre applications).

VS: In this blog post on Huffington Post, 6 Keys to a Successful VoIP Implementation, the writer, Jason Volmut (@javolmut), CEO of CPUrx, states that:

“VoIP systems built on the open-source telephone platform Asterisk are routinely subject to hacking attempts, and should be avoided. “

What VoIP security measures can Asterisk take to secure their systems from hackers?

DD: Although there are a number of places within Asterisk that could be configured to enhance security, I would like to make some more general points:

The mention of only Asterisk in point 5, regarding security, is extremely misleading.
To set the scene, PBXs, even before the advent of IP communications, have always been subject to attacks of one sort or another – all the way from people trying to hack into voicemail boxes to full scale toll fraud through PRIs or even analog lines.

*ANY* SIP IP PBX that has an open connection to the internet (i.e., not within a VPN, or not tied down to a specific IP address, or addresses) will be subject to hacking attempts.

" Just like any type of system – it’s all in the implementation. If that is done in a sloppy way, it could lead to trouble." - David Duffett, Asterisk
” Just like any type of system – it’s all in the implementation. If that is done in a sloppy way, it could lead to trouble.”
– David Duffett, Asterisk

Asterisk is certainly the most popular and established open source communications engine in the world, with millions of Asterisk-based IP PBXs out there – but they are by no means particularly prone to issues of this nature. Just like any type of system – it’s all in the implementation. If that is done in a sloppy way, it could lead to trouble.

There is lots of information around on the internet about certain brands of proprietary IP PBXs and potential vulnerabilities, but to focus on the PBX is to miss the main point about securing IP systems – and that is to ensure proper measures are taken at the network level, before thinking of applications running in the network like a PBX or a CRM system.

If you found a robber in your kitchen, you know that he would have broken into your house through the front door, back door or a window. The best thing to do would be to improve the security on the exterior of your house so as not to let the robber in! And so it is with your network… Stop the bad guys getting into your network in the first place!

Anything you can do in a given appliance or application like an IP PBX or a CRM system should be seen as a secondary line of defence.

Due to the power and flexibility of Asterisk, there are actually more things you can do on an Asterisk PBX to detect and prevent any form of compromise than there are on any other PBX solution. Of course, they must be implemented and adjusted by people that know what they are doing.