 |
|
|
Flash Communication Server Article |
|
|
|
|
| |
| |
|
|
| General
administrative settings |
| |
|
|
| 1 |
Set
a secure user ID and password. Don't use "admin",
"administrator" (and so forth) as
the user name. Pick a password with at least
8 characters, including digits and punctuation. |
| 2 |
Use
the <Allow> and <Deny> tags in the
Server.xml file to restrict which client computers
can connect to the Admin application. |
| 3 |
Set
the Admin tool to bind to a port that is not available
to the general public. Block access to this port
with your firewall. |
|
| The
Vhost.xml file settings |
| |
|
|
| 1 |
Use
the <Allow> and <Deny> tags in Vhost.xml
to restrict what client computers can connect
to the virtual host. (These same settings can
also be accomplished in the Server.xml file—see
above.) |
| 2 |
Set
the <MaxStreams> value to zero in Vhost.xml
if your applications do not create or use streams. |
| 3 |
Turn
the <RecordAccessLog> value on or off as
desired in Vhost.xml. |
|
| Other
server administrator issues |
| |
|
|
| 1 |
Check
the <ResourceLimits> values in Server.xml
if you want to alter memory allocations, garbage
collection frequency, or other similar settings. |
| 2 |
Be
sure to alter the <ServerDomain> tag in
Server.xml if you are building server applications
that connect between multiple computers. |
| 3 |
Double
check the <HostPortList> in Adaptor.xml
(for all adaptors) to make certain you are not
listening on any extra ports. Confirm that your
firewall has the proper ports open or blocked. |
| 4 |
If
your applications are not open to the general
public, use the <Allow> and <Deny>
tags in Adaptor.xml to restrict domains and IP
addresses that can connect to your applications. |
|
| Writing
applications |
| |
|
|
| 1 |
Final,
released Flash applications should not allow
users to specify application names, server addresses
(and so forth) in text fields. These should
be hard-coded in your source code and hidden
from the user. |
| 2 |
Make
certain your server-side scripts check the client
referrer property when a user attempts to log
on. This should be the SWF file from an expected
URL, such as your web server. This will help prevent
someone from writing their own client that logs
on to your server using the same application name. |
| 3 |
You
can add some basic handshaking code in your Flash
movie to try to prevent rogue clients from connecting
to your server. The client and server code might
exchange some token or perform some basic calculations
to try and confirm that the you have the proper
client connected to the proper server. While Flash
movie byte code is not encrypted or fully secure,
this makes it a bit harder for hackers to write
rogue clients. |
| 4 |
Check
all your server scripts (ASC files) and be certain
to remove any debugging code, extra "trace"
output (or other unnecessary code) that remains
from development. |
| 5 |
Be
certain to remove any extra script files or older
versions that are no longer used by your application. |
|
| Application
configuration |
| |
|
|
| 1 |
Set
the <AppsDir> value in Vhost.xml to point
to where your applications can be found. This
directory should not be accessible to normal
outside clients using web browsing or file access
(or any other type of access). |
| 2 |
Remove
any extra applications from your application directory.
Only install the applications you are making available
to the end users. |
| 3 |
Be
certain to remove all the sample applications
that install with the Macromedia Flash Communication
Server MX. |
| 4 |
Set
the <Streams> value in Vhost.xml to point
to the directory where streams are stored. This
directory should not be accessible to normal outside
client's web browsing, file access, etc. You can
also set this in Application.xml |
| 5 |
Check
the <ResourceLimits> values in Vhost.xml
to allow the proper number of shared objects,
etc. Some of these values are limited by your
server license. |
| 6 |
Adjust
the <Allow> value in Vhost.xml if you are
restricting the connections to that virtual host. |
| 7 |
Under
the <JSEngine> section in Application.xml,
change the <MaxTimeOut> value to prevent
a runaway script from executing endlessly. |
| 8 |
Check
all the values in Application.xml. This file provides
the default settings for all applications on the
virtual host. |
|
| Web
files |
| |
|
|
| 1 |
Your
web files (HTML, SWF, and so forth) should be
installed in your web server's publicly available
folders. If this is the same computer which
has the Flash Communication Server, keep the
web files in a completely separate directory
from the application files. |
| 2 |
Remove
any extra files from the web-accessible directories
on your server. Make certain you haven't left
the Flash source files for your movies (the FLA
files) where they could be read by the public. |
|
|
| |
Conclusion
This checklist will help you review many important security-related
configuration settings at production time. During deployment,
moreover, adjusting these settings properly can help to
ensure that your server remains secure and working in top
form.
|
|
| About
the author
Dave Simmons joined Macromedia in 1993 and is currently
an engineer on the Flash Communication Server MX team. Prior
to joining that group, he developed the Shockwave Multiuser
Server for Director. He spent several years as Project Manager
for SoundEdit 16 and also worked on Japanese, Chinese and
Korean language versions of Macromedia products. In a prior
life, he worked in Tokyo and Singapore for 8 years before
settling in Northern California. |
| |
|
|
|
|
|
|
