How SIP Aware Are You?How SIP Aware Are You?
SIP trunking requires its own brand of due diligence for security.
March 6, 2015
SIP trunking requires its own brand of due diligence for security.
How many holes are in your network? You may want to review your SIP phones to determine whether or not you've really protected the fort. Anything with a Web interface is vulnerable, and even if you think it's locked down or just not a big deal, you're probably in for issues ahead.
Recently, someone disclosed to me how much he "loves" a certain hosted phone service because it is so easy. "Love" and "easy" only go hand in hand until problems occur.
Here's the thing: While most hosted providers do lock down the admin login, some do not do the same for the user login -- and yet those logins often end up getting posted all over the Web with default passwords, documentation, and fixes/workarounds posted for most gear. That leaves non-hosted and self-servicing customers maintaining Asterisk and other platforms having to make sure their logins are absolutely secure. But that can lead to the question: In doing so, are you taking away responsibility or features from the user?
Security Over Convenience
Companies may want to consider that security should trump empowering users with changing their own buttons and data fields -- unless you know for certain that granting them the rights to user login poses no vulnerability.
How, for example, are you going to defend against SIP attacks and SIPVicious scanners? Protecting against those is possible by setting access control lists to accept SIP traffic from only your provider's IP addresses and the ports used. This will lock down your firewall.
And how are you going to patrol SIP desktop phones used by telecommuters at homes and other off-site locations? The answer may be you don't, you can't, or you already are defending their connections using VPNs and other solutions.
I recently pondered these and other questions after observing something odd in a firewall log. About every minute, a SIP phone on one network node pinged a desktop workstation on another node located across the network . Now why would a SIP endpoint be pinging a workstation at a different location across the network?
Segregating SIP
When a desktop computer and phone share one cable and reside in the same LAN, the first thing that comes to mind is to place each in its own virtual LAN. But many organizations simply place all switch ports in trunk mode ease moves, adds, and changes. You can add a layer of security by taking the extra step and removing the default access to all VLANs from all ports by granting specific access for each port to specific VLANs. The router/firewall controls routing between VLANs, and enables policing of each VLAN's traffic provided the interfaces are available on the platform.
However, you may have SIP endpoint management issues depending on whether you've acquired your phones through a distribution channel or directly from the service provider. Service providers will back out of support for any devices purchased outside the relationship or if you insist on managing your own endpoints by having control of admin and user logins. Providers don't want the risk of compromise, and this is an area of responsibility that many are not willing to waive.
Using firewall-level application-aware restrictions doesn't ensure security because that could prove a shotgun approach that ends up preventing other applications and services from working. Because hosted telephony services often have many ports, they require careful evaluation as to whether or not they pose a specific risk. These efforts need to occur during the evaluation process and require mapping out in detail any relationships between desktop/laptop computers and telephones or softphones.
This is where I think the session border controller (SBC) is more important than ever, for both service providers and enterprise organizations. Retail VoIP is akin to the Wild West, and simply plugging a SIP phone into a network connection doesn't guarantee good results. The SBC gets specific traffic to where it needs to go, unlike VPNs that will timeout and often not renegotiate yet appear connected but not functioning. The qualifying question is: For which SBC is the hosted platform configured? Questions on supporting details and discovery information should follow.
The key idea is that traffic is complex, and creating many barriers to entry is a best practice. As communications expert Andrew Prokop wrote in his recent No Jitter post, "A Primer on Communications Security": "You can't apply security in just one place and be done with it." SIP-aware firewalls are not enough to maintain and enforce viable security in a complex interconnected environment that demands real-time communications in many applications and devices to many destinations and services.
Follow Matt Brunk on Twitter and Google+!
