Attack protection method and apparatus

Abstract

The application provides an attack protection method and device, the method comprising: receiving a first message sent by a second network device through a P2MP GRE tunnel; if there is no matched first attack prevention table item and the first message is not a Keepalive message, determining whether there is a first tunnel table item matching the home network segments of the first source address and the second source address in a locally stored branch network segment hash table; if there is no first tunnel table item, generating a second attack prevention table item, which comprises the home 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 table item; if a third message sent by the second network device according to the second message is received, deleting the second attack prevention table item from the attack prevention table, and storing the second attack prevention table item as a second tunnel table item in the branch network segment hash table.

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

[0002] A generic routing encapsulation (English: Generic Routing Encapsulation, for short: GRE) tunnel is a common virtual point-to-point connection. When the GRE tunnel is applied to an enterprise network, a plurality of GRE tunnels need to be established between a center node and each branch. When the number of branches is large, the configuration workload is huge; moreover, if a new branch is added, the configuration at the center node needs to be increased, thereby increasing the burden of network maintenance.

[0003] A point-to-multipoint (English: Point to multi-point, for short: P2MP) GRE tunnel can solve the above problems and is suitable for an enterprise network with a large number of branches. In a P2MP GRE tunnel networking, a tunnel interface of a P2MP GRE mode (hereinafter referred to as a P2MP GRE tunnel interface) is configured at the center node, and a tunnel interface of a GRE mode (hereinafter referred to as a GRE tunnel interface) is configured at the branch, so that a tunnel can be dynamically established between the center node and the plurality of branches.

[0004] Unlike the GRE tunnel interface, the P2MP GRE tunnel interface does not need to manually configure a tunnel destination address, but dynamically learns the tunnel destination address according to the received message and establishes a tunnel entry. The tunnel entry includes a tunnel destination address field (a source address in the outer header of the message), a branch network segment address field (a source address in the inner header of the message), a GRE Key field, and a last entry refresh time field.

[0005] However, the existing configuration of the P2MP GRE tunnel in the enterprise network with a large number of branches also exposes the following problems: for the GRE P2MP tunnel, there is a lack of corresponding security check. After the center node receives a message with a destination address matching the local GRE P2MP tunnel source address, a tunnel entry can be established. If an attack message is received, a large number of invalid tunnel entries will be created at the center node, thereby affecting the normal forwarding process. SUMMARY

[0006] Therefore, the present application provides an attack protection method and device to solve the problem of the lack of corresponding security check for the existing GRE P2MP tunnel.

[0007] In a first aspect, the present application provides an attack protection method, which is applied to a first network device, the first network device establishes a P2MP GRE tunnel with a second network device, and the method comprises:

[0008] receive, through the P2MP GRE tunnel, a first packet sent by the second network device, the first packet comprising a first IP header and a second IP header, the first IP header comprising a first source address, and the second IP header comprising a second source address;

[0009] if there is no first attack prevention table entry matching the first source address in the locally-stored attack prevention table and the first packet is a data packet, then determine whether there is a first tunnel table entry matching the home network segments of the first source address and the second source address in a locally-stored branch network segment hash table;

[0010] if there is also no first tunnel table entry matching the home network segments of the first source address and the second source address in the branch network segment hash table, then generate a second attack prevention table entry, the second attack prevention table entry comprising the home network segments of the first source address and the second source address;

[0011] send, according to the second attack prevention table entry, a second packet to the second network device;

[0012] if a third packet sent by the second network device according to the second packet is received, then delete the second attack prevention table entry from the attack prevention table, and store the second attack prevention table entry as a second tunnel table entry in the branch network segment hash table;

[0013] wherein the second packet is a Keepalive request packet, and the third packet is a Keepalive response packet.

[0014] In a second aspect, the present application provides an attack prevention device, the device being applied to a first network device, the first network device establishing a P2MP GRE tunnel with a second network device, the device comprising:

[0015] a receiving unit, configured to receive, through the P2MP GRE tunnel, a first packet sent by the second network device, the first packet comprising a first IP header and a second IP header, the first IP header comprising a first source address, and the second IP header comprising a second source address;

[0016] a determining unit, configured to, if there is no first attack prevention table entry matching the first source address in a locally-stored attack prevention table and the first packet is a data packet, then determine whether there is a first tunnel table entry matching the home network segments of the first source address and the second source address in a locally-stored branch network segment hash table;

[0017] The generation unit is used to generate a second anti-attack entry if there is no first tunnel entry in the branch network segment hash table that matches the home network segments of both the first source address and the second source address. The second anti-attack entry includes the home network segments of both the first source address and the second source address.

[0018] The sending unit is configured to send a second message to the second network device according to the second anti-attack entry;

[0019] The processing unit is configured to, if it receives a third message sent by the second network device according to the second message, delete the second anti-attack entry from the anti-attack table and store the second anti-attack entry as a second tunnel entry in the branch network segment hash table;

[0020] The second message is a Keepalive request message, and the third message is a Keepalive response message.

[0021] Thirdly, this application provides a network device including a processor and a machine-readable storage medium storing machine-executable instructions that can be executed by the processor, which in turn cause the processor to perform the method provided in the first aspect of this application.

[0022] Therefore, by applying the attack protection method and apparatus provided in this application, through a P2MP GRE tunnel, the first network device receives a first packet sent by the second network device. This first packet 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 attack protection entry matching the first source address in the locally stored attack protection table, and the first packet is a data packet, the first network device checks the locally stored branch network segment hash table to determine if there is a first tunnel entry matching the home network segments of both the first and second source addresses. If there is also no home network segment matching the first and second source addresses in the branch network segment hash table... If all first tunnel entries match, the first network device generates a second anti-attack entry, which includes the first source address and the network segment to which the second source address belongs. Based on the second anti-attack entry, the first network device sends a second message to the second network device. If the first network device receives a third message sent by the second network device based on the second message, it deletes the second anti-attack entry from the anti-attack table and stores it as a second tunnel entry in the branch network segment hash table. The second message is a Keepalive request message, and the third message is a Keepalive response message.

[0023] Thus, the aforementioned method provides a simple way for the P2MP GRE tunnel on the central node side to identify attack packets, thereby improving the packet forwarding performance of network devices. It also addresses the lack of corresponding security verification in existing GRE P2MP tunnels. Attached Figure Description

[0024] Figure 1 A flowchart illustrating an attack protection method provided in this application embodiment;

[0025] Figure 2 A flowchart illustrating another attack protection method provided in this application embodiment;

[0026] Figure 3 A schematic diagram illustrating the message format of the Keepalive request message and the Keepalive response message provided in the embodiments of this application;

[0027] Figure 4 This is a structural diagram of the attack protection device provided in the embodiments of this application;

[0028] Figure 5 The network device hardware structure provided in the embodiments of this application. Detailed Implementation

[0029] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0030] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the corresponding listed items.

[0031] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0032] The attack protection method provided in the embodiments of this application will be described in detail below. See also Figure 1 , Figure 1 This is a flowchart illustrating an attack protection method provided in an embodiment of this application. The method is applied to a first network device, and a P2MP GRE tunnel has been established between the first network device and a second network device. The attack protection method provided in this application embodiment may include the following steps.

[0033] Step 110: Receive a first packet sent by the second network device through the P2MP GRE tunnel. The first packet 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.

[0034] Specifically, the first network device and at least one second network device constitute an enterprise network. The first network device may be a central node within the enterprise network, and each second network device may be a branch office within the enterprise network.

[0035] The first network device is configured with a P2MP GRE mode tunnel interface (hereinafter referred to as the P2MP GRE tunnel interface), and the second network device is configured with a GRE mode tunnel interface (hereinafter referred to as the GRE tunnel interface). A P2MP GRE tunnel is established between the first network device and the second network device.

[0036] It is understood that in the embodiments of this application, the steps and processes performed by each second network device are the same, and the following description takes one second network device as an example.

[0037] The second network device wishes to communicate with the first network device. Through a P2MP GRE tunnel, the second network device sends a first message to the first network device.

[0038] The first message includes a first Internet Protocol (IP) header (i.e., the first outer IP header) and a second IP header (i.e., the 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 packet and obtains the first destination address from it.

[0040] Step 120: If there is no first anti-attack entry in the locally stored anti-attack table that matches the first source address and the first packet is not a Keepalive packet, then determine in the locally stored branch network segment hash table whether there is a first tunnel entry that matches the network segment to which both the first source address and the second source address belong.

[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 entry in the locally stored anti-attack table that matches the first source address.

[0042] If the first anti-attack entry does not exist in the anti-attack table, then based on the first destination address, the first network device again determines whether there is a first UpTunnel entry in the locally stored valid tunnel (Up Tunnel) table that matches the first destination address.

[0043] If the Up Tunnel table contains the first Up Tunnel entry, the first network device will again obtain the GRE key from the GRE header included in the first message.

[0044] The first network device decapsulates the first packet to obtain the inner packet. Using the inner packet, the first network device determines whether the first packet is a Keepalive packet. If the source / destination address in the first inner IP header is the opposite of the source / destination address in the first outer IP header, then the first packet is a Keepalive packet; otherwise, if the source / destination address in the first inner IP header is different from the source / destination address in the first outer IP header, then the first packet is not a Keepalive packet.

[0045] In this embodiment of the application, if there is no first anti-attack entry and the first message is not a Keepalive message, the first network device calculates the network segment to which the second source address belongs.

[0046] The first network device checks in its locally stored branch network segment hash table whether a first tunnel entry exists that matches the home network segments of both the first source address and the second source address. If no first tunnel entry exists, the first network device proceeds to step 130.

[0047] Optionally, in this embodiment of the application, if there is a first anti-attack entry in the anti-attack table, the first network device determines that the first packet is an attack packet, discards the first packet, and ends the current process.

[0048] Optionally, in this embodiment of the application, if there is no first Up Tunnel entry in the Up Tunnel table, the first network device ends the current process.

[0049] Optionally, in this embodiment, if no first anti-attack entry exists and the first message is a Keepalive message, the first network device performs a secondary forwarding based on the second destination address included in the inner message. It is understood that the above-mentioned 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 network segments to which the first source address and the second source address belong, then generate a second anti-attack entry, which includes the network segments to which the first source address and the second source address belong.

[0051] Specifically, according to the description of step 120, if the first tunnel entry does not exist, the first network device generates a second anti-attack entry, which includes the first source address and the network segment to which the second source address belongs.

[0052] Optionally, in this embodiment of the 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] The tunnel destination address field stores the first source address of any received data packet; the branch network address field stores the network segment to which the second source address of any data packet belongs; the GRE Key field stores the GRE Key value (range 0 to 4294967295) in the GRE header of any data packet; and the last table entry refresh time field stores the current time of processing the anti-attack table entry.

[0054] For example, the anti-attack entries are shown in Table 1 below.

[0055] Table 1 Defense Items

[0056] Tunnel Destination Address Subnet Address GRE Key Last Entry Refresh Time 11.1.1.1 10.1.1.0 / 24 123 14:00

[0057] Optionally, in this embodiment, if a first tunnel entry exists, the first network device updates the last entry refresh time field included in the first tunnel entry. The first network device stores the current time in the last entry refresh time field. The first network device performs secondary forwarding based on the second destination address included in the inner packet. It is understood that the above-mentioned 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 anti-attack entry;

[0059] Specifically, according to the description in step 130, after the first network device generates the second anti-attack entry, it generates a second message based on the second anti-attack entry. The first network device then sends the second message to the second network device through the P2MP GRE tunnel.

[0060] Optionally, in this embodiment, 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 can also be referred to as the first outer IP header, and the fourth IP header can also be referred to as the 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] The third IP header includes a source address field that stores the source address of the locally configured P2MP GRE tunnel, and a destination address field that stores the address stored in the tunnel destination address field. The fourth IP header includes a source address field that stores the address stored in the tunnel destination address field, and a destination address field that stores the source address of the locally configured P2MP GRE tunnel.

[0062] The second message mentioned above can be a protocol message, such as a Keepalive request message.

[0063] Step 150: If a third message is received from the second network device based on the second message, the second anti-attack entry is deleted from the anti-attack table, and the second anti-attack entry is stored as a second tunnel entry in the branch network segment hash table.

[0064] Specifically, according to the description in step 140, after the first network device sends the second message to the second network device, it internally starts a timer (the preset time can be 3 seconds). Within the preset time, the first network device determines whether it has received the third message sent by the second network device based on the second message.

[0065] If a third message is received, the first network device will delete the second anti-attack entry from the anti-attack table and store the second anti-attack entry as the second tunnel entry in the branch network segment hash table.

[0066] Optionally, in this embodiment of the application, the third message includes a fourth IP header and a second GRE header.

[0067] The fourth IP header includes a source address field that stores the address stored in the tunnel destination address field, and a destination address field that stores the source address of the locally configured P2MP GRE tunnel.

[0068] In this embodiment, after receiving the second packet, the second network device obtains the third IP header and the destination address field from it. The address stored in the destination address field is used to determine that the address is the source address of the locally configured P2MP GRE tunnel. The second network device then decapsulates the second packet, that is, it removes the third IP header and the first GRE header from the second packet to obtain the third packet.

[0069] The second network device sends a third message to the first network device through the P2MP GRE tunnel.

[0070] The aforementioned third message can be a protocol message, such as a Keepalive response message.

[0071] In this embodiment of the application, the first network device uses protocol messages to identify whether the second anti-attack entry was created by an attack message.

[0072] Understandably, if the first network device receives a Keepalive response message from the second network device within a preset time, it determines that the second anti-attack entry was not created by an attack message. The first network device then removes the second anti-attack entry from the anti-attack table and adds it to the official branch network hash table.

[0073] Optionally, if no third message is received, the first network device terminates the current process.

[0074] In this embodiment, before generating a tunnel entry, the first network device first generates a corresponding anti-attack entry and adds it to the anti-attack table. By actively triggering the sending of a Keepalive message, it identifies whether the anti-attack entry was created by an attack message.

[0075] If a Keepalive response message is received from the second network device, it is determined that the anti-attack entry was 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 it to the branch network segment hash table.

[0076] If no Keepalive response message is received from the second network device, it is determined that the anti-attack entry was created by an attack message. In this case, the first network device continues to store the anti-attack entry in the anti-attack table. During subsequent data packet reception, if the destination address of a packet matches an anti-attack entry, the first network device determines that it has been attacked and discards the attack message; simultaneously, the first network device updates the last refresh time of the matching anti-attack entry to reflect the first network device's current time.

[0077] In this embodiment, the anti-attack table can be configured with a maximum size and a timeout aging period for each entry according to the product capabilities of the first network device. If the first network device receives a large number of attack packets, causing the number of anti-attack entries to exceed the maximum size, the first network device will age and delete the anti-attack entry with the earliest time indicated by the last entry refresh time field. If the first network device does not receive any attack packets within a certain period, the first network device can automatically age the anti-attack entries using a timer (e.g., 1 minute).

[0078] Therefore, by applying the attack protection method and apparatus provided in this application, through a P2MP GRE tunnel, the first network device receives a first packet sent by the second network device. This first packet 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 entry matching the first source address in the locally stored anti-attack table and the first packet is not a Keepalive packet, the first network device checks its locally stored branch network segment hash table to determine if there is a first tunnel entry matching the home network segments of both the first and second source addresses. If there is also no entry matching the home network segments of both the first and second source addresses in the branch network segment hash table... If the first tunnel entry matches the home network segment, the first network device generates a second anti-attack entry, which includes the home network segment of the first source address and the second source address. Based on the second anti-attack entry, the first network device sends a second message to the second network device. If the first network device receives a third message sent by the second network device based on the second message, it deletes the second anti-attack entry from the anti-attack table and stores it as a second tunnel entry in the branch network segment hash table. The second message is a Keepalive request message, and the third message is a Keepalive response message.

[0079] Thus, the aforementioned method provides a simple way for the P2MP GRE tunnel on the central node side to identify attack packets, thereby improving the packet forwarding performance of network devices. It also addresses the lack of corresponding security verification in existing GRE P2MP tunnels.

[0080] The attack protection method provided in the embodiments of this application will be described in detail below. See also Figure 2 , Figure 2 A flowchart illustrating another attack protection method provided in this application embodiment. This other attack protection method may include the following steps.

[0081] Step 200: Through the P2MP GRE tunnel, the first network device receives the first message sent by the second network device.

[0082] Specifically, the first network device and the second network device constitute an enterprise network. The first network device may be a central node within the enterprise network, and the second network device may be a branch office within the enterprise network.

[0083] The first network device is configured with a P2MP GRE mode tunnel interface (hereinafter referred to as the P2MP GRE tunnel interface), and the second network device is configured with a GRE mode tunnel interface (hereinafter referred to as the GRE tunnel interface). A P2MP GRE tunnel is established between the first network device and the second network device.

[0084] The second network device wishes to communicate with the first network device. Through a P2MP GRE tunnel, the second network device sends a first message to the first network device.

[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, while the inner IP header includes a second source address and a second destination address. Between the outer and inner IP headers is a GRE header, which includes a GRE Key field.

[0086] Step 201: The first network device sends the first message to the 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 anti-attack entry in the locally stored anti-attack table that matches the first source address.

[0089] Specifically, if the first anti-attack entry exists in the anti-attack table, the first network device executes step 203; if the first anti-attack entry does not exist in the anti-attack table, the first network device executes step 213.

[0090] Step 203: If there is no first anti-attack entry in the anti-attack table that matches the first source address, the first network device determines whether there is a first Up Tunnel entry in the locally stored Up Tunnel table that matches the first destination address.

[0091] Specifically, according to the description of step 202, if there is a first anti-attack entry in the anti-attack table, the first network device continues to determine whether there is a first Up Tunnel entry in the locally stored Up Tunnel table that matches the first destination address.

[0092] If the UpTunnel table contains a first UpTunnel entry, the first network device executes step 204; if the UpTunnel table does not contain a first UpTunnel entry, the first network device executes step 212.

[0093] The first anti-attack item mentioned above is shown in Table 1 above, and will not be repeated here.

[0094] In this embodiment, the anti-attack table can be stored locally in the form of a hash table or a Radix tree. The hash table or Radix tree includes multiple nodes, each storing a hash key value and at least one anti-attack entry. 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, matching nodes are found based on the branch network segment address; then, each anti-attack entry within the node is searched based on 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 Up Tunnel table contains the first Up Tunnel entry, the first network device performs decapsulation processing on the first packet.

[0098] Specifically, according to the description of step 203, if there is a first Up Tunnel table entry in the Up Tunnel table, the first network device will again obtain the GRE Key from the GRE header included in the first message.

[0099] The first network device strips the outer IP header and GRE header from the first packet to obtain the inner packet. That is, after the outer IP header and GRE header are stripped from the first packet, the inner IP header is exposed.

[0100] Step 205: The first network device determines whether the first packet is a Keepalive packet.

[0101] Specifically, the first network device determines whether the first packet is a Keepalive packet based on the inner packet. If the source / destination address included in the inner IP header is the opposite of the source / destination address included in the outer IP header, then the first packet is a Keepalive packet, and the first network device executes step 215; if the source / destination address included in the inner IP header is different from the source / destination address included in the outer IP header, then the first packet is not a Keepalive packet, 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, then the network segment to which the second source address belongs is 10.1.1.0 / 24.

[0105] Step 207: Based on the first source address and the second source address, the first network device searches the locally stored branch network segment hash table.

[0106] Specifically, the branch network segment hash table contains at least one tunnel entry. The structure of each tunnel entry is the same as that 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] The tunnel destination address field stores the first source address (i.e., the source address included in the outer IP header) of any received data packet; the branch network segment address field stores the network segment to which the second source address (i.e., the network segment to which the source address included in the inner IP header) belongs; the GRE Key field stores the GRE Key value (ranging from 0 to 4294967295) in the GRE header of any data packet; and the last table entry refresh time field stores the current time of 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 this embodiment, the branch network segment hash table can be stored locally in the form of a hash table or a Radix tree. Each hash table or Radix tree includes multiple nodes, and each node stores a hash key value and at least one anti-attack entry. 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, matching nodes are found based on the branch network segment address; then, each tunnel entry within the node is searched based on the first source address.

[0111] Step 208: The first network device determines whether there is a first tunnel entry that matches the network segment to which both the first source address and the second source address belong.

[0112] Specifically, according to the description of step 207, the first network device determines in its locally stored branch network segment hash table whether there is a first tunnel entry that matches the network segment to which both the first source address and the second source address belong.

[0113] If no first tunnel entry exists, the first network device executes step 209; if a 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 network segments to which both the first source address and the second source address belong, then the first network device generates a second anti-attack entry and sends a Keepalive request message to the second network device according to the second anti-attack 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 anti-attack entry, which includes the first source address and the network segment to which the second source address belongs.

[0116] The second anti-attack table is shown in Table 1 above and will not be repeated here.

[0117] After generating the second anti-attack entry, the first network device generates a Keepalive message based on the second anti-attack entry. The first network device then sends the Keepalive message to the second network device via a P2MP GRE tunnel.

[0118] like Figure 3 As shown, Figure 3 This diagram illustrates the message formats of the Keepalive request message and Keepalive response message provided in embodiments of this application. Figure 3In a Keepalive request message, the outer IP header, outer GRE header, inner IP header, and inner GRE header are included. The length of a Keepalive request message is 0.

[0119] The outer IP header stores the source address of the locally configured P2MP GRE tunnel in the source address field and the tunnel destination address in the destination address field. The inner IP header stores the source address of the tunnel destination address in the source address field and the tunnel destination address in the destination address field.

[0120] Step 210: The first network device determines whether it has received a Keepalive response message sent by the second network device based on the Keepalive request message.

[0121] Specifically, after the first network device sends a Keepalive request message to the second network device, it internally starts a timer (the preset time can be 3 seconds). Within the preset time, the first network device determines whether it has received a Keepalive response message sent by the second network device based on the Keepalive message.

[0122] If a Keepalive response message is received, the first network device executes step 211; if no Keepalive response message is 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 anti-attack entry from the anti-attack table and stores the second anti-attack entry as the second tunnel entry in the branch network segment hash table.

[0124] Specifically, if a Keepalive response message is received, the first network device deletes the second anti-attack entry from the anti-attack table and stores the second anti-attack entry as the second tunnel entry in the branch network segment hash table.

[0125] like Figure 3 As shown, in Figure 3 In the Keepalive response message, there is an inner IP header and an inner GRE header. The message length of the Keepalive response message is 0.

[0126] The inner IP header includes a source address field that stores the address stored in the tunnel destination address field, and a destination address field that stores the source address of the locally configured P2MP GRE tunnel.

[0127] In this embodiment, after receiving the Keepalive request message, the second network device extracts the outer IP header and the destination address field from it. Using the address stored in the destination address field, it determines that the address is the source address of the locally configured P2MP GRE tunnel. The second network device then decapsulates the Keepalive request message, that is, it removes the outer IP header and outer GRE header from the Keepalive request message to obtain 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 this embodiment of the application, the first network device uses Keepalive messages to identify whether the second anti-attack entry was created by an attack message.

[0130] Understandably, if the first network device receives a Keepalive response message from the second network device within a preset time, it determines that the second anti-attack entry was not created by an attack message. The first network device then removes the second anti-attack entry from the anti-attack table and adds it to the official branch network 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 anti-attack entry exists in the anti-attack table, the first network device discards the first packet.

[0134] Specifically, if the first attack prevention table contains a first attack prevention table entry, the first network device determines that the first packet is an attack packet. The first network device discards the first packet and executes step 212.

[0135] Step 214: If there is a first tunnel entry in the branch network segment hash table that matches the network segments to which both the first source address and the second source address belong, then the first network device updates the first tunnel entry.

[0136] Specifically, according to the description of step 208, if a 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 of the first tunnel entry to the current time.

[0137] Understandably, the updated first tunnel entry will continue to be stored in the branch network hash table. Since the address stored in the branch network address field of the first tunnel entry has not been updated, the node stored in the updated first tunnel entry has not changed.

[0138] Step 215: Forward the first packet after decapsulation.

[0139] Specifically, after the first network device updates the first tunnel entry or the first packet is a Keepalive packet, the first network device obtains the second destination address from the inner IP header. Based on the second destination address, the inner packet is forwarded a second time.

[0140] It is understandable 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, embodiments of this application also provide an attack protection device corresponding to the attack protection method. See also Figure 4 , Figure 4 The attack protection device provided in this application embodiment is applied to a first network device, which establishes a P2MP GRE tunnel with a second network device. The device includes:

[0142] The receiving unit 410 is configured to receive a first message sent by the second network device through the P2MP GRE tunnel. 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.

[0143] The judgment unit 420 is used to determine whether there is a first tunnel entry that matches both the first source address and the second source address in the local branch network segment hash table if there is no first anti-attack table entry that matches the first source address and the first packet is not a Keepalive packet.

[0144] The generation unit 430 is used to generate a second anti-attack entry if there is no first tunnel entry in the branch network segment hash table that matches the home network segments of both the first source address and the second source address. The second anti-attack entry includes the home network segments of both the first source address and the second source address.

[0145] The sending unit 440 is configured to send a second message to the second network device according to the second anti-attack entry;

[0146] The processing unit 450 is configured to, if it receives a third message sent by the second network device according to the second message, delete the second anti-attack entry from the anti-attack table and store the second anti-attack entry as a second tunnel entry in the branch network segment hash table;

[0147] The second message is a Keepalive request message, and the third message is a Keepalive response message.

[0148] Optionally, the device further includes:

[0149] A discarding unit (not shown in the figure) is used to discard the first packet if the first anti-attack table entry that matches the first source address exists in the anti-attack table.

[0150] Optionally, the anti-attack entry includes a tunnel destination address field, a branch network 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 packet; the branch network segment address field stores the network segment to which the second source address included in any data packet belongs; the GRE Key field stores the GRE Key value in the GRE header included in any data packet; and the last entry refresh time field stores the current time of processing the anti-attack 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 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.

[0154] The source address field in the fourth IP header stores the address stored in the destination address field of the tunnel, and the destination address field in the fourth IP header stores the source address of the locally configured 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 source address of the locally configured P2MP GRE tunnel.

[0157] The third message is sent by the second network device after the third IP header and the first GRE header are stripped from the second message.

[0158] Therefore, by applying the attack protection device provided in this application, through a P2MP GRE tunnel, the first network device receives a first packet sent by the second network device. This first packet 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 entry matching the first source address in the locally stored anti-attack table and the first packet is not a Keepalive packet, the first network device checks its locally stored branch network segment hash table to determine if there is a first tunnel entry matching the home network segments of both the first and second source addresses. If there is also no entry matching the home network segments of both the first and second source addresses in the branch network segment hash table... If the first tunnel entry matches the home network segment, the first network device generates a second anti-attack entry, which includes the home network segment of the first source address and the second source address. Based on the second anti-attack entry, the first network device sends a second message to the second network device. If the first network device receives a third message sent by the second network device based on the second message, it deletes the second anti-attack entry from the anti-attack table and stores it as a second tunnel entry in the branch network segment hash table. The second message is a Keepalive request message, and the third message is a Keepalive response message.

[0159] Thus, the aforementioned method provides a simple way for the P2MP GRE tunnel on the central node side to identify attack packets, thereby improving the packet forwarding performance of network devices. It also addresses the lack of corresponding security verification in existing GRE P2MP tunnels.

[0160] Based on the same inventive concept, embodiments of this application also provide a network device, such as... Figure 5 As shown, the system 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. The processor 510 is prompted by the machine-executable instructions to execute the attack protection method provided in the embodiments of this application. (The foregoing...) Figure 4 The attack protection device shown can be adopted as follows: Figure 5 The hardware structure of the network device shown is implemented.

[0161] The aforementioned computer-readable storage medium 530 may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the computer-readable storage medium 530 may also be at least one storage device located remotely from the aforementioned processor 510.

[0162] The processor 510 mentioned above can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can 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 this embodiment, the processor 510 reads the machine-executable instructions stored in the machine-readable storage medium 530, and is prompted by the machine-executable instructions to enable the processor 510 itself and the transceiver 520 to execute the attack protection method described in the aforementioned embodiment.

[0164] In addition, this application provides a machine-readable storage medium 530 that stores machine-executable instructions. When called and executed by the processor 510, the machine-executable instructions cause the processor 510 itself and the transceiver 520 to execute the attack protection method described in the aforementioned application.

[0165] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0166] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0167] As for the attack protection device and machine-readable storage medium embodiments, since the methods involved are basically similar to the aforementioned method embodiments, the description is relatively simple, and relevant details can be found in the descriptions of the method embodiments.

[0168] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. An attack protection method characterized by, 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 comprises: receiving a first packet sent by the second network device through the P2MP GRE tunnel, the first packet comprising a first IP header and a second IP header, the first IP header comprising a first source address, and the second IP header comprising a second source address; if there is no first attack prevention table item matching the first source address in a locally stored attack prevention table and the first packet is not a Keepalive packet, determining whether there is a first tunnel table item matching the first source address and a home network segment of the second source address in a locally stored branch network segment hash table; if there is also no first tunnel table item matching the first source address and the home network segment of the second source address in the branch network segment hash table, generating a second attack prevention table item, the second attack prevention table item comprising the home network segment of the second source address and the first source address; sending a second packet to the second network device according to the second attack prevention table item; if a third packet sent by the second network device according to the second packet is received, deleting the second attack prevention table item from the attack prevention table and storing the second attack prevention table item as a second tunnel table item in the branch network segment hash table; wherein the second packet is a Keepalive request packet, and the third packet is a Keepalive response packet.

2. The method of claim 1, wherein, The method further comprises: if the first attack prevention table item matching the first source address exists in the attack prevention table, discarding the first packet.

3. The method according to any of claims 1 or 2, characterized in that, An attack prevention table item comprises a tunnel destination address field, a branch network segment address field, a GRE Key field and a last table item refresh time field; the first source address included in any received data packet is stored in the tunnel destination address field, the home network segment of the second source address included in the any data packet is stored in the branch network segment address field, the GRE Key value in the GRE header included in the any data packet is stored in the GRE Key field, and the current time for processing the attack prevention table item is stored in the last table item refresh time field.

4. The method of claim 3, wherein, The second packet comprises 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 source address of the P2MP GRE tunnel configured locally, 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 P2MP GRE tunnel configured locally.

5. The method of claim 4, wherein, The third packet comprises the fourth IP header and the second GRE header; The source address field in the fourth IP header stores the address in the tunnel destination address field, and the destination address field in the fourth IP header stores the source address of the P2MP GRE tunnel configured locally; The third message is sent by the second network device after stripping the third IP header and the first GRE header from the second message.

6. An attack protection device characterized by comprising: The device is applied to a first network device that establishes a P2MP GRE tunnel with a second network device, and the device comprises: a receiving unit configured to receive a first message sent by the second network device through the P2MP GRE tunnel, the first message comprising a first IP header and a second IP header, the first IP header comprising a first source address, and the second IP header comprising a second source address; a judging unit configured to, if there is no first attack prevention table item matching the first source address in a locally stored attack prevention table and the first message is not a Keepalive message, judge whether there is a first tunnel table item matching the first source address and a home network segment of the second source address in a locally stored branch network segment hash table; a generating unit configured to, if there is also no first tunnel table item matching the first source address and the home network segment of the second source address in the branch network segment hash table, generate a second attack prevention table item, the second attack prevention table item comprising the home network segment of the second source address and the first source address; a sending unit configured to send a second message to the second network device according to the second attack prevention table item; a processing unit configured to, if a third message sent by the second network device according to the second message is received, delete the second attack prevention table item from the attack prevention table, and store the second attack prevention table item in the branch network segment hash table as a second tunnel table item; The second message is a Keepalive request message, and the third message is a Keepalive response message.

7. The apparatus of claim 6, wherein, The device further comprises: a discarding unit configured to, if the first attack prevention table item matching the first source address exists in the attack prevention table, discard the first message.

8. The device of any one of claims 6 or 7, wherein, An attack prevention table item comprises a tunnel destination address field, a branch network segment address field, a GRE Key field, and a last table item refresh time field; The tunnel destination address field stores a first source address included in any received data message, the branch network segment address field stores a home network segment of a second source address included in the any data message, the GRE Key field stores a GRE Key value in a GRE header included in the any data message, and the last table item refresh time field stores a current time of processing the attack prevention table item.

9. The apparatus of claim 8, wherein, The second message comprises a third IP header, a first GRE header, a fourth IP header, and a second GRE header; The source address field in the third IP header stores the source address of the P2MP GRE tunnel configured locally, and the destination address field in the third IP header stores the address stored in the tunnel destination address field; The source address field in the fourth IP header stores the address stored in the tunnel destination address field, and the destination address field in the fourth IP header stores the source address of the P2MP GRE tunnel configured locally.

10. The apparatus of claim 9, wherein, The third message comprises the fourth IP header and the second GRE header; The source address field in the fourth IP header stores the address stored in the tunnel destination address field, and the destination address field in the fourth IP header stores the source address of the P2MP GRE tunnel configured locally. The third message is sent by the second network device after stripping the third IP header and the first GRE header from the second message.

Images