01.neuvector防护平台功能实现设计.md

# neuvector防护平台功能实现设计
> 本篇文章主要讲neuvector大概的设计与实现，功能实现细节可查看后续文章
## 一、整体架构
相关主要业务容器运行结构如下：
主要容器为以下几个：
1. Controller容器负责规则的收集与下发，同时也是restful服务；
2. Enforcer容器负责策略的实现以及数据的采集上报；
3. Manager容器为前端web容器；
4. Scanner容器负责容器扫描等工作；
## 二、功能设计与实现
### 2.1 网络策略学习与防护
#### 学习模式：
对于学习模式下的组（组的定义后续详细介绍），enforcer容器的白名单策略生成步骤如下：
1. 首先进入对应容器的网络命名空间；
2. 基于packet mmap 创建AF_PACKET的socket并绑定容器的网络接口eth0，并且创建对应的环形缓冲区；
3. 循环处理缓冲区中的数据包，解析数据包的源ip、目的ip、应用协议（基于端口号以及负载特征识别）、端口号 ，生成对应的网络连
接规则；
4. 上报对应的网络连接规则，由controller侧生成相应的白名单策略（白名单策略由源ip、目的ip、应用协议、端口号、动作组成，学习时动作默认为allow，用户可添加deny的规则）；
#### 监视模式：
对于监视模式下的组，其与学习模式的区别在于，对于解析后的网络连接不进行白名单规则添加，而是与现有的白名单规则进行比对，如果违反则上报违规报警；
#### 保护模式：
对于保护模式下的组，enforcer的管控实现思路如下：
1.在enforcer容器中创建桥接的veth pair，将被保护容器与主机的veth pair进行拆分，容器与主机的流量通过enforcer容器进行代
理，实现效果图如下：
2.通过TC规则将ip协议的数据包发送给enforcer内部veth pair ，如下效果如下：
3.基于vth-neuv的网络接口的packet mmap进行流量转发，循环处理接收缓冲区中的数据包，对数据包进行解析，符合白名单规则的
数据包通过发送缓冲区进行传输，不符合则阻塞；
>
> 当前保护模式下不对主机、kube-system等命名空间下的容器以及host模式的容器进行管控，只进行告警。
### 2.2 进程策略学习与防护
进程侧实现效果图如下：
#### 学习\监视模式：
在非保护模式下，进程的学习与告警主要依据通过netlink socket实时获取进程启动和退出的事件:
1.创建netLink socket；
2.通过创建netlink的fd对进程的事件进行捕获与更新，主要是4种类型（exec，fork，exit，uidChange）；
3.学习模式下则对捕获的进程信息进行上报，形成对应的进程白名单，监视模式则对比当前白名单规则选择是否告警；
#### 保护模式：
在保护模式下，enforcer对于保护容器的进程管控主要分为两种方式， **一种是基于fanotify实现的通过阻塞进程进行判断是否放行，另一种是基于syscall的形式（syscall.Kill(pid, syscall.SIGKILL)）直接杀死进程，但不会阻塞；**
##### 其中fanotify实现的进程管控实现思路如下：
1.enforcer遍历该节点上保护模式下容器内的进程信息；
2.通过fanotify，将所有的进程相关文件添加fanotify mask掩码；
3.通过Select Poll方式不断轮询对应的fd，并且根据白名单对进程的操作返回拒绝或者允许。
##### 基于syscall的形式的进程管控实现思路如下：
1.对于主机节点以及k8s相关重要组件的容器，enforcer通过netlink对进程行为进行监控；
2.对于违反白名单的进程规则通过调用syscall.Kill(pid, syscall.SIGKILL)的方式进行释放；
**两种方式的对比如下：**
| 使用场景 | 优点 | 缺点 | |
| ---------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
| fanotify实现 | 业务容器，非k8s相关重要组件的容 器pod | 基于阻塞的方式管控进程，可以有 效防止黑名单进程执行 | 当容器或者pod中存在大量进程运行 时，阻塞的方式可能会导致容器中 进程运行速度变低， 所以不适用主 机节点以及进程较多的系统容器； |
| syscall.Kill(pid, syscall.SIGKILL) | 主机节点、kube-system，istio system、cattle-system命名空间下 的部分系统容器pod、切换保护模式 时，对应的进程可执行文件还没有 加上Mask掩码时、 | 基于非阻塞的方式管控进程，不会 影响被管控容器或者pod的进程执行 速度； | 1.当进程执行速度很快或者Enforcer 通道通信过慢时，可能会来不及杀 死对应的黑名单进程； 2.当超过通道容量2048时，后续的 进程处理将被忽略 |
### 2.3 文件策略学习与防护
文件侧实现效果图如下：
**当前对文件层面的学习管控实现思路如下：**
1.默认监视/etc/passwd、/etc/hosts等重要文件的修改,用户也可添加对应组的想要保护的文件目录；
2.enforcer遍历该节点上所有的pod内的相关文件目录；
3.基于fanotify，将对应的文件和文件夹添加fanotify mask掩码（用于表明监听操作的事件）；
4.通过Select Poll方式不断轮询对应的fd，学习模式下层对该文件的相关行为进行学习，监视或者保护模式则根据白名单对文件的操作返回告警或者拒绝。
> 注意事项：如果保护文件过多的话，读取大量文件会导致page cache非常大；
### 优化思路
1.xdp/dpdk 需要客户内核版本比较高
2.iptables规则设置