Linux系统应用漏洞修复、框架升级的一点心得整理

这几天忙着升级线上环境的框架，迫不得已的升级。为什么说是迫不得已呢，因为Linux服务器检测出来一百多个应用漏洞，没办法只能升级了。

其实这些应用漏洞一直存在，只是刚开始没买安全服务，有漏洞也当作不知道。后来买了安全服务，检测出来的漏洞就摆在那里，再不修复就说不过去了。

针对Linux小白用户，一开始看到这些漏洞肯定头大，不知道怎么修复。细细研究一下，好像修复起来也没那么难。我就把个人的修复经历写出来，有更好方法的不妨留在评论区供大家参考。

一、应用漏洞分析

应用漏洞和系统漏洞不同，系统漏洞是Linux系统的漏洞，Linux系统出现漏洞了，直接升级系统就可以了。

应用漏洞，就是我们写的应用程序，所引用框架出现的漏洞，这个时候就需要修补或升级框架。

有一个zookeeper的应用漏洞，如下图所示：

查看漏洞详情：

在详细里，我们可以看到zookeeper框架当前的版本为3.4.8，漏洞的编号：CVE-2019-0201，修复补丁的链接：https://zookeeper.apache.org/security.html#CVE-2019-0201，还有影响哪些应用。

对于这个漏洞，我可以选择忽略，也可以加入白名单，如果已经修复了，可以进行验证修复结果。

今天我准备修复一下这个漏洞。

二、修复漏洞

1、项目里zookeeper框架引用查看

在项目里，我引用的zookeeper如下：

  <groupId>org.apache.zookeeper</groupId>

  <artifactId>zookeeper</artifactId>

  <version>3.4.8</version>

  <exclusions>

      <exclusion>

          <groupId>log4j</groupId>

          <artifactId>log4j</artifactId>

      </exclusion>

      <exclusion>

          <groupId>org.slf4j</groupId>

          <artifactId>slf4j-api</artifactId>

      </exclusion>

      <exclusion>

          <groupId>org.slf4j</groupId>

          <artifactId>slf4j-log4j12</artifactId>

      </exclusion>     

  </exclusions>

zookeeper是有对应的安装软件的，本地环境的zookeeper的版本为3.4.14，线上环境的zookeeper版本为3.5.9。

也就是说，我在选择新的zookeeper版本时，需要考虑对安装软件的兼容，需不需要升级安装软件，最好不要升级。

2、maven官网调查zookeeper版本

来到maven官网，查找对应的框架。

最新版本的zookeeper已经到3.9.3了。

几乎每个版本都有漏洞，看来框架版本升级只是早晚的事情。

我用的3.4.8还是2016年的框架，十年了，太老了。

在这个版本，有13个编译依赖，就从这个版本看起吧。

为了防止这个架包的log4j、slf4j-api、slf4j-log4j12子依赖和主框架冲突，还把这三个框架移除了。

在3.4.9、3.4.10版本中，和这个版本差不多，依旧是13个编译依赖。

在3.4.11、3.4.12版本中，有15个编译依赖。

在3.4.13中，有16个编译依赖，在3.4.14中有17个编译依赖。

...3.5.4-beta中有19个编译依赖，在3.5.5版本中只有6个依赖，那么多依赖都剪掉了？

不怕多，就怕少，本次就先升级到3.4.14吧。

升级到3.4.14后，项目正常启动，测试几个主要功能OK，升级OK。

3、子架包漏洞修复

还有几个漏洞是关于netty框架的，但是在整个项目里都没有使用netty的地方呀？

会不会是其他架包中包含的架包呢？

使用mvn dependency:tree命令遍历架包。

mvn dependency:tree

# 如果是子项目加 -pl

mvn dependency:tree -pl  子项目名称

输出部分截图：

不是直接引用，就是间接引用，我们总归能找到那个架包。

把这个架包排除，测试一下，项目可以正常启动，所有功能正常运行，项目升级成功，漏洞修复成功。

三、最后总结

代码写好了只是开始，写好的代码后面是无尽的维护，这很残酷，也很真实。

就拿zookeeper框架来说，哪个版本没有漏洞？只要项目有人用，就需要不断地升级。

在springboot 项目里，如果引入的是第三方独立的框架，在第一次使用时建议直接引用最新版本，那样就可以把升级的时间线延长。

如果是关联框架，比如mybatis等等，还需要考虑mysql安装软件的版本是否兼容，不兼容要么不升级，要么一起升级。

springboot的版本和spring相关框架有关联关系，还需要到官网或maven官网查找，查询关联的版本一起升级。框架升级是一件麻烦事，升级有依据，成功的可能性就比较大。