Planning VoIP deployments
(WINDOWSNETWORKING.COM)
This article discusses management of the VoIP PBX, and proposes that it be treated as another service which should be comprehensively managed by the network administrator. It will demonstrate how Voice connectivity relates to data networks and how to effectively and securely implement a PBX within the context of a network infrastructure.
Convergence
Network administrators now have multiple, varied methods of communication running on their network. Whilst protocols and services such as web and email, SMTP and HTTP, are well understood and the techniques for securing these are widely known and discussed, VoIP understanding is often lacking. With the convergence of voice and data networks comes the convergence of roles within an organisation. IT and Telecoms staff are not distinctly separate and there can be an overlap in roles. This can often lead to misunderstandings by staff who make assumptions about systems that they are not familiar with, in environments they are not used to.
This however does not mean that handling voice and data communications need to be complex and hard to understand. In fact, due to the convergence and the fact that VoIP necessarily uses IP, which is also the basis for our data network, we need not treat VoIP infrastructure any differently than our data infrastructure. By looking at common network setups we will see how easy it is to design a secure and stable VoIP infrastructure by using similar principles to those employed in the design of data networks. The principle example we will discuss here is that of Front End and Back End servers, common in the use of e-mail amongst many other applications.
The entry points
When discussing the security and accessibility of a service within a network, a lot of our focus is on the entry points. Questions we should be asking ourselves include:
Where are our users?
- They are on the Internet, PSTN, Internal Voice and Internal Data networks
Where are our threats?
- Every connection point could pose a threat to the others
What connectivity between servers and services are there?
- Incoming and outgoing VoIP over the Internet from/to the PBX (SIP/H.323/IAX/RTP/etc..)
- Incoming and outgoing calls over the PSTN, via ISDN/T1/E1/POTS
- VoIP clients on the internal data network using the VoIP protocls listed above
- Analogue and digital telephones on the internal voice network
There are other points to consider, but generally we are worried about connectivity, ways in/out of our network and who might be using them. The ideas and techniques employed in the pursuit of data security on IP networks relate directly to a VoIP PBX. Our major added complexity is the fact that the PBX may be the terminating equipment on a telephone line. The consequence of this is that we must treat this device as we would any other such device (such as our border router) exposed to a public network. Therefore, we must not trust traffic at this point and would want to have a firewall and/or intrusion detection system between the device and the rest of our network.
The PBX placement problem
It's very common for a PBX system to be installed directly on the corporate LAN and plugged into the PSTN, and when IP communications are set up these are often allowed directly to the the PBX. See figure 1.
Figure 1: Common (bad) PBX placement
This could present a significant threat to the internal network as the network is not protected from a compromise of the PBX from someone accessing it over the PSTN and has limited protection from the Internet. A vulnerability in our front end (or indeed, only) PBX gives attackers free reign over our internal network, with the only obstacle being the single gateway and firewall/IDS system at the Internet interface.
Facing a similar topology involving mail servers exposed directly to the internet and also connected to our corporate LAN, we would likely be very concerned about the lack of layered protection. We have to ask, therefore, how we can add layers to protect a VoIP PBX, which has connections not only to the Internet but also the various PSTN providers.
A solution which works with other services
While there are a variety of telephony specific devices available to protect our VoIP systems, IP firewall and IDS systems that have VoIP awareness are often overlooked. These should feature in our design plan and help us by adding protective layers between our internal and external systems. Figure 2 shows us, from a data network point of view, how to handle a VoIP system within our infrastructure. For added security we should really segregate this further and have a distinct DMZ for our PBX.
Figure 2: Converging Voice and Data Effectively
Consider the simplified network diagram in Figure 2, which shows a number of distinct network segments and the Firewall/IDS separations between them. More segregation is offered by this topology than by the previous setup, and clearly demonstrates how we can effectively use the technologies already developed for our IP networks to offer protection for VoIP. At this point we haven't deployed anything other than the standard IP based firewall and intrusion detection systems we would use if we were protecting web and email servers. If we examine each segment and its function more closely we can see where our protection fits in.
Internet
From the Internet there are often two sets of users of the VoIP system. These sets are as follows:
* Anonymous VoIP callers - This could be users from other organisations calling our users using SIP/H.323/IAX/RTP protocols directly or they could come through trunks we have set up with third party ITSP's.
* Roadwarrior users who may be logging in to their extensions remotely.
These users can only access the front end PBX directly. This provides our first layer of defence when receiving VoIP calls and is exactly what we would do with web/email and other application servers. We can see examples of these servers in the diagram as an illustration of how similar this setup is to the common backend/frontend setup.
PSTN
Our PSTN connectivity could be made up of any number of T1/E1/ISDN/POTS connections to various telecommunication providers. In a traditional PBX these connections would be plugged straight into our single PBX system with our internal users also plugged into this system. In order to prevent this, in this design, we have proposed using the front end PBX in exactly the same way we would for web and email based systems to help protect the backend from attacks originating outside the borders of our networks. By placing the PSTN segment beside the Internet we can see that they can be treated similarly. Traffic between the PSTN connection and our front end PBX would be our incoming and outgoing telephone calls over our PSTN trunks. For anything to pass further back it would require passing through our back end PBX and therefore a firewall/IDS system.
Front End
Our front end server handles all of the traffic that poses an external threat. It has a direct connection to the PSTN and Internet and will process any incoming connections before passing them deeper in to our network. The front end PBX has an IP based connection such as SIP or IAX trunks to the back end. Any and all communication between these go through a firewall and IDS system before reaching the corporate LAN.
Internal Data Network
This network holds our workstations and other internal data devices. If our workstations have soft phones installed they can communicate with the back-end servers and if they need to make or receive calls with users based outside our LAN (on the Internet or via the PSTN) they do so by having their calls forwarded to the front end PBX for routing.
Internal Voice Network
This network contains our traditional hardware telephones which would likely be plugged directly into our PBX. However now that we have separated our network with front and back end servers, in order for these devices to call a device on any other segment, they must pass through a firewall and IDS as IP traffic.
Summary
A VoIP system, whilst introducing the telephony element to a data network, can still be treated in the same manner we would treat any other service which has an IP component. We have seen here that we can effectively segment and control network access relating to VoIP services using techniques and technologies that are already existant on our network. We can reduce the risks involved in a VoIP deployment by carefully planning all aspects and bearing in mind that half of VoIP is "Internet Protocol".
Reprinted with permission from WindowsNetworking.com.
Article copyright 2006 WindowsNetworking.com. All rights reserved.