CN116186701A - docker容器内反弹shell的检测方法、系统、终端及存储介质 - Google Patents
docker容器内反弹shell的检测方法、系统、终端及存储介质 Download PDFInfo
- Publication number
- CN116186701A CN116186701A CN202310108086.9A CN202310108086A CN116186701A CN 116186701 A CN116186701 A CN 116186701A CN 202310108086 A CN202310108086 A CN 202310108086A CN 116186701 A CN116186701 A CN 116186701A
- Authority
- CN
- China
- Prior art keywords
- container
- rebound shell
- shell
- behavior
- rebound
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
- G06F21/566—Dynamic detection, i.e. detection performed at run-time, e.g. emulation, suspicious activities
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
- G06F2221/033—Test or assess software
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Virology (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明涉及计算机技术领域,具体涉及docker容器内反弹shell的检测方法、系统、终端及存储介质。该方法包括以下步骤判断当前进程是否为反弹shell行为;判断发生反弹shell行为的进程是否包含containerd‑shim,若是则表示发生了docker容器内反弹shell行为;输出发生进程容器内反弹shell行为的报警信号,本发明通过判断当前进程是否为反弹shell行为,然后判断发生反弹shell行为的进程是否包含containerd‑shim,若是则表示发生了docker容器内反弹shell行为,快速发现docker容器内的反弹shell行为,相对于比较复杂的检测方法比较简单实用。
Description
技术领域
本发明涉及计算机技术领域,尤其涉及docker容器内反弹shell的检测方法、系统、终端及存储介质。
背景技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中,然后发布到任何流行的Linux或Windows操作系统的机器上,也可以实现虚拟化。容器是完全使用沙箱机制,相互之间不会有任何接口。
目前反弹shell是计算机数据中心的噩梦,针对docker内的攻击也不断增加,每年有大量的企业或单位数据中心中招,损害了根本利益,目前市面上对docker内的反弹shell的检测还比较少,现有的技术也比较复杂,拦截的效果并不是很理想。
发明内容
为了解决上述现有技术中存在的技术问题,本发明提供了一种docker容器内反弹shell的检测方法、系统、终端及存储介质,快速发现docker容器内的反弹shell行为,相对于比较复杂的检测方法比较简单实用。
为实现上述目的,本发明实施例提供了如下的技术方案:
第一方面,在本发明提供的一个实施例中,提供了docker容器内反弹shell的检测方法,该方法包括以下步骤:
判断当前进程是否为反弹shell行为;
判断发生反弹shell行为的进程是否包含containerd-shim,若是则表示发生了docker容器内反弹shell行为;
输出发生进程容器内反弹shell行为的报警信号。
作为本发明的进一步方案,所述判断当前进程是否为反弹shell行为,包括如下步骤:
获取当前进程的进程空间的初始进程号和当前进程号;
根据初始进程号和当前进程号是否一致,判断进程是否发生了反弹shell行为。
作为本发明的进一步方案,所述根据初始进程号和当前进程号是否一致,判断进程是否发生了反弹shell行为:包括,
判断初始进程号和当前进程号是否一致,若不一致判断是否产生异常文件,若产生了则得出进程发生了反弹shell行为。
作为本发明的进一步方案,所述异常文件为socket,所述socket存储在/proc/pid/fd目录下中的文件中。
作为本发明的进一步方案,所述判断发生反弹shell行为的进程是否包含containerd-shim,若是则表示发生了docker容器内反弹shell行为,包括:
通过当前的进程标识,查看/proc/pid/status当前的进程状态,如果进程状态中包含containerd-shim则确定当前进程在docker容器内发生了反弹shell行为。
作为本发明的进一步方案,所述docker容器中containerd通过containerd-shim启动并管理runC。
第二方面,在本发明提供的又一个实施例中,提供了docker容器内反弹shell的检测系统,该系统包括:第一判断模块、第二判断模块和报警模块;
所述第一判断模块,用于判断当前进程是否为反弹shell行为;
所述第二判断模块,用于判断发生反弹shell行为的进程是否包含containerd-shim,若是则表示发生了docker容器内反弹shell行为;
所述报警模块,用于输出发生进程容器内反弹shell行为的报警信号。
作为本发明的进一步方案,所述第一判断模块包括数据获取单元和判断子单元;
所述数据获取单元,用于获取当前进程的进程空间的初始进程号和当前进程号;
所述判断子单元,用于根据初始进程号和当前进程号是否一致,判断进程是否发生了反弹shell行为。
第三方面,在本发明提供的又一个实施例中,提供了一种终端,包括存储器和处理器,所述存储器存储有计算机程序,所述处理器加载并执行所述计算机程序时实现docker容器内反弹shell的检测方法的步骤。
第四方面,在本发明提供的再一个实施例中,提供了一种存储介质,存储有计算机程序,所述计算机程序被处理器加载并执行时实现所述docker容器内反弹shell的检测方法的步骤。
本发明提供的技术方案,具有如下有益效果:
本发明提供的docker容器内反弹shell的检测方法、系统、终端及存储介质,通过判断当前进程是否为反弹shell行为,然后判断发生反弹shell行为的进程是否包含containerd-shim,若是则表示发生了docker容器内反弹shell行为,快速发现docker容器内的反弹shell行为,相对于比较复杂的检测方法比较简单实用。
本发明的这些方面或其他方面在以下实施例的描述中会更加简明易懂。应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本发明。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的实施例。
图1为本发明一个实施例的docker容器内反弹shell的检测方法的流程图;
图2为本发明一个实施例的docker容器内反弹shell的检测系统中结构框图;
图3为本发明一个实施例的docker容器内反弹shell的检测系统中第一判断模块结构框图;
图4为本发明一个实施例的一种终端的结构框图。
图中:第一判断模块-100、第二判断模块-200、报警模块-300、数据获取单元-101、判断子单元-102、处理器-401、通信接口-402、存储器-403、通信总线-404。
具体实施方式
以下参照附图说明各种实施例及/或各形态。在以下说明中,以说明为目的公开了多个具体细节以整体上理解一个以上的形态。但是,本领域的技术人员可以理解在没有具体细节的情况下也可以实施这些形态。在以下的记载及附图中将详细说明一个以上的形态的特定例示。但是,这些形态是例示而已,可以利用各种形态的原理中各种方法中的一部分,所阐述的说明旨在包括所有形态及其等同物。具体地,在本说明书中使用的术语“实施例”、“例”、“形态”、“例示”等可以被解释为所描述的任意形态或设计可以比其他形态或设计更好或具有优点。
另外,各种形态及特征可通过包括一个以上的装置、终端、服务器、设备、组件及/或模块等的系统体现。应理解并认识各种系统可包括额外的多个装置、终端、服务器、设备、组件及/或模块,并且/或也可以不包括图中所示的多个装置、终端、服务器、设备、组件、模块等的全部。
在本说明书中使用的术语“计算机程序”、“组件”、“模块”、“系统”等可以互换使用,并且计算机-相关实体、硬件、固件、软件、软件及硬件的组合或指软件的执行。例如,组件可以是在处理器上执行的处理过程、处理器、客体、执行线程、程序及/或计算机,但不限定于此。例如,可以是在计算机装置执行的应用程序及/或计算装置所有组件。一个以上的组件可以安装在处理器及/或执行线程内。一个组件可以在一个计算机中本地化。一个组件也可以在两个以上的计算机之间分配。
并且,这些组件可由在内部存储各种数据构造的各种计算机可读介质执行。这些组件,例如可根据具有一个以上的数据包的信号(例如,在本地系统、分散系统上通过与其他组件相互作用的一个组件发出的数据及信号与其他系统通过互联网等网络传输的数据)通过本地及/或远程处理通信。
以下,与图面符号无关,对相同或类似的构成要素赋予相同的符号,并省略对此的重复说明。并且,在说明本说明书中公开的实施例时,若判断对公知技术的具体说明会使本发明的要旨不明确,则省略对其的详细说明。并且,附图仅为了更容易理解在本说明书中公开的实施例,本说明书中公开的技术思想并不限定于附图。
在本说明书中使用的术语是为了说明这些实施例的,而不是限制本发明。在没有特别提及的情况下,本说明书中的单数表现包括复数表现。在说明书中使用的“包含(comprises)”及/或“包含的(comprising)”被提及的构成要素以外不排除一个以上的其他构成要素的存在或附加。
第一、第二等术语可用于说明多种元件或构成要素,但所述元件或构成要素并不局限于所述术语。所述术语以从其他元件或构成要素区分一个元件或构成要素而使用。因此,在以下提及的第一元件或构成要素当然也可以是本发明的技术思想内的第2元件或构成要素。
若没有其他定义,在本说明书中使用的所有术语(包括技术及科学术语)可以用于本发明所属领域的领域技术人员共通理解的含义。另外,在一般使用的词典上被定义的术语,若没有特别明确定义,则不应以理想性或过度解释。
另外,术语“或”的意思不是排他的“或”而是包含的“或”。即,除非有其他特定或文脉上不明确时“X利用A或B”意味着自然内涵的替换之一。即,X利用A或;X利用B或X利用A及B时,“X利用A或B”可以上面的任何情况。并且,应理解在本说明书中使用的“及/或”的术语指代包括在例举的相关项目中的一个以上项目可能的所有组合。
另外,在本说明书中使用的术语“信息”及“数据”通常可互换使用。
在以下说明中使用的对构成要素的后缀“模块”及“部”,只是为了方便撰写说明书而赋予或混用的,其本身并没有相互区别的含义或作用。
具体地,下面结合附图,对本发明实施例作进一步阐述。
请参阅图1,图1是本发明实施例提供的一种docker容器内反弹shell的检测方法的流程图,如图1所示,该docker容器内反弹shell的检测方法包括步骤S10至步骤S30。
S10、判断当前进程是否为反弹shell行为;
在本发明的实施例中,所述S10、判断当前进程是否为反弹shell行为,包括如下步骤:
获取当前进程的进程空间的初始进程号和当前进程号;
根据初始进程号和当前进程号是否一致,判断进程是否发生了反弹shell行为。
具体的,每一个进程在创建时都有一个初始命名空间进程号。
Linux容器场景下实现对进程和其相关的资源的隔离,这些资源同样也包括了进程的文件系统环境。这就要求容器中有一个独立的文件环境,而容器中的进程共享这个文件系统环境,即容器自己的根文件系统环境。
所以内核引入了mnt命名空间的概念,来实现文件系统环境的隔离。
通过获取当前进程的mnt命名空间来判断是否发生在docker容器内,如果该命名空间不为空则认为发生在docker容器内,如果该命名空间为空则该进程一定不发生在docker容器内。
其中,所述根据初始进程号和当前进程号是否一致,判断进程是否发生了反弹shell行为:包括,
判断初始进程号和当前进程号是否一致,若不一致判断是否产生异常文件,若产生了则得出进程发生了反弹shell行为。
在本发明的实施例中,所述异常文件为socket,所述socket存储在/proc/pid/fd目录下中的文件中。
S20、判断发生反弹shell行为的进程是否包含containerd-shim,若是则表示发生了docker容器内反弹shell行为。
在本发明的实施例中,所述判断发生反弹shell行为的进程是否包含containerd-shim,若是则表示发生了docker容器内反弹shell行为,包括:
通过当前的进程标识(PID),查看/proc/pid/status当前的进程状态,如果进程状态中包含containerd-shim则确定当前进程在docker容器内发生了反弹shell行为。
其中,所述docker容器中containerd通过containerd-shim启动并管理runC。
所述containerd是dockerd和runC之间的一个中间交流组件。
在本发明实时里中,所述docker容器的管理和操作基本都是通过containerd完成的。例如:容器生命周期管理、镜像管理。
其中,runC是一个根据OCI(开放容器标准)规范生成和运行容器的CLI工具,可通过命令行的形式控制容器的销毁与创建。
S30、输出发生进程容器内反弹shell行为的报警信号。以便用户及时感知受到入侵危害。
本发明通过判断当前进程是否为反弹shell行为,然后判断发生反弹shell行为的进程是否包含containerd-shim,若是则表示发生了docker容器内反弹shell行为,快速发现docker容器内的反弹shell行为,相对于比较复杂的检测方法比较简单实用。
应该理解的是,上述虽然是按照某一顺序描述的,但是这些步骤并不是必然按照上述顺序依次执行。除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,这些步骤可以以其它的顺序执行。而且,本实施例的一部分步骤可以包括多个步骤或者多个阶段,这些步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,这些步骤或者阶段的执行顺序也不必然是依次进行,而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
在一个实施例中,参见图2所示,在本发明的实施例中还提供了docker容器内反弹shell的检测系统,该系统包括第一判断模块100、第二判断模块200和报警模块300。
所述第一判断模块100,用于判断当前进程是否为反弹shell行为。
参见图4所示,在本发明的实施例中,所述第一判断模块100包括数据获取单元101和判断子单元102;
所述数据获取单元101,用于获取当前进程的进程空间的初始进程号和当前进程号;
所述判断子单元102,用于根据初始进程号和当前进程号是否一致,判断进程是否发生了反弹shell行为。
其中,所述根据初始进程号和当前进程号是否一致,判断进程是否发生了反弹shell行为:包括,
判断初始进程号和当前进程号是否一致,若不一致判断是否产生异常文件,若产生了则得出进程发生了反弹shell行为。
具体的,每一个进程在创建时都有一个初始命名空间进程号。
Linux容器场景下实现对进程和其相关的资源的隔离,这些资源同样也包括了进程的文件系统环境。这就要求容器中有一个独立的文件环境,而容器中的进程共享这个文件系统环境,即容器自己的根文件系统环境。
所以内核引入了mnt命名空间的概念,来实现文件系统环境的隔离。
通过获取当前进程的mnt命名空间来判断是否发生在docker容器内,如果该命名空间不为空则认为发生在docker容器内,如果该命名空间为空则该进程一定不发生在docker容器内。
在本发明的实施例中,所述异常文件为socket,所述socket存储在/proc/pid/fd目录下中的文件中。
所述第二判断模块200,用于判断发生反弹shell行为的进程是否包含containerd-shim,若是则表示发生了docker容器内反弹shell行为。
在本发明的实施例中,所述第二判断模块200,用于通过当前的进程标识(PID),查看/proc/pid/status当前的进程状态,如果进程状态中包含containerd-shim则确定当前进程在docker容器内发生了反弹shell行为。
其中,所述docker容器中containerd通过containerd-shim启动并管理runC。
所述containerd是dockerd和runC之间的一个中间交流组件。
在本发明实时里中,所述docker容器的管理和操作基本都是通过containerd完成的。例如:容器生命周期管理、镜像管理。
其中,runC是一个根据OCI(开放容器标准)规范生成和运行容器的CLI工具,可通过命令行的形式控制容器的销毁与创建。
所述报警模块300,用于输出发生进程容器内反弹shell行为的报警信号。
本发明通过判断当前进程是否为反弹shell行为,然后判断发生反弹shell行为的进程是否包含containerd-shim,若是则表示发生了docker容器内反弹shell行为,快速发现docker容器内的反弹shell行为,相对于比较复杂的检测方法比较简单实用。
在一个实施例中,参见图4所示,在本发明的实施例中还提供了一种终端,包括处理器401、通信接口402、存储器403和通信总线404,其中,处理器401,通信接口402,存储器403通过通信总线404完成相互间的通信。
存储器403,用于存放计算机程序;
处理器401,用于执行存储器403上所存放的计算机程序时,执行所述的docker容器内反弹shell的检测方法,该处理器执行指令时实现上述方法实施例中的步骤:
S10、判断当前进程是否为反弹shell行为;
在本发明的实施例中,所述S10、判断当前进程是否为反弹shell行为,包括如下步骤:
获取当前进程的进程空间的初始进程号和当前进程号;
根据初始进程号和当前进程号是否一致,判断进程是否发生了反弹shell行为。
具体的,每一个进程在创建时都有一个初始命名空间进程号。
Linux容器场景下实现对进程和其相关的资源的隔离,这些资源同样也包括了进程的文件系统环境。这就要求容器中有一个独立的文件环境,而容器中的进程共享这个文件系统环境,即容器自己的根文件系统环境。
所以内核引入了mnt命名空间的概念,来实现文件系统环境的隔离。
通过获取当前进程的mnt命名空间来判断是否发生在docker容器内,如果该命名空间不为空则认为发生在docker容器内,如果该命名空间为空则该进程一定不发生在docker容器内。
其中,所述根据初始进程号和当前进程号是否一致,判断进程是否发生了反弹shell行为:包括,
判断初始进程号和当前进程号是否一致,若不一致判断是否产生异常文件,若产生了则得出进程发生了反弹shell行为。
在本发明的实施例中,所述异常文件为socket,所述socket存储在/proc/pid/fd目录下中的文件中。
S20、判断发生反弹shell行为的进程是否包含containerd-shim,若是则表示发生了docker容器内反弹shell行为。
在本发明的实施例中,所述判断发生反弹shell行为的进程是否包含containerd-shim,若是则表示发生了docker容器内反弹shell行为,包括:
通过当前的进程标识(PID),查看/proc/pid/status当前的进程状态,如果进程状态中包含containerd-shim则确定当前进程在docker容器内发生了反弹shell行为。
其中,所述docker容器中containerd通过containerd-shim启动并管理runC。
所述containerd是dockerd和runC之间的一个中间交流组件。
在本发明实时里中,所述docker容器的管理和操作基本都是通过containerd完成的。例如:容器生命周期管理、镜像管理。
其中,runC是一个根据OCI(开放容器标准)规范生成和运行容器的CLI工具,可通过命令行的形式控制容器的销毁与创建。
S30、输出发生进程容器内反弹shell行为的报警信号。以便用户及时感知受到入侵危害。
本发明通过判断当前进程是否为反弹shell行为,然后判断发生反弹shell行为的进程是否包含containerd-shim,若是则表示发生了docker容器内反弹shell行为,快速发现docker容器内的反弹shell行为,相对于比较复杂的检测方法比较简单实用。
上述终端提到的通信总线可以是外设部件互连标准(PeripheralComponentInterconnect,简称PCI)总线或扩展工业标准结构(Extended IndustryStandardArchitecture,简称EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示,图中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
通信接口用于上述终端与其他设备之间的通信。
存储器可以包括随机存取存储器(Random Access Memory,简称RAM),也可以包括非易失性存储器(non-volatile memory),例如至少一个磁盘存储器。可选的,存储器还可以是至少一个位于远离前述处理器的存储装置。
上述的处理器可以是通用处理器,包括中央处理器(Central Processing Unit,简称CPU)、网络处理器(Network Processor,简称NP)等;还可以是数字信号处理器(Digital Signal Processing,简称DSP)、专用集成电路(ApplicationSpecificIntegrated Circuit,简称ASIC)、现场可编程门阵列(Field-ProgrammableGate Array,简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
所述终端包括用户设备与网络设备。其中,所述用户设备包括但不限于电脑、智能手机、PDA等;所述网络设备包括但不限于单个网络服务器、多个网络服务器组成的服务器组或基于云计算(Cloud Computing)的由大量计算机或网络服务器构成的云,其中,云计算是分布式计算的一种,由一群松散耦合的计算机集组成的一个超级虚拟计算机。其中,所述终端可单独运行来实现本发明,也可接入网络并通过与网络中的其他终端的交互操作来实现本发明。其中,所述终端所处的网络包括但不限于互联网、广域网、城域网、局域网、VPN网络等。
还应当进理解,在本发明说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合,并且包括这些组合。
在本发明的一个实施例中还提供了一种存储介质,其上存储有计算机程序,该计算机程序被处理器执行时实现上述方法实施例中的步骤:
S10、判断当前进程是否为反弹shell行为;
在本发明的实施例中,所述S10、判断当前进程是否为反弹shell行为,包括如下步骤:
获取当前进程的进程空间的初始进程号和当前进程号;
根据初始进程号和当前进程号是否一致,判断进程是否发生了反弹shell行为。
具体的,每一个进程在创建时都有一个初始命名空间进程号。
Linux容器场景下实现对进程和其相关的资源的隔离,这些资源同样也包括了进程的文件系统环境。这就要求容器中有一个独立的文件环境,而容器中的进程共享这个文件系统环境,即容器自己的根文件系统环境。
所以内核引入了mnt命名空间的概念,来实现文件系统环境的隔离。
通过获取当前进程的mnt命名空间来判断是否发生在docker容器内,如果该命名空间不为空则认为发生在docker容器内,如果该命名空间为空则该进程一定不发生在docker容器内。
其中,所述根据初始进程号和当前进程号是否一致,判断进程是否发生了反弹shell行为:包括,
判断初始进程号和当前进程号是否一致,若不一致判断是否产生异常文件,若产生了则得出进程发生了反弹shell行为。
在本发明的实施例中,所述异常文件为socket,所述socket存储在/proc/pid/fd目录下中的文件中。
S20、判断发生反弹shell行为的进程是否包含containerd-shim,若是则表示发生了docker容器内反弹shell行为。
在本发明的实施例中,所述判断发生反弹shell行为的进程是否包含containerd-shim,若是则表示发生了docker容器内反弹shell行为,包括:
通过当前的进程标识(PID),查看/proc/pid/status当前的进程状态,如果进程状态中包含containerd-shim则确定当前进程在docker容器内发生了反弹shell行为。
其中,所述docker容器中containerd通过containerd-shim启动并管理runC。
所述containerd是dockerd和runC之间的一个中间交流组件。
在本发明实时里中,所述docker容器的管理和操作基本都是通过containerd完成的。例如:容器生命周期管理、镜像管理。
其中,runC是一个根据OCI(开放容器标准)规范生成和运行容器的CLI工具,可通过命令行的形式控制容器的销毁与创建。
S30、输出发生进程容器内反弹shell行为的报警信号。以便用户及时感知受到入侵危害。
本发明通过判断当前进程是否为反弹shell行为,然后判断发生反弹shell行为的进程是否包含containerd-shim,若是则表示发生了docker容器内反弹shell行为,快速发现docker容器内的反弹shell行为,相对于比较复杂的检测方法比较简单实用。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的计算机程序可存储于一非易失性计算机可读取存储介质中,该计算机程序在执行时,可包括如上述方法的实施例的流程。其中,本发明所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用,均可包括非易失性和易失性存储器中的至少一种。
应当理解的是,在本文中使用的,除非上下文清楚地支持例外情况,单数形式“一个”旨在也包括复数形式。还应当理解的是,在本文中使用的“和/或”是指包括一个或者一个以上相关联地列出的项目的任意和所有可能组合。上述本发明实施例公开实施例序号仅仅为了描述,不代表实施例的优劣。
所属领域的普通技术人员应当理解:以上任何实施例的讨论仅为示例性的,并非旨在暗示本发明实施例公开的范围(包括权利要求)被限于这些例子;在本发明实施例的思路下,以上实施例或者不同实施例中的技术特征之间也可以进行组合,并存在如上的本发明实施例的不同方面的许多其它变化,为了简明它们没有在细节中提供。因此,凡在本发明实施例的精神和原则之内,所做的任何省略、修改、等同替换、改进等,均应包含在本发明实施例的保护范围之内。
Claims (10)
1.一种docker容器内反弹shell的检测方法,其特征在于,该方法包括:
判断当前进程是否为反弹shell行为;
判断发生反弹shell行为的进程是否包含containerd-shim,若是则表示发生了docker容器内反弹shell行为;
输出发生进程容器内反弹shell行为的报警信号。
2.如权利要求1所述的docker容器内反弹shell的检测方法,其特征在于,所述判断当前进程是否为反弹shell行为,包括如下步骤:
获取当前进程的进程空间的初始进程号和当前进程号;
根据初始进程号和当前进程号是否一致,判断进程是否发生了反弹shell行为。
3.如权利要求2所述的docker容器内反弹shell的检测方法,其特征在于,其中,所述根据初始进程号和当前进程号是否一致,判断进程是否发生了反弹shell行为:包括,
判断初始进程号和当前进程号是否一致,若不一致判断是否产生异常文件,若产生了则得出进程发生了反弹shell行为。
4.如权利要求3所述的docker容器内反弹shell的检测方法,其特征在于,所述异常文件为socket,所述socket存储在/proc/pid/fd目录下中的文件中。
5.如权利要求1所述的docker容器内反弹shell的检测方法,其特征在于,所述判断发生反弹shell行为的进程是否包含containerd-shim,若是则表示发生了docker容器内反弹shell行为,包括:
通过当前的进程标识,查看/proc/pid/status当前的进程状态,如果进程状态中包含containerd-shim则确定当前进程在docker容器内发生了反弹shell行为。
6.如权利要求5所述的docker容器内反弹shell的检测方法,其特征在于,所述docker容器中containerd通过containerd-shim启动并管理runC。
7.一种docker容器内反弹shell的检测系统,其特征在于,该系统包括:第一判断模块、第二判断模块和报警模块;
所述第一判断模块,用于判断当前进程是否为反弹shell行为;
所述第二判断模块,用于判断发生反弹shell行为的进程是否包含containerd-shim,若是则表示发生了docker容器内反弹shell行为;
所述报警模块,用于输出发生进程容器内反弹shell行为的报警信号。
8.如权利要求7所述的docker容器内反弹shell的检测系统,其特征在于,所述第一判断模块包括数据获取单元和判断子单元;
所述数据获取单元,用于获取当前进程的进程空间的初始进程号和当前进程号;
所述判断子单元,用于根据初始进程号和当前进程号是否一致,判断进程是否发生了反弹shell行为。
9.一种终端,包括存储器和处理器,所述存储器存储有计算机程序,所述处理器加载并执行所述计算机程序时实现如权利要求1-7任一项所述的docker容器内反弹shell的检测方法的步骤。
10.一种存储介质,存储有计算机程序,所述计算机程序被处理器加载并执行时实现如权利要求1-7任一项所述的docker容器内反弹shell的检测方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310108086.9A CN116186701A (zh) | 2023-02-10 | 2023-02-10 | docker容器内反弹shell的检测方法、系统、终端及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310108086.9A CN116186701A (zh) | 2023-02-10 | 2023-02-10 | docker容器内反弹shell的检测方法、系统、终端及存储介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN116186701A true CN116186701A (zh) | 2023-05-30 |
Family
ID=86439839
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202310108086.9A Pending CN116186701A (zh) | 2023-02-10 | 2023-02-10 | docker容器内反弹shell的检测方法、系统、终端及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN116186701A (zh) |
-
2023
- 2023-02-10 CN CN202310108086.9A patent/CN116186701A/zh active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102419729B (zh) | 并行测试执行 | |
WO2022016847A1 (zh) | 一种适用于云平台的自动化测试方法及装置 | |
CN109661652B (zh) | 使用系统调用序列的异常检测 | |
CN110474900B (zh) | 一种游戏协议测试方法及装置 | |
US9026612B2 (en) | Generating a custom parameter rule based on a comparison of a run-time value to a request URL | |
US10740166B2 (en) | Thread based dynamic data collection | |
CN110908837B (zh) | 应用程序异常处理方法、装置、电子设备及存储介质 | |
CN113220403B (zh) | h5拦截Android返回事件的方法、装置及电子设备 | |
US20150220517A1 (en) | Efficient conflict resolution among stateless processes | |
CN108062224B (zh) | 基于文件句柄的数据读写方法、装置及计算设备 | |
CN116186701A (zh) | docker容器内反弹shell的检测方法、系统、终端及存储介质 | |
CN112506781B (zh) | 测试监控方法、装置、电子设备、存储介质及程序产品 | |
CN111597093A (zh) | 一种异常处理方法、装置及其设备 | |
CN111367750B (zh) | 一种异常处理方法、装置及其设备 | |
CN114356713A (zh) | 线程池监控方法、装置、电子设备及存储介质 | |
CN114116509A (zh) | 程序分析方法、装置、电子设备和存储介质 | |
CN108551410B (zh) | 接口返回方法及终端设备 | |
CN108491190A (zh) | 类继承结构信息获取方法、装置及电子设备 | |
EP4354308A2 (en) | Computer system and method for evaluating integrity and parsing of a file system and parsing implementation | |
US11474816B2 (en) | Code review using quantitative linguistics | |
CN112732568B (zh) | 一种系统日志获取方法、装置、存储介质及终端 | |
CN108664293B (zh) | 安卓系统中的应用控制方法和装置 | |
CN117149355A (zh) | 一种基于OpenStack云平台虚拟机磁盘统一管理方法 | |
US10489267B2 (en) | Taking an action in response to detecting an unsupported language in a log | |
US9575831B2 (en) | Detecting the use of stale data values due to weak consistency |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |