An FTTR-based adaptive firewall implementation method, device and equipment

Abstract

The application discloses an FTTR-based adaptive firewall implementation method, device and equipment, which comprises the following steps: a master gateway receives network data packets at a network card driver layer and filters the network data packets by using an XDP filtering rule set; if the network data packets are not successfully filtered out, the network data packets are sent to a Linux kernel for performing the following steps: extracting attack features based on configured attack feature extraction rules; determining whether an attack occurs based on configured attack behavior determination rules; if an attack occurs, discarding the network data packets, generating corresponding XDP filtering rules and delivering the XDP filtering rules; a child gateway receives the XDP filtering rules and loads the XDP filtering rules to the XDP filtering rule set at the network card driver layer; the network data packets are received at the network card driver layer, and the network data packets are filtered by using the XDP filtering rule set; if the network data packets are not successfully filtered out, the network data packets are sent to the master gateway. The Linux kernel firewall function is reformed by using XDP, so that a double-layer coordinated adaptive firewall can be realized, and the attack resistance capability can be greatly improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network security, and in particular to an FTTR-based adaptive firewall implementation method, device and equipment. BACKGROUND

[0002] With the continuous expansion of network attack scale, especially the Distributed Denial of Service (DDoS) attack and automated port scanning, a serious threat is posed to network infrastructure. In particular, in the FTTR (Fiber to The Remote) networking environment, a distributed network is usually composed of one master gateway and multiple sub-gateways. The master gateway is responsible for core routing and firewall functions, while the sub-gateway mainly provides access expansion and usually does not have complete firewall capabilities.

[0003] Most traditional firewalls are implemented based on the netfilter framework of the Linux kernel (such as iptables, nftables). The netfilter hook is located at a higher layer of the kernel network protocol stack, and can perform comprehensive analysis and complex rule matching on data packets, which is powerful and flexible. However, in the related art, the firewall function is centralized in the master gateway based on the netfilter framework of the Linux kernel, which has the following performance bottlenecks:

[0004] Each data packet needs to go through complete protocol stack processing in the master gateway, consuming a large amount of CPU resources; in the face of massive attack traffic, the firewall itself may become a performance bottleneck, and even collapse due to resource exhaustion. SUMMARY

[0005] The purpose of the present application is to provide an FTTR-based adaptive firewall implementation method, device and equipment, which solves the problem of large defense pressure of the existing master gateway and the lack of security capabilities of the sub-gateway.

[0006] In a first aspect, an FTTR-based adaptive firewall implementation method is provided, which is applied to a master gateway, and the method comprises:

[0007] A network data packet is received at the network card driver layer, and an XDP filtering rule set is used to filter the network data packet;

[0008] If the network data packet is not successfully filtered out, the network data packet is sent to the Linux kernel for execution:

[0009] Attack feature extraction rules are configured based on the attack feature extraction rules, and the network data packet is subjected to attack feature extraction;

[0010] determine whether an attack occurs according to the extracted attack features based on a configured attack behavior determination rule;

[0011] If an attack occurs, discard the network data packet and generate a corresponding XDP filtering rule and issue it.

[0012] In some possible embodiments, the generating a corresponding XDP filtering rule and issuing it comprises:

[0013] When it is determined that the network data packet comes from a master gateway, the generated XDP filtering rule is issued to the XDP filtering rule set;

[0014] When it is determined that the network data packet comes from a sub-gateway, the generated XDP filtering rule is issued to the sub-gateway.

[0015] In some possible embodiments, the attack feature extraction on the network data packet comprises at least one of the following steps:

[0016] According to the network data packet, the number of new connections of a single source IP in a unit of time is counted;

[0017] According to the network data packet, the number of SYN packets sent by a single source IP in a unit of time is counted;

[0018] According to the network data packet, whether a single source IP attempts to connect to multiple different destination ports in a set short time is detected;

[0019] According to the network data packet, traffic statistics are performed, and whether a current service traffic mutates is detected based on a historical traffic baseline.

[0020] In some possible embodiments, the generating a corresponding XDP filtering rule comprises:

[0021] Extracting feature metadata of the network data packet, the feature metadata comprising at least one of a source IP, a destination port, a protocol type, and an attack type label;

[0022] Generating an XDP filtering rule based on the feature metadata to filter a network data packet matching the feature metadata.

[0023] In some possible embodiments, the method further comprises:

[0024] Timing any newly added XDP filtering rule in the XDP filtering rule set;

[0025] When the XDP filtering rule successfully filters out a network data packet before the timing is timed out, the XDP rule is re-timed;

[0026] If the network packet is not successfully filtered out using the XDP filtering rule before the timing timeout, the XDP rule is deleted.

[0027] In some possible embodiments, the method further includes at least one of the following steps:

[0028] Merging multiple XDP filtering rules in the XDP filtering rule set that meet a merging rule;

[0029] De-duplicating multiple XDP filtering rules in the XDP filtering rule set that are duplicated;

[0030] Prioritizing multiple XDP filtering rules in the XDP filtering rule set according to a priority sorting rule.

[0031] In a second aspect, an embodiment of the present application provides an FTTR-based adaptive firewall implementation method, which is applied to a sub-gateway, and the method includes the following steps:

[0032] Receiving an XDP filtering rule issued by a main gateway and loading the XDP filtering rule into an XDP filtering rule set of a network card driver layer;

[0033] Filtering a network packet using the XDP filtering rule set when the network packet is received at the network card driver layer;

[0034] If the network packet is not successfully filtered out, sending the network packet to the main gateway.

[0035] In some possible embodiments, the method further includes the following steps:

[0036] Timing any newly added XDP filtering rule in the XDP filtering rule set;

[0037] If the network packet is successfully filtered out using the XDP filtering rule before the timing timeout, re-timing the XDP rule;

[0038] If the network packet is not successfully filtered out using the XDP filtering rule before the timing timeout, deleting the XDP rule.

[0039] In a third aspect, an embodiment of the present application provides an FTTR-based adaptive firewall implementation device, which serves as a main gateway, and the device includes the following components:

[0040] An XDP rule filtering module, configured to filter a network packet using an XDP filtering rule set when the network packet is received at a network card driver layer;

[0041] An XDP rule generation module, configured to send the network packet to a Linux kernel if the network packet is not successfully filtered out.

[0042] extract attack features from the network data packet based on a configured attack feature extraction rule;

[0043] determine whether an attack occurs according to the extracted attack features based on a configured attack behavior determination rule;

[0044] if the attack occurs, discard the network data packet, generate a corresponding XDP filtering rule, and deliver the XDP filtering rule.

[0045] In a fourth aspect, an FTTR-based adaptive firewall implementation device is provided, which serves as a sub-gateway, and includes:

[0046] an XDP rule loading module configured to receive an XDP filtering rule delivered by a main gateway and load the XDP filtering rule into an XDP filtering rule set of a network card driver layer;

[0047] an XDP rule filtering module configured to filter a network data packet received by the network card driver layer using the XDP filtering rule set;

[0048] a data packet sending module configured to send the network data packet to the main gateway if the network data packet is not successfully filtered out.

[0049] In a fifth aspect, another embodiment of the present application further provides an FTTR-based adaptive firewall implementation device, including at least one processor, and a memory connected with the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute any of the FTTR-based adaptive firewall implementation methods provided in the first aspect of the embodiments of the present application, or execute any of the FTTR-based adaptive firewall implementation methods provided in the second aspect of the embodiments of the present application.

[0050] In a sixth aspect, another embodiment of the present application further provides a computer storage medium storing a computer program, the computer program being configured to enable a computer to execute any of the FTTR-based adaptive firewall implementation methods provided in the first aspect of the embodiments of the present application, or execute any of the FTTR-based adaptive firewall implementation methods provided in the second aspect of the embodiments of the present application.

[0051] The FTTR-based adaptive firewall implementation method, device and equipment provided by the embodiments of the present application greatly improve the protection performance by XDP modification of the Linux kernel firewall function, and greatly improve the security of the FTTR network by realizing attack near-source filtering on the sub-gateway in cooperation with FTTR networking.

[0052] Other features and advantages of the present application will be set forth in the following description, and in part will be apparent from the description, or can be learned by practice of the application. The objects and other advantages of the present application will be realized and attained by the structure particularly pointed out in the written description and claims thereof as well as the appended drawings. BRIEF DESCRIPTION OF DRAWINGS

[0053] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed to be used in the embodiments of the present application will be briefly introduced as follows. Obviously, the drawings to be introduced below are only some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained from these drawings without any creative effort.

[0054] Figure 1 The flow chart of the FTTR-based adaptive firewall implementation method applied to the primary gateway provided by the embodiments of the present application is shown in FIG. 1.

[0055] Figure 2 The flow chart of the FTTR-based adaptive firewall implementation method applied to the secondary gateway provided by the embodiments of the present application is shown in FIG. 2.

[0056] Figure 3 The flow chart of the FTTR-based adaptive firewall implementation method in the embodiments 1 of the present application is shown in FIG. 3.

[0057] Figure 4 The flow chart of the FTTR-based adaptive firewall implementation method in the embodiments 2 of the present application is shown in FIG. 4.

[0058] Figure 5 The device structure diagram of the FTTR-based adaptive firewall implementation device as the primary gateway provided by the embodiments of the present application is shown in FIG. 5.

[0059] Figure 6 The device structure diagram of the FTTR-based adaptive firewall implementation device as the secondary gateway provided by the embodiments of the present application is shown in FIG. 6.

[0060] Figure 7 The device structure diagram of the FTTR-based adaptive firewall implementation device provided by the embodiments of the present application is shown in FIG. 7. DETAILED DESCRIPTION

[0061] To further illustrate the technical solutions provided by the embodiments of the present application, the following will describe in detail in combination with the drawings and specific embodiments. Although the embodiments of the present application provide the following method operation steps as shown in the embodiments or drawings, more or less operation steps can be included in the method based on conventional or non-creative labor. The execution order of the steps is not limited to the execution order provided by the embodiments of the present application in logical terms. The method can be executed in sequence or in parallel when the method is executed in actual processing or by a control device according to the method sequence shown in the embodiments or drawings.

[0062] The eXpress Data Path (XDP) technology allows users to attach custom programs (eBPF (Extended Berkeley Packet Filter) bytecode) to the network card driver layer to process before the packet is assigned a sk_buff structure. This enables XDP to discard or forward packets at extremely high speeds, making it very suitable for fast filtering of attack traffic.

[0063] However, the current application of XDP has the following challenges:

[0064] Limited rule complexity: XDP programs run in a limited virtual machine and cannot access complete kernel data structures, so it is difficult to implement complex connection tracking (conntrack) and multi-layer conditional matching like the netfilter framework;

[0065] Policy rigidity: XDP filtering rules are usually statically or manually configured, lacking the ability to dynamically adapt to real-time traffic characteristics.

[0066] Therefore, the embodiments of the present application provide a solution that can combine the deep analysis capabilities of netfilter and the high-speed processing capabilities of XDP, and achieve intelligent and adaptive collaboration between the two.

[0067] Other features and advantages of the present application will be set forth in the following description, and in part will become apparent to those skilled in the art from the description, or can be learned by practice of the present application. The objects and other advantages of the present application can be realized and obtained by the structure particularly pointed out in the written description, claims, and drawings.

[0068] The search method of the monitoring node in the embodiments of the present application will be described in detail below in combination with the drawings.

[0069] As Figure 1 shown, the method provided by the embodiments of the present application for implementing an adaptive firewall based on FTTR is applied to a main gateway, and the method comprises:

[0070] Step 101, receiving a network data packet at the network card driver layer, filtering the network data packet by using an XDP filtering rule set;

[0071] After the master gateway receives the network data packet at the network card driver layer, the network data packet is first filtered by using an XDP filtering rule set. The XDP filtering rule set is initially empty and is issued by the Linux kernel as the network data packet is received. In the embodiment of the application, the XDP filtering rule issued by the Linux kernel is attached to the network card driver layer by a self-defined program (eBPF bytecode).

[0072] Step 102, if the network data packet is not successfully filtered out, the network data packet is sent to the Linux kernel for subsequent steps;

[0073] The XDP filtering rule set is empty and does not filter any network data packet. The network data packet is processed layer by layer to reach the Linux kernel. When the XDP filtering rule set includes at least one XDP filtering rule, the received network data packet is filtered by using each XDP filtering rule. The XDP filtering rule includes a filtering condition. For the network data packet that meets the filtering condition, the network data packet is discarded at the network card driver layer and will not enter the Linux kernel for processing. If the network data packet does not meet all the filtering conditions, the network data packet is sent to the Linux kernel for processing.

[0074] Step 103, extracting attack features from the network data packet based on the configured attack feature extraction rule;

[0075] In the embodiment of the application, the Linux kernel implements a firewall function based on the netfilter layer. The firewall function includes extracting attack features from the network data packet based on the configured attack feature extraction rule and identifying whether an attack occurs according to the extracted attack features. The specific attack features can be defined according to different attack types, which are not limited in the embodiment of the application.

[0076] Step 104, determining whether an attack occurs according to the extracted attack features based on the configured attack behavior determination rule;

[0077] In the embodiment of the application, the Linux kernel implements a firewall function based on the netfilter layer. The firewall function includes determining whether an attack occurs according to the extracted attack features based on the configured attack behavior determination rule. The specific determination rule can be defined according to different attack types, such as pre-setting attack features corresponding to different attack types and setting that when the attack features are met, the attack of the corresponding type is considered to occur.

[0078] Step 105, if an attack occurs, discarding the network data packet and generating and issuing a corresponding XDP filtering rule.

[0079] In the Linux kernel, if an attack is detected based on the firewall function, the network packet is discarded, and an XDP filtering rule is generated and issued according to the characteristics of the network packet, where the issuing refers to issuing to the XDP layer, that is, the network card driver layer.

[0080] The embodiment of the application constructs a software system composed of a control plane, a data plane and an adaptive engine. The control plane uses the existing mature netfilter for deep network packet detection and attack feature analysis; the data plane uses the XDP technology for high-performance filtering; the adaptive engine acts as the "brain" and analyzes the attack features captured by the netfilter layer in real time, dynamically optimizes and generates XDP rules and issues them to the XDP layer, so as to realize the closed loop from "accurate but slow" detection to "fast and accurate" filtering.

[0081] In the related art, the firewall function based on the netfilter framework of the Linux kernel is concentrated in the main gateway, and the following technical defects exist:

[0082] Uneven security capability: the sub-gateway lacks effective security protection, and when the device accessed under the sub-gateway is infected to become an attack source, the attack traffic will penetrate the sub-gateway and directly reach the main gateway, consuming the processing resources of the main gateway;

[0083] Single-point defense pressure: all security detection and filtering are concentrated in the main gateway, forming a single-point performance bottleneck;

[0084] Internal attack spread: attacks from the internal of the home network (such as DDoS initiated by IoT (Internet of Things) devices controlled) cannot be contained at the source, affecting the performance of the entire FTTR network.

[0085] In some possible embodiments, the generating the corresponding XDP filtering rule and issuing, comprises:

[0086] When it is determined that the network packet comes from the main gateway, the generated XDP filtering rule is issued to the XDP filtering rule set;

[0087] When it is determined that the network packet comes from the sub-gateway, the generated XDP filtering rule is issued to the sub-gateway.

[0088] For the master gateway, the master gateway can determine that the network data packet is from the master gateway or a certain sub-gateway by analyzing the input port or VLAN label of the network data packet, and record the mapping relationship between the attack source IP and the corresponding sub-gateway. In this way, when generating the XDP filtering rule, if the network data packet is from the master gateway, the network data packet is sent to the local XDP layer and loaded into the local XDP filtering rule set. In this way, if it is a WAN port direction external attack, the XDP filtering rule is applied to the master gateway, and XDP filtering is realized when the network card receives the packet, realizing efficient packet loss processing.

[0089] If the network data packet is from a certain sub-gateway, the cross-gateway rule distribution process is started, the XDP rule is sent to the XDP layer of the corresponding sub-gateway, and the corresponding sub-gateway loads it into the local XDP filtering rule set. In this way, if it is an internal attack from the sub-gateway, the XDP filtering rule is sent to the corresponding sub-gateway, and the corresponding sub-gateway realizes XDP filtering when the network card receives the packet, realizing efficient packet loss processing near the source.

[0090] The embodiment of the application also provides an adaptive firewall implementation method based on FTTR, which is applied to a sub-gateway, as shown in the following figure. Figure 2 The method comprises the following steps,

[0091] Step 201, receiving the XDP filtering rule sent by the master gateway and loading it into the XDP filtering rule set of the network card driver layer;

[0092] Specifically, the XDP filtering rule sent by the master gateway can be attached to the XDP filtering rule set of the network card driver layer by using a custom program (eBPF bytecode).

[0093] Step 202, receiving the network data packet at the network card driver layer, and filtering the network data packet by using the XDP filtering rule set;

[0094] It should be noted that the execution of steps 201 and 202 has no sequence limitation, if the master gateway sends the XDP filtering rule, step 201 is triggered, if the network data packet is received, step 202 is triggered, and if the master gateway does not send the XDP rule initially, the XDP filtering rule set is empty when step 202 is executed, and no network data packet is filtered.

[0095] Step 203, if the network data packet is not successfully filtered out, the network data packet is sent to the master gateway.

[0096] The embodiment of the application constructs a master-slave gateway cooperative defense system under the FTTR architecture. The master gateway not only realizes double-layer cooperation of Netfilter and XDP locally, but also serves as a security control center. When detecting that an attack originates from a certain slave gateway, the generated XDP filtering rule is dynamically pushed to the slave gateway, so as to realize near-domain filtering of the attack at the source end, and solve the problems of lack of security capability of the slave gateway and single-point defense pressure of the master gateway.

[0097] In some possible embodiments, attack feature extraction is performed on the network packet, including at least one of the following steps:

[0098] According to the network packet, the number of new connections of a single source IP in a unit of time is counted. The network packet carries information such as a source IP and a packet type, so the attack feature can be extracted. The corresponding attack behavior judgment rule can be that if the number of new connections of a certain source IP in a unit of time exceeds a set connection number threshold, it is considered that the source IP attacks.

[0099] According to the network packet, the number of SYN packets sent by a single source IP in a unit of time is counted. The network packet carries information such as a source IP and a packet type, so the attack feature can be extracted. The corresponding attack behavior judgment rule can be that if the number of SYN packets sent by a certain source IP in a unit of time exceeds a set number, it is considered that the source IP attacks.

[0100] According to the network packet, whether a single source IP attempts to connect to multiple different destination ports in a set short time is detected. The network packet carries information such as a source IP and an access port, so the attack feature can be extracted. The corresponding attack behavior judgment rule can be that if a certain source IP attempts to connect to multiple different destination ports in a set short time, it is considered that the source IP attacks.

[0101] According to the network packet, traffic statistics are performed. Based on a historical traffic baseline, whether current business traffic mutates is detected. The corresponding attack behavior judgment rule can be that if it is detected that the traffic of a certain business mutates, it is considered that the business has an attack behavior.

[0102] The above is only a possible attack feature and a possible implementation mode of judging an attack behavior. In specific implementation, the attack behavior can be defined according to the type of the attack behavior.

[0103] In some possible embodiments, the corresponding XDP filtering rule is generated, including:

[0104] Feature metadata of the network packet is extracted, and the feature metadata includes at least one of a source IP, a target port, a protocol type, and an attack type label.

[0105] generating an XDP filtering rule based on the feature metadata to filter network packets matching the feature metadata.

[0106] In generating the XDP filtering rule, a filtering condition can be generated according to at least one of the feature metadata, and the filtering condition is matched with the network packets to filter the network packets matching the feature metadata.

[0107] In some possible embodiments, the XDP filtering rule of the XDP filtering rule set in the main gateway or the sub-gateway in the application has a timeout mechanism, and the timeout strategy is dynamically adjusted by judging whether the attack is continuous and the timeout time itself. For the main gateway or the sub-gateway, the method further includes:

[0108] Timing any newly added XDP filtering rule in the XDP filtering rule set;

[0109] When the network packets are successfully filtered by the XDP filtering rule before the timing is timed out, the XDP rule is re-timed;

[0110] When the network packets are not successfully filtered by the XDP filtering rule before the timing is timed out, the XDP rule is deleted.

[0111] In some possible embodiments, the method further includes at least one of the following steps:

[0112] Merging multiple XDP filtering rules in the XDP filtering rule set that meet a merging rule, such as merging XDP filtering rules of source IPs belonging to the same network segment;

[0113] De-duplicating multiple XDP filtering rules in the XDP filtering rule set that are repeated;

[0114] Prioritizing multiple XDP filtering rules in the XDP filtering rule set according to a priority sorting rule. The priority can be defined according to requirements, and embodiments of the application are not limited.

[0115] The application embodiment provides a dual-layer coordinated adaptive distributed firewall based on FTTR. The Linux kernel netfilter firewall is reformed by XDP, the protection performance is greatly improved, and the attack can be filtered near the source on the sub-gateway by cooperating with the FTTR networking, so that the security of the FTTR network is greatly improved. The XDP filtering rule of the XDP filtering rule set has a timeout mechanism, and the timeout strategy is dynamically adjusted by judging whether the attack is continuous and the timeout time itself.

[0116] The adaptive firewall implementation method based on FTTR provided by the application embodiment has the following beneficial effects:

[0117] Distributed defense: Extend the protection capability to the network edge (sub-gateway), realize the security concept of "attack at the source", significantly reduce the processing pressure of the main gateway;

[0118] Bandwidth protection: malicious traffic is discarded at the sub-gateway, avoiding the occupation of valuable uplink fiber bandwidth, and ensuring the network quality of other normal services;

[0119] Architecture optimization: Make full use of the FTTR management channel for security cooperation, without additional hardware costs, and realize the deep integration of network and security;

[0120] Sub-gateway lightness: The sub-gateway does not need complex detection logic, only needs to execute simple and efficient XDP filtering rules issued by the main gateway, which meets the design reality of limited resources of the FTTR sub-gateway.

[0121] The following gives a possible specific implementation of the adaptive firewall implementation method based on FTTR provided by the present application.

[0122] Embodiment 1

[0123] The main gateway of the present application realizes the firewall function in the Linux kernel using the netfilter layer, analyzes the attack characteristics of the network packet, generates the XDP rule and issues it to the local XDP layer, as shown in Figure 3 , mainly includes the following stages:

[0124] Stage 1, attack detection and rule issuing;

[0125] Step 1, the attack source sends the network packet corresponding to the attack traffic to the XDP layer of the main gateway;

[0126] Step 2, the XDP layer of the main gateway is initially empty, that is, there is no filtering rule at the initial time, and the XDP layer sends the network packet to the netfilter layer of the Linux kernel;

[0127] Step 3, the netfilter layer performs deep detection analysis on the network packet, and when the netfilter layer determines that a certain source IP or a specific traffic mode is an attack, not only performs actions such as discarding the network packet, but also extracts the feature metadata (such as source IP, target port, protocol type, attack type label) of the attack from the network packet;

[0128] Specifically, network packets can be captured through a hook function of netfilter (such as NF_INET_PRE_ROUTING); a set of XDP filtering rule generation mechanisms based on netfilter for detecting DDoS and port scanning are run, and the XDP filtering rule generation mechanism can perform attack feature extraction based on the following manners: the number of new connections or the number of SYN packets sent by a single source IP within a unit of time can be counted as attack features; connection attempts of a single source IP to multiple different destination ports within a short period of time can be detected; and based on a historical traffic baseline, mutations in current service traffic can be detected.

[0129] Step 4: The netfilter layer reports the extracted attack features to the adaptive engine in the user space;

[0130] Step 5: The adaptive engine receives the feature metadata from the netfilter layer, generates and issues XDP filtering rules to the XDP layer of the main gateway by using a rule generator according to the feature metadata, wherein the XDP filtering rules include a last hit time last_hit timestamp.

[0131] When generating corresponding XDP filtering rules, the XDP filtering rules can be generated according to a predetermined logic based on a pre-set connection frequency threshold, a port scanning mode, a traffic anomaly model, and the like, and specific examples of the generated XDP filtering rules are as follows:

[0132] For a DDoS attack source IP, a rule of if (src_ip == malicious IP) then DROP is generated;

[0133] For port scanning, a rule of if (src_ip == scanner IP && tcp_flags == SYN) then DROP is generated;

[0134] After the XDP filtering rules are generated by using the rule generator, the rules can be merged, de-redundant, simplified, and prioritized by using a rule optimizer, so as to reduce the number of judgments in the XDP program and improve performance. For example, multiple discrete malicious IPs can be merged into a CIDR network segment, or a BPF map (such as a hash map) supported by XDP can be used to store a blacklist.

[0135] Phase 2: XDP filtering rule takes effect and self-updates;

[0136] During the attack duration, the following steps are cyclically executed:

[0137] Step 6: The attack source continuously sends network packets corresponding to attack traffic to the XDP layer of the main gateway;

[0138] Step 7, the XDP layer uses XDP filtering rules to filter network packets, and performs XDP_DROP on network packets that meet the filtering conditions;

[0139] Step 8, after successfully filtering out the network packet using the XDP filtering rule, update the last_hit timestamp of the XDP filtering rule, so that the last_hit timestamp is continuously refreshed, and the XDP filtering rule remains active.

[0140] When the XDP filtering rule is effective, most of the attack traffic is discarded at the network card driver layer, and no longer consumes kernel protocol stack resources. At this time, the traffic from the attack source detected by the netfilter layer will be sharply reduced, forming a negative feedback. The adaptive engine will monitor this negative feedback.

[0141] XDP filtering rule remains active: when there is an attack packet matching, the rule automatically updates the last_hit timestamp to maintain the validity of the rule.

[0142] Phase 3, attack stop and rule self-cleaning;

[0143] Step 9, when the attack stops and the attack source no longer sends attack network packets, and as the XDP filtering rule timeout countdown begins, when the XDP filtering rule is not matched by any packet within the set timeout time (such as 30 minutes), that is, the last_hit timestamp exceeds the set timeout time and is not updated, the XDP program automatically removes it from the rule table, thereby realizing automatic cleaning of idle XDP filtering rules.

[0144] Step 10, the attack source sends normal network packets;

[0145] Step 11, the XDP layer of the main gateway does not find a matching XDP filtering rule;

[0146] Step 12, the XDP layer of the main gateway sends normal network packets to the netfilter layer;

[0147] Step 13, the netfilter layer of the main gateway normally processes the normal network packets;

[0148] Step 14, the XDP layer periodically checks the active state of the XDP filtering rule;

[0149] Step 15, detect that the XDP filtering rule has not been matched for a long time, specifically, detect that the XDP filtering rule has timed out (no match for 30 minutes), automatically delete the XDP filtering rule, thereby realizing resource release and state cleaning.

[0150] Phase 4, state recovery;

[0151] Step 16, the attack source sends the network packet of the attack again after the attack is recovered;

[0152] Step 17, the XDP layer of the master gateway is cleaned up due to the XDP filtering rule, and thus the network packet is transmitted to the netfilter layer;

[0153] Step 18, the netfilter layer re-detects the attack and reports to the adaptive engine;

[0154] Step 19, the adaptive engine re-issues the XDP filtering rule with a last_hit timestamp, so that a new protection closed loop automatic life cycle management is realized.

[0155] Through the above method provided by the embodiment of the application, after the XDP filtering rule is issued and takes effect, most of the attack traffic is discarded at the network card driver layer, and no longer consumes the kernel protocol stack resources.

[0156] Embodiment 2

[0157] The adaptive firewall implementation method based on FTTR provided by the embodiment of the application under the FTTR architecture can construct a master-slave gateway cooperative defense system, and the specific steps are as shown in Figure 4 , mainly including:

[0158] Phase 1, attack traffic detection

[0159] Step 1, the malicious device sends the network packet corresponding to the attack traffic to the slave gateway;

[0160] Step 2, the slave gateway forwards the network packet to the master gateway;

[0161] Step 3, the master gateway sends the network packet to the Netfilter layer after performing protocol stack processing on the network packet;

[0162] Step 4, the Netfilter layer of the master gateway performs deep analysis and attack detection on the network packet, and identifies malicious behaviors such as DDoS attack and port scanning;

[0163] Step 5, when the netfilter layer of the master gateway detects the attack, the source of the network packet is determined to be the slave gateway 5, specifically by analyzing the input network port or VLAN label of the packet to determine the source of the attack traffic from which slave gateway, and recording the mapping relationship between the attack source IP and the corresponding slave gateway;

[0164] Step 6, the netfilter layer of the master gateway reports the attack characteristics to the adaptive engine, wherein the attack characteristics can include {IP_X, slave gateway 5, attack type};

[0165] Phase 2, rule generation and distribution

[0166] Step 7, the adaptive engine of the main gateway generates XDP filtering rules {IP_X, DROP, timeout=1800} based on the reported attack features, which discards network packets with source IP address IP_X, and the timeout of the rule is 30 minutes;

[0167] Step 8, if the attack source is located in the main gateway direct network, the rule is issued under the local XDP layer, if the attack source is located in a certain sub-gateway, the XDP filtering rule is requested to be distributed to the sub-gateway 5 by the cross-gateway distributor;

[0168] Step 9, the cross-gateway distributor sends the XDP filtering rule to the target sub-gateway through the FTTR management channel;

[0169] Step 10, after the sub-gateway receives the XDP filtering rule, it verifies and loads the XDP filtering rule to the XDP filtering rule set through the lightweight XDP rule executor, so that the XDP filtering rule takes effect;

[0170] The XDP rule executor of the sub-gateway is a simplified eBPF program, which mainly maintains a blacklist / rule set issued by the main gateway, and filters the traffic flowing out of the sub-gateway to the main gateway.

[0171] Step 11, the sub-gateway returns a successful loading confirmation to the cross-gateway distributor;

[0172] Step 12, the cross-gateway distributor notifies the adaptive engine that the XDP filtering rule distribution is completed;

[0173] Phase 3, near-source filtering takes effect

[0174] Step 13, the malicious device continues to send network packets corresponding to the attack traffic to the sub-gateway;

[0175] Step 14, the sub-gateway matches the network packets using the XDP filtering rule, and executes the discard DROP after a successful match, so that the attack traffic is intercepted at the source and no longer consumes upstream bandwidth;

[0176] Phase 4, state monitoring and maintenance

[0177] Step 15, the attack traffic is discarded by the XDP program at the network card driver layer of the sub-gateway and cannot reach the main gateway, the main gateway monitors the attack traffic changes and detects that the corresponding attack traffic from the sub-gateway IP_X is reduced, forming an effective negative feedback.

[0178] Step 16, the sub-gateway manages the life cycle of the XDP rule filtering set, specifically timing a certain XDP filtering rule;

[0179] Step 17, if no network packet is matched for more than 30 minutes, it is considered that the XDP filtering rule is timed out, and the XDP filtering rule is automatically cleaned up after being timed out, and if a network packet is successfully matched, the XDP filtering rule is re-timed.

[0180] Optionally, the sub-gateway can report the cleaning state of the XDP filtering rule to the cross-gateway distributor.

[0181] Based on the same inventive concept, the present application also provides an FTTR-based adaptive firewall implementation device, which serves as a master gateway, as shown in Figure 5 The device comprises:

[0182] An XDP rule filtering module 501 is configured to filter a network packet received at a network card driver layer by using an XDP filtering rule set.

[0183] An XDP rule generation module 502 is configured to send the network packet to a Linux kernel for execution if the network packet is not successfully filtered out.

[0184] Attack feature extraction is performed on the network packet based on a configured attack feature extraction rule.

[0185] Attack behavior judgment is performed based on a configured attack behavior judgment rule according to the extracted attack features.

[0186] If an attack occurs, the network packet is discarded, and a corresponding XDP filtering rule is generated and distributed.

[0187] Based on the same inventive concept, the present application also provides an FTTR-based adaptive firewall implementation device, which serves as a sub-gateway, as shown in Figure 6 The device comprises:

[0188] An XDP rule loading module 601 is configured to receive an XDP filtering rule distributed by a master gateway and load the XDP filtering rule into an XDP filtering rule set at a network card driver layer.

[0189] An XDP rule filtering module 602 is configured to filter a network packet received at a network card driver layer by using the XDP filtering rule set.

[0190] A packet sending module 603 is configured to send the network packet to the master gateway if the network packet is not successfully filtered out.

[0191] After introducing the FTTR-based adaptive firewall implementation method and device of the exemplary embodiments of the present application, next, an FTTR-based adaptive firewall implementation device according to another exemplary embodiment of the present application is introduced.

[0192] Those skilled in the art can understand that various aspects of the present application can be implemented as a system, a method or a program product. Therefore, various aspects of the present application can be embodied in a form of a complete hardware, a complete software (including firmware, microcode, etc.), or a combination of hardware and software aspects, which can be collectively referred to as "circuitry", "module" or "system".

[0193] In some possible implementation, the FTTR-based adaptive firewall implementation device according to the present application can at least include at least one processor and at least one memory. Wherein the memory stores program codes, when the program codes are executed by the processor, the processor executes the steps in the FTTR-based adaptive firewall implementation method applied to the master gateway according to various exemplary embodiments of the present application described above in the specification, or executes the steps in the FTTR-based adaptive firewall implementation method applied to the slave gateway according to various exemplary embodiments of the present application described above in the specification.

[0194] The FTTR-based adaptive firewall implementation device 170 according to this embodiment of the present application will be described below with reference to Figure 7 Figure 7 The FTTR-based adaptive firewall implementation device 170 shown is only an example, and should not bring any limitation to the function and use range of the embodiments of the present application.

[0195] As shown in Figure 7 , the FTTR-based adaptive firewall implementation device 170 is in the form of a general electronic device. The components of the FTTR-based adaptive firewall implementation device 170 can include but not limited to the above-mentioned at least one processor 171, the above-mentioned at least one memory 172, the bus 173 connecting different system components (including the memory 172 and the processor 171).

[0196] The bus 173 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a processor or a local bus using any of a variety of bus structures.

[0197] The memory 172 can include a readable medium in the form of a volatile memory, such as a random access memory (RAM) 1721 and / or a cache memory 1722, and can further include a read-only memory (ROM) 1723.

[0198] ​The memory 172 can also include a program / utility 1725 having a set of programs / modules 1724, including an operating system, one or more application programs, other programs, and programmatic data, each of which can implement aspects of a network environment, alone, or in combination. The programs 1724 can include programs for implementing the FTTR-based adaptive firewall implementation methods described herein.

[0199] The FTTR-based adaptive firewall implementation device 170 can also communicate with one or more external devices 174 such as a keyboard, a pointing device, etc.; and can communicate with one or more devices that enable a user to interact with the FTTR-based adaptive firewall implementation device 170, and / or any devices (e.g., a router, a modem, a peer device or other computing device) that enable the FTTR-based adaptive firewall implementation device 170 to communicate with one or more other computing devices. Such communication can occur via Input / Output (I / O) interface(s) 175. Still yet, the FTTR-based adaptive firewall implementation device 170 can communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet) via network adapter 176. As depicted, the network adapter 176 communicates with the other components of the FTTR-based adaptive firewall implementation device 170 via bus 173. It should be understood that although not shown, other hardware and / or software components could be used in conjunction with the FTTR-based adaptive firewall implementation device 170. These include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

[0200] In some possible embodiments, various aspects of the FTTR-based adaptive firewall implementation method provided by the present application can also be implemented as a program product, including a program of instructions 1724 for execution by a computer device 170, the program of instructions 1724 designed to cause the computer device 170 to perform the steps of the FTTR-based adaptive firewall implementation method according to various example embodiments of the present application described above in the specification.

[0201] The program product of the embodiments of the present application for the implementation of the adaptive firewall based on FTTR can employ a portable compact disc read-only memory (CD-ROM) and include program codes, and can run on an electronic device. However, the program product of the present application is not limited thereto, and in the present document, the readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device or apparatus.

[0202] The program product of the embodiments of the present application for the implementation of the adaptive firewall based on FTTR can employ a portable compact disc read-only memory (CD-ROM) and include program codes, and can run on an electronic device. However, the program product of the present application is not limited thereto, and in the present document, the readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device or apparatus.

[0203] The readable signal medium can include a data signal carried in a baseband or as part of a carrier wave, in which the readable program codes are carried. Such a propagated data signal can take any of a variety of forms, including but not limited to electro-magnetic, optical, or any suitable combination thereof. The readable signal medium can also be any readable medium that is not a readable storage medium and that can be used to carry or store program codes for use by or in connection with an instruction execution system, apparatus or device.

[0204] The program codes contained in the readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, optical cable, RF, or the like, or any suitable combination thereof.

[0205] The program codes for performing the operations of the present application can be written in any combination of one or more programming languages, including an object-oriented programming language such as Java, C++, or the like, and a conventional procedural programming language such as the "C" language or the like. The program codes can be executed entirely on the user electronic device, partially on the user device, as an independent software package, partially on the user electronic device and partially on a remote electronic device, or entirely on a remote electronic device or server. In the case involving a remote electronic device, the remote electronic device can be connected to the user electronic device through any kind of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external electronic device (for example, through the Internet by using an Internet service provider).

[0206] It should be noted that while several units or sub-units of the apparatus are mentioned in the above detailed description, such a division is merely exemplary and not mandatory. Indeed, according to an embodiment of the application, the features and functionalities of two or more units described above can be embodied in one unit. Conversely, the features and functionalities of one unit described above can be further divided into units embodied by several units.

[0207] Moreover, while operations of the methods of the present application are described in a particular order in the figures, this is not required or implied in any manner, nor is it required that all of the operations be performed to achieve desirable results. Additionally or alternatively, certain steps can be omitted, combined into a single step, and / or separated into multiple steps.

[0208] Those skilled in the art will appreciate that embodiments of the present application can be readily used as a method, a system, or a computer program product. Accordingly, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, and the like) embodying computer readable program code.

[0209] The present application is described herein with reference to the flowchart and block diagram illustrations of the methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each block of the flowchart and block diagrams, and combinations of blocks in the flowchart and block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processing system or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart and block diagram block or blocks. Figure 1 The flowchart and block diagram illustrations support combinations of means for implementing the functions Figure 1 combinations of means for implementing the functions specified in the flowchart and block diagram block or blocks.

[0210] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart and block diagram block or blocks. Figure 1 The flowchart and block diagram illustrations support combinations of means for implementing the functions Figure 1 combinations of means for implementing the functions specified in the flowchart and block diagram block or blocks.

[0211] These computer program instructions can also be loaded into a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 Figure 1

[0212] Although preferred embodiments of the application have been described herein, it will be apparent to those skilled in the art that various modifications can be made within the scope of the application without departing from the spirit of the application. Accordingly, it is intended that all such possible modifications be included within the scope of the application as described in the following claims. In the claims, means-plus-function clauses are used where function-words have been omitted for purposes of clarity. It will be understood that such function-words have been omitted in order to declare the claim in its broadest form. It will be appreciated that an apparatus, system, or device described as including a particular implemented function can be implemented as any other apparatus, system, or device that includes functionally equivalent specificity.

[0213] Obviously, numerous modifications and variations of the present application are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims and their equivalents, the application can be practiced otherwise than as specifically described.​​

Claims

1. A method for implementing an adaptive firewall based on FTTR, the method is applied to a master gateway, and the method comprises the steps of: The method comprises: receiving a network packet at a network card driver layer, and filtering the network packet by using an XDP filtering rule set; if the network packet is not successfully filtered out, sending the network packet to a Linux kernel for execution; extracting attack features from the network packet based on configured attack feature extraction rules; determining whether an attack occurs based on the extracted attack features according to configured attack behavior determination rules; if an attack occurs, discarding the network packet and generating corresponding XDP filtering rules; when it is determined that the network packet comes from a sub-gateway, issuing the generated XDP filtering rules to the sub-gateway, so that the sub-gateway receives the XDP filtering rules issued by the main gateway and loads the XDP filtering rules into the XDP filtering rule set of the network card driver layer of the sub-gateway; receiving a network packet at the network card driver layer of the sub-gateway, and filtering the network packet by using the XDP filtering rule set of the sub-gateway; if the network packet is not successfully filtered out, sending the network packet to the main gateway.

2. The method of claim 1, wherein, Further comprising: when it is determined that the network packet comes from the main gateway, issuing the generated XDP filtering rules to the XDP filtering rule set of the main gateway.

3. The method of claim 1, wherein, The attack feature extraction from the network packet comprises at least one of the following steps: counting the number of new connections of a single source IP within a unit of time according to the network packet; counting the number of SYN packets sent by a single source IP within a unit of time according to the network packet; detecting whether a single source IP attempts to connect to multiple different destination ports within a set short time according to the network packet; detecting whether a current traffic mutates based on a historical traffic baseline according to the network packet.

4. The method of claim 1, wherein, The generation of the corresponding XDP filtering rules comprises: extracting feature metadata of the network packet, the feature metadata comprising at least one of a source IP, a destination port, a protocol type, and an attack type label; generating XDP filtering rules based on the feature metadata to filter network packets matching the feature metadata.

5. The method according to any one of claims 1 to 4, characterized in that, Further comprising: timing any newly added XDP filtering rule in the XDP filtering rule set; re-timing the XDP filtering rule when the network packet is successfully filtered out by using the XDP filtering rule before the timing expires; deleting the XDP filtering rule when the network packet is not successfully filtered out by using the XDP filtering rule before the timing expires.

6. The method according to any one of claims 1 to 4, characterized in that, Further comprising at least one of the following steps: merging multiple XDP filtering rules in the XDP filtering rule set that meet merging rules; de-duplicating multiple XDP filtering rules in the XDP filtering rule set that are repeated; prioritizing multiple XDP filtering rules in the XDP filtering rule set according to a priority sorting rule.

7. An FTTR-based adaptive firewall implementation method, applied to a sub-gateway, characterized in that, The method comprises, receiving XDP filtering rules issued by a main gateway and loading the XDP filtering rules into an XDP filtering rule set of a network card driver layer; receiving a network packet at the network card driver layer, and filtering the network packet by using the XDP filtering rule set; if the network packet is not successfully filtered out, sending the network packet to the main gateway; The XDP filtering rule is generated by the master gateway, wherein the master gateway receives a network packet at a network card driver layer, filters the network packet by using an XDP filtering rule set of the master gateway, and if the network packet is not successfully filtered, sends the network packet to a Linux kernel to perform attack feature extraction on the network packet based on a configured attack feature extraction rule; determines whether an attack occurs based on the extracted attack feature based on a configured attack behavior determination rule; if the attack occurs, discards the network packet and generates a corresponding XDP filtering rule, and determines that the network packet received at the network card driver layer comes from a sub-gateway, and then distributes the generated XDP filtering rule to the sub-gateway.

8. The method of claim 7, wherein, Further comprising: timing any newly added XDP filtering rule in the XDP filtering rule set; re-timing the XDP filtering rule if the network packet is successfully filtered by using the XDP filtering rule before the timing is timed out; deleting the XDP filtering rule if the network packet is not successfully filtered by using the XDP filtering rule before the timing is timed out.

9. An FTTR-based adaptive firewall implementation device, which serves as a master gateway, characterized in that, The device comprises: an XDP rule filtering module configured to filter a network packet received at a network card driver layer by using an XDP filtering rule set; an XDP rule generation module configured to, if the network packet is not successfully filtered, send the network packet to a Linux kernel to perform attack feature extraction on the network packet based on a configured attack feature extraction rule; determine whether an attack occurs based on the extracted attack feature based on a configured attack behavior determination rule; if the attack occurs, discard the network packet and generate a corresponding XDP filtering rule; if the network packet comes from a sub-gateway, distribute the generated XDP filtering rule to the sub-gateway, so that the sub-gateway receives the XDP filtering rule distributed by the master gateway and loads the XDP filtering rule into an XDP filtering rule set of a network card driver layer of the sub-gateway, filters a network packet received at the network card driver layer of the sub-gateway by using the XDP filtering rule set of the sub-gateway, and if the network packet is not successfully filtered, sends the network packet to the master gateway. The device comprises:

10. An FTTR-based adaptive firewall implementation device, which serves as a sub-gateway, characterized in that, an XDP rule loading module configured to receive an XDP filtering rule distributed by a master gateway and load the XDP filtering rule into an XDP filtering rule set of a network card driver layer; an XDP rule filtering module configured to filter a network packet received at the network card driver layer by using the XDP filtering rule set; a packet sending module configured to, if the network packet is not successfully filtered, send the network packet to the master gateway; ​ The XDP filtering rule is generated by a master gateway, wherein the master gateway receives a network packet at a network card driver layer, filters the network packet by using an XDP filtering rule set of the master gateway, and sends the network packet to a Linux kernel for performing attack feature extraction on the network packet based on a configured attack feature extraction rule, determining whether an attack occurs based on a configured attack behavior determination rule according to the extracted attack feature, discarding the network packet and generating a corresponding XDP filtering rule if the attack occurs, and determining that the network packet received at the network card driver layer is from a slave gateway and then issuing the generated XDP filtering rule to the slave gateway.

11. An FTTR based adaptive firewall implementation device, characterized by, The computer storage medium stores a computer program for causing a computer to execute the method of any one of claims 1-6 or the method of any one of claims 7-8.

12. A computer storage medium, characterized in that The computer storage medium stores a computer program for causing a computer to execute the method of any one of claims 1-6 or the method of any one of claims 7-8.

Images