Log4j严重漏洞修最新复方案参考

　　CVE202144228，原理上是log4jcore代码中的JNDI注入漏洞。这个漏洞可以直接导致服务器被入侵，而且由于日志场景的特性，攻击数据可以多层传导，甚至可以威胁到纯内网的服务器。log4j作为Java开发的基础公共日志类，使用范围非常广，漏洞必定影响深远，想想当年commonscollections反序列化漏洞的影响范围。
　　Github漏洞公告：https：github。comadvisoriesGHSAjfh8c2jp5v3q
　　影响2。15。0的所有2。x版本。也就是说，除了最新版本之外的所有版本都受影响。
　　最直接、有效、稳定的修复方式是：将log4jcore升级到2。15。0版本
　　最直接、有效、稳定的修复方式是：将log4jcore升级到2。15。0版本
　　最直接、有效、稳定的修复方式是：将log4jcore升级到2。15。0版本
　　如果实在无法升级，可以尝试把漏洞类删掉。其他修复方式可以结合使用起到比较好的快速缓解作用，但受限于不同的环境，可能会产生各种各样比较麻烦的问题或者未来的隐患。长期修复方案需要保证稳定、可靠、持久有效，这种严重漏洞值得一个发布和重启。
　　2。15。0版本下载地址：https：repo。maven。apache。orgmaven2orgapachelogginglog4jlog4jcore2。15。0
　　pom。xml配置dependencygroupIdorg。apache。logging。log4jgroupIdlog4jcoreartifactIdversion2。15。0versiondependency缓解方式1：接入安全产品
　　第一时间上WAF规则、RASP拦截等措施，给修复争取时间。
　　但是也要注意一些静态规则上的绕过，log4j支持的写法比较多，有非常多绕过姿势。比如：｛｛lower：j｝｛upper：n｝｛lower：d｝｛upper：i｝：｛lower：r｝m｛lower：i｝｝：xxxxxxx。xxpoc｝缓解方式2：删除漏洞类
　　通过删除漏洞类进行修复的方案比较稳，也是官方推荐的一种修复方案。直接删除log4jjar包中存在漏洞的类：zipqdlog4jcore。jarorgapachelogginglog4jcorelookupJndiLookup。class
　　这种修复比较方便快捷，一般业务代码也不会用到jndilookup这个功能。不过可能会对基于版本号判定的安全数据采集造成一定困扰，无法准确统计漏洞的最新受影响情况。建议删除之后在jar包后面加上一定的标记，如：log4j2。14。1。sec。jar
　　另外，由于某些原因不想删除的话，可以自己代码替换原始的JndiLookup类，将它加到业务代码中。需要注意的是，必须保证它在log4j原类之前加载。packageorg。apache。logging。log4j。core。lookup；publicclassJndiLookup｛publicJndiLookup（）｛thrownewNoClassDefFoundError（JNDIlookupisdisabled）；｝｝
　　也可以做成依赖包，在log4jcore之前添加，可以实现同样的效果（注意不要引入不可信的第三方依赖，可能导致潜在安全风险，以下配置来源互联网，仅作为示例，请勿直接使用）：dependencygroupIdorg。glavogroupIdlog4jpatchartifactIdversion1。0versiondependency
　　当然也可以通过RASP的方式干掉漏洞类，Github上有不少RASP的无损修复方案，比如：
　　https：github。comchaitinlog4j2vaccine
　　https：github。comboundaryxcloudrasplog4j2缓解方式3：通过配置禁用log4j的lookup功能
　　禁用的方式就比较多了。然而下面2、3、4这几种方式对低于2。10版本的log4jcore都没有效果，而且环境变量和启动参数这种设置，在迁移或者变更的过程中丢失的可能性比较大。log4j在2。15。0版本中默认就已经关闭了lookup功能。
　　log4j2。component。properties、log4j2。xml默认放在ClassPath路径下，如：源代码的资源目录或者可执行程序所在的当前目录。1。设置日志输出Pattern格式
　　对于2。7的版本，在log4j中对每一个日志输出格式进行修改。在msg占位符后面添加｛nolookups｝，这种方式的适用范围比其他三种配置更广。比如在log4j2。xml中配置：lt；？xmlversion1。0encodingUTF8？ConfigurationstatusWARNConsolenameConsoletargetSYSTEMOUTPatternLayoutpatternd｛HH：mm：ss。SSS｝〔t〕5levellogger｛36｝msg｛nolookups｝nConsoleAppendersLoggersRootlevelerrorRootLoggersConfigurationpublicclassTest｛publicstaticvoidmain（String〔〕args）｛Stringt｛jndi：ldap：xxx。comxxx｝；LoggerloggerLogManager。getLogger（LogManager。ROOTLOGGERNAME）；logger。error（t）；｝｝2。设置JVM系统属性
　　在Java应用启动参数中增加Dlog4j2。formatMsgNoLookupstrue，或者在业务代码中设置系统属性：必须在log4j实例化之前设置该系统属性System。setProperty（log4j2。formatMsgNoLookups，true）；LoggerloggerLogManager。getLogger（LogManager。ROOTLOGGERNAME）；3。修改配置文件
　　在配置文件log4j2。component。properties中增加：log4j2。formatMsgNoLookupstrue，配置文件放置于应用程序的ClassPath路径下。4。设置进程环境变量
　　在环境变量中增加：LOG4JFORMATMSGNOLOOKUPStrue注意！这些配置和属性，并不能在所有场景下生效，比如在logstash中就无法生效：SolutionsandMitigations：ThewidespreadflagDlog4j2。formatMsgNoLookupstruedoesNOTmitigatethevulnerabilityinLogstash，asLogstashusesLog4jinawaywheretheflaghasnoeffect。ItisthereforenecessarytoremovetheJndiLookupclassfromthelog4j2corejar，withthefollowingcommand：
　　zipqdlogstashcorelibjarslog4jcore2。orgapachelogginglog4jcorelookupJndiLookup。class
　　Refer：https：discuss。elastic。cotapachelog4j2remotecodeexecutionrcevulnerabilitycve202144228esa202131291476缓解方式4：升级JDK版本
　　对于OracleJDK11。0。1、8u191、7u201、6u211或者更高版本的JDK来说，默认就已经禁用了RMIReference、LDAPReference的远程加载。对于RCE来说，可以起到很直接的缓解作用，可以作为增强型的加固方案。
　　在高版本JDK环境下，JNDI注入也还是存在一定RCE风险，可以参考这篇文章：https：kingx。meRestrictionsandBypassofJNDIManipulationsRCE。html
　　另外log4j漏洞本身除了RCE，还存在着巨大的攻击面，比如SSRF、敏感信息泄露等等，威胁非常大，不要企图仅仅通过升级JDK版本来修复漏洞，建议还是老老实实升级。
　　原文链接：https：kingx。mePatchlog4j。html
　　如果这篇文章对你有帮助麻烦点赞关注一下