CN112822214A

CN112822214A - Network attack defense method, device, system, storage medium and electronic equipment

Info

Publication number: CN112822214A
Application number: CN202110182021.XA
Authority: CN
Inventors: 窦小龙
Original assignee: Guangzhou Huiruisitong Technology Co Ltd
Current assignee: Guangzhou Huiruisitong Technology Co Ltd
Priority date: 2021-02-09
Filing date: 2021-02-09
Publication date: 2021-05-18

Abstract

The invention discloses a method, a device, a system, a storage medium and electronic equipment for defending network attacks, and belongs to the field of communication. Wherein, the method comprises the following steps: receiving a handshake confirmation message sent by a client in a third handshake process, wherein the handshake confirmation message carries an authentication field, and the authentication field is generated based on the handshake message sent by the server to the client in the second handshake process; judging whether the authentication field is matched with a preset field or not; and if the authentication field is not matched with the preset field, disconnecting the network connection between the server and the client. By the method and the device, the technical problem of poor DoS attack defending capability in the related technology is solved, the safety of network connection between the client and the server is improved, and the stability and the robustness of the server are improved.

Description

Network attack defense method, device, system, storage medium and electronic equipment

Technical Field

The present disclosure relates to the field of communications, and in particular, to a method, an apparatus, a system, a storage medium, and an electronic device for defending against a network attack.

Background

In the related art, a communication system that uses an AAA (Authentication, Authorization, and Accounting) server for Authentication includes, but is not limited to, a WLAN (Wireless Local Area Network), a website that uses https (hypertext Transfer Security Protocol) Protocol for communication, a system that uses SSH (Secure Shell Protocol) for communication, a communication system that uses TLS (Transport Layer Security)/Secure Layer Security Protocol (Secure socket Protocol) encryption Protocol, and the like, and a replay attack prevention function is designed by adding a random number in a handshake Protocol process. The TLS/SSL three-way handshake protocol generates different random numbers, the third handshake generates pre _ master _ secret (pre-master key), but in practice, hackers can still initiate a large number of connection requests by using pre _ master _ secret stored or used in advance, and the decryption of pre _ master _ secret ciphertext by using the authentication server requires a large amount of Central Processing Unit (CPU) Processing power to perform Denial of Service (DoS) attacks.

Disclosure of Invention

In the related art, according to the RFC 5246(TLS) protocol, a pre _ master _ secret is composed of a client protocol version number of 2 bytes and a random number generated by a client of 46 bytes. The client uses the asymmetric encryption public key sent by the server to perform asymmetric encryption on the pre _ master _ secret, and the encrypted public key is sent to the server to prevent the public key from being acquired by a man-in-the-middle. An attacker can generate a group of pre _ master _ secret in advance, repeatedly use the group of pre _ master _ secret in the attack process, simultaneously generate a large number of connection requests, utilize the principle that the server needs to consume a large amount of CPU processing capacity for decrypting the pre _ master _ secret, and as long as the pre _ master _ secret can be decrypted normally, the server defaults that the connection is legal, and the attacker launches the same connection through the same pre _ master _ secret, so that the purpose of DoS attacking the AAA server can be achieved.

The embodiment of the disclosure provides a method, a device, a system, a storage medium and electronic equipment for defending network attacks, so as to solve the technical problem that the DoS attack defending capability of the related technology is poor.

According to an aspect of the embodiments of the present disclosure, there is provided a method for defending against a network attack, which is applied to a server, and includes: receiving a handshake confirmation message sent by a client in a third handshake process, wherein the handshake confirmation message carries an authentication field, and the authentication field is generated based on the handshake message sent to the client by the server in the second handshake process; judging whether the authentication field is matched with a preset field or not; and if the authentication field is not matched with the preset field, disconnecting the network connection between the server and the client.

Further, the message content of the handshake confirmation message is a cipher text, and before the determining whether the authentication field matches the preset field, the method further includes: decrypting the message content of the handshake confirmation message to obtain a plaintext field; and extracting the authentication field at a preset position of the plaintext field.

Further, the determining whether the authentication field is matched with the preset field includes: locally reading a preset field in the handshake message; judging whether the byte contents of the authentication field and the preset field are consistent or not; if the byte content of the authentication field is consistent with that of the preset field, the authentication field is matched; and if the byte content of the authentication field is not consistent with that of the preset field, the authentication field is not matched.

Further, the method further comprises: if the authentication field is not matched with the preset field, generating an illegal connection log; and if the log quantity of the illegal connection log is accumulated to a threshold quantity within a preset time period, generating alarm information.

Further, before receiving a handshake confirmation message sent by the client in the third handshake process, the method further includes: receiving a connection request sent by the client in a first handshake process; returning the handshake message to the client based on the connection request in a second handshake process, wherein the handshake message carries the preset field, so that the client generates a handshake confirmation message according to the preset field; and locally recording a preset field, wherein the preset field corresponds to the authentication field.

Further, the preset field is contained in one or more of the following messages: server handshake Server hello message, certificate message, Server key exchange message, certificate request message, Server handshake completes Server hello done message.

Further, the preset field is included in a Server random number Server _ random and/or a custom field of the Server handshake Server hello message.

According to an aspect of the embodiments of the present disclosure, there is provided another method for defending against a network attack, which is applied to a client, and includes: receiving a handshake message sent by a server in a second handshake process, wherein the handshake message carries a preset field; generating a handshake confirmation message based on the preset field, wherein the handshake confirmation message carries an authentication field, and the authentication field corresponds to the preset field; and sending the handshake confirmation message to the server in the third handshake process so that the server judges whether the current connection is legal or not through the authentication field in the handshake confirmation message.

Further, the generating of the handshake confirmation message based on the preset field includes: extracting the preset field at the preset position of the handshake message; adding the client protocol version number at a first field position, adding the preset field at a second field position, and adding a first random number at a third field position; and encrypting the client protocol version number, the preset field and the first random number to generate the handshake confirmation message.

Further, the extracting the preset field at the preset position of the handshake message includes: extracting a second random number in the handshake message; extracting a plurality of bytes of the second random number, and determining the plurality of bytes as the preset field.

Further, the handshake message includes at least one of: server handshake Server hello message, certificate message, Server key exchange message, certificate request message, Server handshake completes Server hello done message.

According to another aspect of the embodiments of the present disclosure, there is provided a network attack defense device, applied to a server, including: a receiving module, configured to receive a handshake confirmation message sent by a client in a third handshake process, where the handshake confirmation message carries an authentication field, and the authentication field is generated based on a handshake message sent by the server to the client in a second handshake process; the judging module is used for judging whether the authentication field is matched with a preset field; and the defense module is used for disconnecting the network connection between the server and the client if the authentication field is not matched with the preset field.

Further, the message content of the handshake confirmation message is a ciphertext, and the apparatus further includes: a decryption module, configured to decrypt the message content of the handshake confirmation message to obtain a plaintext field before the determining module determines whether the authentication field matches a preset field; and the extraction module is used for extracting the authentication field from the preset position of the plaintext field.

Further, the judging module includes: a reading unit, configured to locally read a preset field in the handshake message; the judging unit is used for judging whether the byte contents of the authentication field and the preset field are consistent or not; a determining unit, configured to match the authentication field if the byte content of the authentication field is consistent with the byte content of the preset field; and if the byte content of the authentication field is not consistent with that of the preset field, the authentication field is not matched.

Further, the above apparatus further comprises: the first generation module is used for generating an illegal connection log if the authentication field is not matched with a preset field; and the second generation module is used for generating alarm information if the log quantity of the illegal connection log is accumulated to a threshold quantity in a preset time period.

Further, the above apparatus further comprises: a receiving module, configured to receive a connection request sent by a client in a first handshake process before the receiving module receives a handshake confirmation message sent by the client in a third handshake process; a processing module, configured to return the handshake message to the client based on the connection request in a second handshake process, where the handshake message carries the preset field, so that the client generates a handshake confirmation message according to the preset field; and the recording module is used for locally recording a preset field, wherein the preset field corresponds to the authentication field.

According to another aspect of the embodiments of the present disclosure, there is provided another defense apparatus for network attacks, which is applied to a client, and includes: the receiving module is used for receiving a handshake message sent by the server in a second handshake process, wherein the handshake message carries a preset field; a generating module, configured to generate a handshake confirmation message based on the preset field, where the handshake confirmation message carries an authentication field, and the authentication field corresponds to the preset field; and the sending module is used for sending the handshake confirmation message to the server in the third handshake process so that the server judges whether the current connection is legal or not through the authentication field in the handshake confirmation message.

Further, the generating module includes: an extracting unit, configured to extract the preset field at a preset position of the handshake message; an adding unit, configured to add the client protocol version number in a first field position, add the preset field in a second field position, and add a first random number in a third field position; and an encryption unit, configured to encrypt the client protocol version number, the preset field, and the first random number, and generate the handshake confirmation message.

Further, the extraction unit includes: a first extraction subunit, configured to extract the second random number in the handshake message; and a second extraction subunit, configured to extract a plurality of bytes of the second random number, and determine the plurality of bytes as the preset field.

According to another aspect of the embodiments of the present disclosure, there is also provided a defense system for network attacks, including a server and a client, where the server includes the apparatus described in the foregoing embodiments; the client comprises the device described in the above embodiments.

According to another aspect of the embodiments of the present disclosure, there is also provided a storage medium including a stored program, which executes the above steps when the program is executed.

According to another aspect of the embodiments of the present disclosure, there is also provided an electronic device, including a processor, a communication interface, a memory and a communication bus, where the processor, the communication interface, and the memory complete communication with each other through the communication bus; wherein: a memory for storing a computer program; a processor for executing the steps of the method by running the program stored in the memory.

Embodiments of the present disclosure also provide a computer program product containing instructions which, when run on a computer, cause the computer to perform the steps of the above-described method.

By the method, the handshake confirmation message sent by the client is received in the third handshake process, the handshake confirmation message carries the authentication field, the authentication field is generated based on the handshake message sent by the server to the client in the second handshake process, whether the authentication field is matched with the preset field is judged, if the authentication field is not matched with the preset field, the network connection between the server and the client is disconnected, the authentication field is added in the handshake confirmation message, the server uses the authentication field to determine whether the network connection is legal, the access threshold of the client is improved by optimizing the handshake process, the DoS attack caused by the fact that an attacker initiates the same connection for multiple times through the same handshake confirmation message can be avoided, the technical problem of poor capability of defending against the DoS attack in the related technology is solved, and the security of the network connection between the client and the server is improved, the stability and robustness of the server are improved.

Drawings

The accompanying drawings, which are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of this disclosure, illustrate embodiments of the disclosure and together with the description serve to explain the disclosure and not to limit the disclosure. In the drawings:

fig. 1 is a block diagram of a hardware architecture of a server according to an embodiment of the present disclosure;

FIG. 2 is a flow chart of a method for defending against a cyber attack according to an embodiment of the present disclosure;

FIG. 3 is an interaction diagram of an embodiment of the present disclosure;

FIG. 4 is a flow chart of another method of defending against a cyber attack according to an embodiment of the present disclosure;

FIG. 5 is a block diagram of a defense apparatus against cyber attacks according to an embodiment of the present disclosure;

FIG. 6 is a block diagram of another defense apparatus against cyber attacks according to an embodiment of the present disclosure;

FIG. 7 is a block diagram of a defense system against cyber attacks according to an embodiment of the present disclosure;

fig. 8 is a block diagram of an electronic device implementing an embodiment of the disclosure.

Detailed Description

In order to make the technical solutions of the present disclosure better understood by those skilled in the art, the technical solutions of the embodiments of the present disclosure will be clearly and completely described below with reference to the drawings in the embodiments of the present disclosure, and it is obvious that the described embodiments are only some embodiments of the present disclosure, not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments disclosed herein without making any creative effort, shall fall within the protection scope of the present disclosure. It should be noted that, in the present disclosure, the embodiments and features of the embodiments may be combined with each other without conflict.

It should be noted that the terms "first," "second," and the like in the description and claims of the present disclosure and in the above-described drawings are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the disclosure described herein are capable of operation in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

Example 1

The method provided by the first embodiment of the present disclosure may be executed in a server (e.g., an authentication server, a firewall server, a security server, etc.), a computer, a mobile phone, a tablet, or a similar computing device. Taking an example of the server running on the server, fig. 1 is a hardware structure block diagram of a server according to an embodiment of the present disclosure. As shown in fig. 1, the server may include one or more processors 102 (only one is shown in fig. 1), wherein the processors 102 may include, but are not limited to, a Microprocessor (MCU) or a processing device such as a Programmable logic device (FPGA) and a memory 104 for storing data, and optionally, the server may further include a transmission device 106 for communication function and an input/output device 108. It will be understood by those skilled in the art that the structure shown in fig. 1 is only an illustration, and is not intended to limit the structure of the server. For example, the server may also include more or fewer components than shown in FIG. 1, or have a different configuration than shown in FIG. 1.

The memory 104 may be used to store a server program, for example, a software program and a module of application software, such as a server program corresponding to a network attack defense method in the embodiment of the present disclosure, and the processor 102 executes various functional applications and data processing by running the server program stored in the memory 104, so as to implement the method described above. The memory 104 may include high speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include memory located remotely from the processor 102, which may be connected to a server over a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The transmission device 106 is used to receive or transmit data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider of the server. In one example, the transmission device 106 includes a Network adapter (NIC) that can be connected to other Network devices through a base station to communicate with the internet. In one example, the transmission device 106 may be a Radio Frequency (RF) module, which is used to communicate with the internet in a wireless manner.

In this embodiment, a method for defending against a network attack is provided, and is applied to a server, such as an AAA server, a firewall server, a security server, a service server, and the like, fig. 2 is a flowchart of a method for defending against a network attack according to an embodiment of the present disclosure, and as shown in fig. 2, the flowchart includes the following steps:

step S202, receiving a handshake confirmation message sent by the client in a third handshake process, wherein the handshake confirmation message carries an authentication field, and the authentication field is generated based on the handshake message sent by the server to the client in the second handshake process;

optionally, the authentication field of this embodiment may be a part or all of the fields of the handshake confirmation message. The handshake confirmation message may be a message generated based on a message format (pre _ master _ secret, pre-master key) of the relevant TLS handshake protocol, or may be a handshake confirmation message obtained by improving a format of message content in the relevant TLS handshake protocol (for example, replacing a field, adding a field, and the like), where the authentication field has randomness and cannot be multiplexed many times, and may be field data such as a random number and the like carried in the handshake message, or may be timestamp data such as transmission time of the handshake message.

Step S204, judging whether the authentication field is matched with a preset field;

step S206, if the authentication field is not matched with the preset field, the network connection between the server and the client is disconnected.

Optionally, in another aspect of this embodiment, if the authentication fields are matched, it is determined that the network connection between the server and the client is established, and the two parties start to transmit the service data.

Through the steps, a handshake confirmation message sent by the client is received in the third handshake process, the handshake confirmation message carries an authentication field, the authentication field is generated based on the handshake message sent by the server to the client in the second handshake process, whether the authentication field is matched with the preset field is judged, if the authentication field is not matched with the preset field, the network connection between the server and the client is disconnected, the authentication field is added in the handshake confirmation message, the server uses the authentication field to determine whether the network connection is legal, the access threshold of the client is improved through optimizing the handshake process, DoS attack caused by the fact that an attacker initiates the same connection for multiple times through the same handshake confirmation message can be avoided, the technical problem of poor DoS attack defending capability of the related technology is solved, and the security of the network connection between the client and the server is improved, the stability and robustness of the server are improved.

Fig. 3 is an interaction schematic diagram of the embodiment of the disclosure, where a network framework includes a Client and a Server, and the Client needs to perform three-way interaction verification before formally establishing a network connection with the Server, where the three-way interaction verification includes a connection request sent by a first handshake, such as a Clienthello (Client hello message), a handshake message sent by a second handshake, such as a Server hello (Server handshake message), and a handshake confirmation message sent by a third handshake, such as a Client key exchange message, that is, a three-way handshake, and after the three-way handshake is completed, the Client and the Server start to transmit service data, and if any one of the three handshakes fails, the network connection is disconnected. The server can be AAA server, firewall server, safety server, service server, etc., and the client can be any service terminal, test device, etc. which can access network, such as mobile phone, computer, etc.

In an application scenario of this embodiment, the message content of the handshake confirmation message is a ciphertext, and before determining whether the authentication field matches the preset field, the method further includes: decrypting the message content of the handshake confirmation message to obtain a plaintext field; and extracting the authentication field at the preset position of the plaintext field.

During the three-way handshake, the message transmitted between the client and the server is encrypted, so that the data security can be ensured, the stealing can be prevented, and the authentication field can be extracted from the plaintext field after the handshake confirmation message is decrypted.

In one example, the authentication field is extracted between the 3 rd byte and the 6 th byte of the plaintext field of the message content (pre _ master _ secret) of the handshake confirmation message, for a total of 4 bytes, where the 4 bytes are generated based on the handshake message sent by the server to the client in the second handshake process, such as taking the first 4 bits of server _ random in the handshake message. Of course, the field position and the field length may be pre-agreed according to the negotiation between the server and the client, and are not limited in this embodiment.

In an implementation manner of this embodiment, the determining whether the authentication field matches the preset field includes: reading a preset field in the handshake message locally; judging whether the byte contents of the authentication field and the preset field are consistent or not; if the byte content of the authentication field is consistent with that of the preset field, the authentication field is matched; and if the byte content of the authentication field is inconsistent with the byte content of the preset field, the authentication field is not matched.

In this embodiment, after sending the handshake message to the client, the server locally records the handshake message, so that the preset field in the handshake message can be read locally. In the above embodiment, the authentication field is matched if the authentication field is the same as the preset field, optionally, a mapping rule or a matching policy may also be preset, and then in the process of determining whether the authentication field is matched with the preset field, the determination is performed based on the mapping rule or the matching policy, so that the security of authentication may be further improved.

In an embodiment of this embodiment, the method further includes: if the authentication field is not matched with the preset field, generating an illegal connection log; and if the log quantity of the illegal connection log is accumulated to a threshold quantity within a preset time period, generating alarm information. The alarm information is used to prompt the network security administrator to take further security precautions, wherein the preset time period and the threshold amount can be set as configuration items of the server. Optionally, the client may be further pulled into a blacklist based on an IP address or a device identifier of the client, so as to prevent the client from accessing and connecting again, and avoid resource waste caused by continuous invalid access.

In an implementation manner of this embodiment, before receiving a handshake confirmation message sent by a client in a third handshake process, the method further includes: receiving a connection request sent by a client in a first handshake process; in the second handshaking process, a handshaking message is returned to the client based on the connection request, wherein the handshaking message carries the preset field, so that the client generates a handshaking confirmation message according to the preset field; and locally recording a preset field, wherein the preset field corresponds to the authentication field.

By recording the preset field, whether the authentication field is matched with the preset field can be judged based on the preset field in the third handshake process, so that the fast authentication is realized, the illegal connection is identified and blocked, and the DoS attack is prevented.

Optionally, the handshake message may be, but is not limited to: server handshake Server hello message, certificate message, Server key exchange message, certificate request message, Server handshake completes Server hello done message. The preset field is contained in one or several of the following messages: server handshake Server hello message, certificate message, Server key exchange message, certificate request message, Server handshake completes Server hello done message.

Taking the Server handshake Server hello message as an example for illustration, the preset field is included in the Server random number Server _ random of the Server handshake Server hello message, in one example, the preset field is included in the custom field of the Server handshake Server hello message, such as a header field, a check field, and the like, and in another example, the preset field is included in both the Server _ random and the custom field of the Server handshake Server hello message.

In this embodiment, another method for defending against a network attack is provided, and is applied to a client, where the client may be any electronic terminal that can access a network, such as a mobile phone and a computer, and fig. 4 is a flowchart of another method for defending against a network attack according to an embodiment of the present disclosure, and as shown in fig. 4, the flowchart includes the following steps:

step S402, receiving a handshake message sent by a server in a second handshake process, wherein the handshake message carries a preset field;

in this embodiment, the preset field may be a field content based on a relevant TLS handshake protocol, where the preset field is a field carried in a message such as a Server hello in the second handshake process, the message includes a Server public key and a Server _ random (Server random number), and the preset field may be a part or all of the Server _ random or the Server public key.

Step S404, generating a handshake confirmation message based on a preset field, wherein the handshake confirmation message carries an authentication field, and the authentication field corresponds to the preset field;

optionally, when generating the handshake confirmation message in this embodiment, the handshake confirmation message may be a message generated based on a format (pre _ master _ secret) of the relevant TLS handshake protocol, or may be a handshake confirmation message obtained by improving a format of message content in the relevant TLS handshake protocol (for example, replacing an original field in the relevant TLS handshake protocol message with a preset field, adding a preset field in the original field of the relevant TLS handshake protocol message, and the like).

Step S406, sending a handshake confirmation message to the server in the third handshake process, so that the server determines whether the current connection is a legal connection through the authentication field in the handshake confirmation message.

After receiving the handshake confirmation message, the server may directly extract a preset field therein as an authentication field, and perform judgment and authentication, or may generate the authentication field based on the preset field according to a preset mapping rule or a preset conversion rule.

In an implementation manner of this embodiment, generating the handshake confirmation message based on the preset field includes:

s11, extracting a preset field at a preset position of the handshake message;

in one example, extracting the preset field at the preset location of the handshake message includes: extracting a second random number in the handshake message; a number of bytes of the second random number is extracted, and the number of bytes is determined as a preset field.

Optionally, the second random number is a server random number, in this example, the handshake message carries a server random number (server _ random), the server _ random includes 32 bytes, and the preset field is obtained by extracting a plurality of bytes of the server random number. In the three-way handshake process, three random numbers are generated in total, including a client _ random (32 bytes) sent by the client to the server in the first handshake process, which is carried in the connection request, a server _ random (32 bytes) sent by the server to the client in the second handshake process, which is carried in the handshake message, and a client _ random (42 bytes) sent by the client to the server in the third handshake process, which is carried in the handshake confirmation message, where the second random number in this embodiment is the server _ random therein. Optionally, the first bytes of the second random number are extracted, and the first bytes are determined as the preset field.

In another example, a number of bytes may also be extracted from other field positions of the server _ random, such as the middle position, to obtain a preset field; preset fields may also be extracted from fields of other message content of the handshake message.

S12, adding a client protocol version number at the first field position, adding a preset field at the second field position, and adding a first random number at the third field position; optionally, the first random number is a client random number generated by the client during the third handshake.

S13, asymmetrically encrypting the client protocol version number, the preset field, and the first random number to generate a handshake confirmation message.

In this embodiment, the handshake message may include multiple types of messages, and the handshake message may be, but is not limited to: server handshake Server hello message, certificate message, Server key exchange message, certificate request message, Server handshake completes Server hello done message. The messages are handshake messages sent by the server to the client in different time sequences in the second handshake process, and carry different message contents respectively.

In one implementation of this embodiment, the receiving of the handshake message sent by the server in the second handshake process includes one of the following: the method comprises the steps of receiving a Server hello message sent by a Server in a second handshake process, receiving a certificate message sent by the Server in the second handshake process, receiving a Server key exchange message sent by the Server in the second handshake process, receiving a certificate request message sent by the Server in the second handshake process, and receiving a Server hello done message sent by the Server in the second handshake process.

In some examples, handshake confirmation messages are generated based on preset fields carried in at least two types of handshake messages, for example, a first subfield in a Server hello message is taken, a first subfield in the Server hello message is taken, a second subfield in a Server key exchange message is taken, and then the completed preset fields are spliced, so that the concealment of the preset fields can be further improved, the stealing difficulty is improved, and the communication security is further improved.

In an example of this embodiment, an authentication field is generated by using a part of bytes in server _ random, and the server authenticates the authentication field as the authentication field, which is described in connection with this example to fully describe the scheme of the embodiment:

in the TLS three-way handshake protocol, a random number is generated in each handshake process, and the scheme of this embodiment optimizes the process of generating the pre _ master _ secret in the third handshake (sending Client key exchange). The relevant TLS protocol provides that the pre master secret consists of a client protocol version number of 2 bytes and 46 bytes consist of a client generated random number. The Server hello message sent by the Server to the client contains the random number Server _ random generated by the Server. The scheme comprises the following steps:

step 1, according to a TLS handshake protocol, a Client initiates a Client hello request message to a server, wherein the message comprises a random number Client _ random generated by the Client.

And step 2, according to a TLS handshake protocol, the Server sends messages such as Server hello and the like to the testing device, wherein the messages comprise the public key of the Server and the random number Server _ random. Wherein, both the client _ random and the server _ random are 32 bytes.

And 3, generating a random number of 42 bytes by the client, generating a pre _ master _ secret plaintext by adopting a client protocol version number of 2 bytes, contents of the first 4 bytes in the random number of the server and the random number of 42 bytes, and asymmetrically encrypting the pre _ master _ secret plaintext by using the received public key of the server to generate a pre _ master _ secret ciphertext. The Client transmits a pre _ master _ secret ciphertext to the server in a handshake confirmation message (Client key exchange).

And step 4, after receiving the pre _ master _ secret ciphertext, the server decrypts the pre _ master _ secret ciphertext by using a private key to obtain a pre _ master _ secret plaintext, and compares whether the content of the 3 rd byte to the 6 th byte of the pre _ master _ secret plaintext is completely consistent with the content of the 1 st byte to the 4 th byte of the locally recorded server _ random.

If the time and the time threshold are designed according to the requirements of the server, the time and the time threshold can also be designed as a server configuration item. If the consistency is ensured, the subsequent flow and business processing are continued.

The embodiment achieves prevention and discovery of DoS attack behaviors by optimizing the generation format of the pre _ master _ secret, optimizes and adjusts the pre _ master _ secret in the related protocol (consisting of a client protocol version number of 2 bytes and a random number generated by a client with 46 bytes), the optimized pre _ master _ secret consists of a client protocol version number of 2 bytes and the content of the first 4 bytes in the random number of the server + a random number of 42 bytes, and once the server detects that the content of the pre _ master _ secret is not consistent with the content of the random number generated by the server, the server disconnects the connection and records logs, so that the DoS attack behaviors can be effectively prevented.

Through the above description of the embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but the former is a better implementation mode in many cases. Based on such understanding, the technical solutions of the present disclosure may be embodied in the form of a software product, which is stored in a storage medium (e.g., ROM/RAM, magnetic disk, optical disk) and includes instructions for enabling a terminal device (e.g., a mobile phone, a computer, a server, or a network device) to execute the method according to the embodiments of the present disclosure.

Example 2

In this embodiment, a network attack defense device and system are further provided, which are used to implement the foregoing embodiments and preferred embodiments, and are not described again after being described. As used below, the term "module" may be a combination of software and/or hardware that implements a predetermined function. Although the means described in the embodiments below are preferably implemented in software, an implementation in hardware, or a combination of software and hardware is also possible and contemplated.

Fig. 5 is a block diagram of a network attack defense device according to an embodiment of the disclosure, which is applied to a server, and as shown in fig. 5, the network attack defense device includes: a receiving module 50, a determining module 52, a defense module 54, wherein,

a receiving module 50, configured to receive a handshake confirmation message sent by a client in a third handshake process, where the handshake confirmation message carries an authentication field, and the authentication field is generated based on a handshake message sent by the server to the client in a second handshake process;

a judging module 52, configured to judge whether the authentication field matches a preset field;

and a defense module 54, configured to disconnect the network connection between the server and the client if the authentication field is not matched with a preset field.

Optionally, the message content of the handshake confirmation message is a ciphertext, and the apparatus further includes: a decryption module, configured to decrypt the message content of the handshake confirmation message to obtain a plaintext field before the determining module determines whether the authentication field matches a preset field; and the extraction module is used for extracting the authentication field from the preset position of the plaintext field.

Optionally, the judging module includes: a reading unit, configured to locally read a preset field in the handshake message; the judging unit is used for judging whether the byte contents of the authentication field and the preset field are consistent or not; a determining unit, configured to match the authentication field if the byte content of the authentication field is consistent with the byte content of the preset field; and if the byte content of the authentication field is not consistent with that of the preset field, the authentication field is not matched.

Optionally, the apparatus further comprises: the first generation module is used for generating an illegal connection log if the authentication field is not matched with a preset field; and the second generation module is used for generating alarm information if the log quantity of the illegal connection log is accumulated to a threshold quantity in a preset time period.

Optionally, the apparatus further comprises: a receiving module, configured to receive a connection request sent by a client in a first handshake process before the receiving module receives a handshake confirmation message sent by the client in a third handshake process; the processing module is used for returning the handshake message to the client based on the connection request in a second handshake process, wherein the handshake message carries the preset field, so that the client generates a handshake confirmation message according to the preset field; and locally recording a preset field, wherein the preset field corresponds to the authentication field.

Optionally, the preset field is included in one or more of the following messages: server handshake Server hello message, certificate message, Server key exchange message, certificate request message, Server handshake completes Server hello done message.

Optionally, the preset field is included in a Server random number Server _ random and/or a custom field of the Server hello message.

Fig. 6 is a block diagram of another defense apparatus against cyber attacks according to an embodiment of the disclosure, which is applied to a client, and as shown in fig. 6, the apparatus includes: a receiving module 60, a generating module 62, a sending module 64, wherein,

a receiving module 60, configured to receive a handshake message sent by a server in a second handshake process, where the handshake message carries a preset field;

a generating module 62, configured to generate a handshake confirmation message based on the preset field;

a sending module 64, configured to send the handshake confirmation message to the server in a third handshake process, so that the server determines whether the current connection is a legal connection through an authentication field in the handshake confirmation message, where the authentication field corresponds to the preset field.

Optionally, the generating module includes: an extracting unit, configured to extract the preset field at a preset position of the handshake message; an adding unit, configured to add the client protocol version number in a first field position, add the preset field in a second field position, and add a first random number in a third field position; and an encryption unit, configured to encrypt the client protocol version number, the preset field, and the first random number, and generate the handshake confirmation message.

Optionally, the extracting unit includes: a first extraction subunit, configured to extract the second random number in the handshake message; and a second extraction subunit, configured to extract a plurality of bytes of the second random number, and determine the plurality of bytes as the preset field.

Optionally, the handshake message includes one of: server handshake Server hello message, certificate message, Server key exchange message, certificate request message, Server handshake completes Server hello done message.

Fig. 7 is a block diagram of a defending system of a network attack according to an embodiment of the present disclosure, and fig. 7 includes a server 70 and a client 72, wherein the server includes the apparatus described in the above embodiment; the client comprises the device described in the above embodiments.

It should be noted that, the above modules may be implemented by software or hardware, and for the latter, the following may be implemented, but not limited to: the modules are all positioned in the same processor; alternatively, the modules are respectively located in different processors in any combination.

Example 3

Embodiments of the present disclosure also provide a storage medium having a computer program stored therein, wherein the computer program is configured to perform the steps in any of the above method embodiments when executed.

Alternatively, in the present embodiment, the storage medium may be configured to store a computer program for executing the steps of:

s1, receiving a handshake confirmation message sent by a client in a third handshake process, wherein the handshake confirmation message carries an authentication field, and the authentication field is generated based on the handshake message sent by the server to the client in the second handshake process;

s2, judging whether the authentication field is matched with a preset field;

s3, if the authentication field is not matched with the preset field, the network connection between the server and the client is disconnected.

Optionally, in this embodiment, the storage medium may include, but is not limited to: various media capable of storing computer programs, such as a usb disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a removable hard disk, a magnetic disk, or an optical disk.

Embodiments of the present disclosure also provide an electronic device, comprising a memory having a computer program stored therein and a processor configured to execute the computer program to perform the steps in any of the above method embodiments.

Optionally, the electronic device may further include a transmission device and an input/output device, wherein the transmission device is connected to the processor, and the input/output device is connected to the processor.

Optionally, in this embodiment, the processor may be configured to execute the following steps by a computer program:

s2, judging whether the authentication field is matched with a preset field;

Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments and optional implementation manners, and this embodiment is not described herein again.

Fig. 8 is a block diagram of an electronic device according to an embodiment of the disclosure, as shown in fig. 8, including a processor 81, a communication interface 82, a memory 83 and a communication bus 84, where the processor 81, the communication interface 82, and the memory 83 complete communication with each other through the communication bus 84, and the memory 83 is used for storing a computer program; and a processor 81 for executing the program stored in the memory 83.

The above-mentioned serial numbers of the embodiments of the present disclosure are merely for description and do not represent the merits of the embodiments.

In the above embodiments of the present disclosure, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.

In the embodiments provided in the present disclosure, it should be understood that the disclosed technology can be implemented in other ways. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one type of division of logical functions, and there may be other divisions when actually implemented, for example, a plurality of units or components may be combined or may be integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, units or modules, and may be in an electrical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present disclosure may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present disclosure may be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present disclosure. And the aforementioned storage medium includes: a U-disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a removable hard disk, a magnetic or optical disk, and other various media capable of storing program codes.

The foregoing is merely a preferred embodiment of the present disclosure, and it should be noted that modifications and embellishments could be made by those skilled in the art without departing from the principle of the present disclosure, and these should also be considered as the protection scope of the present disclosure.

Claims

1. A method for defending against network attacks is applied to a server and comprises the following steps:

receiving a handshake confirmation message sent by a client in a third handshake process, wherein the handshake confirmation message carries an authentication field, and the authentication field is generated based on the handshake message sent by the server to the client in the second handshake process;

judging whether the authentication field is matched with a preset field or not;

and if the authentication field is not matched with the preset field, disconnecting the network connection between the server and the client.

2. The method according to claim 1, wherein the message content of the handshake confirmation message is a ciphertext, and before the determining whether the authentication field matches a preset field, the method further comprises:

decrypting the message content of the handshake confirmation message to obtain a plaintext field;

and extracting the authentication field at a preset position of the plaintext field.

3. The method of claim 1, wherein determining whether the authentication field matches a predetermined field comprises:

locally reading a preset field in the handshake message;

judging whether the byte contents of the authentication field and the preset field are consistent or not;

if the byte content of the authentication field is consistent with that of the preset field, the authentication field is matched; and if the byte content of the authentication field is inconsistent with the byte content of the preset field, the authentication field is not matched.

4. The method of claim 1, further comprising:

if the authentication field is not matched with the preset field, generating an illegal connection log;

and if the log quantity of the illegal connection log is accumulated to a threshold quantity within a preset time period, generating alarm information.

5. The method of claim 1, wherein before receiving a handshake confirmation message sent by a client in the third handshake process, the method further comprises:

receiving a connection request sent by the client in a first handshake process;

returning the handshake message to the client based on the connection request in a second handshake process, wherein the handshake message carries the preset field, so that the client generates a handshake confirmation message according to the preset field;

and locally recording the preset field, wherein the preset field corresponds to the authentication field.

6. The method of claim 1, wherein the preset field is included in one or more of the following messages: server handshake messages, certificate messages, server key exchange messages, certificate request messages, and server handshake completion messages.

7. The method according to claim 6, wherein the preset field is included in a server random number and/or a custom field of the server handshake message.

8. A method for defending against network attacks is applied to a client and comprises the following steps:

receiving a handshake message sent by a server in a second handshake process, wherein the handshake message carries a preset field;

generating a handshake confirmation message based on the preset field, wherein the handshake confirmation message carries an authentication field, and the authentication field corresponds to the preset field;

and sending the handshake confirmation message to the server in the third handshake process so that the server judges whether the current connection is legal or not through an authentication field in the handshake confirmation message.

9. The method of claim 8, wherein generating the handshake confirmation message based on the preset field comprises:

extracting the preset field at a preset position of the handshake message;

adding a protocol version number of the client at a first field position, adding the preset field at a second field position, and adding a first random number at a third field position;

and encrypting the protocol version number of the client, the preset field and the first random number to generate the handshake confirmation message.

10. The method of claim 9, wherein the extracting the preset field at a preset position of the handshake message comprises:

extracting a second random number in the handshake message;

extracting a number of bytes of the second random number and determining the number of bytes as the preset field.

11. The method of claim 8, wherein the handshake messages comprise at least one of: server handshake messages, certificate messages, server key exchange messages, certificate request messages, and server handshake completion messages.

12. A defending device of network attack is characterized in that the defending device is applied to a server and comprises:

the receiving module is used for receiving a handshake confirmation message sent by a client in a third handshake process, wherein the handshake confirmation message carries an authentication field, and the authentication field is generated based on the handshake message sent by the server to the client in the second handshake process;

the judging module is used for judging whether the authentication field is matched with a preset field or not;

and the defense module is used for disconnecting the network connection between the server and the client if the authentication field is not matched with the preset field.

13. A defending device for network attack is characterized in that the defending device is applied to a client and comprises:

the receiving module is used for receiving a handshake message sent by the server in a second handshake process, wherein the handshake message carries a preset field;

the generating module is used for generating a handshake confirmation message based on the preset field;

and the sending module is used for sending the handshake confirmation message to the server in the third handshake process so that the server judges whether the current connection is legal or not through an authentication field in the handshake confirmation message, wherein the authentication field corresponds to a preset field.

14. A defense system for network attack is characterized in that the defense system comprises a server and a client, wherein,

the server comprising means for performing the steps of any of claims 1-7;

the client comprises means for performing the steps of any of claims 8-11.

15. A storage medium, characterized in that the storage medium comprises a stored program, wherein the program is operative to perform the method steps of any of the preceding claims 1 to 11.

16. An electronic device comprises a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory are communicated with each other through the communication bus; wherein:

a memory for storing a computer program;

a processor for performing the method steps of any of claims 1 to 11 by executing a program stored on a memory.