Configuring security features

For information about security, see the Adobe Media Server Hardening Guide.

If desired, you can restrict which domains are allowed to connect to a virtual host. By default, connections are allowed from all domains.

Verify SWF files

Flash Media Server 3.0, Flash Player 9 Update 3, AIR 1

You can configure the server to verify client SWF files before allowing them to connect to an application. Verifying SWF files prevents third parties from creating their own applications that attempt to stream your resources.

You can verify SWF files at the following server scopes:

• Individual applications. Configure the application-specific Application.xml file.

• All applications in a virtual host. Configure the Application.xml file in the Vhost folder.

• Administrative applications that have access to all server levels. Configure the Server.xml file and an Application.xml file.

SWF verification is disabled by default. To verify SWF files, you must set <SWFVerification enable = "true"> in the Application.xml configuration file. When verification is enabled, the server verifies that the client SWF file requesting a connection to the server matches the verifying SWF file. The verifying SWF file is a copy of the client SWF file that you place on the server or in an external content repository.

By default, the server looks in rootinstall/applications/application_name/SWFs folder for the verifying SWF file. You can override this default in the SWFFolder tag of the Application.xml file, the Server.xml file, or in the File plug‑in. If you installed Apache with Adobe Media Server, you can add a path to the folder from which you serve SWF files. For example, on Windows, adding the path <SWFFolder>C:\Program Files\Adobe\Adobe Media Server 4\webroot</SWFFolder> prevents you from needing to maintain two copies of each SWF file.

When the client SWF file connects to the server, the server verifies it. If the SWF file is verified, it is allowed to connect to the application. If a client SWF file fails verification, the server disconnects the NetConnection object and logs an event to the access log. The server does not send a NetStream status message to the client.

For client applications that comprise multiple SWF files or SWF files that dynamically load other SWF files, the SWF file that contains the NetConnection object to connect to the server is the one that the server attempts to verify.

Locating SWF files for verification

The server looks for verifying SWF files in the following locations, in order:

Configure SWF verification for applications

Create verification exceptions

Configure SWF verification globally

You can configure verification for a group of SWF files on the server that are common to all applications.

Create folders for the verifying SWF files

SWF files in the SWFs directory can verify all instances of the application; SWF files within an instance folder can verify only that instance.

Restrict access to the server with a cross-domain file

You can restrict access to an edge server or the Administration Server with a cross-domain XML file. The cross-domain XML file lets you specify a list of domains from which clients can access the edge server or Administration Server.

Limit access to Adobe Media Administration Server

The Administration Console connects to Adobe Media Administration Server, which connects to Adobe Media Server. By default, the Administration Server in installed on port 1111. Adobe recommends that you block all external access to port 1111 so that access to the admin server is restricted only to clients that are within your firewall.

Additionally, you can restrict access to the admin server by using domain based restrictions.

By default, a client can connect to Adobe Media Administration Server from any domain or IP address, which can be a security risk. If desired, you can change this in the AdminServer section of the Server.xml file.

Set limits on unsuccessful login attempts

You can use the LogInLimits settings in the rootinstall/conf/Server.xml file to set the number of unsuccessful attempts a client is allowed when trying to log in to the admin server. With these settings, you define how many failed attempts are allowed before the client must wait to attempt to log in again. You also define the amount of time they must wait. In addition, you can lock the user out of the server entirely after a certain number of attempts.

To set the number of login attempts the client can have before waiting, use the MaxFailures sub-element. After that number of failures, the client must wait the number of seconds defined by the RecoveryTime sub-element. If the client tries unsuccessfully to log in a number of times equal to LockOutLimit, they are locked out of the server until the server is restarted.

In the following example, a user can try to log in 10 times. If they fail to log in successfully on the 10th attempt, they must wait 5 minutes (300 seconds) before attempting to log in again. If they fail 20 times total, they are barred from logging in until the server is restarted:<Security> <LoginLimits> <!-- Default value is 3 --> <MaxFailures>10</MaxFailures> <!-- Default value is 30 --> <RecoveryTime>300</RecoveryTime> <!-- Default value is 100--> <LockoutLimit>20</LockoutLimit> </LoginLimits> </Security>

For more information, see LogInLimits.

Configure SSL

Secure Sockets Layer (SSL) is a protocol for enabling secure communications over TCP/IP. Adobe Media Server provides native support for both incoming and outgoing SSL connections. An incoming connection is a connection between Flash Player and the server. An outgoing connection is a connection between two servers.

RTMPS adheres to SSL standards for secure network connections and enables connections through a TCP socket on a secure port. Data passed over the secure connection is encrypted to avoid eavesdropping by unauthorized third parties. Because secure connections require extra processing power and may affect the server’s performance, use RTMPS only for applications that require a higher level of security or that handle sensitive or critical data.

By default, when Flash Player connects to Adobe Media Server, it scans the following ports in order: 1935, 443, 80, 80 (RTMP tunneling). To configure SSL, specify that a port is secure. To specify that a port is secure, place a minus (“-”) sign in front of the port number. The default secure port for RTMPS is 443. To configure the default secure port, enter -443 in the ADAPTOR.HOSTPORT parameter in the rootinstall/conf/ams.ini file, as follows:

When Flash Player encounters an “rtmps://amsdomain/application” string, it communicates with Adobe Media Server over port 443. Adobe Media Server returns data to the client over port 443. Traffic with an “rtmp://” string uses port 1935.

To connect to Adobe Media Server over an SSL connection, clients must do the following:

If SSL is configured, the following client code connects securely:

If you configure any port other than 443 as secure, for example, -1935, the client must specify the port in the URI, for example, “rtmps://host:1935/app”.

Certificates

You can get an SSL certificate from a certificate authority or create a certificate yourself. If a certificate is signed by an intermediate Certificate Authority (CA), it must include the intermediate certificate as part of the certificate that the server returns to the client. Your certificate file (if signed by an intermediate CA) should look something like the following:

The first BEGIN CERTIFICATE/END CERTIFICATE pair is your certificate. The next BEGIN CERTIFICATE/END CERTIFICATE pair is the intermediate CA that signed your certificate. You can add additional sections as needed.

Secure incoming connections

Specify the location of the SSL certificate and the certificate’s private key, and configure the adaptor to listen on a secure port.

Configure incoming connections when multiple virtual hosts are assigned to one adaptor

You can configure the server to return a certificate based on which port a client connects to. This lets you assign multiple virtual hosts to one adaptor and return a different certificate for each virtual host.

Secure outgoing connections

Configure adaptors to manage outgoing SSL connections independently

The SSL section in the Server.xml file configures all adaptors to use the same settings. However, you might want to use a different certificate for each virtual host. In this case, assign one virtual host to each adaptor and configure your adaptors individually to override the settings in the Server.xml file.

Configure virtual hosts to manage outgoing SSL connections independently

For example, you can disable certificate checking in one virtual host, use a certificate in a different folder for one virtual host, and implement a different set of ciphers in a third virtual host.

Configure Adobe Media Server to work with a hardware SSL proxy

When you use a hardware SSL proxy, you don't need to configure Adobe Media Server for SSL. The hardware sits between Adobe Media Server and the Internet. Data sent between Adobe Media Server and the hardware is unencrypted. The hardware encrypts the data and forwards it to the Internet.

Configure the hardware to listen externally on port 443 to receive encrypted data sent over Internet from clients. Configure the hardware to forward data to Adobe Media Server on port 1935. Adobe Media Server listens on port 1935 by default. If you’ve changed the default port, configure the hardware to forward data on that port.

Configure RPCs (Remote Procedure Calls)

Adobe Media Server provides settings in the Application.xml file for configuring which RPC methods can be called. The default is to block all RPC calls.

You can enable RPCs by setting the <RPC> element’s enable attribute to true; for example:<RPC enable="true">

After enabling RPCs, you must then list individual methods that are allowed. Each type of class—Client, NetConnection, Stream, and SharedObject—has its own whitelist of methods that can be called. If a method or object is not explicitly listed in the whitelist, then it is considered blocked.

The settings for RPCs are in the <Security><RPC> element of the Application.xml file. This element contains the following sub-elements:

• <Client> — All methods blocked by default.

• <NetConnection> — Only the onStatus() method is allowed by default, if RPCs are enabled.

• <SharedObject> — All methods blocked by default.

• <Stream> — Only the onStatus() method is allowed by default, if RPCs are enabled.

Each of these sub-elements takes a <Method> sub-element. Each <Method> sub-element takes an <Allow> sub-element. The <Allow> sub-element is a comma-delimited list of allowed methods.

To add a method to a class’s whitelist:

1. Enable RPCs by setting the <RPC> element’s enabled attribute to true; for example:<RPC enable="true">

2. Add the method you want to allow to the class’s <Allow> element. The following example allows the getLocal() and setFps() methods to be called on the SharedObject class:<SharedObject> <Method> <Allow>getLocal,setFps</Allow> </Method> </SharedObject>

3. Ensure that the defaults for the other classes meet your security standards. After enabling RPCs for all classes, you should review the default allowed methods.

The method names are case-sensitive and should be in one of the following formats:[objectPath.]method [objectPath.]object

If you allow an object but do not list its methods, then all methods of that object are allowed. For example, <Allow>a.b</Allow> matches methods a.b.c() and a.b.d().

Enable virtual directory mappings for server-side File objects

You can specify virtual directory mappings for server-side File objects in the Application.xml configuration file. However, the feature must be enabled at the server level in the Server.xml configuration file.

To enable virtual directories for server-side File objects, set the <VirtualDirectoryForFile> element’s enable attribute to true in the Server.xml file. In the Application.xml file, add a <VirtualDirectory> sub-element to the <ScriptingEngine><FileObject> element.

Only enable VirtualDirectoryForFile when you must provide virtual directories for server-side scripting; it is not required for adding virtual directories for streams. When virtual directories for File objects are enabled, anyone who has access to a server-side script can write files anywhere on the server disk. As a result, it is disabled by default. Activating it requires a configuration from the Server.xml file administrator.

If you map File objects in the Application.xml file and don’t have the feature enabled in the Server.xml file, the following message appears in the log:"Virtual directories for file objects is not supported due to the Server level security setting."

The following example enables virtual directory mappings for server side File objects in the Server.xml file:<Root> <Server> <Security> <VirtualDirectoryForFile enable="true"></VirtualDirectoryForFile> ... ... ... ...

The following example from the Application.xml file creates a new virtual directory mapping for server-side File objects:<Application> <ScriptEnging> <FileObject override="no"> <VirtualDirectory> /flashapps;C:\dev\Code\Flash\tincan\flashapps\ </VirtualDirectory> </FileObject> ... ... ...