Intranet security policy detection method and device

Abstract

The embodiment of the present application provides a kind of intranet security policy detection method and device, and intranet security policy detection system includes at least one client and server, the at least one client respectively belongs to at least one network area in intranet, the method comprises: the client generates rule acquisition request, and sends the rule acquisition request to the server;The server determines the detection rule of the client according to the rule acquisition request and sends the detection rule to the client, and the detection rule is used to indicate the access authority between client and target end;The client accesses the target end in the detection rule, and sends the abnormal access result that does not meet the detection rule to the server;The server analyzes the abnormal access result and produces alarm.The above method can improve network security policy detection efficiency, and automatically update detection rule.

Description

Technical Field

[0001] This application relates to the field of network technology in financial technology (Fintech), and more particularly to a method and apparatus for detecting intranet security policies. Background Technology

[0002] In recent years, with the development of computer technology, more and more technologies are being applied in the financial sector, and the traditional financial industry is gradually transforming into Fintech. However, due to the security and real-time requirements of the financial industry, higher demands are being placed on technology. In particular, the diversity of network connection methods, wide distribution of terminals, and the openness and interconnectivity of networks, which have emerged during the development of computers, make networks vulnerable to malicious attacks. Since the financial industry has extremely high security requirements, network security is a crucial issue. Therefore, network security strategies, as a fundamental security protection measure at the network layer, play a protective role for information within the network.

[0003] During the process of enterprise informatization construction, information security issues have gradually become prominent. By dividing different network areas for isolation and protection, network access control is required between different network areas and even between different ports in the same network area. This leads to an increasing number of network security policies that are difficult to organize effectively. This may cause performance bottlenecks in firewalls or other network security devices. From the perspective of upper-layer applications, it is also difficult to clearly depict the calling relationships between different business applications, making it difficult to quickly locate problems based on network calling relationships when problems occur.

[0004] To address the aforementioned issues, existing technologies involve configuring port scanners and corresponding detection rules on the client side to obtain connection information between the client's port and other ports. This connection information is then used to analyze the effectiveness of network security policies. However, this method suffers from the inability of port scanners to coordinate with each other. Therefore, manual acquisition and analysis of connection information from each port scanner are required, and redeployment is necessary whenever detection rules change. Consequently, this approach results in low detection efficiency and significant difficulty in modifying detection rules.

[0005] Therefore, there is an urgent need for an intranet security policy detection method and device to improve the efficiency of network security policy detection and automatically update detection rules. Summary of the Invention

[0006] This invention provides a method and apparatus for detecting intranet security policies, which improves the efficiency of network security policy detection and automatically updates detection rules.

[0007] In a first aspect, embodiments of the present invention provide an intranet security policy detection method, the method comprising:

[0008] The intranet security policy detection system includes at least one client and one server. The at least one client belongs to at least one network area in the intranet. The method includes: the client generating a rule retrieval request and sending the rule retrieval request to the server; the server determining the detection rule for the client based on the rule retrieval request and sending the detection rule to the client, the detection rule being used to indicate the access permissions between the client and the target terminal; the client accessing the target terminal in the detection rule and sending abnormal access results that do not conform to the detection rule to the server; the server analyzing the abnormal access results and generating an alarm.

[0009] In the methods described above, network security policies are generally the same within the same network area. Therefore, one client (or multiple clients if network resources allow, but this is just an optimal implementation) can be selected for each network area to detect network security policies. Multiple network areas correspond to multiple clients, and these clients can communicate with the server. In this way, the client can obtain detection rules from the server through rule retrieval requests, enabling automatic updates to the detection rules and reducing the difficulty of changing them. The client can also send the detected abnormal access results to the server, allowing the server to analyze the abnormal access results reported by each client and determine whether the network security policy for the corresponding network area is effective.

[0010] Optionally, the server analyzes the abnormal access result and generates an alarm, including: the server determines whether the abnormal access result conforms to the network security policy in the whitelist; if it does not conform, an alarm is generated based on the abnormal access result.

[0011] In the above method, a whitelist refers to a network area where all clients have the same detection rules, but there is one exception client whose detection rules differ from those of other clients in the network area. For example, all clients in the network area may not allow clients from other network areas to access port 8080, but this exception client may allow clients from other network areas to access port 8080. However, it's unnecessary to set up two clients with different detection rules within a single network area, wasting resources. Therefore, the detection rules for this exception client are added to the whitelist. If a client from another network area connects to the exception client's port 8080, this is considered normal, and the record of this abnormal access result is deleted without generating an alert. This saves network resources and improves the targeting of network security policies. The server receives and analyzes abnormal access results reported by the client and issues alerts. Compared with existing technologies that use open-source tools such as port scanners (e.g., nmap (Network Mapper, a network security auditing tool)) to detect network security policies, which require manual intervention to integrate and analyze abnormal access results from different network areas, this application can analyze and issue alerts based on the abnormal access results received by the server from each client, thereby improving detection efficiency.

[0012] Optionally, the server determines whether the abnormal access result conforms to the network security policy in the whitelist, including: the server determines whether the source IP address, target IP address, and target port in the abnormal access result belong to the preset source IP address, preset target IP address, and preset target port in the network security policy; if at least one of them does not conform, the abnormal access result is determined to not conform to the network security policy.

[0013] In the above method, the client's access information can be determined based on the source IP address, destination IP address, and destination port in the abnormal access results. The preset source IP address, preset destination IP address, and preset destination port in the network security policy are the rule information in the detection rules. Thus, if the client's actual access information differs from the rule information, the network security policy is likely flawed. Therefore, the server will subsequently generate an alert, allowing relevant developers to be aware of the network security policy anomaly and quickly locate the anomaly and its root cause based on the access information.

[0014] Optionally, the rule retrieval request includes the client's IP address and the first signature generated by the client; the server determines the detection rule for the client based on the rule retrieval request, including: the server verifies the first signature in the rule retrieval request, and after successful verification, determines the detection rule for the client based on the client's IP address.

[0015] In the above method, the service unit verifies the first signature in the rule retrieval request. This improves the security of the detection process and prevents unauthorized personnel from obtaining the detection rules and launching attacks on network areas based on them.

[0016] Optionally, the rule retrieval request further includes a timestamp; the first signature is generated as follows: the client concatenates the client's IP address, the timestamp, and the client's authorization information to obtain ordered concatenated data; the client encrypts the ordered concatenated data using a preset encryption algorithm to obtain the first signature; the server verifies the first signature in the rule retrieval request, including: the server encrypts the client's IP address, the timestamp, and the server's authorization information in the rule retrieval request according to the preset encryption algorithm to obtain a second signature; the client's authorization information is the same as the server's authorization information; if the server determines that the first signature and the second signature are the same, then the client is deemed legitimate upon verification.

[0017] In the above method, the client's authorization information is set to be the same as the server's authorization information, ensuring that the first signature generated for verification is the same. This grants the server and client a communication 'permission', allowing the server to verify the client based on the same authorization information. If the authorization information is the same, the resulting first signature and second signature are also the same, thus the client can be deemed legitimate, and detection rules can be provided for that client. This improves the security of server-client interaction.

[0018] Optionally, it also includes: the server receiving a detection rule update instruction, and updating the detection rule and / or the network security policy according to the detection rule update instruction.

[0019] In the above method, the server can update the detection rules via a rule update command, enabling the client to obtain the latest detection rules. Compared to existing technologies that deploy detection rules separately on open-source tools such as port scanners (e.g., nmap (Network Mapper, a network security auditing tool)), this application allows the client to actively download the latest detection rules simply by deploying and updating the detection rules on the server side. This reduces the complexity of updating detection rules, improves the timeliness of updates, and further enhances the accuracy of network security policy detection.

[0020] Secondly, embodiments of the present invention provide an intranet security policy detection method, the method comprising:

[0021] The intranet security policy detection system includes at least one client and one server. The at least one client belongs to at least one network area in the intranet. The method includes: the client generating a rule retrieval request and sending the rule retrieval request to the server; the client receiving a detection rule determined by the server based on the rule retrieval request; the detection rule indicating the access permissions between the client and the target terminal; the client accessing the target terminal in the detection rule and sending an abnormal access result that does not conform to the detection rule to the server; the abnormal access result being analyzed by the server to generate an alarm.

[0022] In the above method, the client can generate a rule retrieval request to actively obtain the client's detection rules from the server. The client can then perform network security policy detection based on the obtained detection rules. This achieves automatic updating of client-side detection rules. Compared to existing technologies where clients need to manually update detection rules, this application improves the timeliness of detection rule updates and reduces the cost of updating detection rules. The detection rules include access permissions indicating the relationship between the client and the target endpoint. Thus, when the client accesses the target endpoint specified in the detection rules, access information can be obtained during this process to determine whether the access between the client and the target endpoint in the detection information conforms to the access permissions specified in the detection rules.

[0023] Thirdly, embodiments of the present invention provide an intranet security policy detection method, the method comprising:

[0024] The intranet security policy detection system includes at least one client and one server. The at least one client belongs to at least one network area in the intranet. The method includes: the server receiving a rule retrieval request sent by the client and determining the detection rule for the client based on the rule retrieval request; the server sending the detection rule to the client, the detection rule being used to indicate the access permissions between the client and the target terminal; the server receiving an abnormal access result sent by the client, the abnormal access result being determined by the client based on the target terminal that does not conform to the detection rule; and the server analyzing the abnormal access result and generating an alarm.

[0025] In the above method, the server can send corresponding detection rules to the client based on the rule retrieval request sent by the client, thereby automatically updating the detection rules and improving the efficiency of rule updates. Furthermore, the server can analyze the anomaly results sent by the client and generate alerts, facilitating developers in locating the root cause of anomalies and improving the accuracy of anomaly identification and operational efficiency.

[0026] Fourthly, embodiments of the present invention provide an intranet security policy detection device, the device comprising: an intranet security policy detection system including at least one client and one server, wherein the at least one client belongs to at least one network area in the intranet, the device comprising: a transceiver module, configured to generate a rule acquisition request and send the rule acquisition request to the server; the transceiver module is further configured to determine a detection rule for the client according to the rule acquisition request and send the detection rule to the client, the detection rule being used to indicate the access permissions between the client and a target terminal; a detection module, configured to access the target terminal in the detection rule and send abnormal access results that do not conform to the detection rule to the server; and an alarm module, configured to analyze the abnormal access results and generate an alarm.

[0027] Fifthly, embodiments of the present invention provide an intranet security policy detection device, the device comprising: an intranet security policy detection system including at least one client and a server, wherein the at least one client belongs to at least one network area in the intranet, the device comprising: a transceiver module, configured to generate a rule acquisition request and send the rule acquisition request to the server; the transceiver module is further configured to receive a detection rule determined by the server according to the rule acquisition request; the detection rule is used to indicate the access permissions between the client and the target terminal; a detection module, configured to access the target terminal in the detection rule and send abnormal access results that do not conform to the detection rule to the server; the abnormal access results are used by the server to generate an alarm after analysis.

[0028] Sixthly, embodiments of the present invention provide an intranet security policy detection device, the device comprising: an intranet security policy detection system including at least one client and one server, wherein the at least one client belongs to at least one network area in the intranet, the device comprising: a transceiver module, configured to receive a rule acquisition request sent by the client, and determine a detection rule for the client according to the rule acquisition request; the transceiver module is further configured to send the detection rule to the client, the detection rule being used to indicate the access permissions between the client and the target terminal; receive an abnormal access result sent by the client, the abnormal access result being determined by the client based on the target terminal that does not conform to the detection rule; and an alarm module, configured to analyze the abnormal access result and generate an alarm.

[0029] In a seventh aspect, embodiments of this application also provide a computing device, including: a memory for storing a program; and a processor for calling the program stored in the memory and executing the method described in various possible designs as described in the first, second, and third aspects according to the obtained program.

[0030] Eighthly, embodiments of this application also provide a computer-readable non-volatile storage medium including a computer-readable program that, when read and executed by a computer, causes the computer to perform the methods described in various possible designs of the first, second, and third aspects.

[0031] These or other implementations of this application will become clearer and easier to understand in the following description of the embodiments. Attached Figure Description

[0032] 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.

[0033] Figure 1 A schematic diagram of an architecture for detecting intranet security policies provided in an embodiment of the present invention;

[0034] Figure 2a A client provided in an embodiment of the present invention;

[0035] Figure 2b A server provided in an embodiment of the present invention;

[0036] Figure 3 A flowchart illustrating an intranet security policy detection method provided in an embodiment of the present invention;

[0037] Figure 4 A flowchart illustrating a method for matching whitelists and abnormal access results provided in an embodiment of the present invention;

[0038] Figure 5 A flowchart illustrating an intranet security policy detection method provided in an embodiment of the present invention;

[0039] Figure 6 A schematic diagram of an intranet security policy detection device provided in an embodiment of the present invention;

[0040] Figure 7 A schematic diagram of an intranet security policy detection device provided in an embodiment of the present invention;

[0041] Figure 8 This is a schematic diagram of an intranet security policy detection device provided in an embodiment of the present invention. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0043] Figure 1 This invention provides a system architecture for intranet security policy detection, applicable to intranet network security detection in any enterprise or organization. The intranet can include multiple network zones, such as network zone 1, network zone 2, ..., network zone n. Each network zone can have its own network security policy set. There can also be network zones without network security policies (network zones without network security policies do not require network security policy detection). Specific configuration schemes are not limited. Taking setting a network security policy in each network zone as an example, a client is selected in each of network zones 1, 2, ..., n. (Generally, clients in the same network zone have the same network security policy. To save network resources, one client can be selected for network security policy detection in each network zone; if network resources are sufficient, multiple clients can be set for one network zone, or one or more clients can be selected in a network zone based on the network security policy deployment and requirements). Developers can configure detection rules and whitelists on the front-end page of server 1. Then, the client sends a generated rule retrieval request to server 1. Server 1 determines the corresponding detection rule for the client based on the rule retrieval request and sends the detection rule to the client. The client accesses the target endpoints specified in the detection rules, obtains access information for each endpoint, and sends any abnormal access results that do not conform to the detection rules to server 1. Server 1 receives the abnormal access results, analyzes them against a whitelist, deletes the abnormal access results corresponding to the whitelist, and generates an alert based on the remaining abnormal access results. This alert can be sent to developers via email or SMS, enabling them to promptly identify anomalies in network security policies, accelerate root cause localization, and improve operational efficiency.

[0044] Based on the above Figure 1 The system architecture in, such as Figure 2aAs shown in the illustration, this application provides a client that includes a rule acquisition module and a detection module. The rule acquisition module generates a rule acquisition request and sends it to server 1. After receiving the detection rules returned by server 1, the client accesses the target endpoints in the detection rules through the detection module, obtains abnormal access results, and sends the abnormal access results back to server 1 through the detection module.

[0045] Based on the above Figure 1 The system architecture in, such as Figure 2b As shown in the illustration, this application provides a server-side component 1, which includes a detection rule module, a result processing module, and an alarm module. The detection rule module updates the detection rules and / or network security policies, as well as the whitelist, according to detection rule update instructions or whitelist update instructions. It also determines the corresponding detection rule based on a received rule retrieval request from a client and sends the detection rule to the client. The result processing module receives abnormal access results from the client, deletes the abnormal access results corresponding to the whitelist, and generates alarms based on the remaining abnormal access results through the alarm module. It should be noted that the above-described system architecture, client, and server for intranet security policy detection are merely examples of this application and do not limit the specific systems and devices on which the implementations of this application are based.

[0046] Based on the above system architecture and equipment, this application embodiment provides a method flow for detecting intranet security policies, such as... Figure 3 As shown, it includes:

[0047] Step 301: The client generates a rule retrieval request and sends the rule retrieval request to the server;

[0048] Here, the client can be a personal computer, a server host, or other device; there is no specific limitation on the type of device.

[0049] Step 302: The server obtains the request according to the rule, determines the detection rule of the client, and sends the detection rule to the client. The detection rule is used to indicate the access permissions between the client and the target.

[0050] Here, access permissions can refer to whether the client should be able to communicate with the target.

[0051] Step 303: The client accesses the target terminal in the detection rules and sends the abnormal access result that does not conform to the detection rules to the server.

[0052] For example, in the detection rules, the client and target should not have access permissions. However, if the client and target do have access, it can be determined that the network security policy of the network area where the client is located has a vulnerability, and an abnormal access result will be generated.

[0053] Step 304: The server analyzes the abnormal access results and generates an alarm.

[0054] In the methods described above, network security policies are generally the same within the same network area. Therefore, one client (or multiple clients if network resources allow, but this is just an optimal implementation) can be selected for each network area to detect network security policies; multiple network areas correspond to multiple clients, and these clients can communicate with the server. In this way, the client can obtain detection rules from the server through rule retrieval requests, enabling automatic updates to the detection rules and reducing the difficulty of changing them. The client can also send the detected abnormal access results to the server, allowing the server to analyze the abnormal access results reported by each client and determine whether the network security policy for the corresponding network area is effective.

[0055] This application provides a method for analyzing abnormal access results. The server analyzes the abnormal access results and generates alarms, including: the server determining whether the abnormal access result conforms to a network security policy in a whitelist; if it does not conform, an alarm is generated based on the abnormal access result. In other words, the server contains a whitelist. If the abnormal access result contains matching information in the whitelist, i.e., it is determined that the abnormal access result does not belong to a network security policy abnormality but to a network security policy in the whitelist, then the matching abnormal access result is deleted without generating an alarm. Alarms are generated only for abnormal access results that do not conform to the whitelist.

[0056] This application provides an abnormal access result analysis method. The server determines whether the abnormal access result conforms to the network security policy in the whitelist, including: the server determines whether the source IP address, target IP address and target port in the abnormal access result belong to the preset source IP address, preset target IP address and preset target port in the network security policy; if at least one does not conform, the abnormal access result is determined to not conform to the network security policy.

[0057] In other words, when a client accesses a target endpoint according to the detection rules, the obtained access information includes the client's IP address (source IP address), as well as the target endpoint's IP address and port. If this access information is abnormal, it is recorded as an abnormal access result and sent to the server. The server's whitelist contains network security policies, which include preset source IP addresses, preset target IP addresses, and preset target ports. If the source IP address, target IP address, and target port in the abnormal access result completely match the preset source IP address, target IP address, and target port in the network security policy, then the abnormal access result is considered to be non-abnormal and is deleted.

[0058] In one example, network zone 1 has an IP address range of 192.168.124.0 / 24, the client's IP address is 192.168.124.20, network zone 2 has an IP address range of 192.168.125.0 / 24, and the server's whitelist network security policy includes a preset source IP address of all IP addresses in the internal network (0.0.0.0 / 0), a preset target IP address of 192.168.125.20, and a preset target port of 8080. The detection rule obtained by the client in network zone 1 is: all IP addresses in the internal network can access ports 80 and 443 of the IP address range 192.168.125.0 / 24, while other ports are not allowed. That is, when the client sends a rule retrieval request to the server, the data returned by the server is:

[0059] {“rules”:{

[0060] "id":"1", --(Detection rule identifier, 1)

[0061] "src_ip": "0.0.0.0 / 0", --(The source IP address is any IP address within this internal network)

[0062] "dst_ip":"192.168.125.0 / 24",--(The target IP address is all IP addresses in network zone 2)

[0063] "open_ports": "80,443", -- (All devices in network zone 2 have open ports 80 and 443)

[0064] }}

[0065] In other words, the network security policy is: devices in network zone 2 cannot be accessed by devices in other network zones to ports other than 80 and 443. However, there is one device in network zone 2 that has requested an exception. The IP address of this device is 192.168.125.20 and it needs to be accessed by devices in other network zones to port 8080.

[0066] The client determines whether its own IP address exists in the source IP address list of detection rule 1 based on the obtained detection rule 1. If not, the client needs to check the default 65535 ports, i.e., all ports. (If the client's own IP address does not exist in the source IP address list of detection rule 1, the network security policy does not allow the client to access any port in network zone 2; therefore, the client needs to try to connect to all ports in network zone 2 to achieve the detection purpose. If the client can connect to a port in network zone 2 that is not accessible, then the network security policy in network zone 1 and / or network zone 2 is abnormal, and an abnormal access result needs to be generated.) If the client determines that its own IP address exists in the source IP address list of detection rule 1, then ports 80 and 443 in network zone 2 are deleted from the port list (in one possibility, ports that the client can connect to do not need to be tried), and the client attempts to connect to the remaining 65533 ports in the port list other than 80 and 443 to achieve the purpose of detecting the network security policy. If the client successfully establishes a connection with ports 90 and 8080 of IP address 192.168.125.20 in network zone 2, two abnormal access results will be generated, each containing: source IP address 192.168.124.20, destination IP address 192.168.125.20, destination port 90, and source IP address 192.168.124.20, destination IP address 192.168.125.20, destination port 8080. The client sends the abnormal access result to the server. After receiving the abnormal access result, the server matches the two abnormal access results with the whitelist. If the abnormal access result with source IP address 192.168.124.20, destination IP address 192.168.125.20, and destination port 8080 is found to be consistent with the network security policy of the whitelist, which includes the preset source IP address as all IP addresses in the internal network (0.0.0.0 / 0), the preset destination IP address (192.168.125.20), and the preset destination port (8080), then the abnormal access result is deleted, and an alarm is generated based on the remaining abnormal access results.

[0067] This application provides a method for matching abnormal access results with a whitelist:

[0068] The server determines whether the source IP address in the abnormal access result belongs to the preset source IP address in the network security policy. If it does not belong to the preset source IP address, the server obtains the next abnormal access result.

[0069] If it does, the server determines whether the destination IP address in the abnormal access result belongs to the preset destination IP address in the network security policy. If it does not, the server obtains the next abnormal access result.

[0070] If it does, the server determines whether the destination port in the abnormal access result belongs to the preset destination port in the network security policy. If it does not, the server obtains the next abnormal access result.

[0071] If the result is found to be an abnormal access result, it is deleted. Finally, the remaining abnormal access results are retrieved, and an alarm is generated for each remaining abnormal access result. The server can match abnormal access results in the order in which they are received, with the earlier received abnormal access results being matched first. However, this method of determining the matching order is only one possible design and does not limit the specific matching order.

[0072] Based on the above examples and methods, this application provides an example of a method flow for matching abnormal access results with a whitelist, such as... Figure 4 As shown: Step 401, obtain abnormal access results by iterating through the whitelist list and obtaining the corresponding whitelist data. For example, obtain the abnormal access results for source IP address 192.168.124.20, target IP address 192.168.125.20, and target port 8080. The first whitelist entry is: {"white_list_src_ip":"0.0.0.0 / 0","white_list_dst_ip":"192.168.125.20","open_ports":"8080"};

[0073] Step 402: Determine if the source IP address (src_ip) of the abnormal access result is in the whitelist of source IP addresses (white_list_src_ip). If not, return to step 401 to retrieve the next entry in the whitelist. If it is, proceed to step 403 to continue the process.

[0074] Step 403: Determine if dst_ip is equal to white_list_dst_ip; if they are not equal, return to step 401 to retrieve the next whitelist entry. If they are equal, proceed to step 404 to continue the determination.

[0075] Step 404: Determine if the port is in open_ports; if not, return to step 401 to retrieve the next whitelist data. If it is, it means the abnormal access result is in the whitelist, delete the abnormal access result, and return to step 401 to retrieve the next abnormal access result data. In this example, the abnormal access result is in the whitelist, so the abnormal access result is deleted. Step 401: If there are still unmatched abnormal access results, retrieve the abnormal access results, iterate through the whitelist list, and retrieve the corresponding whitelist data. As in the example above, retrieve the abnormal access results for source IP address 192.168.124.20, target IP address 192.168.125.20, and target port 90. First whitelist: {"white_list_src_ip":"0.0.0.0 / 0","white_list_dst_ip":"192.168.125.20","open_ports":"8080"};

[0076] Step 402: Determine if the source IP address (src_ip) of the abnormal access result is in the whitelist of source IP addresses (white_list_src_ip). If not, return to step 401 to retrieve the next entry in the whitelist. If it is, proceed to step 403 to continue the process.

[0077] Step 403: Determine if dst_ip is equal to white_list_dst_ip; if they are not equal, return to step 401 to retrieve the next whitelist entry. If they are equal, proceed to step 404 to continue the determination.

[0078] Step 404: Determine if the port is in open_ports; if not, return to step 401 to retrieve the next whitelist data. If it is, it means the abnormal access result is in the whitelist; delete the abnormal access result and return to step 401 to retrieve the next abnormal access result data. In this example, the abnormal access result is not in the whitelist, so the abnormal access result is retained.

[0079] Step 405: After iterating through all abnormal access results, the remaining abnormal access results are the data to be alerted. The server generates an alert based on the remaining abnormal access results. In the example above, the abnormal access result with a destination port of 90 does not match the network security policy in the whitelist. After iterating through all abnormal access results, the final list contains the following abnormal access results: source IP address 192.168.124.20, destination IP address 192.168.125.20, destination port 90; an alert is generated for this abnormal access result. It should be noted that the matching order of the above abnormal access results with the source IP address, destination IP address, and destination port in the whitelist and the preset source IP address, preset destination IP address, and preset destination port can be based on the preset source IP address, preset destination IP address, and preset destination port order in the whitelist, or it can be based on the source IP address, destination IP address, and destination port in the abnormal access results. The matching order of the abnormal access results and the data in the whitelist can be set as needed and is not limited.

[0080] This application provides a method for verifying a rule retrieval request. The rule retrieval request includes the client's IP address and a first signature generated by the client. The server determines the detection rule for the client based on the rule retrieval request, including: the server verifies the first signature in the rule retrieval request; if the verification is successful, the server determines the detection rule for the client based on the client's IP address. In other words, the rule retrieval request may contain a first signature, allowing the server to obtain and verify the first signature. If the first signature is valid, the client sending the rule retrieval request is considered a legitimate client.

[0081] This application provides a method for verifying a rule retrieval request. The rule retrieval request further includes a timestamp. The first signature is generated as follows: the client concatenates its IP address, the timestamp, and its authorization information to obtain ordered concatenated data; the client encrypts the ordered concatenated data using a preset encryption algorithm to obtain the first signature; the server verifies the first signature in the rule retrieval request, including: the server encrypts the client's IP address, the timestamp, and the server's authorization information in the rule retrieval request using the preset encryption algorithm to obtain a second signature; the client's authorization information is the same as the server's authorization information; if the server determines that the first signature and the second signature are the same, then the client is verified as legitimate. Specifically, the client concatenates its IP address, timestamp, and authorization information to obtain ordered concatenated data, and then further encrypts this ordered concatenated data using a preset encryption algorithm to obtain the first signature. For example, the preset encryption algorithm could be an MD5 message digest algorithm or a hash algorithm. If the client's authorization information and the server's authorization information are the same, then the client's first signature and the server's second signature are both obtained by concatenating the client's IP address, timestamp, and authorization information, and then encrypting them using a preset encryption algorithm. In this case, the first and second signatures are identical, verification passes, and the client is a legitimate client. Conversely, if the client's authorization information and the server's authorization information are different, then the first and second signatures are different, verification fails, and the client is an illegitimate client.

[0082] This application provides a rule update method comprising: the server receiving a detection rule update instruction, and updating the detection rule and / or the network security policy according to the detection rule update instruction. In other words, the server can provide external interfaces such as front-end pages, allowing developers to input detection rules, network security policies, whitelists, and other related configuration information at corresponding locations. The server then generates a detection rule update instruction based on the configuration information input by the developer, updating the detection rule, network security policy, and whitelist accordingly.

[0083] based on Figure 1 System architecture, Figure 2a , Figure 2b , Figure 3 Client and server, including Figure 4 The present application provides a method flow for detecting intranet security policies, such as... Figure 5 As shown, it includes:

[0084] Step 501: The server receives the detection rule update instruction and updates the detection rules and / or network security policies and / or whitelists according to the instruction. In one example, the user can configure the detection rules, network security policy rules, and whitelists based on the enterprise's network architecture through the server's front-end page. The server generates the detection rule update instruction based on the configuration information entered by the user on the front-end page and updates the detection rules and / or network security policies and / or whitelists. In the above example, the updated detection rule 1 is: Devices in network zone 2 are allowed to access ports 80 and 443 from devices in other network zones within the enterprise's intranet; other ports in network zone 2 are not allowed to be accessed. That is, source IP address: "0.0.0.0 / 0"; destination IP address: "192.168.125.0 / 24"; open ports: "80, 443". The updated network security policy in the server-side whitelist includes: a preset source IP address of all IP addresses within the intranet (0.0.0.0 / 0), a preset destination IP address of 192.168.125.20, and a preset destination port of 8080. It's important to note that this network security policy includes both the network security policies deployed in each network zone within the intranet and the preset network security policies in the whitelist. This example only demonstrates updating the preset network security policies in the whitelist; it does not restrict the specific update process for the network security policies deployed in each network zone within the intranet. That is, clients can also obtain the network security policies for the corresponding network zone from the server using the same method.

[0085] Step 502: The client concatenates its own IP address, current timestamp, and authorization information, generates a first signature using a preset encryption algorithm, and further generates a rule retrieval request containing its own IP address, current timestamp, and first signature. Here, the authorization information can be what was configured for the client when it joined the network area; the authorization information can be a key value; and the preset encryption algorithm can be the MD5 algorithm.

[0086] Step 503: The client sends a rule retrieval request to the server.

[0087] Step 504: After obtaining the rule retrieval request, the server extracts the client IP address and current timestamp from the request, and obtains its own authorization information. It then concatenates the client IP address, current timestamp, and authorization information, generates a second signature using a preset encryption algorithm, and compares the first and second signatures. If they match, the client corresponding to the rule retrieval request is legitimate. Here, the server's preset encryption algorithm and the client's preset encryption algorithm are the same.

[0088] Step 505: The server obtains the client's IP address from the rule retrieval request, generates the corresponding query statement, and retrieves the detection rules from the database.

[0089] Step 506: The server returns the detection rules to the client that initiated the rule retrieval request.

[0090] Step 507: The client receives the detection rules and generates a detection list based on them, then establishes socket connections with the target ports in the detection list sequentially. In the example above, the detection list generated according to detection rule 1 is as follows:

[0091] {192.168.125.1:1,

[0092] 192.168.125.1:2,

[0093] …

[0094] 192.168.125.24:65535}. This does not include ports 80 and 443.

[0095] Step 508: The client generates abnormal access results based on the access information that does not conform to the detection rules. In the example above, the client successfully established a connection with ports 90 and 8080 of IP address 192.168.125.20 in network zone 2, generating two abnormal access results: source IP address 192.168.124.20, destination IP address 192.168.125.20, destination port 90, and source IP address 192.168.124.20, destination IP address 192.168.125.20, destination port 8080.

[0096] Step 509: The client sends the abnormal access result to the server.

[0097] Step 510: The server determines abnormal access results that do not conform to the whitelist based on the whitelist. In the example above, the two abnormal access results are matched with the whitelist data: preset source IP address (all IP addresses 0.0.0.0 / 0), preset destination IP address (192.168.125.20), and preset destination port (8080).

[0098] Step 511: The server generates an alarm based on abnormal access results that do not conform to the whitelist.

[0099] It should be noted that the above method flow is not unique; for example, step 502 can be executed before step 501.

[0100] Based on the same concept, embodiments of the present invention provide an apparatus for detecting intranet security policies. Figure 6A schematic diagram of an intranet security policy detection device provided in an embodiment of this application is shown below. Figure 6 The following are examples:

[0101] The intranet security policy detection system includes at least one client and one server, wherein the at least one client belongs to at least one network zone within the intranet, and the device includes:

[0102] The transceiver module 601 is used to generate a rule retrieval request and send the rule retrieval request to the server.

[0103] The transceiver module 601 is further configured to obtain a request according to the rule, determine the detection rule of the client, and send the detection rule to the client, wherein the detection rule is used to indicate the access permissions between the client and the target terminal;

[0104] Processing module 602 is used to access the target end in the detection rules and send abnormal access results that do not conform to the detection rules to the server.

[0105] The processing module 602 is also used to analyze the abnormal access results and generate an alarm.

[0106] Optionally, the processing module 602 is specifically used to: determine whether the abnormal access result conforms to the network security policy in the whitelist; if it does not conform, generate an alarm based on the abnormal access result.

[0107] Optionally, the processing module 602 is specifically used to: determine whether the source IP address, target IP address, and target port in the abnormal access result belong to the preset source IP address, preset target IP address, and preset target port in the network security policy; if at least one of them does not conform, then determine that the abnormal access result does not conform to the network security policy.

[0108] Optionally, the rule acquisition request includes the client's IP address and the first signature generated by the client; the transceiver module 601 is specifically used to: verify the first signature in the rule acquisition request, and after successful verification, determine the client's detection rule based on the client's IP address.

[0109] Optionally, the rule acquisition request also includes a timestamp; the first signature is generated in the following way: the transceiver module 601 is specifically used to: concatenate the client's IP address, the timestamp, and the client's authorization information to obtain ordered concatenated data;

[0110] The client encrypts the ordered concatenated data using a preset encryption algorithm to obtain the first signature; the transceiver module 601 is specifically used to: encrypt the client's IP address, the timestamp, and the server's authorization information in the rule acquisition request according to the preset encryption algorithm to obtain the second signature; the client's authorization information is the same as the server's authorization information; if it is determined that the first signature and the second signature are the same, then the client is verified to be legitimate.

[0111] Optionally, the processing module 602 is further configured to: receive a detection rule update instruction, and update the detection rule and / or the network security policy according to the detection rule update instruction.

[0112] Based on the same concept, embodiments of the present invention provide an apparatus for detecting intranet security policies. Figure 7 A schematic diagram of an intranet security policy detection device provided in an embodiment of this application is shown below. Figure 7 The following are examples:

[0113] The intranet security policy detection system includes at least one client and one server, wherein the at least one client belongs to at least one network zone within the intranet, and the device includes:

[0114] The transceiver module 701 is used to generate a rule retrieval request and send the rule retrieval request to the server.

[0115] The transceiver module 701 is further configured to receive the detection rules determined by the server according to the rule acquisition request; the detection rules are used to indicate the access permissions between the client and the target.

[0116] The detection module 702 is used to access the target end in the detection rules and send the abnormal access results that do not conform to the detection rules to the server; the abnormal access results are used by the server to generate an alarm after analysis.

[0117] Based on the same concept, embodiments of the present invention provide an apparatus for detecting intranet security policies. Figure 8 A schematic diagram of an intranet security policy detection device provided in an embodiment of this application is shown below. Figure 8 The following are examples:

[0118] The intranet security policy detection system includes at least one client and one server, wherein the at least one client belongs to at least one network zone within the intranet, and the device includes:

[0119] The transceiver module 801 is used to receive the rule acquisition request sent by the client, and determine the detection rules of the client according to the rule acquisition request;

[0120] The transceiver module 801 is further configured to: send the detection rule to the client, the detection rule being used to indicate the access permissions between the client and the target terminal; and receive an abnormal access result sent by the client, the abnormal access result being determined by the client based on the target terminal that does not conform to the detection rule;

[0121] The alarm module 802 is used to analyze the abnormal access results and generate alarms.

[0122] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0123] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0124] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0125] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0126] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for detecting intranet security policies, characterized in that, The intranet security policy detection system includes at least one client and one server, wherein the at least one client belongs to at least one network zone within the intranet, and the method includes: The client generates a rule retrieval request and sends the rule retrieval request to the server; The server obtains the request according to the rules, determines the detection rules for the client, and sends the detection rules to the client. The detection rules are used to indicate the access permissions between the client and the target. The client accesses the target terminal in the detection rules and sends the abnormal access results that do not conform to the detection rules to the server. The server analyzes the abnormal access results and generates an alert. The server obtains requests based on the rules and determines the detection rules for the client, including: The server determines the detection rules for the client based on the client's IP address.

2. The method as described in claim 1, characterized in that, The server analyzes the abnormal access results and generates an alarm, including: The server determines whether the abnormal access result conforms to the network security policy in the whitelist. If the condition is not met, an alarm will be generated based on the abnormal access result.

3. The method as described in claim 2, characterized in that, The server determines whether the abnormal access result conforms to the network security policy in the whitelist, including: The server determines whether the source IP address, target IP address, and target port in the abnormal access result belong to the preset source IP address, preset target IP address, and preset target port in the network security policy; If at least one of the conditions is not met, the abnormal access result is determined to be inconsistent with the network security policy.

4. The method as described in claim 1, characterized in that, The rule retrieval request includes the client's IP address and the first signature generated by the client; The server obtains requests based on the rules and determines the detection rules for the client, including: The server verifies the first signature in the rule acquisition request, and after successful verification, determines the detection rule for the client based on the client's IP address.

5. The method as described in claim 4, characterized in that, The rule retrieval request also includes a timestamp; The first signature is generated in the following way: The client concatenates the client's IP address, the timestamp, and the client's authorization information to obtain ordered concatenated data; The client encrypts the ordered concatenated data using a preset encryption algorithm to obtain the first signature; The server verifies the first signature in the rule retrieval request, including: The server encrypts the client's IP address, the timestamp, and the server's authorization information in the rule acquisition request according to the preset encryption algorithm to obtain a second signature; the client's authorization information is the same as the server's authorization information. If the server determines that the first signature and the second signature are the same, then the client is deemed legitimate upon verification.

6. The method as described in claim 2 or 3, characterized in that, Also includes: The server receives a detection rule update instruction and updates the detection rules and / or the network security policy according to the detection rule update instruction.

7. A method for detecting intranet security policies, characterized in that, The intranet security policy detection system includes at least one client and one server, wherein the at least one client belongs to at least one network zone within the intranet, and the method includes: The client generates a rule retrieval request and sends the rule retrieval request to the server; the rule retrieval request includes the client's IP address; the client's IP address is used to instruct the server to determine the client's detection rules based on the client's IP address; The client receives the detection rules determined by the server based on the rule acquisition request; the detection rules are used to indicate the access permissions between the client and the target. The client accesses the target endpoint in the detection rules and sends abnormal access results that do not conform to the detection rules to the server; the abnormal access results are used by the server to generate alarms after analysis.

8. A method for detecting intranet security policies, characterized in that, The intranet security policy detection system includes at least one client and one server, wherein the at least one client belongs to at least one network zone within the intranet, and the method includes: The server receives the rule retrieval request sent by the client and determines the client's detection rules based on the rule retrieval request. The server sends the detection rules to the client, and the detection rules are used to indicate the access permissions between the client and the target. The server receives the abnormal access result sent by the client, and the abnormal access result is determined by the client based on the target terminal that does not conform to the detection rules; The server analyzes the abnormal access results and generates an alarm. The process of obtaining requests based on the rules and determining the detection rules for the client includes: The detection rules for the client are determined based on the client's IP address.

9. An intranet security policy detection device, characterized in that, The intranet security policy detection system includes at least one client and one server, wherein the at least one client belongs to at least one network zone within the intranet, and the device includes: The transceiver module is used to generate a rule retrieval request and send the rule retrieval request to the server. The transceiver module is further configured to obtain a request according to the rules, determine the detection rules of the client, and send the detection rules to the client, wherein the detection rules are used to indicate the access permissions between the client and the target terminal; The detection module is used to access the target end in the detection rules and send abnormal access results that do not conform to the detection rules to the server. The alarm module is used to analyze the abnormal access results and generate alarms; The transceiver module is specifically used to determine the detection rules for the client based on the client's IP address.

10. An intranet security policy detection device, characterized in that, The intranet security policy detection system includes at least one client and one server, wherein the at least one client belongs to at least one network zone within the intranet, and the device includes: A transceiver module is used to generate a rule retrieval request and send the rule retrieval request to the server; the rule retrieval request includes the client's IP address; the client's IP address is used to instruct the server to determine the client's detection rules based on the client's IP address; The transceiver module is further configured to receive the detection rules determined by the server based on the rule acquisition request; the detection rules are used to indicate the access permissions between the client and the target. The detection module is used to access the target end in the detection rules and send abnormal access results that do not conform to the detection rules to the server; the abnormal access results are used by the server to generate alarms after analysis.

11. An intranet security policy detection device, characterized in that, The intranet security policy detection system includes at least one client and one server, wherein the at least one client belongs to at least one network zone within the intranet, and the device includes: The transceiver module is used to receive the rule retrieval request sent by the client, and determine the client's detection rules based on the rule retrieval request; The transceiver module is further configured to: send the detection rule to the client, the detection rule being used to indicate the access permissions between the client and the target terminal; and receive an abnormal access result sent by the client, the abnormal access result being determined by the client based on the target terminal that does not conform to the detection rule; The alarm module is used to analyze the abnormal access results and generate alarms; The transceiver module is specifically used to determine the detection rules for the client based on the client's IP address.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program that, when run on a computer, causes the computer to perform the method of any one of claims 1 to 8.

13. A computer device, characterized in that, include: Memory, used to store computer programs; A processor is configured to invoke a computer program stored in the memory and execute the method as described in any one of claims 1 to 8 according to the obtained program.

Images