Flash媒体服务器

将简单谚语 "简单就是美（less is more）" 应用于你的Flash Media Server (FMS)设备，意味着你将会遇到较少的麻烦、安全恶梦或客户投诉等问题。因此，你的FMS设备能够正常启动和运行；而你希望一切事件能够保持这种方式。

在本文中，你将学习如何避免你的FMS用于不当目的的若干方法，以及了解如何关闭你不需要的功能和掌握你不知道的关于你的服务器的知识。

要求

为了最大程度地利用本教程，你需要准备下列软件：

Flash媒体服务器

试用
购买

Flash媒体鉴权附加项 (可选)

下载

预备知识

你应该了解一些关于Flash Media Server管理和应用程序开发的基本信息。如果你是系统管理员，则你应该已经安装了FMS并且至少一次打开过配置文件，因此你已经了解你的设备需求。如果你是应用程序开发人员，你应该具有编写服务器侧ActionScript的基本知识以及了解你是否可以在应用程序中插入你自己的Application.xml配置覆盖代码。

为什么需要强化Flash媒体服务器功能？

Flash媒体服务器是并且总是这样一种产品，它决定了能够使得每件事变得简单以及产品在开箱时能够正常运行。 Flash媒体服务器在这方面已经成功，但我们已经将自己带入了这样一种境地，就像瑞士军刀具有全功能一样，FMS将会引起一个问题。

该问题是有些用户不熟悉基于其FMS设备运行的功能，以及不了解其根据需要关闭、限制或控制这些功能的选项。这是一个与安全相关的问题，正如盗看实况视频流一样，对内容进行认证以及提供大量协议配置能够应付所有种类的安全方面不良习惯，而用户应该知晓这些不良习惯。

你可以通过针对安全方面不良习惯合理地配置FMS设备以便保护你的FMS设备。业界用于描述这一过程的术语是强化（hardening），本指南将说明你能够做什么以便强化你的FMS设备功能。

服务器管理员指南

下面强化指南适用于FMS管理员。本指南假定管理员总体上具有该个体系统和FMS的根访问权限（root access）。下面的章节将划分为：

系统级（System-level）配置
虚拟主机级（VirtualHost-level）配置

红色条目将被高亮为最重要部分，目前被用于获取最重要强化完成条目。

系统级配置

强化FMS设备功能需要了解FMS运行的系统。特别地，必须高度注意容许的网络设置和接入控制，详细情形描述如下：

网络

在你的FMS部署之前加装防火墙可以阻止无控制软件的有害网络接入。请考虑利用防火墙过滤FMS未使用的端口以及将你需要的端口列入白名单。在默认情形下，FMS 使用端口1935、43和 80 接收客户端通信消息。许多配置完全不需要使用端口443，因此可以在防火墙闭塞该端口。大多数设备需要访问端口1935 和 80 以分别进行RTMP和RTMPT操作。

RTMFP使用UDP协议进行通信。许多防火墙在所有端口全部闭塞UDP协议。因此，需要考虑打开端口范围以便用于适当的RTMFP通信（详细内容可以在相应的RTMFP文档中找到）。

目前不能安全地访问FMSAdmin (RTMPS)，因此Adobe 当前建议闭塞端口1111以阻止外部访问FMSAdmin服务。因此，对FMSAdmin控制终端的访问将被限制于你的添加防火墙网络内部范围。
blocking port 1111 to prevent external access to the FMSAdmin service. Access to the
FMSAdmin console will be consequently restricted to within your firewalled network.

系统接入

确保只有管理员或可信用户才具有访问FMS设备文件夹、配置和注册表键值（在使用Windows的情形下）的权限。对这些文件的未控访问可以允许用户接管和修改你的FMS设备，否则将会危及你的FMS设备的安全性。

应该基于需求对FMS媒体内容的访问进行限制，只有FMS和必需的内容上传者及下载者才可以访问FMS媒体内容。对这些领域的未控访问可能会损害FMS性能以及危害客户的内容。

在Unix系统中，FMS应该根据在Server.xml中设置的UID和GID被配置为一个具有有限许可的用户运行。按照推荐，该FMS用户应该具有对配置文件的只读访问权限，以便在违反安全或意外覆盖的情形下阻止有害的更改操作。另外，FMS用户还应该具有对FMS可执行代码的只读和执行许可，以便阻止对FMS DLLs的协同攻击。最后，FMS用户在其自己文件夹和内容目录之外应该具有有限至无许可权限。

在将FMS配置为一个备用用户运行时应该特别小心。此时，FMS具有必要的许可权限以便读取其自己文件夹的所有内容，另外加上对FMS_INSTALL_DIR/tmp目录以及任何视频流存储位置的读/写权限。 FMS还需要支持发起进程间通信的功能-例如访问共享内存和创建互斥体（mutex）等。最后，许多用户需要FMS以便与网络共享资源进行通信以及为特定用户提供网络登录信任状以便对网络源进行认证。即使已经给出上述这些详细说明，在改变FMS用户的许可权限时，你也需要非常小心，并且需要彻底地对这些配置改变进行测试。

如果可能，FMS日志和记录位置应该设置于系统盘位置之外，以便防止由于占用太多磁盘空间而造成意外写入操作。

在文件处理（file handles）、semaphores、sockets和其它受限系统资源等方面的FMS系统限制配置应该考虑最大负荷需求，而不能无任何限制。对这些资源的设置在很大程度上取决于设备。在系统处于正常运行状态下，应该通过监测每种系统资源，为高负荷添加合理的附加容量，最后限制总使用量以防止过度使用，来确定为每种系统资源建立合理的设置。

应用程序

利用FMS部署的范例应用程序在默认情形下支持实时视频流和视频流录制。当你的部署工作准备完毕时，而且没有使用VOD和实时应用程序，请考虑删除它们以便不再支持各种具有许可的、著名的范例应用程序。

Server.xml配置

在FMS Server.xml文件中配置下列元素以便增强你的设备安全性：

Root/Server/NetworkingIPV6: 如果你的FMS配置没有部署IPV6网络，你可以考虑在你的FMS中关闭这一方式。

FMS能够根据需要用于为Flash Player或浏览器提供crossdomain.xml文件。通过限制域（你的FMS将从这些域接受跨域连接），这样能够改进你的部署的安全模型。如需获得更多信息，请参见 Adobe Cross Domain Policy File Specification .

Root/Server/SSL: 将你的服务器配置为使用已包含的SSL配置发送RTMPS可以为客户端-服务器通信提供具有经过验证的安全性的OpenSSL。在此必须提供证书位置和配置以便有效地通过RTMPS进行通信。

Root/Server/Process: 正如在系统接入中提及的那样，在Linux平台，根据需要及利用仔细选择的许可权限，可以创建一个FMS用户。设置FMS以这一用户身份、使用
Process 元素运行。

Root/Server/Mask: 当FMS创建文件时，在Linux平台上设置文件写入掩码（file-writing mask）以便控制已编写完成的FMS文件的读/写访问权限, 这样只有必要的用户才能访问这些文件。注意，FMS自己必须具有正确写入其创建的文件的权限。

Root/Server/AdminServer/RTMP/RTMPE: 如果你必须与FMSAdmin服务器进行外部通信 (不是建议的方式)，则一定要使用RTMPE 协议。这将为RTMP basic提供一些保护，但由于RTMPE是一种具有版本号但没有证书的协议，因此上述保护是不完整的。如上所述，FMSAdmin应该添加防火墙以便只允许可信源接入。

Root/Server/AdminServer/Process: 务必将FMSAdmin 服务器设置为FMS 用户的运行方式，这样可以限制对API的任何意外使用或行为。

Root/Server/AdminServer/(Allow|Deny|Order): 为了进一步限制FMSAdmin接口：如果可能，建立一个可接受IP的白名单，只有通过这些IP才能管理FMSAdmin。注：这一方式不能替代利用防火墙过滤对FMSAdmin的访问。

Root/Server/AutoCloseIdleClients: 将空闲客户端从你的FMS设备中删除可以帮助保持系统资源处于最低水平，因此可以避免基于空闲客户端的攻击或资源浪费。

Root/Server/ResourceLimits/FLVCache/MaxSize: 在进行VOD部署情形下，这一方式将会最大程度地使用你的FMS系统的内存。这一方式的设置应该考虑在拥有深而有效高速缓存和可能覆盖系统资源之间保持平衡。例如，需要考虑FMSCore进程的数量，它们可能立即激活、具有完全的高速缓存。通常，可以使用下列经验法则：

Scope: scope (由Application.xml确定，参见本强化指南的相关章节 ) 将决定FMS发起的FMSCore进程的数量，它取决于你的各种adaptors、vhosts、应用程序和实例的负荷。考虑这一方式立即创建的最多核的数量。
Distribute: 现在考虑是否FMSCore进程将被进一步分为多个实例。这将会增加前面的数量。
Rollover: 此外，如果rollover是激活状态并且MaxCores 元素被设置为大于1，则该数字再次乘以可能的FMSCore进程总数。注意，在默认情形下，Rollover是去活状态。

考虑保持总核数为1-16以便保持系统资源处于可维持状态；当总核数小于8时，系统资源为理想状态。此外，需要考虑上述高速缓存空间仅仅是FMSCores空间的一个部分-其它内存的开销是在套接字缓存（socket buffer）、线程栈（thread stack）和关联缓存（associated buffer）中消耗的。因此应该为每个FMSCore进程分配一些开销。

最后，根据n个FMSCore消耗m字节内存来推算需要多少可用的系统资源。确保这一数字不能消耗你的FMS系统的可用内存，以便防止由于使用过分和内存交换而造成可能的内存枯竭。

Root/Server/ResourceLimits/Protocol/RTMP/Edge/MaxConnectionRate: 考虑设置一个最大连接率（maximum connection rate），以便防止快速涌来的大量用户耗尽用于处理它们的系统资源。 FMS应该能够每秒处理成百上千的连接，但对脚本和插件的处理将会使得FMS的处理速度降低，因此必须在进行设置之前对其进行测试，以确保选择的参数级别不会损害服务器性能，或不会被设置太高以致不能防止损害。

Root/Server/SWFVerification: 使用该元素来控制主SWF文件的位置，这些文件将为所有需要SWF Verification的应用程序传递相应的SWF Verification。这将为SWF Verification要求提供一个主钥（master key ）。必须确保个体客户端不能在此上传其应用程序的SWF文件，因为这将允许这些SWF文件连接至所有应用程序。

Root/Server/Httpd: 如果你不打算使用内置的Apache服务器传送HTTP下载内容，你必须确保关闭这一配置。

Users.xml

正如我前面指出的那样，建议FMSAdmin不要暴露于大众，因为它只提供基本明文密码安全机制，因此不适合公开暴露。配置下列User.xml的元素以进一步强化你的FMS设备功能：

Root/UserList/User/Password: 建议你激活 Password 加密功能以防止错误配置文件访问危及密码安全。

Root/UserList/User/[Allow/Deny]: 考虑只允许那些已知为安全的IP连接至FMSAdmin。这一方式不是用于替换FMSAdmin的防火墙限制功能，而是该功能的补充。

Root/AdminServer/HTTPCommands/Allow: 只允许使用必要的管理员命令将会防止使用功能强大但不是必需的命令。

Adaptor.xml

配置下列Adaptor.xml元素：

Adaptor/Allow: 如果连接FMS的目标客户IP是预先已知的，则考虑在此通过将这些连接添加至 Allow/Deny 元素来锁定它们。

Adaptor/HTTPTunnel/Enable: 如果不需要RTMPT和RTMPTE协议，你应该将它们去活。

Adaptor/SSL: 必须特别注意SSL设置，它用于激活RTMPS以及为你的RTMP获取具有经过验证的安全性的SSL。此外，还需要特别注意 SSLCertificateFile , SSLCertificateKeyFile 和CipherSuite 的设置。

Adaptor/HTTPIdent: 中启动和提供信息是一些播放器/服务器设备的必要操作，但如果没有必要，这将会为攻击者提供FMS 版本信息和状态信息，因此必须仔细考虑在 HTTPIdent 中提供的信息以及这些信息对于你的部署是否是必需的。

Adaptor/HTTPUserInfo: 与 HTTPIdent 相同的指南同样适用于 HTTPUserInfo : 如果没有必要，应该优先选择去活。

虚拟主机(VirtualHost)级配置

虚拟主机能够用作一个或多个域的FMS。它位于联网和系统接入级之下，但具有更多特别需要考虑的FMS因素，例如对FMS资源的限制等，以及各种需要考虑的应用程序控件。

VHost.xml

配置下列VHost.xml元素：

VirtualHost/AutoCloseIdleClients: 激活这一配置不仅能够防止浪费，而且能够防止涉及大量处于“空闲却在线”（idle-but-present）状态的客户端的攻击。使用这一配置将会确保某些客户端不能缓慢地消耗至你的FMS的所有连接资源。

VirtualHost/ResourceLimits: 每项资源限制应该设置为一个合理的水平以防止用户或攻击者利用巨量的连接、视频流或共享对象来耗尽你的FMS资源。

VirtualHost/VirtualDirectory: 确保安全地建立你的虚拟目录，这样在你的虚拟目录根下面将不会存在敏感文件。例如，在Windows系统中，使用C:/作为你的Streams的 VirtualDirectory 根目录将允许通过适当的播放尝试读取在该级别下面的所有文件。

VirtualHost/Allow: 如果预知特定域相关信息，考虑只允许它们连接到你的FMS。

VirtualHost/Proxy/SSL: 使用这些配置控制输出边界/原点（edge/origin）通信，以便能够使用RTMPS和确保高级别的安全。

Application.xml

放置于conf文件夹中的Application.xml文件是默认的Application.xml文件，如果允许，用户可以在其Application文件夹中对这一默认文件的某些设置的覆盖操作进行定义。你应该防止用户覆盖不应该编辑的值。为了实现这一目的，指定 override="no" 作为Application.xml文件的任一XML元素的属性。如果已经指定 override="no" 属性并且节点具有子节点，则这些子节点将继承相应的覆盖设置。因此，为了确保最大程度的安全性，在Application.xml 的根目录的Application元素中添加 override="no" Application ，而且不能对其进行任何改变。

Application/Process/Scope和 Application/Process/Distribute: 仔细考虑这两个元素的使用，因为它们可以决定在没有rollover配置的情形下，运行的FMSCore进程数量。 Scope 决定如何将FMS操作进行分类放入可执行代码中。 Distribute 进一步对核进程数量进行增扩。注意不要指定太多可执行代码。例如，将 Scope 改变为 inst inst并且创建1000个app实例是耗尽具有1000个FMSCore进程的系统资源的“秘诀”。进一步的分发将会再次扩大FMSCores的数量。首先应该确定一个系统要求运行FMSCores的数量。 Adobe的建议是每个虚拟主机的FMSCores数量不能多于16，而推荐的目标数量仅为3，与默认配置相同。Application/Process/Lifetime: 不要反编译FMSCores，除非Adobe的支持工作人员建议这么做，以避免被追究调查。这一设置将会进一步扩大一个系统运行的FMSCores数量并且导致一些未曾预想的副作用。

Application/AuthCloseIdleClients: 正如在VHost.xml中一样，关闭空闲客户端能够降低你的系统资源消耗，并且能够防止利用巨量空闲客户端进行的攻击行为。

Application/JSEngine/RuntimeSize: 务必限制JavaScript内存的总量，以便垃圾收集功能可以有效地防止用户无意识地消耗系统资源。

Application/JSEngine/MaxTimeout: 利用该配置可以防止JavaScript无限循环损害系统的性能。应该注意核查无限循环需要付出一些JavaScript性能代价，因此，根据需要选择这一设置。

Application/JSEngine/FileObject: Adobe强烈建议不要为
VirtualDirectory 设置 FileObject 参数。利用脚本可以将这一配置写入选择的位置，这样可以对可能的攻击者的期望目标进行控制。除非具有明确需求，否则不要打开 FileObject VirtualDirectory ，或者如果打开，必须确保小心地选择一个安全的沙箱位置。

Application/StreamManager/StorageDir: 设置 StorageDir 元素可以为写出记录的文件或读取VOD ("video on demand") 文件改变沙箱路径。在进行这一设置时，需要注意将文件沙箱移到一个安全位置。

Application/Recording/*: 必须对所有记录的最大长度进行设置，以便防止FMS的不良记录器消耗太多的系统资源。如果你能够对最大记录长度进行规划，则使用这一属性以强化这一功能。

Application/SharedObjManager/Max*: SharedObjManager 中的两个最大的元素 MaxProperties 和 MaxPropertySize 能够防止SharedObject 变得太大以及消耗太多资源。如果你预先知道你将不会使用共享对象或你的长度将会受到限制，请充分利用该配置。

Application/Client/Bandwidth: 这些设置能够为应用程序的视频流提供默认的带宽限制设定。BandwidthCap 可以限制最大带宽，而利用脚本可以对最大带宽进行设置。必须仔细观察这些值，因为它们均可以通过对带宽贪婪者进行计算而节省资源，但如果设置太低，在针对大量客户端视频流错误地进行调用时，它们可能引起缓存问题。因此，必须小心谨慎地选择这些值。

Application/BandwidthDetection: 必须小心谨慎地考虑是否应该将客户端暴露于BandwidthDetection 。这是一个用于确定客户端连接速率的有用度量参数。不过，它也能够用于连接消耗服务器资源，因为它对于每个连接来说具有一些关联费用。如果在用连接的数量太多，应该考虑减少连接数量或考虑将来是否需要这些连接。

Application/Access/*SampleAccess: 这两个配置AudioSampleAccess 和 VideoSampleAccess 可以控制Flash Player连接从成为视频流的RTMP内容中获取音频或视频样本信号。当设置这些配置值时必须考虑选择正确的存储器以及这些视频流是否能够删除内容的片段和离线保存它们。

Application/Debug: 调试连接只能用于开发目的。对于所有交付产品，请将 AllowDebugDefault 设置为 false (默认) 以及将MaxPendingDebugConnections 设置为0以关闭该功能。

Application/SWFVerification: SWF Verification是一款能够确保只有你选择的SWF文件才能连接至特定的应用程序的工具。建议激活该功能并且确保不良SWF文件不能连接和使用你的应用程序的资源。

Application/SWFVerification/UserAgentExceptions: 如果需要，为UserAgentException 打开一个用于编码器选择的 SWFVerification 。你还应该利用FMLE鉴权插件（Authentication Plugin）覆盖这一漏洞以便完善你的安全模型。控制编码器鉴权的Access模块（例如FMLE Plugin）和标准播放器的SWF Verification的组合是一条推荐的简单鉴权路径。请参见FMS配置文件中的关于UserAgentExceptions的注释，这些文件是用于说明如何配置你的编码器的UserAgent的范例。

Application/DisallowedProtocols: 如果你希望获得最高级别的安全性，请考虑禁止使用一切不安全的协议。例如，在此列出RTMP和RTMPT将确保只有RTMPE 和RTMPS变量能够连接至FMS，因此强迫对你的应用程序的连接进行加密。此外，必须确保你的空间列出目前被认为是不安全的任意版本的协议；例如，RTMPE1。

开发人员指南

下面指南适用于FMS应用程序开发人员。下面章节将包含修改你的Application.xml文件、编写你的服务器侧的ActionScript、保证与FMS的通信以及执行相应的鉴权操作。

红色条目将被高亮为最重要部分，目前被用于获取最重要强化完成条目。

Application.xml设置

作为一个开发人员，你可以在Application.xml中获得与服务器管理员相同的配置。关于Application.xml 强化指南

服务器脚本

下面是针对使用安全方式编写服务器脚本的若干建议。

application.allowDebug: 将 allowDebug 设置为 false 可以确保你的应用程序不允许使用调试方式连接。调试连接是通过后门进入应用程序的一个有用工具，但在产品中应该关闭。

client.agent: UserAgent 字符串可以用于识别特定类型的RTMP-speaking客户端连接。此外，它还可以用于确定版本和平台信息。如果只希望使用某种连接类型，例如只希望使用Flash Players而不使用特定类型的编码器，那么对此进行核查将是一个有效防卫工具。此外，这是连接客户端的个人信息，并且被认为是你的应用程序的私人信息数据，因此不需要与一般大众共享。

client.ip: 信息的最有意义部分之一是客户端的连接IP地址。该值不能被FMS重置或修改，它直接表示客户端IP地址或暴露给该客户端的最新代理，因此允许追踪你的连接至先前链路。这一信息可以用于根据需求筛选客户端。例如，某些IP是需要的而其它IP是不需要的或已经被禁用。此外，这是关于你的用户群的敏感信息，因此它对社会大众来说应该是受限信息。

client.readAccess 和 writeAccess: 使用这些配置限制客户端在FMS中读取或写入媒体。这是一种最佳的许可权限的限制方式，而且易于实施。不需要writeAccess 的客户端应该将它设置为空字符串以便完全拒绝写入访问并且执行更高级别的安全措施。该访问方式适用于所有FMS存储的和短小的媒体，其中包括实时的和记录的视频流以及共享对象。

client.audioSampleAccess 和 videoSampleAccess: 对该配置进行设置以便允许/拒绝客户端对其下载的视频流进行部分取样。尽管默认的行为是不允许取样，但在某些情形下，这一功能是需要的。仔细想一想打开这一功能所允许的承担截取客户端内容的风险。

client.referrer 和 pageUrl: 这些字段表示一个SWF文件体验的载入的URI — 这将确保RTMP连接来自所需的源。这一验证功能可能会受到干扰，因此针对SWF Verification不推荐使用这一验证功能-但是它仍是一种很好的检查方式，而SWF文件的URI选择正在使用这一方式。

client.nearNonce 和 farNonce: 这些字段是用于RTMP与FMS握手协商的nonce值。根据需要，它们可以用于为鉴权或其它类似协议提供随机的、一次数据源。

file object: 将FMS文件对象的所有用户锁定非常重要。这是一个功能强大的API，它能够为其控制器提供从FMS的沙箱位置写入/读取文件的能力。当与虚拟目录一起使用时，它可以用于在FMS应用程序沙箱之外写入文件，而且能够为其控制器提供一个可能的使用路径。强烈建议限制或禁止用户使用File API，并且禁止使用FMS 文件虚拟目录（File Virtual Directories）以便删除沙箱限制。

loadVars object: 不应该通过直接访问 loadVars 连接客户端。这是因为FMS将变为一个向外发出的客户端请求的代理，并且这些请求能够在比采用连接客户端方式更有特权的环境中执行。例如，如果FMS暴露于来自防火墙外部的连接，但在防火墙内具有后端许可权限，那么人们将希望包含访问这些API的权限以确保只有需要的请求才被发出。

Stream.setVirtualPath: 这一命令可以改变视频流使用的虚拟路径，并且可以用于转换播放和记录操作。使用这一命令对能够进行条目播放的设备及对能够存放条目的地方具有显著的影响，因此人们不希望为外部用户控制提供这一命令参数。

安全通信

与客户端之间的安全通信是确保你的FMS会话不受损害或截获的最有效方式。

RTMPS通信充分利用具有被证实的安全性的SSL来保护你的RTMP会话。利用具有完全认证的RTMPS和合适的加密方式将确保最高安全性。务必对由于RTMPS使用施加的适量的附加负荷进行测试，并且考虑使用SSL加速器。

基于RTMPE的通信方式可以提供RTMPS的若干优势，但不能提供其所有功能。它以性能和无证书通信换取处于私有Adobe控制下的具有版本号的协议。这意味着为了安全目的你可以充分利用RTMPE，但你必须确保你只能使用最新版本的RTMPE，并且只能信赖基于具有被证实安全性的RTMPS及附加性能折衷被正确评估的RTMPE。

鉴权

用户鉴权依赖于具有可靠基础的安全通信方式。如果可能，必须使用上述的最佳安全通信方式，以防止最好的鉴权技术成为截取的目标。

使用SWF Verification将允许FMS限制到特定应用程序的连接只能来自所需的SWF文件。这将确保不良SWF文件或非Flash Player代理不能连接至你的应用程序。如果某些连接代理不支持SWF Verification，则必须将UserAgentExceptions添加至SWF Verification配置中。

可以通过FMLE Authentication Addin对非SWF播放器（例如FMLE视频编码器）进行鉴权。

通过客户端和服务器脚本，或使用基于用户连接信息的接入/鉴权插件，客户端可以实现其自己的鉴权系统。例如，在连接时间请求提供一个独立的鉴权令牌和通过脚本或适配器获取该令牌能够打开/关闭相关特权，并且提供一个高粒度和控制的解决方案。

下一步阅读方向

请签约Above的安全通知服务（Security Notification Service）这是一种很有价值的服务，它可以通知你各种重要的漏洞利用修正补丁。

关于FMS安全或强化你的FMS设备功能的更多问题，请发帖至Flash Media Server forums Flash Media Server论坛

FMS Support和FMS Escalations团队将尽最大努力回复这些问题，并且将其公布以便所有相关人员均受益。在某些安全敏感的情形下，Adobe技术人员可能会请求进行离线讨论，以便以合适的方式处理问题，直到基于大众的利益安全地解决这些问题。如果你已经知道涉及FMS 或其它Adobe产品的安全问题，请使用 security response page .

关于Adobe产品安全事件响应团队（Adobe Product Security Incidence Response Team）的更多信息，请考虑跟随其博客（following their blog）。

本文遵守知识共享—署名-非商业性使用-相同方式共享3.0 Unported License (Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License) 许可条件。

作者简介

Asa Whillock是Flash Media Server项目的负责人，他负责管理 FMS Escalations和Security团队。他从2001年FMS的创始阶段（此时其名称为Macromedia Flash Communication Server）开始一直在该公司工作。他感到最为骄傲的事件是他是Flash视频的一些最成功功能的主要开发人员，例如，H.264 integration、SWF verification和 RTMPE。 Asa毕业于UC Berkeley大学，获得电气工程和计算机科学理学学士学位，他现居住于San Francisco。他认为FMS的成功不仅依赖于在版本发布时提供的高质量的产品，而且依赖于在日常与客户及合作伙伴的配合时提供高质量的服务。