最近闹到沸沸扬扬的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 pidelasticsearch/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"}}'
潇洒地打卡下班........................................
原创文章，作者：诺多，如若转载，请注明出处：https://www.huluohu.com/posts/17/
微信扫一扫 
支付宝扫一扫 
