Oracle数据库加固后Connection reset修复方案

ゝ一世哀愁。 2022-05-30 07:52 128阅读 0赞

半年前开始，项目组测试MM在验证功能时，经常报怨讲测试环境上的应用在启动时很慢，偶尔会报失败，遇到类似问题多数情况下重新启动一次就可以启动成功，但少数时候也有反复启动不成功的案例。当启动失败时，日志里有如下的异常，看起来似乎和网络有关。
    
    java.sql.SQLRecoverableException: I/O Exception: Connection reset
     
    at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:281)
     
    at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:118)
     
    at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:224)
     
    at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:296)
     
    at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:611)
     
    at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:455)
     
    at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:494)
     
    at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:199)
     
    at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:30)
     
    at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:503)
     
    at java.sql.DriverManager.getConnection(DriverManager.java:582)
     
    at java.sql.DriverManager.getConnection(DriverManager.java:154)
     
    
     
     
    应用使用的数据库是Oracle，版本为11g R1和R2，Oracle和应用都运行在Linux环境，JDBC驱动是从Oracle官网下载的ojdbc6.jar。
     
    由于这类问题出现的频率比较低，出现问题的数据库环境都被做过安全加固，加上我忙于其它事情，这个问题就被搁置起来，没有去认真定位，测试MM的怀疑都被我以环境原因的理由搪塞过去。
     
    最近两个月，应用在多个生产环境部署时也出现了类似的现象，在有些生产环境，上述问题还会导致双机切换不成功或者反复切换。做现场实施的同事对此抱怨很多，对我们的应用产生了怀疑。看来这个问题需要认真对待，并且一定要解决了。
     
     
     
    现象分析
     
    从测试MM和现场实施人员的描述看，这个问题有以下几个特征：
     
    1) 应用启动时很慢，这时有很大概率会失败；
     
    2) 应用包括很多组件，其中大部分组件在启动时都会尝试访问数据库加载一些数据，而其中一个组件在访问数据库时经常会报上述异常；
     
    3) 当启动失败时，检查Oracle实例对应的alert日志时，发现出现有TNS错误，样例如下：
     
    
    
    
    Fatal NI connect error 12170.
     
     
     
     
     
     
     
      VERSION INFORMATION:
     
     TNS for Linux: Version 11.2.0.1.0 - Production
     
     Oracle Bequeath NT Protocol Adapter for Linux: Version 11.2.0.1.0 - Production
     
     TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.1.0 - Production
     
      Time: 11-MAY-2014 22:23:40
     
      Tracing not turned on.
     
      Tns error struct:
     
        ns main err code: 12535
     
        
     
    TNS-12535: TNS:operation timed out
     
        ns secondary err code: 12560
     
        nt main err code: 505
     
        
     
    TNS-00505: Operation timed out
     
        nt secondary err code: 110
     
        nt OS err code: 0
     
    
    问题定位
     
    TNS错误
     
    由于实验室里的Oracle环境都做过安全加固，而问题现象里有发现过TNS错误，所以刚开始定位问题的思路出了点偏差，一直以为和安全加固操作有关，所以寻找的资料也和Oracle相关。
     
    根据网上的资料，在sqlnet.ora文件中定义SQLNET.INBOUND_CONNECT_TIMEOUT变量，经过尝试，设置为0或者一个比较大的值如30，都可以消除掉前述问题。根据资料介绍，这个变量用来控制客户端通过认证的时间间隔，假如认证时间超时，则本次数据库链接创建操作就会失败，而缩短超时时间，可以有效的阻止DoS类型的攻击。根据安全加固操作指导，加固操作确实包含用于修改认证超时时间的指令。
     
    问题定位到这里，应该说找到了规避手段，也了解引发问题的初因，但现场实施人员对于我的解释并不满意。好在我又找到一条新线索。
     
    新线索
     
    从Oracle官网论坛里找到一个帖子，讨论的问题和我遇到的问题类似，但提出的问题原因和解决方法比较有意思。按照帖子里的说法，问题的根因和Java的安全随机数生成器的实现原理相关。
     
    
    
    
    java.security.SecureRandom is a standard API provided by sun. Among various methods offered by this class void nextBytes(byte[]) is one. This method is used for generating random bytes. Oracle 11g JDBC drivers use this API to generate random number during
     
    login. Users using Linux have been encountering SQLException("Io exception: Connection
     
    reset").
     
     
     
    The problem is two fold
     
     
     
    1. The JVM tries to list all the files in the /tmp (or alternate tmp directory set by -Djava.io.tmpdir) when SecureRandom.nextBytes(byte[]) is invoked. If the number of files is large the method takes a long time to respond and hence cause the server to timeout
     
     
     
    2. The method void nextBytes(byte[]) uses /dev/random on Linux and on some machines which lack the random number generating hardware the operation slows down to the extent of bringing the whole login process to a halt. Ultimately the the user encounters SQLException("Io exception:
     
    Connection reset")
     
     
     
    Users upgrading to 11g can encounter this issue if the underlying OS is Linux which is running on a faulty hardware.
     
     
     
    Cause
     
    The cause of this has not yet been determined exactly. It could either be a problem in your hardware or the fact that for some reason the software cannot read from /dev/random
     
     
     
    Solution 
     
    Change the setup for your application, so you add the next parameter to the java command:
     
     
     
    -Djava.security.egd=file:/dev/../dev/urandom
     
    
    现场实施人员对于这个帖子里的信息比较感兴趣。按照帖子里的修改方法，在测试环境和生产环境做了多次验证，惊喜的发现问题得到了解决。
     
     
     
    随机数生成器
     
    如果不是为了解决问题，平时也不会去刻意查阅底层实现相关的原理，这次是个好机会。网上关于/dev/random的介绍很多，只列出要点：
     
    1) /dev/random是Linux内核提供的安全随机数生成设备；
     
    2) /dev/random依赖系统中断信息来生成随机数，因而设备数目比较少时，产生随机数的速度比较慢，当应用对随机数的需求比较大时会供不应求；
     
    3) /dev/random在读取时会阻塞调用线程；
     
    4) /dev/urandom是/dev/random的改良版本，解决了随机数生成慢、阻塞调用的问题，但同时稍微降低了安全性；
     
    5) Linux环境下man random命令可以查阅到/dev/random和/dev/urandom的介绍

##       JVM上的随机数与熵池策略 ##

bug(端口监听启动后，Tomcat耗时2min+ ):

2017-09-01 15:51:05.146  WARN 20923 --- [http-nio-80-exec-1] o.a.c.util.SessionIdGeneratorBase        : Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [141,273] milliseconds.
    2017-09-01 15:51:05.160  WARN 20923 --- [http-nio-80-exec-4] o.a.c.util.SessionIdGeneratorBase        : Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [67,573] milliseconds.
    2017-09-01 15:51:05.160  WARN 20923 --- [http-nio-80-exec-3] o.a.c.util.SessionIdGeneratorBase        : Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [72,205] milliseconds.
    2017-09-01 15:51:05.163  WARN 20923 --- [http-nio-80-exec-2] o.a.c.util.SessionIdGeneratorBase        : Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [132,321] milliseconds.
    2017-09-01 18:24:26.447  WARN 21241 --- [http-nio-80-exec-1] o.a.c.util.SessionIdGeneratorBase        : Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [166,806] milliseconds.
    2017-09-01 20:11:12.953  WARN 21508 --- [http-nio-80-exec-1] o.a.c.util.SessionIdGeneratorBase        : Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [173,287] milliseconds.
    2017-09-03 16:50:59.385  WARN 25289 --- [http-nio-80-exec-1] o.a.c.util.SessionIdGeneratorBase        : Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [154,563] milliseconds.

这个`SecureRandom`的初始化竟然花了100秒之多。。。

后来查了一下，发现这个问题抱怨的还是蛮多的，以至于tomcat的[wiki][]里面还单独列出来作为加速启动的一个方面：

*Tomcat 7+ heavily relies on SecureRandom class to provide random values for its session ids and in other places. Depending on your JRE it can cause delays during startup if entropy source that is used to initialize SecureRandom is short of entropy. You will see warning in the logs when this happens.*

*There is a way to configure JRE to use a non-blocking entropy source by setting the following system property: `-Djava.security.egd=file:/dev/./urandom`*

尝试使用`-Djava.security.egd=file:/dev/./urandom`启动了一下，果然快了很多。

不过tomcat的wiki中提到，如果使用这个非阻塞的`/dev/urandom`的话，会有一些安全方面的风险，这块我倒确实不太明白，不过好在有明白人，而且还写了一篇[长文][Link 1]来证明使用`/dev/urandom`是没问题的，所以就先用着吧：-）

另外：

有两种解决办法：

1.在Tomcat环境中解决  
  
可以通过配置JRE使用非阻塞的Entropy Source。  
  
在catalina.sh中加入这么一行：-Djava.security.egd=file:/dev/./urandom 即可。  
  
加入后再启动Tomcat，整个启动耗时下降到Server startup in 6213 ms，大大降低了启动的时间。

2.在JVM环境中解决

先执行which javac命令检查jdk安装路径

/usr/local/java/jdk1.8.0\_92/bin/javac  
  
去到$JAVA\_PATH/jre/lib/security/java.security这个文件，找到下面的内容：

securerandom.source=file:/dev/urandom

替换成

securerandom.source=file:/dev/./urandom

这样问题就解决了

在apache-tomcat官方文档：  
如何**让tomcat启动更快**里面提到了一些启动时的优化项，其中一项是关于随机数生成时，采用的“熵源”(entropy source)的策略。

他提到**tomcat7**的session id的生成主要通过`java.security.SecureRandom`生成随机数来实现，随机数算法使用的是”SHA1PRNG”

private String secureRandomAlgorithm = "SHA1PRNG";

在sun/oracle的jdk里，这个算法的提供者在底层依赖到操作系统提供的随机数据，在linux上，与之相关的是`/dev/random`和`/dev/urandom`，对于这两个设备块的描述以前也见过讨论随机数的文章，  
wiki中有比较详细的描述，摘抄过来，先看`/dev/random`：  
在读取时，/dev/random设备会返回小于熵池噪声总数的随机字节。  
/dev/random可生成高随机性的公钥或一次性密码本。  
若熵池空了，对/dev/random的读操作将会被阻塞，直到收集到了足够的环境噪声为止

而`/dev/urandom`则是一个非阻塞的发生器:

dev/random的一个副本是/dev/urandom （”unlocked”，非阻塞的随机数发生器），它会重复使用熵池中的数据以产生伪随机数据。  
这表示对/dev/urandom的读取操作不会产生阻塞，但其输出的熵可能小于/dev/random的。  
它可以作为生成较低强度密码的伪随机数生成器，不建议用于生成高强度长期密码。

https://bugs.openjdk.java.net/browse/JDK-6202721

另外wiki里也提到了为什么linux内核里的随机数生成器采用SHA1散列算法而非加密算法，是为了**避开法律风险**(密码出口限制)。

回到tomcat文档里的建议，采用非阻塞的熵源(entropy source)，通过java系统属性来设置：

-Djava.security.egd=file:/dev/./urandom

这个系统属性egd表示熵收集守护进程(entropy gathering daemon)，但这里值为何要在`dev`和`random`之间加一个点呢？是因为一个jdk的bug，在这个bug的连接里有人反馈及时对 securerandom.source 设置为`/dev/urandom`它也仍然使用的`/dev/random`，有人提供了变通的解决方法，其中一个变通的做法是对securerandom.source设置为`/dev/./urandom`才行。也有人评论说这个不是bug，是有意为之。

我看了一下我当前所用的jdk7的java.security文件里，配置里仍使用的是`/dev/urandom`：

## Select the source of seed data for SecureRandom. By default an# attempt is made to use the entropy gathering device specified by# the securerandom.source property. If an exception occurs when# accessing the URL then the traditional system/thread activity# algorithm is used.## On Solaris and Linux systems, if file:/dev/urandom is specified and it# exists, a special SecureRandom implementation is activated by default.# This "NativePRNG" reads random bytes directly from /dev/urandom.## On Windows systems, the URLs file:/dev/random and file:/dev/urandom# enables use of the Microsoft CryptoAPI seed functionality.#securerandom.source=file:/dev/urandom

我不确定jdk7里，这个`/dev/urandom`也同那个bug报告里所说的等同于`/dev/random`；要使用非阻塞的熵池，这里还是要修改为`/dev/./urandom`呢，还是jdk7已经修复了这个问题，就是同注释里的意思，只好验证一下。

使用bug报告里给出的代码：

import java.security.SecureRandom;
    
    public class JRand {
    
          public static void main(String args[]) throws Exception {
    System.out.println("Ok: " +SecureRandom.getInstance("SHA1PRNG").nextLong());
         }
    }

然后设置不同的系统属性来验证，先是在我的mac上：

% time java -Djava.security.egd=file:/dev/urandomJRandOk: 8609191756834777000java -Djava.security.egd=file:/dev/urandom JRand0.11s user 0.03s system 115% cpu 0.117 total

% time java -Djava.security.egd=file:/dev/./urandomJRandOk: -3573266464480299009java -Djava.security.egd=file:/dev/./urandom JRand0.11s user 0.03s system 116% cpu 0.116 total

可以看到`/dev/urandom`和`/dev/./urandom`的执行时间差不多，有点纳闷，再仔细看一下wiki里说的：

FreeBSD操作系统实现了256位的Yarrow算法变体，以提供伪随机数流。与Linux的/dev/random不同，FreeBSD的/dev/random不会产生阻塞，与Linux的/dev/urandom相似，提供了密码学安全的伪随机数发生器，而不是基于熵池。而FreeBSD的/dev/urandom则只是简单的链接到了/dev/random。

尽管在我的mac上`/dev/urandom`并不是`/dev/random`的链接，但mac与bsd内核应该是相近的，`/dev/random`也是非阻塞的，`/dev/urandom`是用来兼容linux系统的，这两个随机数生成器的行为是一致的。参考这里。

然后再到一台ubuntu系统上测试：

% time java -Djava.security.egd=file:/dev/urandomJRandOk: 6677107889555365492java -Djava.security.egd=file:/dev/urandom JRand0.14s user 0.02s system 9% cpu 1.661 total
    % time java -Djava.security.egd=file:/dev/./urandomJRandOk: 5008413661952823775java -Djava.security.egd=file:/dev/./urandom JRand0.12s user 0.02s system 99% cpu 0.145 total

这回差异就完全体现出来了，阻塞模式的熵池耗时用了1.6秒，而非阻塞模式则只用了0.14秒，差了一个数量级，当然代价是转换为对cpu的开销了。

// 补充，连续在ubuntu上测试几次`/dev/random`方式之后，导致熵池被用空，被阻塞了60秒左右。应用服务器端要避免这种方式。

JVM上的随机数与熵池策略