容器的入侵检测方法、装置、电子设备及存储介质

摘要

本申请公开一种容器的入侵检测方法、装置、电子设备及存储介质，该方法包括：获取宿主机上进程与各容器内进程的映射关系表征数据，根据映射关系表征数据，确定宿主机上与各容器内进程具有映射关系的进程，从宿主机上与各容器内进程具有映射关系的进程中，筛选与各容器内有对外开放监听端口的进程具有映射关系的进程，根据与各容器内有对外开放监听端口的进程具有映射关系的进程，确定审计进程，进而监测每个审计进程的行为数据，根据监测到的行为数据确定该审计进程是否入侵对应容器。这样，仅对确定的审计进程进行行为监测，监测数据和分析数据都大幅减少，因此，能够节省系统资源。另外，入侵检测的实时性和追溯性也都比较好。

说明书

技术领域

本申请涉及网络安全技术领域，尤其涉及容器的入侵检测方法、装置、电子设备及存储介质。

背景技术

容器技术可以把应用的运行环境和程序打包在一起，消除编译、打包与部署、运维之间的鸿沟，提高应用开发效率。然而，容器生命周期中存在诸多安全问题，因此，对容器进行入侵检测成为一种通用需求。

相关技术中，采用文件扫描、日志监控等技术对容器进行入侵检测，这些技术需要在已扫描大量文件和已产生大量日志的前提下，通过制定一系列过滤规则来发现进程对容器的入侵行为，实际上进行了很多冗余的扫描操作和日志捕获操作，比较浪费系统资源，并且，这种入侵检测方式属于事后检测，实时性比较低。

发明内容

本申请实施例提供容器的入侵检测方法、装置、电子设备及存储介质，用以解决现有技术中的容器检测技术存在的浪费系统资源、实时性比较低的问题。

第一方面，本申请实施例提供一种容器的入侵检测方法，包括：

获取宿主机上进程与各容器内进程的映射关系表征数据；

根据所述映射关系表征数据，确定所述宿主机上与各容器内进程具有映射关系的进程；

从所述宿主机上与各容器内进程具有映射关系的进程中，筛选与各容器内有对外开放监听端口的进程具有映射关系的进程；

根据与各容器内有对外开放监听端口的进程具有映射关系的进程，确定审计进程；

监测每个所述审计进程的行为数据，根据所述行为数据确定所述审计进程是否入侵对应容器。

在一种可能的实施方式中，从所述宿主机上与各容器内进程具有映射关系的进程中，筛选与各容器内有对外开放监听端口的进程具有映射关系的进程，包括：

对所述宿主机上与任一容器内进程具有映射关系的每个进程，获取所述进程当前打开的套接字文件描述符的文件标识，并从所述进程的网络连接文件中获取所述容器内目标端口的监听信息，所述目标端口是指所述容器内与所述宿主机上的监听端口具有映射关系的监听端口；

根据所述容器内目标端口的监听信息和所述进程当前打开的套接字文件描述符的文件标识，确定所述进程是否是与所述容器内有对外开放监听端口的进程具有映射关系的进程。

在一种可能的实施方式中，获取所述进程当前打开的套接字文件描述符的文件标识，包括：

从所述进程当前打开的所有文件描述符中筛选套接字文件描述符；

获取筛选出的套接字文件描述符的文件标识。

在一种可能的实施方式中，根据所述容器内目标端口的监听信息和所述进程当前打开的套接字文件描述符的文件标识，确定所述进程是否是与所述容器内有对外开放监听端口的进程具有映射关系的进程，包括：

若确定所述容器内任一目标端口的监听信息表示所述目标端口处于被监听状态，则获取所述目标端口对应的套接字文件描述符的文件标识；

若确定获取的文件标识与所述进程当前打开的任一套接字文件描述符的文件标识相同，则确定所述进程是与所述容器内有对外开放监听端口的进程具有映射关系的进程。

在一种可能的实施方式中，所述映射关系表征数据是所述宿主机上各进程的控制组文件，根据所述映射关系表征数据，确定所述宿主机上与各容器内进程具有映射关系的进程，包括：

遍历所述宿主机上每个进程的控制组文件；

若确定所述控制组文件中包含表示容器的关键字，则获取所述控制组文件中的容器标识；

确定所述控制组文件对应的进程是所述宿主机上与所述容器标识对应的容器内进程具有映射关系的进程。

在一种可能的实施方式中，所述映射关系表征数据是所述宿主机上容器编排工具的容器配置信息，根据所述映射关系表征数据，确定所述宿主机上与各容器内进程具有映射关系的进程，包括：

根据所述容器配置信息，确定所述宿主机上内部监听端口与服务的对外开放端口之间有映射关系的至少一个容器，所述服务的对外开放端口与所述宿主机上的端口具有映射关系；

确定所述宿主机上与所述至少一个容器内进程具有映射关系的进程。

在一种可能的实施方式中，确定所述宿主机上与所述至少一个容器内进程具有映射关系的进程，包括：

对所述至少一个容器中的每个容器，在所述宿主机上查找所述容器的初始进程；

将所述初始进程的各子进程中启动命令与所述容器中指定进程的启动命令一致的子进程，确定为所述宿主机上与所述容器内指定进程具有映射关系的进程。

在一种可能的实施方式中，还包括：

在确定任一进程不是与对应容器内有对外开放监听端口的进程具有映射关系的进程之后，在所述进程的各子进程中，确定与所述容器内有对外开放监听端口的进程具有映射关系的子进程，将确定的所述子进程作为审计进程。

在一种可能的实施方式中，根据与各容器内有对外开放监听端口的进程具有映射关系的进程，确定审计进程，包括：

将与各容器内有对外开放监听端口的进程具有映射关系的进程和所述进程的子进程，均确定为审计进程。

在一种可能的实施方式中，监测每个所述审计进程的行为数据，包括：

实时获取宿主机上所有进程的进程事件；

从获取的所有进程的进程事件中筛选出每个所述审计进程的进程事件，并监测每个所述审计进程的行为数据。

第二方面，本申请实施例提供一种电子设备，包括：至少一个处理器，以及与所述至少一个处理器通信连接的存储器，其中：

存储器存储有可被至少一个处理器执行的指令，该指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述容器的入侵检测方法。

第三方面，本申请实施例提供一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，所述电子设备能够执行上述容器的入侵检测方法。

本申请实施例中，获取宿主机上进程与各容器内进程的映射关系表征数据，根据映射关系表征数据，确定宿主机上与各容器内进程具有映射关系的进程，之后，从宿主机上与各容器内进程具有映射关系的进程中，筛选与各容器内有对外开放监听端口的进程具有映射关系的进程，根据与各容器内有对外开放监听端口的进程具有映射关系的进程，确定审计进程，进而监测每个确定的审计进程的行为数据，根据监测到的行为数据确定该审计进程是否入侵对应容器。这样，筛选宿主机上与各容器内有对外开放监听端口的进程具有映射关系的进程，基于这些进程确定审计进程，仅对确定出来的审计进程进行行为监测，监测数据和分析数据都大幅减少，因此能够节省系统资源。并且，该方案监测每个确定出来的审计进程的行为数据，可以发现容器内即将或正在实施入侵行为的进程，出现入侵行为后也可以根据该进程的信息快速追溯到出现问题的进程，入侵检测的实时性和追溯性都比较好。另外，由于容器进程命名空间的隔离性，一般从宿主机上无法直接获取到容器内的进程信息，本方案利用宿主机上进程与容器内进程的映射关系，通过监测宿主机上与容器内的进程具有映射关系的审计进程，实现在宿主机上即可对容器内的进程进行入侵监测，不影响容器内业务的运行，对容器内的业务的入侵性也比较小，同时，在宿主机上实现对容器内的进程进行审计，运行于用户态，无需编译底层内核模块，对系统性能影响较小。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的一种容器的入侵检测方法的流程图；

图2为本申请实施例提供的一种确定宿主机上与至少一个容器内进程具有映射关系的进程的方法流程图；

图3为本申请实施例提供的一种筛选与各容器内有对外开放监听端口的进程具有映射关系的进程的方法流程图；

图4为本申请实施例提供的又一种容器的入侵检测方法的流程图；

图5为本申请实施例提供的又一种容器的入侵检测方法的流程图；

图6为本申请实施例提供的一种ip—>service—>pod—>container的层级映射关系示意图；

图7为本申请实施例提供的一种容器的入侵检测装置的结构示意图；

图8为本申请实施例提供的一种用于实现容器的入侵检测方法的电子设备的硬件结构示意图。

具体实施方式

为了解决现有技术中的容器检测技术存在的浪费系统资源的问题，本申请实施例提供了一种容器的入侵检测方法、装置、电子设备及存储介质。

以下结合说明书附图对本申请的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本申请，并不用于限定本申请，并且在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

为了便于理解本申请，本申请涉及的技术术语中：

容器(container)，一种将软件打包成标准化单元，以用于开发、交付和部署的技术。一般地，容器内的进程和宿主机上的进程之间有映射关系，但由于容器进程命名空间的隔离性，目前技术无法从宿主机上直接获取到容器内进程的相关信息。另外，如果一个容器内的进程启用了该容器内的监听端口、且对外提供业务，则该进程就是该容器内有对外开放监听端口的进程。

docker，一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何linux设备上，也可以实现虚拟化。

kubernetes，一个用于容器集群的自动化部署、扩容以及运维的开源平台。

相关技术中，采用文件扫描、日志监控等技术对容器进行入侵检测，这些技术需要在已扫描大量文件和已产生大量日志的前提下，通过制定一系列过滤规则来发现进程对容器的入侵行为，实际上进行了很多冗余的扫描操作和日志捕获操作，比较浪费系统资源，并且，这种入侵检测方式属于事后检测，实时性比较低。

考虑到互联网中对外开放业务相较于其它业务受到攻击的概率更大，为了能够有针对性地进行监测，本申请实施例从容器对外开放的业务出发，仅监测与容器内有对外开放监听端口的进程具有映射关系的宿主机上的进程的行为数据，或，监测与容器内有对外开放监听端口的进程具有映射关系的宿主机上的进程及其子进程的行为数据，以降低容器入侵监测时的系统资源开销，并提升入侵检测的实时性和追溯性。

图1为本申请实施例提供的一种容器的入侵检测方法的流程图，包括以下步骤：

S101：获取宿主机上进程与各容器内进程的映射关系表征数据。

实际应用中，当容器开发工具或容器编排工具不同时，宿主机上进程与各容器内进程的映射关系表征数据的表现形式也会有所不同。

比如，当容器开发工具是docker时，映射关系表征数据可以是宿主机上各进程的控制组文件(cgroup文件)；再比如，当容器编排工具是kubernetes时，映射关系表征数据可以是宿主机上kubernetes的容器配置信息。

S102：根据映射关系表征数据，确定宿主机上与各容器内进程具有映射关系的进程。

在一些可能的实施方式中，映射关系表征数据是宿主机上各进程的控制组文件，可以遍历宿主机上每个进程的控制组文件，若确定控制组文件中包含表示容器的关键字，则可获取控制组文件中的容器标识，进而确定控制组文件对应的进程是宿主机上与容器标识对应的容器内进程具有映射关系的进程。

在一些可能的实施方式中，映射关系表征数据是宿主机上容器编排工具的容器配置信息，此时，可以根据容器配置信息，确定宿主机上内部监听端口与服务的对外开放端口之间有映射关系的至少一个容器，进而确定宿主机上与这至少一个容器内进程具有映射关系的进程，其中，服务的对外开放端口与宿主机上的端口具有映射关系。

在一实施例中，可按照图2所示的流程确定宿主机上与这至少一个容器内进程具有映射关系的进程，该流程包括以下步骤：

S201a：对这至少一个容器中的每个容器，在宿主机上查找该容器的初始进程。

假设初始进程为containerd-shim进程，则对这至少一个容器中的每个容器，可根据该容器的容器id，在当前集群节点上查找进程参数包含该容器id的containerd-shim进程。

S202a：将初始进程的各子进程中启动命令与容器中指定进程的启动命令一致的子进程，确定为宿主机上与容器内指定进程具有映射关系的进程。

具体实施时，可获取containerd-shim进程的子进程，验证子进程的启动指令是否与相应container内指定进程的启动指令一致，若一致，则判定当前进程为容器内指定进程在宿主机上映射的进程，获取其pid(进程号)；若不一致，可再获取当前进程的子级进程进行验证。其中，每个容器中指定进程的启动命令会包含在容器配置信息中，并且，指定进程一般是容器内启动的首个服务进程。

需要说明的是，containerd-shim进程是容器内首个启动的进程，但containerd-shim进程一般不提供业务服务，所以containerd-shim进程并不是容器内启动的首个服务进程，即指定进程不会是containerd-shim进程。

S103：从宿主机上与各容器内进程具有映射关系的进程中，筛选与各容器内有对外开放监听端口的进程具有映射关系的进程。

具体实施时，可以根据图3所示的流程筛选与各容器内有对外开放监听端口的进程具有映射关系的进程，该流程包括以下步骤：

S301a：对宿主机上与任一容器内进程具有映射关系的每个进程，获取该进程当前打开的套接字文件描述符的文件标识。

实际应用中，可以从该进程当前打开的所有文件描述符中筛选套接字(socket)文件描述符，然后，获取筛选出的套接字文件描述符的文件标识比如inode。

S302a：从该进程的网络连接文件中获取该容器内目标端口的监听信息，其中，目标端口是指该容器内与宿主机上的监听端口具有映射关系的监听端口。

其中，该进程的网络连接文件如tcp文件、tcp6文件、udp文件等。

S303a：根据该容器内目标端口的监听信息和进程当前打开的套接字文件描述符的文件标识，确定该进程是否是与该容器内有对外开放监听端口的进程具有映射关系的进程。

比如，若确定该容器内任一目标端口的监听信息表示该目标端口处于被监听状态，则可从相应的网络连接文件中获取该目标端口对应的套接字文件描述符的文件标识，进一步地，若确定获取的文件标识与该进程当前打开的任一套接字文件描述符的文件标识相同，则确定该进程是与该容器内有对外开放监听端口的进程具有映射关系的进程；若确定获取的文件标识与该进程当前打开的各套接字文件描述符的文件标识均不相同，则确定该进程不是与该容器内有对外开放监听端口的进程具有映射关系的进程。

需要说明是，上述流程中S301a和S302a之间没有严格的先后顺序关系。

S104：根据与各容器内有对外开放监听端口的进程具有映射关系的进程，确定审计进程。

当映射关系表征数据是宿主机上各进程的控制组文件时，可以将与各容器内有对外开放监听端口的进程具有映射关系的进程，直接确定为审计进程。

当映射关系表征数据是宿主机上容器编排工具的容器配置信息时，可以将与各容器内有对外开放监听端口的进程具有映射关系的进程和这些进程的子进程，均确定为审计进程。

S105：监测每个审计进程的行为数据，根据监测到的行为数据确定该审计进程是否入侵对应容器。

具体实施时，可实时获取宿主机上所有进程的进程事件，从当前获取的所有进程的进程事件中筛选每个审计进程的进程事件。

比如，可以通过内核cn_proc连接器实时获取各进程的进程事件如fork事件、exec事件、uid变化事件、gid变化事件、exit事件等，从这些行为事件中过滤出审计进程的行为事件，并可通过/proc虚拟文件系统和/etc/passwd文件等获取审计进程的补充信息如cmdline(进程参数)、进程名、进程执行文件绝对路径、sessionid(进程会话id)、ppid(父进程号)、父进程名、uid、cwd(进程工作目录)，fd(进程打开的文件描述符信息)等。另外，还可维护行为事件的hash表，以审计各审计进程在整个生命周期中的行为活动。

进一步地，可对获取的进程事件进行分析，以检测容器中rce、webshell、反弹shell入侵行为。

具体实施时，可通过进程/proc/[pid]/net目录下网络连接信息、/proc/[pid]/fd目录下的打开文件描述符信息、tty等信息进行rce分析；通过进程打开工作目录和web容器进程工作目录进行webshell分析；通过父级进程、当前进程、子级进程的/proc/[pid]/fd目录下的打开文件描述符信息的关联性进行反弹shell分析。

并且，若确定任一审计进程对相应容器出现入侵行为，还可进行告警命令树的拼接(包括进程事件类型、进程名、进程号、进程参数等信息)及告警上报处理。

此外，对于入侵方式和逻辑相同而产生的告警可进行告警抑制，即不进行上报。支持远程获取命令树黑白名单，在本地进行告警过滤，同时支持对于已上报至告警库的告警，制定更为复杂的规则以对告警信息进行过滤，然后，过滤后的告警信息再推送至服务器管理员。

这样，将容器内对外开放监听端口进程在宿主机上映射的进程纳入关心进程，即确定为审计进程，在宿主机上实时审计这些审计进程或者这些审计进程及其派生的子级进程，能够实时检测容器中rce、webshell、反弹shell入侵行为并产生包含进程命令树的告警，方便溯源。

考虑到容器内进程是在不断创建和结束的，容器内进程在宿主机上所映射的进程也会相应发生变化，审计进程也会随之更新，为了应对审计进程的更新，本申请实施例提供的容器入侵检测方法可以周期性执行。

另外，为了减少对系统性能的影响、避免容器入侵检测占用过多(CentralProcessing Unit，CPU)和内存，在进行容器入侵检测时，还可以监控cpu和内存占用情况，当任一资源占用超过设定阈值时，可以及时休眠或重启入侵检测系统。

具体实施时，可以定时计算cpu占用，若确定cpu占用超出第一预设阈值，则发送SIGSTOP信号休眠相关进程，若确定cpu占用未超出第一预设阈值，则发送SIGCONT信号继续运行相关进程。当系统休眠次数超出预设次数时，可发送SIGKILL信号结束相关进程后再重启系统，以避免系统cpu占用过高影响宿主机业务。类似地，可以定时计算内存占用，若确定内存占用超出第二预设阈值，则先发送SIGKILL信号结束相关进程，再重启系统，以避免系统内存占用过高影响宿主机业务。

下面以宿主机上进程与各容器内进程的映射关系表征数据是宿主机上各进程的控制组文件为例，对本申请实施例提供的容器入侵检测方法进行介绍。

图4为本申请实施例提供的又一种容器的入侵检测方法的流程图，包括以下步骤：

S401：遍历宿主机上每个进程的控制组文件。

其中，控制组文件如cgroup文件。

具体实施时，可以遍历宿主机上/proc/[pid]/cgroup文件，这个文件用于描述进程的控制组(cgroups)信息，cgroups信息用于限制、统计和分离一个进程组的资源(如cpu、内存、磁盘输入输出等)，即若一个进程加入某个控制组，则该进程在使用这些资源时需遵守该控制组对这些资源的限定。

S402：判断控制组文件中是否包含表示容器的关键字，若否，则进入S403；若是，则进入S404。

其中，表示容器的关键字如docker。

实际应用中，当宿主机上某个进程与容器内某个进程具有映射关系时，该进程会加入该容器对应的控制组，同时/proc/[pid]/cgroup文件中会包含该容器的容器id(即容器标识)，其中，pid为进程号标识。

因此，若/proc/[pid]/cgroup文件中特定字段包含“docker”关键字，则说明宿主机上进程号为pid的进程与宿主机上一个容器内进程具有映射关系；若/proc/[pid]/cgroup文件中特定字段不包含“docker”关键字，则说明宿主机上进程号为pid的进程与宿主机上的容器内进程没有映射关系。

S403：确定控制组文件对应的进程不是宿主机上与容器内进程具有映射关系的进程。

S404：获取控制组文件中的容器标识，确定控制组文件对应的进程是宿主机上与获取的容器标识对应的容器内进程具有映射关系的进程。

即获取/proc/[pid]/cgroup文件中“docker”关键字的字段信息，该字段信息即容器id，那么，宿主机上进程号为pid的进程即是与宿主机上该容器id对应的容器内进程具有映射关系。

S405：获取该进程当前打开的套接字文件描述符的文件标识。

具体实施时，可根据该进程的pid查看宿主机上/proc/[pid]/fd，fd目标下存放了该进程当前打开的所有文件描述符，若该进程建立有socket连接则会打开socket文件描述符，因此，找到fd目标下的socket文件描述符即可得知该进程当前打开的socket连接，然后，可获取这些socket文件描述符的inode，建立该进程的pid与socket文件描述符的inode之间的映射关系。

S406：从该进程的网络连接文件中获取该容器内目标端口的监听信息，其中，目标端口是指该容器内与宿主机上的监听端口具有映射关系的监听端口。

具体实施时，可利用docker ps命令，确定该进程所属容器的内部监听端口，并确定宿主机上监听端口和容器内监听端口之间的映射关系，基于这些信息将该容器内与宿主机上的监听端口具有映射关系的监听端口，确定为目标端口。其中，docker ps命令的“CONTAINER ID”字段为容器标识，docker ps命令的“PORTS”字段维护开放监听端口信息，包括宿主机上监听端口和容器内监听端口之间的映射关系。

进一步地，可根据该进程的pid，遍历宿主机上该进程的网络连接文件如/proc/[pid]/net/tcp文件、/proc/[pid]/net/tcp6文件和/proc/[pid]/net/udp文件，从这些文件中获取该容器内目标端口的监听信息。

S407：根据该容器内目标端口的监听信息和该进程当前打开的套接字文件描述符的文件标识，确定该进程是否是与该容器内有对外开放监听端口的进程具有映射关系的进程。

具体实施时，若确定这些文件中任一文件中“st”字段是监听状态、且“local_address”字段中端口为该进程对应的容器内目标端口的连接记录，则可获取连接记录中“inode”字段对应的inode(代表一个socket文件描述符的inode)，若在该进程的pid与socket文件描述符的inode的映射关系中找到获取的inode，则说明该进程正是当前打开相应socket连接的进程，进而判定该进程是容器内开放监听端口的进程对应的宿主机上的进程。

S408：将与各容器内有对外开放监听端口的进程具有映射关系的进程，确定为审计进程。

对宿主机上的每个进程，不管该进程是父进程还是子进程，均按照S401-S407的步骤判断该进程是否与容器内有对外开放监听端口的进程具有映射关系，因此，将与各容器内有对外开放监听端口的进程具有映射关系的进程确定为审计进程时，审计进程中可能既有父进程也有子进程。

S409：监测每个审计进程的行为数据，根据监测到的行为数据确定该审计进程是否入侵对应容器。

下面以宿主机上进程与各容器内进程的映射关系表征数据是宿主机上容器编排工具的容器配置信息为例，对本申请实施例提供的容器入侵检测方法进行介绍。

图5为本申请实施例提供的再一种容器的入侵检测方法的流程图，包括以下步骤：

S501：获取宿主机上容器编排工具的容器配置信息。

假设宿主机上的容器编排工具为kubernetes，则容器配置信息包括宿主机的集群ip信息、service(服务)信息、pod信息、container信息，具体地，可以包括宿主机的网络地址，宿主机可提供的服务，这些服务对外开放的端口，这些服务对外开放的端口与宿主机上端口之间的映射关系，每个服务包含的pod，每个pod包含的容器，每个容器的监听端口，每个监听端口与服务对外开放的端口之间的映射关系等。

实际应用中，在创建kubernetes容器集群时，一般会在集群主节点安装并配置kubectl命令以便于管理集群。当将子节点加入集群时，主节点会下发kubelet.conf认证配置文件至子节点，该配置文件包含集群服务器、集群认证机构(Certification Authority，CA)证书、客户端证书、客户端密钥等信息，并且，不同节点之间通过kubernetes应用程序接口(Application Programming Interface，API)进行交互。

在kubernetes容器集群中，宿主机可能是kubernetes容器集群中的主节点，也可能是kubernetes容器集群中的子节点。当宿主机为kubernetes集群的主节点时，可直接用kubectl命令获取集群ip信息、service信息、pod信息、container信息；当宿主机为kubernetes集群的子节点时，若子节点支持kubectl命令，可通过kubectl的--kubeconfig选项指定kubelet.conf为配置文件的方式获取这些信息；若子节点不支持kubectl命令，可将kubelet.conf配置文件中集群服务器、集群CA证书、客户端证书、客户端密钥提取出来，利用curl或wget命令指定上述证书和密钥访问相应的kubernetes API来获取这些信息。

S502：根据容器配置信息，确定宿主机上内部监听端口与服务的对外开放端口之间有映射关系的至少一个容器，其中，服务的对外开放端口与宿主机上的端口具有映射关系。

具体实施时，可只关心有对外开放端口的service，即类型为NodePort和LoadBalancer的service。上述所获取的service信息包含服务对外开放端口和容器内监听端口的映射。service和pod间映射关系可通过service选择器和pod标签建立，某pod的标签包含某service的所有选择器则认为该pod属于该service。pod和container之间的映射关系可由kubectl命令或kubernetes API直接得到。上述所获取的container信息包含容器id唯一标识、容器启动进程参数、容器内监听端口等，只关心容器内监听端口与所属service对外开放端口有映射关系的container。基于此，可以构建从ip—>service—>pod—>container的层级映射关系，且可以确定哪些service对外开放有端口，哪些容器有监听端口。借助于构建的层级映射关系，即可确定宿主机上内部监听端口与有对外开放端口的服务之间有端口映射关系的容器。

假设构建的层级映射关系如图6所示，其中，ip对应有service1和service2，service1对应有pod1和pod2，pod1对应有container11和container12，pod2对应有container21和container22，service2的层级映射关系类似。并且service1有对外开放端口，service2没有对外开放端口，则service2对应的容器全部被排除。

进一步假设service1对应的容器container11、container12、container21和container22中，container11有内部监听端口、且container11的内部监听端口与service1的对外开放端口有映射关系，container12与service1对外开放的端口没有映射关系，container21有内部监听端口、且container21的内部监听端口与service1的对外开放端口有映射关系，container22没有内部监听端口。那么，内部监听端口与service1的对外开放端口有映射关系的为container11和container21。

S503：确定宿主机上与这至少一个容器内进程具有映射关系的进程。

具体实施时，对这至少一个容器中的每个容器，可以在宿主机上查找该容器的初始进程，进而将初始进程的各子进程中启动命令与容器中指定进程的启动命令一致的子进程，确定为宿主机上与容器内指定进程具有映射关系的进程。

S504：对宿主机上与任一容器内进程具有映射关系的每个进程，获取该进程当前打开的套接字文件描述符的文件标识。

具体实施时，对宿主机上与任一容器内进程具有映射关系的每个进程，可根据该进程的pid查看宿主机上/proc/[pid]/fd，fd目标下存放了该进程当前打开的所有文件描述符，若该进程建立有socket连接则会打开socket文件描述符，因此，找到fd目标下的socket文件描述符即可得知该进程当前打开的socket连接，然后，可获取这些socket文件描述符的inode，建立该进程的pid与socket文件描述符的inode之间的映射关系。

S505：从该进程的网络连接文件中获取该容器内目标端口的监听信息，其中，目标端口是指该容器内与宿主机上的监听端口具有映射关系的监听端口。

具体实施时，可利用docker ps命令，确定该容器的内部监听端口，并确定宿主机上监听端口和容器内监听端口之间的映射关系，基于这些信息将该容器内与宿主机上的监听端口具有映射关系的监听端口，确定为目标端口。其中，docker ps命令的“CONTAINERID”字段为容器标识，docker ps命令的“PORTS”字段维护开放监听端口信息，包括宿主机上监听端口和容器内监听端口之间的映射关系。

进一步地，可根据该进程的pid，遍历宿主机上该进程的网络连接文件如/proc/[pid]/net/tcp文件、/proc/[pid]/net/tcp6文件和/proc/[pid]/net/udp文件，从这些文件中获取该容器内目标端口的监听信息。

S506：根据该容器内目标端口的监听信息和该进程当前打开的套接字文件描述符的文件标识，确定该进程是否是与该容器内有对外开放监听端口的进程具有映射关系的进程。

具体实施时，若确定这些文件中任一文件中“st”字段是监听状态、且“local_address”字段中端口为该进程对应的容器内目标端口的连接记录，则可获取连接记录中“inode”字段对应的inode(代表一个socket文件描述符的inode)，若在该进程的pid与socket文件描述符的inode的映射关系中找到获取的inode，则说明该进程正是当前打开相应socket连接的进程，进而判定该进程是容器内开放监听端口的进程对应的宿主机上的进程。

S507：若确定任一进程与对应容器内有对外开放监听端口的进程没有映射关系，则在该进程的各子进程中，确定与该容器内有对外开放监听端口的进程具有映射关系的进程，将确定的子进程作为审计进程。

具体实施时，可以利用ps命令确定该进程的子进程，在确定该进程与对应容器内有对外开放监听端口的进程没有映射关系后，可在该进程的各子进程中，确定与容器内有对外开放监听端口的进程具有映射关系的进程。对任一进程或子进程而言，确定其是否是与容器内有对外开放监听端口的进程具有映射关系的进程的方式相同，在此不再赘述。

S508：将与各容器内有对外开放监听端口的进程具有映射关系的进程和这些进程的子进程，均确定为审计进程。

S509：监测每个审计进程的行为数据，根据监测到的行为数据确定该审计进程是否入侵对应容器。

当本申请实施例中提供的方法以软件或硬件或软硬件结合实现的时候，电子设备中可以包括多个功能模块，每个功能模块可以包括软件、硬件或其结合。

图7为本申请实施例提供的一种容器的入侵检测装置的结构示意图，包括获取模块701、第一确定模块702、筛选模块703、第二确定模块704、检测模块705。

获取模块701，用于获取宿主机上进程与各容器内进程的映射关系表征数据；

第一确定模块702，用于根据所述映射关系表征数据，确定所述宿主机上与各容器内进程具有映射关系的进程；

筛选模块703，用于从所述宿主机上与各容器内进程具有映射关系的进程中，筛选与各容器内有对外开放监听端口的进程具有映射关系的进程；

第二确定模块704，用于根据与各容器内有对外开放监听端口的进程具有映射关系的进程，确定审计进程；

检测模块705，用于监测每个所述审计进程的行为数据，根据所述行为数据确定所述审计进程是否入侵对应容器。

在一种可能的实施方式中，所述筛选模块703具体用于：

对所述宿主机上与任一容器内进程具有映射关系的每个进程，获取所述进程当前打开的套接字文件描述符的文件标识，并从所述进程的网络连接文件中获取所述容器内目标端口的监听信息，所述目标端口是指所述容器内与所述宿主机上的监听端口具有映射关系的监听端口；

根据所述容器内目标端口的监听信息和进程当前打开的套接字文件描述符的文件标识，确定所述进程是否是与所述容器内有对外开放监听端口的进程具有映射关系的进程。

在一种可能的实施方式中，所述筛选模块703具体用于：

从所述进程当前打开的所有文件描述符中筛选套接字文件描述符；

获取筛选出的套接字文件描述符的文件标识。

在一种可能的实施方式中，所述筛选模块703具体用于：

若确定所述容器内任一目标端口的监听信息表示所述目标端口处于被监听状态，则获取所述目标端口对应的套接字文件描述符的文件标识；

若确定获取的文件标识与所述进程当前打开的任一套接字文件描述符的文件标识相同，则确定所述进程是与所述容器内有对外开放监听端口的进程具有映射关系的进程。

在一种可能的实施方式中，所述第一确定模块702具体用于：

遍历所述宿主机上每个进程的控制组文件；

若确定所述控制组文件中包含表示容器的关键字，则获取所述控制组文件中的容器标识；

确定所述控制组文件对应的进程是所述宿主机上与所述容器标识对应的容器内进程具有映射关系的进程。

在一种可能的实施方式中，所述第一确定模块702具体用于：

根据所述容器配置信息，确定所述宿主机上内部监听端口与服务的对外开放端口之间有映射关系的至少一个容器，所述服务的对外开放端口与所述宿主机上的端口具有映射关系；

确定所述宿主机上与所述至少一个容器内进程具有映射关系的进程。

在一种可能的实施方式中，所述第一确定模块702具体用于：

对所述至少一个容器中的每个容器，在所述宿主机上查找所述容器的初始进程；

将所述初始进程的各子进程中启动命令与所述容器中指定进程的启动命令一致的子进程，确定为所述宿主机上与所述容器内指定进程具有映射关系的进程。

在一种可能的实施方式中，所述筛选模块703还用于：

在确定任一进程不是与对应容器内有对外开放监听端口的进程具有映射关系的进程之后，在所述进程的各子进程中，确定是否存在与所述容器内有对外开放监听端口的进程具有映射关系的子进程，将确定的所述子进程作为审计进程。

在一种可能的实施方式中，所述第二确定模块704具体用于：

将与各容器内有对外开放监听端口的进程具有映射关系的进程和所述进程的子进程，均确定为审计进程。

在一种可能的实施方式中，所述检测模块705具体用于：

实时获取宿主机上所有进程的进程事件；

从获取的所有进程的进程事件中筛选出每个所述审计进程的进程事件，并监测每个所述审计进程的行为数据。

本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，另外，在本申请各个实施例中的各功能模块可以集成在一个处理器中，也可以是单独物理存在，也可以两个或两个以上模块集成在一个模块中。各个模块相互之间的耦合可以是通过一些接口实现，这些接口通常是电性通信接口，但是也不排除可能是机械接口或其它的形式接口。因此，作为分离部件说明的模块可以是或者也可以不是物理上分开的，既可以位于一个地方，也可以分布到同一个或不同设备的不同位置上。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

图8为本申请实施例提供的一种电子设备的结构示意图，该电子设备包括收发器801以及处理器802等物理器件，其中，处理器802可以是一个中央处理单元(CentralProcessing Unit，CPU)、微处理器、专用集成电路、可编程逻辑电路、大规模集成电路、或者为数字处理单元等等。收发器801用于电子设备和其他设备进行数据收发。

该电子设备还可以包括存储器803用于存储处理器802执行的软件指令，当然还可以存储电子设备需要的一些其他数据，如电子设备的标识信息、电子设备的加密信息、用户数据等。存储器803可以是易失性存储器(Volatile Memory)，例如随机存取存储器(Random-Access Memory，RAM)；存储器803也可以是非易失性存储器(Non-VolatileMemory)，例如只读存储器(Read-Only Memory，ROM)，快闪存储器(Flash Memory)，硬盘(Hard Disk Drive，HDD)或固态硬盘(Solid-State Drive，SSD)、或者存储器803是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器803可以是上述存储器的组合。

本申请实施例中不限定上述处理器802、存储器803以及收发器801之间的具体连接介质。本申请实施例在图8中仅以存储器803、处理器802以及收发器801之间通过总线804连接为例进行说明，总线在图8中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

处理器802可以是专用硬件或运行软件的处理器，当处理器802可以运行软件时，处理器802读取存储器803存储的软件指令，并在所述软件指令的驱动下，执行前述实施例中涉及的容器的入侵检测方法。

本申请实施例还提供了一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，所述电子设备能够执行前述实施例中涉及的容器的入侵检测方法。

在一些可能的实施方式中，本申请提供的容器的入侵检测方法的各个方面还可以实现为一种程序产品的形式，所述程序产品中包括有程序代码，当所述程序产品在电子设备上运行时，所述程序代码用于使所述电子设备执行前述实施例中涉及的容器的入侵检测方法。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、RAM、ROM、可擦式可编程只读存储器(Erasable Programmable Read-Only Memory，EPROM)、闪存、光纤、光盘只读存储器(Compact Disk Read Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

本申请实施例中用于容器的入侵检测的程序产品可以采用CD-ROM并包括程序代码，并可以在计算设备上运行。然而，本申请的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、射频(Radio Frequency，RF)等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络如局域网(Local AreaNetwork，LAN)或广域网(Wide Area Network，WAN)连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

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

此外，尽管在附图中以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、装置(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。