DevOps经历的 Log4j痛苦经历 - Reddit

22-03-22 banq

我的公司一直在为log4j的修复而苦恼:
巨大的微服务架构意味着数百个应用程序需要更新、重建和重新部署他们的repo。
更糟的是,自从log4j之后,该公司对所有的库都进行了严格的扫描和修复要求。如果在几天内没有得到解决,存储库中的镜像有任何CVE,现在就会被升级到有副总裁参与的作战室...。
我们的CI/CD肯定没有准备好,而且一直在努力保持我们的数百个正在运行的应用程序的顶部,因为新的漏洞被发现...... 而我们是一家大公司(比如,最大的公司之一)。

我只是想知道其他开发者有什么经验...... 你是否有100-1000个应用程序,而log4j对你的组织来说是个小菜一碟?
巨大的影响使其他一切都停滞不前?
你是否利用了像whitesource、snyk等SCA的优势?
你们使用什么工具来管理这样大量的代码/repo级的变化,是容易还是困难?
gitlab是不是为你做了所有的事情?
而且,如果你确实有100-1000个应用程序,而下一个log4j的情况出现了,你是否设置了自动修复它的时间?如何解决?
  
Reddit网友:
我们有大约5个共同的架构,由DevOps团队和架构团队管理。每个人都从一个实现该架构的 repo 中提取,并在此基础上开发他们的应用程序。更新中央架构,每个人都会继承,应用程序会受到保护。
第三方应用程序是另一个问题。Zookeeper是狗屎
 
我的公司相当大,不是怪物,但足够大。我们在处理更多的现代微服务方面没有什么困难,所有的微服务都有一个所有者团队,修复和部署工作在几天内就完成了。我们确实在遗留问题上做了努力...... 有些代码已经12年没有被碰过了(这是我需要修复的最古老的代码),是的,新的扫描每天都会发现新的CVE...... 修复起来还是很麻烦的。
 
有300多个应用程序需要更新。花了几周的时间来发布所有的新版本。现在又有新的工具来扫描漏洞,我们应该更新所有的关键库。
 
这里是大公司 SRE:它需要我们大约 100 人待命的一个完整周末,基本上是为我们许多很多盒子中的每一个更新补丁,然后在我们整理完所有内容时多次重新启动所有内容。幸运的是,漏洞本身没有任何实际影响,因为我们幸运地拥有良好的网络隔离。
  
我遇到的挑战是,我的公司提供了几个不同的SaaS应用程序,其中我的开发团队支持3-4个。当log4j漏洞被公布时(12月中旬),我们没有立即进行自动扫描来确定哪些是有漏洞的,所以我们自然而然地询问开发人员他们的应用程序是否有漏洞。
由于是12月中旬,每个人都在燃烧他们最后的假期,我们只有一个骨干人员,开发人员不能给我们明确的指示,告诉我们该怎么做或什么是有漏洞的,尽管我们有来自管理层的最后期限,所有东西都需要在3天内修复。

更糟糕的是,我们的一些应用程序是单用户的,所以我们需要客户的批准才能获得不定期的停机时间,那接近年底的时候,沟通很慢,所以我们只是决定紧急改变是可以的,因为这些改变与安全有关。

更糟糕的是,尽管我们在devops中部署了应用程序,但我们有一个实施团队,与客户一起工作,以定制东西。这就造成了我们的标准化的偏移,所以如果一些傻瓜移动了文件,或者做了一个没有记录的改变,那么.jar文件就不在它应该在的地方(他们应该开一个票,这样我们就可以更新模板/脚本并重新部署)。因此,我们的自动化查找和替换可能会失败。在规模上,这就成了一个问题,因为我们有时不得不用RDP/SSH来手动寻找这个文件。

当我们最终认为我们已经完成了工作,并且没有什么问题时,2月份的时候,一个开发团队说他们搞错了,他们的应用程序有漏洞,而且已经有两个月了,开发团队需要立即替换jar文件,这样我们才能通过第三方审计。
 

实际上是从 Jar 文件中删除了几个类。只需将更改合二为一。将该 log4j 库推送到服务器的其余部分。这有什么难的?

zip -d log4j-core-2.0.2.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

  
 

猜你喜欢