Weak password scanning behavior identification method and device, storage medium and electronic equipment

Abstract

The application relates to the technical field of computer security, and provides a weak password scanning behavior identification method and device, a storage medium and electronic equipment. The weak password scanning behavior identification method comprises the following steps: acquiring a TCP data packet in an RFB session; judging whether the RFB session is an abnormal login session according to the TCP data packet; if the RFB session is an abnormal login session, acquiring an abnormal login index corresponding to an RFB client, and judging whether there is a weak password scanning behavior against an RFB server according to the abnormal login index; wherein the abnormal login index represents the number of times that the RFB client abnormally logs in the RFB server within a unit time. The method can effectively identify the weak password scanning behavior against the RFB server, and improve the security of the network equipment.

Description

Technical Field

[0001] This invention relates to the field of computer security technology, and more specifically, to a method and apparatus for identifying weak password scanning behavior, a storage medium, and an electronic device. Background Technology

[0002] The Remote Frame Buffer (RFB) protocol is an application layer protocol used for remote control. Through this protocol, users can remotely control the desktop of network devices and obtain higher levels of control.

[0003] To achieve remote desktop control, an RFB client needs to be deployed on the user's device and an RFB server needs to be deployed on the controlled network device. The user needs to enter a login password through the RFB client to log in to the RFB server.

[0004] However, some users set relatively simple login passwords, which are considered weak passwords. Therefore, network attackers can use password dictionaries or brute-force password attacks to scan the RFB server for weak passwords, creating a large number of passwords to attempt logins in order to crack user login passwords and illegally gain access to compromised network devices. Currently, there is no effective method to detect this type of weak password scanning. Summary of the Invention

[0005] The purpose of this application is to provide a method, apparatus, storage medium, and electronic device for identifying weak password scanning behavior, so as to improve the above-mentioned technical problems.

[0006] To achieve the above objectives, this application provides the following technical solution:

[0007] In a first aspect, embodiments of this application provide a method for identifying weak password scanning behavior, comprising: acquiring Transmission Control Protocol (TCP) data packets in an RFB session; determining whether the RFB session is an abnormal login session based on the TCP data packets; wherein, the abnormal login session refers to a session in which an RFB client abnormally logs into an RFB server; if the RFB session is an abnormal login session, acquiring the abnormal login index corresponding to the RFB client, and determining whether there is weak password scanning behavior targeting the RFB server based on the abnormal login index; wherein, the abnormal login index represents the number of times the RFB client abnormally logs into the RFB server within a unit of time.

[0008] Since weak password scanning inevitably involves a large number of login attempts by attackers, and the passwords used in these login attempts are only guessed by the attackers, it will inevitably lead to a large number of login failures in a short period of time. In other words, if a large number of abnormal logins are detected in a short period of time, it can be determined that weak password scanning behavior exists.

[0009] The above method first obtains TCP packets belonging to an RFB session, and then uses these TCP packets to determine whether the RFB session is an abnormal login session. If it is an abnormal login session, it obtains the abnormal login indicator corresponding to the RFB client. Since the abnormal login indicator represents the number of times the RFB client abnormally logs into the RFB server within a unit of time, combined with the detection principle introduced above, the abnormal login indicator can effectively identify weak password scanning behavior targeting the RFB server, thereby improving the security of network devices and user accounts.

[0010] In one implementation of the first aspect, obtaining TCP packets in an RFB session includes: obtaining network packets and their corresponding five-tuple information; if it is determined from the five-tuple information that the network packet does not belong to an existing RFB session, and the application layer protocol data carried by the network packet is RFB protocol data, then the network packet is identified as a TCP packet in a newly created RFB session; if it is determined from the five-tuple information that the network packet belongs to an existing RFB session, then the network packet is identified as a TCP packet in the existing RFB session.

[0011] The above implementation utilizes the 5-tuple information of network packets to quickly filter out TCP packets belonging to the RFB session from network packets.

[0012] In one implementation of the first aspect, determining whether the RFB session is an abnormal login session based on the TCP data packet includes: reassembling the RFB protocol data carried by the TCP data packet to obtain an RFB protocol message; determining whether the login process of the RFB session will be encrypted based on the RFB protocol message; if the login process of the RFB session will be encrypted, then after determining that the RFB session has entered the encrypted transmission stage based on the RFB protocol message, counting the valid data packets in the encrypted TCP data packet to obtain the number of valid data packets, and determining whether the RFB session is an abnormal login session based on the number of valid data packets; wherein, the encrypted TCP data packet refers to the TCP data packet carrying encrypted RFB protocol data.

[0013] In recent years, some application software has introduced certain encryption mechanisms, such as Transport Layer Security (TLS), into the RFB protocol, extending it. The extended RFB protocol encrypts processes such as client login, making it impossible to determine whether an RFB session is an abnormal login session by parsing RFB protocol messages.

[0014] The above implementation determines whether an RFB session is an abnormal login session by counting the number of valid data packets in the encrypted TCP packets. It does not require parsing the RFB protocol data carried in the encrypted TCP packets (since they are encrypted, they cannot be parsed anyway). Therefore, it can also identify weak password scanning behavior even when the above extended RFB protocol is used.

[0015] In one implementation of the first aspect, the encrypted TCP data packet includes a forward data packet sent by the RFB client to the RFB server, and a reverse data packet sent by the RFB server to the RFB client; the step of counting the valid data packets in the encrypted TCP data packet to obtain the number of valid data packets, and determining whether the RFB session is an abnormal login session based on the number of valid data packets, includes: counting the valid data packets in the forward data packet and the valid data packets in the reverse data packet respectively to obtain the total number of valid data packets in both directions; if the total number of valid data packets in both directions is less than a first threshold, then the RFB session is determined to be an abnormal login session; or, counting the valid data packets in the forward data packet and the valid data packets in the reverse data packet respectively to obtain the number of valid data packets in the reverse data packet and the total number of valid data packets in both directions; if the total number of valid data packets in both directions is less than a first threshold, or the number of valid data packets in the reverse data packet is less than a second threshold, then the RFB session is determined to be an abnormal login session; or, counting the valid data packets in the reverse data packet to obtain the number of valid data packets in the reverse data packet; if the number of valid data packets in the reverse data packet is less than a second threshold, then the RFB session is determined to be an abnormal login session.

[0016] If the RFB session is an abnormal login session, the session will end soon after the login failure, so the number of valid TCP packets generated will not be large. Therefore, if the total number of valid packets in both directions is less than the first threshold, the RFB session can be determined to be an abnormal login session.

[0017] Some attackers might intentionally fragment TCP packets into smaller packets. While this doesn't increase the actual amount of valid data, it increases the total number of TCP packets, ensuring the total number of valid packets in both directions is not less than the first threshold. This allows abnormal login sessions to bypass the above checks. Considering that attackers can only control the behavior of the RFB client, not the RFB server, as a targeted measure, if the number of valid packets in the reverse data packets (data packets sent from the RFB server to the RFB client) is less than the second threshold, the RFB session can also be identified as an abnormal login session.

[0018] In one implementation of the first aspect, counting the valid data packets in the forward data packets to obtain the number of valid data packets in the forward data packets includes: counting the forward data packets to obtain the total number of forward data packets, and counting the invalid data packets in the forward data packets to obtain the number of invalid data packets in the forward data packets; subtracting the number of invalid data packets in the forward data packets from the total number of forward data packets to obtain the number of valid data packets in the forward data packets; wherein, the invalid data packets in the forward data packets include the following four categories: Category 1: Data packets with TCP sequence numbers less than the trailing edge of the upward sliding window; Category 2: Data packets with TCP sequence numbers located within the upward sliding window, and having such sequence numbers, which were previously sent but not acknowledged; Category 3: Data packets with TCP sequence numbers greater than the leading edge of the upward sliding window; Category 4: Data packets that do not carry application layer protocol data and do not belong to any of the above three categories. The method involves: 1) counting the valid data packets in the reverse data packets to obtain the number of valid data packets in the reverse data packets; 2) counting the invalid data packets in the reverse data packets to obtain the number of invalid data packets in the reverse data packets; and 3) subtracting the number of invalid data packets from the total number of reverse data packets to obtain the number of valid data packets in the reverse data packets. The invalid data packets in the reverse data packets include the following four categories: Category 1: Data packets with TCP sequence numbers less than the trailing edge of the sliding window on the reverse side; Category 2: Data packets with TCP sequence numbers within the sliding window on the reverse side, and which have been sent but not acknowledged; Category 3: Data packets with TCP sequence numbers greater than the leading edge of the sliding window on the reverse side; and Category 4: Data packets that do not carry application layer protocol data and do not belong to any of the above three categories.

[0019] In the above implementation, since four types of invalid data packets can be accurately identified, the number of valid data packets can be indirectly counted by counting the number of invalid data packets.

[0020] In one implementation of the first aspect, the method further includes: determining, based on the encrypted TCP data packet, whether the TCP connection between the RFB server and the RFB client was closed by the RFB server, and obtaining a connection closure identifier; if the connection closure identifier indicates that the TCP connection between the RFB server and the RFB client was not closed by the RFB server, then the RFB session is not an abnormal login session; if the connection closure identifier indicates that the TCP connection between the RFB server and the RFB client was closed by the RFB server, then determining whether the RFB session is an abnormal login session based on the number of valid data packets.

[0021] When using the RFB protocol for remote desktop control, the RFB client usually closes the TCP connection proactively (for example, when the user no longer needs to perform remote control). The RFB server generally does not proactively close the TCP connection. Therefore, if the RFB server proactively closes the TCP connection, it may be due to an abnormal login by the RFB client.

[0022] In the above implementation, if the connection identifier indicates that the TCP connection between the RFB server and the RFB client was not closed by the RFB server, the RFB session is directly determined to be an abnormal login session. Only when the connection closure identifier indicates that the TCP connection between the RFB server and the RFB client was closed by the RFB server, the number of valid data packets is used to determine whether the RFB session is an abnormal login session, which can make the judgment result more accurate.

[0023] In one implementation of the first aspect, the method further includes: if the login process of the RFB session is not encrypted, obtaining a return value representing the login status of the RFB client from the RFB protocol message, and determining whether the RFB protocol session is an abnormal login session based on the return value.

[0024] In the above implementation, since the login process of the RFB session is not encrypted, the RFB protocol message can be directly parsed, and the return value representing the login status of the RFB client can be used to determine whether the RFB protocol session is an abnormal login session. This method of judgment is highly accurate.

[0025] In one implementation of the first aspect, obtaining the abnormal login indicator corresponding to the RFB client includes: determining a target key value based on the Internet Protocol (IP) address of the RFB client, the IP address of the RFB server, and the port of the RFB server in the RFB session; searching for the abnormal login indicator corresponding to the target key value in a weak password scan detection table; if the search is successful, updating the found abnormal login indicator and obtaining the updated abnormal login indicator; wherein, the weak password scan detection table stores key values ​​and the abnormal login indicators corresponding to the key values, and the abnormal login indicators stored in the weak password scan detection table are reset every unit time.

[0026] In the above implementation, considering that attackers may change the source port each time they log in using the RFB client when performing weak password scanning, the target key value is determined by the IP address of the RFB client, the IP address of the RFB server, and the port of the RFB server in the RFB session. This updates the corresponding abnormal login indicators in the weak password scanning detection table, making the updates to the abnormal login indicators more reasonable. Consequently, the values ​​of the obtained abnormal login indicators are also more reasonable, which helps to improve the accuracy of weak password scanning behavior identification.

[0027] In one implementation of the first aspect, the weak password scanning behavior identification method is executed by an intermediate network device, which is independent of the devices where the RFB server and the RFB client are located; the step of obtaining TCP packets in the RFB session includes: obtaining TCP packets in the RFB session from network packets captured by the intermediate network device.

[0028] In the above implementation, since the weak password scanning behavior identification method is executed by an intermediate network device rather than by the device where the RFB server resides (let's call it the server device), the execution of the method will not affect the stability of the server device, nor will it be limited by the hardware and software environment of the server device, thus exhibiting good versatility. Furthermore, the network data packets used by the method are captured by the intermediate device in a bypass manner, meaning it will not affect the transmission process of the original data packets.

[0029] Secondly, embodiments of this application provide a weak password scanning behavior identification device, comprising: a data packet acquisition unit, configured to acquire TCP data packets in an RFB session; an abnormal login judgment unit, configured to determine whether the RFB session is an abnormal login session based on the TCP data packets; wherein, the abnormal login session refers to a session in which an RFB client abnormally logs into an RFB server; and a weak password scanning detection unit, configured to, when the RFB session is an abnormal login session, update the abnormal login index corresponding to the RFB client, and determine whether there is a weak password scanning behavior targeting the RFB server based on the abnormal login index; wherein, the abnormal login index represents the number of times the RFB client abnormally logs into the RFB server within a unit of time.

[0030] Thirdly, embodiments of this application provide a computer program product, including computer program instructions, which, when read and executed by a processor, perform the method provided in the first aspect or any possible implementation of the first aspect.

[0031] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when read and executed by a processor, perform the method provided in the first aspect or any possible implementation thereof.

[0032] Fifthly, embodiments of this application provide an electronic device, including: a memory and a processor, wherein the memory stores computer program instructions, and the computer program instructions are read and executed by the processor to perform the method provided in the first aspect or any possible implementation of the first aspect. Attached Figure Description

[0033] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0034] Figure 1 The network architecture that may be applicable to the weak password scanning behavior identification method provided in the embodiments of this application;

[0035] Figure 2 The weak password scanning behavior identification method provided in the embodiments of this application may have the following process;

[0036] Figure 3 The detection program provided in the embodiments of this application may have the following functional modules;

[0037] Figure 4 This is a diagram illustrating the sliding window mechanism used in the TCP protocol.

[0038] Figure 5 for Figure 3 The possible process for the login status recognition module to count the number of valid data packets;

[0039] Figure 6 for Figure 3 The weak password scanning and identification module in the system detects possible processes of weak password scanning;

[0040] Figure 7 for Figure 3 The possible execution flow of the timer in the weak password scanning and identification module;

[0041] Figure 8 The weak password scanning behavior recognition device provided in the embodiments of this application may have the following functional modules;

[0042] Figure 9 The electronic device provided in the embodiments of this application may have the following structure. Detailed Implementation

[0043] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. It should be noted that similar reference numerals and letters in the following drawings indicate similar items; therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings.

[0044] The terms “comprising,” “including,” or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase “comprising one…” does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0045] Figure 1 The network architecture that may be applicable to the weak password scanning behavior identification method provided in the embodiments of this application. (Refer to...) Figure 1 Using the RFB protocol, users can remotely control the desktop of a network device through their local device. That is, mouse, keyboard and other operations performed by the user on the local device can be mapped to the desktop of the network device and the operation results can be sent back to the local device for display.

[0046] To achieve remote desktop control, RFB client software, referred to as RFB client 210, needs to be deployed on the local device initiating the control (also known as client device 200); and RFB server software, referred to as RFB server 110, needs to be deployed on the network device being controlled (also known as server device 100). Client device 200 can be a user-used terminal device, such as a PC or mobile phone, while server device can be a remote (relative to client device 200) server, PC, or other similar device.

[0047] To transmit RFB protocol data, an RFB session needs to be established between the RFB client 210 and the RFB server 110. Since the RFB protocol is based on TCP, the RFB session corresponds to the TCP connection between the RFB client 210 and the RFB server 110. The RFB protocol data is carried by TCP packets in this TCP connection, which can also be called TCP packets in the RFB session.

[0048] Furthermore, before transmitting formal data frames, users need to enter a login password through RFB client 210 to log in to RFB server 110. This process is highly vulnerable to weak password scanning: network attackers can construct numerous passwords and repeatedly attempt to log in to RFB server 110 using an RFB client 210 based on these passwords. If the user's password is simple, i.e., a weak password, the attacker may successfully log in after a certain number of attempts, thus cracking the user's login password and illegally gaining certain control privileges over server device 100. To avoid this situation, it is necessary to identify attackers' weak password scanning behavior.

[0049] Continue to refer to Figure 1 To identify weak password scanning behavior, a detection program 310 can be deployed on the intermediate network device 300. The detection program 310 can execute the weak password scanning behavior identification method provided in this application embodiment, and effectively identify weak password scanning behavior based on TCP packets in the RFB session.

[0050] The intermediate network device 300 is located between the client device 200 and the server device 100, and is a different device from both the client device 200 and the server device 100. Deploying the detection program 310 on the intermediate network device offers advantages in terms of versatility and stability. In contrast, if the detection program 310 is deployed on the server device 100, its development is constrained by the server device 100's software environment (such as different operating systems or different operating system versions) or hardware environment (such as processor architecture), resulting in relatively poor versatility. Furthermore, the detection program 310 may affect the operation of the server device 100, meaning its stability is relatively poor.

[0051] Of course, the possibility of deploying the detection program 310 on the server device 100 is not excluded, but for the sake of simplicity, the following text will only take the case of deploying the detection program 310 on the intermediate network device 300 as an example.

[0052] Furthermore, the intermediate network device 300 can bypass the transmission of network data packets between the client device 200 and the server device 100 (including at least TCP data in the RFB session between the RFB client 210 and the RFB server 110) and send these network data packets to the detection program 310 for weak password scanning. Bypassing the transmission means mirroring the original network data packets. The original network data packets continue to be transmitted in the original manner, while the mirrored network data packets are sent to the detection program 310. In this way, the identification of weak password scanning will not affect the transmission of the original network data packets. Of course, the option of directly sending the original network data packets to the detection program 310 is also possible.

[0053] The intermediate network device 300 can be a router, switch, or similar device, while the detection program 310 can be deployed on the mirror port of the intermediate network device 300. The intermediate network device 300 can have... Figure 9 The structure of the electronic device shown is detailed later in the text. Figure 9 The explanation.

[0054] Figure 2 The weak password scanning behavior identification method provided in the embodiments of this application may have the following process. This method can be executed by a detection program deployed on an intermediate network device, and for details, please refer to [reference needed]. Figure 1 The intermediate network device 300 and the detection program 310 are included. (See reference...) Figure 2 Weak password scanning behavior identification methods include:

[0055] Step S410: Obtain TCP packets from the RFB session.

[0056] Step S420: Determine whether the RFB session is an abnormal login session based on the TCP data packets.

[0057] Step S430: If the RFB session is an abnormal login session, obtain the abnormal login indicator corresponding to the RFB client in the RFB session, and determine whether there is a weak password scanning behavior targeting the RFB server in the RFB session based on the abnormal login indicator.

[0058] The general logic of weak password scanning behavior identification in this application is as follows: For each RFB session that the detection program can identify, it is determined whether it belongs to an abnormal login session. An abnormal login session refers to a session in which the RFB client fails to log in to the RFB server. If the RFB session belongs to an abnormal login session, the abnormal login index corresponding to the RFB client in the RFB session is obtained, and based on the obtained abnormal login index, it is determined whether there is weak password scanning behavior targeting the RFB server in the RFB session. The abnormal login index represents the number of times the RFB client in the RFB session abnormally logs in to the RFB server in the RFB session per unit time.

[0059] Since the logic for weak password scanning behavior identification is similar for each RFB session that the detection program can identify, for the sake of simplicity, it can be considered that... Figure 2 The method described here only applies to one RFB session.

[0060] In step S410, the detection program can acquire all network data packets (e.g., TCP packets, User Datagram Protocol (UDP) packets) flowing through the intermediate network device, and filter out TCP packets belonging to a specific RFB session. Alternatively, it may first filter out a portion of the network data packets (e.g., TCP packets) from all the network data packets flowing through the intermediate network device and send them to the detection program, which then further filters out TCP packets belonging to a specific RFB session from this portion of network data packets. As mentioned above, optionally, the network data packets acquired by the detection program can be captured by the intermediate network device in a bypass manner.

[0061] In step S420, it can be determined whether the RFB session is an abnormal login session based on certain attributes of the TCP packets. These attributes may include statistical attributes of the TCP packets, such as the number of TCP packets, or the content of the TCP packets, such as the RFB protocol data carried by the TCP packets, etc.

[0062] When identifying abnormal login sessions, it's possible to use either all TCP packets obtained in step S410 or only a portion of them. Furthermore, different methods can be used to determine whether the RFB protocol data carried in the TCP packets is encrypted or unencrypted. Examples of specific methods will be provided later in the text.

[0063] Since weak password scanning inevitably involves a large number of login attempts by attackers, and the passwords used in these login attempts are only guessed by the attackers, it will inevitably lead to a large number of login failures in a short period of time. In other words, if a large number of abnormal logins are detected in a short period of time, it can be determined that weak password scanning behavior exists.

[0064] Based on the above principle, whenever step S420 determines that an RFB session is an abnormal login session, the abnormal login indicator corresponding to the RFB client is obtained in step S430. Since the abnormal login indicator represents the number of times the RFB client abnormally logs into the RFB server within a unit of time (referred to as the number of abnormal logins), when the number of abnormal logins represented by the abnormal login indicator is large (for example, exceeding a certain threshold), it can be determined that there is currently a weak password scanning behavior targeting the RFB server.

[0065] The abnormal login metric can be directly expressed as the number of abnormal logins, or it can be expressed as a value related to the number of abnormal logins, such as the number of tokens mentioned later.

[0066] Optionally, whenever step S420 determines that an RFB session is an abnormal login session, the abnormal login index corresponding to the RFB client in the RFB session can be updated first, and then the updated abnormal login index can be obtained for weak password scanning behavior identification, so as to ensure that the value of the abnormal login index can represent the number of abnormal logins of the RFB client in the most recent unit time.

[0067] Figure 2 The method described herein implements the function of identifying weak password scanning behavior in the RFB protocol scenario, filling the gap in the existing technology. This method is simple and easy to implement, and is conducive to improving the security of network devices and user accounts.

[0068] Figure 3 The detection program provided in the embodiments of this application may have functional modules. (Refer to...) Figure 3 The detection program 310 may include a data acquisition module 312, a session state recognition module 314, a login state recognition module 316, and a weak password scanning and recognition module 318. The following will combine... Figure 3 These functional modules in the description Figure 2Some possible implementations of the weak password scanning and identification method are described below. Specifically, the functions of the data acquisition module 312 largely correspond to step S410, the functions of the session state identification module 314 and the login state identification module 316 largely correspond to step S420, and the function of the weak password scanning and identification module 318 largely corresponds to step S430. It should be understood that... Figure 3 The way the functional modules are divided is only an example; alternative solutions can completely adopt the same approach. Figure 3 Different methods of dividing functional modules, or even no functional modules at all.

[0069] In one implementation, step S410 may further include the following steps:

[0070] First, obtain the network data packets and their corresponding 5-tuple information. Here, the network data packets can refer to transport layer data packets, and the 5-tuple information can be (source IP address, destination IP address, source port number, destination port number, and transport layer protocol type). The corresponding 5-tuple information can be parsed from the network data packets.

[0071] Then, if the network packet does not belong to an existing RFB session based on the 5-tuple information, and the application layer protocol data carried by the network packet is RFB protocol data, then the network packet is identified as a TCP packet in the newly established RFB session; if the network packet belongs to an existing RFB session based on the 5-tuple information, then the network packet is identified as a TCP packet in the existing RFB session.

[0072] Existing RFB sessions refer to RFB sessions that have been recorded by the detection program. Each RFB session also corresponds to a 5-tuple of information, which can uniquely identify an RFB session. For example, it can be (IP address of the RFB client, IP address of the RFB server, port of the RFB client, port of the RFB server, transport layer protocol type). The port of the RFB client refers to the port used by the RFB client in this RFB session, and the port of the RFB server refers to the port used by the RFB server in this RFB session.

[0073] Therefore, the five-tuple information of the network packet is matched with the five-tuple information of the existing RFB session. If a match is successful, it indicates that the network packet is a TCP packet in the matching RFB session; if a match fails, it indicates that the network packet is not a TCP packet in the existing RFB session. The criterion for a successful match is that all five items in the five-tuple correspond to the same value. However, it should be noted that there are packets in two directions within an RFB session: one from the RFB client to the RFB server, and the other from the RFB server to the RFB client. Therefore, during the above matching, the source (source IP address, source port) and destination (destination IP address, destination port) of the network packet are swapped, and two matches are performed. A successful match is considered successful if either match is successful.

[0074] There are actually two possibilities for a match failure: one is that the network packet is a TCP packet in an RFB session, but the RFB session is newly created and has not been recorded before, so it does not belong to an existing RFB session; the other is that the network packet is not a TCP packet in an RFB session. For example, the network packet is not a TCP packet at all, or the network packet is a TCP packet, but the application layer protocol data it carries is not RFB protocol data.

[0075] Only network packets in the first scenario are of interest to weak password scanning behavior identification. Therefore, when the five-tuple information match fails, it can be further determined whether the network packet carries application layer protocol data and whether that application layer protocol data is RFB protocol data. If it carries RFB protocol data, it indicates that the network packet is a TCP packet in a newly established RFB session (it could be the first TCP packet in this RFB session). The newly established RFB session will be recorded by the detection program, and in subsequent network packet matching processes, this newly established RFB session will be treated as an existing RFB session.

[0076] The above implementation utilizes the 5-tuple information of network packets to quickly filter out TCP packets belonging to the same RFB session from network packets.

[0077] Reference Figure 3 The data acquisition module 312 is used to filter out TCP packets belonging to the same RFB session from the network packets received by the detection program. The method used is the five-tuple information matching method described above.

[0078] Optionally, the data acquisition module 312 internally maintains a flow table. The flow table can be implemented using methods such as hash tables. Each entry in the flow table includes a five-tuple of information uniquely identifying a data flow, and may also include information such as the application layer protocol type and TCP state machine. Each RFB session is also considered a data flow, corresponding to one entry in the flow table, but a data flow is not necessarily an RFB session. Similar to an RFB session, each data flow can also include packets in both directions, but only occupies one entry.

[0079] After receiving a network data packet, the data acquisition module 312 first searches the flow table based on the five-tuple information of the network data packet (i.e., performs five-tuple information matching, note that the source and destination are swapped for matching twice). If no corresponding entry is found, a new entry is created based on the five-tuple information of the network data packet. If a corresponding entry is found, and the transport layer protocol type of the network data packet is TCP (indicating that the network data packet is a TCP data packet), the TCP state machine in the corresponding entry is updated according to the TCP flag bit in the network data packet.

[0080] If the TCP state machine of a table entry has entered the ESTABLISHED state, and the application layer protocol type of that entry is not RFB (including cases where the application layer protocol type has not yet been set), and the network packet matching the entry carries application layer protocol data, then it can be determined whether the application layer protocol data carried by the network packet is RFB protocol data. For example, application layer protocol data that meets the following two conditions is considered RFB protocol data:

[0081] (1) The length of application layer protocol data is 12 bytes;

[0082] (2) The application layer protocol data matches the regular expression “RFB\d{3}\x2e\d{3}\x0a”.

[0083] In condition (1), the length of the application layer protocol data can be calculated by subtracting the length of the network packet header (referring to the TCP header) from the total length of the network packet. In condition (2), "RFB" in the regular expression is a fixed string representing the RFB protocol, and "\d{3}\x2e\d{3}\x0a" represents the RFB protocol version, such as "003.008\n" which represents version 3.8. This can be achieved by calling a regular expression matcher, such as the Hyperscan engine and the pcre library.

[0084] After determining that the application layer protocol data carried by the network packet is RFB protocol data, the application layer protocol type of the corresponding entry can be set to RFB protocol. This operation is equivalent to confirming that the entry corresponds to a newly created RFB session, and the network packet is a packet in this newly created RFB session.

[0085] After that, until the TCP state machine of this entry changes to the CLOSED state (representing the end of the RFB session), whenever the five-tuple information of a network packet matches this entry, based on the value of the application layer protocol type of this entry (RFB protocol), it can be determined that this network packet belongs to a TCP packet in an existing RFB session, without needing to further determine this by parsing the application layer protocol data of the network packet.

[0086] The data acquisition module 312 sends all TCP packets acquired in the RFB session to the session state recognition module 314 for further processing.

[0087] In one implementation, step S420 may further include the following steps:

[0088] First, the RFB protocol data carried by the TCP packets is reassembled to obtain the RFB protocol message. The RFB protocol message is an application layer message. When transmitted using TCP packets at the transport layer, the RFB protocol message may be fragmented and carried by different TCP packets. Therefore, to parse the content of the RFB protocol message, it is necessary to reassemble the RFB protocol data carried by the TCP packets to reconstruct the RFB protocol message.

[0089] Then, based on the reconstructed RFB protocol messages, it is determined whether the login process of the RFB session is encrypted. In recent years, some application software has introduced certain encryption mechanisms (such as TLS) into the RFB protocol, extending it. The extended RFB protocol encrypts the RFB protocol messages involved in the client login process, making it impossible to determine whether an RFB session is an abnormal login session by parsing the RFB protocol messages. However, for the traditional RFB protocol, it is still possible to determine whether an RFB session is an abnormal login session by parsing the RFB protocol messages.

[0090] Note that whether the login process of an RFB session is encrypted and whether the RFB session itself is encrypted are two different concepts. Although some encryption mechanisms encrypt the data frames transmitted after the RFB client logs in, the RFB protocol messages related to the login are still transmitted in plaintext. For this type of encryption mechanism, since it is possible to determine whether the RFB session is an abnormal login session by parsing the RFB protocol messages, it can be considered no different from the RFB protocol without encryption mechanism when identifying weak password scanning behavior.

[0091] During the initial phase of an RFB session, the RFB client and RFB server negotiate data transmission security, including whether the RFB session should be encrypted and what encryption method should be used. By parsing the RFB protocol messages related to these negotiations, it can be determined whether the login process of the RFB session will be encrypted. For example, if the parsed data shows that the RFB session uses TLS encryption, it can be confirmed that the login process of the RFB session will be encrypted.

[0092] Finally, if it is determined that the login process of the RFB session will be encrypted, after determining that the RFB session has entered the encrypted transmission stage based on the RFB protocol message, the number of valid data packets in the encrypted TCP packets is counted to obtain the number of valid data packets, and the RFB session is judged as an abnormal login session based on the number of valid data packets.

[0093] Once the RFB session enters the encrypted transmission phase (RFB client login also falls under the encrypted transmission phase), the RFB protocol data carried by the TCP packets is encrypted. For simplicity, all TCP packets transmitted from the time the RFB session enters the encrypted transmission phase until the end of the RFB session are referred to as encrypted TCP packets.

[0094] According to the RFB protocol, the time when an RFB session enters the encrypted transmission phase is certain. Therefore, as long as the reassembled RFB protocol messages are continuously parsed, it can be determined whether the RFB session has entered the encrypted transmission phase. Once the encrypted transmission phase has been entered, it is no longer possible to continue parsing the RFB protocol messages.

[0095] Valid data packets can be understood as normally sent TCP data packets carrying RFB protocol data, while invalid data packets are the opposite. When counting the number of valid data packets, one can either count them directly, or first count the number of invalid data packets and then deduce the corresponding number of valid data packets. The starting point for the statistical analysis can be the start time of the encrypted transmission phase of the RFB session, and the ending point can be the end time of the RFB session.

[0096] The inventors discovered that if an RFB session is an abnormal login session, the session will end quickly after the login failure, resulting in a limited number of valid data packets. Therefore, the number of valid data packets can be used to determine whether an RFB session is an abnormal login session. For example, if the number of valid data packets is less than a certain threshold, the RFB session can be considered an abnormal login session. The reason for counting the number of valid data packets is that valid data packets are those that truly contribute to the progress of the RFB session, and therefore, the statistical results are closely related to the login status of the RFB session.

[0097] Counting the number of valid packets in encrypted TCP packets is a transport layer operation and does not involve parsing the content of RFB protocol messages. Therefore, the above method for judging abnormal login sessions is also applicable to cases where the login process for RFB sessions is encrypted. Furthermore, this method does not rely on login logs recorded by the RFB server, so it can be executed without problems on intermediate network devices (because intermediate network devices cannot obtain login logs).

[0098] Optionally, when determining whether an RFB session is an abnormal login session based on the number of valid data packets, other judgment conditions can be combined, and corresponding examples will be given later.

[0099] In addition, the above-mentioned method for judging abnormal login sessions starts counting the number of valid data packets after the RFB session enters the encrypted transmission stage. However, it is possible that in some alternative solutions, the counting of the number of valid data packets starts in an earlier stage of the RFB session.

[0100] If it is determined that the login process of the RFB session is not encrypted, the return value representing the login status of the RFB client can be obtained from the RFB protocol message, and the RFB protocol session can be judged as an abnormal login session based on the return value.

[0101] As mentioned earlier, the login process in an RFB session might not be encrypted, which could mean the entire RFB session is unencrypted, or the RFB session is encrypted, but the login process itself is not. Directly parsing the RFB protocol messages and using the return value representing the RFB client's login status to determine if the RFB session is an abnormal login session is a highly accurate method because this return value is returned by the RFB server, which can verify whether the RFB client has logged in normally. Furthermore, this method does not rely on login logs recorded by the RFB server, so it works without problems on intermediate network devices (since intermediate network devices cannot obtain login logs).

[0102] In the above implementation, methods for judging abnormal login sessions are provided for both encrypted and unencrypted client login processes in RFB sessions. This makes the judgment of abnormal login sessions adaptable to different RFB protocol configurations, thereby improving the applicability of the weak password scanning behavior recognition method.

[0103] Reference Figure 3 The functions of the session state identification module 314 include: reassembling the RFB protocol data carried in the TCP data packets received from the data acquisition module 312, identifying the session state of the RFB session based on the reassembled RFB protocol messages, and identifying the security mode of the RFB session based on the RFB protocol messages.

[0104] Optionally, after receiving the TCP data packet sent by the data acquisition module 312, the session state identification module 314 caches the TCP data packet in the corresponding reassembly table. This cache remains in the table until a TCP data packet is received from the peer (the peer is relative to the currently received TCP data packet; for example, if the current TCP data packet is sent by the RFB client, the peer TCP data packet refers to the TCP data packet sent by the RFB server) or the TCP connection is closed. If the sequence numbers of the TCP data packets cached in the reassembly table are consecutive, the RFB protocol data carried by the TCP data packets cached in the reassembly table are concatenated sequentially according to the ascending sequence number of the TCP data packets to obtain the RFB protocol message.

[0105] A TLS-encrypted RFB session can be divided into the following four phases, or four session states:

[0106] (1) Protocol version negotiation phase: used to negotiate the RFB protocol version to be used in the RFB session;

[0107] (2) Security mode negotiation phase: used to negotiate the encryption method to be used in the RFB session, including whether to encrypt, and what method (such as TLS) to use for encryption, etc.

[0108] (3) Encryption algorithm negotiation phase: used to negotiate the specific encryption algorithm to be used, such as the TLS version, etc.

[0109] (4) Other communication phases: Data transmitted from phase (3) onwards until the end of the RFB session belongs to this phase. For the case of using the TLS mechanism, phase (4) is the encrypted transmission phase mentioned above. The login behavior of the RFB client also occurs in this phase.

[0110] The session state identification module 314 can determine which stage the RFB session is currently in by parsing the reassembled RFB protocol messages. After determining that the RFB session has entered stage (2), it can further parse the RFB protocol messages to obtain the user-selected security mode and perform different operations according to different security modes. For simplicity, only the following two modes are used as examples:

[0111] (1) The security mode is VeNCrypt, which means that the RFB session is based on TLS encryption.

[0112] The session state identification module 314 can mark the RFB session as a TLS-encrypted session (this can be done in the flow table maintained by the data acquisition module 312), and then continue to reassemble the RFB protocol data of the TCP packets received from the data acquisition module 312, and continue to parse the reassembled RFB protocol messages until it is determined that the RFB session has entered stage (4), at which point the reassembly and parsing of the RFB protocol data will cease (at this point, the RFB protocol data is encrypted and cannot be parsed). After this, all TCP packets received by the session state identification module 314 will be encrypted TCP packets. By checking the above-mentioned mark in the entry corresponding to the encrypted TCP packet in the flow table, it can be confirmed that the RFB session corresponding to the encrypted TCP packet is based on TLS encryption, and thus the encrypted TCP packet can be directly sent to the login state identification module 316 for processing.

[0113] The login status identification module 316 counts the valid data packets in the received encrypted TCP packets and determines whether the RFB session is an abnormal login session based on the number of valid data packets counted. This process will be explained in detail later.

[0114] (2) The security mode is not VeNCrypt, meaning that the RFB session will not be encrypted.

[0115] The session state identification module 314 can continue to reassemble the TCP packets received from the data acquisition module 312 using the RFB protocol, and continue to parse the reassembled RFB protocol messages until it obtains a return value representing the login status of the RFB client. Based on this return value, it determines whether the RFB protocol session is an abnormal login session. If it is an abnormal login session, the triplet information corresponding to the RFB session (IP address of the RFB client, IP address of the RFB server, and port of the RFB server) is submitted to the weak password scanning identification module 318 for further processing. In this case, the login state identification module 316 does not need to process it.

[0116] Below, based on the above embodiments, we will continue to introduce the method for statistically analyzing valid data packets in encrypted TCP packets and the corresponding rules for judging abnormal login sessions, and give three possible implementation methods:

[0117] Before proceeding, let's define forward, reverse, forward packets, and reverse packets. Encrypted TCP packets include packets sent from the RFB client to the RFB server and packets sent from the RFB server to the RFB client. For ease of explanation, the direction of data transmission from the RFB client to the RFB server is called forward, and the corresponding encrypted TCP packets are called forward packets. The direction of data transmission from the RFB server to the RFB client is called reverse, and the corresponding encrypted TCP packets are called reverse packets.

[0118] Method 1

[0119] The number of valid data packets in the forward data packets is counted (specific statistical methods will be explained later), denoted as sum. client Furthermore, the number of valid data packets in the reverse data packet is counted and denoted as sum. server Then the total number of valid data packets in both directions, sum total =sum client +sum server .

[0120] If the total number of valid data packets in both directions is less than the first threshold, the RFB session is determined to be an abnormal login session; otherwise, the RFB session is not an abnormal login session. If the first threshold is denoted as β, then this judgment condition can be expressed as sum... total <β, where β can be a preset constant, such as 20.

[0121] The principle of Method 1 is as follows: If the RFB session is an abnormal login session, the session will end soon after the login fails, so the total number of valid data packets generated in both directions will not be large. Therefore, if it is determined that the total number of valid data packets in both directions is less than the first threshold, the RFB session can be determined to be an abnormal login session.

[0122] Method 2

[0123] The number of valid packets in the reverse data packets is summed by counting the valid packets in the reverse data packets. server .

[0124] If the number of valid packets in the reverse packet is less than the second threshold, the RFB session is determined to be an abnormal login session; otherwise, the RFB session is not an abnormal login session. If the second threshold is denoted as α, then this judgment condition can be expressed as sum server <α, where α can be a preset constant, such as 14, and α < β.

[0125] Method 2 works on the same principle as Method 1, but only calculates the sum. server Without counting sum client There are other reasons:

[0126] The inventors discovered that, based on the condition sum totalWhile <β can determine whether an RFB session is an abnormal login session, it has some hidden dangers: some attackers may intentionally fragment encrypted TCP packets into smaller packets. Although the actual number of valid data packets does not increase, the number of encrypted TCP packets increases, thus increasing the total number of valid packets in both directions, leading to a failure to satisfy the sum... total The condition <β allows abnormal login sessions to bypass the detection in method 1.

[0127] Considering that attackers can only control the behavior of the RFB client and not the behavior of the RFB server, method 2 only utilizes sum. server Using this method to determine whether an RFB session is an abnormal login session may yield a more accurate result.

[0128] Method 3

[0129] The number of valid data packets in the forward data packets is counted to obtain the sum of the valid data packets in the forward data packets. client Furthermore, the number of valid data packets in the reverse data packets is counted to obtain the sum of valid data packets in the reverse data packets. server Then the total number of valid data packets in both directions, sum total =sum client +sum server .

[0130] If the total number of valid data packets in both directions is less than the first threshold, or the number of valid data packets in the reverse data packets is less than the second threshold, then the RFB session is determined to be an abnormal login session; otherwise, the RFB session is not an abnormal login session. This judgment condition can be expressed as sum total <β or sum server <α.

[0131] Method 3 can be seen as a combination of Method 1 and Method 2. Using Method 3 may capture more abnormal login cases than using Method 1 or Method 2 alone.

[0132] It should be understood that methods 1 to 3 are merely examples, and it is possible that there are other rules for determining whether an RFB session is an abnormal login session.

[0133] The following section introduces specific methods for counting valid data packets. In one implementation, the number of valid data packets in the forward data packets can be counted as follows:

[0134] First, count the number of forward packets to obtain the total number of forward packets. Then, count the number of invalid packets in the forward packets to obtain the number of invalid packets in the forward packets.

[0135] The total number of forward packets can be obtained by incrementing a counter after each forward packet is received. The total number of forward packets is denoted as S1.total.

[0136] According to the TCP protocol specification, both directions of a TCP connection must maintain a sliding window for TCP sequence numbers when sending TCP packets. Figure 4 This is a diagram illustrating the sliding window mechanism used in the TCP protocol. (See reference...) Figure 4 Each small square in the middle represents a TCP packet, and the number within it indicates the TCP sequence number of that packet. The sliding window includes a trailing edge and a leading edge; when sending data, the sliding window typically moves in the direction from the trailing edge to the leading edge. Figure 4 In the middle, the back edge of the sliding window is 31, and the front edge of the sliding window is 50.

[0137] Based on the concept of a sliding window, invalid data packets in a forward data packet can be defined, including at least the following four categories:

[0138] The first type is data packets with TCP sequence numbers less than the trailing edge of the upward sliding window. This means that data packets with the same sequence number have been sent and acknowledged. Therefore, the first type of invalid data packets are redundant packets.

[0139] The second type: The TCP sequence number is located in the upward sliding window, and the data packet with that sequence number has been sent but not acknowledged. That is, the second type of invalid data packet is a retransmission packet.

[0140] The third category: packets with TCP sequence numbers greater than the leading edge of the upward sliding window, i.e. packets that are not allowed to be sent by the TCP protocol specification, or third category invalid packets are abnormal packets;

[0141] Category 4: Forward data packets that do not carry application layer protocol data and do not belong to any of the above three categories.

[0142] By parsing the header of a forward data packet, its corresponding TCP sequence number (SEQ field) can be obtained. Combined with the position of the upward sliding window, it can be determined whether the forward data packet belongs to Category 1, 2, or 3 invalid data packets. If it is determined that the forward data packet does not belong to Category 1, 2, or 3 invalid data packets, the length of the forward data packet header (referring to the TCP header) can be subtracted from the total length of the forward data packet to calculate the length of the application layer protocol data it carries. This allows determination of whether the forward data packet belongs to Category 4 invalid data packets. Thus, the number of invalid data packets of each category can be statistically analyzed.

[0143] The number of the above four types of invalid data packets can be denoted as S1.type1, S1.type2, S1.type3, and S1.type4 respectively. S1.type1 + S1.type2 + S1.type3 + S1.type4 is the number of invalid data packets in the forward data packets.

[0144] Then, by subtracting the number of invalid packets from the total number of forward packets, we can obtain the number of valid packets in the forward packets:

[0145] sum client =S1.total-S1.type1-S1.type2-S1.type3-S1.type4

[0146] Similarly, the number of valid data packets in the reverse data packet can be obtained by counting the valid data packets in the reverse data packet as follows:

[0147] First, count the reverse data packets to obtain the total number of reverse data packets. Then, count the invalid data packets in the reverse data packets to obtain the number of invalid data packets in the reverse data packets.

[0148] The total number of reverse packets is denoted as S2.total. Invalid packets in the reverse packets include at least the following four categories:

[0149] The first type is data packets with TCP sequence numbers less than the trailing edge of the sliding window in the reverse direction. This means that data packets with the same sequence number have been sent and acknowledged. Therefore, the first type of invalid data packets are redundant packets.

[0150] The second type: The TCP sequence number is located in the reverse sliding window, and the data packet with that sequence number has been sent but not acknowledged. That is, the second type of invalid data packet is a retransmission packet.

[0151] The third category: packets with TCP sequence numbers greater than the leading edge of the sliding window in the reverse direction, i.e. packets that are not allowed to be sent by the TCP protocol specification, or the third category of invalid packets are abnormal packets;

[0152] Category 4: Reverse data packets that do not carry application layer protocol data and do not belong to any of the above three categories.

[0153] The number of the above four types of invalid data packets are denoted as S2.type1, S2.type2, S2.type3, and S2.type4, respectively. S2.type1 + S2.type2 + S2.type3 + S2.type4 is the number of invalid data packets in the reverse data packet.

[0154] Then, by subtracting the number of invalid packets from the total number of reverse packets, we can obtain the number of valid packets in the reverse packets:

[0155] sum server =S2.total-S2.type1-S2.type2-S2.type3-S2.type4

[0156] In the above implementation, since four types of invalid data packets can be accurately identified, the number of valid data packets can be indirectly counted by counting the number of invalid data packets, resulting in high accuracy of the statistical results. This makes the judgment on whether an RFB session is an abnormal login session more accurate.

[0157] It should be understood that other methods for counting invalid data packets are possible, such as counting only the first three categories of invalid data packets and considering the fourth category as valid data packets, etc. It should also be understood that methods that directly count valid data packets, rather than indirectly counting invalid data packets, are also possible.

[0158] As mentioned earlier, when determining whether an RFB session is an abnormal login session based on the number of valid data packets, other judgment conditions can also be combined.

[0159] In one implementation, the RFB server can determine whether to close the TCP connection with the RFB client based on the encrypted TCP data packets, and determine the value of the connection closure flag based on the determination result.

[0160] For example, the connection closure flag can be denoted as FIN_BY_SERVER. A corresponding FIN_BY_SERVER can be set for each RFB session, such as by adding it to the flow table. The value of FIN_BY_SERVER can be 0 or 1. If FIN_BY_SERVER is 1, it means that the TCP connection between the RFB server and the RFB client was closed by the RFB server. If FIN_BY_SERVER is 0, it means that the TCP connection between the RFB server and the RFB client was not closed by the RFB server, such as by the RFB client closing the TCP connection between the RFB server and the RFB server.

[0161] First, initialize the value of the FIN_BY_SERVER flag to 0. By parsing the header of the encrypted TCP packet, you can obtain its corresponding FIN flag. If the FIN flag is 1, and the current encrypted TCP packet triggers the TCP state machine corresponding to the RFB session to enter the FIN_WAIT1 state, and the current encrypted TCP packet is a reverse packet, then you can set the value of the FIN_BY_SERVER flag corresponding to the RFB session to which the current encrypted TCP packet belongs to to 1.

[0162] If a connection closure flag is set, the connection closure flag can be checked first. If the connection closure flag indicates that the TCP connection between the RFB server and the RFB client was not closed by the RFB server, then the RFB session is not an abnormal login session. If the connection closure flag indicates that the TCP connection between the RFB server and the RFB client was closed by the RFB server, then the number of valid data packets should be used to further determine whether the RFB session is an abnormal login session.

[0163] For example, if we combine FIN_BY_SERVER with method 3 mentioned above, we can obtain the following judgment condition:

[0164] (1) FIN_BY_SERVER = 1

[0165] (2)sum total <β or sum server <α

[0166] If both conditions (1) and (2) are met, the RFB session is an abnormal login session; otherwise, it is not an abnormal login session. Condition (1) can be executed first, and the result of condition (1) can be used to determine whether condition (2) should be executed (executed only if FIN_BY_SERVER = 1, and not executed if FIN_BY_SERVER = 0). Of course, it is also possible to simultaneously evaluate both conditions (1) and (2).

[0167] The principle behind this judgment is as follows: When using the RFB protocol for remote desktop control, the RFB client typically closes the TCP connection proactively (e.g., when the user no longer needs remote control). The RFB server generally does not proactively close the TCP connection unless encountering abnormal situations (including but not limited to abnormal RFB client login). Therefore, if the TCP connection between the RFB server and the RFB client is not closed by the RFB server, it indicates that the RFB session is not an abnormal login session. Conversely, if the TCP connection between the RFB server and the RFB client is closed by the RFB server, it indicates that the RFB session is abnormal, possibly due to an abnormal RFB client login, but other reasons cannot be ruled out. The number of valid data packets can be used to further determine whether the RFB session is an abnormal login session, thus making the judgment result more accurate.

[0168] Reference Figure 3 The functions of the login status identification module 316 include: counting the valid data packets in the encrypted TCP packets received from the session status identification module 314, setting the value of the FIN_BY_SERVER identifier, and judging abnormal login sessions based on the FIN_BY_SERVER identifier and the number of valid data packets in the encrypted TCP packets.

[0169] Optionally, the login status identification module 316 maintains a set of counters for each TLS-encrypted RFB session in both directions: a first counter group (S1) for the forward direction and a second counter group (S2) for the reverse direction. Each counter group contains a total data packet counter (total), representing the total number of data packets in that direction; a first-type invalid data packet counter (type1), representing the total number of first-type invalid data packets in that direction; a second-type invalid data packet counter (type2), representing the total number of second-type invalid data packets in that direction; a third-type invalid data packet counter (type3), representing the total number of third-type invalid data packets in that direction; and a fourth-type invalid data packet counter (type4), representing the total number of fourth-type invalid data packets in that direction. All of these counters are initially set to 0. The login status identification module 316 also maintains a FIN_BY_SERVER identifier for each TLS-encrypted RFB session, with an initial value of 0.

[0170] Figure 5 for Figure 3 The possible process of the login status recognition module 316 counting the number of valid data packets, combined with Figure 5 This explains the function of the login status recognition module 316. (Refer to...) Figure 5 For each received encrypted TCP packet, the login status identification module 316 performs the following steps:

[0171] Step S501: Determine the counter group corresponding to this data packet.

[0172] This data packet is the currently processed encrypted TCP packet. If the five-tuple information of the entry in the flow table corresponding to the RFB session is (RFB client's IP address, RFB server's IP address, RFB client's port, RFB server's port, transport layer protocol type), and the five-tuple information of this data packet (source IP address, destination IP address, source port number, destination port number, transport layer protocol type) matches a certain entry in the flow table corresponding to the RFB session, then this data packet is a forward data packet, and its corresponding counter group is S1; if the five-tuple information of this data packet (destination IP address, source IP address, destination port number, source port number, transport layer protocol type) matches a certain entry in the flow table corresponding to the RFB session, then this data packet is a reverse data packet, and its corresponding counter group is S2.

[0173] The matching of the five-tuple information can be completed in the data acquisition module 312. In step S501, the login status recognition module 316 only determines the counter group based on the method of successful matching.

[0174] Step S502: Increment the total number of data packets in the counter group by 1.

[0175] For example, if the counter group corresponding to this data packet is S1, then S1.total = S1.total + 1; if the counter group corresponding to this data packet is S2, then S2.total = S2.total + 1.

[0176] Note that, taking S1.total as an example, it is sometimes used to represent the total number of forward packets, and sometimes as a counter for the total number of packets within counter group S1. In fact, these two concepts are consistent. When used as a counter, S1.total counts the total number of forward packets. Therefore, for simplicity, the notation S1.total represents both concepts simultaneously. The same understanding applies to other counters, and will not be repeated here.

[0177] Step S503: Parse the header information of this data packet to obtain the sequence number SEQ field, TCP header length, RST flag, and FIN flag.

[0178] Step S504: Determine whether the following conditions are met: the FIN flag is 1, and this data packet triggers the TCP state machine of the corresponding RFB session to enter the FIN_WAIT state, and this data packet is a reverse data packet. If the conditions are met, proceed to step S505; otherwise, proceed to step S506.

[0179] Step S505: Set the FIN_BY_SERVER flag to 1.

[0180] Step S506: Determine if the RST flag is 1. If it is 1, end the process. If it is not 1, proceed to step S507.

[0181] Step S507: Determine whether this data packet is a Class I, Class II, or Class III invalid data packet in that direction based on the SEQ field and the sliding window in that direction. The determination method is derived from the definitions of each type of invalid data packet and will not be elaborated further. If this data packet is one of the Class I, Class II, or Class III invalid data packets, proceed to step S508; otherwise, proceed to step S509.

[0182] Step S508: Increment the counters of the corresponding categories in the counter group by 1.

[0183] For example, if this data packet is a reverse data packet and is a Type 3 invalid data packet, then S2.type3 = S2.type3 + 1.

[0184] Step S509: Determine whether this data packet is a Type IV invalid data packet based on the length of the application layer protocol data carried in this data packet. If it is a Type IV invalid data packet, proceed to step S510; otherwise, end the process. The length of the application layer protocol data = the total length of this data packet - the length of the data packet header (referring to the TCP header).

[0185] Step S510: Increment the counters of the corresponding categories in the counter group by 1.

[0186] For example, if this data packet is a forward data packet, then S1.type4 = S1.type4 + 1.

[0187] The login status identification module 316 continues to execute the above process to count data packets until the data acquisition module 312 identifies that the TCP state machine of the RFB session has entered the CLOSED state (representing that the RFB session has ended). Then, it notifies the login status identification module 316 to determine whether the RFB session is an abnormal login session based on the values ​​of each counter. Since the counters S1.total, S1.type1, S1.type2, S1.type3, S1.type4, S2.total, S2.type1, S2.type2, S2.type3, and S2.type4 have all been properly assigned values ​​at this point, the formula given earlier is used:

[0188] sum client =S1.total-S1.type1-S1.type2-S1.type3-S1.type4

[0189] sum server =S2.total-S2.type1-S2.type2-S2.type3-S2.type4

[0190] You can then calculate the sum. client and sum server By combining this with FIN_BY_SERVER, we can determine whether the RFB session is an abnormal login session. The determination criteria can be those given above:

[0191] (1) FIN_BY_SERVER = 1

[0192] (2)sum total <β or sum server <α

[0193] If the login status identification module 316 determines that the RFB session is an abnormal login session, it submits the triplet information (IP address of the RFB client, IP address of the RFB server, and port of the RFB server) to the weak password scanning and identification module 318 for further processing.

[0194] In one implementation, obtaining the abnormal login indicator corresponding to the RFB client in step S430 may further include the following steps:

[0195] First, a key-value pair, called the target key-value pair, is constructed using the triple information (RFB client IP address, RFB server IP address, RFB server port) corresponding to the RFB session currently identified as an abnormal login session. The target key-value pair can be the triple information (RFB client IP address, RFB server IP address, RFB server port) itself, or it can be the result of some transformation of the triple information. For simplicity, the following text will only use the case where the target key-value pair is the triple information itself as an example.

[0196] Then, the abnormal login indicator corresponding to the target key value is searched from the weak password scan detection table. The weak password scan detection table can be implemented using a search tree (such as a binary tree) or a hash table. Each entry includes at least one key value and its corresponding abnormal login indicator. The key value is a triplet (IP address of the RFB client, IP address of the RFB server, and port of the RFB server). Each entry can be considered to correspond to an RFB client (identified by its IP address) in an RFB session that has been identified by the detection program as having experienced an abnormal login. The RFB client and RFB server in the entry also belong to that specific RFB session.

[0197] If the search is successful (the target key matches a key in a table entry), the found abnormal login metrics are first updated. The update method depends on how the abnormal login metrics are defined. For example, if the abnormal login metrics are defined as the number of times an RFB client logs into the RFB server within a unit of time, the update method could be to increment that number by 1. The updated abnormal login metrics are then used for weak password scanning behavior identification.

[0198] If the search fails (the target key value does not match any table entry's key value), a new table entry can be created in the weak password scan detection table. The key value in this table entry will be the target key value used in the search, while the abnormal login indicator can be set to an initial value, such as 0.

[0199] The abnormal login indicator recorded in the weak password scanning detection table is reset every unit of time. The specific value of this unit of time is not limited; it could be 1 second, 2 seconds, etc. Resetting the abnormal login indicator means setting it to its initial value. Because, according to the identification principle explained earlier, a large number of abnormal logins within a short period are considered indicative of weak password scanning activity. Therefore, the abnormal login indicator is only valid within a unit of time; after this unit of time, the current value of the abnormal login indicator becomes invalid and must be reset.

[0200] In the above implementation, the target key is constructed based on the triplet information corresponding to the RFB session, rather than the quintet information corresponding to the RFB session. The reason for this is:

[0201] First, since step S430 has already been executed, the transport layer protocol type in the five-tuple information can be determined to be TCP protocol, which is a fixed value and there is no need to add it to the target key value;

[0202] Secondly, the inventors discovered that attackers may change the port they use each time they log in using the RFB client during weak password scanning. Therefore, if the RFB client's port is included in the target key value, and if the target key value is used to create new entries, it will lead to too many entries in the weak password scan detection table, and the abnormal login indicators in each entry cannot effectively describe the weak password scanning behavior. However, by changing it to triple information, the RFB client's IP address can still represent the RFB client well, and the updates to the abnormal login indicators can be more reasonable. As a result, the values ​​of the obtained abnormal login indicators are also more reasonable, which helps to improve the accuracy of weak password scanning behavior identification.

[0203] Reference Figure 3The functions of the weak password scanning and identification module 318 include: searching the weak password scanning detection table based on the triple information received from the login state identification module 316 (when the RFB session is encrypted with TLS) or from the session state identification module 314 (when the RFB session is not encrypted), updating the token bucket (the meaning of the token bucket will be explained later), identifying weak password scanning behavior, and resetting the token bucket.

[0204] Figure 6 for Figure 3 The weak password scanning and identification module 318 in the middle detects possible weak password scanning processes, combined with Figure 6 This will illustrate the function of the weak password scanning and identification module 318. (Refer to...) Figure 6 Upon receiving each triplet (IP address of the RFB client, IP address of the RFB server, and port of the RFB server), the weak password scanning and identification module 318 performs the following steps:

[0205] Step S601: Using the triplet information (IP address of the RFB client, IP address of the RFB server, port of the RFB server) as the target key value, search for the entry in the weak password scan detection table that corresponds to the target key value.

[0206] Each entry in the weak password scanning detection table includes a triplet as a key, a token bucket, and a reset time (denoted as refill_time). The initial number of tokens in the token bucket is the token bucket capacity r, which can take system-configured values ​​such as 10 or 20. This token quantity is one way to implement abnormal login indicators.

[0207] Step S602: Determine whether the lookup table entry is successful. If the lookup is successful, proceed to step S604; if the lookup fails, proceed to step S603.

[0208] Step S603: Create a new entry in the weak password scanning detection table. Initialize the key value of the entry to the target key value used for the lookup, initialize the number of tokens in the token bucket of the entry to r, and initialize the refill_time of the entry to the current time. End the process after creating the entry.

[0209] Step S604: Obtain the number of tokens in the token bucket of the table entry.

[0210] Step S605: Determine if the number of tokens is greater than 0. If it is greater than 0, proceed to step S606. If it is not greater than 0 (equal to 0), proceed to step S607.

[0211] Step S606: Subtract 1 from the token quantity.

[0212] Step S607: Issue a weak password scanning alarm (weak password scanning behavior has been detected). For the principle behind the alarm, see [link to alarm details]. Figure 7 Related analysis.

[0213] exist Figure 6 The process hasn't yet explained the purpose of resetting the time in the table entries. Including a reset time in the table entries is to promptly release entries that haven't been used for a long time, preventing an excessive number of entries in the weak password scanning detection table. This not only consumes storage space but may also affect search efficiency. This will be combined with... Figure 7 Please provide an explanation.

[0214] The weak password scanning and identification module 318 also maintains a timer, which can be understood as a program unit that executes at regular intervals, for example... Figure 7 The timer logic executes once every 1 second, which is the unit of time for resetting the abnormal login indicator. Figure 7 for Figure 3 The possible execution flow of the timer in the weak password scanning and identification module 318. (Refer to...) Figure 7 Each time the timer executes, it iterates through the entries in the weak password scanning detection table and performs the following steps for each entry:

[0215] Step S701: Obtain the number of tokens in the token bucket of the table entry.

[0216] Step S702: Determine if the number of tokens is less than r. If the number of tokens is less than r, proceed to step S703. If the number of tokens is equal to r, proceed to step S704.

[0217] Step S703: Reset the token quantity to r, and set the refill_time in the table entry to the current time, indicating that the token quantity was reset at the current time. After execution, the process ends.

[0218] As can be seen from step S703, since the token count is reset every 1 second, if the token count is equal to 0 in step S605, it means that r abnormal logins have occurred within 1 second. r is equivalent to a threshold. If the number of abnormal logins reaches the threshold, it indicates that there is a weak password scanning behavior. Therefore, the alarm can be triggered in step S607.

[0219] Step S704: Determine whether the difference between the current time and the refill_time in the table entry is greater than a certain time threshold. If it is greater than the time threshold, proceed to step S705; otherwise, end the process.

[0220] Step S705: Release the table entry.

[0221] As can be seen from steps S702 and S703, the refill_time of an entry will only be updated when the number of tokens is less than r; otherwise, it will not be updated. Since the number of tokens is less than r, it means that the RFB client corresponding to the entry has made an abnormal login. Therefore, in step S704, if the difference between the current time and the refill_time in the entry is greater than the time threshold, it indicates that the refill_time has not been updated for a long time, which in turn indicates that the RFB client corresponding to the entry has not made an abnormal login for a long time. Since weak password scanning behavior identification obviously targets RFB clients that have made abnormal logins, the entries corresponding to RFB clients that have not made abnormal logins for a long time can be released to save storage space and maintain a high search efficiency for the weak password scanning detection table.

[0222] It should be understood that the reset time in the table entry is optional. If there is sufficient storage space, the table entry may not need to be released, or it is not necessary to release the table entry by adding a reset time.

[0223] Figure 8 The functional modules that the weak password scanning behavior recognition device provided in the embodiments of this application may have. (Refer to...) Figure 8 The weak password scanning behavior recognition device 800 includes:

[0224] The packet acquisition unit 810 is used to acquire TCP packets in the RFB session;

[0225] The abnormal login judgment unit 820 is used to determine whether the RFB session is an abnormal login session based on the TCP data packet; wherein, the abnormal login session refers to a session in which the RFB client logs into the RFB server abnormally;

[0226] The weak password scanning detection unit 830 is used to obtain the abnormal login index corresponding to the RFB client when the RFB session is an abnormal login session, and determine whether there is a weak password scanning behavior targeting the RFB server based on the abnormal login index; wherein, the abnormal login index represents the number of times the RFB client abnormally logs into the RFB server within a unit of time.

[0227] In one implementation of the weak password scanning behavior identification device 800, the data packet acquisition unit 810 acquires TCP data packets in an RFB session, including: acquiring network data packets and their corresponding five-tuple information; if it is determined from the five-tuple information that the network data packet does not belong to an existing RFB session, and the application layer protocol data carried by the network data packet is RFB protocol data, then the network data packet is identified as a TCP data packet in a newly established RFB session; if it is determined from the five-tuple information that the network data packet belongs to an existing RFB session, then the network data packet is identified as a TCP data packet in the existing RFB session.

[0228] In one implementation of the weak password scanning behavior identification device 800, the abnormal login judgment unit 820 determines whether the RFB session is an abnormal login session based on the TCP data packet, including: reassembling the RFB protocol data carried by the TCP data packet to obtain an RFB protocol message; determining whether the login process of the RFB session will be encrypted based on the RFB protocol message; if the login process of the RFB session will be encrypted, after determining that the RFB session has entered the encrypted transmission stage based on the RFB protocol message, counting the valid data packets in the encrypted TCP data packet to obtain the number of valid data packets, and determining whether the RFB session is an abnormal login session based on the number of valid data packets; wherein, the encrypted TCP data packet refers to the TCP data packet carrying encrypted RFB protocol data.

[0229] In one implementation of the weak password scanning behavior identification device 800, the encrypted TCP data packet includes a forward data packet sent by the RFB client to the RFB server, and a reverse data packet sent by the RFB server to the RFB client; the abnormal login judgment unit 820 counts the valid data packets in the encrypted TCP data packet to obtain the number of valid data packets, and judges whether the RFB session is an abnormal login session based on the number of valid data packets, including: counting the valid data packets in the forward data packet and the valid data packets in the reverse data packet respectively to obtain the total number of valid data packets in both directions; if the total number of valid data packets in both directions is less than a first threshold... If the value is less than a first threshold, the RFB session is determined to be an abnormal login session; or, the valid data packets in the forward data packets and the valid data packets in the reverse data packets are counted separately to obtain the number of valid data packets in the reverse data packets and the total number of valid data packets in both directions. If the total number of valid data packets in both directions is less than a first threshold, or the number of valid data packets in the reverse data packets is less than a second threshold, the RFB session is determined to be an abnormal login session; or, the valid data packets in the reverse data packets are counted to obtain the number of valid data packets in the reverse data packets. If the number of valid data packets in the reverse data packets is less than a second threshold, the RFB session is determined to be an abnormal login session.

[0230] In one implementation of the weak password scanning behavior identification device 800, the abnormal login judgment unit 820 counts the valid data packets in the forward data packets to obtain the number of valid data packets in the forward data packets. This includes: counting the forward data packets to obtain the total number of forward data packets, and counting the invalid data packets in the forward data packets to obtain the number of invalid data packets in the forward data packets; subtracting the number of invalid data packets in the forward data packets from the total number of forward data packets to obtain the number of valid data packets in the forward data packets. The invalid data packets in the forward data packets include the following four categories: Category 1: Data packets with TCP sequence numbers less than the trailing edge of the upward sliding window; Category 2: Data packets with TCP sequence numbers within the upward sliding window that have been sent but not acknowledged; Category 3: Data packets with TCP sequence numbers greater than the leading edge of the upward sliding window; Category 4: Data packets that do not carry application layer protocol data and do not belong to the above three categories. The abnormal login judgment unit 820 counts the valid data packets in the reverse data packets to obtain the number of valid data packets in the reverse data packets, including: counting the reverse data packets to obtain the total number of reverse data packets, and counting the invalid data packets in the reverse data packets to obtain the number of invalid data packets in the reverse data packets; subtracting the number of invalid data packets in the reverse data packets from the total number of reverse data packets to obtain the number of valid data packets in the reverse data packets; wherein, the invalid data packets in the reverse data packets include the following four categories: the first category: data packets with TCP sequence numbers less than the trailing edge of the sliding window on the reverse side; the second category: data packets with TCP sequence numbers located within the sliding window on the reverse side, and which have been sent but not acknowledged; the third category: data packets with TCP sequence numbers greater than the leading edge of the sliding window on the reverse side; the fourth category: data packets that do not carry application layer protocol data and do not belong to any of the above three categories.

[0231] In one implementation of the weak password scanning behavior identification device 800, the abnormal login judgment unit 820 is further configured to: determine whether the TCP connection between the RFB server and the RFB client was closed by the encrypted TCP data packet, and obtain a connection closure identifier; if the connection closure identifier indicates that the TCP connection between the RFB server and the RFB client was not closed by the RFB server, then the RFB session is not an abnormal login session; if the connection closure identifier indicates that the TCP connection between the RFB server and the RFB client was closed by the RFB server, then determine whether the RFB session is an abnormal login session based on the number of valid data packets.

[0232] In one implementation of the weak password scanning behavior identification device 800, the abnormal login judgment unit 820 is further configured to: if the login process of the RFB session is not encrypted, obtain a return value representing the login status of the RFB client from the RFB protocol message, and determine whether the RFB protocol session is an abnormal login session based on the return value.

[0233] In one implementation of the weak password scanning behavior identification device 800, the weak password scanning detection unit 830 acquires the abnormal login indicator corresponding to the RFB client, including: determining a target key value based on the IP address of the RFB client, the IP address of the RFB server, and the port of the RFB server in the RFB session; searching for the abnormal login indicator corresponding to the target key value in the weak password scanning detection table; if the search is successful, updating the found abnormal login indicator and acquiring the updated abnormal login indicator; wherein, the weak password scanning detection table stores key values ​​and the abnormal login indicators corresponding to the key values, and the abnormal login indicators stored in the weak password scanning detection table are reset once every unit time.

[0234] In one implementation of the weak password scanning behavior identification device 800, the weak password scanning behavior identification device 800 is installed on an intermediate network device, which is independent of the devices where the RFB server and the RFB client are located; the data packet acquisition unit 810 acquires TCP data packets in the RFB session, including: acquiring TCP data packets in the RFB session from network data packets captured by the intermediate network device.

[0235] The weak password scanning behavior recognition device 800 provided in this application embodiment can be used to execute the weak password scanning behavior recognition method provided in this application embodiment. Its implementation principle and the resulting technical effects have been introduced in the foregoing method embodiment. For the sake of brevity, for the parts not mentioned in the device embodiment, please refer to the corresponding content in the method embodiment.

[0236] Figure 9 The electronic device provided in the embodiments of this application may have the following structure: the electronic device may be, but is not limited to, the following: Figure 1 The intermediate network device 300. (Refer to...) Figure 9 The electronic device 900 includes a processor 910, a memory 920, and a communication unit 930. These components are interconnected and communicate with each other via a communication bus 940 and / or other forms of connection mechanism (not shown).

[0237] The processor 910 includes one or more (only one is shown in the figure), which can be an integrated circuit chip with signal processing capabilities. The processor 910 can be a general-purpose processor, including a Central Processing Unit (CPU), a Microcontroller Unit (MCU), a Network Processor (NP), or other conventional processors; it can also be a special-purpose processor, including a Neural-network Processing Unit (NPU), a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. Furthermore, when there are multiple processors 910, some can be general-purpose processors and others can be special-purpose processors.

[0238] The memory 920 includes one or more (only one is shown in the figure), which may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc. The processor 910 and other possible components may access the memory 920 to read and / or write data therein.

[0239] Specifically, one or more computer program instructions may be stored in the memory 920, and the processor 910 may read and run these computer program instructions to implement the weak password scanning behavior identification method provided in the embodiments of this application.

[0240] The communication unit 930 includes one or more (only one is shown in the figure) and can be used to communicate directly or indirectly with other devices to exchange data. For example, by means of the communication unit 930, Figure 1 The intermediate network device 300 can communicate with the server device 100 and the client device 200. The communication unit 930 may include devices for wired and wireless communication, such as optical fiber, Serial Peripheral Interface (SPI) module, Inter-Integrated Circuit (I2C) bus, etc., or it may include devices for wireless communication, such as Bluetooth module, Wi-Fi module, mobile communication module (e.g., 4G, 5G module), etc.

[0241] Understandable. Figure 9 The structure shown is for illustrative purposes only; the electronic device 900 may also include more than [other components]. Figure 9 The more or fewer components shown, or having the same Figure 9 The different structures shown. Figure 9 The components shown can be implemented using hardware, software, or a combination thereof. Electronic device 900 may be a physical device, such as a switch, router, server, or PC, or a virtual device, such as a virtual machine or virtualization container. Furthermore, electronic device 900 is not limited to a single device; it can also be a combination of multiple devices or a cluster of numerous devices.

[0242] This application also provides a computer program product, which includes computer program instructions that are read and executed by a processor of an electronic device to perform the weak password scanning behavior identification method provided in this application. For example, it includes:

[0243] Retrieve TCP packets from an RFB session;

[0244] The RFB session is determined to be an abnormal login session based on the TCP data packets; wherein, the abnormal login session refers to a session in which the RFB client fails to log in to the RFB server.

[0245] If the RFB session is an abnormal login session, then obtain the abnormal login indicator corresponding to the RFB client, and determine whether there is a weak password scanning behavior targeting the RFB server based on the abnormal login indicator; wherein, the abnormal login indicator represents the number of times the RFB client abnormally logs into the RFB server within a unit of time.

[0246] This application also provides a computer-readable storage medium storing computer program instructions. These computer program instructions are read and executed by a processor of an electronic device to perform the weak password scanning behavior identification method provided in this application. For example, the computer-readable storage medium can be implemented as follows: Figure 9 The memory 920 in the electronic device 900.

[0247] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0248] Furthermore, the units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0249] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0250] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, combinations of solutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for identifying weak password scanning behavior, characterized in that, include: Retrieve Transmission Control Protocol (TCP) packets from a remote frame buffer (RFB) session; The RFB session is determined to be an abnormal login session based on the TCP data packets; wherein, the abnormal login session refers to a session in which the RFB client fails to log in to the RFB server. If the RFB session is an abnormal login session, then obtain the abnormal login indicator corresponding to the RFB client, and determine whether there is a weak password scanning behavior targeting the RFB server based on the abnormal login indicator; wherein, the abnormal login indicator represents the number of times the RFB client abnormally logs into the RFB server within a unit of time. The step of determining whether the RFB session is an abnormal login session based on the TCP data packets includes: The RFB protocol data carried by the TCP data packet is reassembled to obtain the RFB protocol message; Determine whether the login process of the RFB session will be encrypted based on the RFB protocol message; If the login process of the RFB session is encrypted, after determining that the RFB session has entered the encrypted transmission stage according to the RFB protocol message, the number of valid data packets in the encrypted TCP data packets is counted, and the number of valid data packets is used to determine whether the RFB session is an abnormal login session; wherein, the encrypted TCP data packet refers to the TCP data packet carrying encrypted RFB protocol data.

2. The weak password scanning behavior identification method according to claim 1, characterized in that, The step of obtaining Transmission Control Protocol (TCP) packets in a remote frame buffer (RFB) session includes: Retrieve network data packets and their corresponding 5-tuple information; If, based on the five-tuple information, it is determined that the network data packet does not belong to an existing RFB session, and the application layer protocol data carried by the network data packet is RFB protocol data, then the network data packet is identified as a TCP data packet in a newly created RFB session. If the network data packet is determined to belong to an existing RFB session based on the 5-tuple information, then the network data packet is identified as a TCP data packet in the existing RFB session.

3. The weak password scanning behavior identification method according to claim 1, characterized in that, The encrypted TCP data packet includes a forward data packet sent by the RFB client to the RFB server, and a reverse data packet sent by the RFB server to the RFB client; The step of counting the valid data packets in the encrypted TCP packets to obtain the number of valid data packets, and determining whether the RFB session is an abnormal login session based on the number of valid data packets, includes: The valid data packets in the forward data packets and the valid data packets in the reverse data packets are counted separately to obtain the total number of valid data packets in both directions. If the total number of valid data packets in both directions is less than a first threshold, the RFB session is determined to be an abnormal login session. or, The valid data packets in the forward data packets and the valid data packets in the reverse data packets are counted separately to obtain the number of valid data packets in the reverse data packets and the total number of valid data packets in both directions. If the total number of valid data packets in both directions is less than a first threshold, or the number of valid data packets in the reverse data packets is less than a second threshold, then the RFB session is determined to be an abnormal login session. or, The number of valid data packets in the reverse data packets is counted. If the number of valid data packets in the reverse data packets is less than a second threshold, the RFB session is determined to be an abnormal login session.

4. The weak password scanning behavior identification method according to claim 3, characterized in that, The number of valid data packets in the forward data packets is obtained by counting the valid data packets in the forward data packets, including: The total number of forward data packets is obtained by counting the forward data packets, and the number of invalid data packets in the forward data packets is obtained by counting the invalid data packets in the forward data packets. The number of valid data packets in the forward data packets is obtained by subtracting the number of invalid data packets in the forward data packets from the total number of forward data packets. The invalid data packets in the forward data packets include the following four categories: Category 1: Data packets with TCP sequence numbers less than the trailing edge of the upward sliding window; Category 2: Data packets with TCP sequence numbers within the upward sliding window that have been sent but not acknowledged; Category 3: Data packets with TCP sequence numbers greater than the leading edge of the upward sliding window; Category 4: Data packets that do not carry application layer protocol data and do not belong to any of the above three categories. The number of valid data packets in the reverse data packet is obtained by counting the valid data packets in the reverse data packet, including: The reverse data packets are counted to obtain the total number of reverse data packets, and invalid data packets in the reverse data packets are counted to obtain the number of invalid data packets in the reverse data packets; the number of valid data packets in the reverse data packets is obtained by subtracting the number of invalid data packets from the total number of reverse data packets. The invalid data packets in the reverse data packets include the following four categories: Category 1: Data packets with TCP sequence numbers less than the trailing edge of the sliding window in the reverse direction; Category 2: Data packets with TCP sequence numbers within the sliding window in the reverse direction, and which have been sent but not acknowledged; Category 3: Data packets with TCP sequence numbers greater than the leading edge of the sliding window in the reverse direction; Category 4: Data packets that do not carry application layer protocol data and do not belong to any of the above three categories.

5. The weak password scanning behavior identification method according to claim 1, characterized in that, The method further includes: Based on the encrypted TCP data packet, determine whether the TCP connection between the RFB server and the RFB client is closed, and obtain the connection closure identifier; If the connection closure flag indicates that the TCP connection between the RFB server and the RFB client was not closed by the RFB server, then the RFB session is not an abnormal login session. If the connection closure flag indicates that the TCP connection between the RFB server and the RFB client has been closed, then the RFB session is determined to be an abnormal login session based on the number of valid data packets.

6. The weak password scanning behavior identification method according to claim 1, characterized in that, The method further includes: If the login process of the RFB session is not encrypted, a return value representing the login status of the RFB client is obtained from the RFB protocol message, and the RFB protocol session is determined as an abnormal login session based on the return value.

7. The weak password scanning behavior identification method according to claim 1, characterized in that, The step of obtaining the abnormal login metrics corresponding to the RFB client includes: The target key value is determined based on the Internet Protocol IP address of the RFB client, the IP address of the RFB server, and the port of the RFB server in the RFB session. Search the weak password scanning detection table for abnormal login indicators corresponding to the target key value. If the search is successful, update the found abnormal login indicators and obtain the updated abnormal login indicators. The weak password scanning detection table stores key values ​​and corresponding abnormal login indicators. The abnormal login indicators stored in the weak password scanning detection table are reset every unit of time.

8. The weak password scanning behavior identification method according to any one of claims 1-7, characterized in that, The weak password scanning behavior identification method is executed by an intermediate network device, which is independent of the devices where the RFB server and the RFB client are located. The step of obtaining Transmission Control Protocol (TCP) packets in a remote frame buffer (RFB) session includes: Obtain TCP packets from the RFB session from the network packets captured by the intermediate network device.

9. A weak password scanning behavior recognition device, characterized in that, include: The packet acquisition unit is used to acquire TCP packets in the RFB session; An abnormal login determination unit is used to determine whether the RFB session is an abnormal login session based on the TCP data packet; wherein, the abnormal login session refers to a session in which the RFB client fails to log in to the RFB server; The weak password scanning detection unit is used to obtain the abnormal login index corresponding to the RFB client when the RFB session is an abnormal login session, and to determine whether there is a weak password scanning behavior targeting the RFB server based on the abnormal login index; wherein, the abnormal login index represents the number of times the RFB client abnormally logs into the RFB server within a unit of time. The abnormal login judgment unit is specifically used for: The RFB protocol data carried by the TCP data packet is reassembled to obtain the RFB protocol message; Determine whether the login process of the RFB session will be encrypted based on the RFB protocol message; If the login process of the RFB session is encrypted, after determining that the RFB session has entered the encrypted transmission stage according to the RFB protocol message, the number of valid data packets in the encrypted TCP data packets is counted, and the number of valid data packets is used to determine whether the RFB session is an abnormal login session; wherein, the encrypted TCP data packet refers to the TCP data packet carrying encrypted RFB protocol data.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when read and executed by a processor, perform the method as described in any one of claims 1-8.

11. An electronic device, characterized in that, The method includes a memory and a processor, wherein the memory stores computer program instructions, which are read and executed by the processor to perform the method of any one of claims 1-8.

Images