不升级Elasticsearch版本修复Log4j漏洞的方法

作者 胡萝虎 日期 2022-01-14
不升级Elasticsearch版本修复Log4j漏洞的方法

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

image-20220114222531291

背景

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

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

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

出招

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

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

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

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

正经说话

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

  1. 备份Elasticsearch种的log4j-core Jar包

    cp elasticsearch/elasticsearch-5.6.10/lib/log4j-core-2.9.1.jar .
  1. 关键步骤,删除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
  1. 关闭Elasticsearch集群的分片自动分配

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

    cd elasticsearch/config/

    在**jvm.options **文件中加入-Dlog4j2.formatMsgNoLookups=true

  2. 重启Elasticsearch

    kill -9 pid
    elasticsearch/bin/elasticsearch -d -p pid.txt
  1. 开启Elasticsearch集群的分片自动分配

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

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

“扫一扫接着看”