Network access request detection method for zero trust network and related device

Abstract

This disclosure presents a method and related equipment for detecting network access requests in a zero-trust network, applicable to the field of network security technology. The method, applied to a zero-trust proxy terminal on a terminal, includes: obtaining first address information corresponding to a target site indicated by a network access request; resolving a DNS request corresponding to the network access request to obtain second address information associated with the first address information; sending the network access request, the first address information, and the second address information to a zero-trust network gateway; and, upon receiving third address information sent by the zero-trust network gateway, determining whether the network access request is abnormal based on the first address information, the second address information, and the third address information; the third address information is the information used by the zero-trust network gateway to send the network access request to the target site based on the first address information and the second address information. This disclosure can detect abnormal requests promptly and accurately, improving the security of network access.

Description

Technical Field

[0001] This disclosure relates to the field of network security technology, and in particular to a method and related equipment for detecting network access requests in a zero-trust network. Background Technology

[0002] During network access, the presence of malicious traffic puts the user in an insecure network environment. However, malicious traffic uses encryption, obfuscation, or transformation to evade security protection detection, making it highly concealed and difficult to detect and remove in a timely manner. Summary of the Invention

[0003] This disclosure provides a method and related equipment for detecting network access requests in a zero-trust network, which can detect abnormal requests in a timely and accurate manner, thereby improving network security access capabilities.

[0004] On one hand, this disclosure provides a method for detecting network access requests in a zero-trust network, applied to a zero-trust network proxy on a terminal. The method includes: Obtain the first address information corresponding to the target site indicated by the network access request; Parse the DNS request corresponding to the network access request to obtain the second address information associated with the first address information; Send the network access request, the first address information, and the second address information to the zero-trust network gateway; Upon receiving the third address information sent by the zero-trust network gateway, the system determines whether the network access request is abnormal based on the first address information, the second address information, and the third address information. The third address information is the address information used by the zero-trust network gateway when sending the network access request to the target site based on the first address information and the second address information.

[0005] In one feasible embodiment, the first address information includes first target IP address information and first domain name information; The step of obtaining the first address information corresponding to the target site indicated by the network access request includes: The protocol stack is used to obtain the first target IP address information corresponding to the target site accessed by the network access request; Determine the Internet protocol type used by the network access request, and obtain the first domain name information corresponding to the target site indicated by the network access request under the corresponding Internet protocol type.

[0006] In one feasible embodiment, obtaining the first target IP address information corresponding to the target site indicated by the network access request through the protocol stack includes one of the following: The network access request is imported into the virtual network interface card and processed by the first protocol stack corresponding to the virtual network interface card to obtain the first target IP address information corresponding to the target site. The network access request is imported into the kernel driver and processed by the second protocol stack corresponding to the kernel driver to obtain the first target IP address information corresponding to the target site.

[0007] In one feasible embodiment, the Internet protocol is either HTTP or HTTPS. The step of obtaining the first domain name information corresponding to the target site indicated by the network access request under the corresponding Internet protocol type includes: If the network access request uses the HTTP protocol, then the Host field in the HTTP request header is parsed to obtain the first domain name information corresponding to the target site; If the network access request uses the HTTPS protocol, the first domain name information corresponding to the target site requested during the handshake phase is determined through the SNI extension.

[0008] In one feasible embodiment, determining the Internet protocol type used by the network access request includes one of the following: The type of Internet protocol used in the network access request is determined by the source port or destination port in the TCP header; The type of Internet protocol used by the network access request is determined by the characteristics of the payload content in the data packet corresponding to the network access request.

[0009] In one feasible embodiment, the second address information includes second domain name information associated with the first target IP address information; The method further includes establishing a first mapping relationship between the first target IP address and the first domain name information, establishing a second mapping relationship between the first target IP address and the second domain name information, and obtaining mapping data corresponding to the network access request based on the first mapping relationship and the second mapping relationship; Sending the network access request, the first address information, and the second address information to the zero-trust network gateway includes: sending the network access request and the mapping data to the zero-trust network gateway; The third address information includes second target IP address information, which is obtained by the zero-trust network gateway through DNS resolution of the third domain name information obtained from the mapping data, or determined by the zero-trust network gateway based on the mapping data.

[0010] In one feasible embodiment, determining whether the network access request is abnormal based on the first address information, the second address information, and the third address information includes one of the following: If the first domain name information is inconsistent with the second domain name information, or if the first target IP address information is inconsistent with the second target IP address information, the network access request is determined to be an abnormal request. If the communication frequency of the network access request exceeds the preset communication frequency, and the first domain name information is inconsistent with the second domain name information, or the first target IP address information is inconsistent with the second target IP address information, then the network access request is determined to be an abnormal request. If a warning message is also received when the third address information is received, the communication frequency of the network access request is counted. If the communication frequency exceeds a preset communication frequency, the network access request is determined to be an abnormal request.

[0011] In one feasible embodiment, determining the communication frequency of the network access request includes: The observation target is determined based on information related to the network access request, including at least one of the following: source IP address, destination IP address, destination port, and communication protocol. The data related to the observed object returned by the zero-trust network gateway is obtained and aggregated based on a preset time window to determine the amount of data in each time window; For each time window, the corresponding communication frequency is determined based on the amount and duration of data within that time window.

[0012] On the other hand, embodiments of this disclosure provide a network access request detection method for a zero-trust network, applied to a zero-trust network gateway, the method comprising: The system receives a network access request, first address information, and second address information sent by a zero-trust network proxy. The first address information includes information corresponding to the network access obtained by the zero-trust network proxy based on the network access request sent by the application in the terminal. The second address information includes DNS information corresponding to the network access request. Based on the first address information and the second address information, a third address information for sending the network access request to the target site is determined; Send the third address information to the zero-trust network proxy, or determine whether the network access request is abnormal based on the first address information, the second address information, and the third address information.

[0013] In one feasible embodiment, the first address information includes first target IP address information and first domain name information; The first target IP address information includes information obtained by the zero-trust network proxy through the protocol stack that corresponds to the target site indicated by the network access request; The first domain name information includes information corresponding to the target site obtained by the zero-trust network proxy based on the Internet protocol used by the network access request.

[0014] In one feasible embodiment, the first target IP address information obtained through the protocol stack includes one of the following: After the zero-trust network proxy imports the network access request into the virtual network interface card, it processes the obtained IP address information through the first protocol stack corresponding to the virtual network interface card. After the zero-trust network proxy imports the network access request into the kernel driver, it processes the obtained IP address information through the second protocol stack corresponding to the kernel driver.

[0015] In one feasible embodiment, the Internet protocol is either HTTP or HTTPS. The first domain name information includes the HTTP protocol used for the network access request, the information obtained by parsing the Host field in the HTTP request header, or the information requested during the handshake phase determined by the SNI extension for the HTTPS protocol used for the network access request. Alternatively, the Internet protocol type used in the network access request may be determined by a preset port number or the characteristics of the payload content in the corresponding data packet.

[0016] In one feasible embodiment, the second address information includes second domain name information associated with the first target IP address information; The first address information and the second address information are sent in the form of mapping data, which includes a first mapping relationship between the first target IP address information and the first domain name information and a second mapping relationship between the first target IP address information and the second domain name information; The third address information includes the second target IP address information, which is obtained by DNS resolution of the third domain name information obtained from the mapping data or determined based on the mapping data.

[0017] In one feasible embodiment, determining whether the network access request is abnormal based on the first address information, the second address information, and the third address information includes one of the following: If the first domain name information is inconsistent with the second domain name information, or if the first target IP address information is inconsistent with the second target IP address information, the network access request is determined to be an abnormal request. If the communication frequency of the network access request exceeds a preset communication frequency, and the first domain name information is inconsistent with the second domain name information, or the first target IP address information is inconsistent with the second target IP address information, then the network access request is determined to be an abnormal request.

[0018] In one feasible embodiment, determining the communication frequency of the network access request includes: The observation target is determined based on information related to the network access request, including at least one of the following: source IP address, destination IP address, destination port, and communication protocol. The data related to the observed object returned by the zero-trust network gateway is obtained and aggregated based on a preset time window to determine the amount of data in each time window; For each time window, the corresponding communication frequency is determined based on the amount and duration of data within that time window.

[0019] In one feasible embodiment, the method further includes at least one of the following: If the network access request is determined to be an abnormal request, the network access request will be blocked. If the first domain name information is inconsistent with the second domain name information, or if the first target IP address information is inconsistent with the second target IP address information, a warning message is sent simultaneously when returning the third address information to the zero-trust network proxy.

[0020] On the other hand, this disclosure provides a network access request detection device for a zero-trust network, applied to a zero-trust network proxy terminal of a terminal, the device comprising: The first acquisition module is used to acquire the first address information corresponding to the target site indicated by the network access request. The second acquisition module is used to parse the DNS request corresponding to the network access request to obtain the second address information associated with the first address information; The sending module is used to send the network access request, the first address information, and the second address information to the zero-trust network gateway; The first receiving module is configured to, upon receiving third address information sent by the zero-trust network gateway, determine whether the network access request is abnormal based on the first address information, the second address information, and the third address information; the third address information is the address information used by the zero-trust network gateway to send the network access request to the target site based on the first address information and the second address information.

[0021] On the other hand, this disclosure provides a network access request detection device for a zero-trust network, applied to a zero-trust network gateway, characterized in that the device includes: The second receiving module is used to receive a network access request, a first address information and a second address information sent by the zero-trust network proxy. The first address information includes information corresponding to the target site indicated by the network access request obtained by the zero-trust network proxy. The second address information includes address information associated with the first address information obtained by the zero-trust network proxy through parsing the DNS request corresponding to the network access request. The forwarding module is used to determine, based on the first address information and the second address information, third address information for sending the network access request to the target site; The processing module is used to send the third address information to the zero-trust network proxy, or to determine whether the network access request is abnormal based on the first address information, the second address information, and the third address information.

[0022] On the other hand, embodiments of this disclosure provide an electronic device including a processor and a memory interconnected thereto; The memory is used to store computer programs; The processor is used to execute the network access request detection method for zero-trust networks provided in this disclosure embodiment when the computer program is invoked.

[0023] On the other hand, embodiments of this disclosure provide a computer-readable storage medium storing a computer program that is executed by a processor to implement the network access request detection method for zero-trust networks provided in embodiments of this disclosure.

[0024] On the other hand, this disclosure provides a computer program product, which includes a computer program that, when executed by a processor, implements the network access request detection method for zero-trust networks provided in this disclosure.

[0025] In this embodiment, the zero-trust network proxy of the terminal can obtain the first address information corresponding to the target site indicated by the network access request, and can also resolve the DNS request corresponding to the network access request to obtain the second address information associated with the first address information. Based on this, the zero-trust network proxy can send the network access request, the first address information, and the second address information to the zero-trust network gateway. The zero-trust network gateway then performs the proxying of the network access request. The zero-trust network gateway can send third address information to the zero-trust network proxy. This third address information is the address information used by the zero-trust network gateway to send the network access request to the target site based on the first and second address information. Upon receiving the third address information, the zero-trust network proxy can determine whether the network access request is abnormal based on the first, second, and third address information. This implementation determines whether a network access request is abnormal by using information obtained by the zero-trust network proxy and the zero-trust gateway during the processing of the network access request. This allows for timely and accurate identification of abnormal network access requests, which is beneficial for improving network access security. Attached Figure Description

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

[0027] Figure 1 This is a system architecture diagram of the network access request detection method provided in the embodiments of this disclosure; Figure 2 This is a schematic diagram illustrating the determination of the mapping relationship between IP addresses and domain names in a network access request detection method provided in this embodiment of the present disclosure; Figure 3 This is a schematic diagram illustrating the determination of the mapping relationship between IP addresses and domain names in another network access request detection method provided in this embodiment of the present disclosure; Figure 4 This is a schematic diagram illustrating the identification of abnormal requests in the network access request detection method provided in this embodiment of the disclosure; Figure 5 This is a schematic diagram of the architecture of a zero-trust network provided in an embodiment of this disclosure; Figure 6 This is a schematic diagram of the zero-trust network access process provided in the embodiments of this disclosure; Figure 7 This is a timing diagram of the network access request detection method for zero-trust networks provided in this embodiment of the disclosure; Figure 8This is a schematic diagram of a network access request detection device for a zero-trust network provided in an embodiment of this disclosure; Figure 9 This is another schematic diagram of the network access request detection device for zero-trust networks provided in this embodiment of the disclosure; Figure 10 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this disclosure. Detailed Implementation

[0028] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this disclosure.

[0029] The term "based on" as used in the various embodiments of this disclosure can be interpreted as meaning that the premises, conditions, or information upon which it is based are not unique, but at least one or a part of them. That is, it indicates that at least one explicit basis exists, and does not exclude other possible basis.

[0030] The following describes the technical content related to the method provided in the embodiments of this disclosure.

[0031] Zero Trust Network: A network security architecture in which no accessing entity or device can be automatically trusted, even within an internal network. Internal threats are considered equally unavoidable, and all objects (such as accessing entities, terminal devices, applications, networks, resources, etc.) should be treated as potentially untrusted entities when accessing resources.

[0032] Trusted Applications: Applications authorized by the management end and accessible to terminals to internal business systems, including application name, application MD5 (Message-Digest Algorithm 5), signature information, etc.

[0033] Reachable Area: The access subject of the terminal can access the list of internal sites set up by the enterprise through the zero-trust network.

[0034] Login credentials: After a user successfully logs into the iOA (Intelligent Office Automation) client (such as a zero-trust network client), the iOA server (or zero-trust network server) assigns an encrypted string to that user, representing their login authorization information, including user information and authorization validity period. This encryption is stored on the client side.

[0035] Network access request credentials: Authorization information issued by the iOA server for a single network access request, used to identify the authorization status of the network access request.

[0036] Zero-trust access control policies consist of information about the processes (such as trusted applications) that an access subject can use, as well as the accessible business sites (reachable areas). With authorized permissions, an access subject can access any reachable area through any trusted application. The granularity of zero-trust access control policies is based on the logged-in access subject, allowing for different zero-trust policies to be formulated for different logged-in access subjects.

[0037] Zero Trust Gateway: Deployed at the entry point of enterprise applications and data resources, it is responsible for verifying and forwarding every session request that accesses enterprise resources.

[0038] Access Proxy: An endpoint access proxy is an endpoint agent deployed on a controlled device to initiate secure access. It is responsible for initiating requests for trusted authentication of the access subject. Once the identity is verified, an encrypted access connection can be established with the access gateway. It is also the point of enforcement of access control policies.

[0039] Direct access: In a zero-trust network access architecture, when an application initiates a network access request to a site, the full traffic proxy (such as a zero-trust network proxy) intercepts the traffic and then initiates a network access to the target site through the full traffic proxy, that is, it initiates a direct connection access. The full traffic proxy then sends the network response from the target site to the application. This access mode is called direct access.

[0040] Proxy access: In a zero-trust network access architecture, when an application initiates a network access request to a site, the full traffic proxy intercepts the traffic and then forwards it to the smart gateway. The smart gateway then proxies the access to the target business site. After the access is completed, the smart gateway sends the network response of the target site to the full traffic proxy, which then forwards the network response of the target site to the application. This access mode is called proxy access.

[0041] Access subject: In the network, the party that initiates the access, the person / device / application that accesses internal network business resources, is a digital entity composed of or combined with factors such as people, devices, and applications.

[0042] Accessed object: In the network, the party being accessed, namely the enterprise's intranet business resources, including applications, systems (development and testing environments, operation and maintenance environments, production environments, etc.), data, interfaces, functions, etc.

[0043] Business modules: A collection of multiple files that perform specific functions. The concept of modules not only provides a clearer description of the product but also makes it easier to specify which modules to install or uninstall. For example, you can specify to install only a "Threat Response" module or an "Application Software Management" module.

[0044] Policy: A set of rules issued by the administrator on the management terminal for enterprise endpoint management. This includes patch fixing, zero-trust network control, and security hardening policies. Policies may contain sensitive information such as tickets, expiration dates, and the number of valid entries.

[0045] Network session: The process by which a user interacts with a business system, such as the sending and receiving of data after a client establishes a network connection with a server. This includes connection establishment and termination, or the sending and receiving of data.

[0046] Access Session: Based on network sessions and containing a set of related characteristics. An access session is an abstract concept that binds a network session to a combination of device, access subject, network attributes, process attributes, and endpoint attributes for each access to enterprise intranet business resources (including business applications, core systems, asset data, functional interfaces, etc.).

[0047] SNI (Server Name Indication): An extension of TLS (Transport Layer Security) that allows clients to specify the hostname (i.e., domain name) of the server they want to connect to during the handshake phase.

[0048] ESNI (Encrypted Server Name Indication): A technology that protects the domain name of a website accessed by a user from being eavesdropped on or tampered with by a man-in-the-middle by encrypting the Server Name Indication (SNI) information during the TLS handshake process.

[0049] High-reputation domains: These are website domains that are generally considered safe and trustworthy, and usually belong to well-known and trusted companies or organizations. Domain fronting, also known as domain spoofing, is a censorship evasion technique primarily used in the HTTPS protocol. It hides the real remote endpoint in communication by using different domain names at different communication layers. HTTPS domain fronting is implemented by using a different, censorship-allowed domain name in the TLS handshake phase. This is achieved because the encryption of HTTPS requests prevents intermediaries from directly viewing the actual target domain (hidden within the encrypted HTTP header) and other request content.

[0050] System calls: These are the interfaces through which applications interact with the operating system kernel to request services provided by the operating system, such as file operations, memory management, and process control.

[0051] Deep packet inspection (DPI) is a powerful network observation and control technology that analyzes the application layer content of network data packets. It is used for internet data mining and internet censorship.

[0052] C2 server: Command and Control server, refers to a server used to remotely control malware, including botnets and ransomware. After infecting and accessing a host device, malware establishes a connection with this type of server to receive commands and control from the attacker.

[0053] Netstack: A user-space protocol stack implementation that can be used to process data packets received from virtual network interface devices.

[0054] In this embodiment of the disclosure, techniques such as deep packet inspection (DPI) or configuring a man-in-the-middle HTTPS proxy are used in related technologies to inspect the traffic of the real remote endpoint in hidden communications. DPI is a powerful network observation and control technology that can analyze the application layer content of network packets for applications such as internet data mining and internet censorship.

[0055] In related technologies, some malicious traffic employs techniques such as "domain fronting" to use different domain names at different communication layers. For example, in an HTTPS request initiated by an application, the outer DNS (Domain Name System) request and TLS SNI use domain name A (usually a high-reputation domain name); while the inner layer, the Host field in the HTTP protocol uses the actual domain name B (e.g., the C2 server domain name of remote control malware, including botnets and ransomware). Because the hidden domain name B is under HTTPS encryption, it is invisible to the enterprise security detection system. Malicious traffic bypasses detection by hiding the true remote endpoint in the HTTPS protocol, misleading the enterprise security detection system into believing it is a legitimate address. For enterprise security detection systems, it is difficult to determine whether a domain name is the real target domain or a "shell" used to impersonate the real target in the communication traffic. They can only adopt either direct access or complete blocking, both of which lead to significant collateral damage and affect normal network access.

[0056] To address at least one of the technical problems existing in the aforementioned related technologies, this disclosure provides a method for detecting network access requests in a zero-trust network. Based on the characteristics of a zero-trust network architecture (i.e., no internal or external network traffic is trusted, and all network behaviors must be verified and audited), it compares the results of full traffic analysis, domain name resolution, and actual gateway access to extract abnormal traffic from normal traffic. Compared to most related technologies that focus on single traffic analysis or threat intelligence, the solution provided in this disclosure obtains information from different angles (such as the zero-trust network proxy and the zero-trust network gateway) and then performs comparative analysis. While reducing the required resource consumption, the end-to-end information comparison processing helps improve the timeliness and accuracy of detection, reduces false positives and false negatives, and helps improve network security access capabilities.

[0057] The solution provided in this disclosure is implemented in the access process of a zero-trust network. Wherein, as... Figure 5 As shown, iOA acts as a zero-trust network security service provider, converging the access paths of access subjects targeting enterprise business sites, data, APIs, and other resources. Initially, access subjects are considered untrusted in any environment. Only after passing through the access control policy engine (control flow) is the access transformed into trusted access. A unified entry point (data flow) is provided for access subjects to access resources via network access requests through a zero-trust proxy and access gateway (such as a zero-trust network gateway). iOA provides authentication operations for this unified entry point; only network access requests that pass authentication can be forwarded by the zero-trust proxy to the access gateway, which then proxies access to the actual business system.

[0058] Figure 1 An example implementation environment for the method provided in this disclosure is shown. It may include a terminal 10, a zero-trust network gateway 20, a service server 30, and a zero-trust network server 40.

[0059] Terminal 10 can be an electronic device used by the accessing entity, such as a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, etc., but is not limited to these. Terminal 10 is configured with an application, a zero-trust network proxy, and a zero-trust network client. The application can be an application authorized by the zero-trust network server 40 to access internal business systems (such as business server 30). The zero-trust network client can be a software program configured on terminal 10 used to verify the identity information, device trustworthiness, and application trustworthiness on the terminal, and to request process inspection from the server for unknown processes, ensuring the security, stability, and efficiency of the accessing entity's access to enterprise resources and data in any network environment. The zero-trust network proxy is used to obtain network access requests sent by the application and can store access control policies (such as those obtained by the zero-trust network client from the zero-trust network server 40) Figure 5 (As shown). Among them, the zero-trust gateway server 40 and the business server 30 can be independent physical servers, or server clusters or distributed systems composed of multiple physical servers. They can also be cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0060] Optionally, the terminal 10, the zero-trust network gateway 20, the service server 30, and the zero-trust network server 40 can be directly or indirectly connected through wired or wireless communication methods, and this embodiment of the present disclosure does not limit this.

[0061] Optionally, the zero-trust network client (such as the iOA client) is a security agent installed on the access subject's work device. It is responsible for verifying the trusted identity of the access subject on the device, verifying the trustworthiness of the device and the application, and requesting unknown processes to be submitted for inspection by the server. The zero-trust network proxy (such as an access proxy) obtains device traffic through a TUN / TAP virtual network interface card. After authentication by the iOA client, it forwards the request to the zero-trust network gateway (such as a smart gateway). If authentication fails, it either establishes a direct connection or terminates the connection. The smart gateway can be deployed at the entry point of enterprise applications and data resources, responsible for verifying, authorizing, and forwarding each session request accessing enterprise resources. The zero-trust network server (such as the iOA server) uses a policy control engine to securely schedule business traffic, authorizing at the person-device-software-application granularity. Specifically, the authentication module verifies the access subject's identity, the device trust module verifies the device's hardware information and security status, and the application detection module detects the security of application processes, such as vulnerabilities and viruses / Trojans. The server periodically sends files to the threat intelligence cloud service Anzhi or TAV (such as an antivirus engine) for inspection. If a malicious process is identified, the server notifies the client to perform an asynchronous blocking operation.

[0062] In one feasible embodiment, such as Figure 6As shown, the Zero Trust Network access process is as follows: The accessing entity initiates a network access request for the accessing object through the application. The network access request is obtained through the Zero Trust Network proxy. The Zero Trust Network proxy sends an authentication request to the Zero Trust Network client (iOA client) (i.e., the proxy requests credentials for the current network access request from the iOA client). The request parameters include the source IP or domain name, source port, destination IP or domain name, destination port, and the process PID corresponding to the application. The iOA client collects the process's MD5 hash, process path, last modified time, copyright information, signature information, etc., through the process PID sent by the Zero Trust Network proxy. Together with the source IP or domain name, source port, destination IP or domain name, and destination port of the network access request transmitted by the Zero Trust Network proxy, it requests a ticket from the Zero Trust Network server (such as the iOA server). If the request is successful, the ticket, the maximum number of times the ticket can be used, and the validity period of the ticket are sent to the Zero Trust Network proxy as a response. The zero-trust network proxy first sends an HTTPS request to the zero-trust network gateway (such as an access gateway), including the network access request credentials (tickets) passed by the iOA client in the Authorization header field. After receiving the request from the zero-trust network proxy, the access gateway parses the ticket in the header field and verifies the ticket with the iOA server. If the verification is successful, the access gateway and the zero-trust network proxy successfully establish a connection. Then, the zero-trust network proxy sends the original network access request to the access gateway, which forwards it to the corresponding business server, proxying the actual application network access. If the access gateway fails to verify the ticket, the connection between the zero-trust network proxy and the access gateway is interrupted. For traffic from applications outside the zero-trust policy accessing specific sites, the zero-trust network proxy directly sends a network access request to the target business server to achieve a direct connection.

[0063] In the aforementioned zero-trust network access architecture, terminal access behavior is governed by access control rules issued by the server, which are jointly executed by the iOA client and the iOA server. These access control rules include device information (unique device identifier, etc.), login account information (login credentials, i.e., the access ticket), transport layer protocol type (TCP or UDP), a list of business systems and ports (i.e., enterprise resources), and application process characteristics of the accessing system. Because access control rules are dynamic strategies for managing enterprise resources, incorporating factors such as terminal environment status, security level, network zone, compliance detection results, and access behavior of the accessing entity, different access behaviors may occur for the same business system under different terminal scenarios.

[0064] In the method provided in this disclosure, there are different types of proxies in the network, operating at different layers. The zero-trust network proxy mentioned in the above-described zero-trust network access process and description is a Layer 4 proxy, which can operate at the transport layer on top of the Layer 5 protocol stack, without concern for application layer protocols, including HTTP. Regarding HTTP, this means that the terminal's Layer 4 zero-trust network proxy only processes the IP address and port number, not the specific content of the HTTP request, including the URL (Uniform Resource Locator) and HTTP header information. Specifically, when an HTTP request is sent through the terminal's zero-trust network proxy, the specific content of the HTTP request is not processed; instead, the entire data stream is passed to the zero-trust network gateway (such as an access gateway). Therefore, the terminal's zero-trust network proxy is unaware of the requested URL and cannot pass the URL information to the zero-trust network gateway. In other words, the zero-trust network gateway is unaware of the existence of the URL. After receiving the domain name from the terminal's zero-trust network proxy (e.g., the terminal's zero-trust network proxy can send the target server's domain name and port as the Host field to the zero-trust network gateway via a CONNECT request), the zero-trust network gateway establishes a TCP connection to the target server based on the Host field in the CONNECT request, and then associates this connection with the network connection initiated by the client's original process. In this way, the data flow between the terminal process and the target server can be relayed through the data exchange between the terminal's zero-trust network proxy and the zero-trust network gateway.

[0065] The following is an example illustrating the network access request detection method for zero-trust networks provided in this disclosure.

[0066] In a feasible embodiment, the method provided in this disclosure can be executed by a zero-trust network proxy of the terminal, specifically including steps A1 to A4: Step A1: Obtain the first address information corresponding to the target site indicated by the network access request.

[0067] Optionally, a network access request refers to a request sent by a client (such as a browser or application) to a server to retrieve or submit data. This request follows a specific protocol (such as HTTP or HTTPS) and includes information such as the request method (such as GET or POST), the URL, and request headers. Traffic refers to the amount of data transmitted during network communication. It can be used to measure the load and efficiency of network communication. When a client sends a request to a server, a certain amount of traffic is generated; when a server sends a response to a client, corresponding traffic is also generated.

[0068] Optionally, the target site can be a website or server that the target intends to access during network access, and is the final destination of the network access request. When making network access, the target can specify the target site by entering a domain name or URL, and the browser or client can send the request to the target site.

[0069] In one example, when a user accesses a site using the network, the network access request passes through a zero-trust network proxy. The zero-trust network proxy is configured to capture all traffic originating from applications on the endpoint, and it can obtain the corresponding network access requests and responses.

[0070] Optionally, the Zero Trust Network proxy can relay all network traffic of the accessing entity. When accessing the network through the Zero Trust Network proxy, the proxy acts as an intermediary, handling the accessing entity's network access requests and responses (such as the results returned by the Zero Trust Network gateway). When the Zero Trust Network proxy receives a network access request, it can determine the first address information corresponding to the target site indicated by the network access request, such as the URL, IP address, request type, request header information, and request data of the target website or resource.

[0071] Step A2: Resolve the DNS request corresponding to the network access request to obtain the second address information associated with the first address information.

[0072] Optionally, the zero-trust network proxy can acquire all traffic emitted by applications on the terminal. During traffic acquisition, it can also simultaneously acquire DNS traffic, resolve DNS requests, and obtain the second address information corresponding to network access from the DNS resolution results. For example, the second address information can be information associated with the first address information. If the first address information includes a first target IP address, the second address information can include the domain name (such as second domain name information) associated with the first target IP address obtained from the DNS resolution results. For example, during DNS resolution, the DNS server records the domain name information associated with the IP address. Correspondingly, the second domain name information can be the default domain name of the first target IP address (such as the domain name pre-stored in the DNS server associated with that IP address), a configured domain name, or a domain name associated with the first target IP address for other services or content.

[0073] Optionally, in a zero-trust network architecture, the terminal's zero-trust network proxy can acquire traffic within the device, including DNS traffic. DNS typically uses the UDP protocol, occupying port 53, but in some cases it may use the TCP protocol, such as when the response size exceeds the UDP packet size limit. Therefore, by filtering TCP or UDP traffic on port 53 on the terminal's zero-trust network proxy, traffic on either port is identified as DNS traffic. The proxy also checks the packet content to confirm whether the packets conform to the DNS protocol format (which includes a header containing fields such as transaction ID, flags, question count, answer record count, authoritative record count, and additional record count; followed by the question section, containing the domain name to be queried; and then the answer section, containing the query result, i.e., the resolved IP address). Based on this, the corresponding domain name information can be obtained from the DNS resolution results.

[0074] Step A3: Send a network access request, first address information, and second address information to the zero-trust network gateway.

[0075] Optionally, in the proxy access method, when an application on the terminal initiates a network access request to a website, the zero-trust network proxy receives the traffic and forwards it to the zero-trust network gateway. The zero-trust network gateway then forwards the traffic to the target business website. After the access, the zero-trust network gateway sends the network response from the target website to the zero-trust network proxy, which then forwards the response to the corresponding application. When forwarding traffic to the zero-trust network gateway, the zero-trust network proxy can include both first and second address information.

[0076] Optionally, when a zero-trust network gateway receives forwarded traffic (including first address information and second address information), it can parse the information, such as identifying the source, destination, and data content of the traffic. Then, the zero-trust network gateway can perform routing and forwarding based on the relevant information. In the process of forwarding traffic, it can also perform security checks according to preset security policies, checking the source and destination of the traffic to ensure that it complies with the system's access control policies. For example, certain IP addresses or domain names may be listed in blacklists or whitelists. The zero-trust network gateway can allow or deny the passage of traffic based on the corresponding security check results.

[0077] Step A4: Upon receiving the third address information sent by the zero-trust network gateway, determine whether the network access request is abnormal based on the first address information, the second address information, and the third address information; the third address information is the address information used by the zero-trust network gateway to send the network access request to the target site based on the first address information and the second address information.

[0078] Optionally, the third-party address information may include the actual access result information returned by the zero-trust network gateway, such as the HTTP status code, response header information, response body content, and other relevant information (such as identifying the actual accessed IP address, domain name, etc.). After receiving the third-party address information, the zero-trust network proxy can decide how to further process the response data based on the third-party address information, such as returning relevant information to the access subject, performing data processing, or storing it.

[0079] Optionally, if the zero-trust network proxy receives the third address information returned by the zero-trust network gateway, it indicates that the zero-trust network gateway has implemented a pass policy after performing a security check on the network access request (such as passing the security check of the zero-trust network gateway, or having a certain probability of being abnormal and requiring further checks). Based on this, to improve the accuracy of the security check, the zero-trust network proxy compares the information it obtains (such as the first address information and the second address information) with the information obtained from the zero-trust network gateway (the third address information), and determines whether the network access request is abnormal based on the comparison result.

[0080] This disclosure provides a method for detecting network access requests in a zero-trust network. Based on the characteristics of a zero-trust network architecture (i.e., no internal or external network traffic is trusted, and all network behaviors must be verified and audited), it compares full traffic analysis (such as the first address information determined by the zero-trust network proxy from the network access request), domain name resolution (such as the second address information obtained by the zero-trust network proxy from DNS resolution), and the actual access results of the gateway (such as the third address information returned by the zero-trust network gateway) to extract abnormal traffic from normal traffic. Compared to most related technologies that focus on single traffic analysis or threat intelligence, the solution provided in this disclosure obtains information from different angles (such as the zero-trust network proxy and the zero-trust network gateway) and then performs comparative analysis. While reducing the required resources, the end-to-end information comparison processing helps improve the timeliness and accuracy of detection, reduces false positives and false negatives, and helps improve network security access capabilities.

[0081] In one feasible embodiment, the first address information includes first target IP address information and first domain name information.

[0082] Step A1 involves obtaining the first address information corresponding to the target site indicated by the network access request, including steps A11 to A12: Step A11: Obtain the first target IP address information corresponding to the target site accessed by the network access request through the protocol stack.

[0083] Optionally, an IP address is a unique identifier for a network device, and the destination IP address is the final destination of the data packet. By obtaining the destination IP address, the zero-trust network proxy can determine that the network access request can be correctly forwarded to the target server or device. The protocol stack is a core component in network communication, handling the encapsulation, transmission, and parsing of data packets. Through the protocol stack, the zero-trust network proxy can parse the destination IP address from the network access request.

[0084] Optionally, in step A11, the first target IP address information corresponding to the target site indicated by the network access request is obtained through the protocol stack, including one of the following steps A111 to A112: Step A111: Import the network access request into the virtual network card, process it through the first protocol stack corresponding to the virtual network card, and obtain the first target IP address information corresponding to the target site.

[0085] Step A112: Import the network access request into the kernel driver, process it through the second protocol stack corresponding to the kernel driver, and obtain the first target IP address information corresponding to the target site.

[0086] Optionally, the zero-trust network proxy on the terminal can redirect network access traffic from applications within the device to the virtual network interface or kernel driver for processing by configuring the host routing table (e.g., for hijacking traffic from virtual network interfaces) or issuing relevant interception rules (e.g., for hijacking access traffic from kernel drivers). Figure 2 As shown. However, the protocol stack used differs depending on the approach, such as... Figure 3 As shown, this disclosure provides two different ways to process the data.

[0087] In one example, if a TUN / TAP virtual network interface card (NIC) is used in conjunction with a user-space protocol stack (such as Netstack), traffic will pass through the user-space protocol stack. A TUN / TAP NIC is a technology for transferring data between user space and kernel space. The TUN device handles network layer packets, while the TAP device handles link layer (e.g., Ethernet) frames. When using a TUN / TAP device, the kernel passes network packets to user-space programs for processing, and finally, the packets are encapsulated and processed by the kernel protocol stack. The user-space protocol stack can be used to process packets received from the TUN / TAP NIC device. When using a TUN / TAP NIC and Netstack in combination, network traffic is transferred from kernel space to user space and processed by the user-space protocol stack.

[0088] In another example, if a kernel driver is used to handle network traffic, the traffic does not need to pass through the user-space protocol stack and can be processed directly in kernel space, i.e., using the protocol stack within the operating system kernel. When network packets pass through the protocol stack, the kernel driver implementing the zero-trust network proxy retrieves matching packets according to filtering rules and calls predefined processing functions to process the retrieved packets. During this process, the packets remain in kernel space. The processed packets are then re-injected into the protocol stack and continue through other stages of the protocol stack.

[0089] In this embodiment, two methods are provided for data packet processing: Method 1, which combines a virtual network card with a user-space protocol stack, and Method 2, which combines a kernel driver with a protocol stack. These methods can be adapted to different network scenarios and can be flexibly adjusted. For example, Method 2 can be used in scenarios that require high performance and low latency, while Method 1 can be used in scenarios that require customization or optimization of network communication protocols. This is beneficial for improving the timeliness and accuracy of security detection.

[0090] Step A12: Determine the Internet protocol type used in the network access request, and obtain the first domain name information corresponding to the target site indicated by the network access request under the corresponding Internet protocol type.

[0091] Optionally, the Internet protocol type includes HTTP or HTTPS.

[0092] In this embodiment of the disclosure, different methods are provided for obtaining domain name information to adapt to different Internet protocol types, so as to improve the efficiency and accuracy of obtaining domain name information.

[0093] Optionally, step A12 determines the type of Internet protocol used by the network access request, including one of steps A12a to A12b: Step A12a: Determine the Internet protocol type used in the network access request by using the source port or destination port in the TCP header.

[0094] Step A12b: Determine the Internet protocol type used by the network access request by analyzing the characteristics of the payload content in the data packet corresponding to the network access request.

[0095] Optional, such as Figure 3 As shown, regardless of whether the processing is done through the user-space protocol stack or the operating system kernel protocol stack, the next step is to identify from the network traffic whether the Internet protocol used by the network access request is HTTP or HTTPS based on the preset port number or data packet content.

[0096] In one example, the method based on preset port numbers is as follows: a set of port numbers is set in advance, consisting of specific port numbers commonly used by HTTP and HTTPS protocols (by default, HTTP uses port 80, while HTTPS uses port 443). By checking the source and destination ports in the TCP header of the data packet, if one of the ports is 80, it is likely the HTTP protocol; if one of the ports is 443, it is likely the HTTPS protocol.

[0097] In another example, the HTTP protocol type can be identified based on the characteristics of the packet payload. Since HTTP requests and responses are typically transmitted in plaintext and follow a specific format—for example, HTTP requests usually begin with the request method, such as GET or POST, followed by the URI, HTTP version, and HTTP headers; HTTP responses usually begin with the HTTP version, followed by the status code, status message, and response headers—it's possible to determine if it's an HTTP protocol by checking the packet payload for these characteristics. Since HTTPS is based on HTTP and uses an encrypted SSL / TLS layer on top of HTTP, during the TLS handshake between the communicating parties, the client sends a message called "ClientHello" containing an SNI extension that includes the original domain name. Therefore, this characteristic can be used to determine if it's an HTTPS protocol by capturing and parsing the "ClientHello" message in the TLS handshake record and checking for the presence of the SNI extension.

[0098] In this embodiment of the disclosure, considering that HTTP and HTTPS may also use non-standard ports in practical applications, relying solely on preset port numbers to determine the Internet protocol type may lead to misjudgment. In order to improve the efficiency of Internet protocol type determination while ensuring the accuracy of the determination result, a method based on preset port numbers combined with the characteristics of the payload content is provided. The method based on preset port numbers and the method based on payload content characteristics can be used independently or in combination.

[0099] Optionally, step A12 involves obtaining the first domain name information corresponding to the target site indicated by the network access request under the corresponding Internet protocol type, including steps A121 to A122: Step A121: If the network access request uses the HTTP protocol, parse the Host field in the HTTP request header to obtain the first domain name information corresponding to the target site.

[0100] Step A122: If the network access request uses the HTTPS protocol, the first domain name information corresponding to the target site requested during the handshake phase is determined through the SNI extension.

[0101] Optional, such as Figure 2 and Figure 3 As shown, after identifying whether the current traffic is HTTP or HTTPS, the original domain name of the network traffic can be automatically obtained. Different methods are used for HTTP and HTTPS protocols. In one example, for HTTP, the original domain name (such as the first domain name information) can be obtained by parsing the "Host" field in the HTTP request header from the data packet. In another example, for HTTPS, the "ClientHello" message in the TLS handshake record needs to be parsed, and the SNI extension needs to be extracted (because for HTTPS, the original domain name is usually included in the TLS handshake process between the client and the server. During the TLS handshake, the client sends a message named "ClientHello" which contains the SNI extension, and the SNI extension contains the original domain name).

[0102] In the above embodiments, the first domain name information can be the domain name used by the operation object when it actively initiates a network access request through an application in the terminal. For example, when accessing a website by entering www.A.com (first domain name information) in a browser, the first domain name information is the entry point for the operation object to access the target site, and the corresponding first target IP address information can be obtained through the protocol stack. The second domain name information can be the domain name associated with the first target IP address information obtained through DNS resolution. It may be the default domain name, configuration domain name, or domain name for other purposes of the first target IP address information. It is associated with the first target IP address information, but it is not necessarily the domain name actively accessed by the operation object.

[0103] In this embodiment of the disclosure, different methods are provided for obtaining domain names for different Internet protocol types, which can effectively improve the adaptability to actual application needs, improve the accuracy of processing different network access requests, and thus improve the accuracy of security detection.

[0104] In a feasible embodiment, the method provided by this disclosure further includes establishing a first mapping relationship between a first target IP address and first domain name information, establishing a second mapping relationship between a first target IP address and second domain name information, and obtaining mapping data corresponding to the network access request based on the first mapping relationship and the second mapping relationship.

[0105] Optionally, during the acquisition of traffic from various applications within the terminal, the zero-trust network proxy can automatically obtain the correspondence between the first target IP address information and the first domain name information corresponding to the network access request, and establish a first mapping relationship between the two. Based on this, and as seen in the above embodiments, second domain name information associated with the first target IP address information can be obtained through DNS traffic, and a second mapping relationship between the first target IP address information and the second domain name information can also be established accordingly.

[0106] Optionally, when forwarding traffic to the zero-trust network gateway, the zero-trust network proxy will simultaneously send the first address information and the second address information. To improve forwarding efficiency, the zero-trust network proxy can generate mapping data based on the first and second mapping relationships and send this mapping data while forwarding traffic. During processing, the zero-trust network gateway can also quickly and efficiently find the corresponding domain name from the IP address based on the mapping data. After access ticket verification, it will perform traffic proxying for the target site based on the obtained domain name.

[0107] For example, in DNS traffic, the second mapping relationship DNS_DomainA_IP1 between the second domain name information DomainA and the first target IP address information IP1 is used as data associated with the network session. This is then associated with the first mapping relationship Protocol_IP1_DomainB between the first target IP address information IP1 and the first domain name information extracted from the HTTP or HTTPS protocol in the protocol stack, forming the mapping relationship DomainA_IP1_DomainB. Theoretically, DomainA and DomainB are the same domain name. If DomainA and DomainB are inconsistent, the corresponding traffic may be abnormal.

[0108] In this embodiment, considering that for HTTP traffic, the Host header field in the HTTP request (HTTP / 1.1 stipulates that all HTTP requests must include a Host header field, the value of which is the domain name of the target server) may not match the domain name in the URL, potentially indicating malicious traffic involving domain fronting techniques. DNS resolution is based on the domain name in the URL, while resolving the corresponding domain name from the IP address in the protocol stack is based on preset rules. Normally, the domain name in the URL matches the Host header field of the HTTP request. However, for HTTPS traffic, even abnormal traffic, DNS requests and TLS SNI extensions can use a legitimate domain name, while the HTTP layer, which is not decryptable by intermediate nodes, uses a different, hidden domain name. This domain name is invisible to intermediate nodes due to HTTPS encryption. Therefore, to improve the effectiveness and accuracy of full traffic detection, a security detection scheme is provided that combines information comparison between the zero-trust network proxy and the zero-trust network gateway.

[0109] Optionally, the third address information includes the second target IP address information, which is obtained by the zero-trust network gateway through DNS resolution of the third domain name information obtained from the mapping data, or determined by the zero-trust network gateway based on the mapping data.

[0110] Optionally, the zero-trust network gateway can determine third-party domain information from the mapping data and perform traffic proxying for that third-party domain information.

[0111] For example, with respect to the HTTP protocol, a zero-trust network gateway can directly determine whether the current network access request is abnormal from the mapping data, such as whether the domain names in the first mapping relationship and the second mapping relationship are consistent. Figure 4 As shown, assuming the domain name shown in the Host field of the HTTP header is B.com, which is different from the domain name A.com, the zero-trust network gateway can determine that the network access request has a certain probability of being abnormal. In this case, the zero-trust network gateway can choose a trusted source for traffic proxying. For example, it can perform traffic proxying based on the first domain name information obtained from the protocol stack, or it can choose one of two different domain names for traffic proxying based on a pre-stored whitelist. In another case, if the domain name shown in the Host field of the HTTP header is A.com, that is, the domain name in both the first and second mapping relationships of the HTTP protocol is A.com, then the zero-trust network gateway can directly perform traffic proxying based on the domain name indicated in the mapping data. Subsequently, it can directly determine the first target IP address information as the second target IP address information to be returned to the zero-trust network proxy based on the mapping data, without performing DNS resolution.

[0112] Optionally, in a zero-trust network gateway, it can obtain third-party domain name information corresponding to the network access request from the mapping data, and perform traffic proxying based on this domain name information, forwarding the network access request to the appropriate server. For example, such as... Figure 4 As shown, the mapping data formed by the first mapping relationship DNS_A.com_1.2.3.4 and the second mapping relationship Protocol_1.2.3.4_A.com is forwarded by the zero-trust network proxy (such as a terminal full-traffic proxy) to the zero-trust network gateway (such as an access gateway). The zero-trust network gateway can find the corresponding third-party domain name information A.com from the IP address 1.2.3.4 of the mapping data and perform traffic proxying for the A.com domain. For example... Figure 4 As shown, the zero-trust network gateway can also combine DNS facilities for DNS resolution. For example, it can perform a DNS query based on the third domain name information A.com, obtain the DNS facility's response A.com: 4.3.2.1, and process the second target IP address 4.3.2.1 obtained from the DNS resolution as the third address information related to network access.

[0113] In one feasible embodiment, step A4 determines whether the network access request is abnormal based on the first address information, the second address information, and the third address information, including one of the following steps A41 to A43: Step A41: If the first domain name information is inconsistent with the second domain name information, or the first target IP address information is inconsistent with the second target IP address information, determine that the network access request is an abnormal request.

[0114] Step A42: If the first domain name information is inconsistent with the second domain name information, or the first target IP address information is inconsistent with the second target IP address information, and the communication frequency of the network access request exceeds the preset communication frequency, then the network access request is determined to be an abnormal request.

[0115] Step A43: If a warning message is received when the third address information is received, the communication frequency of the network access request is counted. If the communication frequency exceeds the preset communication frequency, the network access request is determined to be an abnormal request.

[0116] In this embodiment of the disclosure, for the HTTP protocol, suspicious abnormal traffic in the HTTP protocol can be identified in advance by the inconsistency between the URL domain name and the Host header field (such as the recorded domain name). For example, a malicious process initiates a network access request to the control server. The protocol is HTTP, and the URL accessed is HTTP: / / A.com / xxx / xx / xxx-xxxxxxx.js. However, the Host field in the HTTP header is B.com. Since the zero-trust network proxy detects that the traffic is HTTP, it extracts the domain name as B.com based on the Host field and directly accesses B.com instead of A.com. However, the DNS resolution is performed based on the domain name in the URL, that is, it will perform domain name resolution based on A.com. This makes the mapping between IP and A.com obtained from the DNS resolution result inconsistent with the mapping between IP and B.com resolved from the protocol stack based on the Host field. Based on this, it can be determined that the corresponding network access request is an abnormal request.

[0117] In this embodiment, regarding the HTTPS protocol, considering that malicious traffic is less likely to use HTTP for network transmission, HTTPS is more commonly used for encrypting communication content. When using HTTPS for communication, to conceal the true remote endpoint, the real endpoint is placed in the encrypted HTTP Host Header field. Since this domain name is encrypted under HTTPS, it is invisible to intermediate nodes. The plaintext layer visible to intermediate nodes uses a legitimate domain name. Therefore, the DNS request and TLS SNI extension domain name for HTTPS communication are generally the same; malicious traffic will use some high-reputation domain names for disguise. The Host field in the encrypted content is the actual address to be communicated. In related technologies, methods such as deploying HTTPS traffic decryption gateways within enterprises are used to detect such abnormal traffic by comparing whether the SNI and Host in the traffic are equal. However, while methods like Deep Packet Inspection (DPI) have powerful network observation and control technologies, they have limitations for encrypted network traffic such as HTTPS and other encrypted protocols. This is because DPI cannot directly view the communication content for encrypted traffic, limiting its ability to detect and control HTTPS traffic. Meanwhile, performing in-depth analysis of network packets in a large-scale enterprise network environment consumes significant computing resources. For DPI to analyze HTTPS traffic, it needs to rely on SSL / TLS decryption, configuring a man-in-the-middle HTTPS proxy to decrypt and inspect all encrypted traffic in the communication. This requires deploying an SSL / TLS decryption proxy on the decryption gateway to decrypt client HTTPS requests, and configuring client trust certificates on the endpoint. The SSL / TLS proxy on the decryption gateway intercepts HTTPS communication between the client and the target website, decrypting and re-encrypting it. In normal HTTPS communication, there is only one end-to-end encrypted channel between the client and the target website. After TLS / SSL decryption, two independent encrypted channels are established: one between the client and the proxy, and the other between the proxy and the target website. This raises concerns about the privacy and data security of the access subjects, consumes substantial resources, increases access latency for the access subjects, and results in a poor user experience. Performing this TLS / SSL decryption on all network access traffic of an enterprise poses a significant risk. Generally, it is only limited to performing such decryption and security checks on a subset of domains that meet the security rules, which cannot cover most scenarios (because the number of pre-set risky domains is limited and is only detected after the fact), resulting in a low level of security.To address this technical problem, this disclosure proposes a solution for identifying abnormal HTTPS traffic without deploying an HTTPS traffic decryption gateway. Compared to deploying an HTTPS traffic decryption gateway, this disclosure consumes fewer resources, improves detection accuracy, reduces false positives and false negatives, and thus enhances the ability to access networks securely.

[0118] Optionally, the terminal's zero-trust network proxy may forward traffic to a zero-trust network gateway (such as an access gateway) along with IP-DNS and IP-SNI mapping data. Upon receiving the traffic, the access gateway can then identify the traffic specific to the HTTPS protocol, such as... Figure 4 As shown, the corresponding domain name A.com can be found from IP 1.2.3.4. After the zero-trust network gateway verifies the access ticket, it performs traffic proxying for the A.com domain. It is expected that the IP resolved to A.com after DNS resolution on the zero-trust network gateway side will be 1.2.3.4. If an inconsistency occurs (e.g....), Figure 4 If the IP address shown in step 3 is 4.3.2.1, it can be identified as suspicious malicious traffic because the HTTPS SNI extension is for the A.com domain, and its DNS resolution result should be the same as the target IP address of the communication (such as the first target IP address determined by the zero-trust network proxy). Legitimate HTTPS traffic usually has a matching SNI and target IP address. If the domain name stored in the SNI extension does not match the target IP, this usually means that the traffic has been maliciously redirected or spoofed. By checking the consistency of these two, attacks that attempt to hide their malicious behavior by masquerading as legitimate traffic can be identified. If an inconsistency is detected, it can be used to identify malicious traffic based on the security policy. Figure 4 In step 4, as shown, the gateway returns a response to the traffic to the zero-trust network agent. You can either allow or block the traffic, or you can choose to perform auditing or warnings while allowing it.

[0119] Based on the above embodiments, when a zero-trust network proxy determines whether a network access request is abnormal based on various information, there are three methods: Method 1: When prioritizing security over accuracy, network access requests where the first domain name information is inconsistent with the second domain name information, or the first target IP address information is inconsistent with the second target IP address information, can be identified as abnormal requests.

[0120] Method 2: In balancing accuracy and security, if accuracy is prioritized, the accuracy of detection can be further improved by incorporating communication frequency characteristics. Optionally, when it is determined that the first domain name information is inconsistent with the second domain name information, or the first target IP address information is inconsistent with the second target IP address information, the communication frequency of the corresponding network access request is determined, and it is further determined whether the communication frequency exceeds the preset communication frequency. If so, the network access request is determined as an abnormal request.

[0121] Method 3: When the zero-trust network proxy receives both third-party address information and a warning message, it indicates that the zero-trust network gateway has preliminarily confirmed the possibility of an anomaly in the corresponding network access request. To improve processing efficiency, the zero-trust network proxy can directly combine this with the communication frequency for judgment, without needing to further judge based on domain name, IP address, etc. If the zero-trust network proxy determines that the communication frequency of the network access request exceeds the preset communication frequency, it can directly determine that the network access request is an abnormal request.

[0122] In a feasible embodiment, the determination of the communication frequency of the network access request in steps A42 and A43 includes steps A401 to A403: Step A401: Determine the observation target based on information related to the network access request, including at least one of the following: source IP address, destination IP address, destination port, and communication protocol.

[0123] Step A402: Obtain the data related to the observed object returned by the zero-trust network gateway, and aggregate it based on the preset time window to determine the amount of data in each time window.

[0124] Step A403: For each time window, determine the corresponding communication frequency based on the amount of data and duration within that time window.

[0125] In this embodiment, the accuracy of malicious traffic detection is improved by incorporating the communication frequency characteristics of traffic. Communication between malware within a device and an attacker-controlled command server typically exhibits network behavior patterns different from normal applications. One such pattern is the high-frequency execution of communication within a short period to quickly receive instructions and transmit data. In the above embodiment, if the DNS resolution result for the domain name corresponding to the SNI extension in the HTTPS protocol is inconsistent with the target IP address of the communication, or if the domain name corresponding to the SNI extension in the HTTP protocol is inconsistent with the domain name obtained from DNS resolution, an audit-only mode without blocking can be adopted initially. This involves automatically locking the source IP, target IP, target port, and communication protocol, using these elements to form an observation object (observed as a unit). First, a suitable time window size is determined, such as 1 minute or 5 minutes. Since the zero-trust network proxy on the terminal captures traffic information sent by the accessing entity, on the gateway side, when the network traffic characteristics sent by the zero-trust network proxy match the source IP, target IP, target port, timestamp, and communication protocol, the filtered target traffic data is aggregated according to the set time window. For example, the total number of data packets or the total traffic volume within each time window can be calculated. By setting a normal traffic frequency based on historical statistical data, a communication frequency threshold (such as a preset communication frequency) is determined for abnormal traffic, which is used to identify the communication frequency of abnormal traffic. If the communication frequency detected within a certain time window exceeds the preset communication frequency, it can be determined that the corresponding traffic is more likely to be malicious traffic.

[0126] In this embodiment of the disclosure, when a network access request is determined to be an abnormal request, an alert can be generated based on security rules, and automated blocking measures can be executed.

[0127] In one feasible embodiment, the method provided by this disclosure further includes: if no third address information is received within a preset time period, then confirming that the network access request is an abnormal request.

[0128] In this embodiment, the zero-trust network gateway can also detect network access requests. If the zero-trust network gateway determines through information comparison that a network access request may be abnormal and implements blocking measures, it will no longer return third-party address information to the zero-trust network proxy. In this case, the zero-trust network proxy can determine the abnormality by a preset time period. After the preset time period expires, it can directly classify the corresponding network access request as an abnormal request. In one example, if the zero-trust network proxy does not receive third-party address information within the preset time period, it indicates that the corresponding network access request has been blocked. In the proxy access method, the zero-trust network proxy and the zero-trust network gateway cannot communicate normally based on this network access request, which can help improve the security of network access.

[0129] In a feasible embodiment, the method provided in this disclosure can be executed by a zero-trust network gateway, specifically including steps B1 to B3: Step B1: Receive network access request, first address information and second address information sent by the zero-trust network proxy. The first address information includes information corresponding to the target site indicated by the network access request obtained by the zero-trust network proxy. The second address information includes address information associated with the first address information obtained by the zero-trust network proxy from resolving the DNS request corresponding to the network access request.

[0130] Step B2: Based on the first address information and the second address information, determine the third address information used to send a network access request to the target site.

[0131] Step B3: Send the third address information to the zero-trust network proxy, or determine whether the network access request is abnormal based on the first address information, the second address information, and the third address information.

[0132] Optionally, security detection can be implemented on either the zero-trust network gateway side or the zero-trust network proxy side. In one example, when the security detection policy is configured on the zero-trust network proxy side, the zero-trust network gateway can directly return a response to the zero-trust network proxy side after performing traffic proxying based on proxy access. For example, when returning the response result, it can send third address information, which the zero-trust network proxy side then uses for anomaly detection based on the first, second, and third address information. In another example, when the security detection policy is configured on the zero-trust network gateway, the zero-trust network gateway can directly perform anomaly detection based on the first and second address information sent by the zero-trust network proxy side and the third address information generated during its own proxy access process. If it determines that the current network access request is normal or an anomaly exists but a allow policy is executed, it returns the third address information to the zero-trust network proxy side; if it determines that the current network access request is abnormal and a blocking policy is executed, it does not return the third address information to the zero-trust network proxy side. For example, as shown... Figure 7 As shown, when performing information comparison on the zero-trust network gateway side, it can be implemented before or after forwarding the network access request to the business server. If implemented before, then, if it confirms that the current network access request is normal or that there is an anomaly but an allow policy is executed, it performs proxying, initiates network access to the business server, and returns a response result to the zero-trust network proxy. If implemented after, then, after the proxy initiates network access to the business server, if it confirms that the current network access request is normal or that there is an anomaly but an allow policy is executed, it returns a response result to the zero-trust network proxy. In one example, if the zero-trust network gateway confirms that the current network access request is abnormal and an blocking policy is executed, it may choose not to perform proxying or not to return a response result to the zero-trust network proxy.

[0133] The method executed by the zero-trust network gateway in the embodiments of this disclosure involves communication between the zero-trust network gateway and the zero-trust network agent. The description of the relevant embodiments can be referred to the description of the method executed by the zero-trust network agent above, and will not be repeated here.

[0134] The following provides a detailed explanation of the first address information and the second address information determined by the zero-trust network proxy. For details on how to obtain the first address information and the second address information, please refer to the relevant embodiments of the method executed by the zero-trust network proxy mentioned above. This disclosure will not repeat them here.

[0135] The first address information includes the first target IP address information and the first domain name information; the first target IP address information includes information obtained by the zero-trust network proxy through the protocol stack corresponding to the target site indicated by the network access request.

[0136] Optionally, the first target IP address information obtained through the protocol stack includes one of the following: After the zero-trust network proxy imports the network access request into the virtual network interface card (NIC), it processes the obtained IP address information through the first protocol stack corresponding to the virtual NIC.

[0137] After the zero-trust network proxy imports the network access request into the kernel driver, it processes the obtained IP address information through the second protocol stack corresponding to the kernel driver.

[0138] The first domain name information includes information corresponding to the target site obtained by the zero-trust network proxy based on the Internet protocol used for the network access request.

[0139] Optionally, the Internet protocol can be either HTTP or HTTPS.

[0140] Optionally, the Internet protocol type used for the network access request is determined by a preset port number or the characteristics of the payload content in the corresponding data packet.

[0141] Optionally, the first domain name information includes the HTTP protocol used for the network access request, information obtained by parsing the Host field in the HTTP request header, or information requested during the handshake phase by using the SNI extension for the HTTPS protocol used for the network access request.

[0142] Optionally, the second address information includes the DNS resolution request and the second domain name information associated with the first target IP address information obtained from the DNS resolution result.

[0143] Optionally, the first address information and the second address information are sent in the form of mapping data, which includes a first mapping relationship between the first target IP address information and the first domain name information, and a second mapping relationship between the first target IP address information and the second domain name information.

[0144] In one feasible embodiment, the third address information includes the second target IP address information. The second target IP address information is obtained by the zero-trust network gateway through DNS resolution of the third domain name information obtained from the mapping data, or determined by the zero-trust network gateway based on the mapping data.

[0145] Optionally, in a zero-trust network gateway, it can obtain third-party domain name information corresponding to the network access request from the mapping data, and perform traffic proxying based on this domain name information, forwarding the network access request to the appropriate server. For example, such as... Figure 4 As shown, the mapping data formed by the first mapping relationship DNS_A.com_1.2.3.4 and the second mapping relationship Protocol_1.2.3.4_A.com is forwarded by the zero-trust network proxy (such as a terminal full-traffic proxy) to the zero-trust network gateway (such as an access gateway). The zero-trust network gateway can find the corresponding third-party domain name information A.com from the IP address 1.2.3.4 of the mapping data and perform traffic proxying for the A.com domain. For example... Figure 4 As shown, the zero-trust network gateway can also perform DNS resolution in conjunction with DNS facilities. For example, it can perform a DNS query based on the third domain name information A.com, obtain the DNS facility's response A.com: 4.3.2.1, and process the second target IP address 4.3.2.1 obtained from the DNS resolution as the third address information.

[0146] Optionally, for the HTTP protocol, the zero-trust network gateway can directly determine whether the current network access request is abnormal from the mapping data, such as whether the domain names in the first mapping relationship and the second mapping relationship are consistent. For example, Figure 4As shown, assuming the domain name shown in the Host field of the HTTP header is B.com, which is different from the domain name A.com, the zero-trust network gateway can determine that the network access request has a certain probability of being abnormal. In this case, the zero-trust network gateway can choose a trusted source for traffic proxying. For example, it can perform traffic proxying based on the first domain name information obtained from the protocol stack, or it can choose one of two different domain names for traffic proxying based on a pre-stored whitelist. In another case, if the domain name shown in the Host field of the HTTP header is A.com, that is, the domain name in both the first and second mapping relationships of the HTTP protocol is A.com, then the zero-trust network gateway can directly perform traffic proxying based on this domain name. Subsequently, it can directly determine the first target IP address information as the second target IP address information to be returned to the zero-trust network proxy based on the mapping data, without performing DNS resolution.

[0147] In one feasible embodiment, step B3 determines whether the network access request is abnormal based on the first address information, the second address information, and the third address information, including one of the following steps B31 to B32: Step B31: If the first domain name information is inconsistent with the second domain name information, or the first target IP address information is inconsistent with the second target IP address information, determine that the network access request is an abnormal request.

[0148] Step B32: If the first domain name information is inconsistent with the second domain name information, or the first target IP address information is inconsistent with the second target IP address information, and the communication frequency of the network access request exceeds the preset communication frequency, then the network access request is determined to be an abnormal request.

[0149] Optionally, the execution logic of steps B31 to B32 is the same as that of steps A41 to A42 in the above embodiments. For related descriptions, please refer to the embodiments of the corresponding steps above. The embodiments disclosed herein will not be repeated here.

[0150] In a feasible embodiment, the method provided in this disclosure further includes at least one of steps B4 to B5: Step B4: If the network access request is determined to be an abnormal request, block the network access request.

[0151] Optionally, if the zero-trust network gateway determines that the current network access request is an abnormal request, it can implement a blocking policy, and instead of returning the corresponding response to the zero-trust network proxy, it can interrupt the network access request on the zero-trust network gateway side, so as to effectively prevent abnormal requests from affecting the security of the network environment and improve the security of network access.

[0152] Step B5: If the first domain name information is inconsistent with the second domain name information, or the first target IP address information is inconsistent with the second target IP address information, a warning message shall be sent at the same time when returning the third address information to the zero-trust network agent.

[0153] Optionally, the zero-trust network gateway can perform preliminary detection. For example, if it is determined that the first domain name information is inconsistent with the second domain name information, or the first target IP address information is inconsistent with the second target IP address information, the current network access request is initially identified as an abnormal request. However, the gateway can implement a pass policy and return a response and warning information to the zero-trust network proxy to further detect the network access request through the zero-trust network proxy, thereby improving the accuracy of the detection.

[0154] This disclosure provides a method for detecting malicious traffic using a zero-trust network security architecture. Based on the characteristics of a zero-trust network architecture (i.e., it does not trust any internal or external network traffic, and all network behaviors must be verified and audited), it compares the first address information determined by the zero-trust network proxy, the second address information obtained through domain name resolution, and the third address information obtained from the actual access by the zero-trust network gateway. Based on the information comparison results, abnormal traffic is extracted from normal traffic. This disclosure obtains information from different perspectives (zero-trust network proxy and zero-trust network gateway) and then performs information comparison and analysis, which helps improve the accuracy of detection, reduce false positives and false negatives, and improve network security access capabilities. Furthermore, by combining the characteristic of high communication frequency of abnormal traffic within a short period of time, the accuracy of malicious traffic detection can be further improved.

[0155] See Figure 8 , Figure 8 This is a schematic diagram of a network access request detection device 100 for a zero-trust network provided in an embodiment of this disclosure. The network access request detection device for a zero-trust network provided in this embodiment of the disclosure is applied to a zero-trust network proxy terminal of a terminal and includes a first acquisition module 101, a second acquisition module 102, a sending module 103, and a first receiving module 104.

[0156] The first acquisition module 101 is used to acquire the first address information corresponding to the target site indicated by the network access request; the second acquisition module 102 is used to parse the DNS request corresponding to the network access request to obtain the second address information associated with the first address information; the sending module 103 is used to send the network access request, the first address information, and the second address information to the zero-trust network gateway; the first receiving module 104 is used to determine whether the network access request is abnormal based on the first address information, the second address information, and the third address information when it receives the third address information sent by the zero-trust network gateway; the third address information is the address information used by the zero-trust network gateway to send the network access request to the target site based on the first address information and the second address information.

[0157] In one feasible embodiment, the first address information includes first target IP address information and first domain name information; when the first acquisition module 101 is used to acquire the first address information corresponding to the target site indicated by the network access request, it is specifically used for: The protocol stack is used to obtain the first target IP address information corresponding to the target site accessed by the network access request; Determine the Internet protocol type used in the network access request, and obtain the first domain name information corresponding to the target site indicated by the network access request under the corresponding Internet protocol type.

[0158] In a feasible embodiment, when the first acquisition module 101 acquires the first target IP address information corresponding to the target site indicated by the network access request through the protocol stack, it is specifically used to perform one of the following: The network access request is imported into the virtual network interface card (NIC), processed by the first protocol stack corresponding to the virtual NIC, and the first target IP address information corresponding to the target site is obtained. The network access request is imported into the kernel driver and processed by the second protocol stack corresponding to the kernel driver to obtain the first target IP address information corresponding to the target site.

[0159] In one feasible embodiment, the Internet protocol is either HTTP or HTTPS.

[0160] When the first acquisition module 101 is used to acquire the first domain name information corresponding to the target site indicated by the network access request under the corresponding Internet protocol type, it is specifically used for: If the network access request uses the HTTP protocol, then parse the Host field in the HTTP request header to obtain the first domain name information corresponding to the target site; If the network access request uses the HTTPS protocol, the first domain name information corresponding to the target site requested during the handshake phase is determined through the SNI extension.

[0161] In one feasible embodiment, when the first acquisition module 101 is used to determine the Internet protocol type used in the network access request, it is specifically used to perform one of the following: The source or destination port in the TCP header determines the type of Internet protocol used in the network access request. The type of Internet protocol used by the network access request can be determined by the characteristics of the payload content in the data packet corresponding to the network access request.

[0162] In one feasible embodiment, the second address information includes second domain name information associated with the first target IP address information. The apparatus 100 further includes an establishment module for establishing a first mapping relationship between the first target IP address and the first domain name information, establishing a second mapping relationship between the first target IP address and the second domain name information, and obtaining mapping data corresponding to the network access request based on the first and second mapping relationships.

[0163] When the sending module 103 is used to send a network access request, first address information and second address information to the zero-trust network gateway, it is specifically used to send a network access request and mapping data to the zero-trust network gateway.

[0164] The third address information includes the second target IP address information, which is obtained by the zero-trust network gateway through DNS resolution of the third domain name information obtained from the mapping data, or determined by the zero-trust network gateway based on the mapping data.

[0165] In one feasible embodiment, the first receiving module 104 is used to determine whether a network access request is abnormal based on the first address information, the second address information, and the third address information, specifically for one of the following purposes: If the first domain name information is inconsistent with the second domain name information, or if the first target IP address information is inconsistent with the second target IP address information, the network access request is determined to be an abnormal request. If the first domain name information is inconsistent with the second domain name information, or the first target IP address information is inconsistent with the second target IP address information, and the communication frequency of the network access request exceeds the preset communication frequency, then the network access request is determined to be an abnormal request. If a warning message is received along with the third address information, the communication frequency of the network access request is counted. If the communication frequency exceeds the preset communication frequency, the network access request is determined to be an abnormal request.

[0166] In one feasible embodiment, the apparatus 100 provided in this disclosure further includes a confirmation module, which is used to confirm that the network access request is an abnormal request if no third address information is received within a preset time period.

[0167] In one feasible embodiment, when the first receiving module 104 is used to determine the communication frequency of the network access request, it is specifically used for: The observation target is determined based on information related to the network access request, which includes at least one of the following: source IP address, destination IP address, destination port, and communication protocol; Acquire data related to the observed object returned by the zero-trust network gateway, and aggregate it based on a preset time window to determine the amount of data within each time window; For each time window, the corresponding communication frequency is determined based on the amount and duration of data within that time window.

[0168] In specific implementation, the network access request detection device of the aforementioned zero-trust network can perform the above-described actions through its built-in functional modules. Figure 7 The implementation methods provided for each step related to the zero-trust network proxy are detailed in the implementation methods provided for each step mentioned above, and will not be repeated here.

[0169] See Figure 9 , Figure 9 This is a schematic diagram of the structure of another network access request detection device 200 for a zero-trust network provided in this embodiment of the disclosure. The network access request detection device for a zero-trust network provided in this embodiment of the disclosure is applied to a zero-trust network gateway and includes: a second receiving module 201, a forwarding module 202, and a processing module 203.

[0170] The second receiving module 201 is used to receive a network access request, first address information, and second address information sent by the zero-trust network proxy. The first address information includes information corresponding to the target site indicated by the network access request obtained by the zero-trust network proxy. The second address information includes address information associated with the first address information obtained by the zero-trust network proxy from resolving the DNS request corresponding to the network access request. The forwarding module 202 is used to determine a third address information for sending the network access request to the target site based on the first address information and the second address information. The processing module 203 is used to send the third address information to the zero-trust network proxy, or to determine whether the network access request is abnormal based on the first address information, the second address information, and the third address information.

[0171] In one feasible embodiment, the first address information includes first target IP address information and first domain name information.

[0172] The first target IP address information includes information obtained by the zero-trust network proxy through the protocol stack that corresponds to the target site indicated by the network access request.

[0173] The first domain name information includes information corresponding to the target site obtained by the zero-trust network proxy based on the Internet protocol used for the network access request.

[0174] In one feasible embodiment, the first target IP address information obtained by the zero-trust network proxy through the protocol stack includes one of the following: After the zero-trust network proxy imports the network access request into the virtual network interface card (NIC), it processes the obtained IP address information through the first protocol stack corresponding to the virtual NIC. After the zero-trust network proxy imports the network access request into the kernel driver, it processes the obtained IP address information through the second protocol stack corresponding to the kernel driver.

[0175] In one feasible embodiment, the Internet protocol is either HTTP or HTTPS.

[0176] The first domain information includes the HTTP protocol used for the network access request, the information obtained by parsing the Host field in the HTTP request header, or the information requested during the handshake phase by the SNI extension for the HTTPS protocol used for the network access request. Alternatively, the type of Internet protocol used in a network access request can be determined by a preset port number or the characteristics of the payload content in the corresponding data packet.

[0177] In one feasible embodiment, the second address information includes a DNS resolution request and second domain name information associated with the first target IP address information obtained from the DNS resolution result.

[0178] In one feasible embodiment, the first address information and the second address information are sent in the form of mapping data, which includes a first mapping relationship between the first target IP address information and the first domain name information, and a second mapping relationship between the first target IP address information and the second domain name information.

[0179] The third address information includes the second target IP address information, which is obtained by DNS resolution of the third domain name information obtained from the mapping data or determined based on the mapping data.

[0180] In one feasible embodiment, when the processing module 203 is used to determine whether a network access request is abnormal based on the first address information, the second address information, and the third address information, it is specifically used for one of the following: If the first domain name information is inconsistent with the second domain name information, or if the first target IP address information is inconsistent with the second target IP address information, the network access request is determined to be an abnormal request. If the first domain name information is inconsistent with the second domain name information, or the first target IP address information is inconsistent with the second target IP address information, and the communication frequency of the network access request exceeds the preset communication frequency, then the network access request is determined to be an abnormal request.

[0181] In one feasible embodiment, when determining the communication frequency for executing the network access request, the processing module 203 is specifically used for: The observation target is determined based on information related to the network access request, which includes at least one of the following: source IP address, destination IP address, destination port, and communication protocol; Acquire data related to the observed object returned by the zero-trust network gateway, and aggregate it based on a preset time window to determine the amount of data within each time window; For each time window, the corresponding communication frequency is determined based on the amount and duration of data within that time window.

[0182] In one feasible embodiment, the apparatus 200 provided in this disclosure further includes at least one of the following: The blocking module is used to block network access requests when they are determined to be abnormal. The information sending module is used to send a warning message when returning the third address information to the zero-trust network agent in cases where the first domain name information is inconsistent with the second domain name information, or the first target IP address information is inconsistent with the second target IP address information.

[0183] In specific implementation, the network access request detection device of the aforementioned zero-trust network can perform the above-described actions through its built-in functional modules. Figure 7 The implementation methods provided for each step related to the zero-trust network gateway are detailed in the implementation methods provided for each step above, and will not be repeated here.

[0184] See Figure 10 , Figure 10 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this disclosure. For example... Figure 10As shown, the electronic device 1000 in this embodiment may include: a processor 1001, a network interface 1004, and a memory 1005. Furthermore, the electronic device 1000 may also include: an object interface 1003, and at least one communication bus 1002. The communication bus 1002 is used to implement communication between these components. The object interface 1003 may include a display screen and a keyboard; optionally, the object interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be a high-speed RAM or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory 1005 may also be at least one storage device located remotely from the aforementioned processor 1001. Figure 10 As shown, the memory 1005, which is a computer-readable storage medium, may include an operating system, a network communication module, an object interface module, and a device control application.

[0185] exist Figure 10 In the illustrated electronic device 1000, the network interface 1004 provides network communication functionality; the object interface 1003 is mainly used to provide an input interface for objects; and when the processor 1001 is used to execute the method for detecting network access requests in a zero-trust network, it can call the device control application stored in the memory 1005 to achieve the following: it can obtain the first address information corresponding to the target site indicated by the network access request, and it can also resolve the DNS request corresponding to the network access request to obtain the second address information associated with the first address information; based on this, the zero-trust network proxy can send the network access request, the first address information, and the second address information to the zero-trust network gateway, and the zero-trust network gateway performs the proxying of the network access request. The zero-trust network gateway can send the third address information to the zero-trust network proxy. The third address information is the address information used by the zero-trust network gateway to send the network access request to the target site based on the first address information and the second address information. When the zero-trust network proxy receives the third address information, it can determine whether the network access request is abnormal based on the first address information, the second address information, and the third address information.

[0186] The implementation of this disclosure uses information obtained by the zero-trust network proxy and the zero-trust gateway during the processing of network access requests to determine whether a network access request is abnormal. This allows for timely and accurate identification of abnormal network access requests, which helps improve the security of network access.

[0187] It should be understood that in some feasible implementations, the processor 1001 described above may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor. The memory may include read-only memory and random access memory, and provides instructions and data to the processor. A portion of the memory may also include non-volatile random access memory. For example, the memory may also store device type information.

[0188] In specific implementation, the aforementioned electronic device 1000 can perform the above-described actions through its built-in functional modules. Figure 7 The implementation methods provided for each step are detailed in the above-mentioned implementation methods, and will not be repeated here.

[0189] This disclosure also provides a computer-readable storage medium storing a computer program that is executed by a processor to perform... Figure 7 The methods provided in each step are detailed in the implementation methods provided in the above steps, and will not be repeated here.

[0190] The aforementioned computer-readable storage medium can be an internal storage unit of the network access request detection device or electronic device for zero-trust networks provided in any of the foregoing embodiments, such as a hard disk or memory of the electronic device. The computer-readable storage medium can also be an external storage device of the electronic device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device. The aforementioned computer-readable storage medium can also include magnetic disks, optical disks, read-only memory (ROM), or random access memory (RAM), etc. Furthermore, the computer-readable storage medium can include both internal storage units and external storage devices of the electronic device. The computer-readable storage medium is used to store the computer program and other programs and data required by the electronic device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0191] This disclosure provides a computer program product including a computer program that is executed by a processor. Figure 7 The methods provided for each step in the process.

[0192] The terms “first,” “second,” etc., used in the claims, description, and drawings of this disclosure are used to distinguish different objects, not to describe a particular order. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or electronic device that comprises a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or electronic devices. References to “embodiment” herein mean that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this disclosure. The presentation of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments. The term “and / or” as used in this disclosure and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0193] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Those skilled in the art can implement the described functions using different methods for each specific application, but such implementations should not be considered beyond the scope of this disclosure.

[0194] The above-disclosed embodiments are merely preferred embodiments of this disclosure and should not be construed as limiting the scope of this disclosure. Therefore, any equivalent variations made in accordance with the claims of this disclosure shall still fall within the scope of this disclosure.

Claims

1. A method for detecting network access requests in a zero-trust network, characterized in that, The method, applied to a zero-trust network proxy terminal, includes: Obtain the first address information corresponding to the target site indicated by the network access request; Parse the DNS request corresponding to the network access request to obtain the second address information associated with the first address information; Send the network access request, the first address information, and the second address information to the zero-trust network gateway; Upon receiving the third address information sent by the zero-trust network gateway, the system determines whether the network access request is abnormal based on the first address information, the second address information, and the third address information. The third address information is the address information used by the zero-trust network gateway when sending the network access request to the target site based on the first address information and the second address information.

2. The method according to claim 1, characterized in that, The first address information includes the first target IP address information and the first domain name information; The step of obtaining the first address information corresponding to the target site indicated by the network access request includes: The protocol stack is used to obtain the first target IP address information corresponding to the target site accessed by the network access request; Determine the Internet protocol type used by the network access request, and obtain the first domain name information corresponding to the target site indicated by the network access request under the corresponding Internet protocol type.

3. The method according to claim 2, characterized in that, The step of obtaining the first target IP address information corresponding to the target site indicated by the network access request through the protocol stack includes one of the following: The network access request is imported into the virtual network interface card and processed by the first protocol stack corresponding to the virtual network interface card to obtain the first target IP address information corresponding to the target site. The network access request is imported into the kernel driver and processed by the second protocol stack corresponding to the kernel driver to obtain the first target IP address information corresponding to the target site.

4. The method according to claim 2, characterized in that, The internet protocol is either HTTP or HTTPS. The step of obtaining the first domain name information corresponding to the target site indicated by the network access request under the corresponding Internet protocol type includes: If the network access request uses the HTTP protocol, then the Host field in the HTTP request header is parsed to obtain the first domain name information corresponding to the target site; If the network access request uses the HTTPS protocol, the first domain name information corresponding to the target site requested during the handshake phase is determined through the SNI extension.

5. The method according to claim 2, characterized in that, Determining the type of Internet protocol used in the network access request includes one of the following: The type of Internet protocol used in the network access request is determined by the source port or destination port in the TCP header; The type of Internet protocol used by the network access request is determined by the characteristics of the payload content in the data packet corresponding to the network access request.

6. The method according to claim 2, characterized in that, The second address information includes second domain name information associated with the first target IP address information; The method further includes establishing a first mapping relationship between the first target IP address and the first domain name information, establishing a second mapping relationship between the first target IP address and the second domain name information, and obtaining mapping data corresponding to the network access request based on the first mapping relationship and the second mapping relationship; Sending the network access request, the first address information, and the second address information to the zero-trust network gateway includes: sending the network access request and the mapping data to the zero-trust network gateway; The third address information includes second target IP address information, which is obtained by the zero-trust network gateway through DNS resolution of the third domain name information obtained from the mapping data, or determined by the zero-trust network gateway based on the mapping data.

7. The method according to claim 6, characterized in that, The step of determining whether the network access request is abnormal based on the first address information, the second address information, and the third address information includes one of the following: If the first domain name information is inconsistent with the second domain name information, or if the first target IP address information is inconsistent with the second target IP address information, the network access request is determined to be an abnormal request. If the communication frequency of the network access request exceeds the preset communication frequency, and the first domain name information is inconsistent with the second domain name information, or the first target IP address information is inconsistent with the second target IP address information, then the network access request is determined to be an abnormal request. If a warning message is also received when the third address information is received, the communication frequency of the network access request is counted. If the communication frequency exceeds a preset communication frequency, the network access request is determined to be an abnormal request.

8. The method according to claim 7, characterized in that, Determining the communication frequency of the network access request includes: The observation target is determined based on information related to the network access request, including at least one of the following: source IP address, destination IP address, destination port, and communication protocol. The data related to the observed object returned by the zero-trust network gateway is obtained and aggregated based on a preset time window to determine the amount of data in each time window; For each time window, the corresponding communication frequency is determined based on the amount and duration of data within that time window.

9. A method for detecting network access requests in a zero-trust network, characterized in that, Applied to zero-trust network gateways, the method includes: The system receives a network access request, first address information, and second address information sent by a zero-trust network proxy. The first address information includes information corresponding to the target site indicated by the network access request obtained by the zero-trust network proxy. The second address information includes address information associated with the first address information obtained by the zero-trust network proxy through parsing the DNS request corresponding to the network access request. Based on the first address information and the second address information, a third address information for sending the network access request to the target site is determined; Send the third address information to the zero-trust network proxy, or determine whether the network access request is abnormal based on the first address information, the second address information, and the third address information.

10. The method according to claim 9, characterized in that, The first address information includes the first target IP address information and the first domain name information; The first target IP address information includes information obtained by the zero-trust network proxy through the protocol stack that corresponds to the target site indicated by the network access request; The first domain name information includes information corresponding to the target site obtained by the zero-trust network proxy based on the Internet protocol used by the network access request.

11. The method according to claim 10, characterized in that, The internet protocol is either HTTP or HTTPS. The first domain name information includes the HTTP protocol used for the network access request, the information obtained by parsing the Host field in the HTTP request header, or the information requested during the handshake phase determined by the SNI extension for the HTTPS protocol used for the network access request. Alternatively, the Internet protocol type used in the network access request may be determined by a preset port number or the characteristics of the payload content in the corresponding data packet.

12. The method according to claim 10, characterized in that, The second address information includes second domain name information associated with the first target IP address information; The first address information and the second address information are sent in the form of mapping data, which includes a first mapping relationship between the first target IP address information and the first domain name information and a second mapping relationship between the first target IP address information and the second domain name information; The third address information includes the second target IP address information, which is obtained by DNS resolution of the third domain name information obtained from the mapping data or determined based on the mapping data.

13. The method according to claim 12, characterized in that, The step of determining whether the network access request is abnormal based on the first address information, the second address information, and the third address information includes one of the following: If the first domain name information is inconsistent with the second domain name information, or if the first target IP address information is inconsistent with the second target IP address information, the network access request is determined to be an abnormal request. If the communication frequency of the network access request exceeds a preset communication frequency, and the first domain name information is inconsistent with the second domain name information, or the first target IP address information is inconsistent with the second target IP address information, then the network access request is determined to be an abnormal request.

14. The method according to claim 13, characterized in that, Determining the communication frequency of the network access request includes: The observation target is determined based on information related to the network access request, including at least one of the following: source IP address, destination IP address, destination port, and communication protocol. The data related to the observed object returned by the zero-trust network gateway is obtained and aggregated based on a preset time window to determine the amount of data in each time window; For each time window, the corresponding communication frequency is determined based on the amount and duration of data within that time window.

15. The method according to claim 12, characterized in that, The method further includes at least one of the following: If the network access request is determined to be an abnormal request, the network access request will be blocked. If the first domain name information is inconsistent with the second domain name information, or if the first target IP address information is inconsistent with the second target IP address information, a warning message is sent simultaneously when returning the third address information to the zero-trust network proxy.

16. A network access request detection device for a zero-trust network, characterized in that, A zero-trust network proxy for use on a terminal, the device comprising: The first acquisition module is used to acquire the first address information corresponding to the target site indicated by the network access request. The second acquisition module is used to parse the DNS request corresponding to the network access request to obtain the second address information associated with the first address information; The sending module is used to send the network access request, the first address information, and the second address information to the zero-trust network gateway; The first receiving module is configured to, upon receiving third address information sent by the zero-trust network gateway, determine whether the network access request is abnormal based on the first address information, the second address information, and the third address information; the third address information is the address information used by the zero-trust network gateway to send the network access request to the target site based on the first address information and the second address information.

17. A network access request detection device for a zero-trust network, characterized in that, An application to zero-trust network gateways, characterized in that the device comprises: The second receiving module is used to receive a network access request, a first address information and a second address information sent by the zero-trust network proxy. The first address information includes information corresponding to the target site indicated by the network access request obtained by the zero-trust network proxy. The second address information includes address information associated with the first address information obtained by the zero-trust network proxy through parsing the DNS request corresponding to the network access request. The forwarding module is used to determine, based on the first address information and the second address information, third address information for sending the network access request to the target site; The processing module is used to send the third address information to the zero-trust network proxy, or to determine whether the network access request is abnormal based on the first address information, the second address information, and the third address information.

18. An electronic device, characterized in that, It includes a processor and a memory, which are interconnected; The memory is used to store computer programs; The processor is configured to, when the computer program is invoked, execute the method of any one of claims 1 to 8, or execute the method of any one of claims 9 to 15.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that is executed by a processor to implement the method of any one of claims 1 to 8, or the method of any one of claims 9 to 15.

20. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 8, or implements the method according to any one of claims 9 to 15.

Images