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

为了保障客户的主机安全，百度智能云构建了主机安全防护系统(HOSTEYE)。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系统在运维过程中，多次碰到客户主机环境异常导致的客户端退出问题，也碰到过客户误操作导致误杀客户端进程。客户端也可能自行退出，比如上文提到的因资源使用超标导致的退出。因为客户端部署于客户主机环境，当客户端离线时，运维同学很难及时得到客户授权去登录客户主机查看问题；客户端离线场景下，从后端恢复服务也非常困难。因此，客户端保活非常重要。

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