Classification-based suppression and blocking methods and systems for botnets with different communication architectures

Abstract

The present invention provides a method and system for classifying and suppressing zombie networks facing different communication architectures, which relates to the field of network security technology. The method includes: determining an implementable suppression channel according to control instructions, heartbeat mechanisms, and data synchronization characteristics, in combination with the protocol characteristics and network structure to which they belong; matching a corresponding blocking scheme based on the suppression channel; the blocking scheme is selected according to the communication architecture type of the zombie network, and the communication architecture type includes centralized control C2 communication type, peer-to-peer P2P communication type, and hybrid type; implementing blocking measures matching the blocking scheme through policy scheduling, adjusting the suppression blocking intensity according to network feedback, coordinating multi-point linkage operations, and evaluating the blocking effect at the same time. The present invention enhances the ability to govern zombie networks in cyberspace by effectively cutting off and interfering with the communication links of centralized control communication type, peer-to-peer communication type, and hybrid type zombie networks.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a method and system for classifying and blocking botnets for different communication architectures. Background Technology

[0002] With the rapid development of the internet, botnets, as a common cybersecurity threat, have become widespread globally. A botnet is a distributed attack network formed by hackers controlling a large number of compromised computers ("zombie computers") with malware. It can launch DDoS attacks, steal sensitive information, and engage in other illegal activities, posing a serious threat to individual rights, business operations, and national security. For example, a financial institution suffered a hybrid botnet attack, resulting in the leakage of 100,000 user information records, $8 million in losses, and 24-hour service disruption. Its technical architecture has continuously evolved, from early IRC centralized control to P2P self-organizing networks, and now to a hybrid architecture integrating C2 and P2P communication. P2P botnets like Mozi achieve propagation across over 1.5 million nodes through encrypted communication, while hybrid architectures like GameoverZeus combine TCP C2 communication with DHT node synchronization to enhance defense and evasion capabilities.

[0003] Existing defense technologies have the following problems: architecture identification relies on single features such as fixed C2IPs, which may be difficult to deal with mixed multi-channel features, leading to policy mismatch; traditional technologies such as Sinkhole may be effective against centralized C2 but ineffective against P2P networks, and Kelihos botnets can quickly rebuild links through neighbor discovery; fixed-strength blocking may lead to a cycle of over-defense and under-defense, affecting normal services or allowing attacks to continue; single-point defense may lack cross-domain coordination and cannot deal with cross-regional attacks such as Mirai variants. Summary of the Invention

[0004] The technical problem to be solved by this invention is to provide a classification-based suppression and blocking method and system for botnets with different communication architectures. By effectively cutting off and interfering with the communication links of centralized control communication type, point-to-point communication type and hybrid botnet, the ability to manage botnets in cyberspace is improved.

[0005] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:

[0006] Firstly, a categorized suppression and blocking method for botnets with different communication architectures, the method comprising:

[0007] Step 1: Extract the communication parameters between the zombie node and the control terminal from the network traffic through traffic mirroring and protocol decoding. The communication parameters include protocol type, port number and data characteristics.

[0008] Step 2: Based on the communication parameters, perform pattern analysis to identify control commands, heartbeat mechanisms, and data synchronization characteristics;

[0009] Step 3: Based on the control commands, heartbeat mechanism, and data synchronization characteristics, combined with the characteristics of the protocol and network structure to which they belong, determine the feasible suppression channels;

[0010] Step 4: Based on the suppression channel, match the corresponding blocking scheme; the blocking scheme is selected according to the communication architecture type of the botnet, which includes centralized control C2 communication type, peer-to-peer P2P communication type and hybrid type;

[0011] Step 5: Implement blocking measures that match the blocking plan through strategy scheduling, adjust the intensity of suppression and blocking based on network feedback, coordinate multi-point linkage operations, and evaluate the blocking effect.

[0012] Secondly, a botnet classification and suppression system for different communication architectures includes:

[0013] The extraction module is used to extract communication parameters between zombie nodes and the control terminal from network traffic through traffic mirroring and protocol decoding. The communication parameters include protocol type, port number and data characteristics.

[0014] The analysis module is used to perform pattern analysis based on communication parameters to identify control commands, heartbeat mechanisms, and data synchronization characteristics.

[0015] The suppression channel module is used to determine the implementable suppression channels based on control commands, heartbeat mechanisms, and data synchronization characteristics, combined with the characteristics of the protocol to which they belong and the network structure.

[0016] The matching module is used to match corresponding blocking schemes based on the suppressed channels; the blocking schemes are selected according to the communication architecture type of the botnet, which includes centralized control C2 communication type, peer-to-peer P2P communication type and hybrid type;

[0017] The feedback module is used to implement blocking measures that match the blocking scheme through strategy scheduling, adjust the suppression and blocking intensity based on network feedback, coordinate multi-point linkage operations, and evaluate the blocking effect.

[0018] Thirdly, a computing device, comprising:

[0019] One or more processors;

[0020] A storage device for storing one or more programs that, when executed by one or more processors, cause the one or more processors to implement the method.

[0021] Fourthly, a computer-readable storage medium storing a program that, when executed by a processor, implements the method.

[0022] The above-described solution of the present invention has at least the following beneficial effects:

[0023] By extracting core parameters such as protocol type and port number through traffic mirroring and protocol decoding, it's like equipping the defense system with a feature microscope, enabling precise location of communication characteristics between botnet nodes and control terminals from massive amounts of traffic. Pattern analysis deeply identifies behavioral characteristics such as control commands and heartbeat mechanisms, essentially building a behavioral graph that can fully reconstruct the command logic and coordination patterns of the botnet. It can not only selectively cut off control links but also predict botnet evasion methods, providing a basis for proactive defense. Combining protocol characteristics and network structure to determine suppression channels avoids the resource waste of indiscriminate defense. Customized blocking schemes for different architectures such as centralized and P2P demonstrate differentiated performance. A differentiated operational approach is employed; for example, domain name dumping technology is used for C2-type botnets to resolve malicious domain names to invalid IPs; for P2P-type botnets, node clusters are segmented through dynamic rules; this categorized approach maximizes the blocking effect while minimizing the impact on normal P2P applications (such as file sharing), balancing security and business continuity; the policy scheduling and effect evaluation mechanism forms an adaptive feedback loop, which can cope with the dynamic evolution of botnets by adjusting the blocking strength in real time and coordinating multi-point linkage; at the same time, continuous effect evaluation can verify the effectiveness of blocking measures and avoid defense failures caused by missing backup channels, similar to the Kelihos botnet. Attached Figure Description

[0024] Figure 1 This is a flowchart illustrating a botnet classification and suppression method for different communication architectures provided in an embodiment of the present invention.

[0025] Figure 2 This is a schematic diagram of a botnet classification and suppression blocking system for different communication architectures provided by an embodiment of the present invention. Detailed Implementation

[0026] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0027] like Figure 1 As shown, embodiments of the present invention propose a botnet classification-based suppression and blocking method for different communication architectures, the method comprising the following steps:

[0028] Step 1: Extract the communication parameters between the zombie node and the control terminal from the network traffic through traffic mirroring and protocol decoding. The communication parameters include protocol type, port number and data characteristics.

[0029] Step 2: Based on the communication parameters, perform pattern analysis to identify control commands, heartbeat mechanisms, and data synchronization characteristics;

[0030] Step 3: Based on the control commands, heartbeat mechanism, and data synchronization characteristics, combined with the characteristics of the protocol and network structure to which they belong, determine the feasible suppression channels;

[0031] Step 4: Based on the suppression channel, match the corresponding blocking scheme; the blocking scheme is selected according to the communication architecture type of the botnet, which includes centralized control C2 communication type, peer-to-peer P2P communication type and hybrid type;

[0032] Step 5: Implement blocking measures that match the blocking plan through strategy scheduling, adjust the intensity of suppression and blocking based on network feedback, coordinate multi-point linkage operations, and evaluate the blocking effect.

[0033] In this embodiment of the invention, traffic mirroring and protocol decoding are used to obtain the true protocol type, port number, and data characteristics, avoiding subjective bias and laying a reliable data foundation for subsequent analysis; zombie nodes and malicious links at the control end are accurately located without confusing normal traffic, such as legitimate TCP sessions, reducing the cost of ineffective analysis; control commands, heartbeat mechanisms, and data synchronization characteristics are parsed to clarify the botnet's operating mode, rather than simply judging abnormal traffic; malicious and normal protocol behaviors are distinguished to avoid indiscriminate defense that may block legitimate services, such as not affecting normal C2 command transmission; weak links in the botnet, such as TCP connection links and P2P neighboring nodes, are located without interfering with normal links; and feasible suppression measures are clearly defined. Control channels, such as C2 port resources and P2P routing tables, to ensure accurate matching of subsequent solutions and avoid aimless attacks; for differentiated matching solutions for C2 / P2P / hybrid types, such as using TCPRST for C2 and pseudo-neighbor attacks for P2P, solve the problem of single policy adaptation and improve the blocking success rate; focus on architectural weaknesses and avoid ineffective interventions, such as not using IP blocking for P2P, to reduce the waste of computing power and bandwidth and lower governance costs; dynamically adjust blocking strength and coordinate multiple points to deal with botnet evasion behavior and maintain continuous blocking effect; through effect evaluation, such as verifying session interruption, avoid excessive defense affecting normal services; optimize strategies based on evaluation feedback to form a governance closed loop and prevent policy solidification and failure.

[0034] In a preferred embodiment of the present invention, step 1 above includes:

[0035] Step 11: Capture raw network data packets and obtain a complete copy of network traffic by deploying traffic mirroring devices at key network nodes. Specifically, this includes: First, determining the deployment location of key network nodes, which include, but are not limited to, network core switches, router access ports, gateway exits, and other nodes capable of handling full traffic flow; physically connecting or logically associating the traffic mirroring device with the key network nodes; starting the traffic mirroring device and configuring mirroring rules: setting the range of network links to be captured, clearly defining target links that may contain zombie nodes communicating with the control terminal, and excluding non-target links such as internal test links that do not need to be monitored and verified legitimate dedicated links.

[0036] The traffic mirroring device receives all raw network data packets flowing through the key network nodes in real time according to the configured rules. The raw network data packets include a packet header, a data payload, and a tail check field. The packet header includes a frame header, an IP header, and a transport layer protocol header. The received raw network data packets are stored in the order of the received timestamps. During the storage process, the original format and data integrity of the data packets are maintained, and no fields are deleted, modified, or compressed, forming a complete copy of the network traffic covering the target link.

[0037] Step 12: Based on the original data packets, a protocol decoder is used to parse the original data packets and identify the communication protocol type used by the original data packets. Specifically, this includes: pre-constructing a multi-protocol parsing rule base. The core function of the multi-protocol parsing rule base is to store feature templates of commonly used botnet communication protocols such as TCP, UDP, and DHT, providing a standardized comparison basis for subsequent original data packet protocol type determination. Its construction needs to revolve around the precise definition of feature templates, as detailed below:

[0038] Based on governance scenarios targeting centralized control (C2), peer-to-peer (P2P), and hybrid botnets, the rule base focuses on only three core communication protocols: TCP is commonly used for session-based communication in C2-type botnets, UDP is commonly used for connectionless communication in C2-type or hybrid botnets, and DHT is commonly used for node routing and data querying in P2P-type botnets. Dedicated protocols unrelated to botnet communication, such as industrial control protocols, are excluded to avoid redundancy.

[0039] Each protocol's feature template contains three core elements: key identification fields, header length definition, and typical interaction start field features. These three elements together constitute the protocol's identity identifier, ensuring that different protocols can be accurately distinguished during subsequent comparisons.

[0040] The TCP protocol feature template definition uses key identifier fields derived from the IP header and TCP header: At the IP header level, there is a protocol type field, occupying 8 bits and located in the 9th byte of the IP header. A standard value of 6 for this field uniquely corresponds to the TCP protocol; this is the core identifier of the TCP protocol, used for initial protocol attribution. The TCP header auxiliary identifier is a flag field, occupying 6 bits and located in the 13th byte of the TCP header. This includes combinations of flags such as SYN (synchronization) and ACK (acknowledgment). For example, SYN=1 and ACK=0 indicates a connection request, while SYN=1 and ACK=1 indicates a connection acknowledgment. These are unique interaction status identifiers of the TCP protocol and are supplemented into the key identifier field for further verification of the protocol type.

[0041] The TCP header length is a variable value, defined according to the TCP protocol specification: the TCP header includes a header length field, which occupies 4 bits and is located in the last 4 bits of the first byte of the TCP header. Its value is in units of 4 bytes. The minimum value of this field is 5, corresponding to a fixed 20-byte header with no option field, and the maximum value is 15, corresponding to a 60-byte header with a maximum length option field. The rule base explicitly records the position, value range, and conversion rule of the header length field (value × 4 = actual header byte count), ensuring that the actual header length can be calculated from the field value.

[0042] Typical interaction start field characteristics: TCP communication typically starts with connection establishment, corresponding to the characteristics of the SYN packet: the TCP header flag field satisfies SYN=1 and ACK=0; the TCP header sequence number field is a 32-bit random initial value, not a fixed value or 0. This feature is used to identify the interaction start phase of the TCP protocol and assists in protocol type verification.

[0043] The UDP protocol feature template definition uses key identifier fields derived from the IP packet header and UDP header: At the IP packet header level, the IP packet header protocol type field (same location as TCP) has a standard value of 17, which uniquely corresponds to the UDP protocol; this is the core identifier of the UDP protocol. The UDP header auxiliary identifier is that UDP is a connectionless protocol with no flag fields, so the UDP header length field is extracted, occupying 16 bits and located in bytes 4-5 of the UDP header. This field records the total number of bytes in the UDP header and data payload, with a minimum value of 8, corresponding to a fixed UDP header length and no payload. This serves as an auxiliary identifier to distinguish UDP from other connectionless protocols.

[0044] The UDP header is defined as having a fixed length. According to the UDP protocol specification, the UDP header contains only four fields: source port, destination port, length, and checksum, each occupying 2 bytes. The total length is fixed at 8 bytes. The rule base directly records the fixed 8 bytes and the length field to deduce the payload length, and the logic of subtracting 8 bytes from the total length, without the need for dynamic calculation.

[0045] Typical interaction start field characteristics: UDP has no fixed handshake process, and its typical start corresponds to the transmission of the first packet on a specific port: the source port or destination port of the first packet belongs to the range of commonly used UDP ports in botnets, such as 10001-10010, based on botnet communication sample statistics; the payload of the first packet contains a fixed prefix (such as 0xAA0xBB, which is a common identifier for botnet UDP communication). This feature is used to adapt to the starting pattern of botnet UDP communication and assist in protocol determination.

[0046] The DHT protocol feature template definition uses key identifier fields. DHT is an application layer protocol, and its core identifier is derived from the application layer payload header. The application layer payload header contains unique fixed identifier bytes. By analyzing botnet DHT communication samples and legitimate DHT communication samples, common fixed byte sequences are extracted, such as the B-encoded format identifier d1:ad2:id20:, or a custom 1-2 byte starting identifier 0x000x11. This is the core identifier of the DHT protocol. Auxiliary identifiers in the DHT payload include query / response type fields, such as the q field in a query request. Typical values ​​are find_node and get_peers, commonly used routing instructions for P2P botnet nodes. The rule base records the location (N bytes after the payload start) and typical values ​​of this field as auxiliary identifiers.

[0047] The header length definition in DHT headers specifically refers to the starting segment in the application layer payload used to identify the protocol type. Through sample analysis, it is determined whether the starting segment is of fixed or variable length. If it is of fixed length, the specific number of bytes is recorded, such as 6 bytes containing a fixed identifier byte and a type field. If it is of variable length, the end-of-header identifier is recorded, such as using 'e' as the header end-of-header identifier. The header length = the number of bytes from the start identifier to 'e', ​​ensuring that the header segment can be accurately truncated.

[0048] The typical interaction start field characteristic is that DHT communication typically starts with a query request. The corresponding payload characteristics are: the application layer payload starts with d1:q, a query type identifier in B-encoded format; followed by a specific query instruction string, such as find_node or get_peers. This feature directly corresponds to the node interaction start behavior of P2P botnets and is used to accurately identify the DHT protocol.

[0049] After completing the construction of the multi-protocol parsing rule base, the protocol type of the original data packets obtained in step 11 needs to be determined one by one according to the process of retrieving data packets, extracting identification fields, template comparison, and record storage. Specifically, from the complete copy of network traffic obtained in step 11, each original data packet is retrieved one by one according to the storage timestamp order of the data packets. The retrieved original data packets must retain the frame header, IP packet header, transport layer / application layer header, data payload, and tail check fields completely without any field modification or deletion to ensure the originality of the parsed object.

[0050] For a single raw data packet, two core identification fields—the protocol type identification field and the start identification field—are extracted hierarchically. The specific extraction logic is as follows: If the protocol to be determined is a transport layer protocol (TCP, UDP), first locate the IP header of the data packet, find the protocol type field (9th byte, 8th bit), and read the specific value of this field; if the protocol to be determined is an application layer protocol, since the DHT protocol is based on the transport layer protocol, the transport layer protocol identification field needs to be extracted first. For example, if the IP header protocol type field value is 17, the transport layer is determined to be UDP. Then, locate the application layer payload header and extract the application layer protocol identification field unique to the DHT protocol, such as the fixed identifier bytes d1:ad2:id20:. The core principle is that if it is a protocol above the network layer, such as the application layer DHT, first extract the protocol identification field of the corresponding bearer layer, and then extract the protocol identification field of the target layer to ensure the correctness of the extraction hierarchy of the identification fields.

[0051] If it is the TCP protocol, locate the TCP header, extract the flag field (byte 13, 6 bits), and read its value combination, such as SYN=1, ACK=0; if it is the UDP protocol, locate the UDP header and payload, extract the length field (bytes 4-5, 16 bits) and the fixed prefix of the payload, such as 0xAA0xBB; if it is the DHT protocol, locate the application layer payload, extract the query type identifier field at the beginning of the payload, such as d1:q, and the subsequent query instructions, such as find_node;

[0052] The start identifier field must match the protocol type to ensure that the extracted fields are the interaction start-related fields specific to that protocol.

[0053] The extracted protocol type identifier field and start identifier field are compared one by one with the feature templates of TCP, UDP, and DHT in the multi-protocol parsing rule base. The comparison must meet a triple matching condition, as follows: Complete match of the protocol type identifier field means that the extracted protocol type identifier field is completely consistent with the key identifier field in a certain protocol feature template. For example, the extracted value 6 is completely consistent with the protocol type identifier in the IP packet header of the TCP template. Complete match of the start identifier field means that the extracted start identifier field is completely consistent with the typical interaction start field feature in the protocol feature template. For example, the extracted SYN=1, ACK=0 is completely consistent with the start feature of the TCP template. The header length must be completely consistent with the template definition. This involves calculating or reading the header length of the corresponding layer of the data packet. For example, the TCP header length is equal to the value of the header length field multiplied by 4, the UDP header length is 8 bytes, and the DHT header length is the number of bytes from the start identifier to the end identifier. This length must conform to the header length definition in the protocol feature template. For example, the TCP header length is in the range of 20-60 bytes, and the UDP header length is 8 bytes. When all three conditions are met, the communication protocol type used by the original data packet can be determined to be the protocol corresponding to the matching feature template. If all three conditions of the TCP template are met, it is determined to be the TCP protocol.

[0054] For each raw data packet that has completed protocol type determination, perform the following operations: Add a protocol type identifier label to the data packet, such as PROTO_TCP for TCP, PROTO_UDP for UDP, and PROTO_DHT for DHT. The label must be unique and correspond one-to-one with the protocol type in the rule base; Associate the protocol type identifier with the data packet itself (including complete fields) and store it, retaining the original storage order and timestamp information of the data packet during storage.

[0055] Step 13: Based on the communication protocol type, parse the specific header structure of the protocol, extract the source port number and destination port number from the protocol header fields to obtain port information. Specifically, this includes: based on the communication protocol type identified in Step 12, calling the header parsing module corresponding to the protocol type from the preset protocol header parsing module library. The header parsing module pre-stores the header field definitions of the corresponding protocol, including the starting offset of the source port number field and the destination port number field in the protocol header, the field length, and the data storage format, such as binary big-endian or hexadecimal; retrieving the original data packet associated with the protocol type identifier in Step 12, and locating the corresponding protocol header of the data packet, such as locating the TCP header for the TCP protocol and the UDP header for the UDP protocol.

[0056] Based on the preset starting offset of the source port number field in the header parsing module, a field of corresponding length is extracted from the protocol header. The extracted field is then converted into a decimal value according to a preset data storage format, and this value is the source port number. Similarly, based on the starting offset of the destination port number field, a field of corresponding length is extracted and converted into a decimal value to obtain the destination port number. The source port number and the destination port number are integrated to form the port information corresponding to the original data packet. The port information is then associated with the protocol type identifier of the data packet and the data packet itself and stored. The port number value is verified to be within the valid value range of 0-65535. If it exceeds the range, it is marked as abnormal port information for subsequent verification.

[0057] Step 14: Based on port information and communication protocol type, further analyze the payload content of the data packets and extract data features including specific instruction formats, encryption characteristics, and communication frequency. Specifically, this includes: retrieving the original set of data packets associated with port information and protocol type identifiers in Step 13, and filtering based on port information: setting a target port range, retaining data packets whose source or destination port in the port information belongs to the target port range, and excluding data packets whose port information is unrelated to the target port range, forming a subset of data packets to be analyzed; according to the protocol type identifier of each data packet in the subset of data packets to be analyzed, calling the payload parsing rules of the corresponding protocol, such as TCP protocol requiring reassembly of segmented payload data based on sequence number; UDP protocol directly reads the complete payload field without reassembly, and processes the payload part of each data packet to obtain complete and analyzable payload data.

[0058] A pre-built library of common control command format templates is constructed. Each template includes the command's start identifier byte (e.g., a fixed 0xAA, 0xBB start sequence), the command length field position and encoding rules, and the numerical range corresponding to the command type encoding. The payload data of each data packet is compared byte-by-byte with each command format template in the library. If a segment in the payload data matches the start identifier byte of a template, conforms to the encoding rules for its length field, and has its type encoding within the corresponding numerical range, the segment is marked as a specific command format, and format details such as the start identifier, length, and type encoding position are recorded. Byte distribution statistics are performed on the payload data, calculating the frequency and probability distribution of each byte value (0-255). If the frequency distribution is uniform, with no clearly concentrated byte values, and the payload data contains continuous segments of fixed length, such as 16 bytes or 32 bytes, conforming to the block length of common encryption algorithms, or containing encryption algorithm identifier fields, such as ASCII encoded segments corresponding to RSA and AES, then the payload data is determined to have encryption characteristics, and features such as the degree of uniformity, fixed-length segment size, and algorithm identifier (if present) are recorded.

[0059] Set a statistical time period, such as 5 minutes as a period. Within each period, count the number of data packet interactions with the same source port, destination port, and protocol type combination in the subset of data packets to be analyzed. Divide the number of interactions within the period by the period duration to convert it to seconds to obtain the average interaction frequency per unit time. Use this frequency as the communication frequency feature. Integrate the recorded results of specific instruction formats, encryption features, and communication frequencies to form a complete data feature corresponding to each data packet to be analyzed, and store it in association with the protocol type and port information of the data packet.

[0060] In this embodiment of the invention, a traffic mirroring device captures the original data packets and obtains a complete copy, ensuring the integrity and comprehensiveness of network traffic data. The captured original data packets contain all the communication information between the botnet node and the control terminal, avoiding the omission of key communication details in subsequent parsing due to missing data. A protocol decoder is used to parse the original data packets and identify the communication protocol type, achieving accurate determination of the communication protocol type. This clearly distinguishes different protocols used by the botnet, such as TCP, UDP, and DHT, avoiding deviations in subsequent analysis direction due to ambiguous protocol type judgment. The header structure is parsed according to the protocol type, and the source / destination port number is extracted, achieving accurate extraction of port information. Combining the differences in the header structure of different protocols, the header fields are parsed in a targeted manner, accurately obtaining the source and destination port numbers of the communication between the botnet node and the control terminal, avoiding errors in port information extraction due to general parsing methods. The payload is analyzed based on the port and protocol, and data features are extracted to deeply explore the core data features of botnet communication. By analyzing the data packet payload, key information such as specific instruction formats, encryption features, and communication frequencies can be extracted, avoiding only superficial data.

[0061] In a preferred embodiment of the present invention, step 2 above includes:

[0062] Step 21: Based on the data characteristics of the communication parameters, compare the specific instruction format with the known botnet instruction patterns in the predefined rule base to identify the control instructions. Specifically, this includes: firstly, extracting the core data characteristics of the communication data to be analyzed from the previously captured botnet communication traffic, including the structural composition of the data packet payload field, fixed byte sequence, field length range, and field separator type; the payload field structure needs to be decomposed into five parts: start identifier segment, opcode segment, parameter length segment, parameter content segment, and check segment. For example, extract the feature information of a data packet payload where the start identifier segment is 0xAA55, the opcode segment is 1 byte, the parameter length segment is 2 bytes, and the check segment is in CRC16 format; at the same time, record the auxiliary parameters such as the transport layer protocol type and source / destination port number corresponding to the communication data.

[0063] The system invokes a pre-built rule base of known botnet command patterns. This rule base is constructed by collecting control command characteristics from publicly disclosed botnet samples over the past five years. Each rule in the base contains key information such as command structure template, opcode value range, field length threshold, verification algorithm type, and associated protocol / port. For example, a rule in the rule base targeting the TCP protocol C2 botnet is defined as follows: start identifier 0xAA55, opcode range 0x01-0x0F, parameter length range 0x0004-0x0100, verification algorithm CRC16, and associated port 6667.

[0064] The extracted features of the data to be analyzed are compared and calculated field by field with the individual rules of the rule base: it is determined whether the byte sequence of the starting identifier segment of the data to be analyzed is completely consistent with the starting identifier segment in the rule. If there is a difference of less than 1 byte, the variation tolerance item in the rule base is further combined, such as allowing 1 byte of random padding after the starting identifier segment, to determine whether it meets the requirements; it is checked whether the value of the opcode segment of the data to be analyzed falls within the range of opcode values ​​in the rule. At the same time, combined with the associated protocol / port parameters, interference data of non-target protocol / port is excluded. For example, TCP protocol data is only compared with TCP-type instruction rules in the rule base; it is verified whether the value of the parameter length segment of the data to be analyzed meets the field length threshold requirement in the rule. At the same time, the verification algorithm specified by the rule is used to verify and calculate the opcode segment, parameter length segment, and parameter content segment, and it is determined whether the calculation result is consistent with the verification segment of the data to be analyzed.

[0065] The number of consistent items in the above field-by-field comparison is counted. If the three items of the starting identifier segment, opcode segment, and check segment are completely consistent, and the parameter length segment meets the threshold requirement and the associated protocol / port matches, then the instruction corresponding to the data to be analyzed is determined to be a botnet control instruction. If there is only one non-core field difference, combined with the characteristic consistency of the subsequent 10 similar data packets of the communication data, if more than 80% of the similar data packets meet the above comparison conditions, it is further determined whether it is a control instruction.

[0066] Step 22: Using control commands and communication frequency data, identify a heartbeat mechanism that conforms to a periodic pattern by statistically analyzing the distribution pattern of time intervals between adjacent control commands. Specifically, this includes: extracting the transmission timestamp of each control command from the data packets corresponding to the control commands identified in Step 21, accurate to the millisecond level. This timestamp is taken from the reception time field in the header of the data packet and recorded in real time by the packet capture tool during capture. For example, the timestamps of 5 control commands collected from a certain node are 1690000000123ms, 1690000030121ms, 1690000060119ms, 1690000090125ms, and 1690000120122ms.

[0067] The control commands are sorted according to their timestamps. The time interval between each group of adjacent control commands is obtained by subtracting the timestamp value of the earlier control command from the timestamp value of the later control command. For example, based on the timestamps of the above 5 control commands, the 4 time interval values ​​are calculated to be 29998ms, 29998ms, 30006ms, and 30003ms.

[0068] Calculate the statistical parameters of the time interval dataset, including the interval mean, interval variance, and interval frequency distribution. The interval mean is the sum of all interval values ​​divided by the number of intervals; for example, the mean of the above 4 intervals is (29998 + 29998 + 30006 + 30003) / 4 = 30001.25 ms. The interval variance is the sum of the squared differences between each interval value and the mean, divided by the number of intervals; for example, the variance of the above intervals is approximately 15.69. The interval frequency distribution is a statistical... The frequency of each interval value falling within different ranges is counted. For example, if all the intervals mentioned above fall within the range of 29995ms-30010ms, the frequency is 4. An interval value exceeding ±10% of the mean is set as an abnormal interval standard. For example, the abnormal threshold corresponding to the mean of 30001.25ms is 27001.125ms-33001.375ms. If an interval value exceeds this range, such as an interval of 50000ms, it is judged as an abnormal interval and removed from the dataset, and will not be included in subsequent pattern analysis.

[0069] If the time interval dataset meets the following conditions, a heartbeat mechanism is determined to exist: the fluctuation range of the mean interval is ≤5%, such as the mean of 20 consecutive intervals being stable within 30000ms ± 1500ms; the proportion of intervals falling within the mean ± 2% range is ≥80% of the total number of intervals, such as the above 4 intervals falling within the range of 29401.23ms-30601.27ms, accounting for 100%; the duration of this interval pattern is ≥3 interval cycles, such as the interval pattern of around 30000ms appearing continuously for more than 90 seconds; at the same time, the mean interval that meets the conditions is determined as the heartbeat cycle, such as the heartbeat cycle of 30000ms in the above case.

[0070] Step 23: Based on the heartbeat mechanism's occurrence time period, analyze the change pattern of data packet payload content within that time period. When multiple nodes are detected to be synchronously updating content within a specific heartbeat cycle, identify data synchronization characteristics. Specifically, based on the heartbeat cycle determined in Step 22, such as 30000ms, divide the communication time axis into continuous heartbeat periods. The duration of each heartbeat period is equal to the heartbeat cycle, and the starting point of the period is aligned with the timestamp of a certain control command. For example, using timestamp 1690000000123ms as the starting point of the first heartbeat period, divide continuous heartbeat periods such as 1690000000123ms-1690000030122ms and 1690000030123ms-1690000060122ms.

[0071] During each heartbeat period, the data packet payloads of at least 10 zombie nodes communicating with the control terminal are collected, and identifiable content fields are extracted from the payloads, such as data version number, data block number, data checksum, configuration parameter identifier, etc. For example, during a certain heartbeat period, the payloads of nodes A, B, C, and D are collected, and the version number fields of each node's payload are extracted as V2.1.0, V2.1.0, V2.1.0, and V2.1.0, respectively, and the data checksum is 0x12345678.

[0072] The system calculates the percentage of identical identifier fields in the load data of each node within the same heartbeat period. For example, if all four nodes have the same version number (V2.1.0) within the aforementioned heartbeat period, the consistency percentage is 100%. If, within a heartbeat period, nine out of ten nodes change their configuration parameter identifier from Config_001 to Config_002, the consistency percentage for that field is 90%. The system also compares the changes in the same identifier field between two adjacent heartbeat periods. For example, if most nodes had the same version number (V2.0.0) in the previous heartbeat period and most nodes have changed to V2.1.0 in the current heartbeat period, then the system determines that the field has undergone a consistent change across different time periods.

[0073] Data synchronization characteristics are identified if the following conditions are met: Within the same heartbeat period, at least one identifier field, such as version number or checksum, has the same value in ≥70% of the nodes; this identifier field exhibits a uniform change within adjacent heartbeat periods, such as being updated from an old value to a new value, and this uniform change occurs at least once within three consecutive heartbeat periods; isolated changes in a single node are excluded, such as only one node having a different identifier field value from other nodes, and subsequent periods do not cause other nodes to change synchronously, ensuring that the change pattern is universal across nodes; for example, in the above case, the version number and checksum of the four nodes are completely consistent within the same heartbeat period, and the version number is uniformly updated from V2.0.0 to V2.1.0 compared to the previous period, then data synchronization characteristics are identified.

[0074] In this embodiment of the invention, by comparing communication parameter data features with a predefined rule base, and relying on the known botnet instruction patterns in the rule base, including key information such as structure, opcode, and verification algorithm, botnet control instructions can be accurately distinguished from normal network instructions. The comparison process focuses on core fields such as the start identifier segment, opcode segment, and check segment, while combining auxiliary parameters such as transport layer protocol and port to narrow the comparison range. It eliminates the need for indiscriminate analysis of all communication data, improving the identification efficiency of control instructions and laying the foundation for the rapid implementation of subsequent suppression strategies. The heartbeat mechanism is crucial for the botnet control end to maintain connection with nodes and confirm the online status of nodes. By statistically analyzing the time interval distribution of adjacent control instructions, the heartbeat cycle can be accurately identified, directly locking the core rules for maintaining communication in the botnet. After clarifying the heartbeat cycle, subsequent suppression operations can be carried out around the cycle pattern, eliminating the need for 24-hour indiscriminate monitoring of node communication and reducing the consumption of computing, bandwidth, and other resources. Data synchronization is a prerequisite for botnet nodes to uniformly update malicious configurations and launch coordinated attacks. By analyzing load changes and identifying the synchronous update characteristics of multiple nodes by associating heartbeat periods, the synchronous update characteristics of multiple nodes can be associated with scattered bot nodes, expanding the governance coverage.

[0075] In a preferred embodiment of the present invention, step 3 above includes:

[0076] Step 31: Based on the interaction mode and communication protocol type of the control commands, analyze the inherent characteristics of the communication protocol in the connection establishment and command transmission process, and determine whether its communication architecture type is centralized control or point-to-point. Specifically, this includes: extracting the initiator IP and receiver IP of each control command from the control command data packets identified in Step 21, setting the sampling period to 30 minutes to ensure coverage of at least 3 heartbeat cycles, and based on the heartbeat cycle determined in Step 22, having a sample size of no less than 50 control commands.

[0077] The number of unique IPs at the initiating end (denoted as IP_S) and the number of unique IPs at the receiving end (denoted as IP_D) are counted. The percentage of commands initiated by a single IP and the percentage of commands received by a single IP are calculated. The percentage of commands initiated by a single IP is the number of control commands initiated by a single IP divided by the total number of control commands. The percentage of commands received by a single IP is the number of control commands received by a single IP divided by the total number of control commands. For example, if 45 out of 50 commands are initiated by the same IP, the percentage initiated by a single IP is 90%; and if 48 commands are received by the same IP, the percentage received by a single IP is 96%.

[0078] Record the sending and receiving directions of control commands, such as IP_A to IP_B, IP_C to IP_A, etc., and count the proportion of one-way interactions, i.e. the number of control commands in the same direction / the total number of control commands. Determine whether there is a fixed command sending end and command receiving end, i.e. most commands are sent from a certain IP to multiple IPs, rather than bidirectional interaction between nodes.

[0079] Analyze the inherent characteristics of communication protocols: Based on the protocol type obtained during the communication feature extraction phase, such as TCP, UDP, and DHT, analyze the inherent behavior of the protocol during the connection establishment phase. For TCP / UDP protocols, use packet capture tools, such as Wireshark, to trace the connection establishment process, count the proportion of connections with a fixed IP as the server, and the number of TCP three-way handshakes / UDP requests / total connections with that IP as the destination IP to determine whether the connection is dependent on a fixed end. For DHT protocols, extract the routing table interaction data between nodes, such as the find_node response in the Kademlia protocol, count the frequency of nodes actively discovering new neighbors, and the number of find_node requests initiated by nodes / total commands to determine whether there is decentralized node interaction logic. Analyze whether the transmission of control commands depends on the scheduling of a central node. For example, if a command needs to be sent to a fixed IP first, and then forwarded to other nodes by that IP, then a central dependency exists. If a command can be sent directly from any node to other nodes without the need for a third-party forwarding, then there is no central dependency.

[0080] Communication architecture type determination: If all of the following conditions are met, it is determined to be a centralized control architecture: the proportion of instructions initiated by a single IP is ≥80% or the proportion of instructions received by a single IP is ≥85%; the proportion of one-way interaction is ≥90%, that is, most instructions are sent from a fixed IP to multiple nodes; during the protocol connection establishment phase, the proportion of connections with a fixed IP as the server is ≥85%, TCP / UDP protocol, or there is a clear central scheduling node, such as instructions need to be forwarded through a certain IP.

[0081] A peer-to-peer architecture is defined as follows: the number of initiating IPs (S) is ≥10 and the number of receiving IPs (D) is ≥10, and the number of nodes is sufficiently dispersed; the proportion of commands initiated / received by a single IP is ≤20%; the protocol is a decentralized protocol such as DHT; the frequency of nodes actively discovering neighbors is ≥3 times / minute, and command transmission does not require forwarding by a central node.

[0082] If the criteria for both architectures mentioned above are partially met, such as a single IP initiating 50%-79% of commands and there is direct interaction between some nodes, it is temporarily identified as a hybrid architecture that needs further verification.

[0083] Step 32: Based on the distribution characteristics of target addresses and the topological relationships between nodes reflected by the data synchronization characteristics of the heartbeat mechanism, construct a connection structure model of the botnet and determine whether its network topology is star, hierarchical, or mesh. Specifically, this includes: extracting the destination IP (i.e., the target address) of each heartbeat packet from the data packets corresponding to the heartbeat mechanism identified in Step 22; sampling for two heartbeat cycles; a sample size of no less than 100 heartbeat packets; and covering at least 20 botnet nodes; counting the number of heartbeat packets received by each target IP; and calculating the heartbeat percentage of the top 1 target IP, the heartbeat percentage of the top 3 target IPs, and the heartbeat percentage of a single node. The target number is defined as follows: the percentage of heartbeats from the top 1 target IP is the number of heartbeats received from the IP that received the most heartbeats / the total number of heartbeats; the percentage of heartbeats from the top 3 target IPs is the sum of the number of heartbeats received from the 3 IPs that received the most heartbeats / the total number of heartbeats; and the target number of heartbeats for a single node is the average number of target IPs sent by each zombie node. For example, in 100 heartbeat packets, IP_X receives 65, IP_Y receives 10, and IP_Z receives 8, with the top 1 accounting for 65% and the top 3 accounting for 83%. In 20 nodes, each node only sends heartbeats to IP_X, and the average target number of heartbeats for a single node is 1.

[0084] Based on the data synchronization features identified in step 23, the interaction data between nodes during the synchronization period is extracted, such as the source IP and destination IP of the synchronization data packets. A node interaction matrix is ​​constructed, where each row and column represents a node IP, and the matrix element represents the number of synchronization data packets between two nodes. The parent-child node relationship is statistically analyzed, i.e., a node that sends synchronization data to multiple nodes is denoted as a parent node, and a node that receives synchronization data from only a single node is denoted as a child node. The number of levels and the proportion of nodes in each level are calculated. The number of levels is the maximum number of levels from the top-level parent node to the bottom-level child node, and the proportion of nodes in each level is the number of nodes in a certain level divided by the total number of nodes. The average number of node connections and the connection dispersion are calculated to determine whether the node connections are concentrated or dispersed.

[0085] A star topology is defined as follows: the heartbeat percentage of the top-1 target IP is ≥75%, and the average number of heartbeat targets per node is ≤1.2, meaning that most nodes only send heartbeats to a single IP; in the node interaction matrix, there is one central node that interacts with ≥80% of the other nodes, and the other nodes only interact with the central node, with the percentage of interactions with non-central nodes being ≤5%; the average number of connections per node is ≤10% of the total number of nodes, and the connection is highly concentrated in the central node.

[0086] A hierarchical topology is defined as follows: the top 3 target IPs account for ≥80% of heartbeats, and the average number of target heartbeats per node is ≤2, with the target heartbeats of a node concentrated on a few IPs; the number of node levels is ≥2, and the number of top-level parent nodes is ≤3, while the number of bottom-level child nodes accounts for ≥70% of the total number of nodes, with a clear hierarchical structure; synchronous data is mainly transmitted from upper-level nodes to lower-level nodes, with the proportion of synchronous data packets from upper-level to lower-level nodes being ≥90%, and the proportion of reverse transmission being ≤10%.

[0087] A network topology is defined as follows: the percentage of heartbeats from the top-1 target IP is ≤30%, the average number of heartbeat targets per node is ≥3, and the target heartbeats of nodes are dispersed; the average number of connections per node is ≥30% of the total number of nodes, and the connection dispersion is ≤0.5, the node connections are evenly distributed, and there is no obvious center; the percentage of bidirectional interaction between nodes is ≥60%, that is, synchronous data is transmitted bidirectionally between nodes, not unidirectionally at different levels.

[0088] Step 33: Combining the communication architecture type and network topology, map and match a predefined suppression policy library to determine the most effective suppression channel for the target botnet. The suppression channel includes control server connection interruption for centralized architectures, neighbor node route pollution for peer-to-peer architectures, or specific protocol resource exhaustion for hybrid architectures. Specifically, the policy library entry structure is defined so that each entry contains five fields: communication architecture type, network topology, suppression channel name, applicable protocol scope, and core mechanism of action. Example entries are as follows:

[0089] Communication architecture type Network topology Inhibition channel name Scope of Application Core Mechanism Centralized Star Control server connection interruption TCP / UDP Disconnect zombie nodes from C2 servers peer to peer net Neighbor node routing pollution DHT Polluting the routing table of nodes and blocking neighbor interactions Hybrid (C2 dominant) Hierarchical Control server connection interruption + port resource blockage TCP+UDP Prioritize blocking C2 connections and supplement blocked ports. Hybrid (P2P dominant) net Neighbor node routing pollution + resource exhaustion DHT Prioritize polluting routes and replenish consumed node resources.

[0090] The strategy database matching index is built by using the communication architecture type as the first-level index and the network topology as the second-level index to construct a tree-shaped matching index, ensuring that the corresponding entries can be quickly located. For example, in centralized and star topologies, the index directly points to the control server connection interruption.

[0091] Based on the communication architecture type determined in step 31 (centralized / point-to-point / hybrid), locate all entries in the policy library corresponding to the architecture. For example, if the architecture is centralized, then filter out all entries with the communication architecture type = centralized. In the first-level index filtering results, based on the network topology determined in step 32, further filter out entries with a completely matching network topology. For example, if the topology is star, then filter out entries with the topology = star from the centralized entries to obtain the unique candidate suppression channel, such as control server connection interruption. If it is a hybrid architecture, first supplement the determination of the dominant architecture through step 31, such as C2 dominant: centralized feature ratio ≥ 60%; P2P dominant: P2P feature ratio ≥ 60%. Use the dominant architecture as the first-level index and the topology as the second-level index to match the main suppression channel. At the same time, use the non-dominant architecture as the auxiliary index to match the auxiliary suppression channel, such as C2 dominant and hierarchical, where the main channel is control server connection interruption and the auxiliary channel is port resource blocking.

[0092] Check whether the applicable protocol range of the candidate suppression channel is consistent with the actual protocol of the target botnet; for example, if the candidate channel is a control server connection interruption, which applies TCP / UDP, the verification will pass if the target protocol is TCP; if the target protocol is DHT, the verification will fail and other channels need to be matched again.

[0093] Assess whether the implementation of candidate channels meets the premise of not affecting normal network services: If it is to control server connection interruption, confirm by scanning that the target C2 server IP is not a public service IP, such as a normal service IP such as Baidu or Alibaba, to avoid false blocking; if it is to cause routing pollution of neighboring nodes, confirm that the target P2P network nodes have no normal user devices, such as excluding home IPs by checking the node IP's location, to avoid affecting legitimate users; if the candidate channel passes protocol verification and scenario adaptability verification, it is directly determined as an effective suppression channel; if there are multiple candidate channels, such as a primary / secondary channel in a hybrid architecture, implement the primary channel first and supplement with auxiliary channels to enhance it, and determine the final suppression channel combination, such as controlling server connection interruption and port resource blocking.

[0094] In this embodiment of the invention, the architecture type is determined by controlling the command interaction mode and communication protocol type, which can accurately distinguish between centralized and peer-to-peer botnets, avoiding mismatch of subsequent suppression strategies due to architecture misjudgment. For example, using a C2 blocking strategy to deal with a P2P architecture would result in ineffective governance, ensuring that the governance direction matches the core communication logic of the botnet. Analyzing the inherent characteristics of the protocol in connection establishment and command transmission can directly locate the key weak links in the architecture. By constructing a connection structure model through the distribution of heartbeat target addresses and node topology relationships, the abstract botnet topology can be transformed into concrete types such as star, hierarchical, and mesh. For example, the core of a star topology is the central control node, and the core of a mesh topology is the high-frequency interaction node. Based on this, the core links that need to be blocked first can be accurately identified, improving the targeting of governance. By combining the communication architecture and network topology and matching a predefined policy library, the most suitable suppression channel can be directly output, ensuring that the suppression measures directly target the communication vulnerabilities of the botnet and improve blocking efficiency. For hybrid architectures, a comprehensive judgment can accurately select targeted combination strategies, solving the problem that existing technologies do not have dedicated strategies for the governance of hybrid architectures. At the same time, relying on the predefined policy library for rapid matching reduces the time cost of temporary strategy design.

[0095] In a preferred embodiment of the present invention, step 4 above includes:

[0096] Step 41: Based on the suppression channel and communication architecture type, when the communication architecture type is centralized control C2 communication, a blocking scheme for the control server is matched from the predefined policy library to obtain the first type of blocking policy set. Specifically, this includes: basic parameter collection, which involves obtaining key parameters of the C2 architecture from the earlier communication feature extraction and attack surface identification stages, including: confirming the transport layer protocol used by the target C2 architecture (TCP / UDP) based on the protocol connection establishment characteristics analysis results in Step 31; recording the control server's IP address, listening port number, and the port's multi-connection capability, such as TC. The maximum concurrent connections for port P and the upper limit for UDP packet processing are taken from the port scan results in step 4; the effective suppression channels determined in step 33 are identified, such as control server connection interruption, port resource blockage, and protocol awareness resource exhaustion; abnormal parameters, such as invalid IPs and closed ports, are excluded to ensure that the collected parameters are consistent with the current C2 communication status; for example, the communication data between C2 and zombie nodes is captured in real time within 30 seconds using a packet capture tool to verify whether the server IP / port is still the core node of the current interaction. If an IP has no instructions sent or received within 30 seconds, it is determined to be an invalid parameter and is removed.

[0097] The predefined policy library contains entries for the C2 architecture, including communication protocol type, suppression channel type, policy name, applicable port attribute, and core trigger condition fields. Example entries are as follows:

[0098] Communication protocol type Inhibition channel type Strategy Name Applicable port attributes Core triggering conditions TCP Control server connection interruption TCPRST injection The TCP port supports a three-way handshake and has active sessions. There is an established TCP session between C2 and the Bot. UDP Port resource blocking UDP port resource consumption strategy UDP port packet processing capacity ≤1000PPS The target port receives ≥500 PPS of UDP packets within 5 minutes. TCP / UDP Protocol-aware resource exhaustion High-overhead request flooding strategy Server CPU utilization ≥ 60% The C2 protocol contains computationally expensive instructions (such as key exchange).

[0099] The multi-dimensional filtering process involves three steps. The first step is filtering by communication protocol type. For example, if the target protocol is TCP, only entries with "Communication Protocol Type = TCP" are retained. The second step is filtering by suppression channel type. For example, if step 33 determines that the suppression channel is a control server connection interruption, then entries with "Suppression Channel Type = Control Server Connection Interruption" are retained. The third step is filtering by applicable port attributes. For example, if the maximum concurrent connection count of the target TCP port is 500, then entries with a maximum concurrent connection count of ≤1000 for the applicable port attributes are retained to ensure that the policy is adapted to the port's carrying capacity.

[0100] The scoring criteria are based on three dimensions: blocking efficiency, resource consumption, and impact on normal communication, with a maximum score of 10 points: Blocking efficiency (4 points): For example, TCPRST injection can interrupt the session within 1 second, earning 4 points; port resource consumption requires 5 minutes to exhaust the connection, earning 2 points; Resource consumption (3 points): For example, RST injection can be implemented by a single node, earning 3 points; flooding requires more than 10 distributed nodes, earning 1 point; Impact on normal communication (3 points): For example, only interrupting a specific C2 session without affecting other legitimate connections, earning 3 points; possibly occupying a small amount of public bandwidth, earning 2 points.

[0101] Scoring and ranking are done by scoring each candidate strategy after initial screening and ranking them from highest to lowest total score. For example, the scoring results of a candidate strategy for a TCP-type C2 are TCPRST injection (9 points) > port resource blocking (7 points) > resource exhaustion (6 points). The top 3 strategies with the highest total scores are selected to form the first type of blocking strategy set. If the total score of a strategy is ≤1 point lower than the previous one, such as 9 points and 8 points, both strategies are included in the set to ensure that the strategies in the set have high adaptability and substitutability.

[0102] Step 42: Based on the judgment results obtained from policy matching for centralized control architecture, when the communication architecture type is not centralized control C2 communication type, combined with the determined network topology and suppression channels, a blocking scheme for point-to-point P2P communication type is matched from the predefined policy library to obtain a second type of blocking policy set. Specifically, this includes: obtaining key parameters from the network topology judgment stage and protocol behavior analysis stage, including: the network topology type is to confirm the specific topology of the P2P architecture, structured / DHT type, unstructured, based on the node interaction matrix and connection density analysis results in step 32; the node interaction characteristics are to count the number of neighbors of P2P nodes and the routing table update frequency, where the number of neighbors of P2P nodes is the average number of neighbor nodes connected to each node, and the routing table update frequency is the interval between nodes initiating find_node requests; and clarifying the effective suppression channels determined in step 33, such as neighbor node route pollution and protocol-aware resource exhaustion.

[0103] The accuracy of parameters is verified by actively probing. For example, for a structured P2P network, a find_node request is sent to 10 random nodes, the k-bucket structure in the response is parsed, and the number of node neighbors and the routing table update frequency are verified to be consistent with the previous collection results. If the error exceeds 20%, the data is collected again.

[0104] The policy library entries for P2P architecture include fields such as topology type, node interaction characteristics, suppression channel type, policy name, and implementation conditions. Example entries are shown below:

[0105] Topology Node interaction features Inhibition channel type Strategy Name Implementation conditions Structured DHT Number of neighbors ≤ 20, routing table updated once every 10 minutes Neighbor node routing pollution False Neighbor Attack Strategy The target node has ≥3 free k-bucket slots. unstructured ≥30 neighbors, routing table updated every 5 minutes Protocol-aware resource exhaustion High-frequency query flooding strategy Node query request processing response latency < 300ms

[0106] The hierarchical filtering logic is as follows: The first layer is filtering by topology type. For example, if the target is a structured DHT topology, only entries with the topology type = structured DHT are retained. The second layer is filtering by node interaction characteristics. For example, if the target node has 15 neighbors, entries with the node interaction characteristic minus the number of neighbors are retained. The third layer is filtering by suppression channel type. For example, if the suppression channel is neighbor node route pollution, entries with the corresponding channel are retained to ensure that the policy matches the core vulnerability of P2P.

[0107] For each of the selected candidate strategies, their implementation conditions are verified one by one. For example, the fake neighbor attack strategy requires that the target node has ≥3 free slots in its k-bucket. This is done by sending a PING request to the target node and counting the number of unresponsive nodes in its k-bucket, i.e., the free slots. If the number is ≥3, the verification is successful. The high-frequency query flooding strategy requires that the node response latency be <300ms. This is done by periodically sending 10 standard query requests and calculating the average response time. If the response time is <300ms, the verification is successful.

[0108] All strategies that pass the implementation condition verification are included in the second type of blocking strategy set. If only one strategy passes the verification, alternative strategies with an implementation condition deviation of ≤10% are selected. For example, if there are 2 available slots, a deviation of 20% will not be included, while a deviation of 5% will be included, ensuring that the strategies in the set are executable and redundant.

[0109] Step 43: Based on the first and second sets of blocking strategies, when the communication architecture is hybrid, select and execute a corresponding combined blocking scheme from the predefined strategy library according to the different characteristics of C2-dominated or P2P-dominated architectures. Specifically, this includes extracting two types of core feature parameters from the communication architecture determination in Step 31 and the topology determination in Step 32: C2-dominated features, including the percentage of single IP receiving instructions, the percentage of fixed server connections, and the percentage of C2 instruction transmission, where the C2 instruction transmission percentage is the number of C2 instructions issued / the total number of instructions; and P2P-dominated features, including node interaction dispersion and P2P instruction transmission percentage, where the node interaction dispersion is the percentage of single node initiating instructions ≤ 20%, and the P2P instruction transmission percentage is the number of P2P node interaction instructions / the total number of instructions.

[0110] Calculate C2 dominance: (Percentage of single IP receiving commands + Percentage of fixed server connections + Percentage of C2 command transmissions) / 3, round the result to the nearest integer; calculate P2P dominance: (Node interaction dispersion compliance rate + Percentage of P2P command transmissions) / 2, 100 points for meeting the node interaction dispersion standard, 0 points for not meeting the standard, round the result to the nearest integer; if C2 dominance ≥ 60, it is determined to be C2 dominant; if P2P dominance ≥ 60, it is determined to be P2P dominant; if both are 50-59, after core control path verification, if the botnet command transmission interruption rate is ≥ 80% after disconnecting C2 connections, it is determined to be C2 dominant; if the interruption rate is ≥ 80% after disconnecting P2P neighbor connections, it is determined to be P2P dominant.

[0111] The C2-dominant combined strategy is constructed by selecting the strategy with the highest blocking efficiency score from the first set of blocking strategies (C2-specific strategies) as the primary strategy, such as TCPRST injection, which is responsible for cutting off core C2 connections; and selecting the strategy with the lowest resource consumption score from the second set of blocking strategies (P2P-specific strategies) as the secondary strategy, such as lightweight P2P resource exhaustion, which is responsible for interfering with P2P auxiliary links. The primary strategy has higher execution priority than the secondary strategy. The primary strategy covers the core control channel, such as C2 server IP / port, while the secondary strategy covers the P2P auxiliary channel, such as P2P neighbor node interaction ports.

[0112] The P2P-dominant combined strategy is constructed by selecting the strategy with the highest blocking efficiency score from the second-category blocking strategy set as the primary strategy, such as the pseudo-neighbor attack in structured P2P, which is responsible for disrupting the core P2P routing; and selecting the strategy with the highest impact score on normal communication from the first-category blocking strategy set as the auxiliary strategy, such as low-intensity blocking of C2 ports, which is responsible for suppressing backup C2 servers. The primary strategy prioritizes key nodes in the P2P topology, such as high-frequency interaction nodes in the DHT network, while the auxiliary strategy targets non-core ports of the backup C2 server to avoid affecting other legitimate services.

[0113] The resource allocation for primary / secondary strategies is determined based on dominance: For C2-dominant strategies, the primary strategy allocates 60%-70% of computing / bandwidth resources (e.g., 60% of nodes are used for RST injection), while the secondary strategy allocates 30%-40% of resources. For P2P-dominant strategies, the primary strategy allocates 70%-80% of resources (e.g., 70% of nodes are used for pseudo-neighbor deployment), while the secondary strategy allocates 20%-30% of resources. Pre-execution testing is conducted, such as using 10% of resources to execute the primary strategy and monitoring the C2 connection interruption rate; using 5% of resources to execute the secondary strategy and monitoring the P2P interference rate. If the primary strategy interruption rate is <70%, the primary strategy resources are increased by 10%, and vice versa.

[0114] C2-dominant schemes first execute the primary strategy, interrupting C2 connections, and then execute the secondary strategy after 1 minute, interfering with P2P links. P2P-dominant schemes first execute the primary strategy, polluting P2P routes, and then execute the secondary strategy after 2 minutes, blocking backup C2 connections. After execution, core indicators are monitored: for C2-dominant schemes, the C2 connection interruption rate is ≥90% and the P2P secondary link interference rate is ≥70%; for P2P-dominant schemes, the P2P command transmission interruption rate is ≥85% and the backup C2 connection rejection rate is ≥80%. If the indicators meet the standards, the final combined blocking scheme is determined; if the standards are not met, return to step 2 to readjust the primary / secondary strategies.

[0115] In this embodiment of the invention, the core weakness of a centralized control C2 communication botnet lies in its dependence on a fixed control server. By directly matching the blocking scheme against the control server through the suppression channel, its core communication links can be precisely located, avoiding the consumption of resources on non-critical nodes, improving blocking efficiency, and solving the problem of the lack of focus in the governance of the C2 architecture in existing generalized defenses. P2P communication botnets have no fixed control terminal and their node interactions are dynamically distributed. By combining the determined network topology with the suppression channel matching scheme, the core interaction logic of the P2P network can be targeted, such as structured P2P networks. The 2P DHT routing table is polluted, and resources are exhausted on mesh topology nodes to avoid the limitations of existing single strategies that cannot cover the differences in P2P topology. The hybrid botnet combines C2 and P2P characteristics, and a single architecture strategy cannot fully cover it. By distinguishing between C2-dominant and P2P-dominant types, a combination of main and auxiliary strategies can be selected. For example, for C2-dominant types, control server interruption is prioritized, supplemented by P2P node resource blocking. For P2P-dominant types, route pollution is prioritized, supplemented by C2 backup server blocking. This can achieve full coverage of the core control path and auxiliary communication path of the hybrid architecture.

[0116] In a preferred embodiment of the present invention, step 5 above includes:

[0117] Step 51: Based on the first or second type of blocking strategy set, generate a strategy scheduling instruction according to the real-time status of the target network, and initiate the corresponding blocking measure execution process according to the strategy scheduling instruction. Specifically, this includes: determining the real-time status parameters to be collected based on the applicable scenarios of the first or second type of blocking strategy set: if it is a C2 communication type, collect the current number of connections of the control server, the bandwidth utilization rate of C2 and Bot node communication, and the online rate of Bot nodes; if it is a P2P communication type, collect the online density of P2P core nodes, the success rate of P2P query request response, and the P2P network bandwidth load.

[0118] C2 type collects data once every 1 minute for 5 consecutive times; P2P type collects data once every 2 minutes for 3 consecutive times to ensure data coverage of state fluctuations within a short period of time. If the parameter value of a certain collection deviates from the value of other collections by more than ±20%, such as the number of C2 connections being 1000 once and 500-600 in the other 4 times, it is judged as an outlier and removed, and the average value of the remaining data is used as the final real-time state parameter.

[0119] Based on a predefined state parameter-policy priority mapping table, as shown in the table below, policies within the policy set are prioritized:

[0120] Target network type Real-time status parameters Parameter threshold Corresponding strategy Strategy Priority C2 Communication Type Control server connection count >80% of maximum capacity Port resource blocking 1 (highest) C2 Communication Type Communication bandwidth utilization ＞70% TCPRST injection 2 P2P communication type Online density of core nodes ＞60% False Neighbor Attack 1 P2P communication type Query request response success rate ＞85% Protocol-aware resource exhaustion 2

[0121] If multiple parameters trigger different strategies simultaneously, the strategy with the highest priority is selected as the primary strategy, and the strategy with the second highest priority is selected as the backup strategy. For example, if the number of C2 connections exceeds the threshold and the bandwidth utilization exceeds the threshold, the primary strategy is port resource blocking, and the backup strategy is TCPRST injection.

[0122] The scheduling instruction content is constructed by including the main execution strategy name, execution node range, initial execution duration, and execution triggering condition. The execution node range specifies 3 distributed nodes for C2 type and 5 nodes covering East China and North China for P2P type. The initial execution duration is 30 minutes for C2 type and 60 minutes for P2P type. The execution triggering condition is that the parameter threshold is continuously satisfied for ≥5 minutes before starting.

[0123] Select one non-core execution node, such as a backup node for C2 type and an edge area node for P2P type. Execute the main strategy at 10% intensity according to the scheduling instructions. For example, if port resources are blocked, only 10% of concurrent connections will be initiated for 5 minutes. Test and verify the indicators: whether the target communication is successfully interrupted (e.g., the Bot node connection success rate drops by ≥30% after the C2 type test) and whether it interferes with normal network services (e.g., the normal user TCP connection failure rate is ≤1%). If the test passes, proceed to full execution. If the test fails, such as interfering with normal services, adjust the strategy parameters and retest until the requirements are met.

[0124] Send scheduling instructions to all designated execution nodes, record the instruction reception time and execution start time, and ensure that all nodes start execution within 1 minute after the instruction is issued; within the first 10 minutes after startup, check the node execution status every 2 minutes to see if the blocking request is sent normally. If a node execution is abnormal and no blocking request is sent, immediately switch to the backup node.

[0125] Step 52: Based on the initiated blocking measure execution process, network feedback data generated during the blocking measure execution is collected in real time through monitoring points deployed in the network; based on the connection success rate and response latency indicators in the network feedback data, the packet sending rate and concurrent connection number of the blocking request are dynamically adjusted to generate updated blocking strength parameters. Specifically, this includes: determining the monitoring point location according to the target network type: for C2 communication type, one monitoring point is deployed at the exit of the C2 server access router and the entry point of the network segment where the Bot node is located; for P2P communication type, one monitoring point is deployed at the critical link of P2P core node interaction (such as the DHT protocol routing interaction link) and the edge node access link.

[0126] Data is collected every 10 seconds, with 100 valid samples collected each time, such as 100 C2 connection requests and 100 P2P query requests. For C2 requests, the number of initiated connection requests (total requests N) and the number of successfully established connections (successful connections S) are counted, and the success rate is calculated as (S / N) × 100%, with the average value taken after three consecutive calculations. For P2P requests, the number of query requests and the number of requests that received valid responses are counted, and the response success rate is calculated (same logic as C2). For C2 requests, the time from sending a connection request to receiving the first packet (round-trip time) is recorded, and the average value of the remaining 98 values ​​is taken after removing the maximum and minimum values. For P2P requests, the time from sending a query request to receiving a response is recorded, and the average value is taken after removing extreme values, which is used as the current response latency.

[0127] Based on predefined feedback metrics and intensity adjustment relationships, the adjustment logic is clearly defined: If the connection success rate or response success rate is >30%, the blocking effect is insufficient: increase the number of concurrent connections or query request QPS by 20%, while keeping the packet sending rate unchanged; If the connection success rate or response success rate is <10% and the response latency is >1000ms, the blocking intensity is too high and may affect normal service: reduce the packet sending rate by 15%, while keeping the number of concurrent connections or QPS unchanged; If the connection success rate is between 10% and 30% and the response latency is between 500 and 1000ms, the blocking effect meets the standard and there is no excessive interference, so the current blocking intensity parameters remain unchanged.

[0128] After adjustment, data is continuously collected for 5 minutes. If the feedback indicator is stable within the acceptable range within 5 minutes, with a success rate of 10%-30% and a delay of 500-1000ms, then it is determined to be the updated blocking strength parameter. If it still exceeds the range, the adjustment process is repeated, with the adjustment range halved each time, such as adjusting by 20% the first time and 10% the second time, until the indicator meets the standard.

[0129] The updated blocking strength parameters, such as packet sending rate of 100 packets / second and concurrent connection count of 500, are recorded in the policy execution log and simultaneously synchronized to all nodes that performed the blocking operation through an encrypted channel. Within one minute after synchronization, a parameter verification request is sent to each node, requiring the node to return the currently executed parameter value. If the parameter of a node deviates from the updated value by more than 5%, resynchronization is performed to ensure that the parameters of all nodes are consistent.

[0130] Step 53: Based on the updated blocking strength parameters, coordinate the blocking nodes distributed across multiple network areas to initiate linked operations using time synchronization, forming a distributed collaborative blocking against the target node. Specifically, this includes: determining the core network areas to be covered based on the node distribution of the target botnet, such as C2 servers covering East and South China, and P2P nodes distributed in North and Northwest China; selecting 2-3 blocking nodes for each area, with each node having an independent IP address and stable bandwidth ≥100Mbps; conducting three tests on candidate nodes: connectivity test, which involves sending 100 test packets to the target node, such as the C2 server or P2P core node, with a packet loss rate ≤5% to determine connectivity; bandwidth test, which uses the iperf tool to test the node's uplink bandwidth for 1 minute, with an average bandwidth ≥80Mbps to determine compliance; and protocol compatibility test, which verifies whether the node can normally generate blocking packets for the target protocol, such as TCPRST packets or P2P query packets, with a generation success rate ≥95% to determine compatibility; and selecting nodes that pass all tests to form a distributed blocking node cluster.

[0131] All blocking nodes connect to a unified time server via NTP (Network Time Protocol) and calibrate their time every 30 seconds to ensure that the time error of each node is ≤10ms. After calibration, the control node sends a timestamp request to all blocking nodes, and each node returns its current timestamp. The maximum time difference is calculated, and if the difference is >10ms, recalibration is performed until the error meets the standard. The instruction includes the linkage initiation time (e.g., T=2024-05-2014:30:00.000), blocking strength parameters (e.g., packet sending rate 100 packets / second, concurrent connection number 500), and linkage duration (e.g., 60 minutes). Five minutes before the linkage initiation time, the instruction is encrypted and sent to all nodes. After receiving it, the nodes return confirmation information to ensure 100% successful reception by the nodes.

[0132] All nodes simultaneously initiate blocking operations at the designated linkage initiation time (time T), executing the updated blocking strength parameters. After linkage initiation, blocking operation execution data is collected from each node every minute, such as the number of blocking packets sent and the number of successfully interrupted connections. If the number of blocking packets of a certain node deviates from the average level by more than 15%, such as sending only 800 packets out of an average of 1000 packets, the node is deemed to be performing abnormally, and the control node immediately sends a parameter reset command to it, requiring re-execution. After 30 minutes of linkage execution, the blocking coverage rate of the target nodes across the entire region is statistically analyzed through monitoring points: the number of blocked target nodes / the total number of target nodes. If the coverage rate is ≥80%, the distributed collaborative blocking is deemed effective. If it is <80%, the number of nodes in the uncovered areas is increased, such as increasing the number of nodes in the North China region from 2 to 3, and the linkage is re-initiated.

[0133] Step 54: Based on the distributed collaborative blocking execution results, the effectiveness of the blocking operation is evaluated by comparing botnet activity indicators before and after the implementation of the blocking measures. The evaluation results are then fed back to the policy scheduling module for subsequent optimization and adjustment of the blocking strategy. Specifically, this includes determining the activity indicators to be compared according to the target network type: C2 communication type: total number of C2 server commands issued (unit: commands), proportion of bot nodes successfully receiving commands (number of bots that successfully received commands / number of online bots), C2 and bot node communication traffic (unit: GB); P2P communication type: frequency of P2P core node interactions (unit: times / hour), P2P network control command propagation range (number of nodes receiving commands / total number of P2P nodes), P2P node data synchronization success rate (number of nodes that successfully synchronized data / number of nodes that initiated synchronization).

[0134] Data on indicators were collected for the 24 hours prior to the implementation of blocking measures, and statistical analysis was performed every 2 hours. The 24-hour average was used as the baseline value before the blocking measures were implemented. Data on indicators were also collected during the implementation of blocking measures and for the 24 hours following implementation, and statistical analysis was performed every 2 hours. The 24-hour average was used as the actual value after the blocking measures were implemented. If any abnormalities occurred during the data collection period, such as network interruption or temporary offline of target nodes, or if the C2 server was offline for 1 hour, the data for that period was removed, and the data collection time was extended until 24 hours of valid data were collected.

[0135] For each activity indicator, the indicator reduction is calculated as follows: (Pre-block baseline value - Post-block actual value) / Pre-block baseline value × 100%. The effectiveness level is determined based on the reduction: Effective is when the core indicator, such as the total number of C2 commands issued or the frequency of P2P interactions, has a reduction of ≥80%, and other indicators have a reduction of ≥60%; Partially effective is when the core indicator has a reduction of 50%-79%, and other indicators have a reduction of 40%-59%; Ineffective is when the core indicator has a reduction of <50%, or other indicators have a reduction of <40%. If all indicators reach the effective level, the blocking operation is considered effective overall; if the core indicator is partially effective and other indicators are effective, the operation is considered partially effective overall; if any core indicator is ineffective, the operation is considered ineffective overall.

[0136] The evaluation results were compiled into an optimization recommendation report, including: effective strategies and parameters, such as TCPRST injection reducing C2 commands by 85%, and it is recommended to retain this parameter; strategies that need optimization, such as port resource blocking only reducing the number of connections by 45%, and it is recommended to increase the number of concurrent connections from 500 to 800; and ineffective strategies and reasons, such as the P2P resource exhaustion strategy being ineffective because it did not cover nodes in the Northwest region, and it is recommended to add 3 blocking nodes in that region.

[0137] The report is sent to the policy scheduling module, which updates the predefined policy library based on the suggestions, such as adjusting the concurrent threshold for port blocking. At the same time, the optimized parameters are applied in the next blocking operation, forming a closed loop of evaluation, feedback and optimization.

[0138] In this embodiment of the invention, the real-time status of the target network is used as the scheduling basis, avoiding the use of fixed blocking procedures. This ensures that the blocking measures can match the current network attack and defense situation, solving the problem of insufficient effectiveness or resource waste of traditional fixed procedures when the network status changes. The policy scheduling instructions explicitly initiate execution processes that match the target policy set, avoiding the accidental activation of P2P-specific routing pollution policies. Simultaneously, it ensures that the legality verification of the target node is completed before the process starts, reducing false interference to normal network services. The blocking strength is adjusted in real time using two core indicators: connection success rate and response latency, automatically reducing the packet sending rate. If the connection success rate rises back to 30%, the number of concurrent connections is increased. For scenarios such as dispersed P2P nodes and multi-mirror deployment of C2 servers, single-point blocking is difficult to cover all target nodes; through multi-network... Network area blocking node linkage can achieve full coverage of distributed targets, while initiating route pollution on core nodes of the P2P mesh topology, solving the problems of narrow coverage and easy bypass of single-point blocking. The effectiveness is quantitatively evaluated by comparing botnet activity indicators before and after blocking. If the evaluation result is that the effect is not up to standard, the problem is fed back to the policy scheduling module, forming a continuous iterative optimization loop. This approach solves the problem of policy solidification caused by traditional blocking that only executes without evaluation, making subsequent governance methods more suitable for the characteristics of the target botnet. The evaluation results can distinguish the actual effectiveness of different blocking measures. For example, in C2-type governance, TCPRST injection reduces activity indicators by up to 80% and port resource congestion by up to 60%. In the future, more resources can be allocated to efficient measures, reducing the resource investment of inefficient measures.

[0139] like Figure 2 As shown, embodiments of the present invention also provide a botnet classification and suppression system for different communication architectures, comprising:

[0140] The extraction module is used to extract communication parameters between zombie nodes and the control terminal from network traffic through traffic mirroring and protocol decoding. The communication parameters include protocol type, port number and data characteristics.

[0141] The analysis module is used to perform pattern analysis based on communication parameters to identify control commands, heartbeat mechanisms, and data synchronization characteristics.

[0142] The suppression channel module is used to determine the implementable suppression channels based on control commands, heartbeat mechanisms, and data synchronization characteristics, combined with the characteristics of the protocol to which they belong and the network structure.

[0143] The matching module is used to match corresponding blocking schemes based on the suppressed channels; the blocking schemes are selected according to the communication architecture type of the botnet, which includes centralized control C2 communication type, peer-to-peer P2P communication type and hybrid type;

[0144] The feedback module is used to implement blocking measures that match the blocking scheme through strategy scheduling, adjust the suppression and blocking intensity based on network feedback, coordinate multi-point linkage operations, and evaluate the blocking effect.

[0145] It should be noted that this system is a system corresponding to the above method. All implementation methods in the above method embodiments are applicable to this embodiment and can achieve the same technical effect.

[0146] Embodiments of the present invention also provide a computing device, including: a processor and a memory storing a computer program, wherein the computer program, when executed by the processor, performs the method described above. All implementations in the above method embodiments are applicable to this embodiment and can achieve the same technical effects.

[0147] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A botnet classification-based suppression and blocking method for different communication architectures, characterized in that, The method includes: Step 1: Extract the communication parameters between the zombie node and the control terminal from the network traffic through traffic mirroring and protocol decoding. The communication parameters include protocol type, port number and data characteristics. Step 2: Based on the communication parameters, perform pattern analysis to identify control commands, heartbeat mechanisms, and data synchronization characteristics; Step 3: Based on the control commands, heartbeat mechanism, and data synchronization characteristics, combined with the characteristics of their respective protocols and network structure, determine the feasible suppression channels, including: based on the interaction mode and communication protocol type of the control commands, analyze the inherent characteristics of the communication protocol in the connection establishment and command transmission process, and determine whether its communication architecture type belongs to centralized control or point-to-point; based on the target address distribution characteristics of the heartbeat mechanism and the topological relationship between nodes reflected by the data synchronization characteristics, construct the connection structure model of the botnet, and determine whether its network topology belongs to star, hierarchical, or mesh topology; combining the communication architecture type and network topology, map and match a predefined suppression strategy library to determine the most effective suppression channel for the target botnet. The suppression channels include control server connection interruption for centralized architecture, neighbor node routing pollution for point-to-point architecture, or specific protocol resource exhaustion for hybrid architecture. Step 4: Based on the suppression channel, match the corresponding blocking scheme; the blocking scheme is selected according to the communication architecture type of the botnet, which includes centralized control C2 communication type, peer-to-peer P2P communication type and hybrid type; Step 5: Implement blocking measures that match the blocking plan through strategy scheduling, adjust the intensity of suppression and blocking based on network feedback, coordinate multi-point linkage operations, and evaluate the blocking effect.

2. The botnet classification and suppression method for different communication architectures according to claim 1, characterized in that, Step 1 includes: By deploying traffic mirroring devices at key network nodes, raw network packets can be captured to obtain a complete copy of network traffic; Based on the original data packet, a protocol decoder is used to parse the original data packet and identify the communication protocol type used by the original data packet; Based on the communication protocol type, the specific header structure of the protocol is parsed, and the source port number and destination port number are extracted from the protocol header fields to obtain the port information; Based on port information and communication protocol type, the payload content of data packets is further analyzed to extract data features including specific instruction formats, encryption characteristics, and communication frequency.

3. The botnet classification and suppression method for different communication architectures according to claim 2, characterized in that, Step 2 includes: Based on the data characteristics of communication parameters, the specific instruction format is compared with the known botnet instruction patterns in the predefined rule base to identify control instructions; By using control commands and communication frequency data, and by statistically analyzing the distribution pattern of time intervals between adjacent control commands, a heartbeat mechanism that conforms to a periodic pattern can be identified. Based on the time period of the heartbeat mechanism, the change pattern of the data packet payload content within that time period is analyzed. When multiple nodes are detected to be synchronously updating their content within a specific heartbeat cycle, the data synchronization characteristics are identified.

4. The botnet classification and suppression method for different communication architectures according to claim 3, characterized in that, Step 4 includes: Based on the suppression channel and communication architecture type, when the communication architecture type is centralized control C2 communication type, a blocking scheme for the control server is matched from the predefined policy library to obtain the first type of blocking policy set; Based on the judgment results obtained from policy matching for centralized control architecture, when the communication architecture type is not centralized control C2 communication type, combined with the determined network topology and suppression channel, the blocking scheme for point-to-point P2P communication type is matched from the predefined policy library to obtain the second type of blocking policy set. Based on the first and second sets of blocking strategies, when the communication architecture is hybrid, the appropriate combined blocking scheme is selected from the predefined strategy library and executed according to the different characteristics of C2-dominated or P2P-dominated architectures in the hybrid architecture.

5. The botnet classification and suppression method for different communication architectures according to claim 4, characterized in that, Step 5 includes: Based on the first or second set of blocking strategies, a strategy scheduling instruction is generated according to the real-time status of the target network, and the corresponding blocking measures execution process is initiated according to the strategy scheduling instruction. Based on the initiated blocking measure execution process, network feedback data generated during the blocking measure execution process is collected in real time through monitoring points deployed in the network; based on the connection success rate and response latency indicators in the network feedback data, the packet sending rate and concurrent connection number of the blocking request are dynamically adjusted to generate updated blocking strength parameters. Based on the updated blocking strength parameters, blocking nodes distributed across multiple network regions are coordinated to initiate linked operations using a time synchronization method, forming a distributed and collaborative blocking mechanism targeting the target node. Based on the results of distributed collaborative blocking, the effectiveness of the blocking operation is evaluated by comparing botnet activity indicators before and after the blocking measures are implemented. The evaluation results are then fed back to the policy scheduling module for subsequent optimization and adjustment of the blocking strategy.

6. A botnet classification and suppression system for different communication architectures, the system implementing the method as described in any one of claims 1 to 5, characterized in that, include: The extraction module is used to extract communication parameters between zombie nodes and the control terminal from network traffic through traffic mirroring and protocol decoding. The communication parameters include protocol type, port number and data characteristics. The analysis module is used to perform pattern analysis based on communication parameters to identify control commands, heartbeat mechanisms, and data synchronization characteristics. The suppression channel module is used to determine the implementable suppression channels based on control commands, heartbeat mechanisms, and data synchronization characteristics, combined with the characteristics of the protocol to which they belong and the network structure. The matching module is used to match corresponding blocking schemes based on the suppressed channels; the blocking schemes are selected according to the communication architecture type of the botnet, which includes centralized control C2 communication type, peer-to-peer P2P communication type and hybrid type; The feedback module is used to implement blocking measures that match the blocking scheme through strategy scheduling, adjust the suppression and blocking intensity based on network feedback, coordinate multi-point linkage operations, and evaluate the blocking effect.

7. A computing device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program that, when executed by a processor, implements the method as described in any one of claims 1 to 5.

Images