提个建议不定时更新

[sam6666666]

1、hook方式兼容性和稳定性太弱了，哪怕你换成ftrace方式也不错。

2、agent是需要考虑兼容性的，采用golang的话golang本身是需要epoll等接口支持的，所以你这样就得放弃一部分系统平台了。这块建议用C来做。

[EBWi11]

@sam6666666 非常感谢您的建议，关于你的建议，我是这样想的。

首先AgentSmith-HIDS作为一款安全属性的信息收集工具，我们对信息的维度和完整性会比较高，ftrace作为一款优秀的tracker并不一定可以满足我们的需求，举几个例子：

1. Hook DNS Query的过程中，我们对recvfrom的数据进行多处偏移量计算，确认是DNS请求后，又会计算Question，然后才会将Question取出扔回用户态，以确保尽可能小的性能损耗。
2. 针对Rootkit行为检测我们会调用用户态的方法来确认进程/文件的信息，然后在判断是否异常，是否扔回用户态上报。
3. 检测文件创建时，我们不仅判断Flags，还会借助user_path_at来判断文件是否存在，来判断实是否是真正的新建。
4. 我们后期还准备参考LKRG做一些Kernel漏洞利用的检测。
5. 后期我有考虑将它作为HIPS，即拥有阻断能力的入侵检测框架。
6. 这些场景使用ftrace应该是比较难完成的，况且性能损耗也会成为问题。我个人认为ftrace更适合性能分析，异常追踪还原等。不知道我有没有理解错，因为实际上我并没有深度使用过ftrace。

关于稳定性和兼容性，首先兼容性来说是一个比较头疼的问题，但是也还好，原因是syscall在kernel的发展中变动不是很大，我们的一些基础依赖在长期的发展中变化也不是非常的大，都是一些比较细微的差别，目前已经兼容了2.6.32和3.10(Centos上)。

关于稳定性，稳定性的确是最大的问题，但是想做一款性能优秀，信息全面，AntiRootkit，难以被攻击者绕过，响应需求快速，二次开发友好的产品所必须面对的，因为很难有其他的选项。况且目前AgentSmith-HIDS是一款实验性质的，个人的小作品。

最后，如果方便的话，可以提供一下您说的不稳定的环境和测试的情况吗？便于我复现然后fix bug。非常感谢🙏

[sam6666666]

先点个赞，能开源出来都是值得学习的。

这块首先看应用场景了，如果应用到实际服务器或者其他线上环境的话，内核的版本大概是从2.6.9-5.x的。几个大版本之间(2.4\2.6\3.x\4.x-5.x)变化还是很明显的，函数参数和函数声明上。

而且32位和64的hook方式也是有个问题。 兼容性这块你得考虑下如果线上使用的话同时有各个版本的内核，那版本升级的问题怎么解决。 几个建议重点测试的环境是(32位/64位): CentOS4.8 2.6.9 CentOS5.5 2.6.18 CentOS6.5 2.6.32 CentOS7 3.10 Ubuntu16.10 4.2 Ubuntu19 5.1

按照你说的初步只是获取信息做判断，系统调用够用了，但是还不够好。 上面说的ftrace对应到一个工具systemtap，你可以搜下这块的资料。他几乎能hook内核任意函数，比在syscall层要更精准的多的多。因为Linux一切皆文件，sockfs的操作也是丢到VFS上的。所以数据量还是比较大。如果在udp_recvmsg这个点hook的话，那是不是对于UDP的相关处理就比较精简了很多。

所以这块就是hook方式的选择，系统中断描述表的方式粒度太大，这块在精细点的还有LSM、inline hook 、ftrace的等等。这块就需要考虑下场景来选择了。

对于 “关于稳定性，稳定性的确是最大的问题，但是想做一款性能优秀，信息全面，AntiRootkit，难以被攻击者绕过，响应需求快速，二次开发友好的产品所必须面对的，因为很难有其他的选项。况且目前AgentSmith-HIDS是一款实验性质的，个人的小作品。” 如果想以提供二次开发的方式给别人用的话，我有个建议也是我现在在做的，是不是可以提供基础功能和接口，核心代码不用修改。其他人想要扩展或者定制化，二次开发的时候以插件或者restful api的方式扩展。做出来的东西就相当于一个黑盒之类的。

[EBWi11]

@sam6666666 首先非常感谢您的回复！ 关于ftrace我会学习并仔细考虑下可能性。 关于兼容性，由于测试环境(公司的生产环境)都是centos6/7 64位，因此目前仅打算支持这个Linux Kernel大版本。(老实说再多的我也没有足够的环境来做稳定性和兼容性的测试，不敢贸然尝试)。 关于Hook syscall的问题，在实践中也的确发现了精细程度不够，太粗(比如DNS Query Hook)。 关于用户态Agent的问题，其实一开始是Rust的版本(agent_rust)，但是由于部分想参与进来的小伙伴觉得门槛有点高，因此才开始着手进行Golang版本的Agent开发。因为算是个个人项目，一定的社区支持还是有一定必要的，但是Rust版本的用户态Agent我还是会尽可能的支持维护。 关于您最后讲到的，“支持插件/类似黑盒”的观点我也是非常认可的，目前的方向就是如果想要二次开发，LKM模块不做改动，Demo的用户态Agent也不做过多改动(仅改动如server地址等配置文件)，并且目前Rust版本的用户态Agent是支持“自定义模块”的，即类似于外置函数的方式来实现自己的需求，即可完成和Agent的结合。

[sam6666666]

单一平台那就舒服多了。 ftrace只是一种可能，我觉得最好的还是直接修改内核，编译到内核源码里去。当然这都是理想状态了。实际环境中还是inline hook的方式常用。 关于Agent，如果你考虑的平台单一的话，那其实用哪个倒无所谓了。

其实从上到下来看，Agent只做两个功能，一个收集信息，一个是推送策略。 而内核部分也是两个功能，一个是当作数据源，一个是做控制。

所以很期待你内核部分实现，个人觉得IDS/IPS的核心就在于内核部分，控制的精细程度和数据源数据传输的效率都是关键。

[EBWi11]

@sam6666666 昨晚折腾了下systemTap，感觉贼好用而且方便，仿佛打开了新世界的大门233，还可以插入C code来实现自己的特定的需求，完全可以利用systemTap提高我的稳定性和兼容性～哈哈，总之非常感谢了 : ) 我后面应该会把现在基于hook syscall的实现改成利用systemTap的试一试，主要比较担心的是性能问题

[EBWi11]

@sam6666666 这里我用ftrace改写了一版：ftrace_hook_syscall 但是感觉最关键的稳定性问题还是无法解决，因为为了取得数据还是会不得已在ring0层面做大量的自定义的操作。不过不知道我是不是理解有问题

[sam6666666]

内核做的东西太多就容易出现问题，好的办法就是内核取得元信息然后就丢到应用层，应用层做进一步的解析。这块我觉得可以参考下pfring的思路，内核就只管抓包，抓到包丢到ring里面。至于下一步作啥，待应用层从ring里面取包之后随意操作。

[EBWi11]

@sam6666666 其实最早的时候我们就是用Auditd来做+用户态补充来去实现HIDS的功能的，还有比如用netlink connector等等，但是缺点太多了，比如不支持namespace(不支持docker/k8s)，信息严重不全，只能去proc读取(性能问题/生命周期短的进程链接读不到)，或者比如Auditd拿connect信息没有源端口，和我们的NIDS无法联动，信息filter不灵活导致要么信息过多严重损耗性能要么关键信息拿不到等等等等太多缺陷，所以才萌生了这个项目等想法 :) 所以就当这个项目是个随便写的小玩意吧。

[sam6666666]

看你直播了，直播里面有些问题回避了。 其中两个很重要的问题就是内核多样化的维护和版本升级问题。

[EBWi11]

额，首先直播不是讲AgentSmith-HIDS的，如果您看了也很清楚，只是讲了HIDS可能的发展方向和一些Linux的问题而已。所以我个人认为使用“回避”这个词好像有些不太合适？而且我也没有什么宣扬什么，我只是指出问题，提出我的思考仅此而已。 内核的多样性问题我不打算解决，我不是商业项目，甚至都不算是个正式的项目，全靠我个人兴趣支撑而已，仅仅是一个个人的业余项目，我目前仅打算在centos6/7/8上进行兼容。

[sam6666666]

抱歉用词不太准确，是没提到这个。

[zhaozhongshu]

支持用ftrace，再配合ebpf就更好了