对于tomcat8安全加固感兴趣的读者，本文将会是一篇不错的选择，我们将详细介绍tomcat安全加固选项，并为您提供关于APP安全加固怎么做？加固技术、加固方法、加固方案、ApacheTomcat7.
对于tomcat8 安全加固感兴趣的读者，本文将会是一篇不错的选择，我们将详细介绍tomcat安全加固选项，并为您提供关于 APP 安全加固怎么做？加固技术、加固方法、加固方案、Apache Tomcat 7.x安全加固指南、Apache Tomcat 8.0.9 发布，Tomcat8 首个稳定版本、Centos7+Tomcat8 配置 javaweb 环境，tomcat 启动巨慢的问题的有用信息。
本文目录一览：- tomcat8 安全加固（tomcat安全加固选项）
- APP 安全加固怎么做？加固技术、加固方法、加固方案
- Apache Tomcat 7.x安全加固指南
- Apache Tomcat 8.0.9 发布，Tomcat8 首个稳定版本
- Centos7+Tomcat8 配置 javaweb 环境，tomcat 启动巨慢的问题
tomcat8 安全加固（tomcat安全加固选项）
APP 安全加固怎么做？加固技术、加固方法、加固方案
前面的文章中我们为大家介绍了移动应用安全检测的测试依据、测试方法、和测试内容，本文我们着重分享 App 安全加固的相关内容。
（安全检测内容）
通过前面的文章我们知道了 app 安全检测要去检测哪些内容，发现问题后我们如何去修复？如何避免安全问题？首先我们先来讲一下 Android 安全加固技术。
源码加固
Java 源码加固 - dex 文件加壳保护、dex 函数抽取加密；
SO 库加固 - SO 文件加壳保护、高级深度混淆、ELF 数据隐藏；
Html 加固；
资源文件加固 - 音视频加密、配置文件和数据库加密；
运行环境加固
完整性保护 - 签名、防二次打包；
防调试保护 - 双向 ptrace 保护、反 IDAPro 调试；
防篡改保护 - 防数据破解分析、防数据劫持；
反编译保护 - 反 apktool、反 ApkIDE、反 jd-gui；
模拟器识别；
ROOT 检测；
业务场景加固
密钥保护；
安全键盘；
防界面劫持；
反外挂；
清场；
通信协议加密；
iOS 加固技术
高级混淆
字符串加密
指令多样化
基本块分裂
控制流引入
跳转指令插入
控制流扁平化控制流间接化
安全防护 SDK
越狱检测
重签名检测
Cydia Substrate 框架检测
逆向工具检测
代码注入框架检测调试器检测
安全键盘 SDK
键盘字符混排
输入无回显
通过分析 Android 和 ios 两大主流平台的加固技术，这里给大家推荐了一个 App 整体的安全加固方案。通过静态层面、动态层面以及数据层面，多个层面全方位立体式地去进行加固防护。
静态层面，有防逆向，如 DEX 文件的保护、SO 文件的保护、SDK 的保护以及 JS、H5、HTML 等文件的保护，利用一些加固技术去做防逆向的保护。静态层面还有签名保护，主要是防篡改，一个是代码防篡改，一个是资源文件防篡改。将防篡改技术加入进来，嵌入之后，就能实现静态层面的防篡改。
动态层面主要是防调试，一般是通过动态调试来查看你这个平台的逻辑是什么样的，要有防动态调试的技术。还要放进程调试、防内存 DUMP、防模拟器、防 HOCK 攻击等。
数据层面要有数据的防泄漏，像针对内存数据的保护，内存中的数据有没有加密？使用完后有没有及时释放？日志数据，有没有存储一些关键的数据？有没有存储一些敏感数据？以及在数据传输的过程中的一些加固技术要加入进来。
针对页面数据的保护，有应用防截屏、应用防劫持、安全键盘等。
App 的加固是保障 App 安全的一个方法。
介绍一个 c/c++ 代码混淆工具，Ipa Guard 是一款功能强大的 ipa 混淆工具，不需要 ios app 源码，直接对 ipa 文件进行混淆加密。可对 IOS ipa 文件的代码，代码库，资源文件等进行混淆保护。 可以根据设置对函数名、变量名、类名等关键代码进行重命名和混淆处理，降低代码的可读性，增加 ipa 破解反编译难度。可以对图片，资源，配置等进行修改名称，修改 md5。只要是 ipa 都可以，不限制 OC，Swift，Flutter，React Native，H5 类 app。。LLVM 不仅仅提供混淆实现，通过多重 Optimize (优化器)，实现多种效果，例如代码控制流扁平化、虚假控制流、字符串加密、符号混淆、指令替换等。
从需求阶段一直到交付阶段都要进行一些任务明确。比如说需求阶段我们要明确移动安全需求，针对安全需求进行评审，针对安全需求，安全开发也可以在这个阶段进行一些咨询、了解、调查、培训。这是需求阶段可以提前做的一些事情。
在设计阶段，我们可以采用一些安全的 SDK，甚至一些安全模型，并对安全设计进行评审，对安全开发环境和安全编译环境进行统一，用一些正规的编译环境和编译器。
在实现阶段，主要是进行安全编码的培训。编码完成，功能出来之后还要进行一些移动安全的检测，包括移动安全方面的漏扫检测以及移动 App 的渗透测试，手动去查找一些主流的安全问题，模拟黑客攻击的一些方法，一些手段，提前发现一些安全问题，对暴露的安全问题进行及时的整改。
在这个阶段还可以做一些代码测试，我们可以去找一些代码审查的一些工具去做一些相关的检测，针对发现的问题进行加固。（Fortify SCA 静态代码扫描工具，自 2009 年被 Gartner 魔力象限评为第一象限，连续十余年在安全测试领域占据领导地位，扫描文章底部二维码，可申请试用）
最后是交付阶段，要做好渠道监测，比如说你的 App 发布到哪个应用市场，就要去监测下在 App 市场我的 App 有没有被破解掉。有没有被其他人恶意发布？或者被更改掉以后又重新打包发布？再就是威胁感知，这个可以借助一些威胁感知平台。再就是安全响应，针对可能出现的一些安全事件，提前做好应急计划。
Apache Tomcat 7.x安全加固指南
《Apache Tomcat 7.x安全加固指南》要点：
本文介绍了Apache Tomcat 7.x安全加固指南，希望对您有用。如果有疑问，可以联系我们。
版本：1.00
日期：2014-1-11
分类：公开
1 引言
由于官方尚未发布Tomcat 7的强化指南,ERNW便总结了相关的设置,并制作出本文中列出的清单.尽管有大量的设置可以被应用,但本文旨在提供一些加固办法的基础.可能对操作系统功能造成严重影响的并且需要进行进一步大量测试的设置并未列在该清单中,或者被标记为可选.
我们用“强制”或“可选”标记了此清单中的每个保举设置,用以清楚的表达从我们的角度来看哪个设置是必须的(强制)或者是应该的(可选).“可选”也意味着我们保举你应用此设置,但这可能会影响系统的必需功能.
2 操作与系统平安
2.1 补丁与漏洞管理
强制：
必须及时安装与平安相关的Tomcat更新：
¬ 必需在10天内安装高危或重要优先级的更新和补丁.
¬ 必需在发布后30天内安装中等优先级的更新和补丁.
¬ 必需在发布后90天内安装低优先级更新.
有关补丁的可用性和严重性的信息,请参见http://tomcat.apache.org/lists.html#tomcat-announce.
更新可能会影响功效.关于核心/业务方面的Tomcat的更新可能带来的副作用,请查看http://tomcat.apache.org/lists.html#tomcat-announce.
2.2 Tomcat服务的最小权限
强制：
在系统上以低权限运行Tomcat应用程序.创建一个专门的 Tomcat服务用户,该用户只能拥有一组最小权限(例如不允许远程登录).必需检查以最小特权用户身份使用操作系统资源库安装程序的行为,以确保Tomcat不以root /管理员身份运行.必需在配置启动机制的操作系统层级上确保这一点(例如Microsoft Windows上的Windows服务或Unix上的rc脚本)：
图一：Windows服务配置
关于平安的服务配置,请参考ERNW Windows加固指南
图二：FreeBSD rc剧本
具体配置与Unix系统和Tomcat版本有关.例如FreeBSD上的Tomcat 7已经不支持配置rc.conf中的用户帐户,因此用户名被硬编码在启动脚本中—这是不保举的.在FreeBSD上,web和应用服务器应该是以www用户身份运行,可参考http://www.freebsd.org/doc/en/books/porters-handbook/using-PHP.html#WEB-APPS.
以低权限用户身份运行Tomcat可能会影响Tomcat的某些功能.例如,特权端口不可被设置为监听端口.为了办理该问题,可以在系统上使用本地HTTP代理(例如使用Apache的mod_jk模块)或者定义包转发规则,使得进入流量被转发到Tomcat监听的非特权端口.
2.3 限制拜访Tomcat文件夹
可选：
Tomcat文件夹只能由tomcat用户本身拜访,尤其是对于目录${tomcat_home}/conf /和${tomcat_home}/webapps.
当不必要通过应用程序服务器自动部署时,标准配置就是将所有Tomcat文件的所有者设置为root,并且所属群组设置为Tomcat.然后用chmod 740仅允许root用户编辑文件并允许Tomcat用户读取文件.例外是,临时和工作目录的所有者应该是Tomcat用户而不是root用户.
该设置会影响自动部署.(参见第8.5小节)
3 治理界面
可选
Tomcat的主要管理界面被称为Manager应用程序.尽管保护该应用程序对于Tomcat服务器的平安至关重要,但是该应用程序在许多环境中被发现是非常的暴露的(例如,没有部署网络级限制以及使用弱/默认登录信息).如果可能的话,管理性质的任务应该是在操作系统级别执行(例如使用RDP或SSH),并且避免使用Manager应用程序(另见第8.3小节).如果无法做到,下面小节描述的设置(或许还要考虑跳板机)应该与平安认证机制(另请参见第4小节)和加密传输(参见第6.3小节)结合使用.
3.1 网络层限制
如果要使用Manager应用程序,应该只允许从授权的IP地址拜访其管理界面.
这可以通过在CATALINA_HOME/webapps/manager/meta-inf/context.xml文件中的做以下设置来实现.以下设置只允许从本地主机和特定IP地址或IP地址段拜访管理界面：
allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|172\.16\.16\.\d{1,3}
"/>
也可使用主机名：
className="org.apache.catalina.valves.RemoteHostValve"
allow=".*\.admins\.domain\.com" />
allow和deny都支持正则表达式(使用java.util.regex)
3.2 最小原则授权
强制：
根据给定的任务,只能赋予相应角色的权限给用户.角色如下,而且要记得只赋予最小权限：
¬
manager-gui：可以拜访web界面
¬
manager-status：只可以拜访“Server Status”页面
¬
manager-script: 可以剧本文本界面和“Server Status”页面
¬
manager-jmx：可以拜访JMX代理界面和“Server
Status”页面
4 认证
以下设置一般适用于基于Tomcat的身份验证.但是在大多数环境中,主要是针对Manager应用法式,因此以它来做例子.如果部署的应用法式使用基于Tomcat的认证,那么该应用法式也适用这些设置.
4.1 平安认证
可选：
如果要使用Manager应用法式,则还应该附加额外的身份认证机制.认证机制优先级如下：
1 LDAPS或客户端证书
2 当地(基于消息摘要)
另外,认证过程和与Manager应用程序的通信必须使用SSL来掩护(见下文).
强制：
对于当地和基于证书的身份验证,必须部署账户锁定机制(对于集中式认证,目录服务也要做相应配置).为防止暴力破解,使用的认证域必须放在做了如下配置的锁定域中：
编纂CATALINA_HOME/conf/server.xml文件,并添加配置如下的锁定域：
className="org.apache.catalina.realm.LockOutRealm"
failureCount="5"
lockOutTime="30">
AUTHENTICATION REALM -->
4.2 禁用域
强制：
有几个域不适合用作生产用途,这些域必需被禁用.
打开文件CATALINA_HOME/conf/server.xml,搜索MemoryRealm并禁用之.JDBCRealm也必需被禁用,改用DataSourceRealm.使用大规模安装时,请勿使用UserDatabaseRealm并也将其禁用.
5 会话处置
5.1 会话超时
强制 ：
所有的web应用程序的会话超时必需设置为20分钟.
可通过编纂CATALINA_HOME/conf/web.xml文件并做以下配置来实现：
20
5.2 HttpOnly标志
强制：
Tomcat 7对会话cookie自动启用HttpOnly
cookie标志,查看配置以确保该选项为被禁用.
要启用HttpOnly,必需在CATALINA_BASE/conf/context.xml中做如下设置,使之全局应用于所有应用程序：
useHttpOnly='true' .../>
在需要通过JavaScript拜访会话cookie的情况下,使用HttpOnly可能会影响应用程序功能.如果应用程序需要通过JavaScript拜访HttpOnly cookie,可以在MetaINF/context.xml中一个单独的Context中定义一个异常.
5.3 CSRF防护
强制：
为保护应用程序,必须启用Tomcat的跨站哀求伪造防护.Tomcat 7提供了基本的CSRF防护.可以在CATALINA_BASE/conf/web.xml中配置一个全局过滤器.该过滤器可以被每个使用WEB-INF/web.xml文件的应用程序覆盖.
必需做以下设置：
CSRFPreventionFilter
/*
有关详细阐明和其他选项,请参阅Tomcat手册：http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CSRF_Prevention_Filter.
使用CSRF防护可能会影响程序功能,必须要牢记这一点,尤其是在应用程序大量使用异步哀求的情况下.
6 网络平安
6.1 限制监听网络接口
强制：
不要让连接器(connector)监听服务器上所有可用的网络接口和IP地址,而要让连接器监听指定的网络接口和IP地址.
编纂CATALINA_HOME/conf/server.xml,查看每个Connector并指定正确的IP地址：
address="LISTEN_IP_ADDRESS"…
这样可以防止应用程序不测地运行在某个开放的网络接口上.
6.2 限制允许的网络连接
强制：
只开放必需要的Tomcat端口.默认TCP端口是8080和8443.确保在Tomcat和可安装在系统上的现有的包过滤器中正确配置这些端口.
打开CATALINA_HOME/conf/server.xml文件,查看每个Connector的端口配置.移除不必要的端和Connector.
6.3 加密网络连接
强制：
为了保护敏感的应用程序(比如Manager应用程序),必须使用并配置SSL(对于处理敏感数据或提供登录功能的应用程序也是必需的).第一步是创建可信的证书,以避免证书警告,并向终端用户提供一种验证可信连接的办法.
第二步是创建一个证书密钥库(keystore),其中包含CA、服务器证书和相应的私钥.密钥库的密码应按照之前的“保障密码平安”小节中建议来创建.
要启用SSL支持,可以使用以下配置(实际配置取决于给定的平台和要求),并且必需放在CATALINA_HOME/conf/server.xml中：
protocol="org.apache.coyote.http11.Http11Protocol"
port="8443" scheme="https" secure="true"
SSLEnabled="true" sslProtocol="TLS"
keystoreFile="path to keystore file" keystorePass="keystore
password"/>
通过添加以下暗码套件(cipher suite)至SSL Connector来指定可用的SSL加密方式：
ciphers="SSL_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA" …
为了使托管在Tomcat上的所有web应用程序强制使用HTTPS,必须在每个CATALINA_HOME/webapps/$WEBAPP/WEB-INF/web.xml文件里每个security-constraint标签关闭(标签)之前包括以下内容：
CONFIDENTIAL
7 Java Runtime
7.1 Java SecurityManager
可选：
可用Java SecurityManager限制单个应用程序的功能.$CATALINA_HOME/conf/catalina.policy文件包含了Java SecurityManager使用的平安策略的配置.一旦配置了catalina.policy文件,便可以使用SecurityManager和--security选项启动Tomcat.想了解全面的配置介绍,请参阅官方的Tomcat SecurityManager教程：http://tomcat.apache.org/tomcat-7.0-doc/security-manager-howto.html
因为基本上所有的权限类型(比如拜访单个文件和目录或Java包)都应该根据每个应用程序进行单独配置,所以这会大大增加操作成本.另外,限制过于严格的策略文件会影响应用程序的功能.
7.2 拜访Java包
可选：
Tomcat可限制对某些Java包的访问.如果检测到受限制的包被访问,将抛出平安异常.
对Java包做拜访限制,打开$CATALINA_BASE/conf/catalina.properties文件并添加不允许拜访的包至package.access列表.
分析Java import可以列出哪些应用程序必要哪些包.在Unix系统上,可以使用以下例子来实现：
grep –R import ${tomcat_home}/webapps/WEBAPP
8 通用设置
8.1 确保默认设置的平安
强制：
检查几个默认值以防出现潜在的漏洞.参考第9小节列出的不能变动的默认配置.
8.2 确保关闭(shutdown)端口的平安
强制 ：
如果必须要开启使用本地Tomcat系统上的网络端口关闭Tomcat的功能,必须使用难以被猜解出的强暗码.
编辑CATALINA_HOME/conf/server.xml文件并设置关闭暗码：
shutdown="NonDeterministicWordSoShutdownPWisNotEasyToGuess">
如果不需要该功能,必需要将其停用,设置如下：
port="-1" shutdown="SHUTDOWN">
当地管理脚本可将服务器关闭,即使在关闭端口被禁用的情况下.
8.3 移除默认应用法式
强制 ：
Tomcat可能自带一些默认的web应用程序.如果不是必定需要,必须将它们移除.
移除${tomcat_home}/webapps中所有的默认的web应用程序.必需要移除的应用程序有：ROOT、Documentation、Examples、Host Manager和Manager.
Manager应用程序提供管理性质的功能,比如部署应用程序和检索日志信息.这些功能应该使用本地服务器上的命令行来运行.但是,如果这个应用程序是绝对需要的,那它必须用SSL掩护起来.
8.4 自定义差错页面
可选 ：
由于默认的错误页面会泄露一些内部信息(比如版本号和堆栈轨迹),所以应该用包含一般错误信息(比如处理您的哀求时出错了)的自定义错误页面取而代之.
每个web应用程序的web.xml文件里应包括以下配置,该文件位于CATALINA_HOME/webapps/$WEB_APP/WEB-INF：
500
/errorpages/error.html
java.lang.Throwable
/errorpages/error.html
此外,如果Manager应用程序没被移除,必需手动将位于CATALINA_HOME/webapps/manager/WEB-INF/jsp/的错误页面里的“Tomcat 7“版本信息移除.
8.5 禁用自动部署
强制：
Tomcat允许在Tomcat运行时自动部署应用程序.这个功能必需被禁用,因为它可能允许部署恶意或未经测试的应用程序.
自动部署由autoDeploy和deployOnStartup属性控制.如果两者是false,只有在server.xml中定义的Context将被部署,并且任何更改都必要重启Tomcat.要禁用自动部署,请在$CATALINA_HOME/conf/server.xml文件中做以下配置：
autoDeploy=”false”
deployOnStartup=”false”
在托管环境中Web应用法式可能不受信任,也可以设置deployXML属性为false来忽略context.xml,以防给该web应用法式提高权限.
9 附录：默认设置
以下列出了不能更改的默认设置,默认情况下这些设置被认为是平安的：
server.xml中每个Connector的allowTrace的值要么为空或要么被设为false.
在所有的context.xml文件中,将privileged属性设置为false,除非像Manager应用程序那样必要权限：
¬
确保crossContext值为空或被设为false.crossContext值为true可能会导致允许恶意应用程序向受限应用程序发送哀求.
¬
确保allowLinking值为空或被设为false.allowLinking值为true可能会导致目录遍历和源代码泄露漏洞的发生.
¬
制止对默认的servlet的写入.
¬ 在web.xml文件中设置DefaultServlet的read-only为true.如果该值是false,将会允许客户端删除或修改服务器上的静态资源并上传新的资源.一般在没有认证的情况下不该该修改该值.
禁用显示列表
¬ 设置DefaultServlet的listings为false.这不仅仅是因为允许显示目录列表被认为是不平安的,而且还因为生成具有数千个文件的目录列表会消耗大量的cpu资源,相当于被DDoS攻击.
当RECYCLE_FACADES选项设置为true时,Tomcat会回收哀求间会话外观(session facade).这将导致哀求间的信息泄漏.默认情况下,此参数未被设置.确保使用的启动脚本不包含以下内容：
¬ -Dorg.apache.catalina.connector.RECYCLE_FACADES = false
允许在Tomcat上指定不同的路径分隔符,可能会允许攻击者拜访应用程序,该行为本该被代理程序(比如mod_proxy)阻止.默认情况下,此参数未被设置.
¬ 确保正在使用的启动脚本不包括以下内容：
¬ -Dorg.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH = FALSE
¬ -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH = FALSE
允许指定自定义header状态消息,使攻击者也能够插入header.这可能会导致XSS漏洞的发生.默认情况下,此参数未被设置.
¬ 确保使用的启动脚本不包括以下内容：
¬ -Dorg.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER = false
¬ -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH
= FALSE
允许自定义header状态消息,使攻击者也能够插header.这可能会导致XSS漏洞的发生.默认情况下,此参数未被设置.
¬ 确保使用的启动脚本不包括以下内容：
¬
-Dorg.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER = false
本文由看雪翻译小组 SpearMint 编译,起源payatu@Rashid Feroze 转载请注明来自看雪社区
欢迎参与《Apache Tomcat 7.x安全加固指南》讨论，分享您的想法，小编PHP学院为您提供专业教程。
Apache Tomcat 8.0.9 发布，Tomcat8 首个稳定版本
Apache Tomcat 发布 8.0.9 版本，同时这个版本也是 8.0 的第一个 stable 版本。Tomcat 8 需要至少 JDK7 以上。
值得注意的更新如下：
Support for Java Servlet 3.1, JavaServer Pages 2.3, Java Unified Expression Language 3.0 and Java WebSocket 1.0.
The default connector implementation is now the Java non-blocking implementation (NIO) for both HTTP and AJP.
A new resources implementation that replaces Aliases, VirtualLoader, VirtualDirContext, JAR resources and external repositories with a single, consistent approach for configuring additional web application resources. The new resources implementation can also be used to implement overlays (using a master WAR as the basis for multiple web applications that each have their own customizations).
Apache Tomcat 8.0.9 包括了 8.0.8 版本的 bug 修复和大量改进，相对于 8.0.8 版本：
Start to move towards RFC6265 for cookie handling
Better error handling when the error occurs after the response has been committed
Various Jasper improvements to make it easier for other containers (e.g. Jetty) to consume
完全改进：http://tomcat.apache.org/tomcat-8.0-doc/changelog.html
下载：http://apache.org/dist/tomcat/tomcat-8/v8.0.9/
Centos7+Tomcat8 配置 javaweb 环境，tomcat 启动巨慢的问题
去年刚开始遇到这样的问题很郁闷，总以为是服务器的问题，网上的也不好找到很好的答案，花了不少时间，现在感觉这样的问题多了网上的答案也随之很多
启动巨慢问题分析:
启动慢主要是卡在初始化 Session, 通过搜索和分析，Tomcat 的 SessionID 是通过 SHA1PRNG 算法计算得到的，SHA1 算法需要一个密钥，这个密钥在 Tomcat 启动的时候随机生成一个，生成是使用了 Linux 随机函数生成器 /dev/random。读取它相当于生成随机数字。搜索 /dev/random，大概知道是什么鬼了：/dev/random 会根据 噪音 产生随机数，如果噪音不够它就会阻塞。Linux 是通过 I/O，键盘终端、内存使用量、CPU 利用率等方式来收集噪音的，如果噪音不够生成随机数的时候就会被阻塞。
解决方案 A 和 B
A. 使用伪随机函数生成器 /dev/unrandom /dev/urandom 并不是真正的随机行为 (其实一般不容易重复)，主要有两个地方可以修改。
- 通过修改 Tomcat 启动文件 -Djava.security.egd=file:/dev/urandom
- 通过修改 JRE 中的 java.security 文件 securerandom.source=file:/dev/urandom
B. 增大 /dev/random 的熵池（推荐） 问题的原因是由于熵池不够大，所以增大它是最彻底的方法。我们可以通过软件的方法实现，下面是软件的安装和配置流程。
- 安装熵服务
yum install rng-tools - 启动熵服务
systemctl start rngd - 如果你的 CPU 不支持 DRNG 特性或者像我一样使用虚拟机，可以使用 /dev/unrandom 来模拟。
cp /usr/lib/systemd/system/rngd.service/etc/systemd/system vim /etc/systemd/system/rngd.service # 以下是编辑内容 ExecStart=/sbin/rngd -f -r /dev/urandom - 重新载入服务
systemctl daemon-reload systemctl restart rngd
经过上面的修改，我们再观察 /proc/sys/kernel/random/entropy_avail 基本上在 3000 左右。这个时候重新启动 Tomcat，发现启动时间正常。
这两种方案 A 自己没有试过，也是网上看的，我一般用的是 B 方案，安装熵服务和启动熵服务这两步操作就可以了，最好是在 linux 的根目录下操作
我们今天的关于tomcat8 安全加固和tomcat安全加固选项的分享已经告一段落，感谢您的关注，如果您想了解更多关于 APP 安全加固怎么做？加固技术、加固方法、加固方案、Apache Tomcat 7.x安全加固指南、Apache Tomcat 8.0.9 发布，Tomcat8 首个稳定版本、Centos7+Tomcat8 配置 javaweb 环境，tomcat 启动巨慢的问题的相关信息，请在本站查询。
本文标签：
