Configuring security features



Restrict which domains can connect to a virtual host

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

  1. Open the RootInstall/conf/fms.ini file.

  2. Set the VHOST.ALLOW parameter to a comma-delimited list of domains that are allowed to connect to the server. The default value is all.

    If a value is set, only the domains listed are accepted. For example, VHOST.ALLOW = example.com, example2.com allows connections from the example.com and example2.com domains. To allow localhost connections, specify localhost. For more information, see Vhost.xml file.

  3. Restart the server.

Verify SWF files

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.

Note: Verification of SWF files requires Flash Player 9.0.115.0 or later or Adobe® AIR™. This feature is supported in versions 3.0 and later of Flash Media Streaming Server, Flash Media Interactive Server, and Flash Media Development Server.

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 Flash 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\Flash Media Server 3.5\webroot</SWFFolder> prevents you from needing to maintain two copies of each SWF file.

Note: If you’re deploying an Adobe AIR application, copy the SWF file you compiled into the AIR package to the server or external content repository.

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.

Note: SWF files connecting to Flash Media Administration Server cannot be verified.

Locating SWF files for verification

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

  1. The application-specific Application.xml file, if it exists. The Application.xml file defines the location of verifying SWF files in the SWFFolder tag. If SWFFolder contains a file path, the server looks for verifying SWF files in that file path. If SWFFolder is empty, the server looks in the default location: /applications/application_name/SWFs.

  2. The Vhost-level Application.xml file. This Application.xml file defines the location of verifying SWF files for all applications on the virtual host. The SWFFolder tag defines the location. If SWFFolder contains a file path, the server looks for verifying SWF files in that file path. If SWFFolder is empty, the server looks in the default location: /applications/application_name/SWFs.

  3. The server checks the SWFFolder tag in the Server.xml file. This tag specifies a location for global SWF files, which means SWF files that are common to all applications.

  4. If a File plug‑in is enabled for retrieval of SWF files, the server calls the File plug‑in. The server passes any values present in Application.xml or Server.xml to the plug‑in. The plug‑in developer overrides these values with paths to the external content repository.

Configure SWF verification for applications

  1. Locate the following section of the Application.xml file:

    <Application> 
        ... 
        <SWFVerification enabled="false"> 
            <SWFFolder></SWFFolder> 
            <MinGoodVersion></MinGoodVersion> 
            <DirLevelSWFScan>1</DirLevelSWFScan> 
            <MaxInitDelay>5</MaxInitDelay> 
            <FirstHashTimeout>5</FirstHashTimeout> 
            <FinalHashTimeout>60</FinalHashTimeout> 
            <UserAgentExceptions> 
                <Exception to="" from=""/> 
            </UserAgentExceptions> 
            <Cache> 
                <TTL></TTL> 
                <UpdateInterval></UpdateInterval> 
            </Cache> 
        </SWFVerification> 
    </Application>
  2. Edit the following elements.

    Element

    Attribute

    Description

    SWFVerification

    enabled

    Set the enabled attribute to "true" or "false" to turn this feature on or off. The default value is "false".

    SWFFolder

    None.

    A single folder or a semicolon-delimited list of folders that contain copies of client SWF files. These SWF files are used to verify connecting SWF files. They are the verifying SWF files.

    The default value is the application's folder appended with /SWFs. For example, for an application called myApplication, if there isn’t a value set for this element, verifying SWF files should be placed in the applications/myApplication/SWFs folder.

    If you are using the File plug‑in to verify SWF files in an external content repository, leave this field blank.

    If you installed Apache with Flash Media Server, enter the path to the folder from which you are serving SWF files. For example, if you’re serving SWF files from the webroot directory on Windows, enter the path C:\Program Files\Adobe\Flash Media Server 3.5\webroot.

    MinGoodVersion

    None.

    Specifies the minimum version of this feature to accept. The default value is 0, which allows this and all future versions. This is a reserved field that works with Flash Player; Adobe recommends keeping the default value.

    DirLevelSWFScan

    None.

    Specifies the number of levels of subfolders within a parent folder to scan for SWF files. The parent folder is specified in the SWFFolder element. Specifying a positive value scans that number of subfolder levels. Specifying zero scans the parent folder and no subfolders. Specifying a negative value scans all subfolder levels. The default value is 1, which means that the server scans only one subfolder level.

    MaxInitDelay

    None

    The maximum amount of time to process SWF files, in seconds. The default value is 5 seconds.

    FirstHashTimeout

    None

    The maximum amount of time that a client can use to provide its first verification to the server.

    FinalHashTimeout

    None

    The maximum amount of time that a client can use to provide its final verification to the server.

    UserAgentExceptions

    None.

    Container.

    Exception

    from

    to

    A user agent to except from verification. Use the from and to attributes to indicate the lowest and highest versions to except. This is a string comparison, with editing to make all numeric fields equal in length. For more information, see the comments in the Application.xml file and “Create verification exceptions” later in this topic.

    Cache

    None.

    Container.

    TTL

    None.

    The time to live for the SWF file, in minutes. The default value is 1440 minutes (24 hours). If a SWF file is removed from the server, the verification values stay in the cache for 24 hours; users can connect to the application until the cache expires.

    UpdateInterval

    None.

    The maximum time in minutes to wait for the server to scan the SWFs folders for updates when there is a miss in the cache. The default value is 5 minutes, which means a SWF file copied to the SWFs folder is picked up by the server within 5 minutes.

Create verification exceptions

 Add Exception elements to the UserAgentExceptions section of the Application.xml file.

Certain applications—for example, Adobe® Flash® Media Live Encoder—do not support the form of SWF verification used by the server. You can add one or more exceptions to the SWF verification rules that allow specified user agents, such as Flash Media Live Encoder, to bypass SWF verification, as in the following:

<SWFVerification enabled="true"> 
    ... 
    <UserAgentExceptions> 
        <Exception to="FME/0.0" from="FME/2.5"/> 
    </UserAgentExceptions> 
</SWFVerification>

Configure SWF verification globally

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

 In the Server.xml file Root/Server/SWFVerification/SWFFolder tag, specify folders that hold the verifying SWF files. You can also configure other values for these SWF files.

Note: In addition to configuring the SWFFolder tag in the Server.xml file, enable verification in the Vhost-level or application-specific Application.xml file. See “Configure SWF Verification for Applications” in this topic.

Create folders for the verifying SWF files

  1. If the SWFFolder value is the default, create a folder called SWFs in the application’s folder on the server.

    For example, for an application called myMediaApp, create the folder applications/myMediaApp/SWFs. SWF files in the SWFs folder verify connections to any instance of the myMediaApp application.

  2. To verify SWF files for application instances, create instance folders in the SWFs directory, for example, applications/myMediaApp/SWFs/chat01, applications/myMediaApp/SWFs/chat02, and so on.

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

Note: Multiple SWF files may exist in either directory. A SWF file can be renamed and still used for verification as long as it’s a copy of the client SWF file.

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.

  1. Open RootInstall/conf/Server.xml and locate the CrossDomainPath element in the Server element (or the AdminServer element, for the Administration Server):

    <Server> 
        ... 
        <CrossDomainPath></CrossDomainPath>
  2. Specify the location of the cross-domain file in the CrossDomainPathElement, for example:

    <CrossDomainPath>http://store.mydomain.com/crossdomain.xml</CrossDomainPath>
  3. Validate the Server.xml file, save it, and restart the server.

Limit access to Flash Media Administration Server

By default, a client can connect to Flash 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.

  1. Open RootInstall/conf/Server.xml and locate the following code:

    <AdminServer> 
        ... 
        <Allow>all</Allow> 
        ... 
    </AdminServer>
  2. Edit the Allow element to specify which connections to Flash Media Administration Server the server responds to. This is specified as a comma-delimited list of host names, domain names, and full or partial IP addresses, as well as the keyword all. For example: <Allow>x.foo.com, foo.com, 10.60.1.133, 10.60</Allow>.

  3. Alternatively, edit the CrossDomainPath element to specify a cross-domain file, which lets you specify a list of domains from which a client can access the server.

  4. Validate the XML, save the Server.xml file, and restart the server.

Disable RTMPE

By default, RTMPE is enabled in the server’s Adaptor.xml file. In some scenarios, you might want to disable RTMPE (encrypted Real-Time Messaging Protocol). Because RTMPE uses encrypted channels, there is a minor impact on performance; RTMPE requires about 15% more processing power than RTMP. If you don’t control the applications that connect to Flash Media Server and you don’t want them to use RTMPE, you can disable RTMPE at the adaptor level.

To request an encrypted or encrypted tunnelling channel, applications specify rtmpe or rtmpte, respectively, in the NetConnection.connect() URL, for example, nc.connect("rtmpe://www.example.com/myMediaApplication"). If an application specifies RTMPE without explicitly specifying a port, Flash Player scans ports just like it does with RTMP, in the following order: 1935 (RTMPE), 443 (RTMPE), 80 (RTMPE), 80 (RTMPTE).

Note: RTMPE cannot currently be used between servers or from edge to origin. In these cases, RTMPS can be used instead.
  1. Open the Adaptor.xml file for the adaptor you want to disable (located in RootInstall/conf).

  2. Locate the following XML:

    <RTMP> 
    <!-- RTMPE is the encrypted RTMP protocol covering both RTMPE and RTMPTE --> 
    <!-- This is enabled by default, setting enabled to "false will not     --> 
    <!-- allow these protocols on this adaptor                 --> 
        <RTMPE enabled="true"></RTMPE> 
    </RTMP
  3. Set the RTMPE enabled attribute to "false".

  4. Restart the server.

Configure SSL

Secure Sockets Layer (SSL) is a protocol for enabling secure communications over TCP/IP. Flash 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.

When SSL is configured, to use SSL, applications must specify the RTMPS protocol in the NetConnection.connect() URL; for example, nc.connect("rtmps://www.example.com/myMediaApplication").

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.

Note: All server editions support a version of RTMP called RTMPE, which is an 128-bit encrypted protocol. RTMPE is more lightweight than SSL and is enabled by default. For more information, see the NetConnection.connect() entry in the ActionScript® 3.0 Language Reference or in the ActionScript 2.0 Language Reference.

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:

-----BEGIN CERTIFICATE----- 
... 
-----END CERTIFICATE----- 
-----BEGIN CERTIFICATE----- 
... 
-----END CERTIFICATE-----

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.

  1. Open the Adaptor.xml file for the adaptor you want to configure and locate the following code:

    <Adaptor> 
        ... 
        <SSL> 
            <SSLServerCtx> 
                <SSLCertificateFile></SSLCertificateFile> 
                <SSLCertificateKeyFile type="PEM"></SSLCertificateKeyFile> 
                <SSLPassPhrase></SSLPassPhrase> 
                <SSLCipherSuite>ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH</SSLCipherSuite> 
                <SSLSessionTimeout>5</SSLSessionTimeout> 
            </SSLServerCtx> 
        </SSL> 
        ... 
    </Adaptor>
  2. Edit the following elements.

    Element

    Description

    SSLCertificateFile

    The location of the certificate file to send to the client. Specify an absolute path or a path relative to the adaptor folder.

    SSLCertificateKeyFile type="PEM"

    The location of the private key file for the certificate. Specify an absolute path or a path relative to the adaptor folder. The type attribute specifies the type of encoding used for the certificate key file. This can be either "PEM" or "ASN1". The default value is "PEM". The private key and the certificate can be combined into one file.

    If the key file is encrypted, the pass phrase must be specified in the SSLPassPhrase tag.

    SSLPassPhrase

    The pass phrase to use for decrypting the private key file. If the private key file is not encrypted, leave this tag empty.

    SSLCipherSuite

    The SSL ciphers: a colon-delimited list of components. A component can be a key exchange algorithm, authentication method, encryption method, digest type, or one of a selected number of aliases for common groupings. Do not change the default settings unless you are very familiar with SSL ciphers. The possible values are listed in the SSLCipherSuite entry in XML configuration files reference.

    SessionTimeout

    The amount of time in minutes a session remains valid. Any value less than 1 is read as 1. The default value is 5. If a client reconnects to a session before SessionTimeout is reached, the cipher suite list isn’t sent during the SSL handshake.

  3. To configure a secure port for an adaptor, specify a minus sign before the port number in the ADAPTOR.HOSTPORT parameter in the RootInstall/conf/fms.ini file, as follows:

    ADAPTOR.HOSTPORT = :1935,-443

    This configuration tells the server to listen on ports 1935 and 443, and that 443 is a secure port that receives only RTMPS connections. An RTMPS connection to port 1935 fails: the client attempts to perform a SSL handshake that the server fails to complete. An RTMPS connection to port 443 succeeds: the client performs a SSL handshake that the server completes. An RTMP connection to port 443 also fails: the server tries to perform a SSL handshake that the client fails to complete.

  4. Restart the server.

  5. Check the RootInstall/logs/edge.00.log file to verify that no errors have been reported.

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.

Note: Generally, if you’re hosting multiple customers, each virtual host has its own domain name. Each domain name must have its own certificate.
  1. Locate the following code in the Adaptor.xml file:

    <Adaptor> 
        ... 
        <Ho4stPortList> 
            <HostPort name="edge1" ctl_channel=":19350">${ADAPTOR.HOSTPORT}</HostPort> 
        </HostPortList> 
        ... 
    </Adaptor>
  2. Create new HostPort elements with unique name and ctl_channel attributes and unique port values for RTMP and SSL.

    For example, add the following HostPort tag in addition to the default HostPort tag:

    <HostPort name="edge2" ctl_channel=":19351">:1936,-444</HostPort>
  3. For each HostPort element, enter an Edge element under the SSL element with an identical name attribute. If you don’t specify an Edge element, the edge uses the default SSL configuration.

    This sample code demonstrates how to configure edge1 to return cert2.pem when a client connects to it on port 443. Since there is no Edge tag for edge2, edge2 will use the default configuration specified in the SSLServerCtx section that is directly under the SSL container tag. The edge2 server returns cert.pem when a client connects to it on port 444.

    <SSL> 
        <SSLServerCtx> 
            <SSLCertificateFile>cert.pem</SSLCertificateFile> 
            <SSLCertificateKeyFile>private.pem</SSLCertificateKeyFile> 
            <SSLPassPhrase></SSLPassPhrase> 
            <SSLCipherSuite>ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH</SSLCipherSuite> 
            <SSLSessionTimeout>5</SSLSessionTimeout> 
        </SSLServerCtx> 
        <Edge name="edge1"> 
            <SSLServerCtx> 
                <SSLCertificateFile>cert2.pem</SSLCertificateFile> 
                <SSLCertificateKeyFile>private2.pem</SSLCertificateKeyFile> 
                <SSLPassPhrase></SSLPassPhrase> 
                <SSLCipherSuite>ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH</SSLCipherSuite> 
                <SSLSessionTimeout>5</SSLSessionTimeout> 
            </SSLServerCtx> 
        </Edge> 
    </SSL>
  4. Validate the XML and save the file.

  5. Restart the server.

Secure outgoing connections

  1. Open the Server.xml file and locate the following code:

    <Root> 
        <Server> 
            <SSL> 
                <SSLEngine></SSLEngine> 
                <SSLRandomSeed></SSLRandomSeed> 
                <SSLClientCtx> 
                    <SSLVerifyCertificate>true</SSLVerifyCertificate> 
                    <SSLCACertificatePath></SSLCACertificatePath> 
                    <SSLCACertificateFile></SSLCACertificateFile> 
                    <SSLVerifyDepth>9</SSLVerifyDepth>     
                    <SSLCipherSuite>ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH</SSLCipherSuite> 
                </SSLClientCtx> 
            </SSL> 
        </Server> 
    </Root>
  2. Edit the following elements.

    Element

    Description

    SSLRandomSeed

    The number of bytes of entropy to use for seeding the pseudo-random number generator (PRNG). You cannot specify anything less than 8 bytes, and the default value is 16. Entropy is a measure of randomness. The more entropy, the more random numbers the PRNG will contain.

    The server may take longer to start up if you specify a large number.

    SSLSessionCacheGC

    How often to flush expired sessions from the server-side session cache, in minutes.

    SSLVerifyCertificate

    A Boolean value specifying whether to verify the certificate returned by the server being connected to (true) or not (false). The default value is true. Disabling certificate verification can result in a security hazard. Do not disable verification unless you are certain you understand the ramifications.

    SSLCACertificatePath

    A folder containing certificates. Each file in the folder must contain only a single certificate, and the file name must be hash and the extension ".0", for example, e98140a6.0.

    On a Windows 32-bit operating system, if this tag is empty, the server looks for certificates in the RootInstall\certs directory. You can import the Windows certificate store to the certs directory by running FMSMaster -console -initialize from a command line.

    In Linux, you must specify the location of the certificates.

    SSLCACertificateFile

    Specifies the name of a file containing one or more certificates in PEM format.

    SSLVerifyDepth

    Specifies the maximum depth of an acceptable certificate. If a self-signed root certificate cannot be found within this depth, certificate verification fails. The default value is 9.

    SSLCipherSuite

    The SSL ciphers: a colon-delimited list of components. A component can be a key exchange algorithm, authentication method, encryption method, digest type, or one of a selected number of aliases for common groupings. Do not change the default settings unless you are very familiar with SSL ciphers. The possible values are listed in the SSLCipherSuite entry in XML configuration files reference.

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.

 Copy the SSL section in the Server.xml file to the Adaptor.xml files and enter the new values. You don’t need to copy the SSLRandomSeed tag, as this tag is a server-level setting that cannot be overridden in Adaptor.xml.

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.

  1. Uncomment the SSL section under the Proxy tag in the appropriate Vhost.xml file:

    <VirtualHost> 
        ... 
        <Proxy> 
            <SSL> 
                <SSLClientCtx> 
                    <SSLVerifyCertificate></SSLVerifyCertificate> 
                    <SSLCACertificatePath></SSLCACertificatePath> 
                    <SSLCACertifcateFile></SSLCACertificateFile> 
                    <SSLVerifyDepth></SSLVerifyDepth> 
                    <SSLCipherSuite></SSLCipherSuite> 
                </SSLClientCtx> 
            </SSL> 
        </Proxy> 
    </VirtualHost>

    When the SSL tag is present, the entire SSL section is used to configure the virtual host. If an SSL tag is omitted from this section, the server uses the default settings.

  2. Restart the server.