A channel management system based on entropy weight method

Abstract

This invention proposes a channel control system based on the entropy weight method, belonging to the field of network security technology. This system integrates traffic interception, port hiding, traffic forwarding, secure connection, and access proxy technologies to construct a comprehensive network security solution. The core of the system lies in the channel control technology and the access proxy technology based on the entropy weight method. In the channel control technology based on the entropy weight method, the traffic interception module effectively prevents unauthorized traffic from passing through the channel using driver interception and routing interception technologies; the port hiding module hides port information through single-packet authorization technology, thereby improving system security; the traffic forwarding module uses tun2socks technology to allow data to be forwarded transparently after authorization; and the secure connection module, based on a local self-signed certificate, ensures a trusted connection for HTTPS services in the local environment. The access proxy technology based on the entropy weight method implements access control and policy scheduling.

Description

Technical Field

[0001] This invention belongs to the field of network security technology, and in particular relates to a channel control system based on entropy weight method for network resource access control. Background Technology

[0002] Traditional access control is limited to security controls at the business layer, neglecting the management of access channels. How to build secure channels based on existing standards and implementations to enhance resource access security is a key challenge. Meanwhile, network users accessing data center business application systems rely on static authentication and authorization measures to ensure secure access. However, inconsistent authentication methods, a lack of strong access controls, inadequate auditing measures, and the absence of cloud desktops make it difficult to detect and block abnormal and unauthorized access behaviors, and to prevent the leakage of sensitive data. Therefore, developing a channel management system with stronger network security defense capabilities has become a current research hotspot. Summary of the Invention

[0003] In response to the aforementioned technological status quo, this invention proposes a channel control system based on the entropy weight method; aiming to enhance the security of network resource access and realize a "authenticate first, then connect" security model in a zero-trust network environment.

[0004] This invention discloses a channel control system based on the entropy weight method, the system comprising: The traffic interception module is configured to automatically identify and block unauthorized traffic using preset security policies, and all incoming and outgoing data streams must meet security requirements. The port hiding module is configured to encrypt and hide all network ports by implementing single-packet authorization technology, making the ports completely invisible to unauthorized requests and avoiding malicious scanning and reconnaissance activities. The traffic forwarding module is configured to use tun2socks technology to process and forward authenticated and authorized data, and to achieve secure data routing by creating virtual network interfaces and configuring transparent proxies. The secure connection module is configured to: establish an encrypted connection based on access control factors and a local self-signed certificate to achieve end-to-end data transmission security, and use encryption algorithms to protect the confidentiality and integrity of data during transmission; The access proxy module is configured to: implement access control and policy scheduling based on the entropy weight method, use a decision engine to evaluate and manage access requests in real time, and automatically adjust access control rules according to the dynamic environment and policies.

[0005] The traffic interception module includes: The driver interception submodule is configured to: hook network traffic entering and leaving the client at the kernel level of the operating system; determine the traffic allowed to pass by detecting network packets and comparing them with a predefined list of applications; and block traffic from entering the network when it comes from an unauthorized application, or redirect it to a secure processing node for further inspection or logging. The routing interception submodule is configured to: intercept data packets by modifying the iptables rules of network devices; and direct traffic by customizing iptables rules, including: redirecting to specific ports, intercepting suspicious inbound or outbound requests, and completely discarding data packets that do not comply with security policies.

[0006] The port hiding module is specifically configured as follows: After the deployment of network access control technology based on single-packet authorization mechanism is completed, and before sending access request, a single data packet containing all necessary verification information is generated. The data in this data packet includes user credentials, timestamp, and access request. The data in this data packet is encrypted using a strong encryption algorithm to ensure that the data is not lost or tampered with during transmission. The receiving gateway or access controller identifies and processes authorization packets. When a single packet authorization request is received, it first decrypts the data packet and verifies the validity of the credentials and timestamp contained therein. If the verification is successful, it allows or denies access to the specified resource according to the preset security policy and permission settings.

[0007] The traffic forwarding module is specifically configured as follows: After implementing network traffic forwarding based on tun2socks technology, the TUN / TAP virtual network device is used to capture outbound traffic generated by the device. The TUN device processes network layer packets, and the TAP device processes data link layer frames, allowing tun2socks to access all types of network traffic originating from the operating system. The captured packets are encapsulated in SOCKS protocol format, allowing the packets to be forwarded through a proxy server, during which authentication and encryption are implemented. The encapsulated data is forwarded through a configured SOCKS proxy server, allowing tun2socks to cross network isolation and transmit data to the target server or service, thereby bypassing network restrictions or enforcing specific network policies.

[0008] The secure connection module is specifically configured as follows: After completing the issuance of a digital certificate based on local self-signature, use the OpenSSL tool to generate a public key and private key pair locally, and use the key to generate a self-signed certificate. After the self-signed certificate is generated, install it on the server that requires secure communication, specify the use of the certificate and the corresponding private key in the server configuration, and enable HTTPS service to encrypt the communication between the client and the server.

[0009] The access proxy module is configured to perform: proxy plugin scheduling, API hot reloading, authorization control, and API rate limiting. The plugins involved in the proxy plugin scheduling process include application identification plugins, application protection plugins, identity recognition plugins, authorization determination plugins, rate limiting plugins, and load balancing plugins.

[0010] For plugins involved in the proxy plugin scheduling process: Application identification plugin: Identifies the accessed application through HTTP request parameters, supporting fine-grained matching of domain name, URL parameters, header attributes, and cookie attributes, and rejecting unmatched requests; Application protection plugin: Matches the configured policy with the context of the current request and executes the corresponding policy, including denying access or logging; Identity verification plugin: Extracts the application access token from the access request to identify the user's identity information; requests without a valid access token will be rejected. Authorization determination plugin: Combines application access token and request context information for access control. Requests that are authorized will be allowed to pass, while those that are not will be blocked and logged. Rate limiting plugin: Matches the configured policy with the context of the current request and executes rate limiting measures, including denying access or returning a specific status code; Load balancing plugin: Performs load balancing for applications configured with multiple addresses, supporting round-robin, source IP hashing, and hash algorithms with specified parameters.

[0011] For API hot reloading: The API proxy listens for change events in the configuration store. When it detects a change in the configuration information, it immediately triggers an update process, which includes: pulling the latest configuration data from the configuration store, processing and transforming it in memory to adapt to the API proxy's runtime environment; and applying the updated configuration to the proxy system without restarting or reloading the Nginx server, thereby avoiding service interruption and performance degradation.

[0012] Regarding authorization control: The API proxy uses a caching mechanism in memory to query the access token carried in the request. If a valid access token is not found in memory, it switches to the locally deployed Redis caching service. In Redis, the access token is cached together with the related authorization information. When the corresponding access token is not found in the local cache, or the found token is invalid, or the key information associated with the token is inconsistent with the context of the current request, the API proxy will send an authorization request to the authorization subsystem. The authorization subsystem is responsible for handling authentication and authorization logic. It verifies the legitimacy of applications and decides whether to authorize access based on preset security policies. After real-time analysis, the authorization subsystem calculates which access tokens are affected by user status changes, organizational structure changes, policy updates, or abnormal behavior. For access tokens that need to be revoked, the authorization subsystem issues an instruction to the API proxy, which will perform the corresponding revocation operation to ensure that the system's access control is always up-to-date. Once an authorization request is successful, the new authorization result is cached in local Redis for subsequent request verification.

[0013] Regarding API rate limiting and throttling: Configure request rate threshold and burst rate threshold; when the request rate of a single user or IP address exceeds the set rate, additional requests are delayed to reduce the overall request rate; when the request rate exceeds the sum of rate and burst, requests are rejected and a specific HTTP status code is returned. Set a concurrent connection threshold `conn` and a burst concurrency threshold `burst`. When the number of concurrent connections for a user or IP address exceeds `conn`, additional connection requests are placed in a waiting queue or rejected directly to prevent system overload. When the number of concurrent connections exceeds the sum of `conn` and `burst`, new connection requests are rejected. By configuring the time window (time_window) and the request count threshold (count), the total number of requests within a specific time period can be controlled. When a user sends more requests than the set count within one minute, the excess requests are rejected until the time window is reset.

[0014] In summary, the system disclosed in this invention integrates traffic interception, port hiding, traffic forwarding, secure connection, and access proxy technologies to construct a comprehensive network security solution. The core of the system lies in the channel control technology based on entropy weighting and the access proxy technology based on entropy weighting. In the channel control technology based on entropy weighting, the traffic interception module effectively prevents unauthorized traffic from passing through the channel using driver interception and routing interception technologies; the port hiding module hides port information through single-packet authorization technology, thereby improving system security; the traffic forwarding module uses tun2socks technology to allow data to be forwarded transparently after authorization; and the secure connection module ensures a trusted connection for HTTPS services in the local environment based on local self-signed certificates. The access proxy technology based on entropy weighting implements access control and policy scheduling based on entropy weighting. The technical solution of this invention not only improves the security of network channels but also provides users and enterprises with a reliable and efficient network security solution through flexible policy configuration and real-time access control. It can effectively prevent unauthorized access and data leakage in various network environments, protecting critical network resources from security threats. Attached Figure Description

[0015] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0016] Figure 1 This is a schematic diagram of rule filtering in the traffic interception technology according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the port hiding technology according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the single-package licensing technology according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the access control process according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the knocking process according to an embodiment of the present invention; Figure 6 This is a schematic diagram illustrating the working principle of tun2socks according to an embodiment of the present invention. Figure 7 This is a schematic diagram illustrating the functional implementation of tun2socks according to an embodiment of the present invention; Figure 8 This is a schematic diagram of the entropy weighting secure connection technology according to an embodiment of the present invention; Figure 9This is a schematic diagram illustrating the implementation of the plug-in proxy technology according to an embodiment of the present invention; Figure 10 This is a schematic diagram illustrating the implementation of hot loading of plugin information according to an embodiment of the present invention; Figure 11 This is a schematic diagram illustrating the implementation of plug-in access control according to an embodiment of the present invention; Figure 12 This is a schematic diagram illustrating the implementation of plug-in rate limiting according to an embodiment of the present invention. Detailed Implementation

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

[0018] This invention provides a channel control system based on the entropy weight method. It adopts the security model concept of "authentication first, connection later" and can overcome the open and insecure basic characteristics of the existing Transmission Control Protocol / Internet Protocol Address (TCP / IP) that allows "connection first, authentication later". The application of the entropy weight method architecture ensures that only authorized users can reliably access the service, while unauthorized users cannot see these services. In other words, all unauthorized network traffic is discarded by default, achieving a zero-trust effect.

[0019] Traffic interception technology effectively blocks unauthorized traffic from passing through a channel through driver-based interception and routing interception techniques. Driver-based interception technology hooks client traffic and judges based on an application list to achieve traffic forwarding or bypass. Routing interception technology intercepts data by creating virtual network interfaces and modifying iptables rules.

[0020] Port hiding technology uses Single Packet Authorization (SPA) technology to hide port information, ensuring that only authenticated devices and users can access the controller and gateway, thereby improving system security.

[0021] Traffic forwarding technology: Utilizing tun2socks technology, transparent data forwarding is achieved. By encapsulating data in a SOCKS protocol format and forwarding it through a SOCKS proxy, no changes to any application are required.

[0022] Secure connection technology, based on locally self-signed certificates, enables trusted connections for HTTPS services in a local environment. It ensures service security by quantifying the importance of locally self-signed certificates for access control.

[0023] Access control proxy technology, including plugins for application identification, application protection, identity recognition, authorization determination, rate limiting, and load balancing, implements access control and policy scheduling based on the entropy weight method. By analyzing the impact of relevant information changes on online users in real time, it calculates the affected access tokens and performs real-time access control.

[0024] The first embodiment of the present invention will be described below.

[0025] A channel control system based on entropy weighting includes: First, an entropy weighting-based channel control technology. This involves a traffic interception module deployed at the network ingress, incorporating specific drivers and routing interception technologies to automatically identify and block unauthorized traffic using preset security policies. This ensures that all incoming and outgoing data flows comply with enterprise security requirements. Second, a port hiding module implements single-packet authorization technology to encrypt and hide all network ports, ensuring that ports are completely invisible to unauthorized requests and effectively preventing malicious scanning and other network reconnaissance activities. Third, a traffic forwarding module uses tun2socks technology to process and forward authenticated and authorized data. This module achieves secure data routing by creating virtual network interfaces and configuring transparent proxies, requiring no application modifications. A secure connection module establishes encrypted connections based on access control factors and locally self-signed certificates, achieving end-to-end data transmission security and using advanced encryption algorithms to protect the confidentiality and integrity of data during transmission. Finally, an entropy weighting-based access proxy technology is implemented. This module uses an advanced decision engine to evaluate and manage access requests in real time, automatically adjusting access control rules according to the dynamic environment and policies.

[0026] Furthermore, the system implementing the above method includes multiple processors, storage devices, and at least one network interface. The software is configured to run on the processors and includes program code corresponding to each technical module. This configuration enables the system to effectively protect against complex network attacks while maintaining the flexibility and efficiency of network operations.

[0027] The traffic interception module includes: The primary function of the driver interception submodule is to "hook" network traffic entering and leaving the client at the operating system kernel level. This module determines which traffic is allowed by detecting network packets and comparing them with a predefined list of applications. This method allows the module to precisely control traffic generated by specific applications, ensuring that only legitimate and secure applications can access network resources. This module is also responsible for deciding whether traffic should be forwarded directly or bypassed based on rules. When traffic originates from unauthorized applications, this module can block this traffic from entering the network or redirect it to a secure processing stage for further inspection or logging. The route interception submodule intercepts packets by modifying the iptables rules of the network device. This module operates closer to the network infrastructure, directly manipulating the routing of IP packets, enabling global control over data flow. By customizing iptables rules, this module can flexibly direct traffic, whether by redirecting to specific ports, blocking suspicious inbound or outbound requests, or completely discarding packets that do not comply with security policies. Furthermore, the route interception submodule can work closely with the driver interception submodule to form a two-layer defense mechanism.

[0028] After the deployment of the network access control technology based on the Single Packet Authorization (SPA) mechanism, before sending an access request, the user or device must generate a single data packet containing all necessary authentication information. This includes, but is not limited to, user credentials, timestamps, and access request details. All of this information is encrypted using strong encryption algorithms to ensure the security and integrity of the information during transmission. The receiving gateway or access controller is configured with dedicated software to identify and process such authorization packets. When a single packet authorization request is received, the system first decrypts the data packet and then verifies the validity of the credentials and timestamps contained within. If the verification is successful, the system will decide whether to allow or deny access to the specified resource based on preset security policies and permission settings. This process is completed almost in real time, greatly reducing the time latency in conventional multi-step authentication processes.

[0029] After forwarding network traffic using the tun2socks-based network traffic forwarding mechanism, tun2socks first utilizes TUN / TAP virtual network devices to capture outbound traffic generated by the devices. The TUN device handles network layer packets, while the TAP device handles data link layer frames. This method allows tun2socks to access almost all types of network traffic originating from the operating system. The captured packets are then encapsulated in SOCKS protocol format. SOCKS is a widely supported network protocol that allows packets to be forwarded through a proxy server, during which authentication and encryption can be implemented, enhancing data security. The encapsulated data is then forwarded through a configured SOCKS proxy server. This allows tun2socks to securely transmit data to the target server or service across network barriers (such as firewalls). This approach is particularly suitable for environments that require bypassing network restrictions or enforcing specific network policies.

[0030] After issuing a digital certificate based on a local self-signature, tools such as OpenSSL can be used to generate a public and private key pair locally, and then use these keys to generate a self-signed certificate. This process includes filling in the certificate subject, such as the organization name, common name (CN, usually the server's domain name or IP address), and other information. Once the self-signed certificate is generated, it can be installed on any server requiring secure communication. By specifying the use of this certificate and the corresponding private key in the server configuration, HTTPS service can be enabled, thereby encrypting communication between the client and the server.

[0031] Entropy weight-based access proxy technologies include: proxy plugin scheduling technology, including application identification plugins, application protection plugins, identity recognition plugins, authorization determination plugins, rate limiting and speed limiting plugins, and load balancing plugins; API hot reloading technology; authorization control technology; and API rate limiting and speed limiting technology.

[0032] The proxy plugin scheduling technology employs the following methods: Application identification plugin: identifies the accessing application through HTTP request parameters, supporting fine-grained matching based on domain name, URL parameters, header attributes, cookie attributes, etc.; unmatched requests are rejected. Application protection plugin: matches the application with the configured policy and the current request context, executing corresponding policies such as denying access or logging. Identity recognition plugin: extracts the application access token from the access request to identify the user's identity information; requests without a valid access token are rejected. Authorization determination plugin: combines the application access token and request context information for access control; authorized requests are allowed, otherwise they are blocked and logged. Rate limiting plugin: matches the application with the configured policy and the current request context, executing rate limiting measures such as denying access or returning a specific status code. Load balancing plugin: performs load balancing for applications configured with multiple addresses, supporting algorithms such as round-robin, source IP hash, and specified parameter hash.

[0033] API hot-reloading technology works as follows: The API proxy system listens for change events in configuration storage (such as etcd). Once a change in configuration information is detected, the system immediately triggers an update process. This process involves pulling the latest configuration data from the configuration storage, processing and transforming this data in memory to adapt it to the API proxy's runtime environment. The updated configuration is then applied to the proxy system without restarting or reloading the Nginx server, thus avoiding service interruptions and performance degradation.

[0034] The authorization control technology employs the following approach: The system first uses an efficient caching mechanism (such as the LRU algorithm) in memory to query the access-token carried in the request. If a valid access-token is not found in memory, the system will switch to the locally deployed Redis cache service. Redis, as a high-speed key-value store, provides fast data access capabilities and can handle a large number of concurrent requests. In Redis, the access-token is usually cached along with related authorization information for rapid verification. When the corresponding access-token is not found in the local cache, or the found token is invalid, or the key information associated with the token is inconsistent with the context of the current request, the API proxy system will initiate an authorization request to the authorization subsystem. The authorization subsystem is responsible for handling authentication and authorization logic. It verifies the legality of the request and decides whether to authorize access based on preset security policies. After real-time analysis, the authorization subsystem calculates which access-tokens are affected by factors such as user state changes, organizational structure changes, policy updates, or abnormal behavior. For access tokens that need to be revoked, the authorization subsystem sends an instruction to the API proxy system, which then performs the corresponding revocation operation to ensure that the system's access control is always up-to-date. Once the authorization request is successful, the new authorization result is cached in local Redis so that subsequent requests can be quickly verified, thereby reducing the frequency of requests to the authorization subsystem and improving the overall performance of the system.

[0035] API rate limiting technology employs the following methods: The system configures request rate thresholds (rate) and burst rate thresholds (burst). When the request rate of a single user or IP address exceeds the set rate, the system will delay additional requests to reduce the overall request rate. If the request rate exceeds rate plus burst, the system will begin rejecting requests and may return a specific HTTP status code, such as 429 (Too Many Requests). The system also sets concurrent connection thresholds (conn) and burst concurrency thresholds (burst). When the number of concurrent connections for a user or IP address exceeds conn, additional connection requests are either placed in a waiting queue or rejected outright to prevent system overload. If the number of concurrent connections exceeds conn plus burst, the system will reject new connection requests. By configuring a time window (time_window) and a request count threshold (count), the system can control the total number of requests within a specific time period. For example, if a user sends more requests than the set count within one minute, the excess requests will be rejected until the time window resets.

[0036] The second embodiment of the present invention will be described below.

[0037] like Figure 1 As shown, traffic interception technology is used to intercept data traffic within the business channel through driver interception and routing interception techniques.

[0038] Driver-intercepted technology hooks into client traffic and redirects it to the client. Upon arrival, the client checks the application list obtained during login. If the application's IP address and port match the list, the traffic is forwarded to the tap's PRD (Programmable Request Depository); otherwise, it is bypassed. The client forwards the authorization request and corresponding traffic to the PRD. During the authorization process, the PRD obtains the backend application's real address based on the authorization response, establishes a connection with the backend application, and then forwards the data stream over the communication channel.

[0039] Routing interception technology achieves data interception by creating a virtual network interface card (NIC) and modifying iptables to redirect data to the virtual NIC. The iptables firewall operates at the network layer, filtering and restricting TCP / IP packets. Implemented in kernel code, iptables boasts highly stable performance and efficiency, and is a user-space firewall management system.

[0040] The Raw table is primarily used to configure whether packets are processed by iptables' connection tracking mechanism; the Prerouting chain is used to determine whether packets bypass state tracking.

[0041] Mangle table: Used to modify packet content, such as Type of Service (TOS) and Time to Live (TTL). Processing points include Prerouting, Input, Output, Forward, and Postrouting, covering almost all processing stages.

[0042] The NAT table is primarily used for address translation, including Source Address Translation (SNAT) and Destination Address Translation (DNAT). The Prerouting chain is used for destination address translation; the Output chain handles destination address translation for locally generated packets. The Postrouting chain performs source address translation.

[0043] Filter table: Used to determine the fate of data packets, such as whether to accept, reject, or drop them. It includes the Input, Output, and Forward chains, which directly affect whether data packets can be accepted, forwarded, or sent.

[0044] When traffic arrives, packets first enter the Prerouting chain, where NAT table processing, such as destination address translation, is mainly performed. Next, the packet's destination is determined by the route, which may involve local processing (Input chain) or forwarding (Forward chain). Locally generated packets pass through the Output chain, where source address translation, also based on the NAT table, may occur. Finally, all packets leaving the host pass through the Postrouting chain for final processing, such as source address translation.

[0045] like Figure 1 The diagram illustrates the process of iptables in network data processing.

[0046] Inbound packets: Packets sent from outside the local machine (such as web requests) are passed to the Input chain after passing through Prerouting and possibly NAT, based on routing decisions, to determine whether they are allowed to enter the local machine.

[0047] Forwarding data packets: Data packets from the outside need to be forwarded to the internal network or other destinations, such as QQ messages from one subnet to another, which are processed through the Forward chain.

[0048] Outbound packets: Locally generated packets such as DNS requests undergo necessary NAT processing and final preparation for transmission via Output and Postrouting.

[0049] like Figure 2 As shown, port hiding technology, as one of the most critical technologies in entropy weighted channel control, aims to overcome the fundamental open and insecure nature of Transmission Control Protocol / Internet Protocol Address (TCP / IP) to achieve zero trust. This feature allows for "connection first, authentication later," meaning that applications using the entropy weighted architecture can only reliably access services through authorized users, while unauthorized users cannot see these services; that is, all unauthorized network traffic is discarded by default. Only packets that have been authenticated and authorized by the SPA can trigger rules and gain network access.

[0050] like Figure 3As shown, Single Packet Authorization (SPA) is a core network security protocol for achieving zero-trust port hiding. It verifies the identity of devices and users before allowing access to the network containing controllers, gateways, and other related system components, implementing the zero-trust "authenticate first, then connect" security model. To address potential attacks and further enhance security, SPA technology can be used to hide ports for two types of proxies.

[0051] An SPA contains connection request information, including the requester's IP address, encrypted and authenticated within a single network message. By configuring a default-drop firewall policy, the protected service is made invisible to the outside world. The purpose of an SPA is to allow the server firewall to hide and be dropped by default. This firewall system should drop all TCP and User Datagram Protocol (UDP) packets and not respond to connection attempts, thus providing potential attackers with no information about whether the port is being listened to.

[0052] When a user attempts to access the service, their identity, device, and network information are first verified. Then, the user is allowed network access to the zero-trust system component management platform and SDP gateway. Only then is the user granted access to the service. Therefore, SPAs are indispensable for SDP, used for communication between clients and controllers, gateways and controllers, and clients and gateways.

[0053] SPA implementation principles: (a) Data packets must be encrypted and authenticated; (b) Data packets must contain all necessary information on their own; individual data packets are not trusted. (c) The generation and transmission of data packets must not depend on administrator or underlying access permissions, and the original data packets must not be tampered with; (d) The server must receive and process data packets as silently as possible, without sending responses or acknowledgments. Technically, this requires the server to pre-distribute the encryption keys (HMAC key and AES key) to the client, and then the client will perform an SPA knock before initiating any access.

[0054] The SPA packet format references the TLS 1.2 (RFC5246) record protocol format, providing confidentiality (AES encryption) and integrity (HMAC hash) protection. Clients and application agents use the same AES and HMAC keys to encrypt and verify SPA packets. The plaintext data of the SPA packet includes information such as a timestamp, a random string, and a device ID, among which: (a) Timestamps can be used to limit the time difference between the client and the agent; (b) Random strings can be used for replay protection checks, and the same random string cannot appear within a certain period of time; (c) The device ID can be used to check the trustworthiness of the device; It is worth noting that after successfully establishing contact, when subsequently initiating access to business resources, the client still needs to include new SPA data in the TLS packet extension during interaction with the application proxy. This prevents attackers hiding behind the same IP address from attacking temporarily opened TCP ports. Figure 3 As shown.

[0055] like Figure 4 As shown, SPAs (Application Service Providers) use firewalls to control application access to authorized network data packets, thereby achieving the goal of controlling network access. SPA services mainly have the following technical characteristics.

[0056] (a) No listening port: Using the eXpressData Path (XDP), communication data packets are directly obtained from the network card driver layer, and the packet content is processed directly. Scanners cannot detect the listening port, thus preventing pre-attack scanning and eliminating attacks on specific business services at the source. The no-listening-port method only requires the SPA to capture packets directly at the network layer and parse UDP network packet content; it does not require the application service to actually listen on a network port.

[0057] (b) Supports large network traffic processing: XDP technology has very high performance and can approach the bandwidth limit of the network card, especially in resisting DDoS attacks.

[0058] (c) Supports management strategies for tens of millions of users: Using source IP, destination IP and destination port, the network is managed by a hash algorithm based on the service identifier, which can support management strategies for tens of millions of users.

[0059] (d) More Secure SPA First Packet Authentication Protocol: SPAD uses a custom SPA protocol. Security is enhanced through the use of personalized signature and message encryption algorithms, as well as a MAC algorithm.

[0060] (e) Supports high-availability cluster deployment: Management strategies use NoSQL, MySQL and other storage, and support multi-node cluster deployment.

[0061] Deploy a zero-trust access proxy platform at the network entry point, closing all ports by default and rejecting all TCP and UDP connections. The proxy platform only opens ports to the user's IP address after the user has verified their identity using SPA technology. In this way, users with unknown identities cannot easily probe the enterprise's publicly accessible server ports.

[0062] By default, the access proxy closes all ports. Users must log in to the zero-trust client after authenticating through a configuration file (profile) in order to connect to the target server via SPA knocking.

[0063] like Figure 5 As shown, when knocking on the port, a UDPSPA packet carrying the device identifier and a random number encrypted string is sent via the UDP protocol. After the UDP opens the port and establishes a TCP connection, a TCPSPA packet carrying the device identifier and a random number encrypted string needs to be sent to knock on the port. If the knocking is successful, the current connection is allowed to be established.

[0064] Single-packet authorized port knocking: Port knocking involves sending a specific sequence of connection attempts. If the server deems the sequence of attempts legitimate, it will allow (authorize) the client to initiate a connection. Single-packet authorized port knocking achieves the knocking effect by sending only a single knocking packet, thus avoiding potential out-of-order issues associated with multiple knocking packets. The data in the single packet is encrypted, and only authorized users can initiate the connection. Furthermore, the allowed connection data also includes single-packet authorization authentication data to further ensure the client's legitimacy. Implementing this functionality requires a knocking client and a knocking server. The client uses the dTLS protocol, and an extension is added to ClientHello to send encrypted knocking data to the knocking server for port knocking.

[0065] Taking a user accessing port 80 of the target server as an example, the knocking process is as follows: (a) The proxy platform is deployed before the target server to proxy all traffic sent to the target server; (b) Before accessing port 80, the client first sends a UDP packet containing user identity information to port 60000 of the proxy platform (port 60000 is a port agreed upon in advance by the client and the proxy platform, and can be changed to other ports). (c) The proxy platform receives UDP packets but does not respond. (d) The proxy platform verifies the user's identity information in the UDP packet; (e) After successful verification, temporarily grant TCP port access permissions to the source IP of the legitimate user / device; (f) TCP three-way handshake to establish a connection; (g) Send a TLS client hello handshake packet to initiate the connection; (h) Verify the SPA packet information in the TLS client hello extended field; (i) After successful verification, the proxy platform opens port 80 to the user's IP address; (j) When a client accesses port 80 of the target server, the traffic is forwarded to the proxy platform; (k) Since the proxy platform's port is already open, it can continue to forward the message to the real target server; (l) The user and the target server have successfully connected; (m) Subsequently, all data packets used by the user to communicate with the target server carry user information through the client hello extended field. If the proxy platform fails to verify the connection, the connection will be interrupted.

[0066] The steps for using SPA technology to protect access to critical internal services are described below.

[0067] Enterprise Mail Server: The enterprise mail server is configured to accept SPA requests only from authenticated devices. Any device attempting to connect to the mail server must first send an encrypted and authenticated SPA packet. This packet contains the device's authentication information and a request timestamp. The mail server's firewall checks this information, and if it is correct, dynamically opens a TCP port, allowing the device to establish a mail service session.

[0068] Remote database access: The database server is not directly exposed to the internet; access is granted only by internal network requests that send valid SPA packets. This reduces the risk of the database being exposed to potential cyberattacks and ensures that only authorized users or systems can access sensitive data.

[0069] like Figure 6-7 As shown, tun2socks is a network forwarding tool that utilizes virtual network interfaces (TUN / TAP) and SOCKS proxy servers to forward network traffic. This allows applications to route their traffic through a SOCKS proxy even if they do not directly support it.

[0070] Traffic forwarding technology uses tun2socks to implement a mechanism that can encapsulate data in the socks protocol and forward it to a socks proxy without modifying any application. The proxy program is then responsible for forwarding application data between the proxy and the real server.

[0071] like Figure 6 As shown, a socks protocol header is wrapped around the TCP data. After arriving at the socks proxy server, the socks header is removed, and then the raw TCP data is transmitted to the real server through the connection established between the socks server and the real server.

[0072] like Figure 7 As shown, tun2socks can be broken down into three parts: the tun network interface card part, the protocol processing part, and the socks conversion part. These three parts are processed sequentially in the tun2socks process.

[0073] (a) TUN network interface card section: This section solves a fundamental problem, namely "how to obtain raw data packets".

[0074] (b) Protocol processing section: tun2socks uses the tun network card to directly capture raw data packets into an application. It uses tun to capture data packets, processes logic above the IP layer, and compares the captured packets with those processed by the protocol stack.

[0075] tun2socks uses the readily available lwip to handle protocol processing.

[0076] like Figure 8 As shown, this invention illustrates secure connection technologies, particularly the implementation of local HTTPS services. It provides methods for setting up HTTPS services locally and ensuring these services function correctly even without an internet connection, especially when using addresses such as localhost or local IP addresses.

[0077] Secure connection technology provides locally self-signed certificates, making HTTPS services trustworthy in the local environment. It can authorize multiple local addresses, such as the IPv4 loopback address 127.0.0.1, the IPv6 loopback address [::1], the local domain localhost, and other custom domains. It uses an entropy weighting method to weight different access control factors, quantifying the importance of the local self-signature for access control. Ultimately, the trustworthiness of the service is determined by user authorization, giving the power to the user.

[0078] Front-end and back-end separation is a very popular development model for current internet software and client software. For client software using HTTPS as a local service, the front-end (including browser web pages, mobile client software, desktop client software, etc.) communicates with the back-end by calling RESTful APIs. The back-end is deployed locally, providing basic and general services such as information processing, network communication, and data storage. The front-end and back-end typically access each other through local addresses such as 127.0.0.1 or the localhost domain. When developing a local HTTPS service, if an untrusted authentication authority is used, the system will throw an exception. For example, JavaScript connections to untrusted services will be blocked, preventing requests for necessary services; similarly, browsers accessing untrusted services will redirect to a warning page, requiring users to authorize a whitelist. These processes cause significant inconvenience to users when using the software.

[0079] The client program publishes an HTTPS backend service locally, and the frontend program accesses the service interface through a specified address to make function calls.

[0080] Users authorize once during deployment and do not need to authorize again during subsequent use.

[0081] Local trusted services are only valid after authorization by the local user and will not affect the status of other terminals or unauthorized users on the same terminal.

[0082] When a backend service (local HTTPS service) is published on the terminal, a publishing certificate needs to be specified. Different certificate statuses directly affect the results of frontend programs (clients, browsers) requesting the service.

[0083] Non-local trusted certificates refer to certificates whose issuers are not in the trusted certificate store of the local operating system. Services published with this type of certificate will display a message such as "This website's security certificate has a problem" or "This site is not secure" when opened in a browser, requiring user authorization to access. A locally trusted certificate refers to a certificate whose issuer stores it in the trusted certificate store of the local operating system. Its trusted status is only valid locally and cannot affect remotely published services. Services published with this type of certificate will display a site security icon when accessed by a browser. When accessing suspicious (untrusted certificate issuance) services, the operating system or browser will pop up an interface requesting user authorization. If the user authorization is approved, the site will be added to the user's whitelist; otherwise, the user will remain on a warning or pending authorization page.

[0084] Importing trusted certificates allows users to import self-signed digital certificates into the root certificate authorities trusted by their current account using certificate tools or authorized software installation packages.

[0085] In one StarNet implementation, the gateway acts as a security barrier to manage and control API access, ensuring the security of data transmission. The gateway safeguards encryption and integrity during data transmission by implementing layered security protocols such as TLS / SSL. Furthermore, API security management includes precise access control, authentication, and Access Control Lists (ACLs) to prevent unauthorized access and data leakage.

[0086] like Figure 9 The following describes the proxy plugin scheduling technology provided by the present invention.

[0087] Application identification plugin: Identifies the accessed application based on HTTP request parameters. It supports fine-grained parameter matching of domain name and HTTP request URL parameters, header attributes, and cookie attributes. For requests that cannot be matched, they are marked as unidentified applications and access is denied. The identified application identification information is placed in the request context for use by subsequent plugins. Application protection plugin: Matches the configured policy with the context of the current request, and executes the policy according to the match. The actions include denying access and logging access. Identity verification plugin: Extracts the identity information of the accessing party by carrying the application access token in the access request. Access is denied if a valid application access token is not carried. The subject identity information includes user information, device information, and the identified subject information. It is placed in the request context and provided to subsequent plugins for use, such as audit logs. Authorization determination plugin: Based on the application access token and the context information of the access request, and in conjunction with the TAC, access control is performed. Requests that are authorized are allowed to pass, requests that fail to be authorized are blocked, and logs are recorded. Rate limiting plugin: Matches the configured policy with the context of the current request, and performs the corresponding action according to the matched policy. The actions include denying access, returning a specific status code, logging access, etc. Load balancing plugin: For applications configured with multiple addresses, it supports load balancing algorithms such as round-robin, source IP hash, and specified parameter hash.

[0088] like Figure 10 As shown, the operation of a plugin depends on configuration information (management state) and request context information (runtime state). When the configuration changes, the API proxy system needs to update the configuration information in a timely manner without affecting the current request processing. The following describes the plugin information hot-loading technology provided by this invention.

[0089] The API proxy system uses an updated mechanism that can perform hot reloading in real time based on changes. The entire process does not require Nginx to be reloaded, and there is no impact on access requests during hot reloading.

[0090] The main configuration information affecting plugin operation includes resource configuration information and policy configuration information. Resource configuration information includes application and API information; the API proxy system only allows authorized users to access these API resources. Policy configuration information includes application protection policies and rate limiting policies; the API proxy system enforces these policies on requests.

[0091] The API proxy system's configuration proxy plugin is responsible for receiving and processing synchronization information from the authorization subsystem. The relevant configuration information is processed and transformed and written to the etcd configuration library to complete the admin-time configuration update. The runtime plugin listens for etcd configuration changes. Once the configuration changes, it immediately refreshes the cached context information in the Lua runtime, so that nginx does not need to reload and the configuration can take effect in real time.

[0092] like Figure 11As shown, an online e-commerce platform needs to handle a large number of user login and product query requests. Redis is used to store user information, shopping cart data, and product inventory information. The most frequently accessed product information and user login status are stored in an LRU cache to improve access speed. Access token verification is implemented for all API requests to ensure that each request is initiated by a legitimate user, preventing unauthorized access. Under high access pressure, this multi-level caching strategy quickly responds to user requests while protecting the database from overload.

[0093] like Figure 12 As shown, the plugin rate limiting and speed limiting technology provided by this invention is further introduced. Online retail platforms face numerous attacks from automated scripts and web crawlers, which attempt to obtain product information or conduct price comparisons. Platforms can deploy the following defense measures: setting trigger rules to rate limit all requests originating from specific regions or known malicious IPs, automatically triggering alerts and denying service for abnormally frequent access patterns; implementing dynamic responses, automatically enabling additional verification steps, such as requiring CAPTCHA confirmation, or temporarily blocking all requests from that IP when abnormal request frequency is detected; and enhancing monitoring by analyzing access logs in real time through an integrated Kafka system, using machine learning algorithms to predict and identify potential attack patterns, and adjusting defense strategies promptly.

[0094] In summary, this invention provides a channel control system based on the entropy weight method. It adopts the security model concept of "authentication first, connection later" and can overcome the open and insecure basic characteristics of the existing Transmission Control Protocol / Internet Protocol Address (TCP / IP) which allows "connection first, authentication later". The application of the entropy weight method architecture ensures that only authorized users can reliably access the service, while unauthorized users cannot see these services. In other words, all unauthorized network traffic is discarded by default, achieving a zero-trust effect.

[0095] Please note that the technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification. The above embodiments only illustrate several implementations of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the invention patent. It should be pointed out that for those skilled in the art, several modifications and improvements can be made without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of the present invention should be determined by the appended claims.

Claims

1. A channel control system based on the entropy weight method, characterized in that, The system includes: The traffic interception module is configured to automatically identify and block unauthorized traffic using preset security policies, and all incoming and outgoing data streams must meet security requirements. The port hiding module is configured to encrypt and hide all network ports by implementing single-packet authorization technology, making the ports completely invisible to unauthorized requests and avoiding malicious scanning and reconnaissance activities. The traffic forwarding module is configured to use tun2socks technology to process and forward authenticated and authorized data, and to achieve secure data routing by creating virtual network interfaces and configuring transparent proxies. The secure connection module is configured to: establish an encrypted connection based on access control factors and a local self-signed certificate to achieve end-to-end data transmission security, and use encryption algorithms to protect the confidentiality and integrity of data during transmission; The access proxy module is configured to: implement access control and policy scheduling based on the entropy weight method, use a decision engine to evaluate and manage access requests in real time, and automatically adjust access control rules according to the dynamic environment and policies.

2. The channel control system based on entropy weight method according to claim 1, characterized in that, The traffic interception module includes: The driver interception submodule is configured to: hook network traffic entering and leaving the client at the kernel level of the operating system; determine the traffic allowed to pass by detecting network packets and comparing them with a predefined list of applications; and block traffic from entering the network when it comes from an unauthorized application, or redirect it to a secure processing node for further inspection or logging. The routing interception submodule is configured to: intercept data packets by modifying the iptables rules of network devices; and direct traffic by customizing iptables rules, including: redirecting to specific ports, intercepting suspicious inbound or outbound requests, and completely discarding data packets that do not comply with security policies.

3. A channel control system based on entropy weight method according to claim 2, characterized in that, The port hiding module is specifically configured as follows: After the deployment of network access control technology based on single-packet authorization mechanism is completed, and before sending access request, a single data packet containing all necessary verification information is generated. The data in this data packet includes user credentials, timestamp, and access request. The data in this data packet is encrypted using a strong encryption algorithm to ensure that the data is not lost or tampered with during transmission. The receiving gateway or access controller identifies and processes authorization packets. When a single packet authorization request is received, it first decrypts the data packet and verifies the validity of the credentials and timestamp contained therein. If the verification is successful, it allows or denies access to the specified resource according to the preset security policy and permission settings.

4. A channel control system based on entropy weight method according to claim 3, characterized in that, The traffic forwarding module is specifically configured as follows: After completing the network traffic forwarding mechanism based on tun2socks technology, the outbound traffic generated by the device is captured using the TUN / TAP virtual network device. The TUN device processes network layer packets, while the TAP device processes data link layer frames, allowing tun2socks to access all types of network traffic originating from the operating system. Captured packets are encapsulated in SOCKS protocol format, allowing packets to be forwarded through a proxy server, during which authentication and encryption are implemented. The encapsulated data is forwarded through a configured SOCKS proxy server, allowing tun2socks to cross network barriers and transmit data to target servers or services, thereby bypassing network restrictions or enforcing specific network policies.

5. A channel control system based on entropy weight method according to claim 4, characterized in that, The secure connection module is specifically configured as follows: After completing the issuance of a digital certificate based on local self-signature, use the OpenSSL tool to generate a public key and private key pair locally, and use the key to generate a self-signed certificate. After the self-signed certificate is generated, install it on the server that requires secure communication, specify the use of the certificate and the corresponding private key in the server configuration, and enable HTTPS service to encrypt the communication between the client and the server.

6. A channel control system based on entropy weight method according to claim 5, characterized in that, The access proxy module is configured to perform: proxy plugin scheduling, API hot reloading, authorization control, and API rate limiting. The plugins involved in the proxy plugin scheduling process include application identification plugins, application protection plugins, identity recognition plugins, authorization determination plugins, rate limiting plugins, and load balancing plugins.

7. A channel control system based on entropy weight method according to claim 6, characterized in that, For plugins involved in the proxy plugin scheduling process: Application identification plugin: Identifies the accessed application through HTTP request parameters, supporting fine-grained matching of domain name, URL parameters, header attributes, and cookie attributes, and rejecting unmatched requests; Application protection plugin: Matches the configured policy with the context of the current request and executes the corresponding policy, including denying access or logging; Identity verification plugin: Extracts the application access token from the access request to identify the user's identity information; requests without a valid access token will be rejected. Authorization determination plugin: Combines application access token and request context information for access control. Requests that are authorized will be allowed to pass, while those that are not will be blocked and logged. Rate limiting plugin: Matches the configured policy with the context of the current request and executes rate limiting measures, including denying access or returning a specific status code; Load balancing plugin: Performs load balancing for applications configured with multiple addresses, supporting round-robin, source IP hashing, and hash algorithms with specified parameters.

8. A channel control system based on entropy weight method according to claim 7, characterized in that, For API hot reloading: The API proxy listens for change events in the configuration store. When it detects a change in the configuration information, it immediately triggers an update process, which includes: pulling the latest configuration data from the configuration store, processing and transforming it in memory to adapt to the API proxy's runtime environment; and applying the updated configuration to the proxy system without restarting or reloading the Nginx server, thereby avoiding service interruption and performance degradation.

9. A channel control system based on entropy weight method according to claim 8, characterized in that, Regarding authorization control: The system uses a caching mechanism in memory to query the access token carried in the request. If a valid access token is not found in memory, it switches to the locally deployed Redis caching service. In Redis, the access token is cached along with the associated authorization information. When the corresponding access token is not found in the local cache, or the found token is invalid, or the key information associated with the token is inconsistent with the context of the current request, the API proxy will send an authorization request to the authorization subsystem. The authorization subsystem is responsible for handling authentication and authorization logic, verifying the legitimacy of the application and deciding whether to authorize access based on the preset security policy; After performing real-time analysis, the authorization subsystem calculates which access tokens are affected by changes in user status, organizational structure, policy updates, or abnormal behavior. For access tokens that need to be revoked, the authorization subsystem issues an instruction to the API agent, which will perform the corresponding revocation operation to ensure that the system's access control is always up-to-date. Once the authorization request is successful, the new authorization result is cached in the local Redis for subsequent request verification.

10. A channel control system based on entropy weight method according to claim 7, characterized in that, Regarding API rate limiting and throttling: Configure request rate threshold and burst rate threshold; when the request rate of a single user or IP address exceeds the set rate, additional requests are delayed to reduce the overall request rate; when the request rate exceeds the sum of rate and burst, requests are rejected and a specific HTTP status code is returned. Set a concurrent connection threshold `conn` and a burst concurrency threshold `burst`. When the number of concurrent connections for a user or IP address exceeds `conn`, additional connection requests are placed in a waiting queue or rejected directly to prevent system overload. When the number of concurrent connections exceeds the sum of `conn` and `burst`, new connection requests are rejected. By configuring the time window (time_window) and the request count threshold (count), the total number of requests within a specific time period can be controlled. When a user sends more requests than the set count within one minute, the excess requests are rejected until the time window is reset.

Images