一种基于Docker容器的防逃逸蜜罐系统及其方法与流程

本申请涉及基于docker容器的蜜罐系统的技术领域，尤其涉及一种基于docker容器的防逃逸蜜罐系统及其方法。

背景技术：

随着网络高速的发展，网络中的资源也在成倍的增加，如何提高暴露在网络中资源的安全性，是目前急需解决的问题。目前的网络攻击可分为已知类型攻击和未知类型攻击，已知类型攻击我们已经得知其特征，因此可以针对其特征采用防火墙、ips等设备使用特定策略匹配网络流量进行防护，但未知攻击由于具备未知特征，很难被识别，当遇到未知类型攻击时，网络资源将会面临很大的安全风险。因此，只有能够捕捉到攻击方的更多的特征，才能够更多的对其进行识别和抵御。

为诱使攻击方暴露更多的特征，目前常用的是蜜罐类平台产品，其中，蜜罐技术本质上是一种对攻击方进行欺骗的技术，通过布置一些作为诱饵的主机、网络服务或者信息，诱使攻击方实施攻击，从而可以对攻击行为进行捕获和分析，了解攻击方所使用的工具与方法，推测攻击意图和动机，能够让防御方清晰地了解他们所面对的安全威胁，增强实际系统的安全防护能力。

由于蜜罐本身也有被攻破利用的风险，因此目前通常使用的蜜罐是伪系统蜜罐，伪系统蜜罐是在真实系统下设置的一个伪系统，伪系统实际上只是一个程序框架，入侵伪系统后的攻击方只是在一个程序框架里进行操作，不会进入真实的系统内核，伪系统的建立比较容易，通过一些虚拟机程序就可以进行建立，但如果同时建立多个系统，会给主机本身带来很大的消耗，造成系统的不稳定，而随着docker容器技术的出现，由于docker容器的负载很小、启动快速，相互之间隔离性也很强，因此选择采用docker容器蜜罐来进行对攻击特征的捕捉和监控，这样我们可以在同一台设备上运行多个蜜罐进程，每个蜜罐占用的空间较小并能够分别限制在蜜罐自己的环境中运行。

docker容器本质是系统中的一个进程，运行在其中的应用都像是在独立的操作系统中运行一样，docker容器拥有单独命名空间，使用docker容器作为蜜罐保证了蜜罐之间彼此互不影响，拥有单独命名空间的蜜罐与其他的进程共享同一个内核。

而为了增加蜜罐的甜度，引诱攻击方做出动作，蜜罐本身也会自带一些已知或者未知漏洞，这样也就增加了被逃逸的风险。为了解决这个问题，申请号为cn201710083412.x《基于docker容器的移动端双系统实现系统及方法》的专利文件中公开了一种方案，提出了使用lsm在内核里面实现安全模块(对一个模块的操作或者对一个网络的管理)方式，对docker容器所产生的系统调用进行限制的方法，然而这个方案虽然能够降低系统内核被不安全行为攻击的可能性，但是需要对linux内核进行开发定制，每添加一个新的lsm功能，就需要重新对内核进行编译，对内核的多次编译会降低系统的稳定性，甚至可能随时会引入让内核崩溃的bug，也增加了开发的流程。

另外，类似的方法还可以使用安全增强型linux(security-enhancedlinux)简称selinux，selinux是linux的一个安全子系统，其中，审计策略由安全服务器通过一个具有特权的用户空间接口载入内核，selinux在内核中以lsm模块的形式实现，selinux使用lsm钩子控制对内核资源的访问，访问决定由selinux安全服务器产生，然而selinux策略一般都非常大并且复杂，给加载和编译都带来很大负担，且必须使用特定的接口和模块，在操作上非常繁琐且复杂。

因此，我们需要一种既能够使蜜罐的甜度足够，促使攻击方暴露出更多动作，又能够保证系统的安全性以及自身稳定性，并且操作方便，防逃逸性更高的方案。

技术实现要素：

为了解决docker容器逃逸问题，防止攻击者逃逸容器对宿主机实现破坏，并记录攻击者行为，优化审计进程的流程的问题；本申请提供一种docker容器蜜罐防逃逸系统，包括系统平台和作为蜜罐的docker容器，以及审计模块；

所述docker容器在系统平台宿主机的挂载目录为upperdir目录，所述docker容器以树形结构存储其内部的初始进程及子进程的pid；

所述审计模块包括设置在系统平台内核空间的lsm模块和接口设置在系统平台用户空间的bpf模块；所述lsm模块包括安全模块，所述安全模块用于对进入内核空间的进程进行审计；所述bpf模块用于从用户空间将审计策略加载到内核空间的安全模块上。

本申请还提供一种如权利要求1所述的docker容器蜜罐防逃逸系统的防逃逸方法，其步骤为：

s1，遍历宿主机的所有docker容器，获取docker容器的初始进程pid，根据docker容器的元数据记录获得容器的upperdir值；使用树状结构对初始进程及其子进程的pid进行存储；

s2，在用户空间将审计策略以代码形式通过bpf嵌入lsm，使审计策略能够以lsm框架内的安全模块的形式加载到内核中；所述审计策略包括对蜜罐容器upperdir目录下文件的监听；

s3，通过upperdir目录和树状存储结构，能够为进入内核空间的进程找到其对应的初始进程pid，使用lsm安全模块中的审计策略，根据进程的pid判断其是否为蜜罐容器中的进程；当该进程为蜜罐容器中的进程时，进行下一步审计步骤s3；当该进程不是蜜罐容器中的进程时，放弃对该进程的审计；

s4，对蜜罐容器内进程进行审计，审计通过则可以继续执行指令，审计不通过则拒绝访问。

其中，在蜜罐容器启动后，容器内建立的进程都是由初始进程fork出的子进程，都继承了初始进程的部分内容。

蜜罐容器启动后，容器的初始进程在容器内部显示的pid与在宿主机的pid不同，初始进程在宿主机的pid为宿主机动态分配的pid号，容器启动后所有的进程都能够以树状结构进行存储，通过树状存储，能够通过其中任一进程找到初始进程。

其中，在步骤s4中，对蜜罐容器内进程的审计策略包括对不同安全级别的docker容器的进程在内核中执行指令时的处理方式：当高安全级别的docker容器执行内核进程时，拒绝其操作；当中安全级别的docker容器执行内核进程时，允许通过，同时继续监测，形成日志；当低安全级别的docker容器执行内核进程时，允许其操作，形成日志审计策略能够执行监听docker容器内进程。

其中，在步骤s3中，bpf通过load加载到lsmhook函数security_task_create、inode_link，使审计策略以lsm框架内的安全模块的形式加载到内核中。

本申请还提供一种基于docker容器的进程审计方法，步骤包括：

s21，应用程序的进程进行系统调用，查找到内核中对应的inode节点；对进程进行错误检查和dac检查；

s22，调用lsm框架内的安全模块代表的审计策略对该进程进行审计，进程如果通过审计后则继续进行对inode节点的访问，如果不能通过审计，则无法继续执行命令；

其中，所述安全模块内的审计策略由bpf由从用户空间加载到内核中。

本申请实现的有益效果如下：

在不修改linux内核的前提下动态从内核注入lsm策略到内核，并保证lsm策略运行崩溃后不会对内核造成影响。

如果在linux里使用lsm会使得到处都是权限审计，而docker容器由于使用联合文件系统，而进程的id号是系统内唯一的，因此可以对容器内部进程的生命周期进行动态跟踪。结合docker联合文件系统特点高效审计容器内部发生的对文件的操作，用户空间中对用户操作没有任何限制，可以给攻击方很多用户权限，让攻击方暴露出足够多的特征，在内核底层执行操作时才进行审计；这就避免了攻击方刚进入就发现权限被限制发生逃逸。

结合bpf特性动态插入lsm策略到内核对容器行为进行审计，可以完整的审计容器内部所有行为，整个审计过程没有系统调用发生，可以高效的运行，如果审计程序发生异常也不会导致内核崩溃，本申请使用侵入性最小的方式对容器内部行为进行审计。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域技术人员来讲，还可以根据这些附图获得其他的附图。

图1为一个docker容器内以树形结构存储的所有进程pid的结构图。

图2为审计策略通过bpf调用加载到内核中的流程图。

图3为进程经由bpf加载到lsm内的安全模块进行审计的流程图。

具体实施方式

下面结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

操作系统中的状态分为管态(内核态)和目态(用户态)，用户程序只在用户态下运行，当程序需要访问系统核心功能或要执行核心指令比如修改基址寄存器内容时，就必须在内核态下进行。由用户态向内核态切换的方式一般是通过系统调用接口使用系统调用(systemcall)。系统调用规定了用户进程进入内核的具体位置，系统调用是用户进程进入内核的接口层，它本身并非内核函数，但它是由内核函数实现，进入内核后，不同的系统调用会找到各自对应的内核函数，这些内核函数被称为系统调用的“服务例程”。系统调用把应用程序的请求传给内核，调用相应的内核函数完成所需的处理，将处理结果返回给应用程序。也就是说多数的进程执行的过程是由用户态通过系统调用进入内核态，再返回到用户态的过程。

lsm是linuxsecritymodule的简称，即linux安全模块，是一种轻量级通用访问控制框架，适合于多种访问控制模型，可以根据自己的审计策略需求选择的安全模块加载到内核上，lsm框架只是提供一个支持安全模块的接口，本身不能增强系统安全性，因此如果要实现审计策略，则需要加载相应的安全模块，才能实现其审计功能。

bpf(berkeleypacketfilter，伯克利包过滤器)，最初用于过滤网络数据包。从linux3.18版本开始，linux内核提供了一种扩展的bpf虚拟机，称为extendedbpf，简称ebpf，它能够被用于非网络相关的功能，能够向用户空间提供一个向内核注入可执行代码的公共接口。bpf使用clang+llvm方式编译用户态程序，并使用bpf系统调用将编译内容加载到内核，最后使用bpf系统调用绑定加载到内核的bpf程序到指定的内核hook函数。

在linux5.7版本内核提供了lsm的bpf接口，能够实现通过bpf调用lsm接口。

ebpf由执行字节码指令、存储对象和帮助函数组成，字节码指令在内核执行前须通过bpf验证器的验证，同时在启用bpfjit模式的内核中，会直接将字节码指令转成内核可执行的本地指令运行。ebpf具有独立的寄存器，提供单独的虚拟机环境，因此在bpf虚拟环境中运行的指令在不会对系统造成影响，具有安全性，可避免bpf程序崩溃导致内核崩溃的问题。

docker容器技术使用联合文件系统(unionfs)，联合文件系统(unionfilesystem)也叫unionfs，最主要的功能是将多个不同位置的目录(这些目录被称为layer)联合挂载(unionmount)到同一个目录下。

docker所用到的overlayfs，就是联合文件系统中的一种，在overlayfs中，由于docker容器是在基础的docker镜像层上增加了容器层，因此可以看做是docker容器的基础镜像文件放置在下层的镜像层目录lowerdir中，容器运行后的文件更改体现在上层容器层目录upperdir中。

因此，docker容器运行时会在对应宿主机上产生挂载文件目录，也就是容器层目录upperdir，当upperdir目录中产生变化，当文件被创建、删除、权限发生变化时，都会在upperdir目录中有新文件出现。

每个docker容器pid命名空间内的进程pid是唯一的，容器内进程在宿主机系统中会有有两个pid号，一个是这个进程在其容器命名空间的pid号，一个是这个进程在宿主机系统中的pid号，docker容器的初始进程类似linux系统启动时的init进程，会在docker容器pid命名间内的pid被设置为1，初始进程在宿主机的pid为宿主机动态分配的pid号；

在蜜罐容器启动后，由于docker容器内建立的每个新进程都是直接或者间接由初始进程fork出的子进程，都继承了初始进程的部分内容，因此每个docker容器的pid都能够以树形结构存储。每当有新进程建立时，将新进程的pid作为初始进程的子节点加入树状存储结构；

根据docker容器的元数据记录的docker容器的联合文件系统在宿主机上存放的目录能够得到docker容器的upperdir。

在蜜罐容器启动时，记录初始进程的pid以及容器的upperdir值；

通过上述原理，本申请提供一种基于docker容器的防逃逸蜜罐系统，包括系统平台和作为蜜罐的docker容器，以及审计模块；

所述docker容器在系统平台宿主机的挂载目录为upperdir目录，所述docker容器以树形结构存储其内部的初始进程及子进程的pid；

所述审计模块包括设置在系统平台内核空间的lsm模块和接口设置在系统平台用户空间的bpf模块；所述lsm模块包括安全模块，所述安全模块用于对进入内核空间的进程进行审计；所述bpf模块用于从用户空间将审计策略加载到内核空间的安全模块上。

基于上述系统，本申请还提供一种防逃逸方法：

s1，遍历宿主机的所有docker容器，获取所有docker容器的初始进程pid；

s2，建立审计策略：首先，根据进程的pid判断其是否为蜜罐容器中的进程；当该进程为蜜罐容器中的进程时，进行下一步审计步骤s3；当该进程不是蜜罐容器中的进程时，放弃对该进程的审计；

如图1所示，蜜罐容器启动后，容器的初始进程在容器内部显示为1号进程，当容器内的初始进程fork出子进程2和3后，将2和3作为树状结构的第一阶梯分支进行储存，之后进程3又fork出子进程4、5、8，进程2fork出子进程7，以上2-8进程都直接或者间接的继承了初始进程1的部分内容，容器启动后所有的进程都能够以树状结构进行存储，通过树状存储结构，能够通过容器内的任一进程找到其对应的初始进程。

s3，蜜罐容器内进程的审计策略包括对不同安全级别的docker容器的进程在内核中执行指令时的处理方式：比如，当高安全级别的docker容器执行内核进程时，拒绝其操作；当中安全级别的docker容器执行内核进程时，允许通过，同时继续监测，形成日志；当低安全级别的docker容器执行内核进程时，允许其操作，形成日志审计策略能够执行监听docker容器内进程。

s4，将审计策略以代码形式，通过load加载到lsmhook函数，如security_task_create、inode_link等，使审计策略以lsm框架内的安全模块的形式加载到内核中。

如图2所示，lsmprog是加载内核的审计策略代码，通过bpf系统调用，通过load和attach的加载，进入内核空间kernel，挂载到系统钩子挂载点中的lsm的hookpoine(钩子挂载点)的，之后再进行的系统调用(systemcall)都会被lsmhook审计。

因此，本申请还提供一种基于docker容器的流程审计流程为：

如图3所示，进程进行系统调用时，系统调用查找到内核中对应的inode节点(硬盘文件的索引节点)，对进程进行错误检查和dac检查；

调用lsm框架内的安全模块代表的审计策略对该进程进行审计，进程如果通过审计后则继续进行对inode节点的访问，如果不能通过审计，则进程不能继续执行命令；

其中所述安全模块内的审计策略由bpf由从用户空间加载到内核中。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。