RealAudio and RealVideo are proprietary protocols developed by RealNetworks to provide real-time streaming of audio and video data across the Internet. Although the players for these protocols can run as independent applications, they are most frequently used as plug-ins to web browsers. At this writing, these are the most popular protocols for distributing relatively large amounts of audio or video.
The advantage of using them instead of simply distributing audio or video files is twofold. First, if a web browser encounters an audio or video file, it needs to download the entire file before playing it. This can mean a long and extremely boring wait if the file is eventually going to play for more than a few seconds. Few people are willing to hang around watching a transfer progress meter move for 20 minutes in order to watch a 10-second movie. Second, because the files are downloaded, users are not only able to make their own copies, they're encouraged to do so; once they've waited the 20 minutes, they're certainly not going to delete the local copy of the file! If you want to keep track of who's watching the file when, and you don't want copies of it floating around, this is extremely undesirable.
Protocols for distributing audio and video tend to based on UDP because people are more tolerant of having small amounts of data lost than of having pauses. With TCP, if a packet is lost, there will be a wait for retransmission, which is much more annoying than just going on to the next packet. Audio and video protocols also tend to use multiple ports in order to maximize efficiency. Because of these characteristics, these protocols tend to be difficult to support through firewalls.
Running a server for RealAudio or RealVideo is not inherently dangerous; the protocol is a relatively safe one for the server. On the other hand, RealNetworks has had some problems with security, and both the Windows NT and the Unix server have been distributed with extremely risky installations. Be sure that configuration files are not world-writable, that created accounts have appropriate privileges and passwords, and that programs are not running with more privileges than they need. Since the servers represent a considerable load in any case, you may want to dedicate a bastion host to them; that will also help to contain any security problems.
The RealAudio and RealVideo clients have relatively limited capabilities and have not had any known security problems. Because of the way the protocols work, it can be difficult to allow the clients to run effectively without opening large holes in your firewall, which is of course risky. However, the clients themselves are relatively low risk if you are able to safely get the data to them.
RealAudio and RealVideo by default use a system where a TCP connection, initiated by the client, is used for session control, while the actual data is transferred using UDP. Multiple UDP ports may be used for the same session. Because this system is extremely difficult to permit through packet filters without creating significant extra vulnerabilities, it is possible to configure RealVideo and RealAudio clients to use TCP only (on port 7070) or to use TCP accompanied by UDP packets from a single port in the range 6970-7170, specified by the client.
Direction | Source Addr. | Dest. Addr. | Protocol | Source Port | Dest. Port | ACK Set | Notes |
|---|---|---|---|---|---|---|---|
In | Ext | Int | TCP | >1023 | 7070 | [25] | Request, external client to internal server |
Out | Int | Ext | TCP | 7070 | >1023 | Yes | Response session control, internal server to external client |
Out | Int | Ext | UDP | 6970-7170[26] | >1023 | [27] | Response data, internal server to external client |
Out | Int | Ext | TCP | >1023 | 7070 | [25] | Request, internal client to external server |
In | Ext | Int | TCP | 7070 | >1023 | Yes | Response session control, external server to internal client |
In | Ext | Int | UDP | 6970-7170[26] | >1023 | [27] | Response data, external server to internal client |
[25] ACK is not set on the first packet of this type (establishing connection) but will be set on the rest. [26] The client may select a specific port number in this range or may allow the server to choose any port in the range; if the latter, multiple ports may be used for the same session. [27] UDP has no ACK equivalent. | |||||||
RealNetworks provides sample code for RealAudio and RealVideo proxies for use if you would like to have your own. They also have worked with a number of firewall vendors to incorporate the proxy code into products. Using a proxy is the best solution to get reasonable performance of RealAudio and RealVideo through a firewall, since the tricks used to make it allowable through packet filters significantly decrease performance. However, the RealAudio and RealVideo proxies can put a fairly considerable load on a machine.
RealAudio and RealVideo will work with network translation if they are configured to use TCP only; the UDP-based modes use embedded IP addresses. You will need a network address translation system that understands RealAudio and RealVideo to use UDP, but an appropriate module is available for Linux IP masquerading.
Unless you need high performance, run RealAudio and RealVideo clients configured to use TCP only, and permit outbound TCP connections on port 7070.
If you need high performance on RealAudio and RealVideo clients, use RealNetworks' proxies.
Run RealServer on a dedicated bastion host and configure it carefully.