Distributed denial of service (DDOS)-based artificial intelligence (AI) acceleration solution using data processing units (DPU)

Abstract

The invention discloses a distributed denial of service (DDOS)-based artificial intelligence (AI) acceleration solution using a data processing unit (DPU). Apparatuses, systems, and techniques are described for detecting whether a host device is attacked by distributed denial of service (DDOS) using a machine learning (ML) detection system. A computing system includes a data processing unit (DPU) having a network interface and a hardware acceleration engine. The DPU hosts a hardware acceleration security service to extract features from the network data and metadata from the hardware acceleration engine, and sends the extracted features to the ML detection system. The ML detection system determines whether the host device is subjected to a DDOS attack using the extracted features. The ML detection system may send enforcement rules to the hardware acceleration engine in response to determining that the host device is subject to the DDOS attack.

Description

Technical Field

[0001] At least one embodiment is directed to processing resources for performing and facilitating operations for detecting whether a host device is under a malicious network attack. For example, at least one embodiment is directed to a processor or computing system for providing and enabling a data processing unit (DPU) to use a machine learning (ML) detection system to determine whether a host device is under a distributed denial of service (DDOS) attack based on features extracted from network data and metadata of the DPU in accordance with various novel techniques described herein. Background Art

[0002] Cybersecurity involves protecting the communication network and the devices connected to it from various threats. Cybersecurity has always been a challenging problem. There are many possible cyber attacks, including but not limited to distributed denial of service (DDOS) attacks, man-in-the-middle attacks, unauthorized access, etc. The strategies and methods used by malicious actors are constantly evolving. Existing technologies for protecting network communications can be improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Various embodiments according to the present disclosure will be described with reference to the accompanying drawings, in which:

[0004] Figure 1 is a block diagram of an example DPU-based system architecture according to at least one embodiment.

[0005] Figure 2 is a block diagram of an example DPU-based system architecture according to at least one embodiment.

[0006] Figure 3 is a block diagram of an example DPU-based system architecture according to at least one embodiment.

[0007] Figure 4 is a block diagram of an example DPU-based system architecture according to at least one embodiment.

[0008] Figure 5 is a flow chart of an example method of detecting a DDOS attack on a host device in accordance with at least one embodiment.

[0009] Figure 6 is a block diagram of an example DDOS detection system in accordance with at least one embodiment.

[0010] Fig. 7A is an illustration according to at least one embodiment Figure 6 Plot of the unsupervised model results for a tree-based model.

[0011] Figure 7B is an illustration according to at least one embodiment Figure 6 Plot of the unsupervised model results for a tree-based model.

[0012] Figure 8 is a block diagram illustrating a computing system having a DPU and a GPU coupled between a first host device and a second host device according to at least one embodiment.

[0013] Fig. 9 A process flow for detecting DDOS attacks through a machine learning model according to at least one embodiment is shown.

[0014] Fig.10 is a flow chart of a method for determining whether a host device is under a DDOS attack according to one embodiment.

[0015] Fig.11 is a block diagram illustrating an example switch-based system architecture in accordance with at least one embodiment.

[0016] Fig.12 A method according to one embodiment is shown. DETAILED DESCRIPTION

[0017] Data center security includes a wide range of technologies and solutions used to protect data centers from external and internal threats or attacks. A data center is a facility that stores different devices such as switches, routers, load balancers, firewalls, servers, networked computers, storage, network interface cards (NICs), DPUs, GPUs, and other resources as part of the information technology (IT) infrastructure. For private companies moving to the cloud, data centers reduce the cost of running their own centralized computing networks and servers. Data centers provide services such as storage, backup and recovery, data management, networking, security, orchestration, etc. Since data centers hold sensitive or proprietary information such as customer data or intellectual property, servers must always be secured and protected from known and unknown cyber attacks, malware, malicious activities, etc. Data centers are complex and include many types of equipment and services. Security components and advanced technologies are available to protect equipment and services.

[0018] One cybersecurity requirement is protection against malicious cyberattacks, which has become a major concern in today's interconnected world. One traditional solution for detecting cyberattacks is signature-based detection. Signature-based detection is based on past experience and extensive knowledge of each attack. Traditional signature-based detection systems fail to address the increasing variability of today's cyberattacks and have several disadvantages. Traditional systems are unable to detect new attacks because signature-based detection requires new signatures for each new attack. Signatures must be continuously maintained and updated to support new attacks. Traditional systems can be time-consuming and expensive due to the need for security experts to create, test, and verify signatures. These solutions can also be time-constrained because there can be a significant amount of time between the discovery of an attack and the creation, testing, and verification of a signature for deployment.

[0019] A DDOS attack is a type of cyberattack in which a large number of compromised computers or devices (also known as "botnets") are used to "flood" a target website or server with traffic, overwhelming it and rendering it unusable for legitimate users. The purpose of a DDOS attack is to disrupt the normal operation of a target service, website, or network by taking up its resources and making it inaccessible or extremely slow. Attackers typically gain control of these devices by infecting them with malware, turning them into "zombies" or "bots" that can be controlled remotely. These devices then send large amounts of traffic to the target server, often from multiple locations and Internet Protocol (IP) addresses, making it difficult to stop the attack.

[0020] DDOS attacks can be used for a variety of purposes, including extortion, revenge, activism, or simply to disrupt the target's operations. They can be very effective and cause significant damage to businesses and organizations that rely on their websites and online services to operate. To identify a DDOS attack, certain signs and symptoms can indicate that a network or system is under attack. Here are some common indicators of a DDOS attack: 1. Unusually large amounts of traffic: A DDOS attack involves sending a large amount of traffic to a target server or website. If a sudden surge in traffic is observed, it could be a sign of a DDOS attack. 2. Slow or unresponsive websites: If a website or online service is running slowly or becomes unresponsive, it could be due to a DDOS attack. The large amount of traffic overwhelms the server and makes it difficult to respond to legitimate user requests. 3. Network connectivity issues: If the network is experiencing connectivity issues, such as connection drops or latency, it could be a sign of a DDOS attack. 4. Unusual traffic patterns: If the traffic pattern is unusual or does not match typical traffic patterns, it could be a sign of a DDOS attack. For example, if a large number of requests from the same IP address are observed, it could be an indication of a DDOS attack. 5. Abnormal Domain Name System (DNS) traffic: If a large amount of DNS traffic is observed from unexpected sources, it may be an indication of a DNS amplification attack, which is a type of DDOS attack. If a network or system is attacked, immediate measures must be taken to mitigate the damage. Measures can include implementing DDOS mitigation strategies, such as blocking traffic from specific IP addresses or ranges.

[0021] There are a variety of methods that can be used to identify DDOS attacks. Here are some common methods: 1. Traffic monitoring: One of the most effective ways to identify DDOS attacks is to monitor network traffic for abnormal patterns. Network administrators can use tools such as intrusion detection systems (IDS) and network traffic analysis tools to identify and analyze traffic anomalies. 2. Baseline traffic analysis: By establishing a baseline of normal network traffic patterns, administrators can quickly detect deviations from the baseline, which indicates a possible DDOS attack. 3. Network behavior analysis: Network behavior analysis tools can be used to detect abnormal traffic patterns, such as an increase in the number of connections or a sudden surge in traffic. 4. Intrusion prevention system: Intrusion prevention system (IPS) can detect and block traffic from malicious sources before it reaches the target system, thereby preventing DDOS attacks from occurring. 5. Flow-based monitoring: Flow-based monitoring uses NetFlow or similar technologies to track network traffic patterns and identify potential DDOS attacks based on the size and frequency of traffic. 6. Application layer monitoring: Application layer monitoring can detect DDOS attacks against specific applications or services, such as web servers or DNS servers. 7. Signature-based detection: Signature-based detection uses known attack patterns to identify and block malicious traffic.

[0022] Aspects and embodiments of the present disclosure address the above and other deficiencies by providing an AI / ML-based DDOS detection and mitigation solution. Aspects and embodiments of the present disclosure may provide an accelerated hardware engine of an integrated circuit (e.g., a DPU or a switch) to determine whether a host device is under a DDOS attack. Specifically, the accelerated hardware engine of the DPU may extract feature data from network traffic, extract feature data from a register of the DPU, and determine whether the host device is under a DDOS attack based on the feature data. Studies of recent network attacks have shown that using machine learning for network attack detection by learning patterns of network behavior can prevent advanced techniques used by attackers in today's interconnected world. Machine learning involves training a computing system—using training data—to identify features in the data that may be helpful for detection and classification. Training may be supervised or unsupervised. Machine learning models may use a variety of computing algorithms, such as decision tree algorithms (or other rule-based algorithms), artificial neural networks, and the like. During the inference phase, new data is input into a trained machine learning model, and the trained machine learning model may classify items of interest using features identified during training. DPU-based anomaly detection and execution technology for network filtering and acceleration (a GPU-based AI framework) can provide network protection for data centers in today's interconnected world. Additionally, modern datacenter and cloud infrastructures contain heterogeneous computing capabilities, including ARM and GPU-native infrastructure.

[0023] Aspects and embodiments of the present disclosure may provide AI / ML-based DDOS detection and mitigation using a hardware-accelerated security service with data extraction logic and a telemetry service (or telemetry agent). The data extraction logic may be a DOCA flow inspector service based on DPU hardware. The data extraction logic may filter, classify, and monitor traffic, build data structures based on configuration, and send them to a telemetry service (e.g., a DOCA telemetry service). The telemetry service (e.g., a DOCA telemetry service) may query DPU counters and send them to an AI / ML application (local or remotely hosted) along with data from the flow inspector service. The AI / ML application may detect DDOS attacks based on pre-trained AI / ML models using advanced AI / ML algorithms. Once a DDOS attack is detected, the AI / ML application may send network mitigation rules to the DPU hardware. During operation, configurations may be added to the flow inspector service to identify which traffic patterns to monitor. For each traffic pattern, the flow inspector service may configure the relevant fields to be extracted to send to the telemetry service. The telemetry service may query the DPU counters, aggregate information from the flow inspector, and send it to the AI / ML application. The AI / ML application can receive the data and use advanced AI / ML algorithms to decide if this is an actual DDOS attack. The AI / ML application can send hardware-based network rules back to the DPU to mitigate the attack.

[0024] In general, embodiments of the AI / ML-based solutions described herein can be used to detect DDOS attacks more effectively than traditional methods because they can quickly identify anomalies and patterns in network traffic that may indicate an attack. Embodiments of the AI / ML-based solutions described herein can analyze network traffic in real time, enabling them to detect DDOS attacks as they occur. This enables security teams to respond quickly and mitigate the damage caused by the attack. DDOS attacks generate large amounts of traffic, making it difficult for traditional methods to identify and mitigate attacks. Embodiments of the AI / ML-based solutions described herein can scale to handle large amounts of traffic and quickly identify patterns of malicious activity. Embodiments of the AI / ML-based solutions described herein can be automated, allowing security teams to respond to DDOS attacks quickly and efficiently. This reduces the risk of human error and enables security teams to focus on other critical tasks. Attackers are constantly evolving their means, making it challenging to detect and mitigate DDOS attacks using traditional methods. Embodiments of the AI / ML-based solutions described herein can adapt to new attack patterns and identify previously unknown attack methods. Embodiments of the AI / ML-based solutions described herein can analyze large amounts of data more accurately than humans, enabling them to detect DDOS attacks more effectively. This reduces the risk of false positives and enables security teams to focus on real threats.

[0025] Aspects and embodiments of the present disclosure may provide an accelerated hardware engine operably coupled to a host interface and a network interface. The accelerated hardware engine may extract features from network traffic data received through the network interface and directed to a host device. Using an ML detection system, the accelerated hardware engine may determine whether the host device is under a DDOS attack based on features extracted from the network traffic data. The accelerated hardware engine may perform operations related to enforcement of rules. In at least one embodiment, the accelerated hardware engine is implemented on a DPU. In at least one embodiment, the accelerated hardware engine is implemented on a switch.

[0026] Aspects and embodiments of the present disclosure may provide a hardware accelerated security service that may extract features from network data directed to a host device and data stored in registers of an accelerated hardware engine, and send the features to a network security platform to determine whether the host device is under a DDOS attack. The hardware accelerated security service receives enforcement rules from a network security platform in response to the network security platform determining that the host device is under a DDOS attack. The hardware accelerated security service performs actions associated with enforcement rules on subsequent network traffic directed to the host device. The hardware accelerated security service may run on a DPU and is an agentless hardware product that inspects network data directed to the host device. In at least one embodiment, the hardware accelerated security service is NVIDIA DOCA. Alternatively, other hardware accelerated security services may be used. In some cases, the network security platform detects malicious network activity during an attack and may responsively provide enforcement rules to protect the host device from a DDOS attack. The integrated circuit may be a DPU. The DPU may be a programmable data center infrastructure on a chip. The integrated circuit may include a network interface operably coupled to a central processing unit (CPU) to handle network data path processing, and the CPU may control path initialization and exception handling.

[0027] Aspects and embodiments of the present disclosure may provide a first agent (e.g., NVIDIA DOCA flow inspector) and a second agent (e.g., NVIDIA DOCA telemetry agent) of a hardware accelerated security service. The first agent may utilize an accelerated hardware engine (e.g., DPU hardware) to use the hardware capabilities of the accelerated hardware engine to offload network traffic and filter network traffic based on predefined filters. The second agent may extract telemetry data from embedded counters (or other registers) on the accelerated hardware engine and combine the telemetry data with the filtered network traffic to a network security platform. The filtered network traffic may be structured data that may be streamed to an ML detection system (e.g., a locally hosted or remote network security platform) along with counter metadata for analysis using the accelerated memory access method described herein. The ML detection system may process large amounts of data and provide immediate and dynamic protection by providing enforcement network rules to the accelerated hardware engine (e.g., DPU). In some cases, the ML detection system is implemented in a remote network security platform that may process large amounts of data on a GPU and provide immediate and dynamic protection by sending enforcement network rules back to the accelerated hardware engine (e.g., DPU). The ML detection system may detect threats or attacks using anomaly detection methods. The ML detection system can provide feedback results to the acceleration hardware engine (e.g., DPU hardware) to enforce and block malicious activity or other types of network attacks. This feedback may change or otherwise alter the streaming data sent to the ML detection system to further refine the feedback results. Stream inspectors and telemetry agents hosted on the DPU and ML detection system (e.g., a network security platform hosted on the DPU itself or hosted on a GPU) can provide a complete solution for traffic filtering, counter extraction, and data streaming to the ML detection system for machine learning-based anomaly detection. Once a DDOS attack is identified by machine learning-based anomaly detection, the DPU can be configured with mitigation rules to immediately block the attack.

[0028] DPU-based system architecture

[0029] Figure 1is a block diagram of an example DPU-based system architecture 100 according to at least one embodiment. The DPU-based system architecture 100 (also referred to herein as a "system" or "computing system") includes a first integrated circuit (labeled as DPU 102) and a second integrated circuit (labeled as host device 104). The DPU-based system architecture 100 may be part of a data center and include one or more data repositories, one or more server machines, and other components of a data center infrastructure. The DPU 102 may be coupled to a network 108. The network 108 may include a public network (e.g., the Internet), a private network (e.g., a local area network (LAN) or a wide area network (WAN)), a wired network (e.g., Ethernet), a wireless network (e.g., an 802.11 network or a Wi-Fi network), a cellular network (e.g., a long term evolution (LTE) network), a router, a hub, a switch, a server computer, and / or a combination thereof.

[0030] In at least one embodiment, the DPU 102 is integrated as a system on a chip (SoC), which is considered an on-chip data center infrastructure. In at least one embodiment, the DPU 102 includes DPU hardware 110 and DPU software 112 (e.g., a software framework with an acceleration library). The DPU hardware 110 may include a CPU (e.g., a single-core or multi-core CPU), one or more hardware accelerators, a memory, one or more host interfaces, and one or more network interfaces. The software framework and the acceleration library may include one or more hardware acceleration services, including hardware accelerated security services (e.g., NVIDIA DOCA), hardware accelerated virtualization services, hardware accelerated network services, hardware accelerated storage services, hardware accelerated artificial intelligence / machine learning (AI / ML) services, and hardware accelerated management services. Figure 1 As shown, the hardware accelerated security service may include data extraction logic 114 (e.g., DOCA flow checker) and telemetry agent 116 (agent or service), and the AI / ML service may include ML detection system 118. The data extraction logic 114 and the telemetry agent 116 may extract feature data from network traffic received from the second device (or multiple devices) through the network 108 and / or metadata from the DPU hardware 110. The ML detection system 118 includes one or more ML detection models that are trained to determine whether the host device 104 is under a DDOS attack based on the feature data extracted from the data extraction logic 114 and / or the telemetry agent 116. More details of the operation of the data extraction logic 114, the telemetry agent 116, and the ML detection system 118 are described below.

[0031] In at least one embodiment, data extraction logic 114 (e.g., DOCA flow inspector) extracts network data 120 from network traffic received through one or more network interfaces over network 108. Network data 120 may be received from a second device ( Figure 1 104). The second device may be the initiator of the DDOS attack. In at least one embodiment, the data extraction logic 114 receives a copy of the network data 120 (e.g., a mirror copy of the network data 120 directed to the host device 104). The data extraction logic 114 may be configured by a configuration file that specifies which type of data should be extracted from the network data 120. The configuration file may specify one or more filters that are used to extract data of a specified type from the network data 120 for inclusion or removal from inclusion. Since the network data may be a copy of the network data, network traffic that does not meet the filtering criteria may be discarded or removed. The network traffic that meets the filtering criteria may be structured and streamed to the ML detection system 118 for analysis. The data extraction logic 114 may generate a data structure 122 using the extracted data. The data structure 122 may be any type of data structure, such as a structure, an object, a message, etc. For example, the configuration file may specify that all HyperText Transport Protocol (HTTP) traffic is extracted from the network data 120. The profile may specify that all traffic on port 80, port 443, and / or port 22 should be extracted from network data 120 for analysis. A large number of attacks target these three ports: SSH-22 / TCP, HTTPS-443 / TCP, and HTTP-80 / TCP.

[0032] In at least one embodiment, the telemetry agent 116 extracts metadata 124 from one or more registers of the DPU hardware 110. In at least one embodiment, the telemetry agent 116 can be configured or programmed by a configuration file (the same or different configuration file as the data extraction logic 114) that specifies which metadata should be extracted from the hardware of the DPU (e.g., from embedded counters, registers, etc.). For example, the configuration file can specify which values ​​the telemetry agent should extract from the counters, registers, etc. to stream along with the extracted network data. Some metadata 124 can be associated or related to the network data 120. Some metadata 124 can be associated or related to the underlying hardware and not to network traffic. In at least one embodiment, the telemetry agent 116 combines the data structure 122 and the metadata 124 into streaming data 126. The telemetry agent 116 sends the streaming data 126 to the ML detection system 118 (e.g., an accelerated AI / ML pipeline) to determine whether the host device 104 is under a DDOS attack.

[0033] In at least one embodiment, in response to the ML detection system 118 determining that the host device 104 is under a DDOS attack, the ML detection system 118 sends the enforcement rule 128 to the DPU hardware 110. The DPU hardware 110 can perform an action associated with the enforcement rule 128 on subsequent network traffic directed from the second device to the host device 104. In at least one embodiment, the ML detection system 118 can output an indication of the DDOS attack on the host device 104. In at least one embodiment, the ML detection system 118 can send the indication to the hardware accelerated security service, and the hardware accelerated security service can send an alert to another system, such as a security information and event management (SIEM) or an extended detection and response (XDR) system. The alert can include information about the DDOS attack. In at least one embodiment, the ML detection system 118 can send the indication in addition to sending the enforcement rule 128 to the DPU hardware 110.

[0034] In at least one embodiment, the data extraction logic 114 may extract one or more features and send the extracted features to the ML detection system 118, with or without the features extracted by the telemetry agent 116. For example, the data extraction logic 114 may extract HTTP data and the telemetry agent 116 may extract corresponding metadata 124 from the DPU hardware registers and counters. The telemetry agent 116 may generate and send stream data 126 to the ML detection system 118. The stream data 126 may include the features extracted by the data extraction logic 114. The stream data 126 may include the features extracted by the data extraction logic 114 and the telemetry agent 116. In another embodiment, the ML detection system 118 includes feature extraction logic to extract a set of features from the stream data 126. The stream data 126 may be raw data extracted by the hardware accelerated security service. In at least one embodiment, the extracted features are input into the DDOS detection system 130. In at least one embodiment, the DDOS detection system 130 includes a tree-based ML model that is trained to determine whether the host device 104 is under a DDOS attack based on the extracted features.

[0035] In at least one embodiment, DPU hardware 110 includes a data buffer for storing network data 120. In at least one embodiment, DPU hardware 110 creates a copy of network data 120 so that data extraction logic 114 can filter it to extract structured data (eg, data structure 122).

[0036] In at least one embodiment, the data extraction logic 114 can extract some features from the network data 120 and create a feature set, including categorical features, numerical features, binary features, etc. The telemetry agent 116 can extract numerical features from the telemetry data (i.e., metadata 124). These numerical features can be combined into a feature set. In at least one embodiment, the DDOS detection system 130 includes an ML model that is trained to determine whether the feature set indicates a DDOS attack. In at least one embodiment, the ML model includes a tree-based model. In another embodiment, the DDOS detection system 130 includes a neural network (e.g., a fully connected neural network layer or a convolutional neural network (CNN)). More details of the ML model will be referred to below. Figure 6 Give a description.

[0037] It should be noted that, unlike a CPU or GPU, the DPU 102 is a new type of programmable processor that combines three key elements, including, for example: 1) an industry-standard, high-performance, software-programmable CPU (single-core or multi-core CPU) tightly coupled with other SoC components; 2) a high-performance network interface that can parse, process and efficiently transmit data to the GPU and CPU at line rate or the speed of the rest of the network; 3) a rich set of flexible and programmable acceleration engines that can offload and improve the performance of applications such as AI and machine learning, security, telecommunications and storage. These capabilities can enable independent, bare-metal, cloud-native computing platforms for cloud-scale computing. In at least one embodiment, the DPU 102 can be used as a standalone embedded processor. In at least one embodiment, the DPU 102 can be incorporated into a network interface controller (also known as a smart network interface card (SmartNIC)) used as a server system component. A DPU-based network interface card (network adapter) can offload processing tasks that are usually handled by the CPU of the server system. Using its processor, a DPU-based SmartNIC can be able to perform any combination of encryption / decryption, firewall, transmission control protocol / Internet protocol (TCP / IP) and hypertext transfer protocol (HTTP) processing. For example, SmartNICs can be used in high-traffic web servers.

[0038] In at least one embodiment, the DPU 102 can be configured for modern cloud workloads and high-performance computing for traditional enterprises. In at least one embodiment, the DPU 102 can provide a set of software-defined networking, storage, security, and management services at a data center scale, with the ability to offload, accelerate, and isolate data center infrastructure. In at least one embodiment, the DPU 102 can provide these software services for a multi-tenant, cloud-native environment. In at least one embodiment, the DPU 102 can provide data center services for up to hundreds of CPU cores, freeing up valuable CPU cycles to run business-critical applications. In at least one embodiment, the DPU 102 can be viewed as a new class of processors designed to process data center infrastructure software to offload and accelerate the computational load of virtualization, networking, storage, security, cloud-native AI / ML services, and other management services.

[0039] In at least one embodiment, the DPU 102 may include connections to packet-based interconnects (e.g., Ethernet), switched fabric interconnects (e.g., InfiniBand, Fibre Channel, Omni-Path), and the like. In at least one embodiment, the DPU 102 may provide an accelerated, fully programmable, and security-configured (e.g., zero-trust security) data center to prevent data breaches and cyberattacks. In at least one embodiment, the DPU 102 may include a network adapter, an array of processor cores, and an infrastructure offload engine with full software programmability. In at least one embodiment, the DPU 102 may be located at the edge of a server to provide flexible, secure, high-performance cloud and AI workloads. In at least one embodiment, the DPU 102 may reduce total cost of ownership and improve data center efficiency. In at least one embodiment, the DPU 102 may provide a software framework and acceleration libraries (e.g., NVIDIA DOCA TM ), enabling developers to quickly create applications and services for the DPU 102, such as security services, virtualization services, network services, storage services, AI / ML services, and management services. In at least one embodiment, the ML detection system 118 is implemented in the AI / ML service. In another embodiment, the ML detection system 118 is implemented on one or more hardware accelerators or other components of the DPU hardware 110. In at least one embodiment, the software framework and acceleration library make it easy to leverage the hardware accelerators of the DPU 102 to provide data center performance, efficiency, and security. In at least one embodiment, the ML detection system 118 is implemented in a GPU coupled to the DPU 102, such as Figure 2 The GPU may include one or more of the accelerated AI / ML pipelines described herein.

[0040] In at least one embodiment, DPU 102 can provide network services with virtual switches (vSwitch), virtual routers (vRouter), network address translation (NAT), load balancing, and network virtualization (NFV). In at least one embodiment, DPU 102 can provide storage services, including NVME on the structure TM (NVME TM Over fabrics, NVMe-oF TM ) technology, elastic storage virtualization, hyper-converged infrastructure (HCI) encryption, data integrity, compression, data deduplication, etc. NVMExpress TM NVMe-oF is an open logical device interface specification for accessing non-volatile storage media attached through a PCI (PCIe) interface. TM Provides efficient mapping of NVMe commands to multiple network transport protocols, enabling one computer ("initiator") to access block-level storage devices attached to another computer ("target") very efficiently and with minimal latency. The term "Fabric" is a generalization of the more specific concepts of network and input / output (I / O) channels. It essentially refers to the N:M interconnection of elements, typically in a peripheral environment. NVMe-oF TMThe technology supports the transmission of NVMe command sets over various interconnect infrastructures, including networks (e.g., Internet Protocol (IP) / Ethernet) and I / O channels (e.g., Fibre Channel). In at least one embodiment, the DPU 102 can provide hardware-accelerated security services using next-generation firewalls (FGFWs), intrusion detection systems (IDSs), intrusion prevention systems (IPSs), root of trust, micro-segmentation, distributed denial of service (DDoS) prevention technologies, and ML detection using data extraction logic 114 and ML detection system 118. NGFW is a network security device that provides capabilities beyond stateful firewalls, such as application awareness and control, integrated intrusion prevention, and cloud-delivered threat intelligence. In at least one embodiment, one or more network interfaces may include an Ethernet interface (single or dual port) and an InfiniBand interface (single or dual port). In at least one embodiment, one or more host interfaces may include a PCIe interface and a PCIe switch. In at least one embodiment, one or more host interfaces may include other memory interfaces. In at least one embodiment, the CPU may include multiple cores (e.g., up to 8 64-bit core pipelines), where one or two cores have an L2 cache, and an L3 cache with an eviction policy that supports double data rate (DDR) dual in-line memory modules (DIMMs) (e.g., supports DDR4 DIMMs), and a DDR4 DRAM controller. The memory may be onboard DDR4 memory with error correction code (ECC) error protection support. In at least one embodiment, the CPU may include a single core with L2 and L3 caches and a DRAM controller. In at least one embodiment, one or more hardware accelerators may include a security accelerator, a storage accelerator, and a network accelerator. In at least one embodiment, the ML detection system 118 is hosted by a security accelerator.In at least one embodiment, the security accelerator may provide secure boot with hardware root of trust, secure firmware update, Cerberus compliance, regular expression (RegEx) acceleration, IP security (IPsec) / transport layer security (TLS) dynamic data encryption, AES-GCM 128 / 256-bit keys for static data encryption (e.g., Advanced Encryption Standard (AES) with Ciphertext Stealing (XTS) (e.g., AES-XTS AES-XTS256 / 512), Secure Hash Algorithm (SHA) 256-bit hardware acceleration, hardware public key accelerator (e.g., Rivest-Shamir-Adleman (RSA), Diffie-Hellman, Digital Signal Algorithm (DSA), ECC, Elliptic Curve Cryptography Digital Signal Algorithm (EC-DSA), Elliptic Curve Diffie-Hellman (EC-DH)), and True Random Number Generator (TRNG). In at least one embodiment, the storage accelerator may provide BlueField SNAP-NVMe. TM and VirtIO-blk, NVMe-oF TM Acceleration, compression and decompression acceleration, and data hashing and deduplication. In at least one embodiment, the network accelerator can provide remote direct memory access (RDMA) over converged Ethernet (RoCE) RoCE, zero-touch RoCE, TCP, IP and User Datagram Protocol (UDP) stateless offload, large receive offload (LRO), large segment offload (LSO), checksum, total sum of squares (TSS), residual sum of squares (RSS), HTTP dynamic stream (HDS) and virtual local area network (VLAN) insertion / stripping, single root I / O virtualization (SR-IOV), virtual Ethernet card (e.g., VirtIO-net), multi-function per port, VMware NetQueue support, virtualization hierarchy, and ingress and egress quality of service (QoS) levels (e.g., 1K ingress and egress QoS levels). In at least one embodiment, the DPU 102 can also provide boot options, including secure boot (RSA authentication), Ethernet remote boot, Internet Small Computer System Interface (iSCSI) remote boot, pre-boot execution environment (PXE) and unified extensible firmware interface (UEFI).

[0041] In at least one embodiment, the DPU 102 can provide management services including a 1GbE out-of-band management port, a network controller sideband interface (NC-SI), a management component transport protocol (MCTP) on a system management bus (SMBus) and a monitor control table (MCT) on PCIe, a platform level data model (PLDM) for monitoring and control, a PLDM for firmware updates, an inter-integrated circuit (I2C) interface for device control and configuration, a serial peripheral interface (SPI) interface to flash memory, an embedded multimedia card (eMMC) memory controller, a universal asynchronous receiver / transmitter (UART), and a universal serial bus (USB).

[0042] In at least one embodiment, the hardware accelerated security service is an adaptive cloud security service that provides real-time network visibility, detection, and response to network threats. In at least one embodiment, the hardware accelerated security service acts as a DPU 102 or a network security platform (e.g., Figure 2 ) monitoring or telemetry agents, such as the NVIDIA Morpheus platform, an AI-enabled cloud-native cybersecurity platform. The NVIDIA Morpheus platform is an open application framework that enables cybersecurity developers to create AI / ML pipelines to filter, process, and classify large amounts of real-time data, allowing customers to continuously inspect network and server telemetry at scale. The NVIDIA Morpheus platform can provide information security for the data center, enabling dynamic protection, real-time telemetry, and adaptive defense to detect and remediate cybersecurity threats.

[0043] Previously, users, devices, data, and applications inside the data center were implicitly trusted, and perimeter security was sufficient to protect them from external threats. In at least one embodiment, the DPU 102 can use hardware-accelerated security services to define security boundaries through a zero-trust protection model that recognizes that everyone and everything inside and outside the network cannot be trusted. Hardware-accelerated security services can perform network filtering for each host and all network traffic through encryption, fine-grained access control, and micro-segmentation. Hardware-accelerated security services can provide isolation, deploying security agents in a trusted domain separate from the host domain. If the host device is compromised, this isolation of hardware-accelerated security services prevents attackers from understanding or accessing hardware-accelerated security services, thereby helping to prevent the attack from spreading to other servers. In at least one embodiment, the hardware-accelerated security services described herein can provide host monitoring, enabling network security vendors to create accelerated intrusion detection system (IDS) solutions to identify attacks on any physical or virtual machine. Hardware-accelerated security services can provide data about the state of the application to a SIEM or SIEM&XDR system. Hardware-accelerated security services can also provide enhanced forensic investigation and incident response.

[0044] As mentioned above, attackers attempt to exploit vulnerabilities in security controls to move laterally through the data center network to other servers and devices. The hardware-accelerated security services described in this article can enable security teams to protect their application processes and continuously verify their integrity to detect malicious activity. If an attacker terminates a security control's process, the hardware-accelerated security services described in this article can mitigate the attack by isolating the infected host device, preventing the malware from accessing confidential data or spreading to other resources.

[0045] Traditionally, security tools run in the same host domain as malware. As a result, stealthy malware can employ techniques that are hidden from the host device, allowing the malware to quietly take over and tamper with the agent and operating system (OS). For example, if antivirus software is running on a host device that needs to continue running or is not paused, the hardware accelerated security service described herein actively monitors the process to determine any anomalies, malware, or intrusions, as described in more detail in the various embodiments described below. The malware runs in the host domain, while the hardware accelerated security service runs in a domain separate from the host domain.

[0046] The host device 104 can be a desktop computer, a laptop computer, a smart phone, a tablet computer, a server, or any suitable computing device capable of performing the techniques described herein. In some embodiments, the host device 104 can be a computing device of a cloud computing platform. For example, the host device 104 can be a server machine or a component of a server machine of a cloud computing platform. In such an embodiment, the host device 104 can be coupled to one or more edge devices (not shown) via a network 108. An edge device refers to a computing device that enables communication between computing devices at the boundary of two networks. For example, an edge device can be connected to the host device 104, one or more data repositories, one or more server machines via a network 108, and can be connected to one or more endpoint devices (not shown) via another network. In such an example, the edge device can implement communication between the host device 104, one or more data repositories, one or more server machines, and one or more client devices. In other or similar embodiments, the host device 104 can be an edge device or a component of an edge device. For example, host device 104 may facilitate communications between one or more data repositories, one or more server machines connected to host device 104 via network 108, and one or more client devices connected to host device 104 via another network.

[0047] In other or similar embodiments, the host device 104 may be an endpoint device or a component of an endpoint device. For example, the host device 104 may be a television, a smart phone, a cellular phone, a data center server, a data DPU, a personal digital assistant (PDA), a portable media player, a netbook, a laptop, an e-book reader, a tablet computer, a desktop computer, a set-top box, a game console, a computing device of an autonomous vehicle, a monitoring device, or the like, or may be a component of such devices. In such an embodiment, the host device 104 may be connected to the DPU 102 via one or more network interfaces via the network 108. In other or similar embodiments, the host device 104 may be connected to an edge device (not shown) via another network, and the edge device may be connected to the DPU 102 via the network 410.

[0048] In at least one embodiment, the host device 104 executes one or more computer programs. The one or more computer programs may be any process, routine, or code executed by the host device 104, such as a host OS, an application, a guest OS of a virtual machine, or a guest application, such as executed in a container. The host device 104 may include one or more CPUs with one or more cores, one or more multi-core CPUs, one or more GPUs, one or more hardware accelerators, and the like.

[0049] In at least one embodiment, one or more computer programs reside in a first computing domain (e.g., a host domain), and the hardware accelerated security service and the ML detection system 118 reside in a second computing domain (e.g., a DPU domain or an infrastructure domain) that is different from the first computing domain. In at least one embodiment, the malicious activity is caused by malware, and the hardware accelerated security service is out-of-band security software in a trusted domain that is different from and isolated from the malware. That is, the malware may reside in the host domain, and the hardware accelerated security service located in the trusted domain can monitor physical memory to detect malware in the host domain. In at least one embodiment, the DPU 102 includes a direct memory access (DMA) controller ( Figure 1 1. The DMA controller may read data from the physical memory of the host through the host interface. In at least one embodiment, the DMA controller uses PCIe technology to read data from the physical memory of the host. Alternatively, other technologies may be used to read data from the physical memory of the host.

[0050] Although the various embodiments described above are directed to embodiments in which the hardware accelerated security services and ML detection system 118 are implemented in separate computing devices, including a DPU 102 and an accelerated AI / MI pipeline (e.g., on a GPU coupled to the DPU), in other embodiments, operations are performed on a single DPU 102. In other embodiments, the DPU 102 may be any computing system or computing device capable of performing the techniques described herein.

[0051] In at least one embodiment, host device 104 resides in a first computing domain (e.g., a host domain), and hardware accelerated security services and ML detection system 118 reside in a second computing domain (e.g., a DPU domain) that is different from the first computing domain. In another embodiment, host device 104 resides in a first computing domain (e.g., a host domain), hardware accelerated security services reside in a second computing domain (e.g., a DPU domain), and ML detection system 118 resides in a third computing domain that is different from the first computing domain and the second computing domain.

[0052] although Figure 1 The ML detection system 118 is shown as part of the DPU 102, but in other embodiments, the ML detection system 118 may be implemented on a separate device, such as a GPU with an accelerated AI / ML pipeline, such as Figure 2 As shown. In this embodiment, the GPU (or accelerated AI / ML pipeline) is coupled to the DPU 102 and can host the ML detection system 118. In at least one embodiment, the ML detection system 118 is the NVIDIA MORPHEUS cybersecurity platform. The accelerated AI / ML pipeline can perform pre-processing operations, reasoning, post-processing operations, actions, or any combination thereof. The accelerated AI / ML pipeline can be a combination of hardware and software, such as the NVIDIA EXG platform, and software for accelerating AI / ML operations on the NVIDIA EXG platform. For example, the accelerated AI / ML pipeline can provide an advantage of up to 60 times the acceleration process compared to the CPU. The accelerated AI / ML pipeline can also provide the advantage of a large number of reasonings that can be performed in parallel (for example, up to millions of parallel reasonings). More details of the ML detection system 118 will be referenced below. Figure 6 Give a description.

[0053] Figure 2is a block diagram of an example DPU-based system architecture 200 according to at least one embodiment. The DPU-based system architecture 200 is similar to the DPU-based system architecture 100, as indicated by similar reference numbers, except as described below. The DPU-based system architecture 200 includes a first integrated circuit (labeled as DPU 202) and a second integrated circuit (labeled as GPU 204). The GPU 204 can host a cybersecurity platform 206 (e.g., an accelerated AI / ML pipeline), which is remotely hosting the ML detection system 118 relative to the DPU 202. In at least one embodiment, the accelerated AI / ML pipeline can be part of the NVIDIA MORPHEUS cybersecurity platform. As described above, the NVIDIA Morpheus platform is an AI-enabled cloud-native cybersecurity platform. The NVIDIA Morpheus platform is an open application framework that enables cybersecurity developers to create AI / ML pipelines to filter, process, and classify large amounts of real-time data, allowing customers to continuously inspect network and server telemetry at scale. The NVIDIA Morpheus platform can provide information security for data centers to enable dynamic protection, real-time telemetry, and adaptive defenses for detecting and remediating cybersecurity threats. In Figure 2 In at least one embodiment of the present invention, the DPU 202 is configured as described above with respect to Figure 1 The network data 120 and metadata 124 are extracted from the DPU hardware 110 of the DPU 202 in a similar manner. The network data 120 may be extracted from network traffic received by a network interface of the DPU hardware 110. The metadata 124 may be extracted from registers, counters, etc. of the DPU hardware 110.

[0054] In at least one embodiment, the DPU 202 includes data extraction logic 114 (e.g., a DOCA flow inspector) that extracts network data 120 and a telemetry agent 116 that extracts metadata 124 from the DPU hardware 110, as described above. The flow inspector can be configured by a configuration file that specifies what type of data should be extracted from the network data 120. The configuration file can specify one or more filters that are used to extract specific data from the network data 120 to include or remove it from inclusion. The flow inspector can generate a data structure 122 using the extracted data. The data structure 122 can be any type of data structure, such as a structure, an object, a message, etc. For example, the configuration file can specify that all HTTP traffic is extracted from the network data 120. The flow inspector sends the structured data (e.g., the data structure 122) to the telemetry agent 116. In at least one embodiment, the telemetry agent 116 can be programmed by a configuration file (the same or different configuration file as the flow inspector) that specifies what metadata 124 should be extracted from the DPU hardware 110, such as from embedded counters, registers, etc. For example, the configuration file may specify which values ​​the telemetry agent 116 should extract from counters, registers, etc. to stream along with the extracted network data. In at least one embodiment, the telemetry agent 116 combines the metadata 124 with the structured data (e.g., data structure 122) into stream data 126 (e.g., streamed structured data). Figure 1 As described above, instead of sending the streaming data 126 to the locally hosted ML detection system 118, the telemetry agent 116 can send the streaming data 126 to the GPU 204 with the cybersecurity platform 206. In this embodiment, the cybersecurity platform 206 includes one or more accelerated AI / MI pipelines deployed on the GPU hardware 208. The cybersecurity platform 206 can implement the ML detection system 118.

[0055] In at least one embodiment, the DPU hardware 110 includes a data buffer to store the network data 120. In at least one embodiment, the DPU hardware 110 creates a copy of the network data 120 so that the flow inspector can filter it to extract the structured data.

[0056] In at least one embodiment, the computing system includes a DPU 202 and a GPU 204. The DPU 202 has a DPU hardware 110, including a network interface, a host interface, a CPU, and an acceleration hardware engine. The DPU 202 can implement hardware-accelerated security services using a flow inspector and a telemetry agent to collect feature data and stream it to a network security platform 206 to protect the host device from a DDOS attack. As described herein, the hardware-accelerated security service extracts a set of features from first data in network traffic received on a network interface and second data stored in a register in the DPU hardware 110. The hardware-accelerated security service (flow inspector and telemetry agent) can combine the first feature data and the second feature data into a set of features. The GPU 204 or other acceleration pipeline hardware is coupled to the DPU 102. The GPU 204 has a GPU software 210, a network security platform 206 hosting an ML detection system 118, and a GPU hardware 208. The GPU 204 uses the ML detection system 118 to determine whether the host device is under a DDOS attack based on the set of features. The GPU 204 sends the enforcement rule 128 to the DPU 202 (e.g., the DPU hardware 110) in response to determining that the host device is under a DDOS attack. The DPU 102 may perform actions associated with the enforcement rule 128 on subsequent network traffic directed to the host device. In at least one embodiment, the first feature data includes a source media access control (MAC) address (src_mac), a destination MAC address (dst_mac), a source IP address (src_ip), a destination IP address (dst_ip), a source port (src_port), a destination port (dst_port), a protocol identifier, a packet size (packet_size), a maximum packet size (max_packet_size), etc. The second feature data may include one or more flags, one or more counts, etc. The one or more flags and counts may be stored in a register or counter of the DPU hardware 110.

[0057] In at least one embodiment, the host device resides in a first computing domain and the DPU software 112 resides in a second computing domain that is different from the first computing domain. The ML detection system 118 may reside in the second computing domain ( Figure 1 ) or a third computational domain different from the first and second computational domains ( Figure 2 )middle.

[0058] Figure 3is a block diagram of an example DPU-based system architecture 300 according to at least one embodiment. The DPU-based system architecture 300 is similar to the DPU-based system architecture 100, as indicated by similar reference numbers, except as described below. The DPU-based system architecture 300 includes a first integrated circuit, labeled DPU 302. The DPU 302 includes similar hardware and software components as the DPU 102 described above, except that the DPU 302 includes an AI / ML-based service 306 that implements the ML detection system 118 locally on the DPU 302. The AI / ML-based service 306 can receive the streaming data 126 from the telemetry agent 116, as described above. The AI / ML-based service 306 can use the ML detection system 118 to determine whether the host device 304 is under a DDOS attack. In response to determining that the host device 304 is under a DDOS attack, the AI / ML-based service 306 can send an alert 308 to a resource controller 310. The resource controller 310 can be a provisioning server that provisions resources for the host device 304. Resource controller 310 may be implemented on separate devices, such as DPU 302 and host device 304. Resource controller 310 may send resource control information 312 to host device 304 in response to alert 308. Alternatively, alert 308 may be an indication of a DDOS attack, and resource controller 310 may perform one or more operations in response to the indication from ML detection system 118 to prevent any damage or other negative effects caused by the detected DDOS attack.

[0059] In at least one embodiment, the data extraction logic 114 may receive mirrored network traffic data (e.g., network data 120) from the DPU hardware 110 (e.g., an accelerated hardware engine). The data extraction logic 114 may use the DPU hardware 110 (e.g., an accelerated hardware engine) to offload the mirrored network traffic data and filter the mirrored network traffic data based on the predefined filter 314 to obtain filtered network traffic. The processing logic generates first feature data from the filtered network traffic. The processing logic extracts second feature data by extracting telemetry data from a register of the DPU hardware 110 (e.g., an accelerated hardware engine). In at least one embodiment, the telemetry agent 116 generates second feature data from the telemetry data and combines the first feature data and the second feature data into a set of features. The telemetry agent 116 sends the set of features to the DPU hardware 110 (e.g., an accelerated pipeline hardware).

[0060] In at least one embodiment, the DPU 302 provides an AI / ML-based DDOS detection and mitigation solution. The solution is composed of three main components: 1. An accelerated DOCA flow checker service (e.g., data extraction logic 114) based on the DPU hardware to filter, classify and monitor traffic, build data structures according to the configuration, and send them to the DOCA telemetry service (e.g., telemetry agent 116); 2. The DOCA telemetry service (e.g., telemetry agent 116) can query the DPU counters in the DPU hardware 110 and send them together with the data from the flow checker to the local or remotely hosted AI / ML-based application of the AI / ML-based service 306. 3. The AI / ML-based service 306 can use advanced AI / ML algorithms to detect DDOS attacks based on pre-trained (one or more) AI / ML models. Once a DDOS attack is detected, the AI / ML-based service 306 can send network mitigation rules to the DPU hardware 110. The solution provides full end-to-end DDOS detection based on AI / ML on the DPU to achieve DDOS edge protection.

[0061] In at least one embodiment, configurations for the flow checker can be added for traffic patterns to be monitored. For each traffic pattern, relevant fields can be configured to be extracted and sent to the DOCA telemetry service. The DOCA telemetry service can query the DPU counters, aggregate the information from the flow checker, and send it to the AI / ML application. 3. The AI / ML application can receive the data and use advanced AI / ML algorithms to decide if this is an actual DDOS attack. 4. The AI / ML application can mitigate the attack by adding hardware-based network rules to the DPU hardware 110.

[0062] Although the above Figures 1 to 10 The various embodiments described are directed to solutions using a DPU, but other embodiments may be implemented in other devices, such as switches or network interface cards, such as described below with reference to Figures 10 to 12 As shown and described.

[0063] Figure 44 is a block diagram of an exemplary DPU-based system architecture 400 according to at least one embodiment. The DPU-based system architecture 400 (also referred to herein as a "system" or "computing system") includes an integrated circuit (labeled as DPU 402), a host device 404, and a SIEM or XDR system 408. The DPU-based system architecture 400 can be part of a data center and include one or more data repositories, one or more server machines, and other components of a data center infrastructure. In an implementation, the network 410 can include a public network (e.g., the Internet), a private network (e.g., a local area network (LAN) or a wide area network (WAN)), a wired network (e.g., Ethernet), a wireless network (e.g., an 802.11 network or a Wi-Fi network), a cellular network (e.g., a long-term evolution (LTE) network), a router, a hub, a switch, a server computer, and / or a combination thereof.

[0064] In at least one embodiment, the DPU 402 is integrated as a SoC, which is considered as a data center infrastructure on a chip. In at least one embodiment, the DPU 402 includes a DPU hardware 412 and a software framework with an acceleration library 414. The DPU hardware 412 may include a CPU 416 (e.g., a single-core or multi-core CPU), one or more hardware accelerators 417, a memory 418, one or more host interfaces 419, and one or more network interfaces 420. The software framework and acceleration library 414 may include one or more hardware acceleration services, including hardware accelerated security services 421 (e.g., NVIDIA DOCA), hardware accelerated virtualization services 423, hardware accelerated network services 424, hardware accelerated storage services 425, hardware accelerated artificial intelligence / machine learning (AI / ML) 427, and hardware accelerated management services 428. In at least one embodiment, the DPU 402 is coupled to an accelerated AI / ML pipeline 443. In one embodiment, the accelerated AI / ML pipeline 443 may be a GPU coupled to the DPU 402. In at least one embodiment, the accelerated AI / ML pipeline 443 can host an ML detection system 118 that includes one or more ML detection models that are trained to determine whether the host device 404 is under a DDOS attack. In at least one embodiment, the accelerated AI / ML pipeline 443 is the NVIDIA MORPHEUS cybersecurity platform. The accelerated AI / ML pipeline 443 can perform pre-processing operations, inferences, post-processing operations, actions, or any combination thereof. The accelerated AI / ML pipeline 443 can be a combination of hardware and software, such as software used by the NVIDIA EXG platform to accelerate AI / ML operations on the NVIDIA EXG platform. For example, the accelerated AI / ML pipeline 443 can provide an advantage of up to 60 times the acceleration process compared to the CPU. The accelerated AI / ML pipeline 443 can also provide the advantage of a large number of inferences that can be performed in parallel (e.g., up to millions of parallel inferences). More details of the ML detection system 118 will be referenced below. Figure 6 The host device 404 may include a host physical memory 440. The host physical memory 440 may include one or more volatile and / or non-volatile memory devices configured to store data of the host device 404. In at least one embodiment, the ML detection system 118 includes the DDOS detection system 130 and other detection systems, such as a network anomaly detection system, a ransomware detection system, a malicious URL detection system, a DGA detection system, and optionally other malware detection systems.

[0065] In at least one embodiment, the hardware accelerated security service 421 includes data extraction logic 437 (e.g., a DOCA flow inspector) that extracts network data 401 from network traffic received through the network 410 via one or more network interfaces 420. The network data 401 may be received from a second device 435 through the network 410. The second device 435 may be the initiator of a malicious DDOS attack. In at least one embodiment, the hardware accelerated security service 421 receives a copy of the network data 401 (e.g., a mirror copy of the network data 401 directed to the host device 404). The data extraction logic 437 may be configured by a configuration file that specifies what type of data should be extracted from the network data 401. The configuration file may specify one or more filters that are used to extract data of a specified type from the network data 401 for inclusion or removal from inclusion. Since the network data may be a copy, network traffic that does not meet the filtering criteria may be discarded or removed. Network traffic that meets the filtering criteria may be structured and streamed to the network security platform for analysis. The data extraction logic 437 may generate a data structure using the extracted data. The data structure may be any type of data structure, such as a structure, an object, a message, etc. For example, the configuration file may specify that all Hypertext Transfer Protocol (HTTP) traffic is to be extracted from the network data 401. The configuration file may specify that all traffic on port 80, port 443, and / or port 22 should be extracted from the network data 401 for analysis. Most attacks target these three ports: SSH-22 / TCP, HTTPS-443 / TCP, and HTTP-80 / TCP.

[0066] In at least one embodiment, the hardware accelerated security service 421 includes a telemetry agent 433 that extracts metadata 403 from one or more registers 434 of the DPU hardware 412. In at least one embodiment, the telemetry agent 433 can be configured or programmed by a configuration file (the same or different configuration file as the data extraction logic 437) that specifies what metadata should be extracted from the hardware of the DPU, such as from embedded counters, registers, etc. For example, the configuration file can specify which values ​​the telemetry agent should extract from the counters, registers, etc. to stream with the extracted network data. Some metadata 403 can be associated or related to the network data 401. Some metadata 403 can be associated or related to the underlying hardware and not to the network traffic. In at least one embodiment, the telemetry agent 433 can also send a data structure with the extracted network data 401 and the extracted metadata 403 to the network security platform (e.g., (one or more) accelerated AI / ML pipelines 443).

[0067] In at least one embodiment, the telemetry agent 433 combines the extracted network data 401 and the metadata 403 into the streaming data 405. The telemetry agent 433 sends the streaming data 405 to the ML detection system 118 to determine whether the host device 404 is under a DDOS attack. In response to the ML detection system 118 determining that the host device 404 is under a DDOS attack, the ML detection system 118 sends the enforcement rule 409 to the DPU 402. The hardware accelerated security service 421 can perform the action associated with the enforcement rule 409 on subsequent network traffic directed from the second device 435 to the host device 404. In at least one embodiment, the ML detection system 118 can output an indication 411 of the classification performed by the ML detection system 429. The indication 411 can be an indication of a DDOS attack (or other network anomaly) on the host device 404. In at least one embodiment, the ML detection system 429 can send an indication 411 (e.g., a decision / alert) to the hardware accelerated security service 421, and the hardware accelerated security service 421 can send an alert 413 to the SIEM or SIEM and XDR system 408. The alert 413 can include information about the DDOS attack. In at least one embodiment, in addition to or instead of sending the indication 411 to the hardware accelerated security service 421, the ML detection system 118 can also send an indication to the SIEM or SIEM and XDR system 408.

[0068] In at least one embodiment, the data extraction logic 437 has feature extraction logic to extract one or more features and send the extracted features to the ML detection system 118 instead of sending the extracted data to the ML detection system 118. For example, the data extraction logic 437 can extract HTTP data, and the telemetry agent 433 can extract the corresponding metadata 403 from the DPU hardware registers and counters. The data extraction logic 437 can generate streaming data 405 and send it to the ML detection system 118. In another embodiment, the ML detection system 118 includes feature extraction logic to extract a set of features from the streaming data 405. The streaming data can be raw extracted data from the hardware accelerated security service 421. In at least one embodiment, the extracted features are input into the DDOS detection system 130. In at least one embodiment, the DDOS detection system 130 includes a tree-based model that is trained to determine whether the host device 404 is under a DDOS attack.

[0069] In another embodiment, Figure 4As shown, the ML detection system 118 can be hosted locally in the AI / ML service 427. In this embodiment, the hardware accelerated security service 421 can send the streaming data 405 to the AI / ML service 427. The ML detection system 118 of the AI / ML service 427 can determine whether the host device 404 is under a DDOS attack. In response to detecting the DDOS attack, the AI / ML service 427 can send the enforcement rule 409 to the hardware accelerated security service 421. Alternatively, the AI / ML service 427 can send the enforcement rule 409 to the DPU hardware 412.

[0070] Figure 5 is a flow chart of an example method 500 for detecting a DDOS attack on a host device according to at least one embodiment. The processing logic may be a combination of hardware, firmware, software, or any combination thereof. In at least one embodiment, the method 500 may be performed by Figure 1 In at least one embodiment, method 500 may be performed by the processing logic of DPU 102. Figure 2 In at least one embodiment, method 500 may be performed by processing logic of DPU 202 and GPU 204. Figure 3 In at least one embodiment, method 500 may be performed by the processing logic of DPU 302. Figure 4 The method 500 may be executed by one or more data processing units (e.g., a DPU, a CPU, and / or a GPU), including one or more memory devices (or in communication with one or more memory devices). In at least one embodiment, the method 500 may be executed by multiple processing threads, each thread executing one or more separate functions, routines, subroutines, or operations of the method. In at least one embodiment, the processing threads implementing the method 500 may be synchronized (e.g., using semaphores, critical sections, and / or other thread synchronization logic). Alternatively, the processing threads implementing the method 500 may be executed asynchronously relative to each other. The various operations of the method 500 may be executed in different Figure 5 Some operations of the method may be performed concurrently with other operations. In at least one embodiment, Figure 5 One or more of the operations shown may not always be performed.

[0071] refer to Figure 5, processing logic extracts a first feature from first data in network traffic received on a network interface (block 502). The first data is network data directed to a host device. Processing logic extracts a second feature from second data stored in a register in an acceleration hardware engine (block 504). Processing logic uses an ML detection system to determine whether the host device is under a DDOS attack based on the first feature and the second feature (block 506). In response to determining that the host device is under a DDOS attack, processing logic performs an action associated with an enforcement rule on subsequent network traffic directed from a second device to the host device (block 508).

[0072] In at least one embodiment, processing logic extracts first feature data from network traffic and extracts second feature data from a register in an acceleration hardware engine. Processing logic combines the first feature data and the second feature data into a set of features. Processing logic sends the set of features to acceleration pipeline hardware. The acceleration pipeline hardware hosts the ML detection system. Processing logic receives enforcement rules from the acceleration pipeline hardware in response to the acceleration pipeline hardware determining that the host device is under DDOS attack based on the set of features.

[0073] In at least one embodiment, the host device resides in a first computing domain, and the DPU and the ML detection system reside in a second computing domain different from the first computing domain. In at least one embodiment, the host device resides in a first computing domain, the DPU resides in a second computing domain different from the first computing domain, and the ML detection system resides in a third computing domain different from the first computing domain and the second computing domain.

[0074] DDOS Detection

[0075] As described above, one type of malicious activity is caused by a DDOS attack, such as through network traffic on a specified port. In at least one embodiment, the hardware accelerated security service and the network security platform are part of an active system for detecting DDOS attacks on a host device by extracting features from network traffic using accelerated hardware and performing anomaly detection using accelerated hardware, constantly monitoring network traffic for anomalies. The hardware accelerated security service can extract specific types of network data and metadata from the underlying accelerated hardware and stream this information to the GPU for ML-based anomaly detection. The hardware accelerated security service allows live network analysis (or real-time data analysis) of network traffic and provides mitigation or enforcement measures to immediately stop network traffic classified as malicious. In at least one embodiment, the DPU can process a copy of the network data, extract features or indications from the network data, and extract features from the DPU hardware itself, and then send it to an ML detection system on the accelerated hardware, such as a GPU coupled to the DPU. The DPU can collect real-time data through out-of-band filtering using hardware accelerated security services. The DPU can integrate the DDOS detection system with the real-time data collected by the hardware accelerated security service to detect DDOS attacks in network traffic and take immediate enforcement, mitigation, or remediation measures in response. In another embodiment, the DPU may host an ML detection system that detects DDOS attacks in network traffic.

[0076] As described herein, ML detection systems may include different types of detection systems, including DDOS detection systems (e.g., Figure 1 DDOS detection system 130), ransomware detection system, etc. Figure 6 To illustrate and describe an example of a DDOS detection system.

[0077] Figure 6 600 is a block diagram of an exemplary DDOS detection system 600 according to at least one embodiment. The DDOS detection system 600 includes feature extraction logic 602 and a tree-based model 604, which is trained using a set of features to determine whether a host device is under a DDOS attack. The feature extraction logic 602 receives streaming structured data 606 and extracts first feature data 608 from the streaming structured data 606, and extracts second feature data 610 (e.g., digital features of metadata) from registers in an acceleration hardware engine. In at least one embodiment, the feature extraction logic 602 can create an input vector using the first feature data 608 and the second feature data 610. The tree-based model 604 can receive the input vector and provide a decision on whether the host device is under a DDOS attack based on the input vector. The DDOS detection system 600 can output an indication of a DDOS attack 612 in response to determining that the host device is under a DDOS attack.

[0078] The tree-based model 604 can be a classification model or a regression model, depending on the task it is designed to solve and the type of output it produces. When the task is to predict a categorical output or a discrete output, the tree-based model 604 can be used as a classification model. The model builds a decision tree, where each internal node represents a decision based on a feature, and each leaf node corresponds to a class label. The final output is the class label of the leaf node where the input data point arrives. Examples of these types of tree-based models are decision trees, random forests, gradient boosting machines (GBM), XGBoost, LightGBM, etc. When the task is to predict a continuous output, the tree-based model 604 can also be used as a regression model. In this case, the model builds a decision tree, where each internal node represents a decision based on a feature, and each leaf node corresponds to a numerical value. Examples of these types of tree-based models are decision trees for regression, random forests for regression, GBM for regression, XGBoost, LightGBM, etc.

[0079] A tree-based regression model is a supervised machine learning algorithm used to predict continuous or numerical values. It builds a decision tree data structure to make predictions based on input features. The process starts with the entire data set, which consists of input features (also called independent variables) and corresponding continuous target values ​​(dependent variables). The algorithm looks for features that best split the data into two subsets, aiming to minimize the variance or mean squared error (MSE) of the target values ​​within each subset. The data is then divided into two child nodes based on this split. This splitting process is recursively repeated for each child node, creating more nodes and branches in the tree. At each step, the algorithm identifies the best feature to split on and continues this process until a stopping criterion is met. The stopping criterion can be the maximum depth of the tree, the minimum number of samples required to split a node, or other measures to prevent overfitting. Once the tree is built, each leaf node (terminal node) contains a subset of the data. The target values ​​within each leaf node are aggregated (usually by calculating the mean or median) to determine the final prediction for that region of the input feature space. When given a new input data point, the algorithm proceeds along the decision tree from the root node to the leaf nodes based on the values ​​of the input features. The prediction for a new data point is the value stored in the leaf node reached during the traversal. Decision trees are easy to interpret and understand. The process of making a decision can be visualized, making it easier to interpret the model's predictions. Trees can capture non-linear relationships between features and the target variable. Tree-based models are relatively robust to outliers because they segment the data into regions, reducing the impact of individual data points. To improve performance and mitigate some of the shortcomings, ensemble methods such as random forests and gradient boosting machines (GBMs) are often used, which combine multiple decision trees to make more accurate predictions.

[0080] In at least one embodiment, the tree-based model 604 is trained to distinguish network data (and metadata) into malicious network activity 614 and benign network activity 616. In at least one embodiment, the tree-based model 604 can determine the confidence level that the network activity corresponds to a malicious category or a benign category. The confidence level can be a predicted percentage of being malicious. For example, if the confidence level meets the confidence level criteria (e.g., a confidence threshold), the tree-based model 604 can classify the network activity as malicious network activity 614. In at least one embodiment, the DDOS detection system 600 can output an indication of a DDOS attack 612 in response to the network activity being classified as malicious network activity 614. The indication of the DDOS attack 612 can specify the confidence level that the network activity corresponds to the malicious category. Alternatively, the DDOS detection system 600 can output an indication of a benign network activity in response to the network activity being classified as a benign network activity 616. The indication of the benign network activity can indicate the confidence level that the network activity is benign. In other embodiments, the tree-based model 604 may output the model results of malicious network activity 614 or benign network activity 616 as a predicted percentage, such as Fig. 7A and Figure 7B shown.

[0081] In other embodiments, other types of AI / ML models may be used to determine whether the host device is under a DDOS attack based on the first feature data 608 and the second feature data 610. In some cases, the AI / ML model may only receive the first feature data 608 and determine whether the host device is under a DDOS attack. In other embodiments, additional feature data may be used to determine or predict whether the host device is under a DDOS attack.

[0082] As described above, the ML detection model (e.g., tree-based model 604) can be deployed in a DDOS detection system 600 that resides in a GPU, DPU, accelerated AI / ML pipeline, or other hardware-related hardware, as described above. In another embodiment, the hardware accelerated security service 421 and the DDOS detection system 600 can reside on a fusion card that includes DPU hardware and GPU hardware. The fusion card can be a single integrated circuit with DPU and GPU hardware. In another embodiment, the fusion card can include multiple integrated circuits to implement the functionality of the DPU and GPU, as described herein.

[0083] In at least one embodiment, the hardware accelerated security service can extract the first feature data 608 and the second feature data 610 and make the first feature data 608 and the second feature data 610 available to the DDOS detection system 600 using a publisher subscription feature (e.g., a Kafka publisher).

[0084] In various embodiments, data extraction and data analysis are performed by acceleration hardware. Acceleration hardware can be used to extract feature data from network traffic, and acceleration hardware can be used to perform ML-based anomaly detection, as described herein. Acceleration hardware can also provide enforcement rules in response to detecting anomalies to protect host devices from malicious network activities (including DDOS attacks). Acceleration hardware can construct data in any format that a network security platform can receive. The structure can be a message, a structure, etc. The feature data may not necessarily be formatted or serialized in a common format to be sent to the network security platform. In other embodiments, the acceleration hardware can use a common format or serialized data to send to the network security platform.

[0085] Fig. 7A is an illustration according to at least one embodiment Figure 6 Graph 702 shows the unsupervised model results of the tree-based model of Figure 6 The tree-based model 604 outputs malicious network activity signals 706 and benign network activity signals 708 .

[0086] Figure 7B is an illustration according to at least one embodiment Figure 6 Graph 704 shows the unsupervised model results of the tree-based model of Figure 6 The tree-based model 604 outputs malicious network activity signals 710 and benign network activity signals 712 .

[0087] Figure 8 808 is a block diagram of a computing system 800 having a DPU 802 and a GPU 804 coupled between a first host device 806 and a second host device 808 according to at least one embodiment. In at least one embodiment, the computing system 800 and the first host device 806 reside in a data center, and the second host device 808 is a malicious host attempting to attack the first host device 806. In at least one embodiment, the GPU 804 includes an ML model 810 that identifies potential malicious network activity of a DDOS attack between the first host device 806 and the second host device 808. The computing system 800 can be a network device, infrastructure device, or the like that performs network functions (such as functions performed by a hub, repeater, switch, router, bridge, gateway, modem, or network interface). Examples of network devices can include, but are not limited to, access points, routers, Access point, Routers, switches, hubs, bridges, modems, DPUs, SmartNICs, active cables, etc. In at least one embodiment, computing system 800 operates on one or more layers of the Open Systems Interconnection ("OSI") model. For example, in some cases, computing system 800 may correspond to a hub that connects computing devices that operate on the first level of the OSI model. In another embodiment, computing system 800 is a bridge or switch that handles traffic at the second layer of OSI. In another embodiment, computing system 800 is a router that operates at the third layer of OSI. In some embodiments, computing system 800 operates on multiple OSI levels.

[0088] In at least one embodiment, the operation of the computing system 800 at a layer of the OSI model includes: executing network functions related to the layer and collecting telemetry data 812 related to the execution of these functions. The telemetry data 812 may include indicators, log data, or other information describing events, states, or operations related to the computing system 800 and the execution of related functions. Note that in at least some cases and embodiments, the computing system 800 operating on a specific layer of the OSI model can collect telemetry data 812 related to its operation on the layer more efficiently than devices operating on other layers. In addition to collecting telemetry data 812, the DPU 802 also collects and filters network traffic to obtain filtered network data 814. The filtered network data 814 can be HTTP traffic, such as network data on a specified port. The filtered network data 814 and the telemetry data 812 can be combined and sent to the GPU 804 as feature data 816 for DDOS detection. The GPU 804 uses the ML model 810 to identify the network traffic as malicious, i.e., a DDOS attack, using the feature data 816. In response to identifying the DDOS attack, GPU 804 sends enforcement rules 818 to DPU 802 to protect first host device 806 from malicious network traffic of the DDOS attack of second host device 808 .

[0089] In at least one embodiment, the computing system 800 collects and processes telemetry data 812 and filtered network data 814, which are collected by the computing system 800 in real time. For example, such data may be collected by an application specific integrated circuit ("ASIC") that performs the network functions of the device. Using this technique, the telemetry data 812 can be quickly read from the device's registers or other internal memory. Examples of telemetry data may include, but are not limited to, latency histograms, receive counters, transmit counters, metrics related to encapsulation or decapsulation, queue occupancy, queue length, and power level usage indicators. Note that in some cases, attempts to exploit the device to perform cryptocurrency mining, malicious or other undesirable usage patterns may result in increased power consumption of the computing system 800.

[0090] In at least one embodiment, the computing system 800 includes a network component, an ML model 810, and a database. The network component may include circuits and other computing facilities, such as a processor, a memory, and processor-executable instructions, for performing one or more network-related functions of the computing system 800, such as sending or receiving data. The network function may include sending or receiving data between a first host device 806 and a second host device 808. In at least one embodiment, the second host device 808 is considered a source host, and the first host device 806 may be considered a destination host. The source host may be a device, such as a computing device that sends data over a network. Similarly, the destination host may be a device, such as a computing device that receives data sent over a network.

[0091] In at least one embodiment, the ML model 810 can analyze network traffic and identify unwanted data or network traffic patterns. The ML model 810 can implement one or more of a variety of machine learning methods, techniques, and algorithms. These can include, but are not limited to, supervised learning, unsupervised learning, deep learning, and reinforcement learning. Embodiments of the ML model 810 can, for example, implement algorithms for regression, clustering, instance-based algorithms, regularization algorithms, artificial neural networks, convolutional neural networks, recurrent neural networks, long short-term memory networks, decision trees, deep belief networks, gradient boosting, XGBoost, support vector machines, Bayesian techniques, random forests, and the like. It will be appreciated that these examples are intended to be illustrative. Therefore, potential embodiments should not be construed in a manner that limits them to embodiments that only include the specific examples provided.

[0092] In at least one embodiment, the ML model 810 is trained to identify bad use of the computing system 800. Such use may include using the computing system 800 in a manner that causes or facilitates harm, such as damage to the operation of a computer or computer network, harmful disclosure of information, harmful data transmission, etc. In at least one embodiment, the ML model 810 is trained to identify harmful use of the computing system 800 using a data set of examples. These examples may include network telemetry, network data packets, series of network data packets, or other information. In at least one embodiment, these examples are labeled to indicate whether a particular example is associated with bad data or traffic patterns. Depending on the needs of the machine learning model, various techniques can use labeled or unlabeled data to train the model.

[0093] In at least one embodiment, the computing system 800 includes a database that can maintain information related to the ML model 810. For example, the database can maintain the data set just described for training the ML model 810, retraining the ML model 810, or improving the training of the ML model 810. For example, in at least one embodiment, a set of example data patterns are maintained in the database that indicate malicious, unauthorized, or otherwise undesirable network traffic patterns. When new attack patterns are discovered, the data can be updated or supplemented. Therefore, the computing system 800 can include circuits, processor executable instructions, or other computing facilities for receiving updated data and storing the data in the database.

[0094] In at least one embodiment, computing system 800 includes circuitry, processor-executable instructions, or other computing facilities for training, retraining, or improving ML model 810 using such updated data from the database. For example, upon discovery of a new attack pattern, the database may be updated in response to a request from an external source, such as a command from a device performing management functions. After the update, computing system 800 initiates a training procedure using the data stored in the database to train ML model 810, retrain ML model 810, or improve the training of ML model 810. ML model 810 may then have an improved ability to detect network patterns that reflect characteristics similar to those of the new attack pattern or network patterns that reflect characteristics similar to those of other previously known patterns associated with bad network usage.

[0095] In at least one embodiment, the database is omitted from the computing system 800. In some embodiments, an external database is used, and the training samples are transmitted to the computing system 800 and used by the computing system 800 to train the ML model 810, retrain the ML model 810, or improve the training of the ML model 810. In other embodiments, the training, retraining, or improvement of the ML model 810 is performed externally, and the ML model 810 is updated to reflect the new training. For example, in at least one embodiment, a set of weights or other parameters (such as weights or parameters used in an artificial neural network) are transmitted to the computing system 800 and used to update the corresponding weights or parameters in the ML model 810.

[0096] In at least one embodiment, computing system 800 operates on one or more selected layers of the OSI model, collects data related to network operations performed on the one or more selected layers, and analyzes the data using ML model 810 to identify suspicious or unauthorized network traffic patterns. For example, ML model 810 may infer that an observed network traffic pattern appears to be a DDOS attack or other malicious use of computing system 800 based on analyzing data from the OSI layer. Computing system 800 may then initiate a response to the detected network traffic pattern. By performing analysis on computing system 800, data related to a particular OSI layer may be analyzed, and undesired use of computing system 800 may be detected faster or more efficiently than if the analysis were performed remotely. In certain embodiments, such an approach may also convey advantages by allowing analysis of data at a particular OSI layer without transmitting the data to another device or otherwise facilitating faster analysis and response to the data.

[0097] Fig. 9 An example process 900 of DDOS attack detection using a machine learning model according to at least one embodiment is shown. In the example process flow 900, Figure 8The DPU 802 can perform various operations, and the GPU component 920 can perform various operations. The GPU component 920 can be part of a host device. At block 902, the DPU 802 collects filtered network data as described above. The filtered network data can be collected by a hardware accelerated security service (e.g., a flow inspector) as described above. At block 904, the DPU 802 collects telemetry data related to the network operations performed by the DPU 802. In at least one embodiment, the telemetry data is collected by a telemetry agent. Then, in at least one embodiment, the filtered network data and telemetry data are routed to a machine learning model on the GPU component 804 at block 906. In at least one embodiment, training of the machine learning model is performed at block 910 using the filtered network data and telemetry data. This can include retraining or improving a trained model, or training a new or additional machine learning model. In at least one embodiment, the filtered network data and telemetry data collected at blocks 902 and 904 are used to perform reasoning or other analysis consistent with a model type for identifying potential DDOS attacks manifested in undesirable traffic patterns at block 912. At block 914, if a DDOS attack is detected, the GPU component 804 generates an enforcement rule at block 918 to block network traffic for a given DDOS attack. At block 918, the enforcement rule is routed to the DPU 802. The enforcement rule may include mitigation measures, preventive measures, remedial measures, etc. The enforcement rule may be used to prevent traffic from interfering with the operation of the DPU 802 or host device targeted by the DDOS attack. For example, in at least one embodiment, the machine learning model at block 914 identifies bad use of the DPU 802 and may be further used to identify usage characteristics, such as network ports associated with bad use. The DPU 802 may determine whether an enforcement rule is received from the GPU component 804 at block 908. If an enforcement rule is received at block 908, the DPU 802 may apply the enforcement rule to prevent the DDOS attack (block 918). The DPU 802 may perform one or more actions to mitigate, prevent, or remedy the DDOS attack. Examples of potential enforcement actions may include (but are not necessarily limited to) sending a notification describing the reasoning, limiting the use of a network device, shutting down a network device, slowing down a network device, applying restrictions to traffic associated with a network traffic pattern, etc. It will be appreciated that these examples are intended to be illustrative and not limiting. If an enforcement rule is not received at block 908, the DPU 802 may continue to collect filtered network data at block 902.

[0098] After making a determination, in at least one embodiment, information about the determination is fed back to the model training at block 910. This can include information indicating whether a network traffic pattern (or other data or condition) classified as undesirable by the machine learning model is confirmed to be undesirable or not undesirable. This information can then be used in the model training at block 910 to improve the model's understanding of potentially malicious or otherwise undesirable network traffic patterns and approve the model's ability to identify and distinguish undesirable behavior from behavior consistent with the intended use of the DPU 802.

[0099] exist Fig. 9 In an embodiment, both the model training at block 910 and the model inference at block 912 are performed on the GPU component of the host device. The GPU component is local to the host device because it runs the model inference at block 912. In another embodiment, the model training at block 910 can be performed offline, such as on the ML data repository of the central ML platform. The model training at block 910 can be performed during the development cycle, and the GPU component 920 located locally on the host performs model inference at block 912 to detect anomalies. In another embodiment, the model training at block 910 can be a scheduled retraining performed remotely, such as in the ML platform, scheduled retraining on recent data collected to the centralized ML data repository. The model can be updated regularly on the GPU component of each host. This can be an automatic or partially automatic update procedure. In this embodiment, the model inference at block 912 is performed locally on the host. In another embodiment, the model training at block 910 can be performed locally on each host (e.g., fine-tuning a general model that was initially trained remotely, such as in a centralized ML platform). The locally trained model at block 9120 can be used by the GPU component 920 of the host, such as Fig. 9 shown.

[0100] Fig.10 is a flow chart of a method for determining whether a host device is under a DDOS attack according to one embodiment. The processing logic may be a combination of hardware, firmware, software, or any combination thereof. In at least one embodiment, the method 1000 may be Figure 1 In at least one embodiment, method 1000 may be performed by the processing logic of DPU 102. Figure 2 In at least one embodiment, method 1000 may be performed by the processing logic of DPU 202 and GPU 204. Figure 3 In at least one embodiment, method 1000 may be performed by the processing logic of DPU 302. Figure 4The method 1000 may be executed by one or more data processing units (e.g., a DPU, a CPU, and / or a GPU), including one or more memory devices (or in communication with one or more memory devices). In at least one embodiment, the method 500 may be executed by multiple processing threads, each thread executing one or more separate functions, routines, subroutines, or operations of the method. In at least one embodiment, the processing threads implementing the method 1000 may be synchronized (e.g., using semaphores, critical sections, and / or other thread synchronization logic). Alternatively, the processing threads implementing the method 1000 may be executed asynchronously with respect to each other. The various operations of the method 1000 may be executed in different Fig.10 Some operations of the method may be performed concurrently with other operations. In at least one embodiment, Fig.10 One or more of the operations shown in may not always be performed.

[0101] refer to Fig.10 , processing logic first begins with processing logic (e.g., a DPU coupled to a host device) extracting a plurality of features from first data in network traffic data received on a network interface of the DPU and second data stored in a register in an acceleration hardware engine of the DPU, the first data being directed from a second device to the host device (block 1002). At block 1004, processing logic determines whether the host device is under a distributed denial of service (DDOS) attack based on the plurality of features using a machine learning (ML) detection system. At block 1006, in response to determining that the host device is under a DDOS attack, processing logic performs, through the DPU, an action associated with enforcement of a rule on subsequent network traffic data directed from the second device to the host device.

[0102] In a further embodiment, the processing logic extracts first feature data from the network traffic data and extracts second feature data from a register in the acceleration hardware engine. The processing logic combines the first feature data and the second feature data into a plurality of features. The processing logic sends the plurality of features to the acceleration pipeline hardware hosting the ML detection system. The processing logic receives an enforcement rule from the acceleration pipeline hardware in response to the acceleration pipeline hardware determining that the host device is under a DDOS attack based on the plurality of features.

[0103] In at least one embodiment, the processing logic extracts the first feature data from the network traffic data without extracting the second feature data from the register in the acceleration hardware engine. The processing logic sends the first feature data to the acceleration pipeline hardware hosting the ML detection system. The processing logic receives the enforcement rule from the acceleration pipeline hardware in response to the acceleration pipeline hardware determining that the host device is under DDOS attack based on the first feature data.

[0104] In at least one embodiment, the processing logic extracts the first feature data by receiving the mirrored network traffic data from the acceleration hardware engine. The processing logic uses the acceleration hardware engine to offload the mirrored network traffic data and filters the mirrored network traffic data based on a predefined filter to obtain filtered network traffic. The processing logic generates the first feature data based on the filtered network traffic. The processing logic extracts the second feature data by extracting telemetry data from a register of the acceleration hardware engine.

[0105] In at least one embodiment, the processing logic generates second feature data based on the telemetry data, and combines the first feature data and the second feature data into a plurality of features. The processing logic sends the plurality of features to the acceleration pipeline hardware.

[0106] Although the above Figures 1 to 10 The various embodiments described are directed to DPU-based solutions, but other embodiments may be implemented with switch-based solutions, such as described below with respect to Figure 11 to Figure 12 That is, in at least one embodiment, the collection and / or detection of DDOS attacks can be performed on a switch or other network interface device.

[0107] Switch-based system architecture

[0108] Fig.11 1 is a block diagram of an exemplary switch-based system architecture 1100 according to at least one embodiment. The switch-based system architecture 1100 (also referred to herein as a "system" or "computing system") includes a switch 1102, a host device 1104, a host device 1106, and a host device 1108 in a monitored data center 1120. The switch 1102, also referred to as a "network switch," is a network device that connects multiple devices within a local area network (LAN) (or virtual LAN (VLAN)), allowing multiple devices to communicate with each other by forwarding data packets based on their destination media access control (MAC) addresses. VLANs can be configured on network switches to segment and isolate network traffic for different purposes, such as separating production and development environments. In a data center environment, network switches provide high-speed, low-latency connections between servers, storage devices, and other network devices. In larger data center architectures, aggregation switches and core switches can be used to connect multiple server racks and provide connections to external networks.

[0109] Although the monitored data center 1120 is shown as having three host devices 1104-1108, the monitored data center 1120 may include more or fewer host devices. The three host devices 1104-1108 are shown as three different scenarios, in which the switch 1102 can be used as part of the attack detection framework, as described in more detail below. The switch 1102 can be a top-of-rack (TOR) switch commonly used in data center environments. The switch 1102 can connect servers and network devices within the rack and provide high-speed and low-latency connectivity. The switch 1102 may include a CPU, a memory, a port interface, and a switching fabric. The switching fabric is responsible for forwarding data packets between different ports. The switching fabric may be composed of dedicated integrated circuits and components that manage data flows. The port interface is a physical interface where a device (e.g., a server, a storage device, or other switch) is connected to the switch 1102. The port interface may include an Ethernet port, a fiber connection, a copper connection, etc. The CPU and memory handle management tasks, control plane operations, and handle routing and switching protocols. Switch 1102 can execute software components such as an operating system, switching and routing protocols (e.g., network protocols such as Ethernet switching, IP routing, VLAN management, etc.), management interfaces (e.g., a command line interface (CLI), a web interface, or an application programming interface (API) that allows network administrators to set up VLANs, configure ports, and monitor network performance), security features (access control lists (ACLs), port security, authentication, etc.), monitoring and reporting, and firmware.

[0110] The management platform 1116 may be associated with the monitored data center 1120. The management platform 1116 may be used to coordinate and configure the various components of the attack detection framework. In at least one embodiment, the management platform 1116 is a network security platform. The switch-based system architecture 1100 may be part of the monitored data center 1120 and may include one or more data repositories, one or more server machines, and other components of the data center infrastructure. In this embodiment, the switch 1102 may be coupled to the host devices 1104-1108 via a network. The network may be a public network (e.g., the Internet), a private network (e.g., a local area network (LAN) or a wide area network (WAN)), a wired network (e.g., Ethernet), a wireless network (e.g., an 802.11 network or a Wi-Fi network), a cellular network (e.g., a long-term evolution (LTE) network), a router, a hub, a switch, a server computer, and / or a combination thereof.

[0111] As described above, a switch-based attack detection framework may be relevant when there are endpoints that do not have a DPU, the endpoint devices are unable to stream data at scale, or attack detectors (e.g., ML detection systems) cannot be implemented on the endpoint devices. Network traffic at a switch (particularly a TOR switch) is similar to the network traffic seen by a DPU. Therefore, the above-described techniques for collecting, filtering, and processing network data to determine whether a host is under a DDOS attack can be applied in switch 1102 or between a DPU and switch 1102. In some cases, the relevant data for DDOS attack detection is not encrypted. In other cases, full encryption can be performed because the detection is based only on timing characteristics.

[0112] like Fig.11 As shown, the switch 1102 may include network monitoring logic 1112 (e.g., offloaded sFlow technology) that can monitor and analyze network traffic in real time. The network monitoring logic 1112 can provide a method for collecting data about network traffic flows, including information about the source and destination of the traffic, the protocols being used, and other relevant metrics. The network monitoring logic 1112 can provide the collected data 1158 (e.g., flow data) to the ML detection system 118 hosted on the switch 1102. The network monitoring logic 1112 can provide the collected data 1160 to the data flow collector 1110 (e.g., sFlow collector) when training the ML model of the ML detection system 118, as described in more detail below. The network monitoring logic 1112 can use sFlow technology, NetFlow technology, etc. sFlow technology is generally used to gain insight into network performance, solve problems, and enhance security by detecting abnormal or suspicious activities. It works by sampling portions of network packets passing through a network device (e.g., a switch 1102 or a router). These sampled packets can be used to represent the behavior of the overall network traffic. The network monitoring logic 1112 may generate flow records that include information about sampled packets, such as source and destination IP addresses, source and destination ports, protocol types, and packet counters. These flow records provide an aggregated view of network traffic. The data flow collector 1110 may be an sFlow collector, which is a software or hardware component that receives, processes, and stores sFlow data collected from various network devices. The main purpose of an sFlow collector is to analyze network traffic flows, monitor network behavior, and provide insights into network performance, usage patterns, and security events.

[0113] In at least one embodiment, the network monitoring logic 1112 may collect and filter network data in a manner similar to the data extraction logic 114 (e.g., DOCA flow inspector) described above. The network monitoring logic 1112 may extract feature data from network traffic received from a second device (or multiple devices) at the switch 1102. The second device may be a device external to the monitored data center 1120. The second device may be a device within the monitored data center 1120. The second device may be the initiator of a DDOS attack. In at least one embodiment, the network monitoring logic 1112 may be configured by a configuration file that specifies what type of data should be extracted from the network data. The configuration file may specify one or more filters for extracting specified types of data from the network data for inclusion or removal from inclusion. Network traffic that meets the filtering criteria may be constructed and streamed to the ML detection system 118 for analysis. In at least one embodiment, the network monitoring logic 1112 may generate a data structure using the extracted data. The data structure may be any type of data structure, such as a structure, an object, a message, etc. For example, the configuration file may specify that all HTTP traffic is extracted from the network data. The configuration file may specify that all traffic on port 80, port 443, and / or port 22 should be extracted from the network data for analysis. A large portion of attacks target these three ports: SSH-22 / TCP, HTTPS-443 / TCP, and HTTP-80 / TCP. The collected data may be sent or streamed to the ML detection system 118. The ML detection system 118 includes one or more ML detection models that are trained to determine whether a host device is under a DDOS attack based on feature data extracted by the network monitoring logic 1112. In response to a determination of a DDOS attack, the ML detection system 118 may send an alert 1152 to the management platform 1116. If the host device 1104 is under a DDOS attack, the ML detection system 118 may send an alert 1154 to the host device 1104.

[0114] In at least one embodiment, the host device 1104 includes a network interface card (NIC) 1132, a hypervisor 1134, and a plurality of virtual machines (VMs) 1136. In this embodiment, the ML training platform 1118 can send an alert 1154 to the hypervisor 1134 to perform actions to remediate or prevent the DDOS attack from affecting the host device 1104. In some cases, when the second device is part of the monitored data center 1120, the ML detection system 118 can send a command to shut down the second device or otherwise restrict the second device from performing a DDOS attack.

[0115] In at least one embodiment, the host device 1106 includes a DPU 1138, a hypervisor 1140, and a plurality of VMs 1142. In this embodiment, the ML training platform 1118 can send an alert 1156 to the DPU 1138 to perform actions to remediate or prevent the DDOS attack from affecting the host device 1106.

[0116] As described above, three host devices 1104-1108 are shown for three different scenarios in which switch 1102 can be used as part of an attack detection framework. In the first scenario, host device 1104 does not use a DPU; instead, NIC 1132 is used for network traffic to and from switch 1102. In this case, switch 1102 (e.g., a TOR switch) implements ML detection system 118 to detect whether host device 1104 is under a DDOS attack, and ML detection system 118 can command manager 1134 to take action against malicious resources (e.g., one of the VMs).

[0117] In the second scenario, the host device 1106 uses the DPU 1138 for network traffic to and from the switch 1102. In this scenario, the DPU 1138 cannot be used to offload detection, or inference needs to be run at the location where the training data is streamed (i.e., the switch 1102). In this scenario, the switch 1102 (e.g., a TOR switch) implements the ML detection system 118 to detect whether the host device 1106 is under a DDOS attack, and the ML detection system 118 can command the DPU 1138 to take action against the malicious resource (e.g., one of the VMs).

[0118] In a third scenario, the host device 1108 uses the DPU 1144 to offload detection (and optionally action). In this scenario, the DPU 1144 cannot stream (cannot offload streaming), and does not need to run inference at the location where the training data is streamed (i.e., the switch 1102). In this scenario, the DPU 1144 implements the ML detection system 118 to determine whether the host device 1108 is under a DDOS attack, and the ML detection system 118 can command the DPU 1144 to take action against the malicious resource (e.g., one of the VMs). In at least one embodiment, the ML training platform 1118 can send an alert 1162 to the management platform 1116. The management platform 1116 can send enforcement rules 1164 back to the DPU 1144. Alternatively, the management platform 1116 can send other commands to perform other mitigation or prevention actions for the detected attack. This scenario is similar to the DPU-based system architecture described above, where the ML detection system 118 is implemented in the DPU. In this case, switch 1102 can be used as a streaming point to collect data for training the ML model, as described below.

[0119] In at least one embodiment, the switch 1102 may be used to collect network data to train one or more ML models 1130. In this embodiment, the network monitoring logic 1112 may redirect or send sFlow data from the switch 1102 to the ML training platform 1118 using offloaded sFlow technology. The ML training platform 1118 may be located in a cloud computing system 1122. Alternatively, the ML training platform 1118 may be located elsewhere. The ML training platform 1118 may use a streaming pipeline 1126 (e.g., Kafka technology) to process sFlow data received from the switch 1102. In at least one embodiment, the network monitoring logic 1112 may send sFlow data to a data flow collector 1110 that collects flow data from one or more switches. The data flow collector 1110 may send the flow data to a streaming pipeline 1126. The streaming pipeline 1126 may store the flow data in a data repository 1124. The trainer 1128 can access the streaming data in the data repository 1124 to train one or more ML models 1130. The one or more ML models 1130 can be deployed to the switch 1102 or the host device 1108. In at least one embodiment, model procurement can be used to automatically deploy the one or more ML models 1130 to the ML detection system 118. Model procurement can also update the one or more ML models 1130 through a release cycle.

[0120] In at least one embodiment, the network monitoring logic 1112 may collect flow data by sampling packets passing through it. The flow data may include information about network traffic flows, such as source and destination addresses, protocols, and other relevant metrics. Instead of saving the flow data within the switch 1102, the flow data is sent or offloaded to an external system, such as a data flow collector 1110 and / or an ML training platform 1118. The ML training platform 1118 has the ability to process and analyze large amounts of flow data. The ML training platform 1118 may receive and process the offloaded flow data. The ML training platform 1118 may perform various operations through the trainer 1128 to train or update one or more ML models 1130. The ML training platform 1118 may store the flow data in a data repository 1124 for historical purposes. Such historical data may be used to identify trends, assess changes in the network over time, and generate one or more ML models 1130. Offloading flow data (e.g., sFlow data) may reduce the processing load on the switch 1102, enabling it to focus on its primary role of routing or switching network traffic. Offloading allows for centralized monitoring and analysis of flow data from multiple network devices in an organization, providing a holistic view of the entire network. The ML training platform 1118 can also be used to scale more efficiently to handle larger volumes of flow data.

[0121] In at least one embodiment, the switch includes a plurality of port interfaces, a memory for storing instructions, and a CPU operably coupled to the memory and the port interface. The CPU can execute instructions to perform operations, including extracting a plurality of features from network traffic data received from a second device and directed to a host device (e.g., host device 1104 and host device 1106) through at least one of the plurality of port interfaces. The switch can use an ML detection system to determine that the host device is under a DDOS attack based on a plurality of features extracted from the network traffic data. The switch can provide a DDOS attack alert to the host device in response to determining that the host device is under a DDOS attack. In at least one embodiment, the plurality of features include one or more of the following: a source media access control (MAC) address; a destination MAC address; a source Internet Protocol (IP) address; a destination IP address; a source port; a destination port; a protocol identifier; a packet size; or a maximum packet size.

[0122] In at least one embodiment, the ML detection system includes a tree-based ML model that is trained to determine whether a host device is under a DDOS attack based on a plurality of features. In at least one embodiment, the ML detection system includes a regression model that is trained to predict whether a host device is under a DDOS attack based on a plurality of features.

[0123] In at least one embodiment, the CPU may send an enforcement rule to the host device in response to determining that the host device is under a DDOS attack. In at least one embodiment, the CPU may provide an alarm to a DPU of the host device (e.g., DPU 1138 of host device 1106). The alarm may cause the DPU to perform an action associated with the enforcement rule. In at least one embodiment, the CPU may provide an alarm to a manager executed by the host device (e.g., manager 1134 of host device 1104). The host device may include a NIC. The alarm may cause the manager to perform an action associated with the enforcement rule.

[0124] In at least one embodiment, the switch includes an accelerated hardware engine and a network monitoring logic. The accelerated hardware engine can implement an ML detection system. The network monitoring logic can extract multiple features from the network traffic data and send the multiple features to the ML detection system to determine whether the host device is under a DDOS attack. In at least one embodiment, the accelerated hardware engine can receive multiple features from the network monitoring logic. The accelerated hardware engine can use a regression model to determine whether the host device is under a DDOS attack, and the regression model is trained to predict whether the host device is under a DDOS attack based on multiple features. The accelerated hardware engine can send an alarm to the host device in response to determining that the host device is under a DDOS attack. In another embodiment, the accelerated hardware engine can use a tree-based ML model, which is trained to determine whether the host device is under a DDOS attack based on multiple features.

[0125] In at least one embodiment, a network device includes a network interface, a host interface, and a processing device operably coupled to the network interface and the host interface. The network device may be a switch coupled to the host device. The network device may be a NIC coupled to the host device. The processing device may extract multiple features from network traffic data received through the network interface and directed to the host device from a second device. The processing device may use an ML detection system to determine that the host device is under a DDOS attack based on multiple features extracted from the network traffic data. The processing device may provide an alert of a DDOS attack to the host device in response to determining that the host device is under a DDOS attack.

[0126] Fig.12 is a flow chart of a method 1200 for determining whether a host device is under a DDOS attack according to one embodiment. The processing logic may be a combination of hardware, firmware, software, or any combination thereof. In at least one embodiment, the method 1200 may be Fig.111102. In at least one embodiment, method 1200 may be performed by multiple processing threads, each thread performing one or more separate functions, routines, subroutines, or operations of the method. In at least one embodiment, the processing threads implementing method 1200 may be synchronized (e.g., using semaphores, critical sections, and / or other thread synchronization logic). Alternatively, the processing threads implementing method 1200 may be executed asynchronously with respect to each other. The various operations of method 1200 may be performed in different Fig.12 Some operations of the method may be performed concurrently with other operations. In at least one embodiment, Fig.12 One or more of the operations shown in may not always be performed.

[0127] refer to Fig.12 , processing logic begins with processing logic (e.g., a switch coupled to a host device) extracting a plurality of features from network traffic data received on a port interface of the switch, the network traffic data being directed from a second device to the host device. At block 1204, processing logic determines whether the host device is under a DDOS attack based on the plurality of features using the ML detection system. At block 1206, in response to determining that the host device is under a DDOS attack, processing logic causes execution of an action associated with enforcement of the rule on subsequent network traffic data directed from the second device to the host device.

[0128] In at least one embodiment, processing logic uses a regression model at block 1204 that is trained to predict whether the host device is under a DDOS attack based on multiple features. In at least one embodiment, processing logic at block 1204 uses a tree-based ML model that is trained to determine whether the host device is under a DDOS attack based on multiple features.

[0129] In at least one embodiment, the ML detection system is implemented in a switch. In at least one embodiment, the ML detection system is implemented in an acceleration hardware engine coupled to the switch.

[0130] In at least one embodiment, the processing logic at block 1206 causes an action to be performed by sending an alert to a DPU of the host device. The DPU may perform an action associated with enforcing the rule. In at least one embodiment, the processing logic at block 1206 causes an action to be performed by sending an alert to a manager executed by the host device. The manager may perform an action associated with enforcing the rule.

[0131] In at least one embodiment, the plurality of characteristics includes one or more of: source MAC address, destination MAC address, source IP address, destination IP address, source port, destination port, protocol identifier, packet size, maximum packet size, and the like.

[0132] Other variations are within the spirit of the present disclosure. Thus, while the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described in detail above. However, it should be understood that it is not intended to limit the present disclosure to one or more specific forms disclosed, but on the contrary, it is intended to cover all modifications, alternative constructions, and equivalents that fall within the spirit and scope of the present disclosure as defined by the appended claims.

[0133] In the context of describing the disclosed embodiments (especially in the context of the following claims), the use of the terms "one" and "a kind of" and "said" and similar indicators should be interpreted as covering both the singular and the plural, unless otherwise indicated herein or clearly contradicted by the context, and not as a definition of the term. Unless otherwise noted, the terms "comprise", "have", "include" and "contain" should be interpreted as open terms (meaning "including but not limited to"). When unmodified and referring to a physical connection, the term "connection" should be interpreted as being partially or completely contained in, attached to or connected together, even if there is an intervening object. Unless otherwise indicated herein, the statement of the value range herein is intended only to be used as a shorthand method to refer to each individual value falling within the range individually, and each individual value is incorporated into the specification as it is individually stated herein. Unless otherwise indicated or the context is contradictory, the use of the term "set" (e.g., "item set") or "subset" will be interpreted as a non-empty set including one or more members. Furthermore, unless otherwise stated or contradicted by context, the term "subset" of a corresponding set does not necessarily mean a proper subset of the corresponding set, but rather a subset and a corresponding set may be equivalent.

[0134] Unless otherwise expressly stated or otherwise clearly contradicted by context, conjunction language (such as phrases of the form "at least one of A, B, and C" or "at least one of A, B, and C") is also understood together with context to be generally used to present that an item, term, etc. can be any non-empty subset of the set of A or B or C, or A and B and C. For example, in the exemplary example of a group with three members, the conjunction phrases "at least one of A, B, and C" and "at least one of A, B, and C" refer to any of the following groups: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Therefore, such conjunction language is generally not intended to imply that certain embodiments require the presence of at least one of A, at least one of B, and at least one of C, respectively. In addition, unless otherwise stated or contradicted by context, the term "plurality" means a plurality of states (e.g., "a plurality of items" means a plurality of items). In at least one embodiment, a plurality is at least two items, but can be more when explicitly or by context so indicates. Further, the phrase "based on" means "based at least in part on" rather than "based solely on" unless stated otherwise or otherwise clear from the context.

[0135] The operations of the processes described herein may be performed in any suitable order, unless otherwise indicated herein or otherwise clearly contradictory to the context. In at least one embodiment, processes such as those described herein (or variations and / or combinations thereof) are performed under the control of one or more computer systems configured with executable instructions, and are implemented as codes (e.g., executable instructions, one or more computer programs, or one or more applications) that are executed together on one or more processors by hardware or a combination thereof. In at least one embodiment, the code is stored on a computer-readable storage medium, for example, in the form of a computer program including a plurality of instructions that can be executed by one or more processors. In at least one embodiment, the computer-readable storage medium is a non-transient computer-readable storage medium that does not include transient signals (e.g., propagating transient electrical or electromagnetic transmissions) but includes non-transient data storage circuits (e.g., buffers, caches, and queues) within a transceiver of a transient signal. In at least one embodiment, code (e.g., executable code or source code) is stored on a collection of one or more non-transitory computer-readable storage media having executable instructions stored thereon (or other memory for storing executable instructions), which when executed (i.e., due to being executed) by one or more processors of a computer system causes the computer system to perform the operations described herein. In at least one embodiment, a set of non-transitory computer-readable storage media includes a plurality of non-transitory computer-readable storage media, and one or more of the individual non-transitory storage media in the plurality of non-transitory computer-readable storage media lack all codes, while the plurality of non-transitory computer-readable storage media collectively store all codes. In at least one embodiment, executable instructions are executed so that different instructions are executed by different processors. For example, a non-transitory computer-readable storage medium stores instructions, the main CPU executes some instructions, and the GPU executes other instructions. In at least one embodiment, different components of the computer system have separate processors, and different processors execute different subsets of instructions.

[0136] Thus, in at least one embodiment, a computer system is configured to implement one or more services that individually or collectively perform the operations of the processes described herein, and such a computer system is configured with applicable hardware and / or software capable of performing the operations. Further, a computer system implementing at least one embodiment of the present disclosure is a single device, and in another embodiment, is a distributed computer system comprising multiple devices that operate differently, such that the distributed computer system performs the operations described herein, and such that a single device does not perform all operations.

[0137] The use of any and all examples or exemplary language (e.g., "such as") provided herein is intended only to better illustrate embodiments of the present disclosure and does not limit the scope of the present disclosure unless otherwise required. Language in the specification should not be construed as indicating any non-claimed element is essential to the practice of the present disclosure.

[0138] All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.

[0139] In the specification and claims, the terms "coupled" and "connected" and their derivatives may be used. It should be understood that these terms are not intended to be synonymous with each other. On the contrary, in specific examples, "connected" or "coupled" may be used to indicate that two or more elements are in direct or indirect physical or electrical contact with each other. "Coupled" may also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other.

[0140] Unless specifically stated otherwise, it will be appreciated that throughout the specification terms such as "processing," "computing," "calculating," "determining," or similar terms refer to the action and / or process of a computer or computing system or similar electronic computing device that manipulates and / or transforms data represented as physical (such as electronic) quantities within the computing system's registers and / or memories into other data similarly represented as physical quantities within the computing system's memories, registers, or other such information storage, transmission, or display devices.

[0141] In a similar manner, the term "processor" may refer to any device or part of a device that processes electronic data from registers and / or memory and converts the electronic data into other electronic data that can be stored in registers and / or memory. A "computing platform" may include one or more processors. As used herein, a "software" process may include, for example, software and / or hardware entities that perform work over time, such as tasks, threads, and intelligent agents. Moreover, each process may refer to multiple processes for executing instructions sequentially or in parallel, continuously or intermittently. The terms "system" and "method" are used interchangeably herein, as long as the system can embody one or more methods and the method can be considered a system.

[0142] In this document, reference may be made to obtaining, acquiring, receiving or inputting analog or digital data into a subsystem, a computer system or a computer-implemented machine. Obtaining, acquiring, receiving or inputting analog and digital data may be accomplished in various ways, such as by receiving data as a parameter of a function call or a call to an application programming interface. In some implementations, the process of obtaining, acquiring, receiving or inputting analog or digital data may be accomplished by transmitting data via a serial or parallel interface. In another implementation, the process of obtaining, acquiring, receiving or inputting analog or digital data may be accomplished by transmitting data from a providing entity to an acquiring entity via a computer network. Reference may also be made to providing, outputting, transmitting, sending or presenting analog or digital data. In different examples, the process of providing, outputting, transmitting, sending or presenting analog or digital data may be accomplished by transmitting data as an input or output parameter of a function call, a parameter of an application programming interface or an inter-process communication mechanism.

[0143] Although the above discussion describes example implementations of the technology, other architectures may also be used to implement the functionality and are intended to be within the scope of the present disclosure. In addition, although specific allocations of responsibilities are defined above for discussion purposes, various functions and responsibilities may be allocated and divided in different ways depending on the circumstances.

[0144] In addition, although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter claimed in the appended claims is not necessarily limited to the specific features or acts described. Instead, the specific features and acts are disclosed as exemplary forms of implementing the claims.

Claims

1. An integrated circuit, comprising: An acceleration hardware engine operably coupled to the host interface and the network interface, wherein the acceleration hardware engine is configured to: extracting a plurality of features from network traffic data received through the network interface and directed from the second device to the host device; Using a machine learning (ML) detection system, determining that the host device is under a distributed denial of service (DDOS) attack based on the plurality of features extracted from the network traffic data; as well as Perform the actions associated with enforcing the rule.

2. The integrated circuit of claim 1 , further comprising: A central processing unit (CPU) operably coupled to the host interface and the network interface, wherein the CPU and the accelerated hardware engine are used to host a hardware accelerated security service, wherein the hardware accelerated security service is used to: extracting the plurality of features from the network traffic data; sending the plurality of features to the ML detection system to determine whether the host device is under the DDOS attack; receiving the enforcement rule from the ML detection system in response to determining that the host device is under the DDOS attack; as well as An action associated with the enforcement rule is performed on subsequent network traffic data directed from the second device to the host device.

3. The integrated circuit of claim 2, wherein the hardware accelerated security service extracts the plurality of features by an operation comprising: Extracting first feature data from the network traffic data; and The second feature data is extracted from a register in the acceleration hardware engine.

4. The integrated circuit of claim 3, wherein: The first characteristic data includes at least one of a source media access control MAC address, a destination MAC address, a source Internet Protocol IP address, a destination IP address, a source port, a destination port, a protocol identifier, a packet size, or a maximum packet size; and The second characteristic data includes at least one of a flag or a count.

5. The integrated circuit of claim 3, wherein the ML detection system is configured to: receiving the first feature data and the second feature data from the hardware accelerated security service; determining whether the host device is under the DDOS attack using a regression model trained to predict whether the host device is under the DDOS attack based on the first feature data and the second feature data; as well as In response to determining that the host device is under the DDOS attack, the enforcement rule is sent to the hardware accelerated security service.

6. The integrated circuit of claim 1 , further comprising: A central processing unit (CPU) operably coupled to the host interface and the network interface; wherein the CPU and the accelerated hardware engine are used to host hardware accelerated security services, wherein: The hardware accelerated security service includes a first agent, wherein the first agent is used to: receiving mirrored network traffic data from the acceleration hardware engine; offloading the mirrored network traffic data using the acceleration hardware engine and filtering the mirrored network traffic data based on a predefined filter to obtain filtered network traffic; and Generate first feature data based on the filtered network traffic; and The hardware accelerated security service includes a second agent, wherein the second agent is used to: extracting telemetry data from registers of the acceleration hardware engine; generating second characteristic data according to the telemetry data; combining the first feature data and the second feature data into the plurality of features; and The plurality of features is sent to the ML detection system.

7. The integrated circuit of claim 1, wherein the integrated circuit is a data processing unit (DPU), wherein the DPU is a programmable data center infrastructure on a chip.

8. The integrated circuit of claim 2, wherein the host device resides in a first computing domain, wherein the hardware accelerated security service and the ML detection system reside in a second computing domain different from the first computing domain.

9. The integrated circuit of claim 2, wherein the host device resides in a first computing domain, wherein the hardware accelerated security service resides in a second computing domain different from the first computing domain, and wherein the ML detection system resides in a third computing domain different from the first computing domain and the second computing domain.

10. The integrated circuit of claim 1, wherein the ML detection system comprises a tree-based ML model trained to determine whether the host device is under the DDOS attack based on the plurality of features.

11. A computing system comprising: A data processing unit DPU, comprising a network interface, a host interface, a central processing unit CPU and an accelerated hardware engine, wherein the DPU is used to host a hardware accelerated security service to protect a host device from a distributed denial of service (DDOS) attack, wherein the hardware accelerated security service is used to extract a plurality of features from first data in network traffic data received on the network interface and second data stored in a register in the accelerated hardware engine; as well as Acceleration pipeline hardware is coupled to the DPU, wherein the acceleration pipeline hardware is used to: Using a machine learning (ML) detection system, determining whether the host device is under a DDOS attack based on the plurality of features; and In response to determining that the host device is under the DDOS attack, an enforcement rule is sent to the DPU.

12. The computing system of claim 11, wherein the DPU is a programmable data center infrastructure on a chip.

13. The computing system of claim 11, wherein the host device resides in a first computing domain, wherein the hardware accelerated security service resides in a second computing domain different from the first computing domain, and wherein the ML detection system resides in the second computing domain or in a third computing domain different from the first computing domain and the second computing domain.

14. The computing system of claim 11, wherein the hardware accelerated security service is used to: Extracting first characteristic data from the network traffic data; Extracting second feature data from the register in the acceleration hardware engine; combining the first feature data and the second feature data into the plurality of features; sending the plurality of features to the acceleration pipeline hardware to determine whether the host device is under the DDOS attack; In response to determining, by the acceleration pipeline hardware, that the host device is under the DDOS attack, receiving the enforcement rule from the acceleration pipeline hardware; as well as An action associated with the enforcement rule is performed on subsequent network traffic data directed to the host device.

15. The computing system of claim 11, wherein: The hardware accelerated security service includes a first agent, wherein the first agent is used to: receiving mirrored network traffic data from the acceleration hardware engine; offloading the mirrored network traffic data using the acceleration hardware engine and filtering the mirrored network traffic data based on a predefined filter to obtain filtered network traffic; as well as generating first characteristic data according to the filtered network traffic; The hardware accelerated security service includes a second agent, wherein the second agent is used to: extracting telemetry data from the registers of the acceleration hardware engine; generating second characteristic data according to the telemetry data; combining the first feature data and the second feature data into the plurality of features; and The plurality of features are sent to the acceleration pipeline hardware.

16. The computing system of claim 15, wherein: The first characteristic data includes at least one of a source media access control MAC address, a destination MAC address, a source Internet Protocol IP address, a destination IP address, a source port, a destination port, a protocol identifier, a packet size, or a maximum packet size; and The second characteristic data includes at least one of a flag or a count.

17. A method comprising: extracting, by a data processing unit (DPU) coupled to a host device, a plurality of features from first data in network traffic data received on a network interface of the DPU and second data stored in a register in an acceleration hardware engine of the DPU, wherein the first data is directed from a second device to the host device; Using a machine learning (ML) detection system, determining whether the host device is under a distributed denial of service (DDOS) attack based on the multiple features; as well as In response to determining that the host device is under the DDOS attack, the DPU performs an action associated with the enforcement rule on subsequent network traffic data directed from the second device to the host device.

18. The method according to claim 17, further comprising: Extracting first feature data from the network traffic data by the DPU; Extracting, by the DPU, second feature data from the register in the acceleration hardware engine; The DPU combines the first feature data and the second feature data into the plurality of features; sending, by the DPU, the plurality of features to acceleration pipeline hardware, wherein the ML detection system is hosted by the acceleration pipeline hardware; as well as In response to determining, by the acceleration pipeline hardware, that the host device is under the DDOS attack based on the plurality of features, the DPU receives the enforcement rule from the acceleration pipeline hardware.

19. The method of claim 18, wherein: Extracting the first feature data includes: receiving mirrored network traffic data from the acceleration hardware engine; offloading the mirrored network traffic data using the acceleration hardware engine and filtering the mirrored network traffic data based on a predefined filter to obtain filtered network traffic; and generating the first characteristic data according to the filtered network traffic; Extracting the second feature data includes: extracting telemetry data from the register of the acceleration hardware engine; The method further includes: generating the second characteristic data according to the telemetry data; combining the first feature data and the second feature data into the plurality of features; and The plurality of features are sent to the acceleration pipeline hardware.

20. The method of claim 18, wherein: The first characteristic data includes at least one of a source media access control MAC address, a destination MAC address, a source Internet Protocol IP address, a destination IP address, a source port, a destination port, a protocol identifier, a packet size, or a maximum packet size; and The second characteristic data includes at least one of a flag or a count.

Images