上周,Jenkins项目的开发团队已经确认,Jenkins项目的其中一个关键基础设备可能已经被攻击者入侵了。根据分析结果,攻击者很可能是想通过此次攻击,来提升对此项目的访问权限。不幸的是,当系统面对这种无法确定的潜在安全威胁时,最安全的选择就是将其视作一个真实的安全威胁事件来进行处理。被攻击的设备可以访问我们一级镜像文件和二级镜像文件中的二进制程序代码,以及代码贡献者的账户信息。

因为这台设备中存储的并不是Jenkins项目的原始二进制代码,所以我们对发布给用户的Jenkins代码进行了审查,例如插件和代码包等等,并且发现在这些文件中并没有信息被篡改的痕迹。但是,我们并不能确定代码贡献者的账户信息是否被篡改了,而且也无法确定攻击者是否已经访问过这些信息了。但是出于安全方面的考虑,我们仍然重置了所有代码贡献者账户的密码。除此之外,我们还花了很大的努力,将所有的关键服务从受感染的设备中迁移至了虚拟硬件设备中,这样才能对受感染的设备进行彻底的恢复处理。

现在用户应该怎么做?

如果你从来没有在JIRA中提交过问题,没有编辑过该项目的WiKi页面,没有发布过任何插件,或者在Jenkins网站中创建用户账户的话,你仅仅只有一个Jenkins社区的访问账户。那么你很快就会接收到一封提示重置密码的电子邮件,但是如果你在其他的网络服务中使用的密码与Jenkins账户的密码一样,那么我们强烈建议用户修改其他服务的密码。除此之外,我们还建议用户使用密码管理器来生成和管理某些特定网络服务的密码。

如果你没有Jenkins社区的账户,那么你不需要进行任何操作,你也不需要为此担心。

我们怎么做,才能防止此类事件再次发生呢?

正如我们在文章中所提到的那样,我们已经将受感染的设备从基础设施中移除了。因为这样可以帮助我们解决眼下所遇到的安全问题,但是这样做并不能够保证此类事件将来不会再次发生。为了防止我们的项目中再次出现这类安全问题,我们决定采取下列措施:

1.利用Puppet-driven基础设施来提升项目服务的安全保护等级。如果不使用配置管理工具来对系统中的遗留服务进行适当的管理,用户的操作错误以及手动配置的错误都会影响项目的安全性。现在,我们所有的关键服务都已经使用Puppet来进行管理了。

2.将当前项目中的基础设备和权限管理模块尽可能地细分。受感染的设备应该从项目的基础设备中分离出来,因为和传统的系统一样,这些设备中往往托管着大量的服务。我们会根据项目服务当前的用户使用状态来迅速分离出相应的功能模块。

3.同理,我们还会在项目的基础设施中引入一个可信空间,外部网络是无法访问这个空间的,我们可以在这个可信区域内对敏感数据进行处理,例如生成项目的更新信息,采用这种方式来进行操作会更加的安全。

4.项目的安全技术人员正在对基础设施中的访问权限进行审查。项目中某些基础设施的服役时间已经长达六年了,相关项目的代码贡献者也经过了很多次的更新换代。所以我们没有必要为那些活跃度不够高的用户设置较高的访问权限。

在此,我谨代表Jenkins项目的全体开发人员,感谢CloudBees,感谢他们给我们这个项目所提供的资金,以及在迁移基础设施时所提供的帮助。

如果你还对Jenkins项目有其他的问题,你可以与我们联系。