近期log4shell的漏洞可以称作塞博界的原子弹爆炸，不论是对甲方或是承包方，防御方或是进攻方，对每个人基本都是1场武器战。咱们学了十多年技术攻防，技术要求愈来愈高，结果一晚回到解放前，不得不承认是十分打击自信心的非常容易令人生成信念摇摆不定。noting，事儿发生了，那做为甲方的成员或是得好好地解决。应对网络上遮天盖地的有关这一漏洞的修补方法，咱们也没有时间思索只有对着做。如今静下心来，我才发觉有许多地方存有着坑，而这种坑这些拼了命刷存在感的厂家是不容易对你说的，由于她们要抢头条信息。下边我梳理一下下现在我的许多有关修补上的见解和碰到的坑。
最先毫无疑问靠早已有的许多安全防护设备来做安全防护，例如拼了命加waf的各种各样规则，尽管这存有绕过可是一直能阻拦许多脚本小子来给后面的修补争取时间。次之假如你用了rasp，那麼祝贺你了这一的确可以第一时间阻拦漏洞执行，可是也需要考虑到2个方面：你的waf、rasp、hids这类的产品打印日志本身是不是存有漏洞，你的soc本身是不是存有漏洞,你的rasp的涉及面是不是包括到许多非本身研发的资产，例如开源系统的、购置的等.假如网络安全产品本身有什么问题，提议立刻更新log4j版本，对于怎么升级这方面下边要说，由于或是很多地方要留意.
0x02暂时修补方法上的问题
有关这一暂时修补方法我不得不调侃，全部承包方厂家的微信公众号基本都是抄的，里边存有许多问题并没有准确表明，乃至也有失效的修补方法！例如这一段：
这一段是最开始流出来的修补提议，几乎全部微信公众号都写的这一段，这里边有几个问题：
nolookups设置成true的确可以防止漏洞，可是是不是存有业务侧的影响？
设定系统系统变量的方法得出的key值是错误的并不起效
jdk版本高了的确可以阻拦rce，可是不可以阻拦敏感信息外送
刚看了看，某司在后面的通知里对修补方法完成了许多调整，这也的确非常值得毫无疑问的
但如果你是甲方，上边的修补方法你依然要慎重。或是我前边说的那3个问题，我一个一个来说一下下
（1）nolookups
nolookups为true的时候代表着关掉lookup，那麼这一影响究竟是什么呢？三梦师傅检测了一下下回答是那样的：
还没有评论，来说两句吧...