Firewall detection method and device, medium and product

By collecting cluster node traffic information to generate a node relationship table and draw a topology diagram, the problem of cumbersome firewall configuration and real-time monitoring is solved, achieving efficient and accurate firewall detection and status monitoring, and reducing manual intervention and errors.

CN121770852APending Publication Date: 2026-03-31INDUSTRIAL AND COMMERCIAL BANK OF CHINA
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-12-29
Publication Date
2026-03-31

AI Technical Summary

Technical Problem

During cluster migration or expansion, the configuration and activation verification of firewalls are cumbersome and error-prone, leading to network security risks. Existing detection methods cannot monitor firewall status changes in real time, which can easily cause business communication interruptions.

Method used

By collecting cluster node traffic information, generating node relationship tables and drawing topology diagrams, timed firewall detection can be achieved, reducing manual intervention and improving detection efficiency and accuracy.

Benefits of technology

Reduce labor costs, ensure the comprehensiveness and accuracy of traffic information collection, provide reliable data sources, intuitively present node relationships, and improve the startup efficiency and operation and maintenance efficiency of firewall detection.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121770852A_ABST
    Figure CN121770852A_ABST
Patent Text Reader

Abstract

The invention discloses a firewall detection method, firewall detection equipment, a medium and a product, which are applied to the field of financial science and technology. Comprising the steps of collecting node flow information of a to-be-migrated cluster; generating a node relation table according to the node flow information, and displaying the node relation table to the user to obtain an updated node relation table fed back by the user; and deploying the updated node relation table to a new cluster, generating a detection instruction based on the updated node relation table, and performing firewall detection of the new cluster based on the detection instruction. By collecting the node traffic information, the manpower cost is reduced, and the comprehensiveness and accuracy of traffic information collection are ensured at the same time. By generating the node relationship table, the node association relationship is intuitively presented, so that a user can quickly and clearly determine the firewall configuration needing to be migrated. Detection targets do not need to be manually determined one by one, firewall objects needing to be detected in a new cluster can be automatically positioned, instructions can be accurately issued, firewall detection starting efficiency is improved, and orderly development of detection tasks is ensured.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of financial technology, and in particular to a firewall detection method, device, medium, and product. Background Technology

[0002] In the digital operations of large enterprises, cluster migration or expansion is a common maintenance scenario. As the core architecture carrying business, the firewall configuration of the cluster directly affects the data transmission security and communication stability. Therefore, during migration or expansion, the review and verification of firewall access is a key step to ensure seamless business continuity and avoid network interruptions, and it must be carried out in sync with the cluster migration progress.

[0003] Currently, there are two main solutions in the industry for this scenario: when the cluster environment is compatible, the firewall is migrated and copied to replicate the original configuration; when the environment is too different to migrate, a combination of manual and tool-based methods is used, where operations and maintenance personnel first compile a list of firewalls to be enabled, and after configuration, they manually enter the address and port to detect the enabling status using basic network tools.

[0004] Large clusters often involve numerous nodes and complex communication links, with hundreds or even thousands of firewalls to be identified. Manual identification is highly susceptible to errors due to information omissions and parameter confusion, creating potential security vulnerabilities for future network security. During the verification phase, operations personnel must manually input the node address and port for each firewall, a tedious and repetitive process that consumes significant time and manpower and is prone to inaccurate results due to human error. Furthermore, existing detection methods only capture the firewall's operational status at the moment of detection, failing to monitor subsequent dynamic changes in firewall status. If a firewall closes a port due to a fault or configuration change during the new cluster's operation, it is difficult to detect and address in a timely manner, potentially causing business communication interruptions. Summary of the Invention

[0005] This invention provides a firewall detection method, device, medium, and product. By collecting cluster node traffic information, generating a node relationship table, and performing timed firewall detection and topology drawing, it solves the technical problems of cumbersome firewall detection operations, easy omissions, inability to perceive firewall status in real time, and lack of intuitive topology diagrams in existing cluster migration.

[0006] According to one aspect of the present invention, a firewall detection method is provided, the method comprising:

[0007] Collect node traffic information of the cluster to be migrated;

[0008] A node relationship table is generated based on node traffic information, and the node relationship table is displayed to the user to obtain user feedback for an updated node relationship table.

[0009] Deploy the updated node relationship table to the new cluster, generate probe commands based on the updated node relationship table, and perform firewall probes on the new cluster based on the probe commands.

[0010] Optionally, collecting node traffic information of the clusters to be migrated includes: determining each target node contained in each cluster to be migrated; and collecting node traffic information of each target node using an extended Berkeley packet filter, wherein the node traffic information includes source address, destination address, communication port, packet transmission and reception time, packet size, and traffic transmission protocol type.

[0011] The advantages of this setup are: it provides support for data collection by building an architecture, ensuring the work is implemented; it expands the Berkeley package filter to achieve accurate data collection; it provides comprehensive data for node relationship analysis through multi-dimensional information; and it automatically transmits data to reduce manual intervention, improving efficiency and accuracy.

[0012] Optionally, a node relationship table is generated based on node traffic information, including: performing integrity verification on node traffic information; when the verification passes, determining the source node corresponding to the source address and the destination node corresponding to the destination address; sorting out the traffic relationship between the source node and the destination node based on the node traffic information, wherein the traffic relationship includes rate, flow direction and packet loss rate; and generating a node relationship table based on the source node, destination node and traffic relationship, wherein the node relationship table includes node name, node address and traffic relationship.

[0013] The advantages of this setup are: integrity verification ensures data validity and avoids erroneous data interfering with node matching; sorting out multi-dimensional traffic relationships makes node interaction status clear; and generating structured tables intuitively present node information and relationships, providing an accurate data foundation for subsequent updates and exploration.

[0014] Optionally, a probe command is generated based on the updated node relationship table, including: validating the updated node relationship table; if the validation is successful, identifying the node pairs that need to be probed by the firewall based on the updated node relationship table; forming a structured list of tasks to be probed based on the node pairs; and converting the list of tasks to be probed into probe commands for the new cluster.

[0015] The advantages of this setup are: legality checks ensure that the table data is compliant, avoiding errors that could lead to deviations in the detection direction; the structured list clearly defines the detection targets, and instruction conversion and issuance replace manual communication, improving the efficiency of detection initiation.

[0016] Optionally, the method also includes: starting a timed firewall probe task based on probe commands to obtain firewall probe results, wherein the firewall probe results include whether the firewall is enabled or disabled; and dynamically generating a firewall topology map based on the firewall probe results.

[0017] The advantages of this setup are: timed detection enables continuous monitoring of the firewall status, avoiding the omission of status changes due to relying solely on instantaneous detection; the dynamic topology diagram intuitively presents the firewall status and node relationships, replacing textual information, making it easier for users to quickly grasp the overall situation and improving operational efficiency.

[0018] Optionally, a firewall topology map can be dynamically generated based on the firewall detection results, including: drawing topology map elements according to preset visualization rules based on the firewall detection results to generate a firewall topology map; and automatically updating the corresponding line colors and markers when the firewall detection results change.

[0019] The advantages of this setup are: the visual topology map intuitively presents the firewall status, reducing the user's understanding cost; and automatic updating of tags ensures that the topology map is synchronized with the latest detection results, avoiding information lag.

[0020] Optionally, the method also includes: when a new node pair appears, drawing the corresponding node icon and communication lines.

[0021] The advantage of this setup is that it supplements the drawing elements to ensure the integrity of the topology map, covers newly added probe objects, and allows users to have a comprehensive understanding of the cluster firewall status.

[0022] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0023] At least one processor;

[0024] and a memory communicatively connected to the at least one processor;

[0025] The memory stores a computer program that can be executed by the at least one processor, which enables the at least one processor to execute a firewall detection method according to any embodiment of the present invention.

[0026] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement a firewall detection method according to any embodiment of the present invention.

[0027] According to another aspect of the present invention, a computer program product is provided, the computer program product comprising a computer program that, when executed by a processor, implements a firewall detection method according to any embodiment of the present invention.

[0028] The technical solution of this invention reduces labor costs by collecting node traffic information, while ensuring the comprehensiveness and accuracy of traffic information collection, providing a reliable data source for subsequent firewall analysis. By generating a node relationship table, the relationships between nodes are presented intuitively, allowing users to quickly identify the firewall configurations that need to be migrated. Updating the table allows for precise matching of node information in the new cluster, providing suitable basic data for firewall probing of the new cluster. Without the need for manual identification of each probe target, the system can automatically locate the firewall objects to be probed in the new cluster, accurately issue commands, improve the startup efficiency of firewall probing, and ensure the orderly execution of probing tasks.

[0029] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0030] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0031] Figure 1 This is a flowchart of a firewall detection method provided in Embodiment 1 of the present invention;

[0032] Figure 2 This is a flowchart of another firewall detection method provided in Embodiment 2 of the present invention;

[0033] Figure 3 This is a schematic diagram of a firewall detection device according to Embodiment 3 of the present invention;

[0034] Figure 4 This is a schematic diagram of the structure of an electronic device that implements a firewall detection method according to an embodiment of the present invention. Detailed Implementation

[0035] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0036] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0037] Example 1

[0038] Figure 1 This is a flowchart illustrating a firewall detection method provided in Embodiment 1 of the present invention. This embodiment is applicable to network topology drawing programs. The method can be executed by a firewall detection device, which can be implemented in hardware and / or software and can be configured in a computer controller. Figure 1 As shown, the method includes:

[0039] S110. Collect node traffic information of the cluster to be migrated.

[0040] It should be noted that the network topology drawing program is developed based on extended Berkeley packet filter technology. After modification, it is a program with firewall mapping and detection capabilities, including a proxy client and a server. It can realize functions such as node traffic collection, firewall detection, and network and firewall topology drawing. The proxy client refers to the terminal execution component of the network topology drawing program, which needs to be deployed on each node of the cluster. After modification, a communication module and a firewall detection module are added, enabling it to collect node traffic information through extended Berkeley packet filter technology, receive server instructions, execute scheduled firewall detection tasks, and provide feedback on detection results. The server is the control component of the network topology drawing program, which needs to be built on the corresponding server equipment in the cluster. After modification, a communication module, a file import module, a file generation module, and a firewall topology analysis module are added, enabling it to receive data transmitted from the proxy client, generate node relationship tables, issue detection instructions to the proxy client, and draw firewall topology diagrams. The cluster to be migrated refers to the old cluster whose original firewall configuration needs to be migrated to the new cluster due to business migration or expansion requirements. It is the source of node traffic information collection and also the reference for the subsequent firewall configuration of the new cluster. Node traffic information refers to network communication data captured by the agent from the kernel level of the cluster nodes to be migrated through extended Berkeley packet filtering technology.

[0041] Optionally, collecting node traffic information of the clusters to be migrated includes: determining each target node contained in each cluster to be migrated; and collecting node traffic information of each target node using an extended Berkeley packet filter, wherein the node traffic information includes source address, destination address, communication port, packet transmission and reception time, packet size, and traffic transmission protocol type.

[0042] It is known that, firstly, the proxy of the network topology drawing program needs to be deployed on each target node that needs to be monitored in the cluster to be migrated. At the same time, the server of the network topology drawing program needs to be set up on the corresponding device of the cluster to ensure that the proxy and the server can communicate normally, laying the foundation for subsequent traffic collection and data transmission.

[0043] Specifically, the agent on the cluster to be migrated will use extended Berkeley packet filtering technology to collect node traffic information from each target node. Extended Berkeley packet filtering technology can monitor data at the node kernel level without changing or interfering with the business system code and operations. It hooks key events related to network packet transmission and reception in the node kernel, such as the process of receiving and sending network packets, and network communication operations in system calls, thereby capturing raw node network traffic data in real time. After capturing the raw data, the agent will perform preliminary processing, filtering out invalid broadcast packets, empty packets, and other useless information, and then extracting key node traffic information, specifically including source address, destination address, communication port, packet transmission and reception time, packet size, and traffic transmission protocol type. Here, the source address refers to the address of the node initiating network communication, the destination address refers to the address of the node receiving network communication, the communication port refers to the port number used for data transmission between nodes, the packet transmission and reception time refers to the specific time points when packets are sent and received, the packet size refers to the data volume of each packet, and the traffic transmission protocol type, such as Transmission Control Protocol (TCP) or User Datagram Protocol (UDP), which are used to standardize the rules for data transmission between nodes. Finally, the agent will use its newly added communication module to extract and organize the node traffic information and send it to the server of the cluster to be migrated in real time according to a preset transmission format that ensures data integrity and readability. This will provide the server with an accurate and comprehensive data source for subsequent data aggregation and analysis and generation of node relationship tables.

[0044] S120. Generate a node relationship table based on node traffic information and display the node relationship table to the user to obtain updated node relationship table based on user feedback.

[0045] The node relationship table is a table document generated by the server through a file generation module. It contains the node names of the cluster to be migrated, the Internet Protocol addresses of the nodes, and the traffic interaction relationships between the nodes. It serves as the basic data carrier for analyzing firewall configurations and determining paths to be probed. The updated node relationship table is created by the user based on the original node relationship table, replacing the Internet Protocol addresses and other information of the cluster to be migrated (i.e., the old cluster) with the corresponding information of the new cluster. It serves as the configuration basis for the new cluster to carry out firewall probe tasks.

[0046] Optionally, a node relationship table is generated based on node traffic information, including: performing integrity verification on node traffic information; when the verification passes, determining the source node corresponding to the source address and the destination node corresponding to the destination address; sorting out the traffic relationship between the source node and the destination node based on the node traffic information, wherein the traffic relationship includes rate, flow direction and packet loss rate; and generating a node relationship table based on the source node, destination node and traffic relationship, wherein the node relationship table includes node name, node address and traffic relationship.

[0047] Specifically, the servers in the cluster to be migrated will perform integrity checks on the node traffic information transmitted from the proxy to ensure the accuracy and reliability of the data foundation for subsequent table generation. Integrity checks include verifying the completeness of key fields in the traffic information, checking for null values ​​in information such as source address, destination address, communication port, and traffic transmission protocol type, and verifying that the address format conforms to Internet Protocol address specifications to avoid invalid or erroneous data affecting subsequent analysis. Once all checks pass and the data is confirmed to be valid, the server will match the source node in the cluster to be migrated with the source address in the traffic information, and then match the destination node with the receiving node, thus establishing the correspondence between addresses and actual nodes.

[0048] Furthermore, the server will analyze the traffic relationships between source and destination nodes based on the verified node traffic information. This analysis requires combining fine-grained data collected using extended Berkeley packet filtering technology. For example, it calculates the data transmission rate from the source node to the destination node per unit time based on packet transmission and reception time and packet size; it clarifies the unidirectional flow of traffic from the source node to the destination node by analyzing the direction of packet transmission and reception; and it calculates the packet loss rate during data transmission by comparing the total number of sent and received packets, ultimately forming a complete traffic relationship including rate, flow direction, and packet loss rate. Finally, the server will invoke its newly added file generation module. This module will integrate the previously determined key information of the source and destination nodes, including node names and addresses, along with the analyzed traffic relationships, according to a preset table format, to generate a node relationship table. The generated table clearly presents the identity information of each node in the cluster to be migrated and the communication status between nodes, providing intuitive and structured data for users to replace new cluster information and conduct firewall probing of the new cluster.

[0049] S130. Deploy the updated node relationship table to the new cluster, generate probe commands based on the updated node relationship table, and perform firewall probes on the new cluster based on the probe commands.

[0050] The probe command refers to the instruction generated and sent by the server of the new cluster to the agent. It contains key parameters such as the source node's Internet Protocol address (IP address), the destination node's IIP address, the probe port, the transport protocol, and the probe frequency, guiding the agent to accurately execute firewall probe tasks. Firewall probing refers to the process by which the agent periodically checks the firewall status between nodes in the new cluster based on the probe commands sent by the server. The purpose is to confirm whether the firewalls on specific communication paths between nodes are functioning correctly, providing a basis for subsequent firewall activation verification.

[0051] Specifically, a proxy client for the network topology drawing program needs to be installed on each machine in the new cluster, and a server for the program needs to be set up on the corresponding dedicated equipment in the new cluster. It should be noted that both the proxy client and the server installed in the new cluster are modified versions; that is, the proxy client has added communication and firewall detection modules, and the server has added communication and file import modules, ensuring that it has the functionality required for subsequent firewall detection. During installation and setup, it will be ensured that the proxy client is compatible with the operating system environment of the new cluster nodes, such as being compatible with commonly used operating system versions in the new cluster, and that a basic communication link is established between the server and each proxy client to prepare for subsequent command issuance and data feedback.

[0052] Simultaneously, the user-updated node relationship table is imported into the new cluster's server. This updated node relationship table is the original table generated by the user based on the server of the cluster to be migrated, with the node addresses and other information from the new cluster replaced. It includes the names and addresses of each node in the new cluster, as well as the traffic interaction relationships between nodes. During import, the new cluster server receives the table through its newly added file import module. After import, the server stores this table as the basis for subsequent analysis of node pairs to be probed and generation of probe commands, ensuring that the firewall probes of the new cluster accurately match the actual node communication needs.

[0053] Optionally, a probe command is generated based on the updated node relationship table, including: validating the updated node relationship table; if the validation is successful, identifying the node pairs that need to be probed by the firewall based on the updated node relationship table; forming a structured list of tasks to be probed based on the node pairs; and converting the list of tasks to be probed into probe commands for the new cluster.

[0054] Specifically, the server in the new cluster performs a validity check on the imported updated node relationship table to ensure the accuracy of subsequent probe tasks and avoid probe deviations due to table data issues. The validity check includes verifying whether the addresses of each node in the new cluster conform to the specifications and whether the relationships between nodes are clear. It also confirms that the table format is consistent with the server's file import module's requirements to prevent data parsing failures due to format errors. Only after all checks pass and the table data is confirmed to be valid will the server proceed to the next step. After successful verification, the server will use the updated node relationship table to identify node pairs requiring firewall probes. Specifically, the server will extract the names, addresses, and traffic interaction relationships of each node in the new cluster recorded in the table, filtering out node combinations with communication needs. For example, nodes marked "Node A communicates with Node B on a specific port" or "Node C needs to transmit data to Node D" will be used as key node pairs to verify whether the firewall is open. The server will integrate the node pairs and their corresponding communication parameters, organizing them into a probe task list according to a preset structured format. The list will clearly specify the source node, destination node, probe port, and protocol for each probe task.

[0055] Finally, the server invokes its newly added communication module to transform the structured list of tasks to be probed into a command format recognizable by the agent. This involves encoding text information in the list into data packets conforming to the communication protocol, ensuring the agent can accurately parse the command content. Subsequently, the communication module, based on the preset mapping relationship in the new cluster—that is, the agent deployment address corresponding to each node—directs the probe commands to the corresponding agent in the new cluster. This avoids command errors or redundancy, ensuring that each agent receives probe tasks related to its own node, preparing the agent for subsequent firewall probes.

[0056] The technical solution of this invention reduces labor costs by collecting node traffic information, while ensuring the comprehensiveness and accuracy of traffic information collection, providing a reliable data source for subsequent firewall analysis. By generating a node relationship table, the relationships between nodes are presented intuitively, allowing users to quickly identify the firewall configurations that need to be migrated. Updating the table allows for precise matching of node information in the new cluster, providing suitable basic data for firewall probing of the new cluster. Without the need for manual identification of each probe target, the system can automatically locate the firewall objects to be probed in the new cluster, accurately issue commands, improve the startup efficiency of firewall probing, and ensure the orderly execution of probing tasks.

[0057] Example 2

[0058] Figure 2 This is a flowchart of a firewall detection method provided in Embodiment 2 of the present invention. This embodiment adds a specific process for generating a firewall topology map based on Embodiment 1. The specific content of steps S210-S230 is largely the same as steps S110-S130 in Embodiment 1, and therefore will not be repeated in this embodiment. Figure 2 As shown, the method includes:

[0059] S210. Collect node traffic information of the cluster to be migrated.

[0060] Optionally, collecting node traffic information of the clusters to be migrated includes: determining each target node contained in each cluster to be migrated; and collecting node traffic information of each target node using an extended Berkeley packet filter, wherein the node traffic information includes source address, destination address, communication port, packet transmission and reception time, packet size, and traffic transmission protocol type.

[0061] S220. Generate a node relationship table based on node traffic information and display the node relationship table to the user to obtain updated node relationship table based on user feedback.

[0062] Optionally, a node relationship table is generated based on node traffic information, including: performing integrity verification on node traffic information; when the verification passes, determining the source node corresponding to the source address and the destination node corresponding to the destination address; sorting out the traffic relationship between the source node and the destination node based on the node traffic information, wherein the traffic relationship includes rate, flow direction and packet loss rate; and generating a node relationship table based on the source node, destination node and traffic relationship, wherein the node relationship table includes node name, node address and traffic relationship.

[0063] S230. Deploy the updated node relationship table to the new cluster and generate probe commands based on the updated node relationship table.

[0064] Optionally, a probe command is generated based on the updated node relationship table, including: validating the updated node relationship table; if the validation is successful, identifying the node pairs that need to be probed by the firewall based on the updated node relationship table; forming a structured list of tasks to be probed based on the node pairs; and converting the list of tasks to be probed into probe commands for the new cluster.

[0065] S240. Start a scheduled firewall probe task based on the probe command to obtain firewall probe results, including whether the firewall is enabled or disabled.

[0066] Specifically, after receiving the probe command from the server, the agent in the new cluster will initiate a scheduled firewall probe task based on the parameters specified in the command, such as the probe frequency, the pair of nodes to be probed, the communication port, and the transmission protocol. During the probe, the agent will simulate normal data communication between nodes, sending test data packets to the corresponding port of the specified target node. By determining whether it can successfully receive a response data packet from the target node, it determines the firewall's open status. If a response is successfully received, it means that the firewall allows data transmission along that communication path, i.e., the firewall status is open; if no response is received, it means that the firewall blocks that communication path, i.e., the firewall status is closed. After the probe is completed, the agent will feed back the firewall probe results to the server in the new cluster through its newly added communication module, ensuring that the server can obtain the probe data in real time.

[0067] S250: Dynamically generate firewall topology diagrams based on firewall detection results.

[0068] Specifically, after receiving firewall probe results from each agent, the new cluster's server first performs a preliminary verification to confirm that the node and port information in the results match the updated node relationship table, excluding invalid or abnormal probe results. Subsequently, the server calls the newly added firewall topology analysis module to extract the names, addresses, and preset communication associations of each node in the new cluster from the updated node relationship table, and then maps the firewall status in the probe results to the node associations one-to-one. Specifically, the module represents each node with an independent icon, labeled with the node name and address next to the icon; for node pairs with communication needs, lines are used to connect them. If the corresponding firewall status is open, the line is marked with a normal color, such as green; if it is not open, it is marked with an abnormal color, such as red, and a prominent mark is added next to the inactive line to clearly distinguish the firewall status of different node pairs.

[0069] Optionally, a firewall topology map can be dynamically generated based on the firewall detection results, including: drawing topology map elements according to preset visualization rules based on the firewall detection results to generate a firewall topology map; and automatically updating the corresponding line colors and markers when the firewall detection results change.

[0070] Specifically, after the new cluster's server invokes the firewall topology mapping module, it draws topology map elements according to preset visualization rules. Each node in the new cluster is represented by an independent icon, with the node name and address labeled next to the icon to ensure clear identification of the node. For node pairs that have communication needs and have completed probing, the corresponding node icons are connected by lines. The line color and markings are differentiated according to the firewall status, and the corresponding communication ports are labeled next to the lines, allowing users to intuitively understand the specific communication paths between nodes and the firewall status. Finally, these elements are integrated to generate a complete initial firewall topology map.

[0071] It should be noted that because the proxy performs periodic probing tasks, if subsequent probing results differ from historical results—for example, if the firewall changes from enabled to disabled—the server will detect this status change in real time. At this point, the firewall topology analysis module will automatically trigger an update mechanism, locating the node pair connection lines corresponding to the status change. This involves changing the original green lines to red and adding a marker, ensuring that the line colors and markers in the topology diagram are completely synchronized with the latest firewall status, preventing users from obtaining outdated information.

[0072] Optionally, the method also includes: when a new node pair appears, drawing the corresponding node icon and communication lines.

[0073] Specifically, when a new cluster has a new node that needs to be included in the detection range, or an existing node has a new communication requirement, and the agent reports the detection results of the new node pair, the firewall topology sorting module will first add the icon of the new node to the topology map, and then draw the corresponding connection lines according to the communication relationship and firewall status of the new node pair, and mark the communication port. This allows the firewall status and communication relationship of the new node to be quickly integrated into the existing topology map, ensuring that the topology map can completely cover all detection nodes and communication paths of the new cluster, and always reflect the overall situation of the cluster firewall.

[0074] The technical solution of this invention reduces labor costs by collecting node traffic information, while ensuring the comprehensiveness and accuracy of traffic information collection, providing a reliable data source for subsequent firewall analysis. By generating a node relationship table, the relationships between nodes are presented intuitively, allowing users to quickly identify the firewall configurations that need to be migrated. Updating the table allows for precise matching of node information in the new cluster, providing suitable basic data for firewall probing of the new cluster. Without the need for manual identification of each probe target, the system can automatically locate the firewall objects to be probed in the new cluster, accurately issue commands, improve the startup efficiency of firewall probing, and ensure the orderly execution of probing tasks.

[0075] Example 3

[0076] Figure 3 This is a schematic diagram of a firewall detection device provided in Embodiment 3 of the present invention. Figure 3 As shown, the device includes: a traffic information acquisition module 310, used to collect node traffic information of the cluster to be migrated;

[0077] The node relationship table generation module 320 is used to generate a node relationship table based on node traffic information and display the node relationship table to the user to obtain updated node relationship tables based on user feedback.

[0078] Firewall detection module 330 is used to deploy the updated node relationship table to the new cluster, generate detection commands based on the updated node relationship table, and perform firewall detection on the new cluster based on the detection commands.

[0079] Optionally, the traffic information collection module 310 is specifically used to: determine each target node contained in each cluster to be migrated; and collect the node traffic information of each target node using an extended Berkeley packet filter, wherein the node traffic information includes source address, destination address, communication port, data packet transmission and reception time, data packet size, and traffic transmission protocol type.

[0080] Optionally, the node relationship table generation module 320 is specifically used for: performing integrity verification on node traffic information; when the verification passes, determining the source node corresponding to the source address and the destination node corresponding to the destination address; sorting out the traffic relationship between the source node and the destination node based on the node traffic information, wherein the traffic relationship includes rate, flow direction and packet loss rate; and generating a node relationship table based on the source node, destination node and traffic relationship, wherein the node relationship table includes node name, node address and traffic relationship.

[0081] Optionally, the firewall detection module 330 specifically includes: a detection instruction generation unit, used to: perform a validity check on the updated node relationship table; after the check passes, identify the node pairs that need to be detected by the firewall based on the updated node relationship table; form a structured list of tasks to be detected based on the node pairs, and convert the list of tasks to be detected into detection instructions for the new cluster.

[0082] Optionally, the device further includes: a topology map generation module, used to: initiate a timed firewall probe task based on probe commands to obtain firewall probe results, wherein the firewall probe results include those that are enabled and those that are not; and dynamically generate a firewall topology map based on the firewall probe results.

[0083] Optionally, a topology map generation module is used to: draw topology map elements according to preset visualization rules based on firewall detection results, and generate a firewall topology map; when the firewall detection results change, automatically update the corresponding line colors and markers.

[0084] Optionally, the device also includes a topology map supplementation module, used to: draw node icons and communication lines corresponding to the newly added node pairs when new node pairs are added.

[0085] The technical solution of this invention reduces labor costs by collecting node traffic information, while ensuring the comprehensiveness and accuracy of traffic information collection, providing a reliable data source for subsequent firewall analysis. By generating a node relationship table, the relationships between nodes are presented intuitively, allowing users to quickly identify the firewall configurations that need to be migrated. Updating the table allows for precise matching of node information in the new cluster, providing suitable basic data for firewall probing of the new cluster. Without the need for manual identification of each probe target, the system can automatically locate the firewall objects to be probed in the new cluster, accurately issue commands, improve the startup efficiency of firewall probing, and ensure the orderly execution of probing tasks.

[0086] The firewall detection device provided in this embodiment of the invention can execute a firewall detection method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method execution.

[0087] Example 4

[0088] Figure 4 A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0089] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0090] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0091] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as a firewall detection method.

[0092] In some embodiments, a firewall detection method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the firewall detection method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform a firewall detection method by any other suitable means (e.g., by means of firmware).

[0093] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0094] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0095] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0096] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0097] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0098] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0099] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0100] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A firewall detection method, characterized in that, include: Collect node traffic information of the cluster to be migrated; A node relationship table is generated based on the node traffic information, and the node relationship table is displayed to the user to obtain the updated node relationship table based on user feedback. The updated node relationship table is deployed to the new cluster, and a probe command is generated based on the updated node relationship table. The firewall of the new cluster is then probed based on the probe command.

2. The method according to claim 1, characterized in that, The node traffic information collected from the cluster to be migrated includes: Identify the target nodes contained in each cluster to be migrated; An extended Berkeley packet filter is used to collect node traffic information for each target node. The node traffic information includes source address, destination address, communication port, packet transmission and reception time, packet size, and traffic transmission protocol type.

3. The method according to claim 2, characterized in that, The step of generating a node relationship table based on the node traffic information includes: The integrity of the node traffic information is verified. Once the verification is successful, the source node corresponding to the source address and the destination node corresponding to the destination address are determined. Based on the node traffic information, the traffic relationship between the source node and the destination node is analyzed, wherein the traffic relationship includes rate, flow direction and packet loss rate; A node relationship table is generated based on the source node, the destination node, and the traffic relationship, wherein the node relationship table includes node name, node address, and traffic relationship.

4. The method according to claim 1, characterized in that, The generation of probe commands based on the updated node relationship table includes: The updated node relationship table is validated for legality. Once the validation is successful, the node pairs that need to be detected by the firewall are identified based on the updated node relationship table. A structured list of tasks to be probed is formed based on the node pairs, and the list of tasks to be probed is transformed into probe commands for the new cluster.

5. The method according to claim 4, characterized in that, The method further includes: Based on the detection command, a timed firewall detection task is initiated to obtain firewall detection results, wherein the firewall detection results include whether the firewall is enabled or disabled. A firewall topology map is dynamically generated based on the firewall detection results.

6. The method according to claim 5, characterized in that, The dynamic generation of the firewall topology map based on the firewall detection results includes: Based on the firewall detection results, topology graph elements are drawn according to preset visualization rules to generate a firewall topology graph. When the firewall detection results change, the corresponding line color and markers are automatically updated.

7. The method according to claim 6, characterized in that, The method further includes: When a new node pair is added, the corresponding node icon and communication lines are drawn.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.

9. A computer storage medium, characterized in that, The computer storage medium stores computer instructions that are used to cause a processor to execute the method of any one of claims 1-7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method according to any one of claims 1-7.