Technical White paper                                                   www.balabit.com




          VoIP and the SIP pro...
Table of contents



Table of contents
Preface...............................................................................
Preface



Preface
This paper discusses the concepts used in Zorp to support the Session Initiation Protocol (SIP) for
Voi...
Introduction



1. Introduction
VoIP is the hype these days, and the number of individual users and organizations making p...
Introduction


separate – embedded - protocol called Session Description Protocol (SDP) used to describe the channel and
t...
General considerations



2. General considerations
This chapter details some basic security measures to take when having ...
The Zorp SIP proxy module



3. The Zorp SIP proxy module
This chapter discusses the features and capabilities of Zorp's S...
The Zorp SIP proxy module


packet filtering. These forwards are dynamically created and deleted by the SIP proxy, therefo...
Upcoming SlideShare
Loading in …5
×

SSH auditing and forensics

385 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
385
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

SSH auditing and forensics

  1. 1. Technical White paper www.balabit.com VoIP and the SIP protocol Synopsis: How Zorp's SIP proxy secures your network Status: Released Version: 1.0 Date: 07/06/2006 Introduction © 2005 BalaBit IT Security
  2. 2. Table of contents Table of contents Preface.............................................................................................................................................................3 1. Introduction...................................................................................................................................................4 1.1. About the Session Initiation Protocol in a nutshell.................................................................................4 2. General considerations.................................................................................................................................6 2.1. Isolating VoIP........................................................................................................................................6 2.2. Access and media control of VoIP.........................................................................................................6 3. The Zorp SIP proxy module..........................................................................................................................7 3.1. Introduction to the Zorp SIP proxy.........................................................................................................7 3.2. Internals of the SIP proxy......................................................................................................................7 www.balabit.com 2/8
  3. 3. Preface Preface This paper discusses the concepts used in Zorp to support the Session Initiation Protocol (SIP) for Voice over IP (VoIP) telephony. Although the topic is discussed mainly from the Zorp application level gateway point of view, it was written to be useful also as a general reference. Apart from Zorp administrators and IT security experts, this paper is intended for everyone interested in Internet (and particularly VoIP) security. Basic knowledge about networking and firewalls is useful, though not required to fully understand the contents presented in this paper. The procedures and concepts described here are applicable to version 3.1 of Zorp. www.balabit.com 3/8
  4. 4. Introduction 1. Introduction VoIP is the hype these days, and the number of individual users and organizations making phone calls, video conferences, etc. using the Internet is constantly on the rise, just like the number of available VoIP devices and software. However, this rapid adoption of VoIP in production environments raises concerns as VoIP devices and protocols are rarely designed with security in mind – new features are implemented and used without considering and solving their security issues. All this leads to poorly implemented and buggy applications concerned only with (inter)operability, leaving the VoIP phones prone to malicious attacks. To make life a bit even more miserable (at least from the security point of view), VoIP traffic is usually not encrypted, thus easy to eavesdrop. VoIP can also be used to transfer several different kinds of media, including voice, video, files, etc. The VoIP devices have to be accessible from the Internet – signaling messages (i.e. incoming calls) and voice/video traffic have to reach them. These incoming connections are initiated from the external network, the widely used “only connections initiated from the intranet are allowed – incoming connections are rejected” policy does not permit VoIP traffic. However, since VoIP devices usually reside on the same network as servers and workstations, a compromised VoIP device can be a very good starting point to compromising the whole internal network of an organization. From the above considerations it is apparent that the proper protection of VoIP devices is a must, and Zorp's SIP proxy lends a helping hand to this task. 1.1. About the Session Initiation Protocol in a nutshell Although there are several different VoIP protocols, Zorp supports only the use of the Session Initiation Protocol for VoIP communication, because so far it is the only one that was standardized by IETF. Since the interoperability of the different VoIP implementations and systems can also be an issue, it can be said that Zorp supports all solutions based on and conforming to the SIP standard. SIP is a peer-to-peer protocol providing call processing functions and features similar to public switched telephone networks. The SIP protocol (or protocol family rather) is not a conventional Internet protocol, because it is not based on the traditional client-server model. Although there are prioritized servers for performing certain tasks, in most cases SIP phones function as both clients and servers on the network. Consequently, the protocol does not use the usual request/response based communication, and that has important consequences in perimeter defense. The devices involved in SIP communication can have several different roles, but a single device can play the part of different roles at the same time. The most important roles are briefly summarized below: • User-agent: The phone itself. In the traditional model, this would be called client. • Registrar: The registration service. The address where a particular user-agent is accessible is registered here. It acts as a sort of “name service” for the protocol. • Proxy: This device transmits the requests of the user-agents. It has nothing to do, and is not to be confused with a proxy firewall or with a web cache proxy. • Presence server: Similar to the registrar; this device stores information about the availability of the user-agents. Users can monitor if the VoIP devices of their contacts (friends, business partners, etc.) are active (i.e. on-line) via the presence server. • Back2back user-agent: This is a special proxy implementing the functions of two user-agents. On one side of a connection it acts as the caller, on the other side as the called party. SIP is only involved in the signaling part of a communication session, and relies on other protocols to perform the actual data transfer. SIP communication takes place in multiple channels: one is the signaling channel, the other one the actual data channel used to transmit the voice and/or video data. This latter channel is opened dynamically according to parameters negotiated in the signaling channel. The negotiation uses a www.balabit.com 4/8
  5. 5. Introduction separate – embedded - protocol called Session Description Protocol (SDP) used to describe the channel and the type of media used in a session (i.e. the IP ports, codecs, etc.). It is essential for the firewall to understand and inspect the SDP protocol, since it contains all the information required to allow the VoIP traffic pass the firewall. The SDP traffic also has to be modified in case network address translation is performed. To transfer the actual voice, video, or other data, SIP uses the Real-time Transport Protocol (RTP). RTP defines a standardized packet format for delivering audio and video over the Internet, and is frequently used in audio/video streaming and conferencing solutions. From the signaling point of view, it is important to note that there is no client/server hierarchy between the user-agents, only caller/called party. The signaling traffic is usually not transmitted directly between the user- agents, generally proxies and back2back user-agents are also involved. Consequently, signaling messages (for example a request and a corresponding answer) can take very different routes between two user-agents, greatly complicating the secure transmission of the protocol. On the other hand, the RTP session is built directly between the user-agents without the interaction of proxies, though back2back user-agents may still be involved in the transmission of the audio/video data. Therefore a special care must be taken when creating the access control rules of the SIP signaling and data traffic. Apart from making direct voice and video calls, SIP can be also used for instant messaging (SIP Instant Messaging and Presence Leveraging Extension, SIMPLE). Naturally, appropriate devices (user-agents) are required to use SIMPLE, but from the networking point of view there is no real difference between SIP and SIMPLE traffic. www.balabit.com 5/8
  6. 6. General considerations 2. General considerations This chapter details some basic security measures to take when having VoIP devices on the internal network. 2.1. Isolating VoIP Because of the numerous vulnerabilities in the implementations of the VoIP protocols, it is imperative to separate all VoIP traffic from the rest of the network as much as possible. Ideally, VoIP traffic should be directed to a separate network physically separated from the rest of the intranet. Traffic from this VoIP segment to the intranet should be explicitly prohibited by appropriate firewall policies. In certain situations and environments physical separation is not possible; in these cases the VoIP devices should be grouped into a separate virtual network (VLAN) or zone, with no access to the intranet. Naturally, it is possible to create several VoIP segments if needed, with proper access control rules between these segments (but without any of them accessing the non-VoIP devices on the intranet). 2.2. Access and media control of VoIP VoIP traffic should be enabled only to well-defined directions, and only when it is absolutely required. Enabling VoIP just in general without carefully controlling it can negate even the protection of the best firewall. Furthermore, only the required and actually used media types should be allowed: simple VoIP telephones capable only of voice transmissions have little use of video or files, and denying these kinds of media can significantly increase the security of these devices and the network in general. A P P L IC A T IO N L E V E L V O IP C O N T R O L V o IP s e r v ic e e n a b le /d isa b le v o ic e yes / no ZO R P C O M P LE TE v o ic e m a il yes / no P R O T O C O L IN S P E C T IO N v id e o yes / no IN T E R N E T V O IP S E G M E N T O TH E R S E G M E N TS hones V o IP p sk H e lp d e www.balabit.com 6/8
  7. 7. The Zorp SIP proxy module 3. The Zorp SIP proxy module This chapter discusses the features and capabilities of Zorp's SIP proxy, also detailing what kinds of security measures can be realized with its use. 3.1. Introduction to the Zorp SIP proxy The Zorp SIP proxy allows SIP signaling and the dynamic RTP traffic through the firewall without compromising the security of the firewall and the defended network. Ports are dynamically opened through the firewall based on information received in the signaling traffic. The signaling part of the protocol is inspected on the application level for protocol conformance: Zorp's SIP proxy enforces the standards, protecting the network from attacks violating the protocol. This is especially important since SIP clients and even servers are rarely designed with security in mind and many of them have issues from a security point of view. As an application level gateway, Zorp parses, checks, and rebuilds every passing signaling request and response. 3.2. Internals of the SIP proxy The operation of the SIP proxy along with the protection it offers can be summarized as follows. When packets arrive to the port VoIP signaling is permitted, basic access control is performed based on the source IP address of the packets. Each and every request and response is inspected on the application level (Layer 7 in the OSI model). The requests and responses – including protocol elements like headers – are parsed and strictly checked for conformance with the SIP standards. The Zorp SIP proxy understands and enforces the SIP protocol as described in the RFCs. The syntax and length of the various protocol elements (e.g.: length of lines, headers, requests, etc.) is checked in order to repel various attack forms based on malformed messages, such as buffer overflow attacks. The relation of the arriving packets relative to other packets and previous communication information is also inspected. Packets not conforming to the logic and workflow of the protocol (e.g.: responses without requests, etc.) are rejected. This step is important because SIP uses random ports for transferring the actual communication data (the RTP stream, e.g.: voice, video), and otherwise it would be possible to open covert channels through the firewall between machines, not only the intended VoIP communication between the two SIP endpoints (i.e. the caller and the receiver). The payload (SDP) part of the communication is parsed as well and modified if network address translation (NAT) is used. In this case, the addresses and dynamic ports used by the RTP traffic stream have to be modified accordingly. After all these sanity checks the policy settings of the firewall are consulted. Address, media type and header filtering is performed (e.g.: to allow only voice traffic to/from specific addresses). Network address translation is also performed at this step if required. Access control on the RTP stream part of the protocol is performed separately. This is important because RTP and signaling streams can have different access control settings. If SIP servers or a SIP proxy is used on some part of the network, the signaling and the RTP streams originate from different sources. (In such situation, the signaling is originating from the proxy, but the RTP stream arrives directly from the actual client. However, such a situation could also be used to initiate covert channels.) A request or response is only allowed through the firewall if it passes all protocol and policy checks. In this case Zorp rebuilds the message and sends it to the appropriate peer. The Quality of Service (QoS) is especially important in the case of VoIP traffic, voice and video transmission requires connections of suitable quality. These connections do not take up especially large bandwidth, but this bandwidth is continuously needed. Losing a few packets does not affect quality, but large or rapidly changing latency can cause problems, inadequate QoS can render the entire service unusable. For performance and latency reasons the RTP stream (voice/video) is forwarded without L7 processing using "simple" stateful www.balabit.com 7/8
  8. 8. The Zorp SIP proxy module packet filtering. These forwards are dynamically created and deleted by the SIP proxy, therefore it is not possible to exploit them after the communication has ended. Zorp has also the ability to dynamically control the QoS of the data channel based on any information in the signaling part. (For example it could be configured to use different QoS group or priority for different media-types and for different users.) All questions, comments or enquiries should be directed to info@balabit.com or by post to the following address: BalaBit IT Security 1115 Budapest, Bártfai str. 54 Phone: +36 1 371-0540 Fax: +36 1 208-0875 Web: http://www.balabit.com/ Copyright © 2005 BalaBit IT Security Ltd. All rights reserved. For more information about the legal status of this document please read: http://www.balabit.com/products/zorp/docs/legal_notice.bbq www.balabit.com 8/8

×