Chapter 14: Limiting Access to RealServer

RealServer has several methods of restricting access to content. Methods for restricting access to all material provided by RealServer include limiting the number of clients that can connect at any one time, limiting the amount of bandwidth that can be in use, requiring clients to be a certain version of the RealNetworks RealPlayer, or specifying that only multicast connections are permitted. In addition, you can restrict access based on the IP address of the client.

Overview

There are four methods which RealServer uses to block access, via connection volume or client identity. They are listed here, in the order in which they take effect:

1. Controlling access via HTTP.

2. Limiting the bandwidth or connections used.

3. Requiring a minimum player version.

4. Blocking or restricting access based on IP address of client.

Clients that do not meet the above criteria when requesting a presentation receive an error message.

Once a connection attempt is accepted, RealServer looks at the authentication information. Authentication, which can require a user name and password, is discussed in Chapter 15, "Authenticating RealServer Users".

Controlling Access to HTTP Streams

RealServer can serve any content via HTTP, and includes a method for indicating which virtual paths contain content that can be served via HTTP. In this way you can protect your content but still serve HTML pages.

The list of virtual paths is pre-configured.

RealSystem Administrator uses the following entries in the HTTP Delivery list (you can view this list in RealSystem Administrator by clicking General Setup> HTTP Delivery):

• HTTP Directories-the default entries in this list are /admin, /httpfs, /viewsource, and /ramgen. The /scalable mount point is added automatically when you configure multicasting.

  	Warning
  	Do not add directories that contain secure material to this list, or users will not be prompted for their name and password when they view content in the secure directory.

Limiting Access by Number of Connections or Bandwidth

By using the Maximum Client Connections setting (the ClientConnections variable in the configuration file), you can limit the number of clients who connect simultaneously. Once this limit is reached, clients that attempt to connect receive an error message, and will not be able to connect until other clients disconnect.

Similarly, the Maximum Bandwidth setting limits the amount of bandwidth RealServer can use to any number of kilobits per second (Kbps).

If you establish values for both variables, RealServer will limit access when the lower threshold is reached.

To limit access by limiting connections:

1. In RealSystem Administrator, click General Setup. Click Connection Control.

2. In the Maximum Client Connections box, type the number of client connections you want to allow simultaneously.

   This number can be from 1 to 32767, as long as it is less than or equal to the number of streams permitted by your license. If it is 0 or blank, RealServer uses the number of streams specified by your license.

3. Click Apply.

To limit access by bandwidth:

1. In RealSystem Administrator, click General Setup. Click Connection Control.

2. In the Maximum Bandwidth box, type the maximum number of kilobits per second (Kbps) that should be in use at once.

   For example, to limit the bandwidth to one megabyte, specify maximum bandwidth usage by setting Maximum Bandwidth to 1024.

   	Tip
   	Your RealServer license may allow more bandwidth than is suitable for your network. Check with your network administrator to determine the right number to use.

3. When you have finished making changes, click Apply.

Limiting Access by RealPlayer Version

The setting for RealPlayer Plus Only means that only the RealNetworks RealPlayer Plus software can play presentations.

To limit access to RealPlayer Plus:

1. In RealSystem Administrator, click General Setup. Click Connection Control.

2. In the RealPlayer Plus Only list, select On.

3. Click Apply.

Limiting Access to Back-Channel Multicast Reception

By setting Enable Failover to Unicast to No in the back-channel multicast section, you can require that clients within a certain range of IP addresses connect only in multicast mode. When this option is set to No, clients that are not able to connect in multicast mode receive an error message. If this option is Yes, clients that cannot connect in multicast mode can use unicast mode to receive the presentation. This feature is described in"Requiring Multicasting Access Rather Than Unicasting".

For scalable multicast, the Shift to Unicast feature provides the same functionality. See "Using Unicasting as a Backup Method".

Limiting Access with the IP Address

You can block or permit access to RealServer material based on the IP address of the requesting machine and the port to which the request is made. Content is associated with specific port numbers-requests for streamed media arrive on the RTSP Port and PNA Port, HTML pages are made available via the HTTP Port. Encoders send their encoded material to the encoder ports. Server administrators use the Admin Port to access RealSystem Administrator.

The access control feature lets you associate certain client addresses with the ability or permissions to connect to certain ports.

For example, you could restrict which encoders can send encoded streams to your RealServer by restricting access to the encoding port (usually 4040). Or, you could allow only certain groups in your organization to view presentations served by your RealServer by listing their IP addresses and giving them access to your RTSP, PNA, and HTTP ports.

Clients whose IP addresses are configured with "deny" receive an error message indicating that the URL is not valid or that the connection has timed out.

A more selective form of restricting which material users can access (based on the directory or virtual directory where clips are stored) is authentication, described in Chapter 15, "Authenticating RealServer Users".

When to Use Access Control

The following are considerations in deciding whether access control is right for your system:

• You want to restrict client access based on their IP addresses and you have a good way of figuring out their IP addresses

• You want to restrict access to certain features according to the users. For example, you only want to allow splitting from authorized RealServers.

Access Control Used with Other Features

This section describes the ways in which multicasting works together with other features.

On-Demand Streaming, Live Unicasting, G2SLTA, and Access Control

A client's address must be approved by the access control rules before being allowed to receive a stream or broadcast.

Splitting, Multicasting and Access Control

A client's address must be approved by the access control rules before being allowed to receive a stream or broadcast.

RealProxy and Access Control

If a client requests a cached stream, RealProxy will send the request to the source RealServer for permission before allowing the client to play the stream. If RealServer denies the request, RealProxy will not allow the client to receive the stream.

You can block a single RealProxy from caching the material served by your RealServer by creating an access rule that prohibits the IP address of that RealProxy from connecting to your RealServer.

Authentication and Access Control

Verification of the user's IP address takes place before authentication of user name or client ID. If a client fails the access control rules, authentication will not take place.

ISP Hosting and Access Control

Any client that tries to play a presentation hosted by an ISP-hosted customer will be compared against the access control rules before being allowed to play a clip.

Monitoring and Access Control

If a rule exists that allows access to the Monitor Port (9090) from a particular IP address, a user at that address can view and use Java Monitor.

Reporting and Access Control

The access log file shows clips served to clients that were accepted by the access control rules.

Understanding Access Control Rules

Information about each IP address or range of addresses you want to allow or restrict is stored in a rule. A rule is a set of instructions to RealServer about the address range and behavior to allow. Rules are identified by numbers which you assign, and are applied in ascending numeric order.

Before using this feature, you must make decisions about the types of rules you will create.

Each rule contains the following information:

• Access Rule Number-Identification number for this rule.

• Access-Whether the client will be allowed or denied access.

• Client IP Address-Client's address, or a range of addresses. This can also be an encoder's IP address.

• Server IP Address-RealServer's address.

• Ports-Port numbers to which access is specified. For general content viewing, these numbers correspond to settings on the Ports page: RTSP Port, PNA Port, and HTTP Port. For encoders, these correspond to the port numbers in the Broadcasting pages.

When a client attempts to play a RealServer presentation, or an encoder attempts to send material, RealServer compares its address and the requested port to the addresses and ports listed in the rules. You can create as many rules as you like. If the client's IP and requested port number do not match any rules, RealServer denies access.

For example, to allow a content creator to encode live material and send it to your RealServer, you would create a rule that listed the client's address and the encoder port (4040).

Deciding What Rules to Create

There are two ways you can restrict access, and these determine how you set up the rules. Create the third rule first, so that you will be able to connect to RealSystem Administrator and create the rest.

• Specific Address Denial: Deny a specific group of IP addresses and ports, and allow access to everyone else.

• Specific Address Permission: Allow a specific group of IP addresses and ports, and deny access to everyone else.

Both methods require that you set up three sets of rules:

1. The first set of rules refers to specific client addresses you are denying or allowing. There can be several rules that refer to specific addresses or ranges of addresses.

2. All clients not noted specifically in the first set of rules are allowed access (in Specific Address Denial) or denied access (in Specific Address Permission). This second set usually consists of a single rule which uses the word "Any" in the From box.

   	Warning
   	If you are using Specific Address Denial and you omit this step, you will deny access for everyone except those clients mentioned in the first set of rules.

   If you are using Specific Address Permission, this set of rules is optional.

3. Finally, the last rule allows you to access to the RealSystem Administrator port.

As soon as you create one rule, RealServer assumes that all users not mentioned in the rule should be denied access. This is why you need to make enough rules to accommodate all conditions.

	Note
	Even if you are only interested in restricting access for a single client's requests, you must still create all the rules necessary for your method.

Numbering the Rules

Rule numbers can be any length, but a number of more than one digit is recommended in case more lists are added later; with multiple digits, the new lists can be inserted between existing lists. When you create a rule, you give it a number. RealServer uses these numbers to sort the rules before it looks at a client's request.

RealServer compares the client's IP address and requested port to the sorted rules, beginning with the lowest-numbered rule. As soon as RealServer finds a rule which matches the client's address, it allows or denies access, according to the rule's characteristics.

You do not have to create the rules in a certain order; RealServer will perform the sorting automatically.

Getting the Expected Connections

Because RealServer examines the rules in numeric order, you should make the lowest-numbered rules the most strict. Reserve high rule numbers for the most lenient rules. This is similar to schemas for firewall addresses.

Setting Up IP Access Control

There are two steps to setting up access control rules, regardless of which method you chose in "Deciding What Rules to Create":

1. Set up general rules which allow you to remain connected to RealSystem Administrator. You need only perform this set of steps once.

2. Create rules for specific IP addresses and port numbers.

Creating General Access Rules

The steps in this section create a rule that enables you to connect to RealSystem Administrator, regardless of the restrictions you create in other rules. Although it appears that you are allowing everyone to access RealSystem Administrator, the only people who will use it are other administrators who know the Admin Port number (chosen randomly at installation) and who have a user name and password specifically for RealSystem Administrator.

	Warning
	If you omit this initial step, you will not be able to connect to RealSystem Administrator when you restart RealServer, regardless of whether you have username- and-password permission.

	Additional Information
	To learn how to give access to RealSystem Administrator based on user name, see "Authenticating RealSystem Administrator Users".

To create the required access rule:

1. In RealSystem Administrator, click General Setup. Click Ports.

2. Make a note of the Admin Port number. (This is the same number as the port number shown in your browser URL.)

3. In RealSystem Administrator, click Security. Click Access Control.

4. Click Add New.

   A generic access rule number appears in the Edit Rule Number box.

5. In the Edit Rule Number box, type 1000.

6. Click Edit.

7. From the Access list, select Allow.

8. In the Client IP Address box, type Any.

   For additional security, type the IP address or subnet address of users who will be permitted to use RealSystem Administrator.

   If you type a subnet address, be sure to fill in the Client Netmask box with the appropriate subnet mask.

9. In the Server IP Address box, type Any.

10. In the Ports box, type the Admin Port number you noted in Step 2.

11. Click Apply.

You will now be able to access RealSystem Administrator, no matter what rules you create in the next section.

Creating Specific Access Rules

Use the steps in this section to allow or deny access to specific IP addresses or address ranges.

	Warning
	Be sure to first follow the steps in "Creating General Access Rules", or you will not be able to access RealSystem Administrator after you restart RealServer.

To limit access according to IP number:

1. Determine the port numbers in use, for Step 10:

   • Users-If this rule will refer to users who want to play streaming media, click General Setup>Ports. Make a note of the values for PNA Port (usually 7070), HTTP Port (usually 8080), and RTSP Port (usually 554).

   • Encoders-If this rule will refer to version 6 and later encoders that will be sending content to your RealServer, click Broadcasting>Encoder. Make a note of the value for Port (usually 4040).

   • Pre-G2 Encoders-If this rule will refer to pre-G2 encoders that will be sending content to your RealServer, click Broadcasting>Pre-G2 Encoder. Make a note of the value for Port (usually 5050).

   • Receivers-To allow pull splitting receiver connections, look at the port number (usually 2030) in Splitting>Transmitter. For push splitting, check the HTTP Port number (usually 8080) by clicking General Setup>Ports.

   • Java Monitor-To reference Java Monitor, use the Monitor Port number (usually 9090), shown on General Setup>Ports.

2. In RealSystem Administrator, click Security. Click Access Control.

3. Click Add New.

   A generic rule number appears in the Edit Rule Number box.

4. In the Edit Rule Number box, type a three-digit number for the new access rule. RealServer implements the rule numbers in numeric order.

   	Tip
   	Technically, you can type any number in this box. But because rules are sorted numerically, and because the rule that enables access to RealSystem Administrator must be the last rule on the list, use a three-digit number here so the RealSystem Administrator rule (given as rule 1000 in "Creating General Access Rules") can be the last rule on the list.

5. Click Edit.

6. Indicate whether permission is being granted or refused by selecting Allow or Deny from the Access list.

7. In the Client IP Address box, type the IP address of the client machine.

8. To indicate a range of addresses, type the netmask in the Client Netmask.

   	Tip
   	To refer to all clients, regardless of IP address, type the word Any in the Client IP Address box, and leave the Client Netmask box blank.

9. In the Server IP Address box, type the address of the RealServer machine or network card which is hosting the requested content.

   You can type a specific address, or use the word Any to refer to any IP address on the RealServer machine.

   • If you type a specific IP address or DNS name, you must also add that address to the IP Binding list. See "Distributed Licensing" for information.

   • Avoid using 127.0.0.1 or localhost, unless you will only be using test links which use that exact text in their links.

10. Finally, list the RealServer port numbers to which you want to restrict access. In the Ports box, type the port numbers, separated by commas.

    To restrict access to all RealServer content, the port numbers should match the other port numbers you've instructed RealServer to listen to; look at the port numbers for RTSP port, PNA port, HTTP port, and the port value used by the encoder.

11. Click Apply.

Copyright © 2000 RealNetworks
For information on RealNetworks' technical support, click here.
Comments on this document? Click here.
This file last updated on 11/28/00 at 17:35:01.