深度解读:云时代主机安全防护系统

传统企业上云往往从购买云主机资产开始, 而安全风险也随之而来。云主机自身面临多种多样的安全问题,如主机可能被尝试暴力破解,被种植各种病毒木马软件,甚至被加密勒索。主机所承载的业务,也可能成为攻击目标,比如客户网站可能被注入网站后门。即使没有被攻击,主机系统、系统应用所存在的安全漏洞也构成潜在的安全风险。

 

为了保障客户的主机安全,百度智能云构建了主机安全防护系统(HOSTEYE)。HOSTEYE目前覆盖大部分百度智能云虚拟主机,为客户提供资产清点、安全基线检查、登录管理、恶意文件查杀、网站后门查杀等多项安全防护功能,有效保障客户云主机安全。本文将与大家分享HOSTEYE系统在设计与实现过程中的一些思考。

 

本文由百度开发者中心原创,作者刘畅。

 

0 1 对传统HIDS模型的借鉴与丰富

 

百度智能云主机安全系统(HOSTEYE)在设计时,吸收了传统主机入侵检测系统(HIDS)系统的诸多优秀思想。传统HIDS系统一般是C-S架构,以入侵检测为重点,部署于IDC环境。

 

HOSTEYE系统也基于C-S架构,但在后端引入了云端模型,使之能够充分利用云端的巨大算力,做更多、更负责的数据计算;而且能够引入云端的安全能力(比如第三方安全接口提供的能力)。

 

在引入云端概念的基础上,我们对系统的数据流动模型做了新的定义。系统的数据可以简单分类为安全信息和安全策略。安全信息是从客户端采集,向云端流动的。比如某个虚机在某个时刻被某个恶意IP尝试爆破,某个虚机在某个时刻发现恶意木马,又或者某个主机在某个时刻发现有弱密码。这些都可以认为是安全信息。

 

HOSTEYE客户端采集这些信息并上报到云端。安全策略是云端生成,向客户端流动。比如认为某个IP是恶意IP,应当予以阻断;判定某个文件是网站后门,应当清理等。这些策略由后端生成,下发到客户端生效。

 

云端利用海量的安全信息,建立单机、多机、集群等多层次的计算模型,结合人工分析,做复杂的大数据计算,生成丰富的安全策略;这些安全策略下发到客户端生效后,进一步产生新的安全信息。如此循环,构成一个安全信息、安全策略的数据流动反馈。

 

 

0 2 解决容量问题

 

主机安全客户端(Hosteye Agent)部署于几乎所有的百度智能云虚拟主机和部分物理机。伴随着百度智能云的迅速成长,HOSTEYE需要解决容量问题。HOSTEYE系统采用事件驱动的高性能IO复用服务器 + 高可用消息队列 + 云端逻辑处理 的模型来解决这个问题,这也是很多大型互联网系统的基本模型。在具体的实现过程中,以下两点值得注意:

 

第一,Agent与Server端的通信是经过加密的。在Server端处理消息解密是个CPU密集型任务,特别是在系统客户端较多、消息较多的场景下,经常会打满服务端CPU。

 

考虑到消息加解密任务与业务逻辑相对独立,我们将加解密任务与业务逻辑剥离开来,抽成独立的功能模块,并将其单独部署。这种方式,为使用硬件加速消息加解密也提供了可能。

 

第二,保证Agent与Server的通信有序。安全事件往往带有时间戳,定义了事件间的先后顺序,对安全策略分析非常关键。

 

由于使用了消息队列,消息被打散分发至多个队列,而多个队列的消费能力不同,可能导致安全事件归档时时间乱序。在使用消息队列时,HOSTEYE系统通过一致哈希等算法,保证同一客户端消息分发到指定队列,并保证同一客户端消息被同一消费者消费。

 

0 3 构建轻量级客户端

 

HOSTEYE客户端运行在客户主机环境中,与客户的业务在同一环境。

 

HOSTEYE系统的目标是Agent在为客户提供安全服务的同时,不干扰客户业务的正常运行。这其中最首要的内容,就是占用极少的主机资源,如CPU/内存/磁盘IO等。另一方面,HOSTEYE系统为客户提供丰富的主机安全防护功能,覆盖主机风险发现、入侵检测、安全审计等各个方面。某些功能,比如恶意文件查杀,需要扫描客户文件,是资源密集型任务。

 

那么,如何同时满足功能丰富、资源占用少的需求呢?HOSTEYE系统从四方面考虑,构建一个轻量级的客户端Agent。

 

首先是从整体设计的角度,将负载上移。系统将客户端较重的任务,如文件扫描等,从客户端转移到云端,将更多的计算任务放在云端处理。

 

其次是做到功能可伸缩。每一个功能点在客户端实现为一个可动态加载/卸载的功能模块,如登录管理模块、网站后门查杀模块等。客户可以通过配置功能策略,选择适合于自己场景的功能集合;客户端按照功能策略,加载不同的功能集合。通过这种方式,客户端不必加载全部功能集合,负载进一步减小。

 

第三是主动型资源控制。在客户端负载确定的情况下,通过主动控制资源消耗,将客户端资源限定在一定范围内,比如单核5%以内。具体实现时,在客户端实现一个资源主控线程,监控其他任务线程的资源使用状况,如果任务线程出现CPU占用过高,则主动发送命令让任务线程暂停任务,从而降低对系统CPU的占用。可以以信号量作为命令的实现方式,主线程发送自定义信号量,而任务线程需要在初始化时注册该信号量的回调函数。

 

 

第四则是被动型的资源控制。当客户端因为某些非预期的问题,导致客户端进程CPU长时间100%或者内存占用持续超过设定阈值,则可以将客户端进程退出。这样做的首要目的是保护客户业务不被影响。

 

04

客户端保活

 

客户端保活,指的是保证客户端进程持续在线,从而能够与后端正常通信,保证系统功能的正常运行。几乎所有客户端软件,当其运行于多种多样的客户主机环境时,都可能碰到各种问题导致客户端进程退出,从服务端视角看就是客户端离线。

 

HOSTEYE系统在运维过程中,多次碰到客户主机环境异常导致的客户端退出问题,也碰到过客户误操作导致误杀客户端进程。客户端也可能自行退出,比如上文提到的因资源使用超标导致的退出。因为客户端部署于客户主机环境,当客户端离线时,运维同学很难及时得到客户授权去登录客户主机查看问题;客户端离线场景下,从后端恢复服务也非常困难。因此,客户端保活非常重要。

 

常见的保活思路非常简单,就是重启客户端进程。但这种方案非常粗暴。假设某个客户端软件存在内存泄露问题,当它自行崩溃或者被系统主动杀掉后,若重复拉起,对系统还会造成影响。在很多场景下,简单的无休止重启进程并没有什么收益,反而可能对客户的业务造成持续性影响。

 

HOSTEYE系统设计了更优的保活策略。以火箭模型示意,三级火箭在升空过程中,第一级火箭发动机首先关机分离,之后第二节分离,最后是第三节。HOSTEYE客户端保活策略也是类似的。

 

HOSTEYE客户端设计为一个父进程和一个子进程。父进程负责创建子进程,并定期做更新检查;子进程按照功能策略加载功能模块,执行正常的业务逻辑。客户端异常一般是因为功能模块执行中碰到问题。当客户端首次发生异常退出时,客户端会调整其加载的功能模块,尝试子进程重启运行;如果再次发生异常,则会情况功能模块,只留父子进程运行。

 

这种情况下,客户端与服务端的通信仍然保留,服务端可以与客户端通信并尝试策略更新。如果继续发生异常退出,则只保留父进程运行。这种场景下,父进程保留定期检查升级的能力,并在服务端发布更新时拉取新的版本。

 

 

结语

 

以上就是HOSTEYE系统在建设过程中的一些技术方面的思考,抛砖引玉,供大家交流。HOSTEYE系统是一个较为成熟的系统,但也仍然在不断地丰富系统功能,优化系统架构。我们希望能够和客户以及广大开发者一起,将HOSTEYE建设为一个架构可靠、功能丰富的主机安全能力平台。

共4条回复 最后由没在咖啡 回复于2020-03-23 09:34