Securing VoIP networks
Experts agree that one important step in the quest for VoIP security is to separate the VoIP network from the ordinary LAN traffic. The complex and relative insecure nature of computer networks adds many opportunities for eavesdropping and other forms of attack, and seasoned admins are well aware that physical access is more or less identical to a hacked system.
To isolate the VoIP network, use physical separation or even a virtual LAN (VLAN) configuration. Of course, separating VoIP traffic will not protect you against physical access by an attacker who connects to a free port of the voice network. (If a port is accessible, the attacker can simply hitch up a laptop and spoof a phone's MAC address.) The best way to combat this kind of local intrusion is to use additional 802.1x   authentication against the switch.
To ensure secure VoIP communications with the enterprise system for road warriors, it makes sense to route the connection via a VPN tunnel. This setup should support low-bandwidth codecs, such as GSM (Global System for Mobile communications) . As an alternative, you might prefer to use SRTP and SIPS--S/MIME, if clients and servers support this option, because of the lower protocol overhead.
Figure 5 shows a combination of the techniques discussed in this article in which the VoIP infrastructure is isolated from the remaining system. The link between the sub-branch and head office uses one or multiple VPN tunnels. (When forecasting the bandwidth, it is important to take the VPN protocol overhead into consideration.) The PSTN (Public Switched Telephone Network) connection can be handled separately at each branch or routed via the head office. A failover link for each branch is a good idea. This keeps your branch offices reachable, even if the IP connection fails or is overloaded.
If you are thinking about adding a voice component to your network presence, it makes sense to plan your approach to VoIP security before you begin. The hardware and software tools of the VoIP environment provide a number of interesting security options. First determine which protocols and components you need for your VoIP network, then shop for tools that provide the necessary support. Table 1 shows the results of our research into the compatibility of phones and VoIP appliances by various manufacturers.
If you already have a VoIP network, simple techniques such as VLAN isolation and strategic use of available encryption alternatives will help you build a better and more secure environment for VoIP communications.
- SIP standard, RFC 3261: http://www.ietf.org/rfc/rfc3261.txt
- SDP standard, RFC 4566: http://www.rfc-editor.org/rfc/rfc4566.txt
- RTP reference: http://www.voip-info.org/wiki-RTP
- SIP, SDP, RTP, and NAT: http://swik.net/SIP/del.icio.us+tag%2FSIP/Intruduction+to+SIP%2FSDP%2FRTP+and+NAT/bd1m0
- SIP security: http://www.cisco.com/en/US/docs/ios/12_3/vvf_c/cisco_ios_sip_security_application_guide/sipsecov.html
- TLS: http://en.wikipedia.org/wiki/Transport_Layer_Security
- S/MIME: http://en.wikipedia.org/wiki/S/MIME
- Secure RTP: http://en.wikipedia.org/wiki/Secure_Real-time_Transport_Protocol
- SIP, RFC 3893: http://www.ietf.org/rfc/rfc3893.txt
- RTP, RFC 3550: http://www.ietf.org/rfc/rfc3550.txt
- MIKEY, RFC 3830: http://www.ietf.org/rfc/rfc3830.txt
- ZRTP: http://zfoneproject.com/zrtp_ietf.html
- Skype survey: http://www.anagram.com/berson/skyeval.pdf
- The TLS protocol, RFC 4346: http://www.ietf.org/rfc/rfc4346.txt
- 802.1x authentication standard: http://en.wikipedia.org/wiki/802.1x
- 802.1x and attackers on the same port: http://searchsecurity.techtarget.com/expert/KnowledgebaseAnswer/0,289625,sid14_gci1268965,0.html
- GSM communications: http://en.wikipedia.org/wiki/Global_System_for_Mobile_Communications
Buy this article as PDF
Linux Foundation's big event celebrates the 25th anniversary of Linux
Competitors get in the game with RHEL without Red Hat
Security researchers have already notified Microsoft; some fixes are available
The company is collaborating with Google and Intel to use Kubernetes as an engine for Fuel
Customers can take a free test drive of SLES for HPC on the Azure Cloud
San Francisco-based chip company announces their first fully open source chip platform.
The whole distro gets rebuilt on glibc 2.3
Ubuntu Vendor tries to solve app packaging and distribution problem across distributions.