CN117896084A - 一种安全防护方法、装置、设备及介质 - Google Patents

一种安全防护方法、装置、设备及介质 Download PDF

Info

Publication number
CN117896084A
CN117896084A CN202311074970.1A CN202311074970A CN117896084A CN 117896084 A CN117896084 A CN 117896084A CN 202311074970 A CN202311074970 A CN 202311074970A CN 117896084 A CN117896084 A CN 117896084A
Authority
CN
China
Prior art keywords
data
port
processed
security engine
address
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
Application number
CN202311074970.1A
Other languages
English (en)
Inventor
浦明
陈建军
尤扬
刘文懋
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nsfocus Technologies Inc
Nsfocus Technologies Group Co Ltd
Original Assignee
Nsfocus Technologies Inc
Nsfocus Technologies Group Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Nsfocus Technologies Inc, Nsfocus Technologies Group Co Ltd filed Critical Nsfocus Technologies Inc
Priority to CN202311074970.1A priority Critical patent/CN117896084A/zh
Publication of CN117896084A publication Critical patent/CN117896084A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请实施例提供了一种安全防护方法、装置、设备及介质，用以解决相关技术中在将数据发送至安全引擎时，数据传输的通路较长，导致设备的吞吐量较低的问题。由于在本申请实施例中，hook点在检测到数据传输请求后，获取数据传输请求中携带的待处理数据，并通过挂载的eBPF程序将待处理数据发送至安全引擎，该过程无需经过底层协议栈，因此可以在将数据发送至安全引擎的过程中，缩短数据传输的通路，从而提高设备的吞吐量。

Description

一种安全防护方法、装置、设备及介质
技术领域
本申请涉及信息技术领域，尤其涉及一种安全防护方法、装置、设备及介质。
背景技术
随着越来越多应用的云原生化，云原生场景下的安全问题层出不穷，近些年来，安全团队发现一款借助容器进行传播的新型蠕虫病毒。由此可见，虽然云原生化的相关技术带来了技术和产业革新，但云原生场景中同样充满安全风险。云原生场景中的安全问题亟待得到充分的重视和保障。其中，安全问题主要包括应用程序接口(ApplicationProgramming Interface，API)滥用、Webshell连接上传、数据库语言(Structured QueryLanguage，SQl)注入、访问控制列表(ACL)等。为了准确有效地在云原生场景下实现安全防护，相关技术中提出了劫持云原生场景下的数据，并转发至安全引擎，由安全引擎判断接收到的数据是否为恶意数据，从而实现对恶意数据的防护。相关的数据劫持技术通常采用iptables对微服务的Pod的进出口数据进行劫持，在云原生场景下，典型的方法为：服务网格(Istio)通过在微服务的Pod的init容器中内置预先定义的iptables规则，实现对微服务的Pod进出口数据的劫持，进而完成数据透明并引流至Sidecar容器即安全引擎中。
图1为相关技术中进行数据劫持并转发至安全引擎的过程示意图。其中，Pod A与Pod B位于云原生场景下Kubernetes集群的同一个设备中，其中该设备还可以被称为节点，Pod A的业务容器将数据发送Pod B的业务容器时，首先PodA所在的设备的套接口(Socket)拦截数据，并将数据发送至传输控制协议(Transmission Control Protocol，TCP)/网际网络协议(Intellectual Property，IP)层，TCP/IP层通过预先定义的iptables规则，将数据发送至Device，Device通过回环(Loopback)的方式，使得数据重新依次经过Device、TCP/IP层及Socket到达到Pod A的Sidecar容器中，Pod A的Sidecar容器对该数据进行校验，判断该数据是否为恶意数据，若确定该数据并非恶意数据，则Pod A的Sidecar容器将该数据转发至Pod B中。由图1可知，在将Pod A的业务容器的数据定向到Pod A的Sidecar容器中时，共经过两次底层协议栈，其中底层协议栈指的是Device及TCP/IP层，因此数据传输的通路较长，该方案在网络I/O不构成主要瓶颈的系统中并无不妥之处，但在面对云原生场景下数千及上万个容器在短时间内进行大量并发通信的情况时会损失较大性能，从而导致设备的吞吐量大幅降低，恶意数据不能在第一时间得到有效处理。
发明内容
本申请实施例提供了一种安全防护方法、装置、设备及介质，用以解决相关技术中在进行数据劫持时，数据传输的通路较长，导致设备的吞吐量较低的问题。
第一方面，本申请实施例提供了一种安全防护方法，应用于设备的Socket的hook点，所述方法包括：
若检测到数据传输请求，则获取所述数据传输请求中携带的待处理数据；
通过挂载的伯克利包过滤器(extended Berkeley Packet Filter，eBPF)程序将所述待处理数据发送至所述安全引擎，其中，所述安全引擎被设置在所述设备中。
进一步地，若所述hook点为XDP hook点，所述获取所述数据传输请求中携带的待处理数据包括：
获取所述数据传输请求中携带的待处理数据及目的端口；
所述通过挂载的eBPF程序将所述待处理数据发送至所述安全引擎包括：
通过挂载的eBPF程序将所述目的端口调整为预先保存的安全引擎的端口，将调整端口后的待处理数据发送至所述安全引擎。
进一步地，若所述hook点为XDP hook点，所述获取所述数据传输请求中携带的待处理数据及目的端口之后，所述通过挂载的eBPF程序将所述目的端口调整为预先保存的安全引擎的端口，将调整端口后的待处理数据发送至所述安全引擎之前，所述方法还包括：
判断所述目的端口，是否为任一预先保存的待防护的Pod的端口，若是，则执行后续，通过挂载的eBPF程序将所述目的端口调整为预先保存的安全引擎的端口，将调整端口后的待处理数据发送至所述安全引擎的步骤。
进一步地，若所述hook点为TCP hook点，所述获取所述数据传输请求中携带的待处理数据包括：
获取所述数据传输请求中携带的待处理数据、目的IP地址及目的端口；
所述通过挂载的eBPF程序将所述待处理数据发送至所述安全引擎包括：
通过挂载的eBPF程序将所述目的IP地址及所述目的端口调整为安全引擎对应的IP地址及端口，将调整端口及IP地址后的待处理数据发送至所述安全引擎。
进一步地，若所述hook点为TCP hook点，所述获取所述数据传输请求中携带的待处理数据、目的IP地址及目的端口之后，所述通过挂载的eBPF程序将所述目的IP地址及所述目的端口调整为安全引擎对应的IP地址及端口，将调整端口及IP地址后的待处理数据发送至所述安全引擎之前，所述方法还包括：
判断所述目的IP地址及目的端口，是否为任一预先保存的待防护的Pod的IP地址及端口，若是，则执行后续，通过挂载的eBPF程序将所述目的IP地址及所述目的端口调整为安全引擎对应的IP地址及端口，将调整端口及IP地址后的待处理数据发送至所述安全引擎的步骤。
进一步地，所述方法还包括：
若接收到所述安全引擎返回的处理完成指令，则获取所述设备中源被访问Pod的标识及所述待处理数据；
通过bpf_msg_redirect_hash对所述待处理数据进行转发，将所述待处理数据绕过底层协议栈并返回至所述标识对应的所述源被访问Pod。
进一步地，所述获取所述设备中源被访问Pod的标识包括：
若所述hook点为XDP hook点，获取所述处理完成指令中携带的所述设备中源被访问Pod的目的端口；
若所述hook点为TCP hook点，获取所述处理完成指令中携带的所述设备中源被访问Pod的目的端口及目的IP地址。
进一步地，获取未调整端口时的所述待处理数据包括：
若所述hook点为XDP hook点，根据预先保存的端口和调整前的四元组信息的映射信息，获取所述目的端口对应的第一目标四元组信息；并根据预先保存的调整前的四元组信息和调整前的数据的映射信息，获取所述第一目标四元组信息对应的所述待处理数据；
若所述hook点为TCP hook点，根据预先保存的端口及IP地址和调整前的四元组信息的映射信息，获取所述目的端口及所述目的IP地址对应的第二目标四元组信息；并根据预先保存的调整前的四元组信息和调整前的数据的映射信息，获取所述第二目标四元组信息对应的所述待处理数据。
第二方面，本申请实施例还提供了一种安全防护装置，所述装置包括：
检测获取模块，用于若检测到数据传输请求，则获取所述数据传输请求中携带的待处理数据；
处理模块，用于通过挂载的eBPF程序将所述待处理数据发送至所述安全引擎，其中，所述安全引擎被设置在所述设备中。
进一步地，所述检测获取模块，具体用于若所述hook点为XDP hook点，获取所述数据传输请求中携带的待处理数据及目的端口；
所述处理模块，具体用于通过挂载的eBPF程序将所述目的端口调整为预先保存的安全引擎的端口，将调整端口后的待处理数据发送至所述安全引擎。
进一步地，所述处理模块，还用于若所述hook点为XDP hook点，判断所述目的端口，是否为任一预先保存的待防护的Pod的端口，若是，则执行后续，通过挂载的eBPF程序将所述目的端口调整为预先保存的安全引擎的端口，将调整端口后的待处理数据发送至所述安全引擎的步骤。
进一步地，所述检测获取模块，具体用于若所述hook点为TCP hook点，获取所述数据传输请求中携带的待处理数据、目的IP地址及目的端口；
所述处理模块，具体用于通过挂载的eBPF程序将所述目的IP地址及所述目的端口调整为安全引擎对应的IP地址及端口，将调整端口及IP地址后的待处理数据发送至所述安全引擎。
进一步地，所述处理模块，还用于若所述hook点为TCP hook点，判断所述目的IP地址及目的端口，是否为任一预先保存的待防护的Pod的IP地址及端口，若是，则执行后续，通过挂载的eBPF程序将所述目的IP地址及所述目的端口调整为安全引擎对应的IP地址及端口，将调整端口及IP地址后的待处理数据发送至所述安全引擎的步骤。
进一步地，所述处理模块，还用于若接收到所述安全引擎返回的处理完成指令，则获取所述设备中源被访问Pod的标识及所述待处理数据；通过bpf_msg_redirect_hash对所述待处理数据进行转发，将所述待处理数据绕过底层协议栈并返回至所述标识对应的所述源被访问Pod。
进一步地，所述处理模块，具体用于若所述hook点为XDP hook点，获取所述处理完成指令中携带的所述设备中源被访问Pod的目的端口；若所述hook点为TCP hook点，获取所述处理完成指令中携带的所述设备中源被访问Pod的目的端口及目的IP地址。
进一步地，所述处理模块，具体用于若所述hook点为XDP hook点，根据预先保存的端口和调整前的四元组信息的映射信息，获取所述目的端口对应的第一目标四元组信息；并根据预先保存的调整前的四元组信息和调整前的数据的映射信息，获取所述第一目标四元组信息对应的所述待处理数据；若所述hook点为TCP hook点，根据预先保存的端口及IP地址和调整前的四元组信息的映射信息，获取所述目的端口及所述目的IP地址对应的第二目标四元组信息；并根据预先保存的调整前的四元组信息和调整前的数据的映射信息，获取所述第二目标四元组信息对应的所述待处理数据。
第三方面，本申请实施例还提供了一种电子设备，所述电子设备至少包括处理器和存储器，所述处理器用于执行存储器中存储的计算机程序时执行上述任一安全防护方法的步骤。
第四方面，本申请实施例还提供了一种计算机可读存储介质，其存储有计算机程序，所述计算机程序被处理器执行时执行上述任一安全防护方法的步骤。
在本申请实施例中，设备的Socket的hook点若检测到数据传输请求，则获取该数据传输请求中携带的待处理数据，并通过挂载的eBPF程序将待处理数据发送至安全引擎，其中，所述安全引擎被设置在设备中。由于在本申请实施例中，hook点在检测到数据传输请求后，获取数据传输请求中携带的待处理数据，并通过挂载的eBPF程序将待处理数据发送至安全引擎，该过程无需经过底层协议栈，因此可以在将数据劫持至安全引擎的过程中，缩短数据传输的通路，从而提高设备的吞吐量。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为相关技术中进行数据劫持并转发至安全引擎的过程示意图；
图2为本申请实施例提供的一种安全防护过程示意图；
图3为本申请实施例提供的一种将待处理数据发送至安全引擎的过程示意图；
图4为本申请实施例提供的一种场景中的设备示意图；
图5为本申请实施例提供的另一种场景中的设备示意图；
图6为相关技术中安全引擎将数据返回至源被访问Pod的过程示意图；
图7为本申请实施例提供的将待处理数据返回至源被访问Pod的过程示意图；
图8为本申请实施例提供的一种XDP hook点将待处理数据发送至安全引擎的过程示意图；
图9为本申请实施例提供的一种TCP hook点将待处理数据发送至安全引擎的过程示意图；
图10为本申请实施例提供的一种安全防护装置的结构示意图；
图11为本申请实施例提供的一种电子设备的结构示意图。
具体实施方式
下面将结合附图对本申请作进一步地详细描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
为了在将数据发送至安全引擎的过程中，降低数据传输的路径，提升设备的吞吐量，本申请实施例提供了一种安全防护方法、装置、设备及介质。
该安全防护方法包括：应用于设备的Socket的hook点若检测到数据传输请求，则获取该数据传输请求中携带的待处理数据，并通过挂载的eBPF程序将待处理数据发送至安全引擎，其中，安全引擎被设置在设备中。
实施例1：
图2为本申请实施例提供的一种安全防护过程示意图，该过程包括以下步骤：
S201：若检测到数据传输请求，则获取所述数据传输请求中携带的待处理数据。
本申请实施例提供的安全防护方法应用于设备的Socket的hook点，该设备为云原生场景下Kubernetes集群中的设备，该hook点可以为网卡驱动层的XDP hook点，也可以为TC hook点或TCP hook点，其中，Socket在该设备的内核中。
为了将数据拦截至安全引擎，在进行数据传输时，hook点可以检测到数据传输请求，其中，该数据传输请求可以为本申请实施例中所描述的设备的Pod向同一设备中的另一Pod发送的，也可以为云原生场景下Kubernetes集群外的设备中的Pod向本申请实施例中所描述的设备的Pod发送的。hook点在检测到数据传输请求之后，可以获取数据传输请求中携带的待处理数据。
在本申请实施例中，在Pod向另一个Pod发送数据传输请求时，会发起Linux内核connect系统调用，因此hook点可以检测到数据传输请求。
S202：通过挂载的eBPF程序将所述待处理数据发送至安全引擎，其中，所述安全引擎被设置在所述设备中。
在获取到待处理数据后，为了准确地进行安全防护，hook点可以将待处理数据发送至安全引擎，具体的，hook点可以通过自身挂载的eBPF程序将待处理数据发送至安全引擎，该安全引擎为云原生场景中的防护引擎，可对微服务恶意流量即恶意的数据进行防护，该安全引擎可以为WAF或Envoy。
值得说明的是，使用挂载的eBPF程序可以在设备内核的Socket完成待处理数据的转发，而不用经过底层协议栈，从而可以缩短整体数据传输的通路，使得性能上有较大提升。
图3为本申请实施例提供的一种将待处理数据发送至安全引擎的过程示意图。
图3对应的场景为设备中的PodC向PodD发送数据传输请求，Socket可以检测到该数据传输请求，并通过eBPF程序将数据传输请求中携带的待处理数据转发至安全引擎，具体的，该过程是由Socket的hook点执行的，图3所描述的安全引擎可以为Envoy。由图3可知，采用本申请实施例所描述的方法，在Socket这一层面即可完成数据转发，带来了设备吞吐量的提升，无需经过底层协议栈。
云原生场景下Kubernetes集群中同一Service包含多个Pod，同一设备中包含多个Service和一个安全引擎。本申请实施例中提供的方案可以适应云原生场景下应用的普遍容器化、微服务架构、容器的编排调度等特性，并解决数据难以防护的问题。
在本申请实施例中，当内核中触发了与hook相关的事件，例如发生系统调用时，挂载在hook点中的eBPF程序就会执行。由于流经云原生场景中的数据会首先通过内核的物理网卡驱动再到底层协议栈，最后再到达用户态的应用程序中，因此数据越早被eBPF程序拦截处理，整体的通路的长度就越短，从而整体设备吞吐量消耗也会越低，而本申请实施例的方法，可以尽早的拦截数据，从而缩短数据的通路，提升设备的吞吐量。
由于在本申请实施例中，hook点在检测到数据传输请求后，获取数据传输请求中携带的待处理数据，并通过挂载的eBPF程序将待处理数据发送至安全引擎，该过程无需经过底层协议栈，因此可以在将数据发送至安全引擎的过程中，缩短数据传输的通路，从而提高设备的吞吐量。
实施例2：
为了准确有效地进行安全防护，在上述实施例的基础上，在本申请实施例中，若所述hook点为XDP hook点，所述获取所述数据传输请求中携带的待处理数据包括：
获取所述数据传输请求中携带的待处理数据及目的端口；
所述通过挂载的eBPF程序将所述待处理数据发送至所述安全引擎包括：
通过挂载的eBPF程序将所述目的端口调整为预先保存的安全引擎的端口，将调整端口后的待处理数据发送至所述安全引擎。
在云原生场景下，若是Kubernetes集群之外的设备的Pod向本申请实施例所描述的设备的Pod发送数据传输请求，则数据传输请求携带的目的IP地址为该设备的IP地址，并且携带的目的端口为被发送数据的Pod的端口，为了将待处理数据发送至安全引擎，hook点可以将待处理数据中的目的端口，调整为安全引擎的端口。其中，安全引擎的IP地址与目的IP地址一致，因此无需进行目的IP地址的修改。
hook点中的XDP hook点可以应用于Kubernetes集群之外的设备的Pod向本申请实施例所描述的设备的Pod发送数据传输请求这一场景，其中，Kubernetes集群之外的设备的Pod向本申请实施例所描述的设备的Pod发送的数据传输请求，可以被成为东西向流量。具体的，可以将XDP hook点配置为可以检测到Kubernetes集群之外的设备的Pod向本申请实施例所描述的设备的Pod发送数据传输请求。若hook点为XDP hook点，则说明当前检测到的数据传输请求为，Kubernetes集群之外的设备的Pod向本申请实施例所描述的设备的Pod发送的，为了准确地进行安全防护，XDP hook点在获取数据传输请求中携带的待处理数据后，可以获取数据传输请求中携带的待处理数据及目的端口，其中，该目的端口可以为从待处理数据的报文头中获取到的，具体的，在进行数据传输时，如何从被传输的数据中获取数据传输的目的端口为现有技术，在此不再赘述。在获取到该目的端口后，XDP hook点通过挂载的eBPF程序将目的端口调整为预先保存的安全引擎的端口，从而将调整端口后的待处理数据发送至安全引擎。
需要说明的是，云原生场景的Kubernetes集群中，每个Pod通过Service的方式暴露至Kubernetes集群外部以被访问。云原生场景的Kubernetes集群内Pod间的相互访问属于东西向流量，Kubernetes集群外部的设备中服务的Pod访问Kubernetes集群内部的某个服务的Pod时，属于南北向流量。由于两种不同的流量类型涉及同主机、跨主机通信，也就是同设备、跨设备通信，因而eBPF程序需要挂载在不同hook点上，通过不同hook点进行数据传输请求的拦截检测，进而将待处理数据发送至安全引擎。
实施例3：
为了准确有效地进行安全防护，在上述各实施例的基础上，在本申请实施例中，若所述hook点为XDP hook点，所述获取所述数据传输请求中携带的待处理数据及目的端口之后，所述通过挂载的eBPF程序将所述目的端口调整为预先保存的安全引擎的端口，将调整端口后的待处理数据发送至所述安全引擎之前，所述方法还包括：
判断所述目的端口，是否为任一预先保存的待防护的Pod的端口，若是，则执行后续，通过挂载的eBPF程序将所述目的端口调整为预先保存的安全引擎的端口，将调整端口后的待处理数据发送至所述安全引擎的步骤。
由于可能存在某些Pod无需被防护，因此XDP hook点在将待处理数据发送至安全引擎之前，可以先判断原本要接收该数据传输请求的Pod是否为无需被防护的Pod，若为需要防护的Pod，则将数据传输请求中携带的待处理数据发送至安全引擎。
为了准确有效地进行安全防护，设备本地预先保存有每个待防护的Pod的端口，XDP hook点在获取到目的端口后，可以判断数据传输请求中携带的目的端口，是否为任一预先保存的待防护的Pod的端口，若目的端口为任一预先保存的待防护的Pod的端口，则说明原本要接收数据传输请求的Pod为需防护的Pod，则执行后续，挂载的eBPF程序将目的端口调整为预先保存的安全引擎的端口，将调整端口后的待处理数据发送至所述安全引擎的步骤。若数据传输请求中携带的目的端口并非任一预先保存的待防护的Pod的端口，则说明原本要接收数据传输请求的Pod为无需防护的Pod，则无需对目的端口进行调整，将待处理数据发送至目的端口对应的Pod即可。其中，预先保存的每个待防护的Pod的端口可以被保存在svc_list中，svc_list为一种eBPF map，待防护的Pod在本申请实施例中还可以被称为需要引流的Pod。
其中，当云原生场景中Kubernetes集群之外的设备的Pod向本申请实施例所描述的设备的Pod发送数据传输请求时，XDP hook点可以先查询svc_list，根据svc_list中是否存在任一待防护的Pod的端口为目的端口，确定源被访问Pod即原本要接收数据传输请求的Pod是否需要被防护，即确定源被访问Pod是否需要引流，不需要则绕过，不必将待处理数据发送至安全引擎，若需要则通过修改目的端口为安全引擎的端口，将待处理数据发送至安全引擎进行防护。其中，XDP hook点中负责该部分的程序可以被称为eBPF程序中的bpf_tc子程序。
由于安全引擎由Kubernetes的Daemonset资源部署,且原本数据传输请求中携带的目的IP地址便是本申请实施例所描述的设备的IP地址，若将待处理数据发送至安全引擎，则将目的IP地址调整为安全引擎所在的设备的IP地址即可，而安全引擎设置设备中，在因此目的IP地址可以使用设备的IP地址,只需将目的端口修改为安全引擎的端口即可。
图4为本申请实施例提供的一种场景中的设备示意图。
图4中的hook点指的是XDP hook点，由图4可知，设备Node1及设备Node2中均包含微服务，其中，设备Node1中包含微服务SVC1和安全引擎，设备Node2中包含微服务SVC2和另一个安全引擎，图4所描述的安全引擎为WAF，微服务SVC1包含Pod1、Pod2和Pod3，微服务SVC2包含Pod4、Pod5和Pod6。其中，若Kubernetes集群外的设备的Pod向设备Node1中的Pod发送数据传输请求，向设备Node2中的Pod发送数据传输请求，则通过XDP hook点进行数据传输请求的检测及转发至安全引擎等操作。
在本申请实施例中，TCP hook点在修改目的端口时，具体可以是修改所有满足条件的ingress数据和egress数据，修改数据包的同时需要对校验。具体校验的可以是数据中是否包含安全引擎的端口。
实施例4：
为了准确有效地进行安全防护，在上述各实施例的基础上，在本申请实施例中，若所述hook点为TCP hook点，所述获取所述数据传输请求中携带的待处理数据包括：
获取所述数据传输请求中携带的待处理数据、目的IP地址及目的端口；
所述通过挂载的eBPF程序将所述待处理数据发送至所述安全引擎包括：
通过挂载的eBPF程序将所述目的IP地址及所述目的端口调整为安全引擎对应的IP地址及端口，将调整端口及IP地址后的待处理数据发送至所述安全引擎。
在云原生场景中，若是Kubernetes集群中的设备的Pod向同一设备的另一个Pod发送数据传输请求，则数据传输请求携带的目的IP地址为该另一个Pod在该设备中的IP地址，该IP地址为内网IP地址，并且携带的目的端口为该另一个Pod的端口，为了将待处理数据发送至安全引擎，hook点可以将待处理数据中目的IP地址及目的端口，调整为安全引擎的IP地址端口。
hook点中的TCP hook点可以用于是Kubernetes集群中的设备的Pod向同一设备的另一个Pod发送数据传输请求这一场景，具体的，可以将TCP hook点配置为可以检测到Kubernetes集群中的设备的Pod向同一设备的Pod发送数据传输请求。若hook点为TCP hook点，则说明当前检测到的数据传输请求为，Kubernetes集群中的设备的Pod向同一设备的Pod发送的，为了准确地进行安全防护，TCP hook点在获取数据传输请求中携带的待处理数据时，可以获取数据传输请求中携带的待处理数据、目的IP地址及目的端口，其中，该目的IP地址及目的端口可以为从待处理数据的报文头中获取到的，具体的，在进行数据传输时，如何从被传输的数据中获取数据传输的目的IP地址及目的端口为现有技术，在此不再赘述。在获取到该目的IP地址及目的端口后，TCP hook点通过挂载的eBPF程序将目的端口调整为预先保存的安全引擎的端口，将目的IP地址调整为预先保存的安全引擎的IP地址，将调整端口及IP地址后的待处理数据发送至安全引擎。
其中，Kubernetes集群之外的设备的Pod向本申请实施例所描述的设备的Pod发送数据传输请求，可以被称为东西向流量，在东西向流量劫持和引流过程中，因为eBPF程序挂载在内核的TCP hook点，因而可对连接(connect)、sockops、getsockopt等调用产生的数据传输请求进行劫持。
实施例5：
为了准确有效地进行安全防护，在上述各实施例的基础上，在本申请实施例中，若所述hook点为TCP hook点，所述获取所述数据传输请求中携带的待处理数据、目的IP地址及目的端口之后，所述通过挂载的eBPF程序将所述目的IP地址及所述目的端口调整为安全引擎对应的IP地址及端口，将调整端口及IP地址后的待处理数据发送至所述安全引擎之前，所述方法还包括：
判断所述目的IP地址及目的端口，是否为任一预先保存的待防护的Pod的IP地址及端口，若是，则执行后续，通过挂载的eBPF程序将所述目的IP地址及所述目的端口调整为安全引擎对应的IP地址及端口，将调整端口及IP地址后的待处理数据发送至所述安全引擎的步骤。
由于可能存在某些Pod无需被防护，因此TCP hook点在将待处理数据发送至安全引擎之前，可以先判断原本要接收该数据传输请求的Pod是否为无需被防护的Pod，若为需要防护的Pod，则将数据传输请求中携带的待处理数据发送至安全引擎。
为了准确有效地进行安全防护，设备本地预先保存有每个待防护的Pod的IP地址及端口，TCP hook点在获取到的目的IP地址和目的端口，可以判断数据传输请求中携带的目的IP地址及目的端口，是否为任一预先保存的待防护的Pod的IP地址及端口，若目的IP地址及目的端口为任一预先保存的待防护的Pod的IP地址及端口，则说明原本要接收数据传输请求的Pod为需防护的Pod，则执行后续，通过挂载的eBPF程序将目的IP地址及目的端口调整为安全引擎对应的IP地址及端口，将调整端口及IP地址后的待处理数据发送至安全引擎的步骤。若目的IP地址及目的端口并非任一预先保存的待防护的Pod的IP地址及端口，则说明原本要接收数据传输请求的Pod为无需防护的Pod，则无需对待处理数据进行调整，将待处理数据发送至目的IP地址及目的端口对应的Pod即可。其中，预先保存的每个待防护的Pod的IP地址和端口可以被保存在pod_list中，pod_list为一种eBPF map，待防护的Pod还可以被称为需要引流的Pod。在本申请实施例中，通过借助eBPF的map机制准确有效地实现安全防护。
其中，当云原生场景中Pod向同设备的Pod发起数据传输请求时，TCP hook点可以先查询pod_list，根据pod_list中是否存在任一待防护的Pod的IP地址及端口分别为目的IP地址及目的端口，确定源被访问Pod是否需要防护，即确定源被访问Pod是否需要引流，不需要则绕过，不必将待处理数据发送至安全引擎，若需要则通过修改目的IP地址和目的端口为安全引擎的IP地址及端口，将待处理数据发送至安全引擎进行防护。其中，TCP hook点中负责该部分的程序可以被称为bpf_connect程序。
图5为本申请实施例提供的另一种场景中的设备示意图。
图5中的hook点指的是TCP hook点，由图5可知，设备Node1中包含微服务SVC1、微服务SVC2和安全引擎微服务SVC1包含Pod1、Pod2和Pod3，微服务SVC2包含Pod4、Pod5和Pod6。其中，若设备Node1中的Pod向设备Node1中的另一个Pod发送数据传输请求，则通过TCP hook点进行数据传输请求的检测及拦截等操作。
实施例6：
为了准确地对待处理数据进行处理，在上述各实施例的基础上，在本申请实施例中，所述方法还包括：
若接收到所述安全引擎返回的处理完成指令，则获取所述设备中源被访问Pod的标识及所述待处理数据；
通过bpf_msg_redirect_hash对所述待处理数据进行转发，将所述待处理数据绕过底层协议栈并返回至所述标识对应的所述源被访问Pod。
在实际应用场景中，安全引擎在接收到待处理数据后，会对接收到的待处理数据进行处理，具体会判断待处理数据是否为恶意数据，若待处理数据并非恶意数据，则hook点会将待处理数据返回至源被访问Pod，该源被访问Pod即为原本接收数据传输请求的Pod。
在本申请实施例中，若安全引擎确定待处理数据并未恶意数据，则安全引擎会返回处理完成指令至hook点，其中，安全引擎如何向同一设备的Socket的hook点返回一个指令为现有技术，在此不再赘述，若hook点接收到安全引擎返回的处理完成指令，则hook点可以获取设备中源被访问Pod的标识及待处理数据，其中，该待处理数据可以携带在处理完成指令中，并且hook点在将调整端口后的待处理数据发送至安全引擎时，可以将数据传输请求中携带的源被访问Pod的标识发送至安全引擎，安全引擎在返回处理完成指令时，可以将源被访问Pod的标识携带在处理完成指令中，hook点可以在处理完成指令中获取携带的待处理数据及源被访问Pod的标识，在获取到源被访问Pod的标识及待处理数据后，hook点通过bpf_msg_redirect_hash对待处理数据进行转发，将待处理数据绕过底层协议栈并返回至标识对应的源被访问Pod。需要说明的是，通过bpf_msg_redirect_hash对待处理数据进行转发可以绕过底层协议栈，加速将待处理数据发送至源被访问Pod的过程。
图6为相关技术中安全引擎将数据返回至源被访问Pod的过程示意图。
由图6可知，安全引擎将数据返回至Socket，Socket将数据发送至TCP/IP层，TCP/IP层通过预先定义的iptables规则，将数据发送至Device，Device通过eth0的方式，使得数据新依次经过Device、iptables、TCP/IP层及Socket到达到Pod B的业务容器中。
图7为本申请实施例提供的将待处理数据返回至源被访问Pod的过程示意图。
由图7可知，Socket的hook点在获取到待处理数据后，通过bpf_msg_redirect_hash将待处理数据进行发送至源被访问Pod。由图7及图6可知，采用本申请实施例所提供的方式，可以绕过底层协议栈，提升数据传输的速度。
为了准确有效地对待处理数据进行处理，在上述各实施例的基础上，在本申请实施例中，所述获取所述设备中源被访问Pod的标识包括：
若所述hook点为XDP hook点，获取所述处理完成指令中携带的所述设备中源被访问Pod的目的端口；
若所述hook点为TCP hook点，获取所述处理完成指令中携带的所述设备中源被访问Pod的目的端口及目的IP地址。
在云原生场景下，若是Kubernetes集群之外的设备的Pod向本申请实施例所描述的设备的Pod发送数据传输请求，此时本申请实施例所描述的设备的Pod即为本申请实施例所描述的源被访问Pod，此时hook点为XDP hook点，为了将待处理数据发送至源被访问Pod，XDP hook点在获取到安全引擎发送的处理完成指令后，可以获取处理完成指令中携带的设备中源被访问Pod的目的端口。具体的，在设备本地保存有源被访问Pod的目的端口，和调整端口后的待处理数据中的四元组信息的映射信息，安全引擎在接收到调整端口后的待处理数据后，可以获取待处理数据对应的四元组信息，其中，可以在待处理数据的报文头中获取对应的四元组信息，具体的如何在数据中获取对应的四元组信息为现有技术，在此不再赘述，在获取到四元组信息后，安全引擎可以根据保存的该映射信息获取对应的目的端口，并将目的端口携带在处理完成指令中发送，该目的端口即为源被访问Pod的端口。保存该映射信息的方式为：hook点在将目的端口调整为预先保存的安全引擎的端口后，保存目的端口和调整端口后的待处理数据中的四元组信息的映射信息，具体的可以将该映射信息保存在pair_original_dst中。其中，pair_original_dst为一种eBPF map。具体的，安全引擎可以利用bpf_getsockopts这一程序，从pair_original_dst取出四元组信息对应的目的端口并返回,相当于与hook点连接建立成功。
在云原生场景下，若Kubernetes集群中的设备的Pod向同一设备的另一个Pod发送数据传输请求，此时该另一个Pod即为本申请实施例所描述的源被访问Pod，此时hook点为TCP hook点，为了将待处理数据发送至源被访问Pod，TCP hook点在获取到安全引擎发送的处理完成指令后，可以获取处理完成指令中携带的设备中源被访问Pod的目的IP地址及目的端口。具体的，在设备本地保存有源被访问Pod的目的IP地址及目的端口，和调整IP地址和端口后的待处理数据中的四元组信息的映射信息，安全引擎在接收到调整端口后的待处理数据后，可以获取待处理数据对应的四元组信息，其中，可以在待处理数据的报文头中获取对应的四元组信息，具体的如何在数据中获取对应的四元组信息为现有技术，在此不再赘述，在获取到四元组信息后，安全引擎可以根据保存的该映射信息获取对应的目的IP地址及目的端口，并将目的IP地址及目的端口携带在处理完成指令中发送，该目的IP地址及目的端口即为源被访问Pod的IP地址及端口。保存该映射信息的方式为：hook点在将目的IP地址及目的端口调整为预先保存的安全引擎的IP地址及端口后，保存目的IP地址及目的端口和调整端口后的待处理数据中的四元组信息的映射信息，具体的可以将该映射信息保存在pair_original_dst中。其中，pair_original_dst为一种eBPF map。
实施例7：
为了准确地获取到待处理数据，在上述各实施例的基础上，在本申请实施例中，获取未调整端口时的所述待处理数据包括：
若所述hook点为XDP hook点，根据预先保存的端口和调整前的四元组信息的映射信息，获取所述目的端口对应的第一目标四元组信息；并根据预先保存的调整前的四元组信息和调整前的数据的映射信息，获取所述第一目标四元组信息对应的所述待处理数据；
若所述hook点为TCP hook点，根据预先保存的端口及IP地址和调整前的四元组信息的映射信息，获取所述目的端口及所述目的IP地址对应的第二目标四元组信息；并根据预先保存的调整前的四元组信息和调整前的数据的映射信息，获取所述第二目标四元组信息对应的所述待处理数据。
为了准确地获取到待处理数据，设备本地保存有端口和调整前的四元组信息的映射信息，若hook点为XDP hook点，则XDP hook点根据本地保存有端口和调整前的四元组信息的映射信息，获取目的端口对应的第一目标四元组信息，该第一目标四元组信息即为调整端口前待处理数据对应的四元组信息，为了准确地获取到待处理数据，设备本地保存有调整前的四元组信息和调整前的数据的映射信息，XDP hook点根据本地保存的调整前的四元组信息和调整前的数据的映射信息，获取第一目标四元组信息对应的待处理数据。其中，端口和调整前的四元组信息的映射信息可以被保存在cookie_original_dst中，调整前的四元组信息和调整前的数据的映射信息被保存在sock_pair_map中。
图8为本申请实施例提供的一种XDP hook点将待处理数据发送至安全引擎的过程示意图。
由图8可知，XDP hook点在检测到数据传输请求后，获取数据传输请求中携带的待处理数据及目的端口，并由bpf_tc子程序判断svr_list中是否包含该目的端口，若不包含该目的端口，则调整待处理数据的目的端口，并将调整端口后的待处理数据发送至安全引擎，安全引擎判断接收到的待处理数据是否为恶意数据，若并非恶意数据，则通过pair_original_dst中保存的端口和四元组信息的映射信息，获取四元组信息对应的目的端口，将该目的端口携带在处理完成指令中发送至XDP hook点。
为了准确地获取到待处理数据，设备本地保存有IP地址及端口和调整前的四元组信息的映射信息，若hook点为TCP hook点，则TCP hook点根据本地保存有IP地址及端口和调整前的四元组信息的映射信息，获取目的IP地址及目的端口对应的第二目标四元组信息，该第二目标四元组信息即为调整IP地址及端口前待处理数据对应的四元组信息，为了准确地获取到待处理数据，设备本地保存有调整前的四元组信息和调整前的数据的映射信息，TCP hook点根据本地保存的调整前的四元组信息和调整前的数据的映射信息，获取第二目标四元组信息对应的待处理数据。其中，IP地址及端口和调整前的四元组信息的映射信息可以被保存在cookie_original_dst中，调整前的四元组信息和调整前的数据的映射信息被保存在sock_pair_map中。TCP hook点可以通过redir这一子程序调整端口前的获取待处理数据。
在本申请实施例中，为了将映射信息保存，TCP hook点在调整待处理数据的端口和IP地址后，TCP hook点的bpf_connect子程序可以先查询pod_list，判断源被访问Pod是否需要被防护，若需要则修改目的IP地址和目的端口为安全引擎的IP和端口，并将当前Socket的cookie即调整前的待处理数据和调整前的四元组信息的映射信息写入cookie_original_dst中。
TCP hook点的bpf_sockops子程序可以先判断调整前的待处理数据是否在cookie_original_dst中，如果存在，则将调整前的四元组信息和调整前的数据的映射信息保存至sock_pair_map中，同时将待处理数据调整后的四元组信息和原始目的IP地址及目的端口的映射信息写入pair_original_dst中，具体可以通过Key/Value形式的形式写入。
在本申请实施例中，通过借助eBPF的map机制，使得通用的数据结构存储不同类型的数据，提供了用户态和内核态数据交互、数据存储、多程序共享数据等功能。
图9为本申请实施例提供的一种TCP hook点将待处理数据发送至安全引擎的过程示意图。
由图9可知，Socket的TCP hook点在检测到数据传输请求后，获取数据传输请求中携带的待处理数据、目的IP地址及目的端口，并由bpf_connect子程序判断pod_list中是否包含某一Pod的IP地址及端口分别为该目的IP地址及目的端口，若不包含，则调整待处理数据的目的IP地址及目的端口，将调整后的待处理数据发送至安全引擎，并将调整前的待处理数据和调整前的四元组信息的映射信息写入cookie_original_dst中。bpf_sockops子程序将调整前的四元组信息和调整前的数据的映射信息保存至sock_pair_map中，同时将待处理数据调整后的四元组信息和原始目的IP地址及目的端口的映射信息写入pair_original_dst中。安全引擎若确定接收到的待处理数据并非恶意数据，则通过pair_original_dst中保存的IP地址及端口和四元组信息的映射信息，获取四元组信息对应的目的IP地址及目的端口，将该目的IP地址及目的端口携带在处理完成指令中发送至TCP hook点，TCP hook点根据预先保存的多个映射信息获取调整前的待处理数据，具体如何获取待处理数据在上述实施例中已经描述过，在此不再赘述，并将调整前的待处理数据发送至源被访问Pod。
实施例8：
图10为本申请实施例提供的一种安全防护装置的结构示意图，所述装置包括：
检测获取模块1001，用于若检测到数据传输请求，则获取所述数据传输请求中携带的待处理数据；
处理模块1002，用于通过挂载的eBPF程序将所述待处理数据发送至所述安全引擎，其中，所述安全引擎被设置在所述设备中。
进一步地，所述检测获取模块1001，具体用于若所述hook点为XDP hook点，获取所述数据传输请求中携带的待处理数据及目的端口；
所述处理模块1002，具体用于通过挂载的eBPF程序将所述目的端口调整为预先保存的安全引擎的端口，将调整端口后的待处理数据发送至所述安全引擎。
进一步地，所述处理模块1002，还用于若所述hook点为XDP hook点，判断所述目的端口，是否为任一预先保存的待防护的Pod的端口，若是，则执行后续，通过挂载的eBPF程序将所述目的端口调整为预先保存的安全引擎的端口，将调整端口后的待处理数据发送至所述安全引擎的步骤。
进一步地，所述检测获取模块1001，具体用于若所述hook点为TCP hook点，获取所述数据传输请求中携带的待处理数据、目的IP地址及目的端口；
所述处理模块1002，具体用于通过挂载的eBPF程序将所述目的IP地址及所述目的端口调整为安全引擎对应的IP地址及端口，将调整端口及IP地址后的待处理数据发送至所述安全引擎。
进一步地，所述处理模块1002，还用于若所述hook点为TCP hook点，判断所述目的IP地址及目的端口，是否为任一预先保存的待防护的Pod的IP地址及端口，若是，则执行后续，通过挂载的eBPF程序将所述目的IP地址及所述目的端口调整为安全引擎对应的IP地址及端口，将调整端口及IP地址后的待处理数据发送至所述安全引擎的步骤。
进一步地，所述处理模块1002，还用于若接收到所述安全引擎返回的处理完成指令，则获取所述设备中源被访问Pod的标识及所述待处理数据；通过bpf_msg_redirect_hash对所述待处理数据进行转发，将所述待处理数据绕过底层协议栈并返回至所述标识对应的所述源被访问Pod。
进一步地，所述处理模块1002，具体用于若所述hook点为XDP hook点，获取所述处理完成指令中携带的所述设备中源被访问Pod的目的端口；若所述hook点为TCP hook点，获取所述处理完成指令中携带的所述设备中源被访问Pod的目的端口及目的IP地址。
进一步地，所述处理模块1002，具体用于若所述hook点为XDP hook点，根据预先保存的端口和调整前的四元组信息的映射信息，获取所述目的端口对应的第一目标四元组信息；并根据预先保存的调整前的四元组信息和调整前的数据的映射信息，获取所述第一目标四元组信息对应的所述待处理数据；若所述hook点为TCP hook点，根据预先保存的端口及IP地址和调整前的四元组信息的映射信息，获取所述目的端口及所述目的IP地址对应的第二目标四元组信息；并根据预先保存的调整前的四元组信息和调整前的数据的映射信息，获取所述第二目标四元组信息对应的所述待处理数据。
实施例9：
图11为本申请实施例提供的一种电子设备的结构示意图，如图11所示，包括：处理器1101、通信接口1102、存储器1103和通信总线1104，其中，处理器1101，通信接口1102，存储器1103通过通信总线1104完成相互间的通信。
所述存储器1103中存储有计算机程序，当所述程序被所述处理器1101执行时，使得所述处理器1101执行如下步骤：
若检测到数据传输请求，则获取所述数据传输请求中携带的待处理数据；
通过挂载的eBPF程序将所述待处理数据发送至所述安全引擎，其中，所述安全引擎被设置在所述设备中。
进一步地，所述处理器1101，具体用于若所述hook点为XDP hook点，取所述数据传输请求中携带的待处理数据及目的端口；
所述处理器1101，具体用于通过挂载的eBPF程序将所述目的端口调整为预先保存的安全引擎的端口，将调整端口后的待处理数据发送至所述安全引擎。
进一步地，所述处理器1101，还用于若所述hook点为XDP hook点，判断所述目的端口，是否为任一预先保存的待防护的Pod的端口，若是，则执行后续，通过挂载的eBPF程序将所述目的端口调整为预先保存的安全引擎的端口，将调整端口后的待处理数据发送至所述安全引擎的步骤。
进一步地，所述处理器1101，具体用于若所述hook点为TCP hook点，获取所述数据传输请求中携带的待处理数据、目的IP地址及目的端口；
所述通过挂载的eBPF程序将所述待处理数据发送至所述安全引擎包括：
通过挂载的eBPF程序将所述目的IP地址及所述目的端口调整为安全引擎对应的IP地址及端口，将调整端口及IP地址后的待处理数据发送至所述安全引擎。
进一步地，所述处理器1101，还用于若所述hook点为TCP hook点，判断所述目的IP地址及目的端口，是否为任一预先保存的待防护的Pod的IP地址及端口，若是，则执行后续，通过挂载的eBPF程序将所述目的IP地址及所述目的端口调整为安全引擎对应的IP地址及端口，将调整端口及IP地址后的待处理数据发送至所述安全引擎的步骤。
进一步地，所述处理器1101，还用于若接收到所述安全引擎返回的处理完成指令，则获取所述设备中源被访问Pod的标识及所述待处理数据；
通过bpf_msg_redirect_hash对所述待处理数据进行转发，将所述待处理数据绕过底层协议栈并返回至所述标识对应的所述源被访问Pod。
进一步地，所述处理器1101，具体用于若所述hook点为XDP hook点，获取所述处理完成指令中携带的所述设备中源被访问Pod的目的端口；
若所述hook点为TCP hook点，获取所述处理完成指令中携带的所述设备中源被访问Pod的目的端口及目的IP地址。
进一步地，所述处理器1101，具体用于若所述hook点为XDP hook点，根据预先保存的端口和调整前的四元组信息的映射信息，获取所述目的端口对应的第一目标四元组信息；并根据预先保存的调整前的四元组信息和调整前的数据的映射信息，获取所述第一目标四元组信息对应的所述待处理数据；
若所述hook点为TCP hook点，根据预先保存的端口及IP地址和调整前的四元组信息的映射信息，获取所述目的端口及所述目的IP地址对应的第二目标四元组信息；并根据预先保存的调整前的四元组信息和调整前的数据的映射信息，获取所述第二目标四元组信息对应的所述待处理数据。
上述服务器提到的通信总线可以是外设部件互连标准(Peripheral ComponentInterconnect，PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture，EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
通信接口1102用于上述电子设备与其他设备之间的通信。
存储器可以包括随机存取存储器(Random Access Memory，RAM)，也可以包括非易失性存储器(Non-Volatile Memory，NVM)，例如至少一个磁盘存储器。可选地，存储器还可以是至少一个位于远离前述处理器的存储装置。
上述处理器可以是通用处理器，包括中央处理器、网络处理器(NetworkProcessor，NP)等；还可以是数字指令处理器(Digital Signal Processing，DSP)、专用集成电路、现场可编程门陈列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。
实施例10：
在上述各实施例的基础上，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质内存储有可由电子设备执行的计算机程序，当所述程序在所述电子设备上运行时，使得所述电子设备执行时实现如下步骤：
所述存储器中存储有计算机程序，当所述程序被所述处理器执行时，使得所述处理器执行如下步骤：
若检测到数据传输请求，则获取所述数据传输请求中携带的待处理数据；
通过挂载的eBPF程序将所述待处理数据发送至所述安全引擎，其中，所述安全引擎被设置在所述设备中。
在一种可能的实施方式中，若所述hook点为XDP hook点，所述获取所述数据传输请求中携带的待处理数据包括：
获取所述数据传输请求中携带的待处理数据及目的端口；
所述通过挂载的eBPF程序将所述待处理数据发送至所述安全引擎包括：
通过挂载的eBPF程序将所述目的端口调整为预先保存的安全引擎的端口，将调整端口后的待处理数据发送至所述安全引擎。
在一种可能的实施方式中，若所述hook点为XDP hook点，所述获取所述数据传输请求中携带的待处理数据及目的端口之后，所述通过挂载的eBPF程序将所述目的端口调整为预先保存的安全引擎的端口，将调整端口后的待处理数据发送至所述安全引擎之前，所述方法还包括：
判断所述目的端口，是否为任一预先保存的待防护的Pod的端口，若是，则执行后续，通过挂载的eBPF程序将所述目的端口调整为预先保存的安全引擎的端口，将调整端口后的待处理数据发送至所述安全引擎的步骤。
在一种可能的实施方式中，若所述hook点为TCP hook点，所述获取所述数据传输请求中携带的待处理数据包括：
获取所述数据传输请求中携带的待处理数据、目的IP地址及目的端口；
所述通过挂载的eBPF程序将所述待处理数据发送至所述安全引擎包括：
通过挂载的eBPF程序将所述目的IP地址及所述目的端口调整为安全引擎对应的IP地址及端口，将调整端口及IP地址后的待处理数据发送至所述安全引擎。
在一种可能的实施方式中，若所述hook点为TCP hook点，所述获取所述数据传输请求中携带的待处理数据、目的IP地址及目的端口之后，所述通过挂载的eBPF程序将所述目的IP地址及所述目的端口调整为安全引擎对应的IP地址及端口，将调整端口及IP地址后的待处理数据发送至所述安全引擎之前，所述方法还包括：
判断所述目的IP地址及目的端口，是否为任一预先保存的待防护的Pod的IP地址及端口，若是，则执行后续，通过挂载的eBPF程序将所述目的IP地址及所述目的端口调整为安全引擎对应的IP地址及端口，将调整端口及IP地址后的待处理数据发送至所述安全引擎的步骤。
在一种可能的实施方式中，所述方法还包括：
若接收到所述安全引擎返回的处理完成指令，则获取所述设备中源被访问Pod的标识及所述待处理数据；
通过bpf_msg_redirect_hash对所述待处理数据进行转发，将所述待处理数据绕过底层协议栈并返回至所述标识对应的所述源被访问Pod。
在一种可能的实施方式中，所述获取所述设备中源被访问Pod的标识包括：
若所述hook点为XDP hook点，获取所述处理完成指令中携带的所述设备中源被访问Pod的目的端口；
若所述hook点为TCP hook点，获取所述处理完成指令中携带的所述设备中源被访问Pod的目的端口及目的IP地址。
在一种可能的实施方式中，获取未调整端口时的所述待处理数据包括：
若所述hook点为XDP hook点，根据预先保存的端口和调整前的四元组信息的映射信息，获取所述目的端口对应的第一目标四元组信息；并根据预先保存的调整前的四元组信息和调整前的数据的映射信息，获取所述第一目标四元组信息对应的所述待处理数据；
若所述hook点为TCP hook点，根据预先保存的端口及IP地址和调整前的四元组信息的映射信息，获取所述目的端口及所述目的IP地址对应的第二目标四元组信息；并根据预先保存的调整前的四元组信息和调整前的数据的映射信息，获取所述第二目标四元组信息对应的所述待处理数据。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (11)

1.一种安全防护方法，其特征在于，应用于设备的套接口Socket的hook点，所述方法包括：
若检测到数据传输请求，则获取所述数据传输请求中携带的待处理数据；
通过挂载的伯克利包过滤器eBPF程序将所述待处理数据发送至所述安全引擎，其中，所述安全引擎被设置在所述设备中。
2.根据权利要求1所述的方法，其特征在于，若所述hook点为XDP hook点，所述获取所述数据传输请求中携带的待处理数据包括：
获取所述数据传输请求中携带的待处理数据及目的端口；
所述通过挂载的eBPF程序将所述待处理数据发送至所述安全引擎包括：
通过挂载的eBPF程序将所述目的端口调整为预先保存的安全引擎的端口，将调整端口后的待处理数据发送至所述安全引擎。
3.根据权利要求2所述的方法，其特征在于，若所述hook点为XDP hook点，所述获取所述数据传输请求中携带的待处理数据及目的端口之后，所述通过挂载的eBPF程序将所述目的端口调整为预先保存的安全引擎的端口，将调整端口后的待处理数据发送至所述安全引擎之前，所述方法还包括：
判断所述目的端口，是否为任一预先保存的待防护的Pod的端口，若是，则执行后续，通过挂载的eBPF程序将所述目的端口调整为预先保存的安全引擎的端口，将调整端口后的待处理数据发送至所述安全引擎的步骤。
4.根据权利要求1所述的方法，其特征在于，若所述hook点为TCP hook点，所述获取所述数据传输请求中携带的待处理数据包括：
获取所述数据传输请求中携带的待处理数据、目的IP地址及目的端口；
所述通过挂载的eBPF程序将所述待处理数据发送至所述安全引擎包括：
通过挂载的eBPF程序将所述目的IP地址及所述目的端口调整为安全引擎对应的IP地址及端口，将调整端口及IP地址后的待处理数据发送至所述安全引擎。
5.根据权利要求4所述的方法，其特征在于，若所述hook点为TCP hook点，所述获取所述数据传输请求中携带的待处理数据、目的IP地址及目的端口之后，所述通过挂载的eBPF程序将所述目的IP地址及所述目的端口调整为安全引擎对应的IP地址及端口，将调整端口及IP地址后的待处理数据发送至所述安全引擎之前，所述方法还包括：
判断所述目的IP地址及目的端口，是否为任一预先保存的待防护的Pod的IP地址及端口，若是，则执行后续，通过挂载的eBPF程序将所述目的IP地址及所述目的端口调整为安全引擎对应的IP地址及端口，将调整端口及IP地址后的待处理数据发送至所述安全引擎的步骤。
6.根据权利要求1所述的方法，其特征在于，所述方法还包括：
若接收到所述安全引擎返回的处理完成指令，则获取所述设备中源被访问Pod的标识及所述待处理数据；
通过bpf_msg_redirect_hash对所述待处理数据进行转发，将所述待处理数据绕过底层协议栈并返回至所述标识对应的所述源被访问Pod。
7.根据权利要求6所述的方法，其特征在于，所述获取所述设备中源被访问Pod的标识包括：
若所述hook点为XDP hook点，获取所述处理完成指令中携带的所述设备中源被访问Pod的目的端口；
若所述hook点为TCP hook点，获取所述处理完成指令中携带的所述设备中源被访问Pod的目的端口及目的IP地址。
8.根据权利要求6所述的方法，其特征在于，获取未调整端口时的所述待处理数据包括：
若所述hook点为XDP hook点，根据预先保存的端口和调整前的四元组信息的映射信息，获取所述目的端口对应的第一目标四元组信息；并根据预先保存的调整前的四元组信息和调整前的数据的映射信息，获取所述第一目标四元组信息对应的所述待处理数据；
若所述hook点为TCP hook点，根据预先保存的端口及IP地址和调整前的四元组信息的映射信息，获取所述目的端口及所述目的IP地址对应的第二目标四元组信息；并根据预先保存的调整前的四元组信息和调整前的数据的映射信息，获取所述第二目标四元组信息对应的所述待处理数据。
9.一种安全防护装置，其特征在于，所述装置包括：
检测获取模块，用于若检测到数据传输请求，则获取所述数据传输请求中携带的待处理数据；
处理模块，用于通过挂载的伯克利包过滤器eBPF程序将所述待处理数据发送至所述安全引擎，其中，所述安全引擎被设置在所述设备中。
10.一种电子设备，其特征在于，所述电子设备至少包括处理器和存储器，所述处理器用于执行存储器中存储的计算机程序时执行权利要求1-8中任一所述安全防护方法的步骤。
11.一种计算机可读存储介质，其特征在于，其存储有计算机程序，所述计算机程序被处理器执行时执行权利要求1-8中任一所述安全防护方法的步骤。
CN202311074970.1A 2023-08-24 2023-08-24 一种安全防护方法、装置、设备及介质 Pending CN117896084A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311074970.1A CN117896084A (zh) 2023-08-24 2023-08-24 一种安全防护方法、装置、设备及介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311074970.1A CN117896084A (zh) 2023-08-24 2023-08-24 一种安全防护方法、装置、设备及介质

Publications (1)

Publication Number Publication Date
CN117896084A true CN117896084A (zh) 2024-04-16

Family

ID=90641948

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311074970.1A Pending CN117896084A (zh) 2023-08-24 2023-08-24 一种安全防护方法、装置、设备及介质

Country Status (1)

Country Link
CN (1) CN117896084A (zh)

Similar Documents

Publication Publication Date Title
US10454953B1 (en) System and method for separated packet processing and static analysis
Shu et al. Security in software-defined networking: Threats and countermeasures
US10693899B2 (en) Traffic enforcement in containerized environments
US10608995B2 (en) Optimizing data transfer costs for cloud-based security services
US9954873B2 (en) Mobile device-based intrusion prevention system
US11831420B2 (en) Network application firewall
KR102451237B1 (ko) 컨테이너 네트워크를 위한 보안
US10270792B1 (en) Methods for detecting malicious smart bots to improve network security and devices thereof
US11627148B2 (en) Advanced threat detection through historical log analysis
US9491190B2 (en) Dynamic selection of network traffic for file extraction shellcode detection
US20160164840A1 (en) Network security processing
CN110166459B (zh) 反序列化漏洞的防护方法、装置、设备及可读存储介质
US9661006B2 (en) Method for protection of automotive components in intravehicle communication system
US10904274B2 (en) Signature pattern matching testing framework
US12111928B2 (en) Utilizing machine learning to detect malicious executable files efficiently and effectively
KR101200906B1 (ko) 네트워크 기반 고성능 유해사이트 차단 시스템 및 방법
US10805323B1 (en) Cloud computing platform that isolates suspicious third-party code in a distributed cloud computing network
US20220255898A1 (en) Systems and methods for monitoring and securing networks using a shared buffer
CN117896084A (zh) 一种安全防护方法、装置、设备及介质
Wang et al. Tualatin: Towards network security service provision in cloud datacenters
US20220311791A1 (en) Systems and methods for low latency stateful threat detection and mitigation
CN117135104A (zh) 数据处理方法、装置、计算机设备、存储介质及程序产品
CN113783897A (zh) 一种跨网络访问进程流量管理方法、系统、设备及介质
CN115913583A (zh) 业务数据访问方法、装置和设备及计算机存储介质
You et al. HELIOS: Hardware-assisted High-performance Security Extension for Cloud Networking

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