阅读字数：1699 | 6分钟阅读
https://v.qq.com/x/page/t05573lwe73.html
入侵检测主要分为海量数据的实时获取和实时分析两方面。
海量数据的实时获取主要的思路是通过在操作系统上放一个安全agent，频繁地进行扫描以获取进程执行信息或者是网络连接信息。但这种思路会面临几个问题。
第一个是存在死角。因为考虑到性能开销和对业务性能的影响，所以不可能一直扫描，还是存在间断。有一些执行时间比较短的进程或网络连接的信息扫描不到。这就存在监控死角留下安全隐患。
第二个问题是性能开销。现在的安全agent在扫描的时候还是会对一些业务造成影响，有时就会收到业务的投诉。只能把投诉的业务加入白名单，以后就不扫描这个业务了。但这样是存在安全隐患的。
第三个问题是如何适应越来越复杂的业务环境。最早的时候，所有业务都是位于物理机上，后来云计算兴起，引入了服务器虚拟化。每一个虚拟机上放一个agent。近几年虚拟化大火，docker在我们公司内部平台用得比较多，它的使用模式是比较复杂的。有些docker子集是有独立IP的，有些则没有。容器虚拟化可能是一个轻量级的虚拟化，一台物理机上有可能运行非常多的docker子集。每个docker子集里放一个安全agent，这些安全agent都在进行扫描，性能开销是非常大的。
当前入侵检测的海量实时获取面临的这些问题，我们的解决思路是从操作系统层面建立一个入侵监控信息获取框架。
新的入侵检测框架
基本思路很简单，从操作系统层面的入侵信息获取支持和相关信息，然后把这些信息传送给安全那边的数据模块。
它的子进程的好处首先是全面无死角，其次是得到了操作系统层面的支持，业务环境适应性好。
面临挑战有性能开销和海量现网业务的支持。对于现网业务来说，部分开放内核模块支持，部分不开放内核模块支持。
技术路线
技术路线分为两条，一条是内核热补丁，针对有内核模块支持系统。另一条是C库劫持和进程热补丁，针对无内核模块支持系统。
技术路线一：内核&内核热补丁（1）整体架构
技术路线一：内核&内核热补丁（2）
考虑到内核热补丁这块，ftrace的好处在于它可以动态地在指定函数上添加需要的钩子函数。但是对我们来说，ftrace仅仅是在工作开头能添加钩子函数，对我们来说是不够的。
Kpatch是基于ftrace的框架来实现的。每做一次新旧函数的替换都会执行到ftrace一系列的框架代码，包含了几百条指令。对于一些调用非常频繁的场景下，性能开销是非常高的。
我们自己写了tpatch内核热补丁的框架，它相对于Kpatch来说更加简化。
技术路线一：内核&内核热补丁（3）
通过以上方法我们解决了数据获取的问题，之后要把数据传送给数据分析模块。直接的思路就是开辟一片数据缓冲区，读者和写者通过数据缓冲区进行数据的传送。
这里面临的问题是缓冲区不能加锁，一旦加锁，性能开销就非常大。在五个性能并行，对一个个缓冲区进行操作的情况下，因为锁竞争导致的CPU性能开销就在百分之十以上。这个开销太大业务不能忍受，所以数据的缓冲区必须是无锁的。
这个缓冲区可能的锁竞争主要来源于三个方面，第一是写者方面的竞争，第二读者之间的竞争，第三是写者与读者之间的竞争。我们用一个缓冲区只面向一个读者就可以解决读者间的竞争问题。写者的竞争在内核里面用per-cpu的数据结构以解决这个问题。读者与写者间的竞争可以利用一个经典的数据结构ringbuffer来消除。
技术路线一：内核&内核热补丁（4）热补丁性能优化
技术路线一：内核&内核热补丁（5）
在性能开销方面的优化，引用计数优化，开销降低3%。代码优化，开销降低了2%。
技术路线二：C库劫持&进程热补丁（2）进程热补丁
操作系统安全增强未来展望
身份认证：内核签名、模块签名和进程签名。
访问控制：取消root的完全权限，权限细分，关键数据访问受限。
密钥管理：密钥分发和管理框架与操作系统紧密结合，密钥由内核管理并据此进行相关认证，应用层接触不到私钥。
