如果 XML Web 服务正在 Internet Information Server (IIS) 上运行，那么我们就有必要提及一种能免费得到的非常有用的报告类型。即，为所有传入的 HTTP 请求（包括对您服务的请求）进行的 IIS 日志记录。您可以使用 IIS 日志中提供的信息来改进自己的报告。
最后，实施了审核及适当的报告方法后，您需要使用某种机制以发现所报告的问题。这就是监视。
可以以不同级别进行监视。当然，定期手动查看报告是监视 XML Web 服务的使用情况的一种方式，但是还应检查事件日志中已报告的错误，使用性能监视日志，并利用可以监视 Web 服务器停机时间的多种工具中的一种。性能监视对于检测攻击可能是非常关键的。幸好，与 IIS 关联的大量性能计数器可以为检测问题提供许多重要的统计数据。
您可能还希望为 XML Web 服务创建自己的性能计数器。有关创建您自己的性能计数器的详细信息，请参阅 Performance Monitoring（英文）。为了确保引起您对异常情况的特殊关注，应以某种形式通知您正在发生的事件，这点是非常重要的。可以在异常事件发生时，利用性能监视警报发送弹出式消息，或运行某个程序。图 1 显示的性能监视警报会监视未完成的 IIS ISAPI 请求的数量，以及当前队列中的 ASP 请求的数量。
如果不对可能发生的问题采取一些措施，则对滥用的操作进行审核、报告和监视不会有任何用处。拒绝服务攻击可能会被定义到特定的 IP 地址，这意味着您可能需要在路由器中过滤来自该地址的请求。但是，拒绝服务攻击或电子欺骗攻击可能与 XML Web 服务的特定用户相关。您必须能够在这种问题发生时禁用帐户。完成此操作可能仅需在 Microsoft® Active Directory™ 中禁用 Windows 用户帐户。或者，如果使用的是自己设计的身份验证方式，则意味着必须在用户记录中添加一个可以表示禁用帐户的状态字段。您还应确认 XML Web 服务的用户同意“服务条款”文档，该文档指明在何种情况下您可以删除或禁用他们的帐户。
定义接口
与其他 Web 应用程序相比，XML Web 服务器应用程序的一个主要优点就是很好地定义了传递到您的应用程序的整个 XML 架构。对于应用程序设计人员和开发人员来说，这意味着您已经知道 XML Web 服务所必须处理的数据具有有效的格式。如果接收的数据格式不正确，那么 Microsoft® SOAP Toolkit 2.0 或 .NET 框架之类的工具将过滤出该请求，这样您就不必为此担心了。
例如，您不必分析日期输入的语法是否有效。日期必须具有有效的 XSD 格式，否则该请求会被丢弃。您可能需要利用结构验证，因此不要隐藏字符串变量中的结构。利用 XML 的能力和灵活性可以全面描述发送和接收的数据。
不可见的服务器
黑客攻击您的系统时，首先寻找的是信息。此 Web 站点是驻留在 Windows 中还是驻留在其他系统中？是否正在运行 Active Server Pages？是否安装了 Index Server？是否安装了已知的易受攻击的组件？是否安装了已知的易受攻击的 CGI 应用程序？主机是否正在运行 Microsoft SQL Server？我是否可以对此服务器进行分布式 COM (DCOM) 调用？
对于不希望受到攻击的站点，即使非常聪明的 Internet 用户也应该无法回答上述任何问题。黑客对您的系统了解得越少，对平台的了解也越少，就越难在您的服务器上找到问题。
例如，试想一下，如果黑客只知道 XML Web 服务的 URL 为“http://www.coldrooster.com/ssf/account.asp”，他们能了解什么呢。由于此 URL 的扩展名为 .ASP，他们可以假设这是一台运行了 Active Server Pages 的 Windows 计算机。根据黑客对 Internet Information Server 的默认配置的了解，他们已具有足够的信息对大量的未正确配置的弱点进行攻击。他们可对配置方法进行大量的、很可能有效的假设，并用这些假设来刺探计算机。
如果 URL 为“http://www.coldrooster.com/ssf/account/”，情况又会怎样呢？在这种情况下，黑客得不到任何服务器所用操作系统的信息，也无从假设系统的配置。将虚拟目录级的请求映射到某个特定的 ASP 页是一个非常小的配置选项，但能为服务器提供很多保护。
熟悉基本 HTTP 协议的用户可能注意到 HTTP 标头特别指明了正在使用的 Web 服务器类型。是的，这是另一种确定计算机上操作系统的更为复杂的方法，但是也可以编写 ISAPI 过滤器来删除或替换此标头。有关如何进行这种操作的信息，请参阅 Developing ISAPI Filters（英文）,以及 IIS 程序员指南中的 SF_NOTIFY_SEND_RESPONSE（英文）通知。服务器上运行的基础系统越难辨认，黑客编写的用于在 Internet 上查找某种类型计算机的脚本失败的可能性就越大。
但是操作系统本身并不是唯一的弱点。您创建的 ASP 页在后端执行 SQL 查询并抛出异常时，会执行什么操作？您是否将异常信息返回给用户浏览器？这样不仅指出了 Web 服务器平台，还指出了数据库平台。除此之外，它还可以使用户了解您正在进行的特定 SQL 查询，并为他们提供信息，使其了解如何更改要输入到窗体中的内容以得到他们不应有权访问的信息。
出现其他 COM 异常情况怎么办？如果将异常信息传播给用户，黑客将会知道您的计算机上安装了哪些 COM 组件。如果此 COM 对象是第三方 DLL，则黑客可以得到它的一个副本，并竭尽全力搜索可能存在的所有弱点。这至少使黑客有机会了解服务器上可能存在的问题。
同样，黑客可能会利用触发 COM 异常这一事实来阻塞服务器。黑客意识到多数异常代码路径未经充分测试，且常常是资源泄露或变得更糟的起因。要避免出现这种情况，服务器上的代码应能捕获所有异常情况，并且应该只返回普遍性的错误。对于 XML Web 服务，您应返回几乎不带有平台信息的 SOAP 错误。您可能希望以某种方式将数据连同 ID 一起返回给用户以便将错误与审核日志中的记录进行比较，但是，请将错误详细信息放在审核日志中而不是放在返回的 SOAP 错误中。建议应用程序设计人员创建自己的应用程序的 SOAP 错误架构，同时提供一个非常短的选项列表，并且仅返回此列表上的错误。调用 XML Web 服务的客户端不必知道有关 SQL 查询异常的详细信息，他们只需要知道出现了 SOAP 服务器错误。
如果正在使用 Microsoft® SOAP Toolkit 2.0，可以在 COM 对象上实现 ISoapError 接口以返回您希望返回的确切的 SOAP 错误,而不是一般的工具包错误。一般的工具包错误可以提供大量的、有关错误出现时在服务器上所发生情况的信息。在开发阶段，工具包错误对于调试来说是很有用的，但是它们在产品服务器上不应出现。他们可以为黑客提供大量的、具有潜在破坏性的信息。
