传统企业上云往往从购买云主机资产开始, 而安全风险也随之而来。云主机自身面临多种多样的安全问题,如主机可能被尝试暴力破解,被种植各种病毒木马软件,甚至被加密勒索。主机所承载的业务,也可能成为攻击目标,比如客户网站可能被注入网站后门。即使没有被攻击,主机系统、系统应用所存在的安全漏洞也构成潜在的安全风险。
为了保障客户的主机安全,百度智能云构建了主机安全防护系统(HOS TE YE)。HOSTEYE目前覆盖大部分百度智能云虚拟主机,为客户提供资产清点、安全基线检查、登录管理、恶意文件查杀、网站后门查杀等多项安全防护功能,有效保障客户云主机安全。本文将与大家分享HOSTEYE系统在设计与实现过程中的一些思考。
在引入云端概念的基础上,我们对系统的数据流动模型做了新的定义。系统的数据可以简单分类为安全信息和安全策略。安全信息是从客户端采集,向云端流动的。比如某个虚机在某个时刻被某个恶意IP尝试爆破,某个虚机在某个时刻发现恶意木马,又或者某个主机在某个时刻发现有弱密码。这些都可以认为是安全信息。
主机安全客户端(Hosteye Agent)部署于几乎所有的百度智能云虚拟主机和部分物理机。伴随着百度智能云的迅速成长,HOSTEYE需要解决容量问题。HOSTEYE系统采用事件驱动的高性能IO复用服务器 + 高可用消息队列 + 云端逻辑处理 的模型来解决这个问题,这也是很多大型互联网系统的基本模型。在具体的实现过程中,以下两点值得注意:
第一,Agent与Server端的通信是经过加密的。在Server端处理消息解密是个 CPU 密集型任务,特别是在系统客户端较多、消息较多的场景下,经常会打满服务端CPU。考虑到消息加解密任务与业务逻辑相对独立,我们将加解密任务与业务逻辑 剥离 开来,抽成独立的功能模块,并将其单独部署。这种方式,为使用硬件加速消息加解密也提供了可能。第二,保证Agent与Server的通信有序。安全事件往往带有时间戳,定义了事件间的先后顺序,对安全策略分析非常关键。
由于使用了消息队列,消息被打散分发至多个队列,而多个队列的消费能力不同,可能导致安全事件归档时时间乱序。在使用消息队列时,HOSTEYE系统通过一致哈希等算法,保证同一客户端消息分发到指定队列,并保证同一客户端消息被同一消费者消费。
HOSTEYE系统的目标是Agent在为客户提供安全服务的同时,不干扰客户业务的正常运行。这其中最首要的内容,就是占用极少的主机资源,如CPU/内存/磁盘IO等。另一方面,HOSTEYE系统为客户提供丰富的主机安全防护功能,覆盖主机风险发现、入侵检测、安全审计等各个方面。某些功能,比如恶意文件查杀,需要扫描客户文件,是资源密集型任务。
那么,如何同时满足功能丰富、资源占用少的需求呢?HOSTEYE系统从四方面考虑,构建一个轻量级的客户端Agent。首先是从整体设计的角度,将负载上移。系统将客户端较重的任务,如文件扫描等,从客户端转移到云端,将更多的计算任务放在云端处理。
其次是做到功能可伸缩。每一个功能点在客户端实现为一个可动态加载/卸载的功能模块,如登录管理模块、网站后门查杀模块等。客户可以通过配置功能策略,选择适合于自己场景的功能集合;客户端按照功能策略,加载不同的功能集合。通过这种方式,客户端不必加载全部功能集合,负载进一步减小。
第三是主动型资源控制。在客户端负载确定的情况下,通过主动控制资源消耗,将客户端资源限定在一定范围内,比如单核5%以内。具体实现时,在客户端实现一个资源主控线程, 监控 其他任务线程的资源使用状况,如果任务线程出现CPU占用过高,则主动发送命令让任务线程暂停任务,从而降低对系统CPU的占用。可以以信号量作为命令的实现方式,主线程发送自定义信号量,而任务线程需要在初始化时注册该信号量的回调函数。
第四则是被动型的资源控制。当客户端因为某些非预期的问题,导致客户端进程CPU长时间100%或者内存占用持续超过设定阈值,则可以将客户端进程退出。这样做的首要目的是保护客户业务不被影响。客户端保活,指的是保证客户端进程持续在线,从而能够与后端正常通信,保证系统功能的正常运行。几乎所有客户端软件,当其运行于多种多样的客户主机环境时,都可能碰到各种问题导致客户端进程退出,从服务端视角看就是客户端离线。
HOSTEYE系统在运维过程中,多次碰到客户主机环境异常导致的客户端退出问题,也碰到过客户误操作导致误杀客户端进程。客户端也可能自行退出,比如上文提到的因资源使用超标导致的退出。因为客户端部署于客户主机环境,当客户端离线时,运维同学很难及时得到客户授权去登录客户主机查看问题;客户端离线场景下,从后端恢复服务也非常困难。因此,客户端保活非常重要。
常见的保活思路非常简单,就是重启客户端进程。但这种方案非常粗暴。假设某个客户端软件存在内存泄露问题,当它自行崩溃或者被系统主动杀掉后,若重复拉起,对系统还会造成影响。在很多场景下,简单的无休止重启进程并没有什么收益,反而可能对客户的业务造成持续性影响。