中小企业经常受到的 3 种主机安全系统攻击,你中招了吗?(内附防御方法)丨Q推荐

百家 作者:InfoQ 2019-06-27 05:02:36

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

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

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

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

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

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

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

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


2解决容量问题

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

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

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

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

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

3构建轻量级客户端

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

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

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

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

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

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


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

4 客户端保活

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

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

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

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

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

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


5 结语

以上就是 HOSTEYE 系统在建设过程中的一些技术方面的思考,抛砖引玉,供大家交流。扫描图片二维码添加小助手,可获得现场视频及更多学习资料。


点个在看少个 bug ?

关注公众号:拾黑(shiheibook)了解更多

[广告]赞助链接:

四季很好,只要有你,文娱排行榜:https://www.yaopaiming.com/
让资讯触达的更精准有趣:https://www.0xu.cn/

公众号 关注网络尖刀微信公众号
随时掌握互联网精彩
赞助链接