Flash Media Server Resources
|
Configuring security features
Restrict which domains can connect to a virtual hostIf desired, you can restrict which domains are allowed
to connect to a virtual host. By default, connections are allowed
from all domains.
Open the RootInstall/conf/fms.ini file.
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.
Restart the server.
Verify SWF filesYou
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 verificationThe
server looks for verifying SWF files in the following locations,
in order:
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.
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.
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.
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 applicationsLocate 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>
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 globallyYou 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 filesIf 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.
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 fileYou 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.
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>
Specify the location of the cross-domain file in the CrossDomainPathElement,
for example:
<CrossDomainPath>http://store.mydomain.com/crossdomain.xml</CrossDomainPath>
Validate the Server.xml file, save it, and restart the server.
Limit access to Flash Media Administration ServerBy
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.
Open RootInstall/conf/Server.xml and locate the
following code:
<AdminServer>
...
<Allow>all</Allow>
...
</AdminServer>
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>.
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.
Validate the XML, save the Server.xml file, and restart the
server.
Disable RTMPEBy 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.
Open the Adaptor.xml file for the adaptor you want to
disable (located in RootInstall/conf).
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
Set the RTMPE enabled attribute to "false".
Restart the server.
Configure SSLSecure
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.
CertificatesYou
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 connectionsSpecify
the location of the SSL certificate and the certificate’s private
key, and configure the adaptor to listen on a secure port.
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>
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.
|
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.
Restart the server.
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 adaptorYou
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.
Locate
the following code in the Adaptor.xml file:
<Adaptor>
...
<Ho4stPortList>
<HostPort name="edge1" ctl_channel=":19350">${ADAPTOR.HOSTPORT}</HostPort>
</HostPortList>
...
</Adaptor>
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>
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>
Validate the XML and save the file.
Restart the server.
Secure outgoing connectionsOpen 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>
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 independentlyThe 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 independentlyFor 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.
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.
Restart the server.
|