RASP之困
引言
身为一名小小的安全研究员，在体验过公司部署的安全产品后，深感这些产品在漏洞利用检测、入侵检测方面做的还不够完美，这段时间恰逢年终，笔者也在思考其中之道，所以抛出一些想法，主要针对JAVA应用。
现状
OpenRASP
起初定位上应该是一款”降维“的WAF，通过hook相关类方法进行漏洞检测，检测逻辑串行于业务，且检测逻辑可在JAVA代码中或JS插件中进行修改，拥有灵活的拦截开关。
Elkeid
定位上是一款linux下的HIDS，终端agent拥有驱动、内核、ssh日志、系统进程、敏感目录的检测能力，我们还可以注意到，其实它还配备了JVM等语言的RASP”探针“。其JVMProbe做的事情相对OpenRASP就很简单，hook点只有文件操作、命令执行、类加载、网络连接，并将hook点的线程堆栈信息及入参数据传给agent（异步），由agent传给center，且center可以下发拦截规则，规则为字符串正则，指定hook点的参数匹配拦截。另外，rasp与agent之间的数据通路还没打通，或是说还没有开源，center对agent上传的日志分析检测能力也需要我们自己建设。
鱼与熊掌
OpenRASP拥有丰富的漏洞检测能力，但受限于单机，无法拥有更强的检测能力：
1、检测逻辑是串行于业务的，需要做性能考虑；
2、很多情况下还是“黑名单”检测（如反序列化），检测能力不足；
3、无法对灰色行为监控判断，如命令执行；
4、毕竟与业务耦合，java代码基本无法更新吧？另外我看js插件也没人更新（我们公司）。
定位是入侵检测的Elkedi，其JVMProbe已经把JAVA应用的主干道占住了（不过笔者测试的还是有bypass问题，二开时要注意），单单从理论上来说，攻击者若从应用入侵，后续想要有其他行为，都会触发这些hook点：
1、可对灰色行为进行监控判断：得益于center，我们可以分析这些行为
2、由于其定位问题，所以没有什么漏洞检测能力
起初是想着能不能通过center做到如下几点：
1、更强的检测能力：对高危漏洞不再是“黑名单”式的感知告警，对灰色行为能判断，且另外拥有了历史溯源分析能力；
2、具有生命力的RASP：与业务过于耦合的OpenRASP，在甲方似乎缺少生命力，笔者希望能在动态的攻防中，安全分析人员愿意使用它来提升应用安全。
elkeid的思路下，其向center上发的数据量很小（5000进程100k/s），但大多漏洞是随着业务流量的，笔者的想法下，极有可能造成网络拥堵，这样一来，通过center加强RASP检测能力似乎不可行了。
思路
其实，基于HIDS角度来说，字节Elkeid的hook点基本足够了，攻击者从应用入侵的话，无论如何都无法绕过这些基本的hook点 ，防守方要做的，其实就是做好这些hook点（文件操作、类加载、命令执行）的分析即可。
基于这个角度的话，做深度的漏洞检测似乎就没必要了，毕竟我只要分析好这些hook点就可以很好地发现入侵者了。但仔细想来，这样就一根筋了，毕竟如果一个产品兼具业务漏洞的检测能力与入侵检测能力不更好吗，如果我是甲方，那会十分满意的。
所以，经过一番思考交流后，笔者提出了以下构思，后面也打算进行一番实践：
1、大的架构上还是用Elkeid这套 JVMProbe -> rasp-agent -> agent -> center -> kafaka
2、rasp-agent接收到hook点数据后，尽量先在本地做一些去重操作，然后传到center（解决前文说的灰度数据、黑名单问题），这里认为hook点数据有以下几种
a. 较好去重的：如反序列一类的，根据线程堆栈信息去重即可
b.不好去重的，但数据量很小：主要是命令执行类的，选择直接上传即可（HIDS思路）
c.不好去重的，数据量大，业务类的：如SQL一类的，这个我想着后面引入OpenRASP的检测引擎来检测
d.不需要上传的，直接在本地处理即可：xxe一类的
3、JVMProbe增加动态hook功能，规则增加线程堆栈拦截维度
PS：
当我和同事说到字节的这个RASP HIDS 做好了（目前字节给的还是有bypass），理论上可以让应用入侵者无所遁形时，同事与我都纳闷到，如果真的这么好，为啥没火起来。当然，可能是我们没有实践应用，现在从理论上进行思考，遂得出理所当然的结论。
