A method and apparatus for detecting brute-force attacks on RDP.

Abstract

This disclosure relates to the field of network intrusion detection technology, and discloses a method and apparatus for detecting RDP brute-force attacks. The method includes: acquiring transmitted data; determining whether the transmitted data is an RDP data stream using a preset method; when the transmitted data is an RDP data stream, determining the RDP protocol version corresponding to the RDP data stream; when the RDP protocol version of the RDP data stream is a first version, using a first detection method to detect whether brute-force attacks exist between the RDP server and the client; when the RDP protocol version of the RDP data stream is a second version, using a second detection method to detect whether brute-force attacks exist between the RDP server and the client. The method provided in this disclosure, which determines the corresponding detection method based on the RDP protocol version, can more easily detect whether brute-force attacks exist between the RDP server and the client, thereby improving the accuracy of RDP brute-force attack detection.

Description

Technical Field

[0001] This invention relates to the field of network intrusion detection technology, specifically to a method and apparatus for detecting RDP brute-force attacks. Background Technology

[0002] Remote Desktop Protocol (RPD) is a protocol that allows users to remotely access computer desktops and is widely used for remote work by businesses and individuals. RDP can become a target for network intrusion attacks, especially for brute-force attacks to obtain login credentials for remote computers. Although the success rate of RDP brute-force attacks is low, they are frequent and persistent, posing a threat to network security.

[0003] In related technologies, there is often a possibility of false positives and false negatives in brute-force attacks, and the effectiveness of brute-force attack identification is not accurate enough. This poses a great threat to the security of networks and systems, and a better solution is needed. Summary of the Invention

[0004] In view of this, the present invention provides an RDP brute-force attack detection method and apparatus to solve the problem of poor identification effect of devices using the RDP protocol when subjected to brute-force attacks, resulting in low system security.

[0005] This disclosure provides a method for detecting brute-force attacks on RDP servers. The method includes: acquiring transmission data between an RDP server and a client; determining whether the transmission data is an RDP data stream using a preset method; when the transmission data is an RDP data stream, and the result of RDP protocol verification of the RDP data stream is successful, determining the RDP protocol version corresponding to the RDP data stream, wherein the RDP protocol version is used to characterize whether the RDP protocol conforms to the RDP data stream is a first version or a second version; when the RDP protocol version of the RDP data stream is a first version, detecting whether brute-force attacks exist between the RDP server and the client using a first detection method; and when the RDP protocol version of the RDP data stream is a second version, detecting whether brute-force attacks exist between the RDP server and the client using a second detection method.

[0006] This disclosure also provides a detection device, comprising: a first determining module for acquiring transmission data between an RDP server and a client, and determining whether the transmission data is an RDP data stream using a preset method; a second determining module for determining the RDP protocol version corresponding to the RDP data stream when the transmission data is an RDP data stream and the RDP protocol verification result of the RDP data stream is successful, wherein the RDP protocol version is used to characterize whether the RDP data stream conforms to a first version or a second version of the RDP protocol; a first detection module for detecting whether there is a brute-force attack between the RDP server and the client when the RDP protocol version of the RDP data stream is the first version, using a first detection method; and a second detection module for detecting whether there is a brute-force attack between the RDP server and the client when the RDP protocol version of the RDP data stream is the second version, using a second detection method.

[0007] This disclosure also provides a computer-readable storage medium storing computer instructions for enabling a computer to implement the aforementioned RDP brute-force detection method.

[0008] This disclosure also provides a computer program product, including computer instructions for causing a computer to execute the aforementioned RDP brute-force detection method.

[0009] The RDP brute-force attack detection method and apparatus of the above embodiments of this disclosure acquire the RDP data stream between the RDP server and the client, verify the RDP protocol of the RDP data stream, determine the RDP protocol version corresponding to the RDP data stream, and perform brute-force attack detection on the RDP data stream using either the first detection method or the second detection method according to the different protocol versions of the RDP data stream, thereby determining whether brute-force attacks exist between the RDP server and the client. By determining the corresponding detection method based on the RDP protocol version, it is easier to detect whether brute-force attacks exist between the RDP server and the client, thereby improving the accuracy of RDP brute-force attack detection. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the specific embodiments or related technologies of this disclosure, the accompanying drawings used in the description of the specific embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1a An exemplary schematic diagram of the architecture of a detection device used in an RDP brute-force attack detection method according to an embodiment of the present disclosure is shown;

[0012] Figure 1b This is a flowchart illustrating an RDP brute-force attack detection method provided in an embodiment of this disclosure;

[0013] Figure 2 This is a schematic diagram of the RDP protocol verification process of an RDP brute-force attack detection method provided in this embodiment of the disclosure;

[0014] Figure 3 This is a schematic flowchart of the first detection method of an RDP brute-force attack detection method provided in this embodiment of the disclosure;

[0015] Figure 4 This is a schematic diagram of the second detection method of an RDP brute-force attack detection method provided in this embodiment of the disclosure;

[0016] Figure 5 This is a schematic diagram of the structure of a detection device provided in an embodiment of this disclosure;

[0017] Figure 6 This is a schematic diagram of the structure of another detection device provided in the embodiments of this disclosure. Detailed Implementation

[0018] RDP is a protocol for remote desktop access, allowing users to connect to a network-enabled computer and perform tasks similar to local operations. RDP is widely used in remote management, technical support, and remote work, and is an indispensable part of modern information technology infrastructure. However, the prevalence of RDP also makes it a target for attackers, particularly those attempting to obtain login credentials for remote computers through brute-force attacks.

[0019] According to relevant security analysis reports, RDP brute-force attacks are a major threat in the current cybersecurity field. Hundreds of computers are potentially vulnerable to brute-force attacks every day. Although these attacks are typically short-lived—approximately 90% end within a week, and the attacks usually last 2-3 days—brute-force attacks continue to occur frequently. The report points out that while the success rate of RDP brute-force attacks is low, with only about 0.08% of attempts ultimately succeeding, the high frequency and persistence of these attacks still place enormous pressure on cybersecurity.

[0020] The following problems often exist in related technologies:

[0021] 1. In related technologies, the RDP protocol version is often ignored during brute-force attack detection, and only a single detection method is used. This may result in the detection method being unable to adapt to changes in different RDP protocol versions, thus affecting the accuracy of the detection results.

[0022] 2. Related technologies typically rely on detecting a large number of abnormal accesses within a short period of time for brute-force attack detection, without considering the relationship between the number of bytes sent in each data stream and the brute-force attack, which may reduce the accuracy and timeliness of brute-force attack detection;

[0023] 3. Brute-force attack detection in related technologies often focuses on detecting and counting the number of brute-force attacks, while neglecting to determine whether the brute-force attack was successful, resulting in insufficient comprehensiveness of the detection results.

[0024] To address the aforementioned issues, various embodiments of this disclosure provide an RDP brute-force attack detection method. The method includes: acquiring transmission data between an RDP server and a client; determining whether the transmission data is an RDP data stream using a preset method; when the transmission data is an RDP data stream, and the RDP protocol verification result for the RDP data stream is successful, determining the RDP protocol version corresponding to the RDP data stream, where the RDP protocol version indicates whether the RDP data stream conforms to a first version or a second version; when the RDP protocol version of the RDP data stream is the first version, using a first detection method to detect whether a brute-force attack exists between the RDP server and the client; and when the RDP protocol version of the RDP data stream is the second version, using a second detection method to detect whether a brute-force attack exists between the RDP server and the client.

[0025] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0026] Please refer to Figure 1a , Figure 1a This diagram illustrates an exemplary schematic of the architecture of a detection device used in an RDP brute-force attack detection method according to an embodiment of this disclosure. Figure 1a As shown, the detection device may include a determination module and a detection module.

[0027] like Figure 1a As shown, the detection device is deployed in the network environment where the RDP server and client are located.

[0028] The deployment location of the detection device may include, but is not limited to: the network environment where the RDP server is located, the network environment where the client is located, or an intermediate network node between the client and the RDP server.

[0029] For example, the detection device can be deployed on the firewall of the RDP server or client, or on the gateway between the client and the RDP server.

[0030] The determination module in the detection device can be used to determine the type and protocol version of the data stream between the client and the RDP server. The detection module in the detection device can be used to perform brute-force detection based on the protocol version of the data stream using the corresponding detection method.

[0031] An RDP server can be a computer or device that receives and responds to remote desktop connection requests, and can be provided by an operating system that supports the RDP protocol; a client can be a device or application that initiates a remote desktop connection, allowing users to access a remote computer, control the remote desktop, and interact with it through a graphical interface.

[0032] Further reference Figure 1b , Figure 1b This is a flowchart illustrating an RDP brute-force attack detection method provided in this disclosure embodiment, applied to the above-mentioned... Figure 1a The detection device shown in the figure, the method process may include the following steps:

[0033] Step S101: Obtain the transmission data between the RDP server and the client, and use a preset method to determine whether the transmission data is an RDP data stream.

[0034] In this embodiment, the data transmitted between the RDP server and the client may include various data packets and messages transmitted between the two parties; the RDP data stream may refer to the communication data stream between the RDP client and the server, and the RDP data stream may include, but is not limited to, various requests and input information from the client to the RDP server, as well as desktop images and status information from the server to the client.

[0035] As an example, an RDP data stream can include control packets and session packets. Control packets can be used to manage the lifecycle of a remote desktop session and the transmission of control information, while session packets can be used to transmit user input, screen images, device redirection, clipboard data, etc.

[0036] Here, the control data packet may include at least one of the following: session initialization data packet, handshake data packet, authentication data packet, and the session data packet may include at least one of the following: image update data packet, input event data packet, clipboard synchronization data packet.

[0037] Determining whether transmitted data is an RDP data stream using a preset method can refer to using a preset method to initially determine whether the transmitted data conforms to the characteristics of an RDP data stream.

[0038] As an example, determining whether transmitted data is an RDP data stream using a preset method may include, but is not limited to: determining whether it is an RDP data stream based on the destination port of the transmitted data, and determining whether it is an RDP data stream based on the content characteristics of the transmitted data.

[0039] The RDP protocol used for transmitting RDP data streams defaults to Transmission Control Protocol (TCP) port 3389. Therefore, by checking if the destination port of the transmitted data is 3389, it can be preliminarily determined that the transmitted data conforms to the characteristics of an RDP data stream. The content characteristics of an RDP data stream can include user input events and desktop graphics transmissions, and it can be used to determine whether it is an RDP data stream.

[0040] Step S102: When the transmitted data is an RDP data stream, if the result of the RDP protocol verification of the RDP data stream is that the verification is successful, the RDP protocol version corresponding to the RDP data stream is determined.

[0041] In this embodiment, the RDP protocol version is used to indicate whether the RDP data stream conforms to a first version or a second version of the RDP protocol. The first version can be a newer version, and the second version can be an older version.

[0042] Here, because the RDP protocol has been updated, the old version of the RDP protocol before the update used the Secure Sockets Layer (SSL) encryption protocol, while the new version after the update uses the Transport Layer Security (TLS) encryption protocol.

[0043] RDP protocol verification is performed on the RDP data stream to determine the corresponding RDP protocol version. This can include: in the initial stage of the RDP server-client session, detecting the protocol type used during the handshake negotiation between the RDP server and client; if the protocol type is determined to be SSL, the RDP protocol version corresponding to the RDP data stream is determined to be version 2; if the protocol type is determined to be TLS, the RDP protocol version corresponding to the RDP data stream is determined to be version 1.

[0044] Step S103: When the RDP protocol version of the RDP data stream is version 1, the first detection method is used to detect whether there is a brute-force attack between the RDP server and the client.

[0045] In this embodiment, when the RDP protocol of the RDP data stream adopts the TLS protocol, a first detection method matching the TLS protocol is used to determine whether there is a brute-force attack between the RDP server and the client.

[0046] As an example, methods to determine whether a brute-force attack exists between an RDP server and client can include, but are not limited to: determining this based on a large number of failed login requests within a short period; determining this based on the login failure status codes; determining this based on the frequency of common password combinations appearing; and determining this based on the time interval between login attempts. Common password combinations can include "123456" or "password," etc. If multiple login attempts with common password combinations are observed within a short period, it can be considered that a possible brute-force attack exists.

[0047] Step S104: When the RDP protocol version of the RDP data stream is version 2, the second detection method is used to detect whether there is a brute-force attack between the RDP server and the client.

[0048] In this embodiment, when the RDP protocol of the RDP data stream uses the SSL protocol, a first detection method matching the SSL protocol is used to determine whether there is a brute-force attack between the RDP server and the client.

[0049] In the RDP brute-force attack detection method and apparatus of the above embodiments of this disclosure, the RDP data stream between the RDP server and the client is acquired, and the RDP protocol is verified on the RDP data stream to determine whether the RDP protocol version corresponding to the RDP data stream is TLS or SSL. Depending on the different protocol versions of the RDP data stream, a first detection method or a second detection method is used to perform brute-force attack detection on the RDP data stream to determine whether brute-force attacks exist between the RDP server and the client. The detection method is determined by the RDP protocol version, so that the detection method can adapt to changes in different protocol versions, which can improve the accuracy of RDP brute-force attack detection and thus improve the security of the system. By using the first detection method and the second detection method according to different RDP protocol versions, different types of brute-force attack can be covered, enhancing the detection capability for complex attacks.

[0050] In step S101 of the above embodiment, a preset method is used to determine whether the transmitted data is an RDP data stream, which is implemented based on the following steps:

[0051] The first data packet after the TCP handshake is obtained from the transmitted data. It is determined whether the first data packet contains a preset keyword. If the first data packet contains the preset keyword, the transmitted data is determined to be an RDP data stream.

[0052] The method further includes: when the byte at the first preset position of the RDP data stream is a first value, determining that the RDP data stream is an RDP negotiation request packet sent by the client to the RDP server; when the byte at the first preset position of the RDP data stream is a second value, determining that the RDP data stream is an RDP negotiation response packet returned by the RDP server to the client.

[0053] In this embodiment, the TCP handshake can occur during the initial stage of establishing a connection between the client and the RDP server. The TCP handshake can be used to establish a reliable TCP connection between the client and the RDP server. During the three-way TCP handshake, the client and server exchange a series of control packets to ensure the reliability of the connection and the effectiveness of bidirectional communication.

[0054] Furthermore, the first data packet after the TCP handshake can be the first application layer data packet after the three-way handshake is completed and data transmission begins.

[0055] Retrieve the first data packet after the TCP handshake during data transmission and determine whether the first data packet contains a preset keyword. This may include determining whether the first data packet contains the keyword "Cookie:mstshash=username".

[0056] Here, regardless of whether the client and RDP server successfully connect, the first data packet of the RDP data stream transmitted after the TCP handshake always contains the keyword "Cookie:mstshash=username". Therefore, the presence or absence of this keyword in the data packet can be used as a criterion for determining whether a data stream belongs to the RDP data stream category.

[0057] Furthermore, determining that the transmitted data is an RDP data stream when the first data packet contains a preset keyword can include: determining that the transmitted data is an RDP data stream when the first data packet contains the keyword "Cookie:mstshash=username".

[0058] In the RDP protocol, the "Cookie" field is used to identify a specific session. mstshash can be a specific form of hash value in the RDP protocol used to identify the identity of a remote desktop session. The "username" following mstshash can represent the user identity that the client wants to log in when initiating a connection. Since the above keywords contain user identity and session identifier, they will appear in every RDP session and in the first data packet after the handshake to start the subsequent authentication and session establishment process.

[0059] When the byte at the first preset position of the RDP data stream is a first value, it is determined that the RDP data stream is an RDP negotiation request packet sent by the client to the RDP server. This can include: when the 8th byte from the end of the RDP data stream is determined to be 0x01, it is determined that the RDP data stream is an RDP negotiation request packet sent by the client to the RDP server. Here, the first preset position can refer to the 8th byte from the end of the RDP data stream, and the first value can refer to 0x01.

[0060] Here, in the RDP protocol packet structure, the 8th byte from the end can refer to the header of the protocol message, used to store flags indicating the message type or status. Hexadecimal 0x01, converted to decimal 1, can be used as an identifier for a negotiation request packet, indicating that the packet is a request during the negotiation process.

[0061] When the byte at the first preset position of the RDP data stream is the second value, determining that the RDP data stream is an RDP negotiation response packet returned by the RDP server to the client can include: when the 8th byte from the end of the RDP data stream is determined to be 0x02 (i.e., the second value), determining that the RDP data stream is an RDP negotiation response packet returned by the RDP server to the client. Here, the second value can refer to 0x02.

[0062] Here, hexadecimal 0x02 is converted to decimal 2, which can be used as an identifier for the negotiation response packet to indicate that the packet is a response in the negotiation process.

[0063] Furthermore, when it is determined that the RDP data stream is an RDP negotiation request packet sent by the client to the RDP server and there is a brute-force attack between the client and the RDP server, the client can be considered the attacker of the brute-force attack; when it is determined that the RDP data stream is an RDP negotiation response packet returned by the RDP server to the client and there is a brute-force attack between the client and the RDP server, the RDP server can be considered the attacker of the brute-force attack.

[0064] In the RDP brute-force attack detection method and apparatus of the above embodiments of this disclosure, by checking the first data packet after the TCP handshake and determining whether it contains a preset keyword, it is possible to quickly determine whether the transmitted data is an RDP data stream. This avoids tedious packet-by-packet analysis of the entire data stream, thereby greatly improving the efficiency of data stream determination. By further analyzing only the traffic containing specific preset keywords, the overhead of comprehensively parsing all traffic is avoided, thereby reducing interference with irrelevant data. By determining the position and value of specific bytes, the probability of false alarms and missed alarms can be reduced, and the accuracy of detection can be improved.

[0065] In step S102 of the above embodiment, RDP protocol verification is performed on the RDP data stream, which is achieved based on the following steps:

[0066] Based on the structural characteristics of the TPKT protocol, determine whether the RDP data stream conforms to the TPKT protocol;

[0067] When an RDP data stream conforms to the TPKT protocol, its conformity is determined based on the structural characteristics of the X.224 protocol; the X.224 protocol depends on the TPKT protocol.

[0068] When the RDP data stream conforms to the X.224 protocol, the result of the RDP protocol verification of the RDP data stream is determined to be verification passed. Verification passed indicates that the RDP data conforms to the RDP protocol. The RDP protocol depends on the X.224 protocol.

[0069] In this embodiment, the TPKT protocol can be an application-layer data transmission protocol, situated between TCP and the Connection-Oriented Transport Protocol (COTP), used to establish a bridge between COTP and TCP. The X.224 protocol can be a transport layer protocol within the RDP protocol suite, providing functionality for establishing and managing RDP sessions within the network.

[0070] Here, the TPKT protocol encapsulates application layer data, enabling different application protocols to reliably transmit using the TCP protocol. It ensures data transmission integrity by providing the structure of data packets (including headers and data portions). The X.224 protocol encapsulates and transmits data through the TPKT protocol; therefore, the X.224 protocol depends on the TPKT protocol. The RDP protocol uses the X.224 protocol for session management and control information exchange. That is, RDP messages are first encapsulated and managed using X.224 during transmission; therefore, the RDP protocol depends on the X.224 protocol.

[0071] Based on the structural characteristics of the TPKT protocol, determining whether an RDP data stream conforms to the TPKT protocol can include: determining the first and second bytes of the data portion of the RDP data stream after it has been encapsulated by the TPKT protocol; if the first byte of the data portion is 0x03 and the second byte of the data portion is 0x00, then the RDP data stream conforms to the TPKT protocol.

[0072] Here, the data portion of the RDP data stream after being encapsulated by the TPKT protocol can refer to the TCP payload, that is, the effective payload of the TCP data packet, excluding the TCP header. The first byte being 0x03 and the second byte being 0x00 are characteristic of the data portion after TPKT protocol encapsulation. The first two bytes of the TCP payload are 0x03 0x00, which is a fixed flag in the TPKT protocol header used to identify the start of the TPKT data packet.

[0073] When the RDP data stream conforms to the TPKT protocol, determining whether the RDP data stream conforms to the X.224 protocol based on the structural characteristics of the X.224 protocol can include: when the first byte in the TCP payload is 0x03 and the second byte in the data portion is 0x00, determining whether the sixth byte in the TCP payload is 0xe0 or 0xd0; when the sixth byte is 0xe0 or 0xd0, determining whether the RDP data stream conforms to the X.224 protocol.

[0074] Here, the sixth byte in the TCP payload can be a PDU type field, used to identify whether the current PDU data stream is a request or a response. Specifically, 0xe0 indicates a request, and 0xd0 indicates a response.

[0075] When these two types of PDU packets are found in the data stream, it indicates that the communication of the above data stream at the application layer (RDP protocol) is controlled by the X.224 protocol, thus confirming that the above data stream is an RDP data stream.

[0076] In the RDP brute-force attack detection method and apparatus of the above embodiments of this disclosure, by verifying whether the data flow conforms to the TPKT protocol, X.224 protocol and RDP protocol layer by layer, the real RDP session flow can be effectively identified from the network traffic. Since brute-force attacks usually generate a large number of invalid connections or traffic that does not conform to the protocol specifications, this multi-layer verification mechanism can effectively filter out legitimate RDP traffic, thereby reducing false positives and false negatives. By detecting the alternation pattern of request and response packets, abnormal request patterns can be quickly identified, thereby improving the response speed and real-time performance of brute-force attack detection.

[0077] In one possible implementation of the above embodiments, determining the RDP protocol version corresponding to the RDP data stream includes:

[0078] The third packet of the RDP data stream is obtained, and the type of handshake information in the third packet is detected. If it is determined that the third packet contains TLS handshake information, the RDP protocol corresponding to the RDP data stream is determined to be version 1; if it is determined that the third packet contains SSL handshake information, the RDP protocol corresponding to the RDP data stream is determined to be version 2.

[0079] In this embodiment, the third data packet of the RDP data stream may contain protocol negotiation information between the RDP server and the client.

[0080] When it is determined that the third data packet contains TLS handshake information, the RDP protocol corresponding to the RDP data stream is determined to be version 1. This can include: when it is determined that the third data packet contains TLS handshake information, the RDP protocol corresponding to the RDP data stream is determined to be the TLS protocol.

[0081] As an example, when the field 0x03 0x01 is detected in the third packet, it can be determined that the RDP data stream corresponds to the TLS protocol version 1.0. Here, 0x03 0x01 is only an example; the specific TLS protocol version determination bytes in the third packet are not specifically limited here.

[0082] When it is determined that the third data packet contains SSL handshake information, the RDP protocol corresponding to the RDP data stream is determined to be version 2. This can include: when it is determined that the third data packet contains SSL handshake information, the RDP protocol corresponding to the RDP data stream is determined to be the SSL protocol.

[0083] As an example, when the 0x02 field is detected in the third data packet, it can be determined that the RDP protocol corresponding to the RDP data stream is SSL protocol version 1.1. Here, 0x02 is only used as an example, and the specific SSL protocol version determination byte in the third data packet is not specifically limited here.

[0084] In the RDP brute-force attack detection method and detection device of the above embodiments of this disclosure, by analyzing the handshake information in the third data packet, the protocol version used by the RDP session can be directly confirmed, avoiding detailed analysis of the entire data stream and improving identification efficiency. Different versions of the RDP protocol use different encryption mechanisms (TLS and SSL), and their encryption strength and handshake process are different. After identifying the protocol version, corresponding brute-force attack detection strategies can be adopted based on its characteristics to improve detection efficiency and accuracy.

[0085] In one possible implementation of the above embodiments, a first detection method is used to detect whether brute-force attacks exist between the RDP server and the client, including:

[0086] The system detects whether a TLS payload exists in the RDP data stream between the RDP server and the client. When the detection result indicates that a TLS payload exists in the RDP data stream, the value of the TLS payload counter is incremented. The presence of a TLS payload indicates that a secure connection has been established between the RDP server and the client.

[0087] When the detection result is that there is no TLS payload in the RDP data stream and the value of the TLS payload counter is less than the first preset threshold, the RDP data stream is marked as a short session record;

[0088] When the number of short session records within a preset time threshold exceeds a second preset threshold, it is determined that there is a possible brute-force attack between the RDP server and the client.

[0089] In this embodiment, when a TLS payload is detected in the RDP data stream, it indicates that the RDP server and client have completed the handshake via TLS, established a secure connection, and started encrypted data transmission.

[0090] A TLS payload counter can be defined as a statistical variable used to track and record the number of TLS payload packets in an RDP data stream. Each time a TLS payload packet is detected in the RDP data stream, the counter value increments by 1 to accumulate the total number of payload packets. The incrementing counter reflects the activity level of TLS traffic in the RDP connection; continuous growth indicates that the TLS session in the data stream is proceeding normally. If the growth is interrupted or the counting suddenly stops, it may mean that the session has been interrupted or an abnormal situation has occurred.

[0091] Here, the TLS payload counter can be used in brute-force attack detection to determine whether there are abnormal attempts (brute-force attacks usually cause frequent packet transmissions, and the TLS payload counter grows faster). That is, if the counter grows abnormally, it may indicate the existence of possible brute-force attacks.

[0092] When the detection result indicates that there is no TLS payload in the RDP data stream and the value of the TLS payload counter is less than the first preset threshold, the RDP data stream is marked as a short session record. This may include: detecting whether the secure connection of the RDP data stream is broken; when the connection is broken, checking the statistical value of the TLS payload counter; if the statistical value of the TLS payload counter is less than the first preset threshold, marking the session of the aforementioned secure connection as a short session and recording the time of session breakage.

[0093] When the number of short session records within a preset time threshold exceeds a second preset threshold, it is determined that there is a possible brute-force attack between the RDP server and the client. This can include: confirming a preset observation time window, counting the number of disconnected short sessions within the preset observation time window, and marking the current RDP data stream as suspected of a brute-force attack when the number of short sessions exceeds the second preset threshold.

[0094] Here, a short session refers to an RDP connection session with a short connection duration and a small TLS payload. Because brute-force attackers test different username and password combinations through multiple, rapid attempts, each attempt generates a short session connection. Most erroneous attempts are rejected quickly, causing the session to close. Therefore, the number of short sessions increases significantly during a brute-force attack. Thus, the number of short sessions can be used to determine if a potential brute-force attack exists between the RDP server and client.

[0095] In the RDP brute-force attack detection method and device of the above embodiments of this disclosure, the statistics of TLS payload counter and short sessions are used to distinguish between normal user sessions and malicious brute-force attacks. The detection method based on connection frequency and session characteristics effectively reduces the false alarm rate and improves the accuracy of detection. By increasing or decreasing the TLS payload counter, it is possible to quickly identify whether a secure session has been established, so that while recording secure connections, false judgments of normal encrypted sessions can be eliminated, making the detection more intelligent.

[0096] In one possible implementation of the above embodiments, a second detection method is used to detect whether brute-force attacks exist between the RDP server and the client, including:

[0097] Retrieve the session termination packet and its sequence number from the RDP data stream. The session termination packet is sent by the client to the RDP server.

[0098] When the sequence number of the session termination packet belongs to the first sequence range, it is determined that there is a possible brute-force attack between the RDP server and the client, and the brute-force attack statistics table is updated.

[0099] When the sequence number of the session termination packet belongs to the second sequence range and the brute-force attack statistics table is greater than the third preset threshold, it is determined that there is a successful brute-force attack between the RDP server and the client.

[0100] In this embodiment, when a client using the SSL protocol attempts to perform a brute-force attack, it will send an end-session data packet when ending the session. The end-session data packet is used to terminate the current session connection.

[0101] Furthermore, when a client using the SSL protocol sends an RST data stream, the sequence numbers of the data packets in the RST data stream are typically within the first sequence range. However, when a brute-force attack is successful, the sequence numbers of the data packets sent by the client are typically within the second sequence range. The sequence number can be used to indicate the total number of bytes in the payload of the current data packet.

[0102] Therefore, the range of sequence numbers in the session termination data packets can be used to determine whether a possible brute-force attack exists and whether a successful brute-force attack has been achieved.

[0103] When the sequence number of the session termination packet falls within the first sequence range, it is determined that there is a possible brute-force attack between the RDP server and the client, and the brute-force attack statistics table is updated. This may include: when the sequence number of the session termination packet is around 1663, it is determined that there is a possible brute-force attack between the RDP server and the client, and the brute-force attack statistics table is updated.

[0104] When the sequence number of the session termination packet belongs to the second sequence range and the brute-force attack statistics table is greater than the third preset threshold, it is determined that there is a successful brute-force attack between the RDP server and the client. This can include: when the sequence number of the session termination packet is around 2373 and the brute-force attack statistics table is greater than the third preset threshold, it is determined that there is a successful brute-force attack between the RDP server and the client.

[0105] Here, the values ​​around 1663 and 2373 are data obtained through experimental statistics and are used only as examples; they are not strictly limited. During brute-force attacks, the attacker sends different RST packets at different stages of the attack, causing the sequence number to change from around 1663 to around 2373.

[0106] Furthermore, when the sequence number of the session termination packet is around 1663, it can indicate the presence of a potential brute-force attack or an incorrect user login password. In this case, the value of the brute-force attack statistics table is incremented by 1. The brute-force attack statistics table can be a data table or data structure used to record and analyze data related to brute-force attack detection, primarily for tracking potential brute-force attack behavior in RDP connections.

[0107] Furthermore, the third preset threshold can refer to a standard for measuring the frequency of brute-force attack activities. When the number of records in the brute-force attack statistics table exceeds this threshold, it indicates that an unusually large number of connection attempts have occurred within a specific time period.

[0108] In the RDP brute-force attack detection method and apparatus of the above embodiments of this disclosure, by analyzing the end-session data packets in the RDP data stream, focusing on the relationship between the number of bytes sent in each data stream and brute-force attacks, and combining the data of the sequence number range and the brute-force attack statistics table, the existence of brute-force attack behavior can be accurately determined, and a timely response can be made, thereby improving the timeliness of brute-force attack detection; accurately determining whether a brute-force attack is successful can reduce unnecessary alarms and false judgments to a certain extent, thereby improving the stability of system detection; and by simultaneously detecting both possible brute-force attacks and successful brute-force attacks, the comprehensiveness of detection is improved.

[0109] In one possible implementation of the above embodiments, the method further includes:

[0110] When there is a potential brute-force attack and / or a successful brute-force attack between the RDP server and the client, an alarm notification is sent to both the RDP server and the client.

[0111] In this embodiment, when there is a possible brute-force attack and / or a successful brute-force attack between the RDP server and the client, an alarm notification is sent to the RDP server and the client. This may include: when the brute-force attack success flag is triggered, triggering a brute-force attack success alarm to indicate that an attack exists; when the possible brute-force attack flag is triggered, triggering a possible brute-force attack alarm to indicate that a brute-force attack may be in progress.

[0112] As an example, a brute-force attack alert may include at least one of the following: alert type, attack source IP, target IP, connection time information, brute-force attack statistics, and security recommendations. The alert level can be high, medium, or low. High indicates a successful brute-force attack, potentially leading to data breaches or system intrusion; medium indicates a possibility of a brute-force attack and that the attack is in progress; and low indicates some brute-force attempts have been made, but without success.

[0113] Furthermore, the methods for sending brute-force attack alerts may include, but are not limited to: email notifications, SMS notifications, and push notifications.

[0114] In the RDP brute-force attack detection method and device of the above embodiments of this disclosure, by conducting in-depth analysis of RDP data streams, an alarm notification is automatically triggered when a brute-force attack occurs, which can effectively improve the security of the RDP server and respond quickly to potential attacks.

[0115] In one embodiment, the method for detecting whether a brute-force attack exists may further include: detecting the number of concurrent connections in the RDP data stream; if the number of concurrent connections is greater than a fourth preset threshold, determining that a possible brute-force attack exists between the RDP server and the client.

[0116] In this embodiment, since normal connections between the RDP server and client, whether transferring files or sharing interfaces, do not involve multi-threaded concurrent RDP traffic, while brute-force attacks are mostly multi-threaded to increase speed, the presence of brute-force attacks can be determined by detecting the number of concurrent connections in the RDP data stream.

[0117] Here, by detecting the number of concurrent connections in the RDP data stream, concurrent brute-force attacks can be effectively identified, ensuring that potential attack behaviors are detected in a timely manner.

[0118] In one embodiment, Figure 2 This is a schematic diagram of the RDP protocol verification process of an RDP brute-force attack detection method provided in this embodiment of the present disclosure, applied to the above. Figure 1b The RDP brute-force attack detection method shown herein may include the following steps:

[0119] Step S201: Obtain TCP packets from the RDP data stream;

[0120] Step S202: Does TCP.payload[0] = 0X03 && TCP.payload[1] = 0X00 satisfy? If yes, proceed to step S203; otherwise, proceed to step S204.

[0121] Here, the first and second bytes in the TCP payload are determined. If the first byte is 0x03 and the second byte is 0x00, the RDP data stream is determined to conform to the TPKT protocol. If not, the RDP data stream is determined to not conform to the TPKT protocol.

[0122] Step S203: Does TCP.payload[5] = 0xe0 || TCP.payload[5] = 0xd0 satisfy? If TCP.payload[5] = 0xe0, proceed to step S205. If TCP.payload[5] = 0xd0, proceed to step S206. If not, proceed to step S204.

[0123] Here, we determine whether the sixth byte in the TCP payload is 0xe0 or 0xd0. If it is, we determine that the RDP data stream conforms to the X.224 protocol. If it is not, we determine that the RDP data stream does not conform to the X.224 protocol.

[0124] Step S204: The RDP data stream does not conform to the RDP protocol;

[0125] Here, when the RDP data stream does not conform to the TPKT protocol, or conforms to the TPKT protocol but not to the X.224 protocol, it is determined that the RDP data stream does not conform to the RDP protocol.

[0126] Step S205: The RDP data stream conforms to the RDP protocol and is a request;

[0127] Here, when TCP.payload[5] = 0xe0, the RDP data stream conforms to the RDP protocol, and the TCP payload represents the request;

[0128] Step S206: The RDP data stream conforms to the RDP protocol and is a response;

[0129] Here, when TCP.payload[5] = 0xd0, the RDP data stream conforms to the RDP protocol, and the TCP payload represents the response.

[0130] In one embodiment, Figure 3 This is a schematic flowchart of the first detection method of an RDP brute-force attack detection method provided in this disclosure embodiment, applied to the above-mentioned... Figure 1b The RDP brute-force attack detection method shown herein may include the following steps:

[0131] Step S301: Obtain TCP packets from the RDP data stream;

[0132] Step S302: Determine if it conforms to the TPKT protocol; if yes, proceed to step S303; otherwise, end.

[0133] Step S303: Determine whether it conforms to the X.224 protocol; if yes, if the sixth byte in the TCP payload is 0xe0, proceed to step S305; if the sixth byte in the TCP payload is 0xd0, proceed to step S306.

[0134] Step S304: Determine if it is a TLS payload; if yes, proceed to step S307; otherwise, proceed to step S308.

[0135] Here, we check if a payload exists in the TCP data packet;

[0136] Step S305: Mark that a request has been sent;

[0137] Here, the TCP load characterization request is determined and marked as a sent request;

[0138] Step S306: Mark X.224 connection as successful;

[0139] Here, the TCP payload characterization response is determined, and the X.224 connection is marked as successful, i.e., a secure connection is established;

[0140] Step S307: Determine whether an X.224 connection (i.e., a secure connection) has been established; if yes, proceed to step S309; ​​otherwise, proceed to step S310.

[0141] Here, the existence of a payload in the TCP packet confirms that an X.224 connection has been established.

[0142] Step S308: Determine whether the security connection has been disconnected. If so, proceed to step S310.

[0143] Here, based on the absence of a payload in the TCP packet, it is determined that an X.224 connection was established and then closed.

[0144] Step S309, TLS payload counter +1;

[0145] Step S310: If the RDP protocol is met and the TLS payload counter is less than the first threshold, proceed to step S311; otherwise, proceed to step S312.

[0146] Step S311: Mark as a short session record and record the time;

[0147] Step S312: Determine whether the number of short session records within a preset time threshold is greater than the second preset threshold; if so, proceed to step S313.

[0148] Step S313: Determine if a possible brute-force attack exists.

[0149] In one embodiment, Figure 4 This is a schematic flowchart of the second detection method of an RDP brute-force attack detection method provided in this disclosure embodiment, applied to the above-mentioned... Figure 1b The RDP brute-force attack detection method shown herein may include the following steps:

[0150] Step S401: Obtain the SSL version of the session packet;

[0151] Here, when the RDP protocol conforms to the SSL version, the session packet of the SSL version is obtained;

[0152] Step S402: Does the client end the session?

[0153] Step S403: Determine the sequence number of the session termination data packet; when the sequence number is around 1633, proceed to step S404; when the sequence number is around 2373 and the counter is greater than the third preset threshold, proceed to step S404.

[0154] Step S404: Determine if a possible brute-force attack exists, increment the counter by 1;

[0155] Step S405: Confirm that a successful brute-force attack has occurred.

[0156] In one embodiment, a detection device 50 is provided, which corresponds one-to-one with the RDP brute-force attack detection method described in the above embodiments. For example... Figure 5 As shown, the detection device 50 includes a first determining module 501, a second determining module 502, a first detection module 503, and a second detection module 504. The detailed descriptions of each functional module are as follows:

[0157] The first determining module 501 is used to obtain the transmission data between the RDP server and the client, and to determine whether the transmission data is an RDP data stream using a preset method.

[0158] The second determining module 502 is used to determine the RDP protocol version corresponding to the RDP data stream when the transmitted data is an RDP data stream and the result of the RDP protocol verification of the RDP data stream is that the verification is successful. The RDP protocol version is used to characterize whether the RDP protocol conformed to by the RDP data stream is the first version or the second version.

[0159] The first detection module 503 is used to detect whether there is a brute-force attack between the RDP server and the client when the RDP protocol version of the RDP data stream is the first version;

[0160] The second detection module 504 is used to detect whether there is a brute-force attack between the RDP server and the client when the RDP protocol version of the RDP data stream is version 2.

[0161] In one embodiment, the first determining module 501 is used to obtain the first data packet after the TCP handshake in the transmitted data, determine whether the first data packet contains a preset keyword, and determine that the transmitted data is an RDP data stream when the first data packet contains the preset keyword.

[0162] The detection device 50 also includes a third determining module 505, wherein:

[0163] The third determining module 505 is used to determine that the RDP data stream is an RDP negotiation request packet sent by the client to the RDP server when the byte at the first preset position of the RDP data stream is a first value; and to determine that the RDP data stream is an RDP negotiation response packet returned by the RDP server to the client when the byte at the first preset position of the RDP data stream is a second value.

[0164] In one embodiment, the second determining module 502 is used to determine whether the RDP data stream conforms to the TPKT protocol based on the structural features of the TPKT protocol;

[0165] When an RDP data stream conforms to the TPKT protocol, its conformity is determined based on the structural characteristics of the X.224 protocol; the X.224 protocol depends on the TPKT protocol.

[0166] When an RDP data stream conforms to the X.224 protocol, the result of RDP protocol verification of the RDP data stream is determined as verification passed. Verification passed indicates that the RDP data conforms to the RDP protocol; the RDP protocol depends on the X.224 protocol.

[0167] In one embodiment, the second determining module 502 is used to obtain the third data packet of the RDP data stream, detect the type of handshake information in the third data packet, and determine that the RDP protocol corresponding to the RDP data stream is the first version when the third data packet contains TLS handshake information; and determine that the RDP protocol corresponding to the RDP data stream is the second version when the third data packet contains SSL handshake information.

[0168] In one embodiment, the first detection module 503 is used to detect whether there is a TLS payload in the RDP data stream between the RDP server and the client. When the detection result is that there is a TLS payload in the RDP data stream, the value of the TLS payload counter is incremented. The presence of a TLS payload can indicate that a secure connection has been established between the RDP server and the client.

[0169] When the detection result is that there is no TLS payload in the RDP data stream and the value of the TLS payload counter is less than the first preset threshold, the RDP data stream is marked as a short session record;

[0170] When the number of short session records within a preset time threshold exceeds a second preset threshold, it is determined that there is a possible brute-force attack between the RDP server and the client.

[0171] In one embodiment, the second detection module 504 is used to obtain the session termination data packet in the RDP data stream and the sequence number of the session termination data packet, wherein the session termination data packet is sent by the client to the RDP server;

[0172] When the sequence number of the session termination packet belongs to the first sequence range, it is determined that there is a possible brute-force attack between the RDP server and the client, and the brute-force attack statistics table is updated.

[0173] When the sequence number of the session termination packet belongs to the second sequence range and the brute-force attack statistics table is greater than the third preset threshold, it is determined that there is a successful brute-force attack between the RDP server and the client.

[0174] In one embodiment, the detection device 50 further includes an alarm module 506, wherein:

[0175] The alarm module 506 is used to send alarm notifications to the RDP server and client when there is a possible brute-force attack and / or a successful brute-force attack between the RDP server and the client.

[0176] It should be noted that the detection device provided in the above embodiments is only illustrated by the division of the above program modules when implementing the corresponding RDP brute-force attack detection method. In practical applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the above system can be divided into different program modules to complete all or part of the processing described above. In addition, the system provided in the above embodiments and the corresponding Figure 1b The embodiments of the methods shown belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0177] This disclosure also provides a computer device having the above-described features. Figure 5 The detection device shown.

[0178] Please refer to 6. Figure 6 This is a schematic diagram of another detection device provided in an embodiment of this disclosure, as shown below. Figure 6 As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 6 Take a processor 10 as an example.

[0179] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0180] The memory 20 stores instructions executable by at least one processor 10 to cause at least one processor 10 to perform the method shown in the above embodiments.

[0181] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0182] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0183] The computer device also includes an input device 30 and an output device 40. The processor 10, memory 20, input device 30, and output device 20 can be connected via a bus or other means. Figure 6 Taking the example of a connection between China and Israel via a bus.

[0184] Input device 30 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the computer device, such as a touchscreen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 40 may include display devices, auxiliary lighting devices (e.g., LEDs), and haptic feedback devices (e.g., vibration motors). The aforementioned display devices include, but are not limited to, liquid crystal displays, light-emitting diodes, displays, and plasma displays. In some alternative embodiments, the display device may be a touchscreen.

[0185] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0186] This disclosure also provides a computer-readable storage medium in which the methods described in this disclosure can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium after being downloaded over a network. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium may be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium may also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code that, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0187] A portion of this disclosure can be applied to computer program products, such as computer program instructions, which, when executed by a computer, can invoke or provide methods and / or technical solutions according to this disclosure through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, and installation package files. Accordingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions; the computer compiling the instructions and then executing the corresponding compiled program; the computer reading and executing the instructions; or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0188] Although embodiments of the present disclosure have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for detecting brute-force attacks on RDP, characterized in that, The method includes: Obtain the transmission data between the RDP server and the client, and use a preset method to determine whether the transmission data is an RDP data stream; When the transmitted data is the RDP data stream, if the result of the RDP protocol verification of the RDP data stream is that the verification is successful, the RDP protocol version corresponding to the RDP data stream is determined. The RDP protocol version is used to characterize whether the RDP protocol conformed to by the RDP data stream is the first version or the second version. The step of determining the RDP protocol version corresponding to the RDP data stream includes: The third data packet of the RDP data stream is obtained, and the type of handshake information in the third data packet is detected. If it is determined that the third data packet contains TLS handshake information, the RDP protocol corresponding to the RDP data stream is determined to be version 1; if it is determined that the third data packet contains SSL handshake information, the RDP protocol corresponding to the RDP data stream is determined to be version 2. When the RDP protocol version of the RDP data stream is the first version, a first detection method is used to detect whether there is a brute-force attack between the RDP server and the client, including: The system detects whether a TLS payload exists in the RDP data stream between the RDP server and the client. When the detection result indicates that the TLS payload exists in the RDP data stream, the value of the TLS payload counter is incremented. The presence of the TLS payload indicates that a secure connection has been established between the RDP server and the client. When the detection result indicates that the TLS payload is not present in the RDP data stream and the value of the TLS payload counter is less than a first preset threshold, the RDP data stream is marked as a short session record. When the number of short session records within a preset time threshold exceeds a second preset threshold, it is determined that there is a possible brute-force attack between the RDP server and the client. When the RDP protocol version of the RDP data stream is the second version, a second detection method is used to detect whether there is a brute-force attack between the RDP server and the client, including: Obtain the session termination packet and the sequence number of the session termination packet from the RDP data stream, wherein the session termination packet is sent by the client to the RDP server; When the sequence number of the session termination packet belongs to the first sequence range, it is determined that there is a possible brute-force attack between the RDP server and the client, and the brute-force attack statistics table is updated. When the sequence number of the session termination data packet belongs to the second sequence range and the brute-force attack statistics table is greater than the third preset threshold, it is determined that there is a successful brute-force attack between the RDP server and the client.

2. The method according to claim 1, characterized in that, The method for determining whether the transmitted data is an RDP data stream is based on the following steps: The first data packet after the TCP handshake is obtained from the transmitted data. It is determined whether the first data packet contains a preset keyword. If the first data packet contains the preset keyword, the transmitted data is determined to be an RDP data stream. The method further includes: when the byte at the first preset position of the RDP data stream is a first value, determining that the RDP data stream is an RDP negotiation request packet sent by the client to the RDP server; When the byte at the first preset position of the RDP data stream is a second value, the RDP data stream is determined to be an RDP negotiation response packet returned by the RDP server to the client.

3. The method according to claim 1, characterized in that, The RDP protocol verification of the RDP data stream is performed based on the following steps: Based on the structural characteristics of the TPKT protocol, determine whether the RDP data stream conforms to the TPKT protocol; When the RDP data stream conforms to the TPKT protocol, it is determined whether the RDP data stream conforms to the X.224 protocol based on the structural characteristics of the X.224 protocol; the X.224 protocol depends on the TPKT protocol. When the RDP data stream conforms to the X.224 protocol, the result of the RDP protocol verification of the RDP data stream is determined to be verification passed, wherein the verification passed indicates that the RDP data stream conforms to the RDP protocol; the RDP protocol depends on the X.224 protocol.

4. The method according to any one of claims 1-3, characterized in that, The method further includes: When there is a possible brute-force attack and / or a successful brute-force attack between the RDP server and the client, an alarm notification is sent to the RDP server and the client.

5. A detection device, characterized in that, The device includes: The first determining module is used to obtain the transmission data between the RDP server and the client, and to determine whether the transmission data is an RDP data stream using a preset method. The second determining module is used to determine the RDP protocol version corresponding to the RDP data stream when the transmitted data is the RDP data stream and the result of the RDP protocol verification of the RDP data stream is that the verification is passed. The RDP protocol version is used to characterize whether the RDP protocol conformed to by the RDP data stream is a first version or a second version. Specifically, the second determining module is used to obtain the third data packet of the RDP data stream, detect the type of handshake information in the third data packet, and determine that the RDP protocol corresponding to the RDP data stream is the first version when the third data packet contains TLS handshake information; and determine that the RDP protocol corresponding to the RDP data stream is the second version when the third data packet contains SSL handshake information. The first detection module is used to detect, using a first detection method, whether there is a brute-force attack between the RDP server and the client when the RDP protocol version of the RDP data stream is the first version. The first detection module is specifically used to detect whether a TLS payload exists in the RDP data stream between the RDP server and the client. When the detection result indicates that the TLS payload exists in the RDP data stream, the value of the TLS payload counter is incremented. The existence of the TLS payload indicates that a secure connection has been established between the RDP server and the client. When the detection result indicates that the TLS payload is not present in the RDP data stream and the value of the TLS payload counter is less than a first preset threshold, the RDP data stream is marked as a short session record. When the number of short session records within a preset time threshold exceeds a second preset threshold, it is determined that there is a possible brute-force attack between the RDP server and the client. The second detection module is used to detect, using a second detection method, whether there is a brute-force attack between the RDP server and the client when the RDP protocol version of the RDP data stream is the second version. The second detection module is specifically used to obtain the session termination data packet in the RDP data stream, as well as the sequence number of the session termination data packet, wherein the session termination data packet is sent by the client to the RDP server. When the sequence number of the session termination packet belongs to the first sequence range, it is determined that there is a possible brute-force attack between the RDP server and the client, and the brute-force attack statistics table is updated. When the sequence number of the session termination data packet belongs to the second sequence range and the brute-force attack statistics table is greater than the third preset threshold, it is determined that there is a successful brute-force attack between the RDP server and the client.

6. A computer device, characterized in that, include: A memory and a processor are interconnected, the memory stores computer instructions, and the processor executes the computer instructions to perform the RDP brute-force attack detection method according to any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the RDP brute-force attack detection method according to any one of claims 1 to 4.

Images