Method and apparatus for preventing network attacks

Abstract

The present specification provides a method and device for preventing network attacks, applied to a verification node in a blockchain network, the method comprising: sending a verification request to a to-be-verified node in the blockchain network, the verification request comprising a block height of a to-be-verified block selected by the verification node from a locally maintained block; receiving a verification response sent by the to-be-verified node in response to the verification request, the verification response comprising first block information; determining that the to-be-verified node fails verification in a case where the first block information fails to match second block information corresponding to the to-be-verified block; and disconnecting from the to-be-verified node in a case where a first number of times of determining that the to-be-verified node fails verification exceeds a first preset threshold.

Description

TECHNICAL FIELD

[0001] The embodiment of the present specification belongs to the technical field of network security, and particularly relates to a method and device for preventing network attacks. BACKGROUND

[0002] At present, attack events on communication networks are emerging in an endless stream, and attack methods are also different. Among them, the number of attack cases on P2P networks is relatively common. For example, for a blockchain network, an attacker can design an attack algorithm according to the characteristics of the underlying P2P network corresponding to the blockchain network, thereby achieving an attack on the blockchain network. SUMMARY

[0003] The purpose of the present application is to provide a method and device for preventing network attacks.

[0004] According to a first aspect of one or more embodiments of the present specification, a method for preventing network attacks is provided, applied to a verification node in a blockchain network, comprising:

[0005] sending a verification request to a to-be-verified node in the blockchain network, the verification request comprising a block height of a to-be-verified block selected by the verification node from a locally maintained block;

[0006] receiving a verification response sent by the to-be-verified node in response to the verification request, the verification response comprising first block information;

[0007] determining that the to-be-verified node fails verification in the case that the first block information fails to match second block information corresponding to the to-be-verified block;

[0008] disconnecting from the to-be-verified node in the case that a first number of times of determining that the to-be-verified node fails verification exceeds a first preset threshold.

[0009] According to a second aspect of one or more embodiments of the present specification, a device for preventing network attacks is provided, applied to a verification node in a blockchain network, comprising:

[0010] a request sending unit configured to send a verification request to a to-be-verified node in the blockchain network, the verification request comprising a block height of a to-be-verified block selected by the verification node from a locally maintained block;

[0011] a response receiving unit configured to receive a verification response sent by the to-be-verified node in response to the verification request, the verification response comprising first block information;

[0012] a verification unit configured to determine that the to-be-verified node fails verification in the case that the first block information fails to match second block information corresponding to the to-be-verified block;

[0013] A connection disconnecting unit is configured to disconnect from the to-be-verified node in a case where a first number of verification failures of the to-be-verified node is determined to exceed a first preset threshold.

[0014] According to a third aspect of one or more embodiments of the present specification, an electronic device is provided, comprising:

[0015] a processor;

[0016] a memory for storing processor-executable instructions;

[0017] The processor implements the method according to the first aspect by running the executable instructions.

[0018] According to a fourth aspect of one or more embodiments of the present specification, a computer-readable storage medium is provided, which stores computer instructions that are executed by a processor to implement the steps of the method according to the first aspect.

[0019] Based on the foregoing embodiments of the present specification, a verification mechanism is provided to ensure that each node in the blockchain network maintains the same set of blockchain account books. The to-be-verified node needs to provide correct block information based on the block height in the verification request to the verification node, otherwise the to-be-verified node will be regarded as a faulty node or an attack party of abnormal attack by the verification node, that is, the to-be-verified node actually does not maintain the same set of blockchain account books with the verification node, but reuses the communication module of the same underlying P2P network, resulting in that the nodes actually in different blockchain networks can access in violation of rules. At this time, the verification node disconnects from the to-be-verified node regarded as a faulty node or an attack party, so as to timely eliminate the risk of threatening the normal operation of the system or the network security. In addition, even if the attack party as the to-be-verified node can provide correct block information through other means to evade forced disconnection, the foregoing embodiments of the present specification can objectively increase the cost of the attack party to maintain the connection with the blockchain network, thereby indirectly improving the ability of the blockchain network to prevent network attacks by increasing the attack cost. BRIEF DESCRIPTION OF DRAWINGS

[0020] In order to more clearly illustrate the technical solutions of the embodiments of the present specification, the drawings needed in the embodiment description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments described in the present specification, and those skilled in the art can also obtain other drawings according to these drawings without creative labor.

[0021] Figure 1 is a schematic diagram of a blockchain network provided by an exemplary embodiment.

[0022] Figure 2 FIG. 1 is a flowchart of a method for preventing network attacks according to an example embodiment.

[0023] Figure 3 FIG. 2 is a structural diagram of a device according to an example embodiment.

[0024] Figure 4 FIG. 3 is a block diagram of an apparatus for preventing network attacks according to an example embodiment. DETAILED DESCRIPTION

[0025] In order to better understand the technical solutions in the specification, the technical solutions in the specification will be clearly and completely described below in conjunction with the drawings in the specification. Obviously, the described embodiments are only part of the embodiments of the specification, rather than all the embodiments. Based on the embodiments in the specification, all other embodiments obtained by those skilled in the art without creative labor should fall within the scope of protection of the specification.

[0026] A P2P (Peer to Peer) network, also known as a peer-to-peer network, is a distributed network different from a C / S (Client / Server) mode. In the P2P network, all nodes are in an equal position with each other, and each node can act as a client and also provide resources and services to other nodes as a server. For example, a blockchain network is a typical P2P network, and the P2P network involved in the embodiments of the specification can be a blockchain network, and the nodes included in the P2P network are all blockchain nodes in the blockchain network.

[0027] Figure 1 FIG. 1 is a flowchart of a method for preventing network attacks according to an example embodiment. Figure 1As shown, there are 5 nodes in the blockchain network, including node A, node B, node C, node D and node E. The 5 nodes are not in a full connection relationship, for example, node A is only connected with node B, node C and node D, and is not connected with node E. Each node locally maintains an independent node list, which records the node information of other nodes in the same blockchain network connected with the node. Therefore, the node list is also called a neighbor table. For example, the node list maintained by node A records the node information of node B, node C and node D. In addition, from the functional point of view, the node list can also be used as a routing table to guide message transmission. In the embodiments of the present specification, the node information of any node can include the node identifier, network address (such as IP address, port number, etc.) and / or identity information (such as node public key) of the node, which is not limited in the present specification. The connection involved in the embodiments of the present specification refers to network connection, such as TCP or TLS connection at the session layer, which is not limited in the embodiments of the present specification. It should be noted that the node information maintained in the node list maintained by any node corresponds to a node that does not necessarily have a physical direct connection with the any node, that is, other nodes connected with the any node may have a multi-hop relationship with the any node.

[0028] In the field of blockchain technology, due to the phenomenon of code reuse of different blockchain networks, the same P2P network may be used as the underlying communication basis, which eventually leads to the occurrence of metamorphic attacks. Metamorphic attack is a network attack, also known as address pollution attack, which refers to an attack method of inducing nodes in different blockchain networks to discover and connect with each other and invade each other. If the attacker performs metamorphic attack, it is possible to cause the nodes in different blockchain networks to be intertwined with each other, affect the communication and routing between the nodes in the respective blockchain networks, and further affect the security of transaction execution and block consensus, so that the attacker has the opportunity to perform other attacks, such as DDoS (Distributed Denial of Service) attack, network splitting attack, etc.

[0029] In normal circumstances, a P2P network will only interface with one blockchain network, i.e., the nodes in the P2P network will only maintain one set of blockchain ledger and only provide communication services for the nodes maintaining the set of blockchain ledger. The essence of the heterogeneous attack is that the same P2P network provides communication services for multiple blockchain networks, i.e., in addition to interfacing with the corresponding dedicated blockchain network, the P2P network also mistakenly joins some nodes from other blockchain networks due to code reuse, which is ultimately reflected in the fact that the nodes in the blockchain network may maintain different blockchain ledgers (because these nodes do not belong to the same blockchain network in the first place). To address the above problem, the embodiments of the present specification propose a method for preventing heterogeneous attacks, which initiates a verification request for verifying whether the nodes in the blockchain network maintain the same set of blockchain ledger by the verification node in the blockchain network to the to-be-verified node in the blockchain network, and disconnects from the to-be-verified node if the number of verification failures reaches a preset threshold, thereby ensuring that the nodes in the blockchain network belong to the same blockchain network and reducing the possibility of encountering heterogeneous attacks.

[0030] The node in the blockchain network that actively verifies whether other nodes maintain the same set of blockchain ledger is called a verification node, and the node in the blockchain network that is verified is called a to-be-verified node. In the embodiments of the present specification, the verification node can be any node that has joined the blockchain network, and the verification node usually needs to ensure that it is trustworthy and open source. In order to ensure that the verification node has a high probability of maintaining a correct blockchain ledger (to avoid the phenomenon that the verification node itself is a node from other blockchain networks that has mistakenly joined the blockchain network), the initial node when the blockchain network is initially established can be used as the verification node, or the communication backbone node in the blockchain network (which usually has more connections with other nodes in the blockchain network and is usually considered as a backbone node, and has a relatively high probability of maintaining a correct blockchain ledger) can be used as the verification node. For example, Figure 1 nodeA can send a verification request to nodeB to which a connection has been established to verify whether nodeB maintains the same set of blockchain ledger, where nodeA is the verification node and nodeB is the to-be-verified node.

[0031] Please refer to Figure 2 , Figure 2 is a flowchart of a method for preventing network attacks provided by an exemplary embodiment. As shown in Figure 2 , the method is applied to a verification node in a blockchain network and can include the following steps 202-208.

[0032] Step 202: sending a verification request to a to-be-verified node in the blockchain network, the verification request comprising a block height of a to-be-verified block selected by the verification node from a locally maintained block.

[0033] After determining that the verification node needs to send a verification request to the to-be-verified node, the verification node first needs to determine a block height to be carried in the verification request and used as a basis for the to-be-verified node to obtain first block information. Specifically, the verification node can select a block from the locally maintained blockchain ledger as the to-be-verified block, and then carry the block height of the to-be-verified block in the verification request. In the embodiments of the present specification, the to-be-verified block is obtained by the verification node from the locally maintained block according to a preset selection rule or randomly. When the to-be-verified block is randomly selected by the verification node from the blockchain ledger maintained by itself, the randomness of the verification task can be maximized, and the to-be-verified node can be prevented from preparing block information of the corresponding block height in advance instead of obtaining first block information temporarily.

[0034] In the embodiments of the present specification, the sending of the verification request to the to-be-verified node in the blockchain network comprises periodically sending the verification request to the to-be-verified node in the blockchain network. In the embodiments of the present specification, any node in the blockchain network can act as a verification node to send a verification request to other nodes, and the verification node can also send a verification request to multiple to-be-verified nodes at the same time. In addition, for each to-be-verified node, a verification request can also be periodically sent to the to-be-verified node. When a verification request is initiated to different to-be-verified nodes or a verification request is periodically sent, since the corresponding to-be-verified block needs to be selected again each time a verification request is generated, the block height carried in each verification request is not necessarily the same. When the process of verifying whether to maintain the same blockchain ledger is a common and continuous behavior in the blockchain network, it can continuously ensure that the nodes in the blockchain network maintain the same blockchain ledger and belong to the same blockchain network, thereby further increasing the ability of the entire blockchain network to resist system failures (since the reason for the verification failure can also be that the to-be-detected node is a faulty node) and prevent abnormal attacks.

[0035] Step 204: receiving a verification response sent by the to-be-verified node in response to the verification request, the verification response comprising first block information.

[0036] The to-be-verified node, after receiving the verification request, will respond to the verification request and obtain the corresponding block height therefrom, and will locally look up the first block corresponding to the block height in the blockchain ledger maintained by the to-be-verified node, while determining the first block information corresponding to the first block, and will send the verification response carrying the first block information to the verification node for subsequent verification by the verification node. In the embodiments of the present specification, the first block information can include the first block itself or a hash value corresponding to the first block.

[0037] At the same time, in order to prove that the first block information obtained by the to-be-verified node is obtained by the to-be-verified node itself by querying the blockchain ledger, the corresponding identity proof needs to be provided to the verification node for proving that the first block information is obtained by the to-be-verified node. Specifically, the to-be-verified node, after obtaining the first block information, will also generate a corresponding signature for the first block information, which is obtained by encrypting the first block information using the node private key of the to-be-verified node held by the to-be-verified node.

[0038] Finally, the to-be-verified node will send the first block information obtained by the to-be-verified node and the signature generated for the first block information to the verification node for verification by the verification node. Of course, the to-be-verified node can also send the node public key of the to-be-verified node to the verification node at the same time.

[0039] Step 206: determining that the to-be-verified node fails to verify in the case that the first block information fails to match the second block information corresponding to the to-be-verified block.

[0040] After receiving the verification response sent by the to-be-verified node, the verification node will obtain the first block information from the verification response. In addition, the verification node also needs to obtain the to-be-verified block selected previously from the blockchain ledger locally maintained by the verification node, while determining the second block information corresponding to the to-be-verified block, which includes the to-be-verified block or a hash value corresponding to the to-be-verified block. For example, when the first block information is the first block, the second block information is the second block, and when the first block information is a hash value corresponding to the first block, the second block information is a hash value corresponding to the second block. The process of obtaining the second block information by the verification node can occur at any time point between the selection of the to-be-selected block by the verification node and the matching of the first block information with the second block information by the verification node.

[0041] After obtaining the first block information and the second block information, the verification node can match the first block information and the second block information to determine whether they are consistent. If the two are consistent, it is determined that the matching is successful. If the two are inconsistent, it is determined that the matching fails. If the to-be-verified node and the verification node maintain the same block chain ledger, the blocks obtained by them at the same block height should be the same, and the corresponding first block information and second block information should also match successfully. If the first block information and the second block information finally fail to match, it can be indicated that the to-be-verified node and the verification node maintain different block chain ledgers or the to-be-verified node sends a fault. At this time, it can be determined that the verification result of the to-be-verified node about whether it maintains the same block chain ledger as the verification node is verification failure.

[0042] In addition to the above verification method of matching the first block information and the second block information to determine whether the to-be-verified node fails verification, the embodiments of the present specification also provide other additional verification methods that can determine whether the to-be-verified node fails verification.

[0043] Optionally, it also includes determining that the to-be-verified node fails verification in a case that the verification response is not received within a first preset time length after the verification request is sent. In the embodiments of the present specification, the verification node requires the to-be-verified node to return a verification response within a specified first preset time length, otherwise it is considered that the to-be-verified node fails verification, even if the first block information in the subsequently received verification response can match the second block information successfully. Assuming that the to-be-verified node itself belongs to the same block chain network as the verification node, that is, the to-be-verified node maintains the same block chain ledger as the verification node, the to-be-verified node obtains the first block information by searching locally according to the block height. The efficiency of this process is theoretically fast. If the to-be-verified node does not maintain (or does not completely maintain) the complete block chain ledger corresponding to the block chain network where the verification node is located, but wants to obtain the first block information through other means (for example, first accessing the public platform of the block chain network where the verification node is located to query the first block corresponding to the block height), in order to fake its own identity in the block chain network where the verification node is located, the time cost of this process is higher than that of directly searching and obtaining the first block information locally. Therefore, the time length of the to-be-verified node returning the verification response can be limited to identify those attack parties who attempt to fake their own true identity through the above-mentioned means, and then the to-be-verified node is regarded as an attack party and determined to fail verification if the specified time length for returning the verification response is exceeded, so as to avoid the to-be-verified node as an attack party evading verification failure through other means or increasing the attack cost of the attack party as much as possible, and improve the ability of the block chain network to prevent network attacks.

[0044] Optionally, the verification response further comprises a signature generated by the to-be-verified node for the first block information, and the method further comprises: verifying the signature based on a node public key of the to-be-verified node, and determining that the to-be-verified node fails verification in a case where the signature verification fails. As described above, the to-be-verified node can also provide the signature of the first block information to the verifying node to prove its identity. When the verifying node verifies the signature, the node public key of the to-be-verified node maintained in advance or temporarily provided by the to-be-verified node needs to be used to decrypt the signature, and the decryption result is compared with the first block information. If the comparison is consistent, it indicates that the source of the first block information is indeed the to-be-verified node, so that the signature verification is determined to be successful. If the comparison is inconsistent, it indicates that the source of the first block information is not the to-be-verified node, so that the signature verification is determined to fail. In the case of verification failure, it is considered that the to-be-verified node is verified, so as to avoid the to-be-verified node as an attacker evading the case of verification failure by means of faking identity or increasing the attack cost of the attacker, and improve the ability of the blockchain network to prevent network attacks.

[0045] Step 208: disconnecting the to-be-verified node in a case where the first number of times of verification failure of the to-be-verified node exceeds the first preset threshold.

[0046] The verifying node can count the total number (the first number) of times of verification failure of the to-be-verified node. When the first number of times of verification failure of the to-be-verified node exceeds the first preset threshold, the verifying node can completely confirm that the to-be-verified node does not belong to the same blockchain network, and thus needs to disconnect the connection with the to-be-verified node to exclude the to-be-verified node from the blockchain network, so as to ensure that the P2P network is connected to the same blockchain network, and the nodes included in the P2P network only maintain the same set of blockchain account books, thereby avoiding attacks on the blockchain network. In addition, since the embodiment of the present specification needs to disconnect the connection with the to-be-verified node only when the verification failure reaches a certain threshold, a certain fault tolerance mechanism is also preserved, and the possibility of mistakenly excluding a normal node with temporary failure from the blockchain network is reduced as much as possible.

[0047] Based on the foregoing embodiments of the present specification, a verification mechanism is proposed to ensure that each node in the blockchain network maintains the same set of blockchain ledger. The to-be-verified node needs to provide correct block information to the verification node based on the block height in the verification request, otherwise the to-be-verified node will be regarded as a faulty node or an attacker of abnormal attack by the verification node, that is, the to-be-verified node actually does not maintain the same set of blockchain ledger with the verification node, but reuses the communication module of the same underlying P2P network, resulting in that the nodes actually in different blockchain networks can access in violation of rules. At this time, the verification node disconnects from the to-be-verified node regarded as a faulty node or an attacker, so as to timely eliminate the risk of threatening the normal operation of the system or the network security. In addition, even if the attacker as the to-be-verified node can provide correct block information through other means to evade forced disconnection, the foregoing embodiments of the present specification can objectively increase the cost of the attacker to maintain the connection with the blockchain network, thereby indirectly improving the ability of the blockchain network to prevent network attacks by increasing the attack cost.

[0048] Optionally, further comprising: in a case where the first number of verification failures of the to-be-verified node exceeds a first preset threshold, deleting the node information of the to-be-verified node from the node list maintained by the verification node. As mentioned before, each node in the blockchain network maintains a node list for storing the node information of other nodes that have established a connection with the node. In the embodiments of the present specification, since the verification node and the to-be-verified node have established a connection before, the node information of the to-be-verified node is stored in the node list of the verification node. In a case where the first number of verification failures of the to-be-verified node exceeds a first preset threshold, the verification node will disconnect from the to-be-verified node, and the verification node will also delete the node information of the to-be-verified node originally stored in the node list maintained by the verification node to forget the to-be-verified node and release the storage space of the node list.

[0049] Optionally, the method further comprises: in a case where the first number of verification failures of the to-be-verified node exceeds a first preset threshold, initiating a node deletion transaction containing node information of the to-be-verified node to a network management contract in the blockchain network, so that the network management contract deletes the node information of the to-be-verified node maintained in the network management contract. In the embodiment of the present specification, the network management contract deployed by the blockchain network maintains the node information of each blockchain node as all members in the blockchain network (including the node information of the to-be-verified node), so that in a case where it is determined that the to-be-verified node needs to be exited from the blockchain network (i.e., the to-be-verified node is verified not to belong to the blockchain network), the verification node can also initiate a node deletion transaction to the network management contract to make the network management contract delete the node information of the to-be-verified node maintained in the network management contract, so as to ensure the correctness of the node members in the blockchain node.

[0050] Optionally, the method further comprises: in a case where the first number of verification failures of the to-be-verified node exceeds a first preset threshold, initiating a node deletion transaction containing node information of the to-be-verified node to a network management contract in the blockchain network, so that the network management contract deletes the node information of the to-be-verified node maintained in the network management contract. In the embodiment of the present specification, the network management contract deployed by the blockchain network maintains the node information of each blockchain node as all members in the blockchain network (including the node information of the to-be-verified node), so that in a case where it is determined that the to-be-verified node needs to be exited from the blockchain network (i.e., the to-be-verified node is verified not to belong to the blockchain network), the verification node can also initiate a node deletion transaction to the network management contract to make the network management contract delete the node information of the to-be-verified node maintained in the network management contract, so as to ensure the correctness of the node members in the blockchain node.

[0051] Optionally, the method further comprises: in a case where the first number of verification failures of the to-be-verified node exceeds a first preset threshold, rejecting a connection request sent by the to-be-verified node within a third preset time period after a current time. In the embodiment of the present specification, in a case where the first number of verification failures of the to-be-verified node exceeds the first preset threshold, in addition to the need to disconnect the to-be-verified node, the to-be-verified node can also be added to a connection blacklist, so that the to-be-verified node cannot establish a connection with the verification node again within a period of time, thereby avoiding the to-be-verified node as an attacker continuously harassing the verification node by initiating a connection request. The node information of the node in the connection blacklist involved in the embodiment of the present specification will be automatically deleted after being added for a third preset time period, so that after the third preset time period after the disconnection with the to-be-verified node, the to-be-verified node can still establish a connection with the verification node again by initiating a connection request to the verification node.

[0052] Optionally, the to-be-verified block is selected by the verification node from a selected range of blocks corresponding to the verification difficulty value maintained locally by the verification node, and the selected range is positively correlated with the verification difficulty value; the method further comprises: adjusting the verification difficulty value according to a second number of verification failures of the to-be-verified node within a second preset time period before the current time, and the verification difficulty value is positively correlated with the second number. In the embodiments of the present specification, it is considered that the to-be-verified node as an attacker can also maintain the same block chain ledger locally by other means to find the correct first block information and thus evade the verification failure, but due to the attack cost, it is possible that the to-be-verified node does not maintain a complete block chain ledger (like a normal node), so the embodiments of the present specification adjust the selected range of the to-be-verified block according to the verification difficulty value to different degrees, so as to require the to-be-verified node as an attacker to locally maintain a sufficient number of blocks in the same block chain ledger as the verification node in the case of high verification difficulty value to evade the verification failure, thereby indirectly increasing the attack cost of the attacker. At the same time, the verification difficulty value maintained by the verification node can be dynamically adjusted, for example, the verification difficulty value is adjusted according to the second number of verification failures of the to-be-verified node in the recent period (i.e., the second number of verification failures of the to-be-verified node within the second preset time period before the current time), and since the second number objectively reflects the possibility of the to-be-verified node as an attacker, the embodiments of the present specification can increase the verification difficulty of the to-be-verified node (require the to-be-verified node to maintain more blocks in the correct block chain ledger) in the case that the to-be-verified node as an attacker has a high possibility, to further increase the cost of the attacker to attack the network by evading the verification failure, and further improve the ability of the block chain network to prevent network attacks. In addition, since the adjustment of the verification difficulty value is dynamically performed, for example, when the number of verification failures of the to-be-verified node in the recent period decreases, the current verification difficulty value can also be appropriately reduced, so as to reduce the cost required for normal verification behavior in the case that the to-be-verified node as an attacker has a low possibility (when the selected range of the to-be-verified block is small, the to-be-verified node needs to search a smaller range when obtaining the first block information, so the required time and calculation cost are smaller).

[0053] Optionally, the block chain network deploys a network management contract to maintain the verification difficulty value; and the adjusting the verification difficulty value according to the second number of verification failures of the to-be-verified node within the second preset time period before the current time comprises: initiating a difficulty value adjustment transaction containing the second number to the network management contract deployed by the block chain network, so that the network management contract adjusts the verification difficulty value maintained in the network management contract based on the second number.

[0054] In the embodiments of the present application, the verification difficulty value maintained by the verification node is specifically stored in the network management contract deployed by the verification node. Therefore, in this case, each blockchain node in the blockchain network actually shares the same verification difficulty value by maintaining the same network management contract, which makes it possible for any blockchain node in the blockchain network to adjust the verification difficulty value maintained in the network management contract by initiating a proof difficulty value adjustment transaction to the network management contract when it detects that a to-be-verified node is more likely to be an attacker, so as to inform other blockchain nodes in the blockchain network of the change of the verification difficulty value for the to-be-verified node when verifying the to-be-verified node, so that the blockchain network has the function of adjusting the verification strategy of all nodes as a whole according to the change of the current network environment, and improves the ability of the blockchain network to prevent network attacks as a whole.

[0055] Optionally, the method further includes: in a case where the number of historical messages based on any protocol initiated by the same initiator and received within a fourth preset time period before the current time exceeds a second preset threshold, rejecting the message based on the any protocol initiated by the same initiator. The message based on the any protocol includes at least a connection request in a connection protocol, a node discovery request in a node discovery protocol, a verification response in a verification protocol for verifying whether the same set of blockchain ledgers is maintained, and the like, and the embodiments of the present application do not limit the type of protocol, but the protocol must be pre-established and maintained in the blockchain network, so that the nodes in the blockchain network can identify and process the message corresponding to the protocol. Through the embodiments of the present application, by counting the messages (including various requests or responses) of various protocols received, and in a case where the historical messages of a certain type of protocol from the same initiator are excessive in a short time, the message of the same type of protocol from the same initiator is rejected again, so that the attacker can be effectively identified and moved to the blacklist, and the network attack mode of the same attacker by excessively sending messages, such as a flooding attack or a DOS (Denial of Service) attack, can be effectively prevented.

[0056] Figure 3 FIG. 1 is a schematic structural diagram of a device provided by an example embodiment. Please refer to Figure 3At the hardware level, the device includes a processor 302, an internal bus 303, a network interface 306, a memory 308, and a non-volatile memory 310, and can also include other hardware required by the business. One or more embodiments of the present specification can be implemented in a software manner, such as reading a corresponding computer program from the non-volatile memory 310 into the memory 308 by the processor 302 and then running. Of course, in addition to the software implementation, one or more embodiments of the present specification do not exclude other implementation manners, such as logic devices or a combination of software and hardware, and the like, that is, the execution party of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0057] As shown in Figure 4 , Figure 4 is a block diagram of an apparatus for preventing network attacks provided by the present specification according to an exemplary embodiment. The apparatus can be applied to a device as shown in Figure 3 to implement the technical solutions of the present specification. The apparatus is applied to a verification node in a blockchain network and includes:

[0058] The request sending unit 401 is configured to send a verification request to a to-be-verified node in the blockchain network, and the verification request includes a block height of a to-be-verified block selected by the to-be-verified node from a locally maintained block.

[0059] The response receiving unit 402 is configured to receive a verification response sent by the to-be-verified node in response to the verification request, and the verification response includes first block information.

[0060] The verification unit 403 is configured to determine that the to-be-verified node fails verification in a case where the first block information fails to match second block information corresponding to the to-be-verified block.

[0061] The connection disconnecting unit 404 is configured to disconnect the to-be-verified node in a case where a first number of times of determining that the to-be-verified node fails verification exceeds a first preset threshold.

[0062] Optionally, the request sending unit 401 is specifically configured to:

[0063] periodically send a verification request to the to-be-verified node in the blockchain network.

[0064] Optionally, the second block information includes the to-be-verified block or a hash value corresponding to the to-be-verified block.

[0065] Optionally, the to-be-verified block is obtained by the to-be-verified node from a locally maintained block according to a preset selection rule or randomly.

[0066] Optionally, the to-be-verified block is selected by the verification node from a selected range of blocks corresponding to the verification difficulty value maintained locally by the verification node, and the selected range is positively correlated with the verification difficulty value; the device further comprises:

[0067] The difficulty value adjustment unit 405 is configured to adjust the verification difficulty value according to a second number of verification failures of the to-be-verified node within a second preset time period before the current time, and the verification difficulty value is positively correlated with the second number.

[0068] Optionally, the verification difficulty value is maintained by a network management contract deployed in the blockchain network; and the difficulty value adjustment unit 405 is specifically configured to:

[0069] Initiate a difficulty value adjustment transaction containing the second number to the network management contract deployed in the blockchain network, so that the network management contract adjusts the verification difficulty value maintained in the network management contract based on the second number.

[0070] Optionally, the device further comprises:

[0071] The verification failure determination unit 406 is configured to determine that the to-be-verified node fails in verification if the verification response is not received within a first preset time period after the verification request is sent.

[0072] Optionally, the verification response further comprises a signature generated by the to-be-verified node for the first block information, and the device further comprises:

[0073] The signature verification unit 407 is configured to verify the signature based on a node public key of the to-be-verified node, and determine that the to-be-verified node fails in verification if the signature verification fails.

[0074] Optionally, the device further comprises:

[0075] The list information deletion unit 408 is configured to delete the node information of the to-be-verified node from a node list maintained by the verification node if the first number of verification failures of the to-be-verified node exceeds a first preset threshold.

[0076] Optionally, the device further comprises:

[0077] The node deletion transaction sending unit 409 is configured to initiate a node deletion transaction containing the node information of the to-be-verified node to a network management contract in the blockchain network if the first number of verification failures of the to-be-verified node exceeds a first preset threshold, so that the network management contract deletes the node information of the to-be-verified node maintained in the network management contract.

[0078] Optionally, the device further comprises:

[0079] The suspicious node notification sending unit 410 is configured to, in a case where the first number of verification failures of the to-be-verified node exceeds the first preset threshold, send a suspicious node notification carrying node information of the to-be-verified node to other nodes in the blockchain network, so that the other nodes send a verification request to the to-be-verified node in response to the suspicious node notification.

[0080] Optionally, the node information includes a node identifier, a node public key and / or a network address.

[0081] Optionally, the method further includes:

[0082] The connection request rejecting unit 411 is configured to, in a case where the first number of verification failures of the to-be-verified node exceeds the first preset threshold, reject a connection request sent by the to-be-verified node within a third preset time period after a current time.

[0083] Optionally, the method further includes:

[0084] The response rejecting unit 412 is configured to, in a case where a number of historical messages initiated by a same initiator based on any protocol received within a fourth preset time period before a current time exceeds a second preset threshold, reject a message initiated by the same initiator based on the any protocol.

[0085] In the 1990s, it was quite obvious to distinguish whether an improvement in a technology was in hardware (e.g., improvement in circuit structures of diodes, transistors, switches, etc.) or in software (improvement in method flow). However, as technology has evolved, many improvements in method flow today can be considered as direct improvements in hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structures by programming the improved method flow into hardware circuits. Therefore, it cannot be said that an improvement in a method flow cannot be implemented by hardware entity modules. For example, a programmable logic device (PLD) (e.g., a field programmable gate array (FPGA)) is an integrated circuit whose logic function is determined by user programming of the device. A digital system is "integrated" on a PLD by the designer programming it, rather than by asking a chip manufacturer to design and fabricate a custom integrated circuit chip. Moreover, instead of manually fabricating integrated circuit chips, this programming is now mostly implemented by "logic compiler" software, which is similar to software compilers used in program development, and the original code to be compiled is written in a specific programming language, which is called a hardware description language (HDL), and there are many such languages, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., and the most commonly used are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should be aware that, as long as the method flow is logically programmed in the above-mentioned hardware description languages and programmed into an integrated circuit, a hardware circuit implementing the logical method flow can be easily obtained.

[0086] The controller can be implemented in any suitable way, for example, the controller can take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code, such as software or firmware, executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller and an embedded microcontroller, examples of which include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the control logic of the memory. The skilled person will also appreciate that, in addition to implementing the controller in pure computer readable program code, it is possible to implement the controller in the form of logic gates, switches, an application specific integrated circuit, a programmable logic controller and an embedded microcontroller, etc. to perform the same functions by logically programming the method steps. Such a controller can therefore be considered to be a hardware component, and the means included therein to perform the various functions can also be considered to be structures within the hardware component. Alternatively, or even additionally, the means to perform the various functions can be considered to be both a software module implementing the method and a structure within a hardware component.

[0087] The systems, apparatuses, modules or units illustrated by the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, the present application does not exclude that with the development of computer technology in the future, computers implementing the functions of the above embodiments can be personal computers, laptop computers, vehicle human-computer interaction devices, cellular phones, camera phones, smart phones, personal digital assistants, media players, navigation devices, email devices, game consoles, tablet computers, wearable devices, or combinations of any of these devices.

[0088] Although the method operations of the embodiments of the present disclosure are described in a particular, sequential order, one or more of the method operations can be omitted, or the method operations can be performed in an order other than the described order. Additionally, one or more of the method operations can be performed concurrently, or with partial concurrence. Furthermore, one or more of the method operations can be performed by different entities, or over different time periods. The term "including" as used herein is intended to mean "comprising," such that the process, method, article, or apparatus that includes elements in addition to those specified can still be deemed to include the specific elements. The term "coupled" as used herein is intended to mean two or more entities that have a direct or indirect connection between or among each other.

[0089] For the sake of description, the above-described apparatuses are described with various modules for convenience. Of course, when implementing one or more embodiments of the present disclosure, the functions of the modules can be implemented in one or more software and / or hardware, and modules implementing the same function can be implemented by a combination of a plurality of sub-modules or sub-units, etc. The above-described apparatus embodiment is merely illustrative, for example, the division of the units is merely a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the displayed or discussed each other can be indirect coupling or communication connection through some interfaces, devices or units, and can be electrical, mechanical or other forms.

[0090] The computer program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other processing device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other processing device to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions specified in the flowchart block or blocks or in the flowcharts or block diagrams. Figure 1 The flowchart and / or block diagram in the flowcharts and / or block diagrams of the methods, apparatuses (systems), and computer program products according to the embodiments of the present disclosure can be implemented by computer program instructions. Although the computer program instructions are described as a process that is executed by a computer system in accordance with the embodiments of the present disclosure, the flowchart and / or block diagram in the flowcharts and / or block diagrams of the methods, apparatuses (systems), and computer program products according to the embodiments of the present disclosure can also be implemented by a combination of hardware and software, or as entirety hardware. Figure 1 The apparatuses in one or more flowcharts and / or one or more blocks in the flowcharts and / or block diagrams of the methods, apparatuses (systems), and computer program products according to the embodiments of the present disclosure can be implemented by one or more computer program instructions.

[0091] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.

[0092] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.

[0093] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0094] The memory can include non-persistent memory and / or volatile memory, such as random access memory (RAM) and / or cache memory, non-volatile memory, such as read-only memory (ROM), EPROM, and / or flash memory. The memory is an example of computer-readable media.

[0095] Computer-readable media includes permanent and non-permanent, moveable and non- moveable media that can be implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile discs (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, graphene storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to computing devices. According to the definition herein, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

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

[0097] The one or more embodiments described herein can be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. The one or more embodiments described herein can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote computer storage media including memory storage devices.

[0098] The various embodiments described in this specification are described in the context of progressive embodiments, with each embodiment building on the previous one. The same or similar parts between embodiments are cross-referenced as appropriate. Each embodiment focuses on the differences between that embodiment and the previous one. In particular, the system embodiments are described relatively simply, as they are substantially similar to the method embodiments. In the description of the specification, the description of the terms "one embodiment", "some embodiments", "example", "specific example" or "some examples" means that the specific feature, structure, material or characteristic being described in connection with that embodiment or example is included in at least one embodiment or example in the specification. Illustrative representations of the above terms in the specification are not necessarily referring to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics being described can be combined in any suitable manner in one or more embodiments or examples. Furthermore, the skilled person can combine and combine features of different embodiments or examples and characteristics of different embodiments or examples in a manner that is not mutually contradictory.

[0099] The above only describes some embodiments of the one or more embodiments described in this specification and is not intended to limit the one or more embodiments described in this specification. The one or more embodiments described in this specification can have various modifications and changes for those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the specification shall be included in the scope of the claims.

Claims

1. A method for preventing network attacks, applied to a verification node in a blockchain network, comprising: Sending a verification request to the node to be verified in the blockchain network, wherein the verification request includes the block height of the block to be verified selected by the verification node from the locally maintained blocks; The block to be verified is selected by the verification node from a selected range of blocks corresponding to a locally maintained verification difficulty value, where the selected range is positively correlated to the verification difficulty value; receiving a verification response sent by the node to be verified in response to the verification request, wherein the verification response includes first block information; Determining that verification of the node to be verified fails when the first block information fails to match the second block information corresponding to the block to be verified; Adjusting the verification difficulty value according to a second number of verification failures of the node to be verified within a second preset time period before the current moment, wherein the verification difficulty value is positively correlated with the second number; If it is determined that a first number of verification failures of the node to be verified exceeds a first preset threshold, disconnecting from the node to be verified; wherein the first number is the total number of verification failures of the node to be verified.

2. The method according to claim 1, wherein sending a verification request to the node to be verified in the blockchain network comprises: Periodically send verification requests to the nodes to be verified in the blockchain network.

3. The method according to claim 1, wherein the second block information includes the block to be verified or a hash value corresponding to the block to be verified.

4. According to the method of claim 1, the block to be verified is obtained by the verification node from the locally maintained blocks according to a preset selection rule or randomly selected.

5. The method according to claim 1, wherein the network management contract deployed by the blockchain network maintains the verification difficulty value; and adjusting the verification difficulty value based on a second number of verification failures of the node to be verified determined within a second preset time period before the current moment, comprises: Initiate a difficulty value adjustment transaction including a second number to a network management contract deployed on the blockchain network, so that the network management contract adjusts the verification difficulty value maintained in the network management contract based on the second number.

6. The method according to claim 1, further comprising: If the verification response is not received within a first preset time period after the verification request is sent, it is determined that the verification of the node to be verified has failed.

7. The method according to claim 1, wherein the verification response further includes a signature generated by the node to be verified for the first block information, and the method further includes: The signature is verified based on the node public key of the node to be verified, and if the signature verification fails, it is determined that the verification of the node to be verified fails.

8. The method according to claim 1, further comprising: When it is determined that a first number of verification failures of the node to be verified exceeds a first preset threshold, the node information of the node to be verified is deleted from the node list maintained by the verification node.

9. The method according to claim 1, further comprising: When it is determined that the first number of verification failures of the node to be verified exceeds a first preset threshold, a node deletion transaction containing the node information of the node to be verified is initiated to the network management contract in the blockchain network, so that the network management contract deletes the node information of the node to be verified maintained in the network management contract.

10. The method according to claim 1, further comprising: When it is determined that the first number of verification failures of the node to be verified exceeds a first preset threshold, a suspicious node notification carrying the node information of the node to be verified is sent to other nodes in the blockchain network, so that the other nodes send a verification request to the node to be verified in response to the suspicious node notification.

11. The method according to claim 8, 9 or 10, wherein the node information comprises a node identifier, a node public key and / or a network address.

12. The method according to claim 1, further comprising: When it is determined that the first number of verification failures of the node to be verified exceeds a first preset threshold, a response to a connection request sent by the node to be verified is refused within a third preset time period after the current moment.

13. The method according to claim 1, further comprising: If the number of historical messages based on any protocol received from the same initiator within a fourth preset time period before the current moment exceeds a second preset threshold, refuse to respond to messages based on any protocol initiated by the same initiator.

14. A device for preventing network attacks, applied to a verification node in a blockchain network, comprising: A request sending unit, configured to send a verification request to a node to be verified in the blockchain network, wherein the verification request includes a block height of a block to be verified selected by the verification node from locally maintained blocks; The block to be verified is selected by the verification node from a selected range of blocks corresponding to a locally maintained verification difficulty value, where the selected range is positively correlated to the verification difficulty value; a response receiving unit, configured to receive a verification response sent by the node to be verified in response to the verification request, wherein the verification response includes first block information; A verification unit, configured to determine that verification of the node to be verified fails if the first block information fails to match the second block information corresponding to the block to be verified; A difficulty value adjustment unit, configured to adjust the verification difficulty value according to a second number of verification failures of the node to be verified determined within a second preset time period before the current moment, wherein the verification difficulty value is positively correlated with the second number; The connection disconnection unit is used to disconnect the node to be verified when it is determined that the first number of verification failures of the node to be verified exceeds a first preset threshold; wherein the first number is the total number of verification failures of the node to be verified.

15. An electronic device comprising: processor; a memory for storing processor-executable instructions; The processor implements the method according to any one of claims 1 to 13 by running the executable instructions.

16. A computer-readable storage medium having computer instructions stored thereon, wherein when the instructions are executed by a processor, the steps of the method according to any one of claims 1 to 13 are implemented.

Images