测试网络基础结构配置

总结
互连和异构 Web 服务器基础结构（可能包括数百个 Web 应用程序）的内在复杂性使得配置管理和审查成为测试和部署每个应用程序的基本步骤。只需要一个漏洞就可以破坏整个基础架构的安全性，即使是看似不重要的小问题也可能演变成同一服务器上另一个应用程序的严重风险。为了解决这些问题，在映射整个体系结构之后，对配置和已知安全问题进行深入审查至关重要。

为了保护应用程序本身的安全性，Web服务器基础结构的正确配置管理非常重要。如果未正确检查和保护 Web 服务器软件、后端数据库服务器或身份验证服务器等元素，则它们可能会引入不希望的风险或引入可能危及应用程序本身的新漏洞。

例如，允许远程攻击者泄露应用程序本身源代码的 Web 服务器漏洞（在 Web 服务器和应用程序服务器中多次出现的漏洞）可能会危害应用程序，因为匿名用户可以使用源代码中披露的信息来利用针对应用程序或其用户的攻击。

• 需要执行以下步骤来测试配置管理基础结构：
• 需要确定构成基础结构的不同元素，以便了解它们如何与 Web 应用程序交互以及它们如何影响其安全性。
• 需要检查基础结构的所有元素，以确保它们不包含任何已知漏洞。
• 需要审查用于维护所有不同要素的管理工具。
• 需要检查身份验证系统，以确保它们满足应用程序的需求，并且外部用户无法操纵它们来利用访问权限。
• 应维护应用程序所需的已定义端口列表，并将其置于更改控制之下。

映射构成基础结构的不同元素（请参阅映射网络和应用程序体系结构）后，可以查看建立的每个元素的配置并测试任何已知漏洞。

测试目标

• 查看跨网络设置的应用程序配置，并验证它们是否易受攻击。
• 验证使用的框架和系统是否安全，并且不容易受到由于未维护的软件或默认设置和凭据而导致的已知漏洞的影响。

如何测试

已知服务器漏洞

应用程序体系结构各个领域的漏洞（无论是在 Web 服务器还是后端数据库中）都可能严重危害应用程序。例如，考虑一个服务器漏洞，该漏洞允许未经身份验证的远程用户将文件上载到 Web 服务器，甚至替换现有文件。此漏洞可能会危害应用程序，因为恶意用户可能能够替换应用程序本身或引入会影响后端服务器的代码，因为其应用程序代码将像任何其他应用程序一样运行。

如果需要通过盲渗透测试进行测试，则很难查看服务器漏洞。在这些情况下，需要从远程站点测试漏洞，通常使用自动化工具。但是，测试某些漏洞可能会在 Web 服务器上产生不可预知的结果，并且由于测试成功所涉及的服务停机时间，可能无法测试其他漏洞（如直接涉及拒绝服务攻击的漏洞）。

一些自动化工具会根据它们检索的 Web 服务器版本标记漏洞。这会导致误报和漏报。一方面，如果本地站点管理员删除或掩盖了 Web 服务器版本，则扫描工具不会将服务器标记为易受攻击，即使它是。另一方面，如果提供软件的供应商在修复漏洞时未更新 Web 服务器版本，则扫描工具将标记不存在的漏洞。后一种情况实际上非常常见，因为一些操作系统供应商将安全漏洞补丁移植到他们在操作系统中提供的软件，但不完全上传到最新的软件版本。这发生在大多数GNU/Linux发行版中，如Debian，Red Hat和SuSE。在大多数情况下，应用程序架构的漏洞扫描只会发现与架构的“暴露”元素（例如 Web 服务器）相关的漏洞，并且通常无法找到与未直接公开的元素相关的漏洞，例如身份验证后端、后端数据库或使用中的反向代理 [1]。

最后，并非所有软件供应商都公开披露漏洞，这意味着这些漏洞可能不会在已知的漏洞数据库中注册[2]。此信息仅向客户披露或通过没有随附公告的修补程序发布。这会降低漏洞扫描工具的有效性。通常，这些工具的漏洞覆盖对于常见产品（如Apache Web服务器，Microsoft IIS或IBM的Lotus Domino）非常有用，但对于鲜为人知的产品则缺乏漏洞覆盖率。

这就是为什么最好在向测试人员提供有关软件的内部信息（包括版本、发行版和应用的补丁）时进行漏洞审查。有了这些信息，测试人员可以从供应商处检索数据，分析架构中的潜在漏洞，以及它们对应用程序的潜在影响。如果可能，可以测试这些漏洞以确定其实际影响，并检测是否存在任何外部元素（如入侵检测或防御系统）可能会减少或否定成功利用的可能性。测试人员甚至可能通过配置审查确定该漏洞实际上并不存在，因为它会影响未使用的软件组件。

还值得注意的是，供应商有时会默默修复漏洞，并在新软件版本中提供修复程序。不同的供应商有不同的发布周期，这些周期决定了他们可能为旧版本提供的支持。具有有关体系结构使用的软件版本的详细信息的测试人员可以分析与使用旧软件版本相关的风险，这些版本可能在短期内不受支持或已经不受支持。这一点至关重要，因为如果不受支持的旧软件版本中出现漏洞，系统人员可能不会直接意识到它。不会为其提供修补程序，并且公告可能不会将该版本列为易受攻击的版本，因为它不再受支持。即使他们意识到漏洞和相关系统风险，也需要完全升级到新的软件版本，这可能会在应用程序架构中引入大量停机时间，或者由于与最新软件版本不兼容而需要重新编码应用程序。

管理工具

任何 Web 服务器基础结构都需要存在管理工具来维护和更新应用程序使用的信息。此信息包括静态内容（网页、图形文件）、应用程序源代码、用户身份验证数据库等。使用的管理工具类型可能因所使用的特定站点、技术或软件而异。例如，某些Web服务器将使用管理界面进行管理，这些界面本身就是Web服务器（例如iPlanet Web服务器），或者由纯文本配置文件（例如在Apache案例[3]中）或使用操作系统GUI工具（例如使用Microsoft的IIS服务器或 ASP.Net 时）。

在大多数情况下，服务器配置使用各种文件维护工具进行管理，这些工具通过FTP服务器，WebDAV，网络文件系统（NFS，CIFS）或其他机制进行管理。显然，构成应用程序体系结构的元素的操作系统也将使用其他工具进行管理。应用程序还可能包含用于管理应用程序数据（用户、内容等）的嵌入式管理界面。

映射用于管理体系结构不同部分的管理界面后，查看它们非常重要。如果攻击者获得对这些接口中的任何一个的访问权限，他们可能会破坏或损坏应用程序体系结构。为此，请务必：

• 确定控制对这些接口的访问及其相关敏感性的机制。此信息可在线获取。
• 确保更改默认用户名和密码。

一些公司选择不管理其 Web 服务器应用程序的所有方面，并可能将内容管理委托给其他方。此外部公司可能仅提供内容的某些部分（如新闻更新或促销），也可能完全管理 Web 服务器（包括内容和代码）。在这些情况下，通常会从 Internet 找到可用的管理接口，因为使用互联网比提供通过仅管理界面将外部公司连接到应用程序基础结构的专用线路便宜。在这种情况下，测试管理界面是否容易受到攻击至关重要。

引用

• [1] WebSEAL，也称为 Tivoli Authentication Manager，是来自 IBM 的反向代理，它是 Tivoli 框架的一部分。
• [2] 例如赛门铁克的Bugtraq，ISS的X-Force或NIST的国家漏洞数据库（NVD）。
• [3] Apache有一些基于GUI的管理工具（如NetLoony），但它们还没有被广泛使用。