Elasticsearch版本修复Log4j漏洞的方法

最近闹到沸沸扬扬的Log4j漏洞事件可谓人尽皆知，各大厂商也纷纷开始紧急救火、修补漏洞。修复漏洞的方法也很简单，一般也就是把依赖的Log4j版本升级到官方最新版即可，但是也有一种情况比较棘手--中间件系统。

背景

笔者同样也接到公司安全部门的通知，要求尽快修复此漏洞。说干就干，快刀斩乱麻，一通招呼后，各个业务系统也都正常更新了版本发布上线。本以为已经没事了，结果我还是太年轻。

就在我以为可以万事大吉的时候，安全部又发来一个待修复列表，上面赫然是非常核心的Elasticsearch集群！！！真是头皮发麻，Elasticsearch用的log4j版本也有问题！

话说这个Elasticsearch集群大概还是在2017年上线的，版本比较低（v5.6.3）,里面保存着5年多订单数据，真心没胆量为了修复一个日志漏洞去升级这么重要的中间件，可不修复又不行，如何是好？

世上本没有河，我踩的坑多了自然就会有炸土豆条。

经过主持了一次度娘与谷哥的婚礼后，我成功找到了一个解决方案----擒贼擒王大法。

何谓擒贼擒王，简单说就是拿住关键敌手，在这个问题中关键敌手不是Elasticsearch本身，而是Log4j的lookup特性。

那么我把lookup干掉不就行了嘛！

前面啰嗦了这么多，其实都是在废话，下面正经上操作步骤(其他中间件修复也类似)。

备份Elasticsearch种的log4j-core Jar包

cp elasticsearch/elasticsearch-5.6.10/lib/log4j-core-2.9.1.jar .

关键步骤，删除log4j-core中的JndiLookup.class文件

zip -q -d elasticsearch/elasticsearch-5.6.10/lib/log4j-core-2.9.1.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

关闭Elasticsearch集群的分片自动分配

curl -H "Content-Type: application/json" -XPUT http://esip:9200/_cluster/settings -d '{"transient":{"cluster.routing.allocation.enable":"none"}}'

禁用lookup
```
cd elasticsearch/config/
```
在jvm.options 文件中加入-Dlog4j2.formatMsgNoLookups=true

重启Elasticsearch

kill -9 pid
elasticsearch/bin/elasticsearch -d -p pid.txt

开启Elasticsearch集群的分片自动分配

curl -H "Content-Type: application/json" -XPUT http://esip:9200/_cluster/settings -d '{"transient":{"cluster.routing.allocation.enable":"all"}}'

潇洒地打卡下班........................................