Attack protection method and device
By introducing a matching mechanism for anti-attack table entries and tunnel table entries in the GRE P2MP tunnel, combined with the confirmation mechanism of Keepalive messages, the problem of lack of security verification in the GRE P2MP tunnel is solved, effectively identifying and processing attack messages is realized, and the forwarding performance of network devices is improved.
Patent Information
- Application Number
- CN202510101437.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-01-22
- Publication Date
- 2025-05-06
- Estimated Expiration
- 2045-01-22
AI Technical Summary
The existing GRE P2MP tunnel lacks corresponding security verification, which causes the central node to create a large number of invalid tunnel table entries when receiving attack messages, affecting the normal forwarding process.
By receiving the message sent by the second network device on the first network device, it is determined whether there is an attack-proof table entry or a tunnel table entry that matches the source address. If it does not exist, an attack-proof table entry is generated, and the validity of the entry is confirmed through the Keepalive request message and the reply message, and the invalid table entry is deleted.
Effectively identify and process attack messages, prevent the creation of invalid tunnel table entries, improve the message forwarding performance of network equipment, and solve the problem of lack of security verification in GRE P2MP tunnels.
Smart Images

Figure CN119945777A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of communication technology, and in particular to an attack protection method and device. Background Art
[0002] Generic Routing Encapsulation (GRE) tunnel is a common virtual point-to-point connection. When GRE tunnel is applied to enterprise network, multiple GRE tunnels need to be established between the central node and each branch. When there are many branches, the configuration workload is huge; moreover, if a new branch is added, additional configuration needs to be added at the central node, which increases the burden of network maintenance.
[0003] Point to multi-point (P2MP) GRE tunnels can solve the above problems and are suitable for enterprise networks with many branches. In P2MP GRE tunnel networking, a P2MP GRE mode tunnel interface (hereinafter referred to as P2MP GRE tunnel interface) is configured at the central node, and a GRE mode tunnel interface (hereinafter referred to as GRE tunnel interface) is configured at the branch. In this way, tunnels can be dynamically established between the central node and multiple branches.
[0004] Unlike the GRE tunnel interface, the P2MP GRE tunnel interface does not need to manually configure the tunnel destination address, but dynamically learns the tunnel destination address based on the received message and establishes a tunnel table entry. The tunnel table entry includes the tunnel destination address field (the source address in the outer header of the message), the branch network segment address field (the source address in the inner header of the message), the GRE Key field, and the last entry refresh time field.
[0005] However, the existing configuration of P2MP GRE tunnels in enterprise networks with many branches also exposes the following problems: There is a lack of corresponding security verification for GRE P2MP tunnels. After the central node receives a message whose destination address matches the source address of the local GRE P2MP tunnel, it can establish a tunnel table entry. If an attack message is received, it will cause the central node to create a large number of invalid tunnel table entries, affecting the normal forwarding process. Summary of the invention
[0006] In view of this, the present application provides an attack protection method and device to solve the problem that the existing GRE P2MP tunnel lacks corresponding security verification.
[0007] In a first aspect, the present application provides an attack protection method, the method is applied to a first network device, the first network device establishes a P2MP GRE tunnel with a second network device, the method comprising:
[0008] Receiving, through the P2MP GRE tunnel, a first message sent by the second network device, the first message including a first IP header and a second IP header, the first IP header including a first source address, and the second IP header including a second source address;
[0009] If there is no first anti-attack table entry matching the first source address in the locally stored anti-attack table and the first message is a data message, determine in the locally stored branch network segment hash table whether there is a first tunnel table entry matching both the first source address and the belonging network segment of the second source address;
[0010] If there is no first tunnel entry in the branch network segment hash table that matches the network segments of the first source address and the second source address, a second anti-attack entry is generated, where the second anti-attack entry includes the network segments of the first source address and the second source address;
[0011] Sending a second message to the second network device according to the second attack prevention table entry;
[0012] If a third message sent by the second network device according to the second message is received, the second attack prevention entry is deleted from the attack prevention table, and the second attack prevention entry is stored in the branch network segment hash table as a second tunnel entry;
[0013] The second message is a Keepalive request message, and the third message is a Keepalive response message.
[0014] In a second aspect, the present application provides an attack protection device, which is applied to a first network device, wherein the first network device establishes a P2MP GRE tunnel with a second network device, and the device includes:
[0015] a receiving unit, configured to receive, through the P2MP GRE tunnel, a first message sent by the second network device, wherein the first message includes a first IP header and a second IP header, the first IP header includes a first source address, and the second IP header includes a second source address;
[0016] A judgment unit, used for judging whether there is a first tunnel table entry matching both the first source address and the belonging network segment of the second source address in the locally stored branch network segment hash table if there is no first anti-attack table entry matching the first source address in the locally stored anti-attack table and the first message is a data message;
[0017] A generating unit, configured to generate a second anti-attack entry if there is no first tunnel entry in the branch network segment hash table that matches both the first source address and the second source address's belonging network segments, wherein the second anti-attack entry includes the first source address and the second source address's belonging network segments;
[0018] A sending unit, configured to send a second message to the second network device according to the second anti-attack table item;
[0019] a processing unit, configured to delete the second anti-attack entry from the anti-attack table if a third message sent by the second network device according to the second message is received, and store the second anti-attack entry in the branch network segment hash table as a second tunnel entry;
[0020] The second message is a Keepalive request message, and the third message is a Keepalive response message.
[0021] In a third aspect, the present application provides a network device, including a processor and a machine-readable storage medium, the machine-readable storage medium storing machine-executable instructions that can be executed by the processor, and the processor is prompted by the machine-executable instructions to execute the method provided in the first aspect of the present application.
[0022] Therefore, by applying the attack protection method and device provided by the present application, through the P2MP GRE tunnel, the first network device receives the first message sent by the second network device, the first message includes a first IP header and a second IP header, the first IP header includes a first source address, and the second IP header includes a second source address; if there is no first anti-attack table entry matching the first source address in the locally stored anti-attack table and the first message is a data message, the first network device determines whether there is a first tunnel table entry matching the belonging network segments of the first source address and the second source address in the locally stored branch network segment hash table; if there is no belonging network segment matching the first source address and the second source address in the branch network segment hash table If there is a first tunnel table entry that matches both of them, the first network device generates a second anti-attack table entry, and the second anti-attack table entry includes the first source address and the network segment to which the second source address belongs; according to the second anti-attack table entry, the first network device sends a second message to the second network device; if a third message is received from the second network device based on the second message, the first network device deletes the second anti-attack table entry from the anti-attack table, and stores the second anti-attack table entry as the second tunnel table entry in the branch network segment hash table; wherein the second message is a Keepalive request message, and the third message is a Keepalive response message.
[0023] Thus, through the above-mentioned method, the P2MP GRE tunnel on the central node side can identify the attack message through a simple method, thereby improving the message forwarding performance of the network device. At the same time, it also solves the problem that the existing GRE P2MP tunnel lacks corresponding security verification. BRIEF DESCRIPTION OF THE DRAWINGS
[0024] Figure 1 A flowchart of an attack protection method provided in an embodiment of the present application;
[0025] Figure 2 A flowchart of another attack protection method provided in an embodiment of the present application;
[0026] Figure 3 A schematic diagram of the message format of a Keepalive request message and a Keepalive response message provided in an embodiment of the present application;
[0027] Figure 4 A structural diagram of an attack protection device provided in an embodiment of the present application;
[0028] Figure 5 The network device hardware structure provided in the embodiment of the present application. DETAILED DESCRIPTION
[0029] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.
[0030] The terms used in this application are only for the purpose of describing specific embodiments and are not intended to limit this application. The singular forms of "a", "said" and "the" used in this application and the appended claims are also intended to include plural forms unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used in this article refers to and includes any or all possible combinations of one or more corresponding listed items.
[0031] It should be understood that although the terms first, second, third, etc. may be used in the present application to describe various information, these information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of the present application, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".
[0032] The attack protection method provided by the embodiment of the present application is described in detail below. Figure 1 , Figure 1 A flowchart of an attack protection method provided in an embodiment of the present application. The method is applied to a first network device, and a P2MP GRE tunnel has been established between the first network device and the second network device. An attack protection method provided in an embodiment of the present application may include the following steps.
[0033] Step 110: Receive, through the P2MP GRE tunnel, a first message sent by the second network device, where the first message includes a first IP header and a second IP header, where the first IP header includes a first source address, and the second IP header includes a second source address;
[0034] Specifically, the first network device and at least one second network device form an enterprise network, wherein the first network device may be specifically a central node included in the enterprise network, and each second network device may be specifically a branch office included in the enterprise network.
[0035] The first network device is configured with a tunnel interface in P2MP GRE mode (hereinafter referred to as P2MP GRE tunnel interface), and the second network device is configured with a tunnel interface in GRE mode (hereinafter referred to as GRE tunnel interface). A P2MP GRE tunnel is established between the first network device and the second network device.
[0036] It can be understood that in the embodiment of the present application, the steps and processes performed by each second network device are the same, and the following description is given using a second network device as an example.
[0037] The second network device wants to communicate with the first network device. The second network device sends a first message to the first network device through the P2MP GRE tunnel.
[0038] The first message includes a first Internet Protocol (IP) header (i.e., a first outer IP header) and a second IP header (i.e., a first inner IP header). The first IP header includes a first source address and a first destination address, and the second IP header includes a second source address and a second destination address.
[0039] Through the P2MP GRE tunnel, the first network device receives the first message and obtains the first destination address therefrom.
[0040] Step 120: If there is no first anti-attack table entry matching the first source address in the locally stored anti-attack table and the first message is not a Keepalive message, determine in the locally stored branch network segment hash table whether there is a first tunnel table entry matching both the first source address and the home network segment of the second source address;
[0041] Specifically, according to the description of step 110, after the first network device obtains the first source address and the first destination address, it first identifies whether the first destination address is the source address of the locally configured P2MP GRE tunnel. If so, the first network device determines whether there is a first anti-attack table entry matching the first source address in the locally stored anti-attack table.
[0042] If the first attack prevention entry does not exist in the attack prevention table, then according to the first destination address, the first network device again determines whether there is a first UpTunnel entry matching the first destination address in the locally stored valid tunnel (Up Tunnel) table.
[0043] If the first Up Tunnel table entry exists in the Up Tunnel table, the first network device obtains the GRE key (Key) again from the GRE header included in the first message.
[0044] The first network device decapsulates the first message to obtain an inner message. The first network device determines whether the first message is a Keepalive message through the inner message. If the source / destination address included in the first inner IP header is an opposite record of the source / destination address included in the first outer IP header, the first message is a Keepalive message; if the source / destination address included in the first inner IP header is different from the source / destination address included in the first outer IP header, the first message is not a Keepalive message.
[0045] In the embodiment of the present application, if the first attack protection entry does not exist and the first message is not a Keepalive message, the first network device calculates the home network segment of the second source address.
[0046] The first network device determines whether there is a first tunnel entry matching both the home network segments of the first source address and the second source address in the locally stored branch network segment hash table. If there is no first tunnel entry, the first network device executes step 130.
[0047] Optionally, in an embodiment of the present application, if the first attack prevention entry exists in the attack prevention table, the first network device determines that the first message is an attack message, discards the first message, and ends this process.
[0048] Optionally, in the embodiment of the present application, if the first Up Tunnel table does not contain the first Up Tunnel table entry, the first network device ends the process.
[0049] Optionally, in the embodiment of the present application, if the first anti-attack entry does not exist and the first message is a Keepalive message, the first network device performs secondary forwarding according to the second destination address included in the inner message. It can be understood that the secondary forwarding process is the same as the existing forwarding process and will not be repeated here.
[0050] Step 130: If there is no first tunnel entry in the branch network segment hash table that matches the home network segments of the first source address and the second source address, generate a second attack prevention entry, where the second attack prevention entry includes the home network segments of the first source address and the second source address;
[0051] Specifically, according to the description of step 120, if the first tunnel entry does not exist, the first network device generates a second attack prevention entry, and the second attack prevention entry includes the first source address and the home network segment of the second source address.
[0052] Optionally, in an embodiment of the present application, each anti-attack entry includes a tunnel destination address field, a branch network segment address field, a GRE Key field, and a last entry refresh time field.
[0053] Among them, the tunnel destination address field stores the first source address included in any received data message; the branch network segment address field stores the network segment to which the second source address included in any data message belongs; the GRE Key field stores the GRE Key value (the value range is 0 to 4294967295) in the GRE header included in any data message, and the last table entry refresh time field stores the current time for processing the anti-attack table entry.
[0054] For example, the attack prevention table is shown in Table 1 below.
[0055] Table 1 Attack prevention entries
[0056] Tunnel destination address Branch network segment address GRE Key Last entry refresh time 11.1.1.1 10.1.1.0 / 24 123 14:00
[0057] Optionally, in an embodiment of the present application, if there is a first tunnel table entry, the first network device updates the last table entry refresh time field included in the first tunnel table entry. The first network device stores the current time in the last table entry refresh time field. The first network device performs secondary forwarding according to the second destination address included in the inner message. It can be understood that the above secondary forwarding process is the same as the existing forwarding process and will not be repeated here.
[0058] Step 140: Send a second message to the second network device according to the second attack protection entry;
[0059] Specifically, according to the description of step 130, after the first network device generates the second attack prevention entry, it generates the second message according to the second attack prevention entry. The first network device sends the second message to the second network device through the P2MP GRE tunnel.
[0060] Optionally, in an embodiment of the present application, the second message includes a third IP header, a first GRE header, a fourth IP header, and a second GRE header. The third IP header may also be referred to as a first outer IP header, and the fourth IP header may also be referred to as a first inner IP header. The first GRE header is located after the third IP header and before the fourth IP header, and the second GRE header is located after the fourth IP header.
[0061] Among them, the source address field included in the third IP header stores the source address of the locally configured P2MP GRE tunnel, and the destination address field included in the third IP header stores the address stored in the tunnel destination address field; the source address field included in the fourth IP header stores the address stored in the tunnel destination address field, and the destination address field included in the fourth IP header stores the source address of the locally configured P2MP GRE tunnel.
[0062] The second message may specifically be a protocol message, for example, a Keepalive request message.
[0063] Step 150: If a third message sent by the second network device according to the second message is received, the second attack prevention entry is deleted from the attack prevention table, and the second attack prevention entry is stored in the branch network segment hash table as a second tunnel entry.
[0064] Specifically, according to the description of step 140, after the first network device sends the second message to the second network device, a timer is started internally (the preset time may be 3 seconds). Within the preset time, the first network device determines whether a third message sent by the second network device according to the second message is received.
[0065] If the third message is received, the first network device deletes the second attack prevention entry from the attack prevention table, and stores the second attack prevention entry in the branch network segment hash table as the second tunnel entry.
[0066] Optionally, in an embodiment of the present application, the third message includes a fourth IP header and a second GRE header.
[0067] The source address field included in the fourth IP header stores the address stored in the tunnel destination address field, and the destination address field included in the fourth IP header stores the source address of the locally configured P2MP GRE tunnel.
[0068] In the embodiment of the present application, after receiving the second message, the second network device obtains the third IP header and the destination address field from the third IP header. The address stored in the destination address field is determined to be the source address of the locally configured P2MP GRE tunnel. The second network device decapsulates the second message, that is, strips the third IP header and the first GRE header from the second message to obtain the third message.
[0069] The second network device sends a third message to the first network device through the P2MP GRE tunnel.
[0070] The third message may specifically be a protocol message, for example, a Keepalive response message.
[0071] In the embodiment of the present application, the first network device uses the protocol message to identify whether the second attack prevention entry is created by the attack message.
[0072] It is understandable that if the Keepalive response message sent by the second network device is received within the preset time, the first network device determines that the second attack prevention entry is not created by the attack message. The first network device deletes the second attack prevention entry from the attack prevention table and adds it to the formal branch network segment hash table.
[0073] Optionally, if the third message is not received, the first network device ends this process.
[0074] In the embodiment of the present application, the first network device generates a corresponding anti-attack entry before generating a tunnel entry, and adds the anti-attack entry to the anti-attack table. By actively triggering the sending of a Keepalive message, it is identified whether the anti-attack entry is created by an attack message.
[0075] If the Keepalive response message sent by the second network device is received, it is determined that the anti-attack entry is not created by the attack message. At this time, the first network device removes the anti-attack entry from the anti-attack table and adds the anti-attack entry to the branch network segment hash table.
[0076] If the Keepalive response message sent by the second network device is not received, it is determined that the anti-attack table entry is created by the attack message. At this time, the first network device continues to store the anti-attack table entry in the anti-attack table. In the subsequent process of receiving data messages, if the destination address of the message matches a certain anti-attack table entry, the first network device determines that it has been attacked and discards the attack message; at the same time, the first network device will also update the last table entry refresh time included in the matching anti-attack table entry. The last table entry refresh time is updated to the current time of the first network device.
[0077] In an embodiment of the present application, the anti-attack table can set the maximum specification and the timeout aging time of each table item according to the product capability of the first network device. If the first network device currently receives a large number of attack messages, resulting in the anti-attack table item exceeding the maximum specification, the first network device will age and delete the anti-attack table item of the earliest time indicated by the last table item refresh time field. If the first network device does not receive an attack message within a period of time, the first network device can age the anti-attack table item by itself through a timer (for example, 1 minute).
[0078] Therefore, by applying the attack protection method and device provided by the present application, through the P2MP GRE tunnel, the first network device receives the first message sent by the second network device, the first message includes a first IP header and a second IP header, the first IP header includes a first source address, and the second IP header includes a second source address; if there is no first anti-attack table entry matching the first source address in the locally stored anti-attack table and the first message is not a Keepalive message, the first network device determines whether there is a first tunnel table entry matching the belonging network segments of the first source address and the second source address in the locally stored branch network segment hash table; if there is no first tunnel table entry matching the belonging network segments of the first source address and the second source address in the branch network segment hash table, If the first tunnel table entry of the belonging network segments all matches, the first network device generates a second anti-attack table entry, and the second anti-attack table entry includes the belonging network segments of the first source address and the second source address; according to the second anti-attack table entry, the first network device sends a second message to the second network device; if a third message sent by the second network device according to the second message is received, the first network device deletes the second anti-attack table entry from the anti-attack table, and stores the second anti-attack table entry as the second tunnel table entry in the branch network segment hash table; wherein the second message is a Keepalive request message, and the third message is a Keepalive response message.
[0079] Thus, through the above-mentioned method, the P2MP GRE tunnel on the central node side can identify the attack message through a simple method, thereby improving the message forwarding performance of the network device. At the same time, it also solves the problem that the existing GRE P2MP tunnel lacks corresponding security verification.
[0080] The attack protection method provided by the embodiment of the present application is described in detail below. Figure 2 , Figure 2 A flowchart of another attack protection method provided in an embodiment of the present application. Another attack protection method provided in an embodiment of the present application may include the following steps.
[0081] Step 200: Through the P2MP GRE tunnel, the first network device receives a first message sent by the second network device.
[0082] Specifically, the first network device and the second network device form an enterprise network, wherein the first network device may be specifically a central node included in the enterprise network, and the second network device may be specifically a branch office included in the enterprise network.
[0083] The first network device is configured with a tunnel interface in P2MP GRE mode (hereinafter referred to as P2MP GRE tunnel interface), and the second network device is configured with a tunnel interface in GRE mode (hereinafter referred to as GRE tunnel interface). A P2MP GRE tunnel is established between the first network device and the second network device.
[0084] The second network device wants to communicate with the first network device. The second network device sends a first message to the first network device through the P2MP GRE tunnel.
[0085] The first message includes an outer IP header and an inner IP header. The outer IP header includes a first source address and a first destination address, and the inner IP header includes a second source address and a second destination address. A GRE header is between the outer IP header and the inner IP header, and the GRE header includes a GRE Key field.
[0086] Step 201: A first network device sends a first message to a protocol stack for processing.
[0087] Specifically, after obtaining the first source address and the first destination address from the outer IP header, the first network device first identifies whether the first destination address is the source address of the locally configured P2MP GRE tunnel. If so, the first network device executes step 202.
[0088] Step 202: The first network device determines whether there is a first attack prevention entry matching the first source address in the locally stored attack prevention table.
[0089] Specifically, if the first attack prevention entry exists in the attack prevention table, the first network device executes step 203 ; if the first attack prevention entry does not exist in the attack prevention table, the first network device executes step 213 .
[0090] Step 203: If there is no first attack prevention entry matching the first source address in the attack prevention table, the first network device determines whether there is a first Up Tunnel entry matching the first destination address in the locally stored Up Tunnel table.
[0091] Specifically, according to the description of step 202, if the first attack prevention entry exists in the attack prevention table, the first network device continues to determine whether there is a first Up Tunnel entry matching the first destination address in the locally stored Up Tunnel table.
[0092] If the first Up Tunnel entry exists in the Up Tunnel table, the first network device executes step 204 ; if the first Up Tunnel entry does not exist in the Up Tunnel table, the first network device executes step 212 .
[0093] The first attack prevention table item is shown in Table 1 above and will not be repeated here.
[0094] In an embodiment of the present application, the anti-attack table can be stored locally in the form of a hash table or a Radix tree. The hash table or the Radix tree includes multiple nodes, each of which stores a hash key value and at least one anti-attack table item. The hash key value can be specifically calculated from the branch network segment address (i.e., the second source address) where the second network device is located.
[0095] During the search process, a matching node is found according to the branch network segment address; and then each anti-attack table entry in the node is found according to the first source address.
[0096] If the first Up Tunnel entry does not exist in the Up Tunnel table, the first network device executes step 212 to end the current process.
[0097] Step 204: If the first Up Tunnel entry exists in the Up Tunnel table, the first network device decapsulates the first message.
[0098] Specifically, according to the description of step 203, if the first Up Tunnel table entry exists in the Up Tunnel table, the first network device obtains the GRE Key again from the GRE header included in the first message.
[0099] The first network device strips the outer IP header and the GRE header from the first message to obtain an inner message. That is, after the outer IP header and the GRE header are stripped from the first message, the inner IP header is exposed.
[0100] Step 205: The first network device determines whether the first message is a Keepalive message.
[0101] Specifically, the first network device determines whether the first message is a Keepalive message through the inner layer message. If the source / destination address included in the inner layer IP header is an opposite record to the source / destination address included in the outer layer IP header, the first message is a Keepalive message, and the first network device executes step 215; if the source / destination address included in the inner layer IP header is different from the source / destination address included in the outer layer IP header, the first message is not a Keepalive message, and the first network device executes step 206;
[0102] Step 206: The first network device obtains the second source address from the first message, and determines the network segment to which the second source address belongs.
[0103] Specifically, if the first message is not a Keepalive message, the first network device obtains the second source address from the inner IP header and determines the network segment to which the second source address belongs.
[0104] For example, if the second source address is 10.1.1.2 / 24, the network segment to which the second source address belongs is 10.1.1.0 / 24.
[0105] Step 207: According to the first source address and the second source address, the first network device searches the locally stored branch network segment hash table.
[0106] Specifically, there is at least one tunnel entry in the branch network segment hash table. The structure of each tunnel entry is the same as the structure of the aforementioned anti-attack entry. The tunnel entry includes a tunnel destination address field, a branch network segment address field, a GRE Key field, and a last entry refresh time field.
[0107] Among them, the tunnel destination address field stores the first source address included in any received data message (that is, the source address included in the outer IP header); the branch network segment address field stores the network segment to which the second source address included in any data message belongs (that is, the network segment to which the source address included in the inner IP header belongs); the GRE Key field stores the GRE Key value in the GRE header included in any data message (the value range is 0 to 4294967295), and the last table entry refresh time field stores the current time for processing the anti-attack table entry.
[0108] The structure of the first tunnel entry is shown in Table 1 above and will not be repeated here.
[0109] In an embodiment of the present application, the branch network segment hash table can be stored locally in the form of a hash table or a Radix tree. The hash table or the Radix tree includes multiple nodes, each of which stores a hash key value and at least one anti-attack table item. The hash key value can be specifically calculated from the branch network segment address (i.e., the second source address) where the second network device is located.
[0110] During the search process, a matching node is found according to the branch network segment address; and then each tunnel table entry in the node is found according to the first source address.
[0111] Step 208: The first network device determines whether there is a first tunnel entry that matches the home network segments of the first source address and the second source address.
[0112] Specifically, according to the description of step 207, the first network device determines whether there is a first tunnel table entry that matches both the home network segments of the first source address and the second source address in the locally stored branch network segment hash table.
[0113] If the first tunnel entry does not exist, the first network device executes step 209 ; if the first tunnel entry exists, the first network device executes step 214 .
[0114] Step 209: If there is no first tunnel entry in the branch network segment hash table that matches the home network segments of the first source address and the second source address, the first network device generates a second attack prevention entry and sends a Keepalive request message to the second network device according to the second attack prevention entry.
[0115] Specifically, according to the description of step 208, if the first tunnel entry does not exist in the branch network segment hash table, the first network device generates a second attack prevention entry, which includes the first source address and the home network segment of the second source address.
[0116] The second attack prevention table entry is shown in the aforementioned Table 1 and will not be repeated here.
[0117] After the first network device generates the second attack prevention entry, it generates a Keepalive message according to the second attack prevention entry. The first network device sends the Keepalive message to the second network device through the P2MP GRE tunnel.
[0118] like Figure 3 As shown, Figure 3 A schematic diagram of the message format of a Keepalive request message and a Keepalive response message provided in an embodiment of the present application. Figure 3In the example, the Keepalive request message includes an outer IP header, an outer GRE header, an inner IP header, and an inner GRE header. The message length of the Keepalive request message is 0.
[0119] The source address field included in the outer IP header stores the source address of the locally configured P2MP GRE tunnel, and the destination address field included in the outer IP header stores the address stored in the tunnel destination address field; the source address field included in the inner IP header stores the address stored in the tunnel destination address field, and the destination address field included in the inner IP header stores the source address of the locally configured P2MP GRE tunnel.
[0120] Step 210: The first network device determines whether a Keepalive response message sent by the second network device in response to the Keepalive request message is received.
[0121] Specifically, after the first network device sends a Keepalive request message to the second network device, a timer is started internally (the preset time may be 3 seconds). Within the preset time, the first network device determines whether a Keepalive response message sent by the second network device according to the Keepalive message is received.
[0122] If the Keepalive response message is received, the first network device executes step 211 ; if the Keepalive response message is not received, the first network device executes step 212 .
[0123] Step 211: If a Keepalive response message is received, the first network device deletes the second attack prevention entry from the attack prevention table, and stores the second attack prevention entry as a second tunnel entry in the branch network segment hash table.
[0124] Specifically, if the Keepalive response message is received, the first network device deletes the second attack prevention entry from the attack prevention table, and stores the second attack prevention entry as the second tunnel entry in the branch network segment hash table.
[0125] like Figure 3 As shown, in Figure 3 In the example, the Keepalive response message includes an inner IP header and an inner GRE header. The message length of the Keepalive response message is 0.
[0126] The source address field included in the inner IP header stores the address stored in the tunnel destination address field, and the destination address field included in the inner IP header stores the source address of the locally configured P2MP GRE tunnel.
[0127] In the embodiment of the present application, after receiving the Keepalive request message, the second network device obtains the outer IP header and the destination address field from the outer IP header. The address stored in the destination address field is determined to be the source address of the locally configured P2MP GRE tunnel. The second network device decapsulates the Keepalive request message, that is, strips the outer IP header and the outer GRE header from the Keepalive request message, and then obtains the Keepalive response message.
[0128] The second network device sends a Keepalive response message to the first network device through the P2MP GRE tunnel.
[0129] In the embodiment of the present application, the first network device uses the Keepalive message to identify whether the second attack prevention entry is created by the attack message.
[0130] It is understandable that if the Keepalive response message sent by the second network device is received within the preset time, the first network device determines that the second attack prevention entry is not created by the attack message. The first network device deletes the second attack prevention entry from the attack prevention table and adds it to the formal branch network segment hash table.
[0131] Step 212, end this process.
[0132] Specifically, if a Keepalive response message is received, the first network device ends the current process.
[0133] Step 213: If the first attack prevention entry exists in the attack prevention table, the first network device discards the first message.
[0134] Specifically, if the first attack prevention table contains the first attack prevention entry, the first network device determines that the first message is an attack message. The first network device discards the first message and executes step 212.
[0135] Step 214: If there is a first tunnel entry in the branch network segment hash table that matches both the home network segments of the first source address and the second source address, the first network device updates the first tunnel entry.
[0136] Specifically, according to the description of step 208, if the first tunnel entry exists in the branch network segment hash table, the first network device obtains the current time and updates the time value stored in the last entry refresh time field included in the first tunnel entry to the current time.
[0137] It is understandable that the updated first tunnel entry will continue to be stored in the branch network segment hash table. Since the address stored in the branch network segment address field included in the first tunnel entry is not updated, the node stored in the updated first tunnel entry is not changed.
[0138] Step 215: Forward the first message after decapsulation.
[0139] Specifically, after the first network device updates the first tunnel table entry or the first message is a Keepalive message, the first network device obtains the second destination address from the inner IP header and forwards the inner message for a second time according to the second destination address.
[0140] It can be understood that the above-mentioned secondary forwarding process is the same as the existing forwarding process and will not be repeated here.
[0141] Based on the same inventive concept, the embodiment of the present application also provides an attack protection device corresponding to the attack protection method. Figure 4 , Figure 4 An attack protection device provided in an embodiment of the present application is applied to a first network device, the first network device establishes a P2MP GRE tunnel with a second network device, and the device includes:
[0142] The receiving unit 410 is configured to receive, through the P2MP GRE tunnel, a first message sent by the second network device, wherein the first message includes a first IP header and a second IP header, wherein the first IP header includes a first source address, and the second IP header includes a second source address;
[0143] A judgment unit 420 is used to judge whether there is a first tunnel table entry matching the first source address and the belonging network segment of the second source address in the locally stored branch network segment hash table if there is no first anti-attack table entry matching the first source address in the locally stored anti-attack table and the first message is not a Keepalive message;
[0144] A generating unit 430 is configured to generate a second anti-attack entry if there is no first tunnel entry in the branch network segment hash table that matches both the first source address and the second source address's belonging network segment, wherein the second anti-attack entry includes the first source address and the second source address's belonging network segment;
[0145] A sending unit 440, configured to send a second message to the second network device according to the second attack prevention table item;
[0146] The processing unit 450 is configured to delete the second attack prevention entry from the attack prevention table if a third message sent by the second network device according to the second message is received, and store the second attack prevention entry in the branch network segment hash table as a second tunnel entry;
[0147] The second message is a Keepalive request message, and the third message is a Keepalive response message.
[0148] Optionally, the device further comprises:
[0149] A discarding unit (not shown in the figure) is used to discard the first message if the first anti-attack table entry matching the first source address exists in the anti-attack table.
[0150] Optionally, the attack prevention entry includes a tunnel destination address field, a branch network segment address field, a GRE Key field, and a last entry refresh time field;
[0151] The tunnel destination address field stores the first source address included in any received data message, the branch network segment address field stores the network segment to which the second source address included in any data message belongs, the GRE Key field stores the GRE Key value in the GRE header included in any data message, and the last table entry refresh time field stores the current time for processing the anti-attack table entry.
[0152] Optionally, the second message includes a third IP header, a first GRE header, a fourth IP header and a second GRE header;
[0153] The source address field included in the third IP header stores the locally configured source address of the P2MP GRE tunnel, and the destination address field included in the third IP header stores the address stored in the tunnel destination address field;
[0154] The source address field included in the fourth IP header stores the address stored in the tunnel destination address field, and the destination address field included in the fourth IP header stores the locally configured source address of the P2MP GRE tunnel.
[0155] Optionally, the third message includes the fourth IP header and the second GRE header;
[0156] The source address field included in the fourth IP header stores the address stored in the tunnel destination address field, and the destination address field included in the fourth IP header stores the locally configured source address of the P2MP GRE tunnel;
[0157] The third message is sent after the second network device strips the third IP header and the first GRE header from the second message.
[0158] Therefore, by applying the attack protection device provided by the present application, through the P2MP GRE tunnel, the first network device receives the first message sent by the second network device, the first message includes a first IP header and a second IP header, the first IP header includes a first source address, and the second IP header includes a second source address; if there is no first anti-attack table entry matching the first source address in the locally stored anti-attack table and the first message is not a Keepalive message, the first network device determines whether there is a first tunnel table entry matching the belonging network segments of the first source address and the second source address in the locally stored branch network segment hash table; if there is no first tunnel table entry matching the belonging network segments of the first source address and the second source address in the branch network segment hash table, If the first tunnel table entry of the belonging network segments all matches, the first network device generates a second anti-attack table entry, and the second anti-attack table entry includes the belonging network segments of the first source address and the second source address; according to the second anti-attack table entry, the first network device sends a second message to the second network device; if a third message sent by the second network device according to the second message is received, the first network device deletes the second anti-attack table entry from the anti-attack table, and stores the second anti-attack table entry as the second tunnel table entry in the branch network segment hash table; wherein the second message is a Keepalive request message, and the third message is a Keepalive response message.
[0159] Thus, through the above-mentioned method, the P2MP GRE tunnel on the central node side can identify the attack message through a simple method, thereby improving the message forwarding performance of the network device. At the same time, it also solves the problem that the existing GRE P2MP tunnel lacks corresponding security verification.
[0160] Based on the same inventive concept, the embodiment of the present application also provides a network device, such as Figure 5 As shown, it includes a processor 510, a transceiver 520 and a machine-readable storage medium 530, the machine-readable storage medium 530 stores machine-executable instructions that can be executed by the processor 510, and the processor 510 is prompted by the machine-executable instructions to execute the attack protection method provided in the embodiment of the present application. Figure 4 The attack protection device shown can be used as follows Figure 5 The network device hardware structure shown is implemented.
[0161] The computer-readable storage medium 530 may include a random access memory (RAM) or a non-volatile memory (NVM), such as at least one disk storage. Optionally, the computer-readable storage medium 530 may also be at least one storage device located away from the processor 510.
[0162] The processor 510 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.
[0163] In the embodiment of the present application, the processor 510 reads the machine executable instructions stored in the machine readable storage medium 530, and the machine executable instructions enable the processor 510 itself and the transceiver 520 to execute the attack protection method described in the aforementioned embodiment of the present application.
[0164] In addition, an embodiment of the present application provides a machine-readable storage medium 530, which stores machine-executable instructions. When called and executed by the processor 510, the machine-executable instructions prompt the processor 510 itself and the calling transceiver 520 to execute the attack protection method described in the aforementioned embodiment of the present application.
[0165] The implementation process of the functions and effects of each unit in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.
[0166] For the device embodiment, since it basically corresponds to the method embodiment, the relevant parts can refer to the partial description of the method embodiment. The device embodiment described above is only schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present application scheme. A person of ordinary skill in the art can understand and implement it without paying any creative work.
[0167] As for the attack protection device and the machine-readable storage medium embodiments, since the method contents involved are basically similar to the aforementioned method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.
[0168] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.
Claims
1. An attack protection method, characterized in that: The method is applied to a first network device, the first network device establishes a P2MP GRE tunnel with a second network device, and the method includes: Receiving, through the P2MP GRE tunnel, a first message sent by the second network device, the first message including a first IP header and a second IP header, the first IP header including a first source address, and the second IP header including a second source address; If there is no first anti-attack table entry matching the first source address in the locally stored anti-attack table and the first message is not a Keepalive message, determine in the locally stored branch network segment hash table whether there is a first tunnel table entry matching both the first source address and the belonging network segment of the second source address; If there is no first tunnel entry in the branch network segment hash table that matches the network segments of the first source address and the second source address, a second anti-attack entry is generated, where the second anti-attack entry includes the network segments of the first source address and the second source address; Sending a second message to the second network device according to the second attack prevention entry; If a third message sent by the second network device according to the second message is received, the second attack prevention entry is deleted from the attack prevention table, and the second attack prevention entry is stored in the branch network segment hash table as a second tunnel entry; The second message is a Keepalive request message, and the third message is a Keepalive response message.
2. The method according to claim 1, characterized in that The method further comprises: If the first attack prevention entry matching the first source address exists in the attack prevention table, the first message is discarded.
3. The method according to any one of claims 1 or 2, characterized in that: The attack prevention table entry includes the tunnel destination address field, branch network segment address field, GRE Key field, and the last table entry refresh time field; The tunnel destination address field stores the first source address included in any received data message, the branch network segment address field stores the network segment to which the second source address included in any data message belongs, the GRE Key field stores the GRE Key value in the GRE header included in any data message, and the last table entry refresh time field stores the current time for processing the anti-attack table entry.
4. The method according to claim 3, characterized in that The second message includes a third IP header, a first GRE header, a fourth IP header and a second GRE header; The source address field included in the third IP header stores the locally configured source address of the P2MP GRE tunnel, and the destination address field included in the third IP header stores the address stored in the tunnel destination address field; The source address field included in the fourth IP header stores the address stored in the tunnel destination address field, and the destination address field included in the fourth IP header stores the locally configured source address of the P2MP GRE tunnel.
5. The method according to claim 4, characterized in that The third message includes the fourth IP header and the second GRE header; The source address field included in the fourth IP header stores the address stored in the tunnel destination address field, and the destination address field included in the fourth IP header stores the locally configured source address of the P2MP GRE tunnel; The third message is sent after the second network device strips the third IP header and the first GRE header from the second message.
6. An attack protection device, characterized in that: The apparatus is applied to a first network device, the first network device establishes a P2MP GRE tunnel with a second network device, and the apparatus includes: a receiving unit, configured to receive, through the P2MP GRE tunnel, a first message sent by the second network device, wherein the first message includes a first IP header and a second IP header, the first IP header includes a first source address, and the second IP header includes a second source address; A judgment unit, used for judging whether there is a first tunnel table entry matching both the first source address and the belonging network segment of the second source address in the locally stored branch network segment hash table if there is no first anti-attack table entry matching the first source address in the locally stored anti-attack table and the first message is not a Keepalive message; A generating unit, configured to generate a second anti-attack entry if there is no first tunnel entry in the branch network segment hash table that matches both the first source address and the second source address's belonging network segments, wherein the second anti-attack entry includes the first source address and the second source address's belonging network segments; A sending unit, configured to send a second message to the second network device according to the second anti-attack table item; a processing unit, configured to delete the second anti-attack entry from the anti-attack table if a third message sent by the second network device according to the second message is received, and store the second anti-attack entry in the branch network segment hash table as a second tunnel entry; The second message is a Keepalive request message, and the third message is a Keepalive response message.
7. The device according to claim 6, characterized in that The device also includes: A discarding unit is used to discard the first message if the first anti-attack table entry matching the first source address exists in the anti-attack table.
8. The device according to any one of claims 6 or 7, characterized in that The attack prevention table entry includes the tunnel destination address field, branch network segment address field, GRE Key field, and the last table entry refresh time field; The tunnel destination address field stores the first source address included in any received data message, the branch network segment address field stores the network segment to which the second source address included in any data message belongs, the GRE Key field stores the GRE Key value in the GRE header included in any data message, and the last table entry refresh time field stores the current time for processing the anti-attack table entry.
9. The device according to claim 8, characterized in that The second message includes a third IP header, a first GRE header, a fourth IP header and a second GRE header; The source address field included in the third IP header stores the locally configured source address of the P2MP GRE tunnel, and the destination address field included in the third IP header stores the address stored in the tunnel destination address field; The source address field included in the fourth IP header stores the address stored in the tunnel destination address field, and the destination address field included in the fourth IP header stores the locally configured source address of the P2MP GRE tunnel.
10. The device according to claim 9, characterized in that The third message includes the fourth IP header and the second GRE header; The source address field included in the fourth IP header stores the address stored in the tunnel destination address field, and the destination address field included in the fourth IP header stores the locally configured source address of the P2MP GRE tunnel; The third message is sent after the second network device strips the third IP header and the first GRE header from the second message.
Citation Information
Patent Citations
Virtual private network (VPN) gateway and method for forwarding messages at VPN gateway
CN102694738A
Data message transmission method and device
CN106878184A
Message forwarding method and device
CN106992917A
Message processing method and device
CN112272164A
Tunnel message processing method and device
CN114697408A