我们将该项目开源，希望可以帮助到广大的信息安全团队来建设和完善自己的HIDS体系，也希望大家能够支持并共同维护这个还处于刚起步阶段的项目。

项目地址：

https://github.com/DianrongSecurity/AgentSmith-HIDS

HIDS要解决的问题

HIDS(Host-based Intrusion Detection System)作为传统攻防视角的重要一环，有着不可替代的作用，可以有效的检测到从网络层面难以发现的安全问题，如：后门，反弹shell，恶意操作，主机组件安全漏洞，系统用户管理安全问题，主机基线安全风险等。

曲折的尝试探索之路

众所周知，HIDS开源产品不乏有一些经历过大量大型甲方考验的产品，比如大名鼎鼎的OSSEC，也有一些非常完善的产品帮助可以我们建设自己的HIDS，如Linux Audit等。我们曾经尝试基于OSSEC进行裁剪和二次开发，也曾经试图借助Linux Audit的能力获取用户操作信息，但是这些尝试往往因为性能和资源消耗问题、用户态监测的信息来源完整性的问题，最终放弃了这种改造方案。在探索尝试过程中，我们逐渐清晰了点融对于HIDS的需求：

* 灵活且轻量级：对系统资源需求少，系统负载占用小；

* 有丰富的API和强大的联动能力：需要可以和我们自研的AgentSmith-NIDS联动，达到网络层发现一切安全问题可以追溯到主机层的用户-进程信息等一些具体细节，不仅方便排查，也可以快速解决误报，可以更详细的制定规则；

* 支持基线检查/系统完整性检测；

* 支持规则引擎，能够灵活的进行规则配置(规则引擎最好可以和AgentSmith-NIDS复用)；

* 支持最基本的HIDS功能，如各种主机层安全问题的检测等；

* 支持和CMDB联动，支持Docker，可以梳理建立“白名单”(如某应用的对外连接名单，数据库名单等)。

从上述需求可以看到，完全符合的开源产品并不存在。但是当谈论到“安全纵深防御体系”，就一定绕不开不同层次安全设备的联动能力，而HIDS、NIDS和CMDB的联动意义重大，几乎是一切联动的基础。

前文提到的几种尝试中，我们曾经着重测试了Linux Audit，但是其对Docker容器的不支持，收集的信息过于碎片化比较成为问题，最为关键的是，其较为复杂庞大的架构实现导致对宿主机性能产生了显著的影响，因此最终放弃。而其他的产品往往过于强调其本身的安全能力，失去了联动能力，二次开发难度也颇大，因此最终我们选择了自研之路，试图打造一款可以符合我们自身期望的产品。

AgentSmith-HIDS的研发思路和测试结果

AgentSmith-HIDS从设计伊始，就是以黑客攻击的Kill Chain作为出发点，从这个角度分析梳理常见的风险操作，从而确保轻量化和对性能损耗的最小化。我们采用了通过加载LKM来实现Hook execve,

connectinit_module,finit_module 的system_call，execve是为了捕获执行的命令来监控异常操作，归档等；监控connect是为了捕获服务器的网络行为，不仅仅可以发现很多安全问题，也可以方便的和AgentSmith-NIDS联动；监控init_modle和finit_module是为了监控加载LKM的行为，可以在这个层面做一些Anti-Rootkit的检测。

为什么要在内核态实现这些Hook呢？因为我们希望可以尽可能的全面的收集以上信息，避免被绕过。而且在这里做Hook如果将来需要做一些危险命令等拦截也成为了可能，如：rm -rf /等。我们认为，越接近底层，离真相越近。

关于性能，我们为了尽可能的减少系统负载，放弃了最开始的传输方案：netlink，改用共享内存的方式来实现内核态到用户态到消息传输，经过测试对Hook的system_call的性能影响相较于netlink降低30%左右（更加详细的性能测试报告请见项目内）。

由于Docker的底层实现依赖了Linux namespace，因此我们在Hook的过程中可以很容易的区分信息的来源是宿主机本身还是其上的某个Docker容器，达到对Docker的一定支持，在这里我们确定了Docker容器信息后便可方便的和我们的CMDB关联，梳理业务信息等。

以上是AgentSmith-HIDS的LKM模块的功能，而用户态的接收端，目前的主要作用是接收LKM传输的信息，格式化，传输到server端，功能还较为简单，开源的部分还不具备检测能力(规则引擎复用AgentSmith-NIDS规则引擎，联动能力复用AgentSmith-NIDS，归档等其他功能复用AgentSmith-NIDS)，有简单的心跳检测支持，断连自动关闭LKM等，后期会增加基线检查/系统完整性检测两项比较重要的功能。

AgentSmith HIDS整体架构

AgentSmith HIDS实现原理

AgentSmith-HIDS的能力

考虑到AgentSmith-HIDS在纵深防御体系中的定位和功能需求，我们希望除了监测能力之外，还要保持充分的联动能力和可扩展性，在规则引擎上，能够尽量复用我们的AgentSmith-NIDS的规则引擎/联动/告警/归档/异常检测算法/资产模块等基础能力，保持体系的一致性和连贯性。

这样，一方面能够尽可能的减少在宿主机的运算，另一方面我们的思路还是“看好两扇大门”：操作和网络行为。因此在第一阶段我们舍去了文件变更检测等功能，而是尝试通过梳理“白名单”来发现异常。比如，我们规范了线上服务器用户后，我们不需要监测authorized_keys和/etc/shadow，在异常用户第一次操作的时候我们便可以关联到堡垒机或其他地方来检测该用户是否有存在的合理性；一切对外连接行为无论是正常第三方业务调用，DNS，NTP，反弹shell，被C&C上线，各种姿势的隐秘通道通信，我们都可以通过连接行为基础信息(TCP/UDP五元组+nodename+appid)+CMDB+pre环境第三方业务调用名单+DNS/NTP等基础服务白名单(往往是内部指定)来排除掉正常的连接行为，而简单的反弹shell等，规则引擎就可以应付一二。

这样不仅可以有发现安全问题，归档操作等安全能力，还可以来建立起对我们自己业务的熟悉程度，比如：通过HIDS，NIDS，CMDB的关联，可以快速查询出数据库、表和应用的调用访问关系及相关的db user；我们可以快速的识别到我们整个业务线应用系统调用了哪些第三方服务，在故障应急需要切换线路IP时快速的联系对方，将我们新出口的IP加入白名单；还有一些终端信息收集的能力，可以大大的提高我们定位、分析、处置异常的能力，比如以前只有NIDS的时候，端口扫描的策略是通过源IP+被reset的频率来做的，但是也可能是某些业务调整或者故障引起的，这时候NIDS排查较为困难，但是有了HIDS的联动我们可以快速的识别是我们的内部应用还是恶意行为。

总而言之，我们的HIDS的期望是尽量轻量化，注重联动能力，尽可能复用已有的基础能力，二次开发友好，整体思路还是黑名单(规则)+异常检测+白名单来做，可以参考点融的NIDS的建设思路：http://www.ebwill.com/2018/09/10/DR_NIDS/

关于二次开发

AgentSmith-HIDS对二次开发应该是很友好的，基础的LKM模块完善程度较高，遵循其共享内存的消息传输算法便可获取信息，项目中有基础的Demo实现，任何人都可以快速搭建并实现最基础的信息收集，关于规则引擎的编写也应该足够简单，如果有自己的NIDS，那么基于TCP/UDP五元组的信息也可以快速联动，这样未来发现NIDS告警或者威胁情报告警就再也不用上服务器抓包/手动排查了，通过关联HIDS的信息就可以有一个基础的判断（这是曾经我努力坚持推HIDS的一个重要目标。面对稍纵即逝的短连接和大量的威胁情报告警NIDS提供的有限的信息让我们判断是不是误报都成为问题）。

项目地址

最后，该项目是本人的第一个C && Rust项目，时间仓促，开发周期不满2个月，但已经过点融内部的初期性能、稳定性测试，也欢迎大家把玩测试，希望能在issue区见：https://github.com/DianrongSecurity/AgentSmith-HIDS

可在微信群 “DSRC点融安全”中与我们讨论

入群请先添加运营人员

（微信：yyf0630）

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课