最近闹到沸沸扬扬的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"}}'
潇洒地打卡下班........................................
