Vulnerability scanning prevention method and device, computer equipment, storage medium and product
By analyzing the sessions of vulnerability scanning behavior and generating blocking rules, and using TCP RST packets or ICMP Port Unreachable packets to block connections, the adaptability problem of existing vulnerability scanning blocking methods is solved, improving the accuracy of identification and reducing the probability of false positives.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-25
- Publication Date
- 2026-04-14
AI Technical Summary
Existing methods for blocking vulnerability scanning behavior cannot adapt to the updates and changes in vulnerability scanning tools, resulting in a high probability of false positives and false negatives.
By identifying the sessions that perform vulnerability scanning, we analyze protocol logs to formulate blocking rules, generate blocking messages to block the connection between the source host and the target host, and use TCP RST messages or ICMP Port Unreachable messages for blocking.
It improves the accuracy of vulnerability scanning behavior identification, reduces the probability of false positives and false negatives, and achieves effective location and blocking of vulnerability scanning behavior.
Smart Images
Figure CN121864388A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of security operation and maintenance technology, and in particular to a vulnerability scanning and blocking method, device, computer equipment, storage medium and product. Background Technology
[0002] In modern network security protection systems, Out-of-Band Blocking Systems (OBS) are a key, non-intrusive security component widely used in enterprise backbone networks, data centers, and cloud environments. These devices are typically deployed in bypass positions on core switches or egress routers. They enable real-time detection and analysis of network behavior by mirroring traffic. Once potential threat behaviors are identified, they can proactively construct blocking commands (such as TCP RST packets, ICMP messages, or invoke firewall APIs to achieve rapid interception), thereby ensuring the security and continuity of business systems.
[0003] However, existing methods for blocking vulnerability scanning behavior often rely on fixed filtering feature fields (such as fixed ports or fixed request keywords). This makes it difficult for existing technologies to adapt to the continuous updates and changes in vulnerability scanning tools when blocking funnel scans. Consequently, they cannot effectively block vulnerability scanning behavior and have a high probability of false positives and false negatives. Summary of the Invention
[0004] Therefore, it is necessary to provide a vulnerability scanning blocking method, device, computer equipment, storage medium, and product that can effectively block vulnerability scanning behavior in response to the above-mentioned technical problems.
[0005] Firstly, this application provides a vulnerability scanning and blocking method. The method includes:
[0006] Identify at least one first session that constitutes vulnerability scanning behavior;
[0007] The blocking rules are obtained by analyzing the protocol logs corresponding to each of the first sessions.
[0008] Based on the blocking rule, session monitoring is performed on the real-time traffic session to obtain the second session corresponding to the blocking rule;
[0009] According to the second session, a blocking message is sent to the source host; the blocking message is used to block the connection between the source host and the target host. In one embodiment, the blocking rule analysis based on the protocol logs corresponding to each first session to obtain the blocking rules includes:
[0010] The protocol logs corresponding to each first session are sent to the backend so that the backend can perform vulnerability scanning feature filtering on each protocol log to obtain target logs containing vulnerability scanning features, and generate the blocking rule based on the target logs.
[0011] Receive the blocking rule sent by the backend.
[0012] In one embodiment, the blocking rule is generated by the backend based on the scanner identifier of the scanner to be blocked; the scanner identifier is determined based on the attack source identifier contained in the target log.
[0013] In one embodiment, sending a blocking message to the source host according to the second session includes:
[0014] Determine the protocol type of the second session;
[0015] Based on the protocol type, determine the blocking message to be sent;
[0016] Send a blocking message to the source host.
[0017] In one embodiment, determining the blocking message to be sent based on the protocol type includes:
[0018] When the protocol type is TCP session, the TCP RST message will be treated as a blocking message;
[0019] In the case of a UDP session, ICMP Port Unreachable messages will be treated as blocking messages.
[0020] In one embodiment, determining at least one first session belonging to vulnerability scanning behavior includes:
[0021] Based on pre-defined vulnerability scanning behavior pre-conditions, real-time traffic sessions are monitored, and at least one session that conforms to the vulnerability scanning behavior pre-conditions is selected as the first session.
[0022] Secondly, this application also provides a vulnerability scanning and blocking device. The device includes:
[0023] The determination module is used to identify at least one first session that belongs to vulnerability scanning behavior;
[0024] The analysis module is used to analyze the blocking rules based on the protocol logs corresponding to each of the first sessions to obtain the blocking rules;
[0025] The monitoring module is used to perform session monitoring on real-time traffic sessions according to the blocking rules, and obtain the second session corresponding to the blocking rules;
[0026] A sending module is configured to send a blocking message to a source host according to the second session; the blocking message is used to block the connection between the source host and the target host. Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the following steps:
[0027] Identify at least one first session that constitutes vulnerability scanning behavior;
[0028] The blocking rules are obtained by analyzing the protocol logs corresponding to each of the first sessions.
[0029] Based on the blocking rule, session monitoring is performed on the real-time traffic session to obtain the second session corresponding to the blocking rule;
[0030] According to the second session, a blocking message is sent to the source host; the blocking message is used to block the connection between the source host and the target host. Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, performs the following steps:
[0031] Identify at least one first session that constitutes vulnerability scanning behavior;
[0032] The blocking rules are obtained by analyzing the protocol logs corresponding to each of the first sessions.
[0033] Based on the blocking rule, session monitoring is performed on the real-time traffic session to obtain the second session corresponding to the blocking rule;
[0034] According to the second session, a blocking message is sent to the source host; the blocking message is used to block the connection between the source host and the target host. Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, performs the following steps:
[0035] Identify at least one first session that constitutes vulnerability scanning behavior;
[0036] The blocking rules are obtained by analyzing the protocol logs corresponding to each of the first sessions.
[0037] Based on the blocking rule, session monitoring is performed on the real-time traffic session to obtain the second session corresponding to the blocking rule;
[0038] According to the second session, a blocking message is sent to the source host; the blocking message is used to block the connection between the source host and the target host. The aforementioned vulnerability scanning and blocking method, apparatus, computer equipment, storage medium, and product, in which the behavior recognition engine determines at least one first session belonging to vulnerability scanning behavior; and performs blocking rule analysis based on the protocol logs corresponding to each first session to obtain blocking rules; implements session monitoring of real-time traffic sessions according to the blocking rules to obtain the second session corresponding to the blocking rules; and finally sends a blocking message to the source host according to the second session; wherein, the blocking message is used to block the connection between the source host and the target host. As can be seen from the above, this application performs vulnerability scanning... During the blocking process, blocking rules are analyzed based on the protocol logs corresponding to the first session to obtain the blocking rules. This ensures that the determined blocking rules can effectively identify sessions belonging to vulnerability scanning behavior, improving the accuracy of vulnerability scanning behavior identification and providing a foundation for subsequent session monitoring of real-time traffic sessions. Furthermore, by monitoring real-time traffic sessions through blocking rules, the second session corresponding to the blocking rules is obtained, and blocking packets are sent to the source host based on the second session. This achieves effective localization of the attacker's vulnerability scanning behavior and accurate identification of the second session based on the blocking rules, effectively reducing the probability of false positives and false negatives in vulnerability scanning behavior. Attached Figure Description
[0039] Figure 1 An application environment diagram for a vulnerability scanning and blocking method provided in this application embodiment;
[0040] Figure 2 A flowchart illustrating the first vulnerability scanning and blocking method provided in this application embodiment;
[0041] Figure 3 A flowchart illustrating the second vulnerability scanning and blocking method provided in this application embodiment;
[0042] Figure 4 A flowchart illustrating the third vulnerability scanning and blocking method provided in this application embodiment;
[0043] Figure 5 A flowchart illustrating the fourth vulnerability scanning and blocking method provided in this application embodiment;
[0044] Figure 6 A structural block diagram of a vulnerability scanning and blocking device provided in an embodiment of this application;
[0045] Figure 7 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation
[0046] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0047] The vulnerability scanning and blocking method provided in this application embodiment can be applied to, for example... Figure 1 In the application environment shown, the execution entity 102 communicates with the backend 104 via a network. A data storage system can store the data that the backend 104 needs to process. The data storage system can be integrated on the backend 104 or placed in the cloud or on other network servers. The behavior recognition engine identifies at least one first session belonging to vulnerability scanning behavior; analyzes blocking rules based on the protocol logs corresponding to each first session to obtain blocking rules; monitors real-time traffic sessions according to the blocking rules to obtain the second session corresponding to the blocking rules; and finally sends a blocking message to the source host based on the second session. The blocking message is used to block the connection between the source host and the target host. The execution entity 102 can be a bypass blocking device (OBS), firewall, intrusion detection system (IDS), gateway, server, cloud security component, or any computing device with traffic monitoring and message sending capabilities. The backend 104 can refer to a remote analysis server, a cloud management platform, or an independent analysis process or storage module in a local device.
[0048] In one embodiment, such as Figure 2 As shown, a vulnerability scanning and blocking method is provided, which can be applied to... Figure 1 Taking the execution entity 102 as an example, the following steps are included:
[0049] S201, Identify at least one first session that belongs to vulnerability scanning behavior.
[0050] It should be noted that when it is necessary to determine at least one first session belonging to vulnerability scanning behavior, the following may be included: perform session monitoring on real-time traffic sessions according to pre-set vulnerability scanning behavior pre-rules, and take at least one session that meets the vulnerability scanning behavior pre-rules as the first session.
[0051] To further explain, the vulnerability scanning behavior pre-rules refer to the rules used to determine whether a session has a vulnerability scanning trend.
[0052] Among them, the pre-conditions for vulnerability scanning behavior can be set or adjusted according to the actual situation of the current session and the historical experience of the operation and maintenance personnel. The specific content of the pre-conditions for vulnerability scanning behavior is not limited here.
[0053] In one embodiment of this application, pre-built vulnerability scanning behavior pre-rules are loaded into the behavior recognition engine to ensure that the behavior recognition engine can perform session monitoring according to the vulnerability scanning behavior pre-rules; the behavior recognition engine receives real-time traffic sessions generated between the probe module and the target host through the mirror network card; wherein, the attacker (i.e., the vulnerability scanning module) will initiate probe traffic to the target host; the behavior recognition engine performs session monitoring on the real-time traffic sessions by reconstructing the sessions and decoding the protocols, and determines whether the detected sessions match the vulnerability scanning behavior pre-rules. If they match, the session is taken as the first session.
[0054] S202, based on the protocol logs corresponding to each first session, the blocking rules are analyzed to obtain the blocking rules.
[0055] It should be noted that when it is necessary to perform blocking rule analysis based on the protocol logs corresponding to each first session, the following may be included: sending the protocol logs corresponding to each first session to the backend so that the backend can filter the vulnerability scanning features of each protocol log to obtain the target logs containing vulnerability scanning features, and generating blocking rules based on the target logs; receiving the blocking rules sent by the backend.
[0056] The blocking rules are determined based on the scanner identifier of the scanner to be blocked.
[0057] S203, perform session monitoring on real-time traffic sessions according to the blocking rules, and obtain the second session corresponding to the blocking rules.
[0058] In one embodiment of this application, the behavior recognition engine loads and executes blocking rules to perform session monitoring on real-time traffic sessions according to the blocking rules, and filters out a second session that conforms to the blocking rules from the real-time traffic sessions.
[0059] S204, according to the second session, sends a blocking message to the source host.
[0060] Among them, blocking messages are used to block the connection between the source host and the target host.
[0061] It should be noted that when it is necessary to send a blocking message to the source host based on the second session, the following may be included: determining the protocol type of the second session; determining the blocking message to be sent based on the protocol type; and then sending the blocking message to the source host.
[0062] The aforementioned vulnerability scanning and blocking method involves a behavior recognition engine identifying at least one first session belonging to vulnerability scanning behavior; analyzing blocking rules based on the protocol logs corresponding to each first session to obtain blocking rules; monitoring real-time traffic sessions according to the blocking rules to obtain the second session corresponding to the blocking rules; and finally sending a blocking message to the source host based on the second session. The blocking message is used to block the connection between the source host and the target host. As can be seen from the above, this application analyzes blocking rules based on the protocol logs corresponding to the first session during the vulnerability scanning and blocking process. This ensures that the determined blocking rules can effectively identify sessions belonging to vulnerability scanning behavior, improving the accuracy of vulnerability scanning behavior identification and providing a foundation for subsequent session monitoring of real-time traffic sessions. Furthermore, by monitoring real-time traffic sessions through blocking rules to obtain the second session corresponding to the blocking rules, and sending a blocking message to the source host based on the second session, effective localization of the attacker's vulnerability scanning behavior is achieved, and accurate identification of the second session based on the blocking rules is realized, effectively reducing the probability of false positives and false negatives in vulnerability scanning behavior.
[0063] In one embodiment, such as Figure 3 As shown, when it is necessary to analyze the blocking rules based on the protocol logs corresponding to each first session to obtain the blocking rules, the following can be included:
[0064] S301, send the protocol logs corresponding to each first session to the backend so that the backend can filter the vulnerability scanning features of each protocol log, obtain the target log containing the vulnerability scanning features, and generate blocking rules based on the target log.
[0065] It should be noted that the blocking rules are generated by the backend based on the scanner identifier of the scanner to be blocked; the scanner identifier is determined based on the attack source identifier contained in the target log.
[0066] In one embodiment of this application, when it is necessary to generate blocking rules, the behavior recognition engine sends the protocol logs corresponding to each first session to the backend for storage. The backend periodically executes an SQL task to query the protocol logs of the sessions that have hit the pre-set rules based on the characteristics of the missed scan traffic; it determines whether a protocol log matching the characteristics of the missed scan traffic is found; if found, it determines that the source identifier in the target log is the scanner identifier, and generates blocking rules based on the scanner identifier.
[0067] As an example, the following SQL is used to detect the characteristic behavior of having a request for ` / api / v4 / users / 95-100` but no request for ` / api / v4 / users / 101`:
[0068] SELECT sip
[0069] FROM "matrix_http"
[0070] WHERE uri IN (' / api / v4 / users / 95', ' / api / v4 / users / 96', ' / api / v4 / users / 97', ' / api / v4 / users / 98', ' / api / v4 / users / 99', ' / api / v4 / users / 100')
[0071] OR uri = ' / api / v4 / users / 101'
[0072] GROUP BY sip
[0073] HAVING COUNT(DISTINCT CASE WHEN uri IN (' / api / v4 / users / 95', ' / api / v4 / users / 96', ' / api / v4 / users / 97', ' / api / v4 / users / 98', ' / api / v4 / users / 99', ' / api / v4 / users / 100') THEN uri END) = 6
[0074] AND SUM(CASE WHEN uri = ' / api / v4 / users / 101' THEN 1 ELSE 0 END) =0;
[0075] Specifically, if the source identifier (SIP) 192.168.1.213 appears in the SQL query results, it can be determined that the host with that identifier is the server that performed the vulnerability scan.
[0076] As another example, generating blocking rules based on scanner identifiers can be represented as follows:
[0077] alert tcp any any -> any any (
[0078] msg:"Fast blocking - IP - 192.168.1.213 - 20250529135642";
[0079] ip.src;dataset:isset,285575711895556096;
[0080] sid:2855757118955560960;
[0081] metadata: action_id 285575711895556096; )
[0083] alert udp any any -> any any (
[0084] msg:"Fast blocking - IP - 192.168.1.213 - 20250529135642";
[0085] ip.src;dataset:isset,285575711895556096;
[0086] sid:2855757118955560962;
[0087] metadata: action_id 285575711895556097; )
[0089] The dataset stores IP addresses. Action_id 285575711895556096 corresponds to TCP RST injection, and action_id 285575711895556097 corresponds to ICMP unreachable injection.
[0090] S302, receive blocking rules sent by the backend.
[0091] The aforementioned vulnerability scanning and blocking method sends protocol logs corresponding to each first session to the backend and receives blocking rules sent by the backend. This ensures that the determined blocking rules can effectively identify sessions that belong to vulnerability scanning behavior, improves the accuracy of vulnerability scanning behavior identification, and provides a foundation for subsequent session monitoring of real-time traffic sessions.
[0092] In one embodiment, such as Figure 4 As shown, when it is necessary to send a blocking message to the source host based on the second session, the following may be included:
[0093] S401, determine the protocol type for the second session.
[0094] The protocol types include TCP (Transmission Control Protocol) sessions and UDP (User Datagram Protocol) sessions.
[0095] S402, determine the blocking message to be sent based on the protocol type.
[0096] In one embodiment of this application, when it is necessary to determine the blocking message to be sent based on the protocol type, the following may be included: in the case of a Transmission Control Protocol (TCP) session, a Transmission Control Protocol Reset Message (TCPRST) message is used as the blocking message; in the case of a User Datagram Protocol (UDP) session, an Internet Control Message Protocol (ICMP) Port Unreachable message is used as the blocking message.
[0097] S403 sends a blocking message to the source host.
[0098] In one embodiment of this application, a TCP RST message is injected into the source host to forcibly close the connection when the protocol type is Transmission Control Protocol (TCP) session; when the protocol type is User Datagram Protocol (UDP) session, a forged ICMP Port Unreachable message is injected into the source host to block communication attempts.
[0099] Furthermore, if the blocking message is sent before the target server's actual response packet reaches the attacker's scanner, the attacker's Nuclei tool will not receive valid response data, thus misjudging the target host as having no vulnerabilities or the request failing, and the scanning behavior will be interrupted, thereby achieving the goal of preventing the attacker from obtaining valid scan response data through vulnerability scanning behavior.
[0100] The aforementioned vulnerability scanning and blocking method determines the protocol type of the second session and, based on the protocol type, determines the blocking message to be sent; thereby sending the blocking message to the source host, it effectively locates the attacker's vulnerability scanning behavior and effectively reduces the probability of false positives and false negatives in vulnerability scanning behavior.
[0101] In one embodiment, such as Figure 5 As shown, when vulnerability scanning and blocking are required, the following can be included:
[0102] S501, based on the pre-set vulnerability scanning behavior pre-rules, performs session monitoring on real-time traffic sessions, and selects at least one session that meets the vulnerability scanning behavior pre-rules as the first session.
[0103] S502 sends the protocol logs corresponding to each first session to the backend so that the backend can filter the vulnerability scanning features of each protocol log, obtain the target logs containing vulnerability scanning features, and generate blocking rules based on the target logs.
[0104] S503 receives blocking rules sent by the backend.
[0105] S504 performs session monitoring on real-time traffic sessions based on blocking rules to obtain the second session corresponding to the blocking rules.
[0106] S505, determine the protocol type for the second session.
[0107] S506, in the case of a Transmission Control Protocol (TCP) session, uses the TCP RST message as a blocking message; in the case of a User Datagram Protocol (UDP) session, uses the Internet Control Message Protocol (ICMP) Port Unreachable message as a blocking message.
[0108] S507 sends a blocking message to the source host.
[0109] Among them, blocking messages are used to block the connection between the source host and the target host.
[0110] The aforementioned vulnerability scanning and blocking method involves a behavior recognition engine identifying at least one first session belonging to vulnerability scanning behavior; analyzing blocking rules based on the protocol logs corresponding to each first session to obtain blocking rules; monitoring real-time traffic sessions according to the blocking rules to obtain the second session corresponding to the blocking rules; and finally sending a blocking message to the source host based on the second session. The blocking message is used to block the connection between the source host and the target host. As can be seen from the above, this application analyzes blocking rules based on the protocol logs corresponding to the first session during the vulnerability scanning and blocking process. This ensures that the determined blocking rules can effectively identify sessions belonging to vulnerability scanning behavior, improving the accuracy of vulnerability scanning behavior identification and providing a foundation for subsequent session monitoring of real-time traffic sessions. Furthermore, by monitoring real-time traffic sessions through blocking rules to obtain the second session corresponding to the blocking rules, and sending a blocking message to the source host based on the second session, effective localization of the attacker's vulnerability scanning behavior is achieved, and accurate identification of the second session based on the blocking rules is realized, effectively reducing the probability of false positives and false negatives in vulnerability scanning behavior.
[0111] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.
[0112] Based on the same inventive concept, this application also provides a vulnerability scanning and blocking device for implementing the vulnerability scanning and blocking method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more vulnerability scanning and blocking device embodiments provided below can be found in the limitations of the vulnerability scanning and blocking method described above, and will not be repeated here.
[0113] In one embodiment, such as Figure 6 As shown, a vulnerability scanning and blocking device is provided, comprising: a determination module 10, an analysis module 20, a monitoring module 30, and a sending module 40, wherein:
[0114] Module 10 is used to determine at least one first session that belongs to vulnerability scanning behavior.
[0115] Analysis module 20 is used to analyze the blocking rules based on the protocol logs corresponding to each first session to obtain the blocking rules.
[0116] The monitoring module 30 is used to perform session monitoring on real-time traffic sessions according to the blocking rules, and obtain the second session corresponding to the blocking rules.
[0117] Sending module 40 is configured to send a blocking message to the source host according to the second session; wherein the blocking message is used to block the connection between the source host and the target host.
[0118] In one embodiment, protocol logs corresponding to each first session are sent to the backend so that the backend can perform vulnerability scanning feature filtering on each protocol log to obtain target logs containing vulnerability scanning features, and generate blocking rules based on the target logs.
[0119] Receive blocking rules sent by the backend.
[0120] In one embodiment, the blocking rule is generated by the backend based on the scanner identifier of the scanner to be blocked; the scanner identifier is determined based on the attack source identifier contained in the target log.
[0121] In one embodiment, the protocol type of the second session is determined;
[0122] Determine the blocking message to be sent based on the protocol type;
[0123] Send a blocking message to the source host.
[0124] In one embodiment, when the protocol type is Transmission Control Protocol (TCP) session, the Transmission Control Protocol Reset (TCP) RST message is used as a blocking message.
[0125] In the case of a User Datagram Protocol (UDP) session, the Internet Control Message Protocol (ICMP) Port Unreachable message is treated as a blocking message.
[0126] In one embodiment, real-time traffic sessions are monitored according to pre-defined vulnerability scanning behavior pre-rules, and at least one session that conforms to the vulnerability scanning behavior pre-rules is designated as the first session.
[0127] The aforementioned vulnerability scanning and blocking device uses a behavior recognition engine to identify at least one first session belonging to vulnerability scanning behavior; analyzes blocking rules based on the protocol logs corresponding to each first session to obtain blocking rules; monitors real-time traffic sessions according to the blocking rules to obtain the second session corresponding to the blocking rules; and finally sends a blocking message to the source host based on the second session. The blocking message is used to block the connection between the source host and the target host. As can be seen from the above, during the vulnerability scanning and blocking process, this application analyzes blocking rules based on the protocol logs corresponding to the first session to obtain blocking rules. This ensures that the determined blocking rules can effectively identify sessions belonging to vulnerability scanning behavior, improving the accuracy of vulnerability scanning behavior identification and providing a foundation for subsequent session monitoring of real-time traffic sessions. Furthermore, by monitoring real-time traffic sessions through blocking rules to obtain the second session corresponding to the blocking rules and sending a blocking message to the source host based on the second session, effective location of the attacker's vulnerability scanning behavior is achieved, and accurate identification of the second session based on the blocking rules is realized, effectively reducing the probability of false positives and false negatives in vulnerability scanning behavior.
[0128] The modules in the aforementioned vulnerability scanning and blocking device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.
[0129] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 7As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a vulnerability scanning and blocking method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.
[0130] Those skilled in the art will understand that Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0131] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:
[0132] Identify at least one first session that constitutes vulnerability scanning behavior;
[0133] The blocking rules are obtained by analyzing the protocol logs corresponding to each first session.
[0134] Based on the blocking rules, real-time traffic sessions are monitored to obtain the second session corresponding to the blocking rules;
[0135] According to the second session, a blocking message is sent to the source host; the blocking message is used to block the connection between the source host and the target host.
[0136] In one embodiment, the processor, when executing a computer program, also performs the following steps:
[0137] Send the protocol logs corresponding to each first session to the backend so that the backend can filter the vulnerability scanning features of each protocol log, obtain the target logs containing vulnerability scanning features, and generate blocking rules based on the target logs.
[0138] Receive blocking rules sent by the backend.
[0139] In one embodiment, the processor, when executing a computer program, also performs the following steps:
[0140] The blocking rules are generated by the backend based on the scanner identifier of the scanner to be blocked; the scanner identifier is determined based on the attack source identifier contained in the target log.
[0141] In one embodiment, the processor, when executing a computer program, also performs the following steps:
[0142] Determine the protocol type for the second session;
[0143] Determine the blocking message to be sent based on the protocol type;
[0144] Send a blocking message to the source host.
[0145] In one embodiment, the processor, when executing a computer program, also performs the following steps:
[0146] In the case of a Transmission Control Protocol (TCP) session, the TCP RST message is treated as a blocking message.
[0147] In the case of a User Datagram Protocol (UDP) session, the Internet Control Message Protocol (ICMP) Port Unreachable message is treated as a blocking message.
[0148] In one embodiment, the processor, when executing a computer program, also performs the following steps:
[0149] Based on pre-defined vulnerability scanning behavior rules, real-time traffic sessions are monitored, and at least one session that meets the vulnerability scanning behavior rules is designated as the first session.
[0150] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:
[0151] Identify at least one first session that constitutes vulnerability scanning behavior;
[0152] The blocking rules are obtained by analyzing the protocol logs corresponding to each first session.
[0153] Based on the blocking rules, real-time traffic sessions are monitored to obtain the second session corresponding to the blocking rules;
[0154] According to the second session, a blocking message is sent to the source host; the blocking message is used to block the connection between the source host and the target host.
[0155] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:
[0156] Send the protocol logs corresponding to each first session to the backend so that the backend can filter the vulnerability scanning features of each protocol log, obtain the target logs containing vulnerability scanning features, and generate blocking rules based on the target logs.
[0157] Receive blocking rules sent by the backend.
[0158] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:
[0159] The blocking rules are generated by the backend based on the scanner identifier of the scanner to be blocked; the scanner identifier is determined based on the attack source identifier contained in the target log.
[0160] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:
[0161] Determine the protocol type for the second session;
[0162] Determine the blocking message to be sent based on the protocol type;
[0163] Send a blocking message to the source host.
[0164] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:
[0165] In the case of a Transmission Control Protocol (TCP) session, the TCP RST message is treated as a blocking message.
[0166] In the case of a User Datagram Protocol (UDP) session, the Internet Control Message Protocol (ICMP) Port Unreachable message is treated as a blocking message.
[0167] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:
[0168] Based on pre-defined vulnerability scanning behavior rules, real-time traffic sessions are monitored, and at least one session that meets the vulnerability scanning behavior rules is designated as the first session.
[0169] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, performs the following steps:
[0170] Identify at least one first session that constitutes vulnerability scanning behavior;
[0171] The blocking rules are obtained by analyzing the protocol logs corresponding to each first session.
[0172] Based on the blocking rules, session monitoring is performed on the real-time traffic sessions to obtain the second session corresponding to the blocking rules;
[0173] According to the second session, a blocking message is sent to the source host; the blocking message is used to block the connection between the source host and the target host.
[0174] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:
[0175] Send the protocol logs corresponding to each first session to the backend so that the backend can filter the vulnerability scanning features of each protocol log, obtain the target logs containing vulnerability scanning features, and generate blocking rules based on the target logs.
[0176] Receive blocking rules sent by the backend.
[0177] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:
[0178] The blocking rules are generated by the backend based on the scanner identifier of the scanner to be blocked; the scanner identifier is determined based on the attack source identifier contained in the target log.
[0179] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:
[0180] Determine the protocol type for the second session;
[0181] Determine the blocking message to be sent based on the protocol type;
[0182] Send a blocking message to the source host.
[0183] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:
[0184] In the case of a Transmission Control Protocol (TCP) session, the TCP RST message is treated as a blocking message.
[0185] In the case of a User Datagram Protocol (UDP) session, the Internet Control Message Protocol (ICMP) Port Unreachable message is treated as a blocking message.
[0186] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:
[0187] Based on pre-defined vulnerability scanning behavior rules, real-time traffic sessions are monitored, and at least one session that meets the vulnerability scanning behavior rules is designated as the first session.
[0188] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.
[0189] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.
[0190] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0191] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.
Claims
1. A vulnerability scanning and blocking method, characterized in that, The method includes: Identify at least one first session that constitutes vulnerability scanning behavior; The blocking rules are obtained by analyzing the protocol logs corresponding to each of the first sessions. Based on the blocking rule, session monitoring is performed on the real-time traffic session to obtain the second session corresponding to the blocking rule; According to the second session, a blocking message is sent to the source host; wherein the blocking message is used to block the connection between the source host and the target host.
2. The method according to claim 1, characterized in that, The step of analyzing the blocking rules based on the protocol logs corresponding to each first session to obtain the blocking rules includes: The protocol logs corresponding to each first session are sent to the backend so that the backend can perform vulnerability scanning feature filtering on each protocol log to obtain target logs containing vulnerability scanning features, and generate the blocking rule based on the target logs. Receive the blocking rule sent by the backend.
3. The method according to claim 2, characterized in that, The blocking rule is generated by the backend based on the scanner identifier of the scanner to be blocked; the scanner identifier is determined based on the attack source identifier contained in the target log.
4. The method according to claim 1, characterized in that, The step of sending a blocking message to the source host according to the second session includes: Determine the protocol type of the second session; Based on the protocol type, determine the blocking message to be sent; Send a blocking message to the source host.
5. The method according to claim 4, characterized in that, The step of determining the blocking message to be sent based on the protocol type includes: In the case where the protocol type is Transmission Control Protocol (TCP) session, the Transmission Control Protocol Reset Message (TCP RST) will be used as a blocking message. In the case of a User Datagram Protocol (UDP) session, the Internet Control Message Protocol (ICMP) Port Unreachable message is treated as a blocking message.
6. The method according to claim 1, characterized in that, The determination of at least one first session belonging to vulnerability scanning behavior includes: Based on pre-defined vulnerability scanning behavior pre-conditions, real-time traffic sessions are monitored, and at least one session that conforms to the vulnerability scanning behavior pre-conditions is selected as the first session.
7. A vulnerability scanning and blocking device, characterized in that, The device includes: The determination module is used to identify at least one first session that belongs to vulnerability scanning behavior; The analysis module is used to analyze the blocking rules based on the protocol logs corresponding to each of the first sessions to obtain the blocking rules; The monitoring module is used to perform session monitoring on real-time traffic sessions according to the blocking rules, and obtain the second session corresponding to the blocking rules; The sending module is configured to send a blocking message to the source host according to the second session; the blocking message is used to block the connection between the source host and the target host.
8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.
10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.