docker容器内反弹shell的检测方法和系统与流程

本发明涉及互联网安全技术领域，尤其涉及一种docker容器内反弹shell的检测方法和系统、电子设备以及存储介质。

背景技术：

目前互联网环境下，容器已经渐渐成为主流趋势，针对docker(一种系统容器)容器的攻击也层出不穷。

目前市场上的安全产品中，对于docker容器内的反弹shell(操作系统最外面的一层命令行程序)检测还存在一定的难度，现有的检测方案也存在漏报及误报的情况。一个是无法实时获取bash(由gun(目标是创建一套完全自由的操作系统)开发的shell)进程的启动，另一个是无法得到底层的进程调用，使用hook(钩子函数)方式对系统侵入太高，在实际场景中不太适用。

目前市面上的开源产品ossec(一种入侵检测系统)、以及商业产品hids(基于主机型入侵检测系统)，均不能较好的实现docker容器内攻击的检测，尤其在反弹shell检测这一部分。

技术实现要素：

本发明要解决的技术问题是为了克服现有技术中docker容器内的反弹shell检测效果不好的缺陷，提供一种docker容器内反弹shell的检测方法和系统、电子设备以及存储介质。

本发明是通过下述技术方案来解决上述技术问题：

一种docker容器内反弹shell的检测方法，所述docker容器内反弹shell进程检测的方法包括：

开启内核审计组件服务，所述内核审计组件服务用于记录审计记录；

在所述审计记录中查找shell进程；

判断所述审计记录中是否存在所述shell进程的重定向连接，若是，则确定所述shell进程为反弹shell进程；

判断所述反弹shell进程是否为docker容器内进程，若是，则确定所述反弹shell进程为所述docker容器内反弹shell进程。

优选地，所述docker容器内反弹shell进程检测的方法还包括：

当判断所述审计记录中是否存在所述shell进程的重定向连接的判断结果为否时，判断所述shell进程的父进程是否存在重定向连接，若是，则确定所述shell进程为反弹shell进程。

优选地，所述审计记录记录有docker容器内进程树，所述判断所述反弹shell进程是否为docker容器内进程的步骤包括：

判断所述反弹shell进程是否在所述docker容器内进程树中；

和/或，

确定所述反弹shell进程为所述docker容器内反弹shell进程的步骤之后还包括：

根据所述docker容器内反弹shell进程生成反弹报警事件。

优选地，在所述审计记录中查找shell进程的步骤包括：

在所述审计记录中查找bashshell进程；

所述判断所述审计记录中是否存在所述shell进程的重定向连接的步骤包括：

判断所述审计记录中是否存在所述bashshell进程的重定向连接。

一种docker容器内反弹shell的检测系统，所述docker容器内反弹shell进程检测的系统包括开启模块、查找模块、重定向模块和确定模块；

所述开启模块用于开启内核审计组件服务，所述内核审计组件服务用于记录审计记录；

所述查找模块用于在所述审计记录中查找shell进程；

所述重定向模块用于判断所述审计记录中是否存在所述shell进程的重定向连接，若是，则确定所述shell进程为反弹shell进程；

所述确定模块用于判断所述反弹shell进程是否为docker容器内进程，若是，则确定所述反弹shell进程为所述docker容器内反弹shell进程。

优选地，所述docker容器内反弹shell进程检测系统还包括：

所述重定向模块还用于当判断所述审计记录中是否存在所述shell进程的重定向连接的判断结果为否时，判断所述shell进程的父进程是否存在重定向连接，若是，则确定所述shell进程为反弹shell进程。

优选地，所述审计记录记录有docker容器内进程树，所述确定模块还用于判断所述反弹shell进程是否在所述docker容器内进程树中；

和/或，

所述docker容器内反弹shell进程检测的系统还包括报警模块，所述报警模块用于根据所述docker容器内反弹shell进程生成反弹报警事件。

优选地，所述查找模块还用于在所述审计记录中查找bashshell进程；

所述重定向模块还用于判断所述审计记录中是否存在所述bashshell进程的重定向连接。

一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上所述的docker容器内反弹shell的检测方法。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的docker容器内反弹shell的检测方法的步骤。

本发明的积极进步效果在于：

本发明通过使用aduitd内核审计机制，实现了对系统调用的监控，结合反弹shell攻击过程中获取shell进程和重定向连接这两种行为特征，分析auditd产生的审计记录，成功的覆盖了docker容器内部反弹shell的攻击行为，实现一种更彻底、更准确、更实时的反弹shell检测机制。

附图说明

图1为本发明的实施例1的docker容器内反弹shell的检测方法的流程图。

图2为本发明的实施例2的docker容器内反弹shell的检测系统的模块示意图。

图3为本发明的实施例3提供的一种电子设备的结构示意图。

具体实施方式

下面通过实施例的方式进一步说明本发明，但并不因此将本发明限制在所述的实施例范围之中。

实施例1

本实施例提供一种docker容器内反弹shell的检测方法，如图1所示。docker容器内反弹shell进程检测的方法包括：

步骤11、开启内核审计组件服务，内核审计组件服务用于记录审计记录。

auditd(内核审计组件服务)是linux(一种操作系统)系统中重要的内核审计组件，其负责将审计记录写入磁盘。使用auditd可以实现如下场景的审计监控：

(1)监控文件访问

(2)监控系统调用

(3)记录用户命令执行

(4)记录安全事件

(5)执行审计搜索

(6)统计概要报表

(7)监控网络访问

在本实施例中主要应用了auditd机制的监控系统调用功能和记录用户命令执行功能。

在linux系统中以root(linux系统中的超级管理员用户帐户)身份执行一条auditctl(用于管理用户定义的审计规则)规则，可实现对执行系统命令这一个系统调用行为的监控审计。系统记录到的日志事件将存储在系统上的/var/log/audit/aduit.log日志文件内，即审计记录。

步骤12、在审计记录中查找shell进程。

以shell进程为bashshell(一种命令行外壳)进程为例，其他类型shell进程类似，不再赘述。

在通常情况下，每个进程在开始运行的时刻，都会有3个已经打开的stream(流)，即stdin(标准输入)、stdout(标准输出)、stderr(标准错误输出)，分别用来输入、输出、打印诊断和错误信息，指的就是通常他们会被连接到用户终端，也可以改变到其它文件或设备。反弹shell的最终目的就是让外部设备获取bash控制权，因此反弹shell产生的bash进程通常会重定向到某个外部设备。

以下方式为如何区分正常bash和恶意bash(bashshell进程的重定向连接)：

正常bash：bash进程的stdin\stdout\stderr对应本机的字符设备/dev/pts。

异常bash：bash进程的stdin\stdout\stderr指向一个重定向连接。

反弹shell这一行为的外连建立过程并不一定由bash进程本身来完成，很多时候黑客会通过pipe管道启动bash，把bash进程包装起来由父进程来建立连接，而后所有的操作行由父进程通过pipe管道传递给终端bash。

步骤12包括：在审计记录中查找bashshell进程。

步骤13、判断审计记录中是否存在shell进程的重定向连接，若是，执行步骤14，若否，则执行步骤15。

当shell进程为bashshell进程时，更具体的是判断审计记录中是否存在bashshell进程的重定向连接。

步骤14、确定shell进程为反弹shell进程。

步骤15、判断shell进程的父进程是否存在重定向连接，若是，则执行步骤16。

步骤16、确定shell进程为反弹shell进程。

步骤17、判断反弹shell进程是否为docker容器内进程，若是，则执行步骤18。

步骤18、确定反弹shell进程为docker容器内反弹shell进程。

审计记录中记录有docker容器内进程树，步骤15更具体的是判断反弹shell进程是否在docker容器内进程树中。

docker容器内进程树：一定存在docker-current和docker-containe节点，所以只要判断审计记录中是否存在docker-current和docker-containe节点。

步骤19、根据docker容器内反弹shell进程生成反弹报警事件。

反弹报警事件可用于发送至安全运营中心(soc)，安全运营中心进而对反弹报警事件进行报警提示，以利于管理人员及时处理。

本实施例通过使用aduitd内核审计机制，实现了对系统调用功能和记录用户命令的监控记录，结合反弹shell攻击过程中获取shell进程和重定向连接这两种行为特征，分析auditd产生的审计记录，成功的覆盖了docker容器内部反弹shell的攻击行为，实现一种更彻底、更准确、更实时的反弹shell检测机制。

实施例2

本实施例提供一种docker容器内反弹shell的检测系统，如图2所示，docker容器内反弹shell进程检测的系统包括开启模块21、查找模块22、重定向模块23、确定模块24和报警模块25。

开启模块21用于开启内核审计组件服务，内核审计组件服务用于记录审计记录。

auditd(内核审计组件服务)是linux(一种操作系统)系统中重要的内核审计组件，其负责将审计记录写入磁盘。使用auditd可以实现如下场景的审计监控：

(1)监控文件访问

(2)监控系统调用

(3)记录用户命令执行

(4)记录安全事件

(5)执行审计搜索

(6)统计概要报表

(7)监控网络访问

在本实施例中主要应用了auditd机制的监控系统调用功能和记录用户命令执行功能。

在linux系统中以root(linux系统中的超级管理员用户帐户)身份执行一条auditctl(用于管理用户定义的审计规则)规则，可实现对执行系统命令这一个系统调用行为的监控审计。系统记录到的日志事件将存储在系统上的/var/log/audit/aduit.log日志文件内，即审计记录。

查找模块22用于在审计记录中查找shell进程。

以shell进程为bashshell(一种命令行外壳)进程为例，其他类型shell进程类似，不再赘述。

查找模块22还用于在审计记录中查找bashshell进程；

在通常情况下，每个进程在开始运行的时刻，都会有3个已经打开的stream(流)，即stdin(标准输入)、stdout(标准输出)、stderr(标准错误输出)，分别用来输入、输出、打印诊断和错误信息，指的就是通常他们会被连接到用户终端，也可以改变到其它文件或设备。反弹shell的最终目的就是让外部设备获取bash控制权，因此反弹shell产生的bash进程通常会重定向到某个外部设备。

以下方式为如何区分正常bash和恶意bash(bashshell进程的重定向连接)：

正常bash：bash进程的stdin\stdout\stderr对应本机的字符设备/dev/pts。

异常bash：bash进程的stdin\stdout\stderr指向一个重定向连接。

反弹shell这一行为的外连建立过程并不一定由bash进程本身来完成，很多时候黑客会通过pipe管道启动bash，把bash进程包装起来由父进程来建立连接，而后所有的操作行由父进程通过pipe管道传递给终端bash。

重定向模块23用于判断审计记录中是否存在shell进程的重定向连接，若是，则确定shell进程为反弹shell进程。

当shell进程为bashshell进程时，更具体的是判断审计记录中是否存在bashshell进程的重定向连接。

确定模块24用于判断反弹shell进程是否为docker容器内进程，若是，则确定反弹shell进程为docker容器内反弹shell进程。

重定向模块23还用于当判断审计记录中是否存在shell进程的重定向连接的判断结果为否时，判断shell进程的父进程是否存在重定向连接，若是，则确定shell进程为反弹shell进程。

审计记录记录有docker容器内进程树，确定模块24还用于判断反弹shell进程是否在docker容器内进程树中。

docker容器内进程树：一定存在docker-current和docker-containe节点，所以只要判断审计记录中是否存在docker-current和docker-containe节点。

报警模块25用于根据docker容器内反弹shell进程生成反弹报警事件。

反弹报警事件可用于发送至安全运营中心(soc)，安全运营中心进而对反弹报警事件进行报警提示，以利于管理人员及时处理。

本实施例通过使用aduitd内核审计机制，实现了对系统调用功能和记录用户命令的监控记录，结合反弹shell攻击过程中获取shell进程和重定向连接这两种行为特征，分析auditd产生的审计记录，成功的覆盖了docker容器内部反弹shell的攻击行为，实现一种更彻底、更准确、更实时的反弹shell检测机制。

实施例3

图3为本发明实施例3提供的一种电子设备的结构示意图。电子设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时实现实施例1的弹幕的加载方法。图3显示的电子设备30仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图3所示，电子设备30可以以通用计算设备的形式表现，例如其可以为服务器设备。电子设备30的组件可以包括但不限于：上述至少一个处理器31、上述至少一个存储器32、连接不同系统组件(包括存储器32和处理器31)的总线33。

总线33包括数据总线、地址总线和控制总线。

存储器32可以包括易失性存储器，例如随机存取存储器(ram)321和/或高速缓存存储器322，还可以进一步包括只读存储器(rom)323。

存储器32还可以包括具有一组(至少一个)程序模块324的程序/实用工具325，这样的程序模块324包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

处理器31通过运行存储在存储器32中的计算机程序，从而执行各种功能应用以及数据处理，例如本发明实施例1所提供的docker容器内反弹shell的检测方法。

电子设备30也可以与一个或多个外部设备34(例如键盘、指向设备等)通信。这种通信可以通过输入/输出(i/o)接口35进行。并且，模型生成的设备30还可以通过网络适配器36与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器36通过总线33与模型生成的设备30的其它模块通信。应当明白，尽管图中未示出，可以结合模型生成的设备30使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理器、外部磁盘驱动阵列、raid(磁盘阵列)系统、磁带驱动器以及数据备份存储系统等。

应当注意，尽管在上文详细描述中提及了电子设备的若干单元/模块或子单元/模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之，上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。

实施例4

本实施例提供了一种计算机可读存储介质，其上存储有计算机程序，程序被处理器执行时实现实施例1所提供的docker容器内反弹shell的检测方法的步骤。

其中，可读存储介质可以采用的更具体可以包括但不限于：便携式盘、硬盘、随机存取存储器、只读存储器、可擦拭可编程只读存储器、光存储器件、磁存储器件或上述的任意合适的组合。

在可能的实施方式中，本发明还可以实现为一种程序产品的形式，其包括程序代码，当程序产品在终端设备上运行时，程序代码用于使终端设备执行实现实施例1的docker容器内反弹shell的检测方法中的步骤。

其中，可以以一种或多种程序设计语言的任意组合来编写用于执行本发明的程序代码，程序代码可以完全地在用户设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户设备上部分在远程设备上执行或完全在远程设备上执行。

虽然以上描述了本发明的具体实施方式，但是本领域的技术人员应当理解，这仅是举例说明，本发明的保护范围是由所附权利要求书限定的。本领域的技术人员在不背离本发明的原理和实质的前提下，可以对这些实施方式做出多种变更或修改，但这些变更和修改均落入本发明的保护范围。