VOIP Security in 2020 – How to Defend Your Right For a Defensive Telephony Network

When seeking for SIP Trunks, or “Cloud PBX” or “Cloud Phone systems”, they are mostly provided by an Internet Telephony Service Provider known as an ITSP, believe it or not. Some coaxial ISPs like Comcast Business, Charter/Spectrum or Cox will also bundle this for their “Business Class” offerings. SIP would not work to scale on DSL, better on bonded T1 lines. While the Internet (the data/web) is considered to be Title II of the FCC regulations, the FCC has put some conditions to VOIP service providers. Your freedoms are not well as celebrated in theory like the ol Part 68/Carterfone ruling; because of the provisions the FCC put in as well as Kari’s Law for Enhanced 9-1-1 services (let’s not touch that anymore.)

I acquired these Polycom phones from a local business that was relocating. I grabbed them without really the intent of actually using them because it’s Polycom and it’s VOIP and the two together is an oxymoron, because I started to realize how bad SIP was. What’s concerning was when I took these phones, I realized they were connected directly to Comcast Business, and while today IP Polycoms are in the mainstream, the lack of any firewall protection is concerning for the overall security.

As a customer (and not a consumer); you can throw-away-the-script by using phrases like

“How are these phones going to connect with my existing network?

“What concerns should I have with security?”

“Wait, I am responsible for something right?”

“I have a SIP Proxy being implemented, and my ‘IT Manager*’ telling me we need this interconnected or we’re done!”

*he doesn’t exist because the person that’s talking, has a part time IT manager in their role!

The best way of scoring deals is to do reversed-sales tactics, and go on the offense as your best defense. Put the sales person in the call center into the fetal position (ok that’s too far) but in a way to get a higher up so then you’re holding the sales person at the ISP or ITSP accountable. This is how customer service used to be, then they went “consumer” (or dumbed-it-down) to then force the customer, the not so well versed communicated type to do anything the enterprise class ISP would tell ’em to do.

Even better, throw a Service Level Agreement to ensure if the imaginary lines go down in the packetwaves, that you can get credited in the next billing cycle for loss of potential revenue. Make sure you can reproduce the problem so you can ensure you did your part.

#

VOIP Security in 2020 – More Concerning Than Ever Before

I don’t intend to scare any potential readers with my written work, however it’s something people need to be on alert. Particularly on a specific technology, not the protocol/service itself.

Voice over IP or VOIP (sometimes spelled with the tacky “VoIP”, pronounced as Vo-eye-pee) is a technology that puts mostly telephony over the open Internet Protocol (hence the IP part of the acronym.)

IP dates back to the early 1980s and it’s offspring to the original DARPAnet that began as a Defense Department project in 1969 to have some form of a communications network in case the Soviets or some other rouge country had bad intentions against America.

Oh this phone is so sexy… and cheap! (And perhaps a bit insecure for our 300 lines we will be acquiring?)

IP then and now is a fragmented protocol, with billions of devices traditionally tied to firewall or Network Address Translation, that is better known as a “router”, so on the wild Net, what it sees is mostly machines and rarely users; except at the application level of the OSI Layer. In reality TCP/IP is your device’s driver to interconnect with other devices like the sound driver enables you to hear things on your machines. 

VOIP is mostly an application, and the IP Phones are really desktop sized streaming devices that replicate that ol telephone that was invented by either Alexander Graham Bell, or Elisha Grey or Thomas Edison.

When VOIP became popular in the enterprise in the early 2000s, the security and reliability had been a concern. “Pure IP” vendors like Cisco came from data point of view so  they felt routing telephony should be routing like accessing the Web. Early on some large-scale implementations had some major failures. Some were bone-headed from the phone guy’s point of view, and some were reliant on Microsoft Windows Server (other vendors probably laughed at Cisco.)

The issue then was a lack of encryption, lack of basic controls such as binding IP addresses for specific services, etc. Earlier versions of VOIP used proprietary protocols, and vendors like Avaya, Nortel and Mitel implemented their hard-wired telephony protocols on top of the “IP stack” (again like a plugin to that driver metaphor”.) VLANs along with firewall policies ensured that VOIP networks would be seen by the IT or phone guy and not a co-worker in accounting.

If a bad guy wanted to get into the phone system, s/he would needed to know the IP address of the server, or gateways, and manipulate the system at that point.

Problem Met Another Problem Without a Simpler Solution

Within the VOIP ecosystem, there was that proprietary way known as H323 (this is a signaling protocol of how the VOIP sets talked to the routers and servers) and then there was Session Initiation Protocol or SIP.

SIP decentralized the telephony networks by putting a switching like system on every device; and took the Web playbook for signaling the servers and gateways, and streaming audio and even video through the hand or headsets. Even that, it could support instant messaging or chat services, since the devices were chatting to each other via text, why can users?

The one thing I left out with H323 vs SIP, was, either a hostname or an IP address with H323, and with SIP it requires a server for authentication, another server for “proxy” another one for an emergency (ala 9-1-1), and another for time of day, and another set of IP addresses or Domain Names for “provisioning” to send all those stuff to the sets.

It also enabled the customer to the standard 19 Custom Calling Services features that in the old consumer landline world would cost a fortune. Any “PBX” type of features has to be “extended” from the vendor, say a Cisco, or Avaya.

SIP was great for long haul trunking between the phone company and the customer, or even inter site linking, since SIP did Caller ID well, if you had played around the graphically enhanced distro of Asterisk, Free PBX, the phrase is used very liberally.

As with any technology or service, without any baseline of historical context, the only thing SIP could relate was the unrelated H323 standard. SIP is open, meaning any vendor that adheres to the Request for Comment/RFC for SIP could theoretically work. Early on in the development of the endpoints (the “phones”) the prediction was you could go to BestBuy or RadioShack and buy a phone off the shelf and bring into the office. While those places did (or does not) carry them per se, but any eBay or Amazon store you could buy a $59 single line set and plug it into a SIP controller in the office and hello to BYOD.

Improper SIP Deployments can be a Threat to Small Businesses 

The issues in the early 2000s involved H323 and proprietary software and servers. A lot of what caused H323 issues then were taught later (such as admin web pages to stay local and not be exposed to the open Internet, or remote users requiring log in through VPN compared SIP could be logged in from anywhere; which is why it’s successful)

Many traditional Nortel, Avaya small end systems that serviced customers less than 30 stations have been replaced Key Phone Systems  “for a little more” or “better off” going a cheaper path to “Cloud PBX” systems. Most small businesses are using store bought technology (which is a whole other issue that would be beating a dead horse); worse is that these devices, Polycoms, Grandstreams, alike are likely directly connected to the Open and Wild Interwebz. If you work in an office with over 255 PCs, typically the DNS address is going to be something like a 172.16.1.x or 10.0.x.x) and not an 8.8.8.8 because if every PC and every device had that; it would stress out the network with every device pinging Google to get onto Facebook.com that then turns into Facebook’s public IP address when using browsers or apps.

For SIP deployments, these devices are going directly on the Internet and not some middleman in the datacenter or server closet. This is how many of the VOIP Phone Spam or Prank calls on steroids occur. There needs to be some device at where the Wide Area Network, WAN or “the Internet comes in” such a enterprise class firewall or a proxy server. All SIP calls would “originate” from this box. Unlike H323 or the traditional phone system, it’s not “the brain” per se, but it controls the quality, security and the “noise” that SIP devices would talk to each other if it’s going to Comcast Business or RingCentral. These things are called SIP Proxy Servers or firewalls, they aren’t “private” per se, it’s a hybrid of a multi line phone system meets the customer premise equipment like those T1-landline adaptors, or straight up modems. They can come in various shapes and sizes. You may need more servers/devices for redundancy. Cisco’s IOS routers have some level of support. If you have virtualization like VMware, you could run this as an instance, or if you have PFsense firewall, there is built in packages to do that.

In 2020, you wouldn’t plug your computer into a modem like you used to in 2002, so why would you do this to an IP enabled phone?

#

Session Initiation Protocol – The Secrets, part two

For the end user level, SIP telephones can do cool stuff that couldn’t be done on “office phones” prior to.

One for the first time since ISDN, office grade sets can interconnect without the expense of a large PBX  system. Some can work in Peer to Peer fashion.  BUT, don’t believe in this entirely just yet.

They work in basic modes when it’s off the H323 network, if the Avayas, the Mitels and the Ciscos have “dual modes”. You have to toggle this in it’s basic configuration. Continue reading