Firewall policy generation method and device, equipment, medium and program product

Abstract

The invention provides a firewall policy generation method and device, equipment, a medium and a program product, and relates to the field of financial science and technology or the field of big data. The method comprises the steps that asset information and calling relation data of a service system are obtained, a network flow logic model is generated based on the asset information and the calling relation data, and the network flow logic model comprises a topological structure model used for describing the interior of the service system and a communication link between the service system and an external system, generating a firewall policy according to the network flow logic model; the firewall policy refuses access of all IPs to a specified port of the database by default, and the recorded specific IPs are released only through a white list; according to the method, the automation level of strategy configuration and the attack response speed are improved, so that the real-time defense requirement is efficiently met.

Description

Firewall policy generation methods, devices, equipment, media, and program products Technical Field

[0001] This application relates to the fields of financial technology or big data, and in particular to a firewall policy generation method, apparatus, device, medium, and program product. Background Technology

[0002] As large enterprises expand their businesses, their network architectures become increasingly complex. They not only divide their networks into multiple logical zones and subdivide them into sub-zones, but also deploy servers in multiple data centers within the same city and across different regions. Business operations involve multi-layered interactions and are undergoing a migration towards domestically produced solutions. In this environment, enterprises face a massive need for dynamic maintenance of firewall policies, such as policy adjustments for system expansion and data center relocation, as well as rapid response to network attacks.

[0003] Currently, enterprises mainly rely on asset management tools and network management systems to manually maintain firewall policies. They register server information through the asset management system and manually configure rules in conjunction with the network management system. When an attack occurs, the development team needs to manually check logs, trace traffic to sort out the attack chain, and adjust policies.

[0004] However, this model has a high degree of reliance on manual intervention and high complexity in collaborative configuration, resulting in low attack response efficiency that cannot meet real-time defense requirements. The strategies are prone to redundancy and failure, and lack dynamic correlation models, making it difficult to adapt to dynamic business needs. Summary of the Invention

[0005] This application provides a firewall policy generation method, apparatus, device, media, and program product to solve the technical problem of low attack response efficiency failing to meet real-time defense requirements.

[0006] Firstly, this application provides a firewall policy generation method, including:

[0007] Obtain asset information and call relationship data of the business system, wherein the asset information of the business system refers to the basic information of the server nodes in the business system, and the call relationship data refers to the communication logic inside the business system and the communication logic between the business system and external systems;

[0008] Based on the asset information and the call relationship data, a network traffic logic model is generated. The network traffic logic model includes: a topology model for describing the internal structure of the business system and the communication links between the business system and external systems.

[0009] Based on the network traffic logic model, a firewall policy is generated; the firewall policy by default denies all IPs accessing the specified port of the database, and only allows specific IPs registered through a whitelist.

[0010] Secondly, this application provides a firewall policy generation apparatus, comprising:

[0011] The acquisition module is used to acquire asset information and call relationship data of the business system. The asset information of the business system refers to the basic information of the server nodes in the business system, and the call relationship data refers to the communication logic inside the business system and the communication logic between the business system and external systems.

[0012] The generation module is used to generate a network traffic logic model based on the asset information and the call relationship data. The network traffic logic model includes a topology model describing the communication links within the business system and between the business system and external systems.

[0013] The generation module is also used to generate firewall policies based on the network traffic logic model; the firewall policies by default deny all IPs access to the specified ports of the database, and only allow specific IPs for filing through a whitelist.

[0014] Thirdly, embodiments of this application provide a firewall policy generation device, including: a memory and a processor;

[0015] The memory stores computer-executed instructions;

[0016] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0017] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0018] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0019] The firewall policy generation method provided in this application automatically collects asset information (such as server node type and region of origin) and service call chain data from business systems, and uses a large language model for semantic analysis to accurately construct communication relationship models within and between systems, thereby forming a network traffic logic model that highly conforms to actual business logic. Based on this, the model is incrementally trained using historical firewall policy logs and real-time traffic data to continuously optimize its ability to understand legitimate business call behavior, and automatically generates firewall policies accordingly, effectively blocking unauthorized IP access to critical resources such as databases. The entire process requires no manual intervention in policy configuration, significantly improving the accuracy and deployment efficiency of security policies, and achieving second-level identification and blocking of abnormal traffic. This greatly enhances the system's real-time defense capabilities against new or unknown attacks, ultimately ensuring business continuity while building a dynamic, intelligent, and closed-loop network security protection system. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0021] Figure 1 is a flowchart illustrating the firewall policy generation method provided in this application.

[0022] Figure 2 is a flowchart illustrating the firewall policy generation method provided in this application.

[0023] Figure 3 is a flowchart illustrating the firewall policy generation method provided in this application.

[0024] Figure 4 is a schematic diagram of the firewall policy generation device provided in this application;

[0025] Figure 5 is a schematic diagram of the firewall policy generation device provided in this application.

[0026] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concepts of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0027] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0028] It should be noted that the firewall policy generation method, apparatus, device, media and program products provided in this application can be used in the fintech field or the big data field, or in any field other than the fintech field or the big data field. This application does not limit the application field of the firewall policy generation method, apparatus, device, media and program products.

[0029] As large enterprises continue to expand their business scale, their network architecture becomes increasingly complex, typically divided into multiple logical zones and further subdivided into sub-zones. Simultaneously, servers are generally deployed in multiple data centers within the same city or even across regions, resulting in multi-layered and highly coupled business interactions, and accelerating the migration of domestically produced hardware and software. Against this backdrop, firewall policies need to cover a large number of dynamically changing assets and paths, placing higher demands on the accuracy and timeliness of these policies.

[0030] Currently, enterprises mainly rely on asset management tools and network management systems to manually maintain firewall policies: basic server information is registered through the asset management system, and then operation and maintenance personnel manually configure or adjust access control rules in the network management system; when encountering network attacks, it is also necessary to work together with development, security and operation and maintenance teams to manually analyze logs and trace traffic paths to reconstruct the attack chain, and then manually update the policy accordingly.

[0031] However, the heavy reliance on manual operation leads to high coordination costs and slow response times, making it difficult to meet real-time defense requirements.

[0032] To address the aforementioned issues, the firewall policy generation method provided in this application firstly collects asset information (such as server node type and logical zone) and call relationship data (such as call paths between service components) from the business system. Then, it utilizes a large language model to deeply analyze the structured and unstructured semantics contained within this data, automatically extracting communication relationship models within and across systems. Next, it integrates historical firewall policy logs and real-time network traffic to continuously and incrementally train the constructed network traffic logic model, enabling it to accurately map real business interaction behaviors. Based on this, a firewall policy is generated and dynamically distributed to the target server, while simultaneously monitoring traffic in real time and immediately blocking unauthorized access. This method achieves high-precision, high-response, and adaptive security protection capabilities for complex and dynamic enterprise network environments.

[0033] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0034] Figure 1 is a flowchart illustrating the firewall policy generation method provided in this application. The execution entity in this embodiment is, for example, a firewall policy generation system. As shown in Figure 1, the method includes:

[0035] S101: Obtain asset information and call relationship data of the business system. The asset information of the business system refers to the basic information of the server nodes in the business system, and the call relationship data refers to the communication logic within the business system and the communication logic between the business system and external systems.

[0036] Among them, the asset information of the business system refers to the basic information of the server nodes in the business system, including key information such as the identity of the server nodes, hardware configuration, and network attributes.

[0037] The call relationship data reflects the communication logic of the business system, including the communication logic between different server nodes and functional modules within the business system, as well as the communication logic between the business system and other independent external systems (such as partner enterprise systems, third-party service platforms, etc.), directly reflecting the path and relationship of system data flow.

[0038] Specifically, by deploying asset detection tools, a full scan of the business system network segment is performed to collect basic data such as server node IP address, hostname, operating system type and version, CPU / memory / disk configuration, and network card information; the scan results are manually verified to supplement the corresponding business function identifiers of the servers (such as "order server" and "user database server"), correct any missing or incorrect data, and form a complete asset information list.

[0039] The data on call relationships can be obtained through multi-dimensional data collection and integration: network traffic analysis tools are used to capture network data packets during the operation of the business system, and information such as source IP, destination IP, and port number in the data packets is parsed; the architecture design documents and interface development manuals of the business system are retrieved to extract the call interfaces between internal modules and the interface information of external systems; at the same time, the call records during long-term operation are supplemented by operation and maintenance logs (such as application server logs and gateway logs), and finally integrated to form a complete call relationship data graph.

[0040] For example, when acquiring asset information, a vulnerability scanning tool scans the 192.168.1.0 / 24 network segment, collecting information on three server nodes: Server A (IP: 192.168.1.10, hostname: order-server (OSvr, order server), CPU: 8 cores, memory: 16GB, business function: order processing); Server B (IP: 192.168.1.20, hostname: user-db-server (UserDB Svr, user database server), CPU: 16 cores, memory: 32GB, business function: user data storage); Server C (IP: 192.168.1.30, hostname: pay-server (PaySvr, payment server), CPU: 8 cores, memory: 16GB, business function: payment processing). After verification, the database port of Server B is added as 3306, forming an asset information list.

[0041] When obtaining call relationship data, network traffic analysis and monitoring tools were used to capture traffic data, revealing frequent communication between server A and servers B and C. The architecture documentation showed that server A (order processing) needed to call server B (user database) to query user information and server C (payment processing) to complete order payments. Gateway logs indicated that the e-commerce system needed to communicate with an external third-party payment system (IP: 203.0.113.50) via port 8080.

[0042] S102: Based on asset information and call relationship data, generate a network traffic logic model. The network traffic logic model includes a topology model that describes the communication links within the business system and between the business system and external systems.

[0043] Among them, the network traffic logic model is an abstract and structured representation of the communication relationships of business systems, and its core component is the topology model.

[0044] The topology model accurately describes the connection relationships, data flow, and key communication attributes (such as communication ports and protocol types) between server nodes within the business system and between the business system and external systems. It is not the connection topology of physical devices, but a virtual topology mapping that focuses on business communication logic.

[0045] Specifically, the acquired asset information and call relationship data are cleaned to remove duplicate data (such as duplicate call records) and invalid data (such as unreachable IP communication records), and key missing information (such as communication protocol type and data transmission direction) is supplemented. Then, a logical association mapping is performed: using the server nodes in the asset information as core nodes and the communication links in the call relationship data as connecting edges, the association between nodes and edges is established, clarifying the data flow direction of each edge (e.g., unidirectional flow from the order server to the user database server), communication port, and protocol (e.g., TCP protocol, port 3306). Finally, a visual modeling tool is used to construct a topology model, visually presenting the core nodes, connecting edges, and communication attributes, forming a complete network traffic logical model. During the modeling process, a model description document needs to be generated simultaneously, annotating the business meaning of each node and the business purpose of the link to ensure the model's understandability and reusability.

[0046] For example, the acquired asset information and call relationship data are preprocessed: one duplicate "order server → user database server" call record is removed, and the protocol and port information of each communication link is supplemented (order server → user database server: TCP protocol, port 3306; order server → payment server: TCP protocol, port 8081; e-commerce system → third-party payment system: HTTPS protocol, port 8080). Then, logical association mapping is performed: server A (order server), server B (user database server), and server C (payment server) are designated as internal core nodes, and the third-party payment system (IP: 203.0.113.50) as an external node; the call relationship is used as the connection edge to clarify the data flow: server A → server B (query user data), server A → server C (initiate payment request), server C → third-party payment system (submit payment information). Finally, a topology model is constructed, in which internal and external nodes are distinguished by different colors. Protocols, ports, and data flow directions are marked on the connection edges. At the same time, a model description document is generated, indicating that "the communication between server A and server B is used for user information verification when creating an order" and "the communication between server C and the third-party payment system is used to complete the payment amount deduction". This ultimately forms the network traffic logic model of the e-commerce business system.

[0047] S103: Generate firewall policies based on the network traffic logic model; the firewall policies by default deny all IPs access to the specified ports in the database, and only allow specific IPs registered through the whitelist.

[0048] Firewall policies, deployed on firewall devices, are a set of rules used to manage network access permissions, blocking any network access not explicitly permitted. Firewall policies focus on access control for specific database ports. While defaulting to denying all IP access to that port, they employ a whitelist mechanism to precisely allow specific, registered IPs, achieving fine-grained security protection for database ports and preventing unauthorized access from IPs.

[0049] Specifically, first, identify the IP address and designated open ports of the database server in the model; second, define the whitelist IP range: extract IP addresses with legitimate communication links to the database server from the model (i.e., application server IPs within the business system that need to access the database), and collect management terminal IPs approved by operations and maintenance personnel, register these IPs, and form a whitelist IP list; then, formulate basic denial rules: configure a rule in the firewall to "deny all IP addresses from accessing the specified database port by default" to ensure unauthorized access is blocked; finally, configure whitelist allow rules: add allow rules for the whitelist IP list to the firewall, clarifying the rule's scope (database server IP + designated port), access source (whitelist IP), protocol type, and setting rule priority (allow rules have higher priority than default denial rules) to ensure legitimate access from whitelist IPs is not blocked. After the policy is generated, rule verification is required by simulating access tests to the database port from different IPs (within and outside the whitelist) to verify the policy's effectiveness.

[0050] For example, firstly, based on the network traffic logical model, the core protection target is located: the database server is server B (IP: 192.168.1.20); secondly, the whitelist IP range is defined: the IP that has legitimate communication with server B is extracted from the model as server A (192.168.1.10, order server, which needs to query user data), and the IP of the operation and maintenance management terminal approved by the operation and maintenance team (192.168.0.50) is collected. These two IPs are registered and filed to form a whitelist IP list; subsequently, basic blocking is configured in the firewall. **Isolate Rule:** The rule content is "Deny all IP addresses accessing port 3306 of 192.168.1.20 via TCP protocol". Finally, configure the whitelist rules: Add two rules, Rule 1 "Allow 192.168.1.10 to access port 3306 of 192.168.1.20 via TCP protocol", and Rule 2 "Allow 192.168.0.50 to access port 3306 of 192.168.1.20 via TCP protocol", and set the priority of these two rules to be higher than the default deny rule. After configuring the policy, conduct an effectiveness test: Accessing port 3306 of server B from server A (192.168.1.10) should result in a successful connection; accessing the same port from the maintenance terminal (192.168.0.50) should also result in a successful connection; accessing the same port from a non-whitelisted IP address (such as 192.168.1.40, the test terminal) should result in the firewall blocking the connection. After verifying the policy's effectiveness, archive the firewall policy document.

[0051] The firewall policy generation method provided in this embodiment obtains asset information and call relationship data of the business system. The asset information refers to the basic information of the server nodes in the business system, and the call relationship data refers to the communication logic within the business system and the communication logic between the business system and external systems. Based on the asset information and call relationship data, a network traffic logic model is generated. The network traffic logic model includes a topology model describing the communication links within the business system and between the business system and external systems. A firewall policy is generated based on the network traffic logic model. The firewall policy, by default, denies all IP access to specified ports in the database, allowing only specific IPs registered through a whitelist. This method automatically obtains the asset information and call relationship data of the business system, constructs an accurate network traffic logic model, and generates a firewall policy based on a whitelist mechanism. This effectively eliminates the reliance on manual intervention, improves the automation level of policy configuration and attack response speed, thereby efficiently meeting real-time defense requirements.

[0052] Figure 2 is a flowchart illustrating the firewall policy generation method provided in this application. As shown in Figure 2, this embodiment, based on the embodiment in Figure 1, provides a detailed description of the firewall policy generation method, which includes:

[0053] S201: Obtain asset information and call relationship data from the business system.

[0054] Step S101 is similar to step S201, and will not be described again here.

[0055] Optionally, obtain asset information and call relationship data from the business system, specifically including at least one of the following:

[0056] Obtain server operation logs and extract asset information and call relationship data;

[0057] Synchronize asset information and call relationship data through the server interface.

[0058] Specifically, log files generated during server operation are collected. Through log parsing, key field extraction (such as asset identifiers, interface call records, and data transmission link information), and data cleaning, basic information of core assets such as servers, applications, and databases, as well as call relationship data such as call sequence and dependencies between assets, are separated and extracted from the log data. By calling the standardized interfaces provided by the business system server, based on the preset data synchronization protocol and authorization mechanism, asset information and call relationship data such as structured asset configuration information, interface call list, and service dependency table are directly synchronized from the server to ensure the efficiency and accuracy of data acquisition.

[0059] S202: Using a large language model, semantic analysis is performed on the server node type, region of ownership, and service call links in the call relationship data of the asset information to generate a system internal node communication relationship model and an inter-system communication link model. Among them, server node type refers to the classification of servers with different functions in the business system, region of ownership refers to the region obtained by dividing the server into logical regions in the network architecture, and service call link refers to the path of call between components in the business system.

[0060] Among them, server node type refers to the classification of servers within the business system according to business functions, such as order processing server, database server, payment processing server, etc.

[0061] The domain area refers to the logical division of servers based on network architecture planning, such as service access area, data storage area, operation and maintenance management area, etc., which is used to clarify the logical location of the server in the network topology.

[0062] A service call chain refers to the complete path when different components (servers, application modules) within a business system call services, as well as when the business system calls services from external systems. It includes the call initiator, intermediate nodes, call receiver, and data flow.

[0063] Large language model semantic analysis leverages the natural language understanding capabilities of large language models to parse, correlate, and refine unstructured / semi-structured information in asset information and call relationship data, uncovering hidden semantic relationships.

[0064] The internal node communication relationship model is a structured model used to represent the communication relationships between various server nodes within the business system. It includes information such as node type, region of origin, communication path, and data flow direction.

[0065] The inter-system communication link model is a structured model used to represent the communication relationship between business systems and external systems, focusing on cross-system service call paths and interaction logic.

[0066] Specifically, firstly, asset information (including node type and region of origin) and call relationship data (including service call chains) are organized into a standardized text format, removing duplicate and invalid data (such as unreachable call records) and supplementing missing semantic information (such as call scenario descriptions). Secondly, the preprocessed data is input into a large language model to parse the semantic association between server node type and region of origin (e.g., "data storage area" should be associated with database-type nodes); identify the core components, call order, and business scenarios in the service call chain; and associate the semantic differences between internal node communication and cross-system communication. Finally, based on the semantic analysis results, a visualization modeling tool is used to construct an internal node communication relationship model, clearly presenting the type, region of origin, and communication chain of internal nodes; simultaneously, an inter-system communication chain model is constructed, focusing on the initiating node, target system, call path, and interaction protocol of cross-system calls, and simultaneously generating model documentation to annotate semantic associations and business meanings.

[0067] For example, the preprocessed asset information and call relationship data are first organized into text: "Asset Information: Server A (order processing server, business access area), Server B (user database server, data storage area), Server C (payment processing server, business access area), Server D (log storage server, operation and maintenance management area); Call Relationship: Server A → Server B (order creation and query user information), Server A → Server C (order payment and call payment service), Server C → Third-party payment system (submit payment request), Server A / C → Server D (upload business logs)". This text is then input into a large language model, and the model is guided by prompt words to analyze: identify the semantic association between "data storage area" and "database server", and the association between "business access area" and "business processing server"; parse the business scenarios of the service call chain (order creation, order payment, log upload, cross-system payment); and distinguish between internal communication (server A → B, A → C, A / C → D) and cross-system communication (server C → third-party payment system). Based on the analysis results, an internal node communication relationship model is used, with node labels indicating type and region, and edge labels indicating communication path and business scenario. An inter-system communication link model is constructed to clearly present the call path "Server C (payment processing server, business access area) → third-party payment system (IP: 203.0.113.50)", the HTTPS (Hypertext Transfer Protocol Secure) protocol, and the business scenario of "submitting a payment request".

[0068] S203: Based on historical firewall policy execution logs and real-time network traffic data, incrementally train the network traffic logic model to optimize its ability to model business call relationships.

[0069] Among them, historical firewall policy execution logs refer to log data recorded during the past operation of firewall devices, including key information such as policy matching, access permission / denial, traffic source and destination. It contains historical records of legal and illegal access and can reflect the historical patterns of business call relationships.

[0070] Real-time network traffic data refers to the network data packets generated in real time during the operation of a business system. It includes information such as the current business call path, traffic volume, and communication frequency, and can reflect the real-time status of business call relationships.

[0071] Specifically, the process begins with data collection and preprocessing: historical firewall policy execution logs are extracted using log collection tools, and valid data related to business calls (such as records of legally allowed business traffic and records of mistakenly blocked normal business traffic) are filtered out. Network traffic data is captured in real time using network traffic collection tools, and key fields such as source IP, destination IP, port, and communication frequency are parsed out, while noise data (such as invalid broadcast packets) is removed. Next, an incremental training dataset is constructed: the preprocessed historical log data and real-time traffic data are correlated and fused, and the business call relationships (such as newly added temporary business call links and traffic changes in existing links) are labeled to form an incremental training dataset. Finally, incremental training and optimization are performed: the incremental training dataset is input into the existing network traffic logic model, and the gradient descent optimization algorithm is used to adjust the model parameters to adapt the model to the newly added business call patterns. After training, the accuracy and misjudgment rate of identifying business call relationships before and after optimization are compared to verify the optimization effect. If the expected results are not achieved, additional data is added and incremental training is repeated until the model's modeling capabilities meet the requirements.

[0072] For example, first extract firewall policy execution logs from the past three months and filter out valid data, such as "Allow 192.168.1.10→192.168.1.20:3306 (order query user data)", "Deny 192.168.1.50→192.168.1.20:3306 (unauthorized access)", and "Mistakenly deny 192.168.1.30→192.168.1.20:3306 (temporary payment reconciliation business)". Real-time network traffic data is captured, revealing a new communication link "Server C→Server B (payment reconciliation data query)" with a communication frequency of once per hour. These data are then correlated and merged, and the newly added call links and temporary business scenarios are labeled to form an incremental training dataset. This dataset is input into the existing network traffic logic model for incremental training, adjusting the "communication association weights between Server C and Server B" in the model, and adding identification rules for the "temporary payment reconciliation" business scenario. Validation after optimization: The model can accurately identify the legitimate call chain of "Server C → Server B", and the false judgment rate has been reduced from 8% before optimization to 2%, successfully improving the modeling accuracy of new business call relationships.

[0073] S204: Generate firewall policies based on the network traffic logic model; the firewall policies by default deny all IPs access to the specified ports in the database, and only allow specific IPs registered through the whitelist.

[0074] The whitelist refers to a list of IP addresses that have been formally registered and verified and are allowed to access a specified port of the database. Only IPs on the whitelist can bypass the default denial rule.

[0075] The specific IPs registered refer to legitimate IP addresses that have undergone business approval and security verification and are clearly required to access the database, such as application server IPs and operation and maintenance management terminal IPs within the business system.

[0076] Specifically, firstly, based on the network traffic logic model, the IP address and designated protection port (such as the default port or custom business port corresponding to the database service) of the database server in the business system are clearly defined. Secondly, a whitelist of IP addresses is compiled: internal server IPs with legitimate business call relationships with the database server are extracted from the model; IP addresses of operation and maintenance management terminals and legitimate third-party interface IPs that have been approved by both the operation and maintenance department and the business department and completed filing are collected and integrated to form a whitelist of IP addresses and archived for record. Then, firewall rules are formulated: first, the basic rule "default denies all IP addresses access to the specified database port" is configured; then, whitelist allow rules are configured, clarifying the scope of application (database server IP + specified port), access source (whitelist IP), communication protocol, and setting the allow rule priority higher than the default deny rule. Finally, rule verification is performed: the effectiveness of the rules is verified by simulating access tests of whitelisted and external IPs to the specified database port; the rule document is reviewed and archived.

[0077] For example, based on the network traffic logic model, the core protection target is located: the database server is server B (IP: 192.168.1.20), and the designated protection port is port 3306 of the database. A whitelist of IPs is compiled: internal IPs with legitimate call relationships to server B are extracted from the model (server A: 192.168.1.10, server C: 192.168.1.30); the registered operation and maintenance management terminal IPs (192.168.0.50) are collected, integrated to form a whitelist, and archived. Firewall policies are formulated: the basic rule is "by default, deny all IPs accessing port 3306 of 192.168.1.20 via TCP protocol"; the whitelist allow rule is "allow 192.168.1.10, 192.168.1.30, and 192.168.0.50 to access port 3306 of 192.168.1.20 via TCP protocol", with the allow rule set to the highest priority. Verification test: Accessing from server A (within the whitelist) is successful, accessing from the maintenance terminal (within the whitelist) is successful, accessing from an unregistered test terminal (192.168.1.60, outside the whitelist) is blocked. After verifying the effectiveness of the policy, archive the rule document.

[0078] S205: Dynamically distribute firewall policies to the target server.

[0079] Specifically, first, a policy distribution management platform is built, and an automated operation and maintenance management platform is deployed. Communication configuration between the platform and the target server is completed to ensure the platform can properly manage the target devices. Second, policy format conversion is performed: the generated firewall policies (such as text-based rule lists) are converted into the firewall configuration format corresponding to the target server using the platform's built-in parsing tool. Then, dynamic distribution is executed: the target server list is selected in the management platform, triggering the policy distribution command. The platform pushes the converted configuration command to the target server through a preset communication channel. During the distribution process, the distribution status is monitored in real time. If a distribution failure occurs (such as network interruption or insufficient permissions), it is automatically retried and logged. After distribution is complete, the platform pushes a distribution result notification to the operation and maintenance personnel. Finally, distribution verification is performed: the target server is logged into, and the firewall policy configuration is viewed through the command line or graphical interface to confirm that the distributed rules are complete and correct.

[0080] For example, the target servers are a firewall server (IP: 192.168.1.1) and database server B (IP: 192.168.1.20, with host firewall enabled), deployed at the boundary of the data storage area. First, set up an automated management platform and configure SSH key authentication between the platform and the two target servers to ensure normal communication. Parse the firewall policy into rule format. Select the two target servers on the platform and trigger the push command. The platform pushes the rules to the servers via the SSH (Secure Shell) channel. After the push is complete, the operations and maintenance personnel receive a "Policy push successful" notification; log in to the target servers, execute the command, and check and confirm that the rules are correctly configured.

[0081] S206: Real-time acquisition of network traffic of the target server.

[0082] Among them, the network traffic of the target server refers to all data packets related to the network interface of the target server, including key information such as the source IP, destination IP, destination port, communication protocol, traffic size, access time, and data packet type, including legitimate access traffic and potential illegal access traffic.

[0083] Specifically, depending on the target server's operating system type, deploy the corresponding real-time traffic collection tool or use a general network traffic monitoring platform. Next, configure the collection parameters: in the collection tool, set the target server's network interface, the traffic fields to be collected (source IP, destination IP, port, protocol, etc.), the collection frequency (e.g., millisecond-level collection), and the data storage path (local cache + remote database). Simultaneously, set filtering rules to prioritize collecting traffic data related to a specified port in the database (e.g., port 3306) to reduce interference from irrelevant data. Then, establish a real-time transmission channel: use streaming technology (e.g., Kafka) to transmit the collected real-time traffic data to the monitoring center's database, ensuring low latency and stability in data transmission; perform simple data cleaning during transmission to remove invalid data (e.g., broken data packets). Finally, build a real-time monitoring interface: configure a traffic display panel in the monitoring platform to present information such as the target server's traffic volume, access IP distribution, and port access popularity in real time.

[0084] For example, the target servers are a firewall server (192.168.1.1) and database server B (192.168.1.20). Deploy real-time data collection tools on both servers and configure the collection parameters: specify the network interface for collection, and include the source IP, destination IP, destination port, protocol, access time, and traffic volume in the collection fields. Set the collection frequency to 500 milliseconds / time, and the filtering rule to "only collect TCP traffic destined for port 3306". Establish a Kafka transmission channel to transmit the collected traffic data to the monitoring center's database in real time. Build a real-time display panel on the monitoring platform and configure modules such as "Top 5 IPs Accessing Port 3306", "Real-time Traffic Trends", and "Legal / Illegal Access Statistics". The maintenance personnel can view in real time through the panel: server A (192.168.1.10) accesses approximately 100MB of traffic per hour to server B's port 3306, server C (192.168.1.30) accesses approximately 50MB of traffic per hour, and the maintenance terminal (192.168.0.50) accesses traffic occasionally, thus realizing real-time monitoring of the network traffic related to the target server.

[0085] S207: If target network traffic that does not conform to the firewall policy is detected, the target network traffic will be blocked. The target network traffic is an unauthorized IP access.

[0086] Specifically, based on the generated firewall policy whitelist, detection rules are configured in the real-time monitoring platform. When the collected network traffic has a destination IP that is the database server IP, a destination port that is a specified protected port, and a source IP that is not in the whitelist, it is determined to be target network traffic that does not comply with the policy (unauthorized IP access). Next, real-time detection is performed: the monitoring platform continuously compares the collected real-time traffic data with the detection rules to identify illegal traffic in real time; during the detection process, detailed information about the illegal traffic (source IP, access time, number of accesses, traffic size) is recorded to form an illegal access log. Then, a blocking mechanism is triggered: when illegal traffic is detected, the monitoring platform automatically sends a blocking command to the target server's firewall, dynamically adds temporary blocking entries through firewall rules, and blocks subsequent access from the unauthorized IP (the blocking duration can be set, such as 24 hours); at the same time, an alarm notification (such as SMS or email) is sent to the operations and maintenance personnel, informing them of the key information of the illegal access. Finally, a violation review is conducted: operations and maintenance personnel regularly review the illegal access logs, analyze the source and access intent of the unauthorized IP, and if there is a risk of continuous attacks, the IP can be added to a long-term blacklist; if it is a misjudgment, the detection rules are adjusted or the whitelist is supplemented.

[0087] For example, the monitoring platform can be configured with the following detection rule: "If the destination IP of the traffic is 192.168.1.20, the destination port is 3306, and the source IP is not within the range {192.168.1.10, 192.168.1.30, 192.168.0.50}, then it is determined to be unauthorized IP access." At a certain moment, the monitoring platform collects traffic data: source IP is 192.168.1.60 (not registered), destination IP is 192.168.1.20, destination port is 3306, and the protocol is TCP. The system immediately determines this to be target network traffic that does not conform to the policy. The platform then automatically sent a blocking command to the firewall server (192.168.1.1), added a new rule, and set the blocking duration to 24 hours. Simultaneously, it sent an email alert to the operations and maintenance personnel: "Unauthorized IP (192.168.1.60) was detected accessing database server port 3306. Access time: 2025-XX-XX 14:30:25, Access count: 3." After reviewing the logs, the operations and maintenance personnel confirmed that the IP was an unauthorized external probe IP and added it to the long-term blacklist to strengthen security protection.

[0088] The firewall policy generation method provided in this embodiment obtains asset information (including server node types and their logical regions) and call relationship data (covering service call links between internal system components and with external systems) from the business system. It then uses a large language model to perform semantic analysis on this structured and unstructured data, automatically generating a communication relationship model between internal system nodes and a communication link model between systems. Simultaneously, it combines historical firewall policy execution logs and real-time network traffic data to continuously and incrementally train the constructed network traffic logic model, constantly improving its accuracy in modeling dynamic business call relationships. Based on this, it generates a refined firewall policy that, by default, denies all IP access to specified database ports and only allows whitelisted IPs to pass. This policy is dynamically distributed to the target server, and network traffic is monitored in real time. Once unauthorized access is detected, it is immediately blocked. The entire process achieves closed-loop automation from asset identification and relationship modeling to policy generation and execution, reducing reliance on manual operation, significantly improving policy configuration efficiency and security response speed, and effectively meeting the needs of real-time, accurate, and adaptive network security defense in complex business environments.

[0089] Figure 3 is a flowchart illustrating the firewall policy generation method provided in this application. As shown in Figure 2, this embodiment, based on the embodiment in Figure 2, provides a detailed description of dynamically distributing firewall policies to the target server. The method includes:

[0090] S301: Prioritize firewall policies based on business importance and risk level.

[0091] Business importance refers to the degree of coreness of the business functions protected by the firewall policy in the overall business system. It is usually divided according to the scope of the impact of the business on the system operation, the scale of service users, and the losses caused by the interruption. Core businesses are more important than non-core businesses.

[0092] Risk level refers to the likelihood of security threats facing the protected scenario corresponding to the firewall policy and the degree of harm caused by the threats. It is assessed based on dimensions such as threat source, attack probability, and data leakage risk. The higher the risk, the higher the protection priority should be.

[0093] Firewall policy priorities are used to define the execution order and deployment priority of different firewall policies. Policies with higher priorities will be executed and distributed first, ensuring that core protection needs are met first and avoiding security vulnerabilities in core businesses due to improper policy execution / deployment order.

[0094] Specifically, firstly, business importance is categorized into three levels: "core," "important," and "general," while risk levels are categorized into three levels: "high," "medium," and "low." A matrix mapping is used to determine the priority hierarchy of firewall policies (e.g., core business + high risk corresponds to priority 1, the highest level; general business + low risk corresponds to priority 3, the lowest level). The definitions and applicable scenarios for each priority level are clearly defined, and an assessment manual is created. Secondly, policy hierarchical assessment is conducted: each generated firewall policy is reviewed, identifying the corresponding protection business module (e.g., user data query, payment reconciliation, log upload, etc.). In collaboration with business and security departments, the business importance and risk level of each policy are determined according to the assessment system, thus mapping the priority level. Finally, priorities are marked and archived: each policy is clearly marked with a priority identifier (e.g., P1, P2, P3) in the firewall policy document, grouped by priority to form a policy list, and synchronously updated to the policy management platform.

[0095] For example, the system has generated three core firewall policies: Policy 1 "Allow 192.168.1.10 (order server) to access 192.168.1.20:3306 (user database)", Policy 2 "Allow 192.168.1.30 (payment server) to access 192.168.1.20:3306 (user database)", and Policy 3 "Allow 192.168.0.50 (operations and maintenance terminal) to access 192.168.1.20:3306 (user database)". A priority assessment system has been established: core business (order processing, payment services) + high risk (data leakage affecting user fund security) corresponds to P1 (highest level); general business (operations and maintenance management) + medium risk (only affecting operations and maintenance efficiency) corresponds to P2 (medium level). Assessment Process: Strategy 1 protects order processing business (core), and Strategy 2 protects payment service business (core), both of which are core businesses with high risk, and are assessed as P1; Strategy 3 protects operation and maintenance query business (general), which is a general business with medium risk, and is assessed as P2. Final Marking and Archiving: Strategy 1 (P1), Strategy 2 (P1), Strategy 3 (P2), and updating to the e-commerce system strategy management platform.

[0096] S302: Send firewall policies to target servers in priority order.

[0097] The priority order refers to the order in which firewall policies are issued according to their priority hierarchy. Policies with higher priority (such as P1) are issued and take effect first, while policies with lower priority (such as P2 and P3) are issued in sequence after the higher priority policies are issued, ensuring that core protection requirements are implemented first.

[0098] Policy delivery refers to the process of converting priority-marked firewall policies into configuration instructions that can be recognized by the target server and pushing them to the devices through an automated management platform.

[0099] The target server refers to the network boundary firewall or host firewall where firewall policies need to be deployed, such as the boundary firewall of the data storage area in an e-commerce system (192.168.1.1) and the user database server (192.168.1.20).

[0100] Specifically, in the automated operation and maintenance management platform, a list of policies with priority tags is imported, and the distribution rule is set to "distribute policies sequentially from highest to lowest priority, with policies of the same priority being distributed in parallel; after all high-priority policies have been distributed and verified to be effective, the distribution of low-priority policies will then begin." Next, policy configuration is pre-processed: policies of different priorities are converted into the firewall configuration format corresponding to the target servers, and stored in groups according to priority to avoid format confusion during distribution. Then, tiered distribution is executed: the target server list is selected in the management platform, and a distribution command is triggered. The platform first pushes P1-level policies to the target servers, monitoring the distribution status in real time (e.g., whether the push was successful, whether it has started to take effect); after all P1-level policies have been distributed and verified to be effective, the distribution process for P2-level and lower policies is automatically started. Finally, distribution logs are recorded: the platform synchronously records the distribution time, target server, priority, and distribution result (success / failure) for each policy.

[0101] For example, the target servers are a data storage zone boundary firewall (192.168.1.1) and a user database server (192.168.1.20), and the deployment is executed using an automated platform. First, the policy list (Policy 1: P1, Policy 2: P1, Policy 3: P2) is imported into the platform, and the deployment rule is set to "P1 is deployed first, and P2 is deployed only after all policies are effective." The P1-level policies (Policy 1 and Policy 2) are converted into rule format, and the P2-level policy (Policy 3) is converted into a separate rule. After triggering the deployment command, the platform first pushes Policy 1 and Policy 2 in parallel to the two target servers. After 5 minutes, monitoring shows that both servers have successfully received and implemented the policy. Subsequently, the platform automatically pushes Policy 3 to the target servers, and it is verified to be effective after 1 minute. The log entries are as follows: "2025-XX-XX 15:00 Strategy 1 (P1) successfully sent to 192.168.1.1 / 192.168.1.20" and "2025-XX-XX 15:05 Strategy 3 (P2) successfully sent to 192.168.1.1 / 192.168.1.20".

[0102] S303: Obtain the status information of the target server.

[0103] Among them, the target server's status information refers to the core data set that reflects the target server's operating status, network connectivity, and firewall policy operation, and is the key basis for determining whether the server is working properly. It includes three types of information: first, the server's basic operating status (such as CPU utilization, memory usage, disk space, and process running status); second, network connectivity status (such as whether the network interface is normal and whether communication with the management platform is smooth); and third, firewall service status (such as whether the firewall process is running, whether the policy is loaded normally, and whether there are policy conflicts).

[0104] Specifically, first, deploy automated monitoring tools and complete the communication configuration between the tools and target servers (such as installing monitoring agents, configuring API interfaces, and setting up SSH key authentication) to ensure that the tools can collect data stably. Second, define the collection metrics (basic operating status: CPU utilization, memory usage, etc.; network status: port open status, etc.; firewall status: firewall process status, policy loading status, etc.), set the collection frequency (core metrics once every minute, non-core metrics once every 5 minutes), and define the data transmission method (real-time streaming to the monitoring platform) and storage path (local cache + remote monitoring database). Then, the monitoring tools continuously collect the status information of the target servers according to the configured frequency and metrics, and perform preliminary data cleaning during the collection process (removing invalid data and correcting outliers). Finally, configure a visualization panel in the monitoring platform to display the real-time status information of each target server and set data threshold alarms (such as an alarm when CPU utilization exceeds 80%).

[0105] For example, the target servers are 192.168.1.1 (border firewall) and 192.168.1.20 (database server), and monitoring tools are used to collect status information. The collection parameters are configured as follows: core metrics (CPU utilization, memory usage, firewall process status) are collected every minute, and non-core metrics (disk space, network interface traffic) are collected every 5 minutes. After real-time collection, the platform panel displays: 192.168.1.1 (CPU utilization 25%, memory usage 30%, process running normally); 192.168.1.20 (CPU utilization 40%, memory usage 45%, process running normally, port 3306 open). Thresholds are also set: an alarm is triggered when CPU utilization ≥ 85% and memory usage ≥ 90%, ensuring that abnormal states are detected promptly.

[0106] Optionally, the status information of the target server can be obtained. Specific implementation methods include:

[0107] The probe online status of the target server is obtained in real time. The probe online status refers to the operating status of the probe.

[0108] An alarm message is generated when the probe's online status is abnormal.

[0109] Specifically, monitoring probes deployed on the target server continuously acquire their operational status (i.e., probe online status, including normal operation, process termination, communication interruption, etc.) using timed heartbeat detection or real-time communication mechanisms. Simultaneously, a status verification and alarm triggering mechanism is established. The monitoring platform or management terminal receives the status data reported by the probes in real time. If an abnormal online status is detected (e.g., failure to receive heartbeat packets on time, communication connection timeout, probe process non-existence, etc.), a preset alarm process is immediately triggered. This generates alarm information containing key information such as the target server identifier, probe anomaly type, anomaly occurrence time, and anomaly troubleshooting suggestions. This information is then pushed to relevant maintenance personnel via SMS, email, monitoring platform pop-ups, or maintenance work orders to ensure timely response to server monitoring anomalies.

[0110] S304: Determine whether the target server is invalid based on the status information.

[0111] Among them, target server failure refers to the state in which the target server is unable to provide network protection services normally due to hardware failure, software crash, network interruption or abnormal configuration, and the firewall policy cannot be effectively executed.

[0112] Specifically, based on the types of status information collected, the core failure criteria are clearly defined: first, basic operational failure (e.g., CPU / memory usage consistently at 100%, core process crashes and inability to automatically restart); second, network connectivity failure (e.g., network interface disconnection, communication interruption with the management platform exceeding 5 minutes, inaccessibility of critical protection ports); and third, firewall service failure (e.g., firewall process stops running, policy loading fails, severe policy conflicts leading to paralysis of protection functions). Secondly, a multi-level verification mechanism is established: when the monitoring platform detects that a certain indicator triggers a failure condition, it does not directly determine failure, but initiates secondary verification (e.g., remote login to verify process status, manual query of policy loading status) to avoid misjudgments due to temporary network fluctuations or data collection errors. Finally, failure determination is performed: if the failure determination conditions are still met after secondary verification, the target server is officially determined to be failed; if the indicator returns to normal after verification, it is determined to be a temporary anomaly, an anomaly log is recorded, and continuous monitoring continues.

[0113] For example, failure criteria were defined as follows: "1. The firewall process stops running and cannot automatically restart within 3 minutes; 2. Communication with the platform is interrupted for more than 5 minutes." On-site inspection by data center maintenance personnel revealed that the firewall server had stopped due to a power failure, and the firewall process was completely inoperable. Both verifications met the failure conditions, and the 192.168.1.1 server was officially declared faulty. The determination result was pushed to the maintenance management platform, and a text message alert was sent to the maintenance manager: "Target server 192.168.1.1 (border firewall) has failed due to a power failure. Please handle it promptly."

[0114] S305: If the target server fails, delete the firewall policy associated with the target server.

[0115] Among them, the firewall policies associated with the target server refer to all firewall policies that have been issued to the failed target server, including allow rules and deny rules with different priorities. These policies can no longer perform their protective functions due to the server failure.

[0116] Specifically, in the policy management platform, based on the unique identifier of the failed server (such as IP address or hostname), all associated firewall policies issued to that server are queried and filtered to form a policy deletion list. This list clearly defines the ID, priority, and rule content of each policy to avoid deleting irrelevant policies. Next, the deletion execution method is selected: if the failed server can still communicate with the management platform (e.g., only the firewall service is down, and the server's basic network is normal), a remote deletion command is sent through the automated management platform to delete associated policies in batches; if the server is completely uncommunicative (e.g., downtime, network interruption), maintenance personnel are assigned to log in to the server on-site (or through the server console) and manually execute the deletion command to remove the associated policies. Then, the policy deletion is executed: policies are deleted one by one according to the deletion list, with the deletion status (success / failure) recorded in real time during the process; after deletion, all associated policies are confirmed to have been completely removed through command queries (e.g., iptables -L) or platform verification. Finally, the deletion records are archived: the deleted policy list, deletion time, executor, and deletion result are archived to the policy management log, and the status record of the failed server is marked as "Associated policies deleted".

[0117] For example, if the target server 192.168.1.1 (border firewall) has been determined to be ineffective, firstly, in the policy management platform, query the associated policies based on the IP address 192.168.1.1 to generate a deletion list: Policy 1 (P1: Allow 192.168.1.10 to access 192.168.1.20:3306), Policy 2 (P1: Allow 192.168.1.30 to access 192.168.1.20:3306), and Policy 3 (P2: Allow 192.168.0.50 to access 192.168.1.20:3306). Since the server is completely uncommunicative due to a power failure, on-site maintenance personnel are dispatched to handle the situation: log in to the server through the KVM console in the data center, execute the deletion command, and delete the associated policies one by one. After deletion, execute the command verification to confirm that all three policies have been removed. Finally, the deletion list, execution time (2025-XX-XX 16:30), executor, and deletion result (success) are archived to the policy management log, and server 192.168.1.1 is marked "Associated policy has been deleted".

[0118] Figure 4 is a schematic diagram of the firewall policy generation device provided in this application. As shown in Figure 4, the firewall policy generation device 400 provided in this embodiment includes:

[0119] The acquisition module 401 is used to acquire asset information and call relationship data of the business system. The asset information of the business system refers to the basic information of the server nodes in the business system, and the call relationship data refers to the communication logic inside the business system and the communication logic between the business system and external systems.

[0120] The generation module 402 is used to generate a network traffic logic model based on asset information and call relationship data. The network traffic logic model includes a topology model describing the communication links between the business system and external systems.

[0121] The generation module 402 is also used to generate firewall policies based on the network traffic logic model; the firewall policy by default denies all IPs accessing the specified ports in the database, and only allows specific IPs registered through a whitelist.

[0122] In one possible implementation, the generation module 402 is further configured to perform semantic analysis on the server node type, home region, and service call link in the call relationship data in the asset information through a large language model, and generate a system internal node communication relationship model and an inter-system communication link model; wherein, the server node type refers to the classification of servers with different functions in the business system, the home region refers to the region obtained by dividing the server into logical regions in the network architecture, and the service call link refers to the path of inter-component calls in the business system.

[0123] In one possible implementation, the firewall policy generation device 400 further includes: a sending module 403 and a processing module 404;

[0124] The sending module 403 is used to dynamically send firewall policies to the target server;

[0125] The acquisition module 401 is also used to acquire the network traffic of the target server in real time;

[0126] Processing module 404 is used to block target network traffic that does not conform to the firewall policy if it detects target network traffic that is accessed by an unauthorized IP.

[0127] In one possible implementation, the processing module 404 is also configured to assign priorities to firewall policies based on business importance and risk level.

[0128] The sending module 403 is also used to send firewall policies to the target server in order of priority.

[0129] In one possible implementation, the firewall policy generation apparatus 400 further includes: a determination module 405 and a deletion module 406;

[0130] The acquisition module 401 is also used to acquire the status information of the target server;

[0131] The determination module 405 is used to determine whether the target server has failed based on the status information.

[0132] Remove module 406, which is used to remove firewall policies associated with a target server in the event that the target server fails.

[0133] In one possible implementation, the acquisition module 401 is used to acquire the probe online status of the target server in real time, where the probe online status refers to the operating status of the probe.

[0134] The generation module 402 is used to generate alarm information when the probe is in an abnormal online state.

[0135] In one possible implementation, the acquisition module 401 is also used to acquire server operation logs and extract asset information and call relationship data;

[0136] The acquisition module 401 is also used to synchronize asset information and call relationship data through the server interface.

[0137] In one possible implementation, the processing module 404 is further configured to incrementally train the network traffic logic model based on historical firewall policy execution logs and real-time network traffic data, thereby optimizing its ability to model service call relationships.

[0138] Figure 5 is a schematic diagram of the firewall policy generation device provided in this application. As shown in Figure 5, the electronic device of this embodiment may include: at least one processor 501; and a memory 502 communicatively connected to at least one processor; wherein, the memory 502 stores instructions that can be executed by at least one processor 501, and the instructions are executed by at least one processor 501 to cause the electronic device to perform the method as described in any of the above embodiments.

[0139] Optionally, the memory 502 can be either standalone or integrated with the processor 501. When the memory 502 is set up independently, the device also includes a bus for connecting the memory 502 and the processor 501.

[0140] The implementation principle and technical effects of the electronic device provided in this embodiment can be found in the foregoing embodiments, and will not be repeated here.

[0141] This application also provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are executed by a processor, the methods provided in any of the foregoing embodiments can be implemented.

[0142] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the method provided in any of the foregoing embodiments.

[0143] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0144] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0145] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0146] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0147] Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as resistive random access memory (RRAM), dynamic random access memory (DRAM), static random access memory (SRAM), enhanced dynamic random access memory (EDRAM), high-bandwidth memory (HBM), hybrid memory cube (HMC), etc.

[0148] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0149] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0150] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0151] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A firewall policy generation method, characterized in that, The method includes: acquiring asset information and call relationship data of a business system, wherein the asset information of the business system refers to the basic information of server nodes in the business system, and the call relationship data refers to the communication logic within the business system and the communication logic between the business system and external systems; generating a network traffic logic model based on the asset information and the call relationship data, wherein the network traffic logic model includes: a topology model describing the communication links within the business system and between the business system and external systems; generating a firewall policy based on the network traffic logic model; wherein the firewall policy, by default, denies all IP access to a specified port of the database, and only allows specific IPs registered through a whitelist.

2. The method according to claim 1, characterized in that, The step of generating a network traffic logical model based on the asset information and the call relationship data includes: performing semantic analysis on the server node type and home region in the asset information and the service call link in the call relationship data through a large language model to generate an internal node communication relationship model and an inter-system communication link model; wherein, the server node type refers to the classification of servers with different functions in the business system, the home region refers to the region obtained by dividing the server into logical regions in the network architecture, and the service call link refers to the path of inter-component calls in the business system.

3. The method according to claim 1, characterized in that, After generating the firewall policy based on the network traffic logic model, the process further includes: dynamically sending the firewall policy to the target server; acquiring the network traffic of the target server in real time; and blocking the target network traffic if it does not conform to the firewall policy, wherein the target network traffic is unauthorized IP access.

4. The method according to claim 1, characterized in that, The step of dynamically distributing the firewall policy to the target server includes: assigning priorities to the firewall policy based on business importance and risk level; and distributing the firewall policy to the target server in priority order.

5. The method according to claim 3 or 4, characterized in that, After dynamically distributing the firewall policy to the target server, the method further includes: obtaining the status information of the target server; determining whether the target server is inactive based on the status information; and deleting the firewall policy associated with the target server if the target server is inactive.

6. The method according to claim 5, characterized in that, The step of obtaining the status information of the target server includes: obtaining the probe online status of the target server in real time, wherein the probe online status refers to the operating status of the probe; and generating alarm information when the probe online status is abnormal.

7. The method according to claim 1, characterized in that, The acquisition of asset information and call relationship data of the business system specifically includes at least one of the following: acquiring server operation logs and extracting the asset information and the call relationship data; The asset information and the call relationship data are synchronized through the server interface.

8. The method according to claim 1, characterized in that, After generating the network traffic logic model based on the asset information and the call relationship data, the method further includes: incrementally training the network traffic logic model based on historical firewall policy execution logs and real-time network traffic data to optimize its ability to model business call relationships.

9. A firewall policy generation device, characterized in that, include: The acquisition module is used to acquire asset information and call relationship data of the business system. The asset information refers to the basic information of the server nodes in the business system, and the call relationship data refers to the communication logic within the business system and the communication logic between the business system and external systems. The generation module is used to generate a network traffic logic model based on the asset information and the call relationship data. The network traffic logic model includes a topology model describing the communication links within the business system and between the business system and external systems. The generation module is also used to generate a firewall policy based on the network traffic logic model. The firewall policy, by default, denies all IP access to a specified port in the database, and only allows specific IPs registered through a whitelist.

10. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-8.

12. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-8.

Images