如何设定执行Java的Linux安全环境

C# 怎么样？
与 Java 执行时环境有许多共同点的一个替代方法是 Microsoft 的 C# 语言和相关的公共语言执行时（Common Language Runtime，CLR）。C# 是 Java 语言的关系紧密的衍生物，CLR 可能容许 C# 在许多平台上使用。CLR 还提供了 JVM 的许多执行时安全特性（尽管有严重削弱安全保证的逃离出口）。Microsoft .Net 实作还支持预编译成本机程序代码的选项以获得更快速启动，这与 GCJ 对 Java 字节码所做的工作相同。当然，Linux 使用者并不能直接使用这项功能，因为 .Net 只适用于 Windows 系统。
Mono Project 正致力于为多种 Linux 产品建置「CLean Room」开放来源码 C# 和等价于 CLR 的产品。现在，该项目中的 C# 编译器已开发完成，而且还完成了大部分的 CLR，Microsoft 已发布将它用于标准化。但是，无论从效能还是功能角度来看，在它成为合理的 Java 平台替代选择之前还有许多工作要做。CLR 只包括了与 Java 核心类别库等价的基本内容。在可以将它看作是企业软件开发的合理选项之前，还需要用许多额外 API 来补充它。
Mono Project 正在致力于开发 CLR 以外的 .Net 其它部分的移植，如果这些移植成功了 ─ 并且如果 Microsoft 不对 .Net 的这些部分强加它的专利权 ─ 那么它们会有助于满足 C# 成为 Linux 上服务器软件开发的可靠平台的需要。但要使那些假设成为现实，还需要做很多工作，同时，Java 程序的本机程序代码编译器和开放来源码 JVM 向那些确实想要避免使用特许 JVM 并可以忍受有限功能性的使用者提供了比较稳定的替代选择。
Apache Tomcat
最普遍存在的 Java 平台服务器应用程序之一是 Apache Tomcat.Tomcat 是基于最初由 Sun 捐赠的来源码的开放来源码项目。它是一个 HTTP 服务器，是 Sun 透过 Java Community Process 开发的、对广泛使用的 servlet 和 JavaServer Page（JSP）技术的正式参考实作。我将在本文中使用 Tomcat 作为样本 Java 应用程序，将其部署成 Linux 上的一个服务。如果您想要尝试自己执行 Tomcat，那么您将需要在系统上安装 Java 开发工具箱（Java Development Kit，JDK），而不是安装更小的 Java 执行时环境（Java Runtime Environment，JRE）。
servlet 和 JSP 技术用于建构 HTTP 服务器应用程序。虽然 servlet 技术中加入了许多特性（包括存取安全性、Session管理和执行绪控制），但它本身祇是粗略地等价于为快速直接的 Java 语言呼叫而定制的 CGI 接口。JSP 技术提供了一种处理动态生成的 HTML 页面的简便方法，这些 HTML 页面被直接编译成 servlet 以用于快速执行时作业。
在这两种技术之外，Tomcat 还提供了其它许多特性。凭它本身的效能，它实际上是全功能 Web 服务器，但它通常在 Linux 系统上与 Apache Web 服务器前端共同使用。Apache 向 Tomcat 提供了许多进阶效能以适合静态内容。对于静态内容所占比例比较高且使用率很高的 Web 应用程序，Apache 前端非常有用。但对于许多简单的 Web 应用程序，就没必要使用它了，当更易于组态和管理时，单独执行 Tomcat 就可提供足够的效能（至少对于以前没有使用过 Apache 的工作人员来说是这样）。
连接埠难题
单独执行 Tomcat 的一个大问题是它无法存取标准 HTTP 连接埠 80，除非是作为 root 使用者执行。作为 root 使用者执行服务器应用程序的想法通常并不是上串流公司所讨论的问题，因此我将完全放弃这个想法﹗使用除 80 以外的连接埠是一个更好的选择（例如，Tomcat 缺省连接埠 8080）。这通常适用于测试，但当使用者正在存取服务时，它会导致杂乱的 URL，因为需要在请求中清楚地说明连接埠号。使用非标准连接埠还意味着如果需要外部存取，就需要重新组态所有的防火墙。
xinetd 解决方案
幸好，Linux 支持一些利用 Tomcat（或任何其它使用者方式应用程序）处理连接端口 80 请求的简便方式。一种常用方式是透过 xinetd.xinetd 是带有广泛存取控制和日志记录支持的因特网服务守护程序，它还拥有方便的重新导向特性。重新导向让您将系统组态成接受一个连接埠上的进入请求，然后将请求传递到另一个连接埠或者甚至另一个 IP 地址进行处理。
如果您想要在系统上设定 Tomcat 以处理连接埠 80 请求，就需要加入 xinetd 组态文件来实作这一目的。假设按一般在正常路径上安装了 xinetd，那么您可以透过对 /etc/xinetd.d 目录加入一个文件（以 root 使用者身份）来执行这一作业。清单 1 提供了用于 Tomcat 的一个样本组态文件。
清单 1. xinetd 重新导向组态

# Redirects any requests on port 80 # to port 8080 （where Tomcat is listening） service tomcat { socket_type = stream protocol = tcp user = root wait = no port = 80 redirect = localhost 8080 disable = no }

在加入了组态文件之后，需要重新启动 xinetd 来真正活化重新导向。在大多数 Linux 安装上，透过以 root 使用者身份执行以下指令来重新启动 xinetd:

/sbin/service xinetd restart

祇要将组态文件放在 /etc/xinetd.d 目录中，当重新启动系统时，重新导向就会自动启动。如果没有将 Tomcat 设定成自动启动，那么在启动 Tomcat 之前，会拒绝进入请求。
iptables 解决方案
xinetd 是处理请求重新导向的一种好方法，但它执行了一个处理序以在连接端口之间实际转信数据，这确实增加了一些开销。最新的 Linux 内核版本透过使用 iptables 来支持一种更好的设定重新导向的方法。iptables 与 xinetd 的区别之处在于它是一个真正的内核组件。因此，它可以避免 xinetd 方法增加的开销。使用 iptables 的唯一缺点是它可能比 xinetd 更难以组态，而且它只可用于相当新的内核版本。
您需要执行支持 iptables 的 2.4.x 或更新的内核，以便使用我在这里描述的技术。组态和设定 iptables 是一个确信由几篇文章来单独描述的主题，所以我不打算在这里尝试讨论该主题。如果对 iptables 的入门需要帮助，请阅读 Linux 分发版的手册。要快速检查 iptables 是否在您的系统上执行，尝试以 root 使用者身份执行:

/sbin/service iptables status

如果它正在执行，您将会在控制台上看到表和链的清单。
iptables 使用几个不同的表和封包链来处理规则的。为了将进入 HTTP 请求从连接端口 80 重新导向到系统中的另一个连接埠，您将要使用 nat 表（表示网络地址转换，Network Address Translation）和 PREROUTING 链。清单 2 提供了要执行的实际指令（以 root 使用者身份），以便于加入一条处理这一请求的规则。这条规则的作用是将进入包的目标连接端口 80 修改成目标连接端口 8080，因此祇有在您没有阻止从外部使用连接埠 8080 时，这条规则才会正确工作。一旦执行了该指令，您就应该能够立即处理进入请求。
清单 2. iptables 重新导向规则

/sbin/iptables -t nat \ -A PREROUTING -j REDIRECT -p tcp \ ——destination-port 80：80 ——to-ports 8080 /sbin/service iptables save

以便于储存目前 iptables 组态。