开源项目 AgentSmith-HIDS 介绍

​ 今天开源内部重点项目AgentSmith-HIDS。我们会将该项目开源，希望可以帮助到广大的信息安全团队来建设和完善自己的HIDS体系，也希望大家可以共同维护这个还处于刚起步阶段的项目。

1.关于HIDS的目的

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

2.为何自研

​ 众所周知，HIDS开源产品不乏有一些经历过大量大型甲方考验的产品，比如大名鼎鼎的OSSEC，也有一些非常完善的产品帮助可以我们建设自己的HIDS，如Linux Audit等。但是这些产品往往有一些问题不能满足我们的需求，这就要从自身对HIDS的需求来看了：

• 灵活切轻量级，有强大的联动能力，需要可以和我们自研的AgentSmith-NIDS联动，达到网络层发现一切安全问题可以追溯到主机层的用户-进程信息等一些具体细节，不仅方便排查，也可以快速解决误报，可以更详细的制定规则；
• 轻量级，对系统资源，负载占用小；
• 支持基线检查/系统完整性检测；
• 灵活的规则配置(规则引擎最好可以和AgentSmith-NIDS复用)；
• 支持最基本的HIDS功能，如各种主机层安全问题的检测等；
• 支持和CMDB联动，支持Docker，可以梳理建立“白名单”(如某应用的对外连接名单，数据库名单等)。

​ 从上述需求可以看到，完全符合的开源产品是不存在的，当谈论到“安全体系建设”，就一定绕不开联动能力，而HIDS和NIDS和CMDB的联动意义重大，几乎是一切联动的基础。而我们一开始着重测试了Linux Audit，其对Docker容器的不支持，收集的信息过于碎片化比较成为问题，关键是其较为复杂庞大的架构实现导致对宿主机性能有着较大的影响，因此考虑放弃，而其他的产品往往过于强调其本身的安全能力，而失去了联动能力，二次开发难度也颇大，因此考虑自研一款可以符合我们自身期望的产品。

3.关于AgentSmith-HIDS的功能

​ 目前AgentSmith-HIDS开发处于很早期阶段，这是我们第一个经过较为全面测试的稳定版本，功能主要是通过加载LKM来实现Hook execve,connect,init_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等，后期会增加基线检查/系统完整性检测两项比较重要的功能。

4.关于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/

​

5.关于二次开发

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