Apache Tomcat 安全性指南

Apache Tomcat 在安全性方面拥有令人印象深刻的记录。根据官方 Apache Tomcat Wiki Pages，从未报告过由于对任何 Apache Tomcat 实例的恶意攻击而导致实际损坏或重大数据丢失的案例。大多数漏洞，无论是主要的还是次要的，都是由 Tomcat 社区本身或安全研究人员发现的，并迅速修补。因此，Tomcat的默认安装可以说是“相当安全”的。

从这个基线开始，可以采取其他措施来使 Tomcat 对于给定的用例尽可能安全。与任何安全方案一样，Tomcat 安全性是在易用性和访问与访问的限制和强化之间取得平衡。例如，虽然在迁移到生产环境时禁用 Tomcat 的部署功能在技术上更安全，但对于许多组织来说，自动化部署的愿望取代了禁用这些功能的安全优势。 

在本文中，我们将提供 Tomcat 中包含的安全功能的概览。为了有效地实施这些实践，管理员应该为他们所监督的系统创建一个经过充分研究的配置文件，并根据这组明确的需求来确定可以进行哪些安全改进。  

本文涵盖三类安全改进：  Tomcat 内部配置的更改、运行 Tomcat 的操作系统的更改以及 Web 应用程序的最佳安全实践。

强化 Apache Tomcat

在本节中，我们将了解您可以采取哪些措施来调整 Tomcat 实例的安全性，以更好地满足您的访问和功能要求。

保持最新

由于 Tomcat 是一个活跃的开源项目，提高实例安全性的最简单方法是使您的版本保持最新并与 Tomcat 邮件列表保持同步。每个版本都添加了新的错误修复和安全补丁，并且可能适用于您的基础架构的新问题在 Tomcat 邮件列表中进行了讨论。Apache 还通过Tomcat Announce 邮件列表通知社区成员主要的安全威胁和补丁 。始终尽快升级到 Tomcat 的最新稳定版本。

维护和使用日志

维护良好的访问日志是识别安全漏洞和攻击源的重要工具。在开发环境中，您应该防御哪些类型的恶意活动并不总是很明显。在投入生产后维护日志将有助于确保在开发中看起来安全的应用程序在现实世界中保持安全。  

日志应该在多个级别上维护 - 用户访问、应用程序流量、Tomcat 内部和操作系统/防火墙，并且所有系统管理员都应该同意一个用于查看和处理日志的单一过程。

要在 Tomcat 中启用网络流量记录，请使用 AccessLogValve 组件。该元素可以在主机、引擎或上下文的基础上进行配置，它将创建一个标准的 Web 服务器日志文件，用于与与其关联的任何资源的流量。Access Log Valve 支持多种属性来控制 Valve 的输出。

有关配置 AccessLogValve 的详细信息， 请单击此处。

请注意，如果您通过另一台服务器代理对 Tomcat 的请求，您还应该在那里启用日志记录。 

控制访问

由于 Tomcat 从良好的安全基线开始，您可以采取的许多进一步提高其安全性的步骤涉及限制对某些资源的访问。  

部署设置

Tomcat“主机”组件可以配置为允许各种自动部署方案。这些在开发过程中非常有用，随着持续部署变得越来越普遍，越来越多的开发团队希望在生产中使用这些特性。任何主机都可以配置为根据三个参数之一自动部署应用程序 - autoDeploy、deployOnStartup 和 deployXML。（如果您想了解有关这些属性如何工作的更多信息，请访问我们的 Tomcat 部署指南。）  

如果您不需要自动部署，最好将这些属性设置为“false”——它们不仅会由于授权用户错误而导致问题，而且如果攻击者获得访问权限，它们更容易造成麻烦。服务器。

安全管理器

SecurityManager 是一个 Java 组件，它允许上下文在各个沙箱中运行。每个沙箱都可以配置不同的权限，从而对它们对系统资源的访问提供更精细的控制，并可能防止一个被破坏的应用程序允许访问其他应用程序。（有关标准 SecurityManager 类的概述， 请单击此处）。

SecurityManager 通常由一个名为“java.policy”的文件控制，该文件与 SDK 一起分发。Tomcat 使用文件 $CATALINA_BASE/conf/catalina.policy 代替此文件。Tomcat 还引入了一个自定义类 - org.apache.naming.JndiPermission - 控制对 JNDI 资源的访问。但是，catalina.policy 的格式是标准策略格式：

	
/示例条目


grant [signedBy <signer>,] [codeBase <code source>] {


  权限 <class> [<name> [, <action list>]];


};

使用 SecurityManager 的缺点是，由于大多数应用程序最初并非设计为在沙箱中运行，因此 SecurityManager 通过引入难以发现的权限错误来破坏 Web 应用程序而享有盛誉。在 SecurityManager 中运行应用程序通常需要用户编写自定义权限规则、调试产生的问题并彻底测试配置。

因此，这种安全实践通常应与开发团队一起实施。Apache Tomcat 文档中的 SecurityManager HOW-TO 包括一个故障排除部分， 为面临这些问题的开发人员提供了一些提示。

有关使用 SecurityManager 运行 Tomcat 的详细信息，请访问 Tomcat 官方文档。

Tomcat 管理器 Web 应用程序

Tomcat 管理器应用程序是一个基本的基于 Web 的 Tomcat 管理控制台 ，用于控制 Tomcat 实例、应用程序部署和其他设置。出于安全原因，默认情况下禁用管理器 - 事实上，甚至没有在 tomcat-users.xml 中配置有权访问它的用户。  

获得对 Tomcat 管理器的访问权将使攻击者对您的 Tomcat 实例具有相当大的控制权。您应该问的第一个问题是您是否需要访问管理器。如果您使用另一种方法来管理 Tomcat 实例，最好禁用管理器。  

如果您确实需要使用 Manager 应用程序，您可以强制执行许多配置选项和最佳实践来限制与运行它相关的风险。

限制访问

唯一需要访问 Manager 应用程序的人是管理员。对 Manager 应用程序的访问应仅限于已知的 IP 地址（这可以通过使用 RemoteHostValve 或 RemoteAddrValve 组件来完成）。  

作为额外的预防措施，您可以在称为 LockOut 领域的特殊类型的 Tomcat 领域中运行 Manager Web 应用程序。标准的 Tomcat Realm 组件允许无限制的授权尝试，为来自欺骗性 IP 地址的暴力攻击打开了大门。LockOut 领域通过限制在用户被锁定在系统之外之前的给定时间段内的登录尝试次数来防止这种情况。  

不要马虎

像对待任何其他重要资源（例如银行帐户）一样对待对 Manager 应用程序的访问。强制使用强密码，登录时不要访问其他网站，并确保退出。最重要的是，确保将访问该应用程序的其他任何人都理解并遵循相同的准则。

请注意，目前处于测试阶段的 Tomcat 7 包括一个改进的 Manager 应用程序，该应用程序具有更精细的角色。这将允许管理器配置更少“全有或全无”。

领域

在 Tomcat 中控制对资源的访问的一种方法是使用领域 - 访问用户数据库的组件，这些用户应该有权访问给定的应用程序或应用程序组，以及他们在登录后在应用程序中拥有的角色/权限。

Tomcat 总共包含 6 个 Realm 实现：MemoryRealm、JDBCRealm、JAASRealm、UserDatabaseRealm、JNDIRealm、DataSourceRealm。除此之外，从 Tomcat 6.0.2 开始，还包括了两个额外的伪实现：LockOut Realm 和 CombinedRealm

其中，两个——MemoryRealm 和 JDBCRealm——不应该作为一个规则使用。这些领域已分别被 DatabaseRealm 和 DataSource 领域所取代。这减少了它们的使用，因此为它们提供的错误（和错误修复）的数量已经下降。除了更好的安全性之外，替代领域还提供更好的功能，例如线程池。  

总体上最安全的 Realm 是 LockOut Realm，如上一节所述，它限制了用户可以尝试验证自己的次数。如果您需要来自多个 Realm 的功能，CombinedRealm 可用于为每个 Engine/Host/Context 配置多个 Realm 实现。 

其他配置选项

您可以启用以下一些额外的配置选项来进一步保护您的实例：

关机端口

默认情况下，Tomcat 服务器在 localhost 上侦听端口 8005 以获取关闭命令。此地址是通过服务器组件的“端口”属性配置的：

	
<Server port="VALUE" .../>


	

如果您的方案允许，将端口设置为“-1”将更好地保护您的服务器免于意外关闭。使用此配置，Tomcat 只能由拥有 Tomcat 进程的用户通过终端通过“kill”命令关闭。此标准 kill 将触发与发出关闭命令相同的正常关闭过程，但以更安全的方式。

限制连接器的可用性

默认情况下，连接器侦听所有接口。使用 Tomcat 连接器 元素的“地址”属性，您可以强制连接器忽略 Web 应用程序不需要的任何接口。  

如果您在配置连接器时需要更多帮助，请阅读我们的简单 Tomcat 连接器指南。

安全 Web 应用程序配置

尽管 Web 应用程序的适当/可行的安全措施自然会因上下文而异 ，但有一些实践适用于所有人：

如果没有理由让任何其他机制访问您的应用程序的会话 cookie，请仅限制对 HTTP 的访问。这是在 Context 组件中配置的：

	
<Context useHttpOnly='true' .../>


	

在启用允许在服务器上增加特权的属性之前请三思：

将 Context 元素的 "crossContext" 属性设置为 "true" 会使您的服务器面临损坏的应用程序向其他应用程序发送恶意请求的可能性（没有办法阻止来自其他应用程序的请求，只有这个属性可以控制是否应用程序可以创建它们）。 

某些应用程序需要通过“allowLinking”上下文属性在 Web 应用程序中启用符号链接。但是，当与不区分大小写的文件系统一起使用时，会导致源代码泄露问题。在实施之前确保您的文件系统区分大小写。

最后，也是最明显的，除非绝对必要，否则应该避免使用“特权”上下文属性来允许访问 Tomcat 内部，并且应该更加小心地限制对这些应用程序的访问。

加固操作系统

即使您的 Apache Tomcat 配置尽可能安全，不安全的操作系统也会很快使您的工作变得毫无用处。在本节中，我们将了解您可以采取的一些步骤来保护您的服务器机器本身。

在 Tomcat 中配置安全选项时，等式中有很大程度的妥协因素——更好的安全性通常意味着牺牲可用性。在配置底层操作系统时，这应该不是问题。一个好的经验法则是尝试从尽可能少地访问操作系统开始，然后从那里构建配置，直到达到 Tomcat 无错误运行所需的最低系统访问权限。

不要以 root 身份运行

在运行任何 Internet 服务时，尽可能避免以 root 用户身份运行它总是一个好主意——攻击者获得服务器控制权并因此获得系统控制权的机会太大了。安装 Tomcat 时，创建一个具有最低权限集的新用户，该用户将始终在配置过程中为您运行 Tomcat。  

（请注意，以这种方式限制权限会引入监听特权端口的问题。这些通常通过使用 JSVC、反向代理（如 HTTPD）或 iptables 工具来调用 root 用户并将适当的端口绑定到 Tomcat 用户来解决.)

配置防火墙

您的操作系统防火墙是您服务器的一道强大的防线——没有它就不要运行 Tomcat。配置防火墙时，您可以使用与所有操作系统设置相同的经验法则 - 阻止所有内容，然后一次添加一个权限，直到您允许您的方案所需的最小访问量。  

在确定允许哪些流量时，请务必同时考虑入站和出站活动。没有理由允许通过您不需要的接口进行出站活动，这可能会被恶意应用程序利用（例如，恶意程序经常使用出站 HTTP 请求与操作员进行通信）。

确定最低权限

您为运行 Tomcat 而创建的用户应仅被授予运行 Tomcat 所需的最低权限（根据您的方案的要求）。从安全的角度来看，理想的用户将只有读取文件的权限。  

但是，许多用户可能会发现允许修改启动脚本和配置文件或部署新的 Web 应用程序是必要或方便的。无论您使用何种配置，只要确保您了解相关风险即可。

保护您的 Web 应用程序

安全性差的 Web 应用程序是 Apache Tomcat 的最大安全风险。无论您对 Web 应用程序进行多少限制，将其放置在沙箱中，限制其对资源的访问，或限制对特定用户的访问，任何重要的 Web 应用程序都极有可能访问某种形式的敏感数据，或者最少代表中断/拒绝服务攻击的有吸引力的目标。

在本节中，我们将讨论影响 Web 应用程序的一些常见安全风险，以及您可以采取的一些措施来使您的 Web 应用程序尽可能安全。

HTTP 请求模型漏洞

对于大多数面向外部的 Web 应用程序来说，通过 HTTP 进行的一些通信是不可避免的，这使得它成为一种流行的攻击渠道。恶意 HTTP 请求可用于尝试各种攻击，包括：

• XSS - 跨站点脚本，或 XSS，是一种利用客户端安全漏洞将恶意脚本注入应用程序的攻击，然后用于提升权限、窃取会话 cookie、抓取页面内容等。
• CSRF - 跨站点请求伪造，或 CSRF，是一种类似于 XSS 的攻击。但是，这些攻击不是依靠用户对网站的信任来获得访问权限，而是利用两个网站在交换信息时使用的信任机制将代码注入特权页面。
• SQL 注入 - 此攻击利用无法正确过滤用户生成的 SQL 语句以查找字符串文字转义字符或未“强输入”用户输入的应用程序。转义字符（例如引号或运算符）在过滤不当时可用于更改特定查询的功能，以强制披露隐藏信息或错误地验证用户。非“强类型”的字段（即，请求数字变量但不验证用户输入是否为数字的字段）可以以类似的方式被利用。
• 请求标头漏洞利用——如果应用程序在其标头编写代码中包含错误，攻击者通常可以通过发送格式错误的请求来强制披露有关服务器版本、端口地址等信息。
• 请求 URI 漏洞利用 - 这些攻击试图使使用 URI 存储某些重要会话数据的应用程序通过恶意制作的请求暴露安全数据

防止攻击

您可以采取一些步骤来保护您的 Web 应用程序免受上述攻击。

测试漏洞

除了手动调查已知漏洞外，还有许多备受推崇的扫描工具可用于测试 Web 应用程序漏洞。  

其中包括 IBM Rational AppScan、HP WebInspect 和 Acunetix Web Vulnerability Scanner等商业产品，以及Ratproxy等开源工具 。

测试应遵循类似于以下描述的格式：

	
	Scan

	Research / Repair Found Vulnerabilities

	Repeat scan

强化您的 Web 应用程序配置

一个安全的 Web 应用程序应该具有尽可能多的以下特征：

	
	Enforced HTTPS

	No Caching Of Secure Data

	No Small Key Length Ciphers

	CSRF and XSS Attack Filtering

强制 HTTPS

对 Tomcat 中的所有事务强制使用 HTTPS 是一个多步骤过程。必须配置 HTTPS 连接器，HTTP 连接器必须重定向到 HTTPS，并且 Web 应用程序的部署描述符必须将 HTTPS 指定为默认协议。

有关创建密钥库和配置 HTTPS/SSL 的详细分步信息，请访问我们的 Tomcat SSL 配置简单指南。

如需快速参考，请参阅下面的常见 HTTPS 配置：

	
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"


               maxThreads="450" scheme="https" secure="true"


               clientAuth="false" sslProtocol="TLS”       


               keystoreFile="conf/keystore" keystorePass="yourpass"


               proxyHost="10.1.1.1" proxyPort="443"


               URIEncoding="UTF-8"

               maxHttpHeaderSize="32768"/>

接下来，为确保您的 Web 应用程序始终使用 HTTPS，请通过使用“redirectPort”属性指定与您在上一步中配置的相同端口来配置您的 HTTP 连接器以将所有流量重定向到 HTTPS 连接器。请参见下面的示例：

<连接器端口="8080" 协议="HTTP/1.1" 

	

               connectionTimeout="20000" 


               redirectPort="443"


               proxyHost="10.1.1.1" proxyPort="80"


               URIEncoding="UTF-8"


               maxHttpHeaderSize="32768"/>

最后，在 Web 应用程序的部署描述符 (appName/WEB-INF/web.xml) 中配置适当的传输保证。示例配置如下所示：

	
<security-constraint>


 <web-resource-collection>


  <web-resource-name>SecureConnection</web-resource-name>


<!-- set all URL patterns within the context to trigger a secure connection -->


  <url-pattern>/*</url-pattern


 </web-resource-collection>


<!-- force HTTPS for the application -->


 <user-data-constraint>


  <transport-guarantee>CONFIDENTIAL</transport-guarantee>


 </user-data-constraint>


</security constraint


<--! allow Favicons -->


 <security-constraint>


  <web-resource-collection>


   <web-resource-name>NonSecureConnectionOK</web-resource-name>


   <url-pattern>*.ico</url-pattern>


 </web-resource-collection>


  <user-data-constraint>


   <transport-guarantee>NONE</transport-guarantee>


  </user-data-constraint>


 </security-constraint>

最后，使用 Connector 元素的“ciphers”属性指定用于加密数据的“强”加密系统（具有公用的单独套件）：

<连接器密码="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,...">

有关各种密码套件的优势和功能的更多信息，请访问 Java 6 文档。

禁用缓存安全数据

一个经常被忽视的 Web 应用程序漏洞是允许代理服务器缓存安全页面。虽然缓存可以加快页面的加载速度，但允许代理服务器缓存安全数据会带来不可接受的风险。

在您的应用程序代码中根据需要使用以下设置，以确保禁用安全页面的代理缓存：

	
/ Standard HTTP 1.1 no-cache header


httpResponse.setHeader("Cache-Control", "no-cache,must-revalidate");


/ Set IE extended HTTP 1.1 no-cache header


httpResponse.addHeader("Cache-Control", "post-check=0,pre-check=0");


/ Tell proxy caches not to cache a given resource


httpResponse.addHeader("Cache-Control", "proxy-revalidate");


/ Standard HTTP 1.0 cache disabling header


httpResponse.setHeader("Pragma", "no-cache");


/ Standard HTTP 1.0 cache disabling header, prevents caching at the proxy server 

httpResponse.setDateHeader("Expires", 0);

权限

如果可能，任何开发人员都应该尝试遵循其他一些 Web 应用程序安全提示；这些以安全权限配置为中心。  

首先，避免将文件写入 Web 应用程序的树 - 这需要授予对应用程序本身的访问权限，并且应该避免。接下来，将系统上您授予访问权限的区域数量缩小到尽可能少的数量。  

理想情况下，任何组件都应该具有读写访问权限的系统区域只有 conf/Catalia、conf/Catalina/localhost、work/、temp/ 和 log/ 目录，以及 webapps/ 目录（不是 web应用程序本身）。

实施最佳实践

作为世界上使用最广泛的 Java 应用服务器，Apache Tomcat 是唯一一个互联网安全中心发布了基准测试的 Web 服务器。CIS Tomcat 安全基准包括一长串其他最佳实践，一旦您完成了对系统的基本尽职调查，您应该考虑实施。  

要下载 Tomcat 基准测试或 Internet 安全中心的任何其他基准测试， 请单击此处。