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

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

 

为了保障客户的主机安全，百度智能云构建了主机安全防护系统(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建设为一个架构可靠、功能丰富的主机安全能力平台。