A zero-trust network authorization method and system based on DNS

Abstract

The invention discloses a zero-trust network authorization method and system based on DNS, and the method includes: obtaining a request sent by a client to a DNS server, identifying the source IP address of the client and sending it to a controller; if the source IP address of the client meets the firewall rules of the SPA knocking port, the DNS server synchronizes the TXT value corresponding to the controller domain name and returns it to the client; the client sends an SPA message and a login request to the controller, the controller decrypts and verifies the SPA message, the login is successful, the client sends an SPA message to the gateway, the gateway decrypts and verifies the SPA message, after the verification is passed, the client initiates a request to the gateway to establish a tunnel, if the request meets the firewall rules of the service port opened by the gateway, then a tunnel between the client and the gateway is established. The invention adopts a DNS server to hide the controller and the gateway server, so as to achieve the purpose of resisting DDOS attacks.

Description

Technical Field

[0001] The present invention relates to the technical field of zero-trust network authorization, and in particular to a zero-trust network authorization method and system based on DNS. Background Art

[0002] In recent years, "zero trust" has become a hot word in the security circle. Zero trust is a security concept. To fully realize zero trust, it is necessary to ensure that user terminals, user identities, links, gateways, and application resources are trustworthy. Enterprises can introduce different product components to build their own zero trust solutions based on their own organizational structure, business processes, and work scenarios. Currently, there are three common zero trust solutions: zero trust based on identity governance (IAM), zero trust based on micro-isolation, and zero trust based on software defined perimeter (SDP).

[0003] SDP is a new generation of network security model based on the concept of Zero Trust proposed by the International Cloud Security Alliance CSA in 2013. It is mainly composed of three components: 1) Initiating SDP Host, referred to as IH, i.e. client; 2) Accepting SDP Host, referred to as AH, i.e. gateway; 3) SDP Controller, i.e. controller. The relationship between the three components is divided into two planes: 1) control plane and 2) data plane. Both the gateway and the client are connected to the controller. The connection between the client and the gateway is managed through the interaction between the controller and the security control channel. This structure enables the control plane to be separated from the data plane in order to achieve a fully scalable security system.

[0004] In the SDP architecture design, the client needs to complete network authentication through Single Packet Authorization (SPA) before connecting to the controller and gateway. The controller and gateway will only open the corresponding service port to the client that has passed the SPA authentication. Figure 1 The specific steps are as follows:

[0005] ① The client (IH) sends an SPA message to the controller, and the SPA module of the controller determines whether it is a legitimate client. If it is a legitimate client, only the authentication service port is opened to the client's corresponding IP;

[0006] ② Since the SPA module of the controller does not return any response, the client actively initiates an authentication request attempt after sending the SPA message;

[0007] ③ After the client completes the authentication, it obtains the authorization gateway from the controller;

[0008] ④ The client sends a SPA message to the gateway, and the SPA module of the gateway determines whether it is a legitimate client. If it is a legitimate client, the service port is only opened to the client's corresponding IP;

[0009] ⑤ The client attempts to establish a tunnel connection with the gateway; if SPA authentication is successful, the port is opened and the tunnel between the client and the gateway is successfully established;

[0010] ⑥ After the tunnel is successfully established, users can access the application resources protected by the gateway through the client.

[0011] At present, in the zero-trust SDP architecture, single-packet authentication achieves the purpose of hiding the port by listening to the UDP port and only receiving UDP messages but not replying. However, this solution still listens to a UDP port on the server, and all messages sent to this port will be decrypted and judged whether they meet the format requirements of SPA. Therefore, attackers can still use this port to attack, so this solution can only delay DDOS attacks, but cannot completely protect against them. Summary of the invention

[0012] Purpose of the invention: The purpose of the present invention is to address the deficiencies in the prior art and provide a DNS-based zero-trust network authorization method and system to solve the problem of UDP port exposure, thereby making the controller and gateway server completely invisible, thereby completely solving the threat of DDOS.

[0013] Technical solution: The DNS-based zero-trust network authorization method of the present invention comprises: obtaining a request sent by a client to a DNS server for querying a TXT value corresponding to a controller domain name, and the DNS server identifies the source IP address of the client and sends it to the controller;

[0014] The controller opens the firewall rule of the SPA knocking port for the client. If the source IP address of the client meets the firewall rule of the SPA knocking port, the client is allowed to perform knocking verification. The DNS server obtains the TXT value currently corresponding to the controller domain name and returns it to the client.

[0015] The client sends a SPA message to the controller according to the TXT value corresponding to the returned controller domain name, and the controller decrypts and verifies the SPA message. After the verification is passed, the controller opens the firewall rules of the service port to the client;

[0016] The client initiates a login request to the controller, and returns a login result to the client according to the firewall rules of the service port opened by the controller;

[0017] If the login result is successful, the client sends a SPA message to the gateway, and the gateway decrypts and verifies the SPA message. After the verification is passed, the gateway opens the firewall rules of the service port to the client;

[0018] The client initiates a request to the gateway to establish a tunnel. If the request complies with the firewall rules of the service port opened by the gateway, a tunnel is established between the client and the gateway;

[0019] The user initiates a request to access the application resources managed by the gateway through the client, and the gateway returns the access result of the application according to the user's authority.

[0020] To further improve the above technical solution, in order to ensure security, the TXT value corresponding to the controller domain name is updated regularly, and the time interval can be customized.

[0021] Furthermore, the TXT value corresponding to the controller domain name is generated based on a hash value obtained by performing a hash calculation on the timestamp+the hardware feature code of the controller.

[0022] Furthermore, the SPA message sent by the client to the controller is encrypted by a SPA shared key, and the SPA shared key is a TXT value corresponding to the domain name of the controller.

[0023] Furthermore, the controller determines whether the SPA shared key in the cache exists. If so, the SPA shared key is used to decrypt the SPA message sent by the client. If not, the DNS server is queried again to obtain the TXT value corresponding to the controller domain name as the key to decrypt the SPA message.

[0024] Furthermore, the SPA message sent by the client to the gateway is encrypted by a SPA shared key, and the SPA shared key is a TXT value corresponding to the controller domain name.

[0025] Furthermore, the gateway determines whether the SPA shared key in the cache exists. If so, the SPA shared key is used to decrypt the SPA message sent by the client to the gateway. If not, the DNS server is queried again and the TXT value corresponding to the controller domain name is used as the key to decrypt the SPA message.

[0026] A system for implementing the above-mentioned DNS-based zero-trust network authorization method includes: a client, a DNS server, a controller, and a gateway;

[0027] The DNS server is connected to the client and the controller in communication, respectively, and is used to obtain a request sent by the client to the DNS server for querying a TXT value corresponding to a domain name of the controller, identify a source IP address of the client according to the request and send it to the controller, the controller opens a firewall rule of the SPA knocking port for the client, and if the source IP address of the client meets the firewall rule of the SPA knocking port, the client is allowed to perform knocking verification, and the DNS server synchronizes the TXT value corresponding to the domain name of the controller and returns it to the client;

[0028] The client is connected to the controller for sending SPA messages and login authentication to the controller;

[0029] The controller is in communication with the DNS server and is used to obtain the SPA key to decrypt and authenticate the SPA message when the SPA key expires;

[0030] The client is connected to the gateway for communication, and is used to send a SPA message to the gateway, and establish a tunnel after the SPA message is authenticated;

[0031] The gateway is in communication connection with the DNS server and is used to obtain the SPA key to decrypt and authenticate the SPA message when the SPA key fails.

[0032] Furthermore, the controller manages and configures the DNS server, that is, the controller should be able to dynamically add and delete domain names and TXT values ​​of the DNS server, and can also be manually configured and updated through the page.

[0033] Further, the communication connection between the controller and the DNS server includes: the controller determines whether the SPA shared key in the cache exists; if so, the SPA shared key is used to decrypt the SPA message sent by the client; if not, the DNS server is queried again for the TXT value corresponding to the controller domain name as the key to decrypt the SPA message; the communication connection between the gateway and the DNS server includes: the gateway determines whether the SPA shared key in the cache exists; if so, the SPA shared key is used to decrypt the SPA message sent by the client to the gateway; if not, the DNS server is queried again for the TXT value corresponding to the controller domain name as the key to decrypt the SPA message.

[0034] Beneficial effects: Compared with the prior art, the advantages of the present invention are:

[0035] 1. The present invention adds a DNS server to the SDP architecture for pre-verification before the client accesses the controller. The client needs to first obtain the TXT value corresponding to the controller domain name from the DNS server. The DNS server interacts with the controller and opens the corresponding SPA knocking port for the client. The DNS server is used to hide the controller and the gateway server, thereby achieving the purpose of resisting DDOS attacks and making the controller and the gateway server more secure.

[0036] 2. The SPA shared key is implemented based on the TXT value of the controller domain name. The controller needs to support the scheduled update of the TXT value. The DNS server obtains the current TXT value from the controller, updates the TXT record of the controller domain name, and returns the latest TXT value to the client. Based on the dynamic change of the TXT value of the controller domain name, the dynamic update of the SPA shared key can be realized, which can not only hide the server port, but also increase the difficulty of cracking the SPA message, making the overall SDP architecture more secure and reliable. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 It is the traditional SDP architecture and interaction flow chart;

[0038] Figure 2 It is the SDP architecture and interaction flow chart of the zero-trust network authorization system based on DNS of the present invention;

[0039] Figure 3 It is an access flow chart of the zero-trust network authorization method based on DNS of the present invention. DETAILED DESCRIPTION

[0040] The technical solution of the present invention is described in detail below with reference to the accompanying drawings, but the protection scope of the present invention is not limited to the embodiments.

[0041] like Figure 2As shown, the DNS-based zero-trust network authorization system provided by the present invention includes a client, a DNS server, a controller, and a gateway. The DNS server is connected to the client and the controller in communication, and is used to obtain a request sent by the client to the DNS server for querying the TXT value corresponding to the controller domain name, and identifies the source IP address of the client according to the request and sends it to the controller. The controller opens the firewall rule of the SPA knocking port for the client. If the source IP address of the client meets the firewall rule of the SPA knocking port, the client is allowed to perform knocking verification. The DNS server synchronizes the TXT value corresponding to the controller domain name and returns it to the client; the client is connected to the controller in communication, and is used to send SPA messages and login authentication to the controller; the controller is connected to the DNS server in communication, and is used to obtain the SPA key to decrypt and authenticate the SPA message when the SPA key expires; the client is connected to the gateway in communication, and is used to send the SPA message to the gateway, and establish a tunnel after the SPA message authentication is passed; the gateway is connected to the DNS server in communication, and is used to obtain the SPA key to decrypt and authenticate the SPA message when the SPA key expires.

[0042] Based on the SDP architecture, a DNS server is introduced. Through the DNS server, special DNS messages from the client are received. Ordinary users will not be able to directly access the controller and gateway in the SDP architecture, including the UDP port that provides SPA services, which also avoids the controller and gateway in the SDP architecture from being attacked by DDOS, thereby screening and filtering illegal clients. The DNS server in the optimized SDP architecture should have the following functions: identify the DNS request sent by the client and send the source IP address of the client to the controller; regularly update the TXT value corresponding to the controller domain name, which should be generated based on time and remain unchanged for a period of time; the DNS server should be managed by the controller and support the management and configuration of the controller. The DNS server can also use other third-party modules (such as WeChat and DingTalk) to implement the dynamic SPA verification process, which should be regarded as the same solution.

[0043] When using the above system for access, the actual access process of the client will be safer, the servers corresponding to the controller and gateway will be completely hidden, and users will not be able to perceive the existence of the controller and gateway on the Internet, greatly reducing the risk of DDOS attacks. The specific access process Figure 3 As shown:

[0044] 1. The client (IH) queries the TXT value corresponding to the controller domain name from DNS;

[0045] 2. After receiving the query message, the DNS server analyzes the message and finds that it is from the client, and then sends the source IP address corresponding to the message to the controller;

[0046] 3. After receiving the source IP address of the DNS query, the controller will open the SPA firewall rules to the IP address and allow the client to perform SPA single packet authentication;

[0047] 4. After the DNS server completes the synchronization of the controller IP address, it returns the corresponding TXT value to the client;

[0048] 5. The client sends a SPA message to the controller. The encryption key of the message is the TXT value obtained by the controller domain name resolution.

[0049] 6. The controller determines whether the SPA key cache exists. If so, the SPA key is used.

[0050] 7. If the SPA key cache does not exist, the DNS server is used to resolve the TXT value corresponding to the domain name and use it as the key to decrypt the SPA message.

[0051] 8. The DNS server returns the TXT value corresponding to the domain name to the controller;

[0052] 9. After receiving the TXT value of the domain name, the controller decrypts the SPA message and opens the firewall of the corresponding service port for the client;

[0053] 10. After the client knocks on the door, try to log in to the controller;

[0054] 11. After the firewall rules are opened, the login results are returned;

[0055] 12. After the client successfully logs in, it sends a SPA message to the gateway;

[0056] 13. The gateway checks whether the SPA key cache exists, which is the same as the controller logic.

[0057] 14. If the cache does not exist, the gateway queries the DNS server for the TXT value of the controller domain name;

[0058] 15. The DNS server returns the corresponding TXT value;

[0059] 16. The gateway uses the TXT value as the SPA key to decrypt the SPA message. After verification, the firewall opens the service port to the client.

[0060] 17. After the client sends the SPA message, it can try to establish a tunnel with the gateway;

[0061] 18. If the firewall rules are already open, the gateway responds to the client's tunnel establishment request, and the client and gateway complete the tunnel establishment;

[0062] 19. After the client tunnel is successfully established, the user actively initiates a request to access the application;

[0063] 20. The gateway determines whether the user has permission to use the application;

[0064] 21. If the user has application permissions, the proxy application results are returned.

[0065] The present invention adopts a DNS server to hide the controller and the gateway server, so as to achieve the purpose of resisting DDOS attacks and make the controller and the gateway server more secure; in addition, based on the dynamic change of the TXT value of the controller domain name, the SPA shared key is dynamically updated, which can not only hide the ports of the controller and the gateway server, but also increase the difficulty of cracking the SPA message, making the overall SDP architecture more secure and reliable.

[0066] As described above, although the present invention has been shown and described with reference to specific preferred embodiments, it should not be construed as limiting the present invention itself. Various changes in form and details may be made without departing from the spirit and scope of the present invention as defined in the appended claims.

Claims

1. A zero-trust network authorization method based on DNS, characterized in that: The steps include: Obtain a request sent by the client to the DNS server for querying the TXT value corresponding to the domain name of the controller, and the DNS server identifies the source IP address of the client and sends it to the controller; The controller opens the firewall rule of the SPA knocking port for the client. If the source IP address of the client meets the firewall rule of the SPA knocking port, the client is allowed to perform knocking verification. The DNS server obtains the TXT value currently corresponding to the controller domain name and returns it to the client. The client sends a SPA message to the controller according to the TXT value corresponding to the returned controller domain name, and the controller decrypts and verifies the SPA message. After the verification is passed, the controller opens the firewall rules of the service port to the client; The client initiates a login request to the controller, and returns a login result to the client according to the firewall rules of the service port opened by the controller; If the login result is successful, the client sends a SPA message to the gateway, and the gateway decrypts and verifies the SPA message. After the verification is passed, the gateway opens the firewall rules of the service port to the client; The client initiates a request to the gateway to establish a tunnel. If the request complies with the firewall rules of the service port opened by the gateway, a tunnel is established between the client and the gateway; The user initiates a request to access the application resources managed by the gateway through the client, and the gateway returns the access result of the application according to the user's authority.

2. The DNS-based zero-trust network authorization method according to claim 1, characterized in that: The TXT value corresponding to the controller domain name is updated regularly.

3. The DNS-based zero-trust network authorization method according to claim 2, characterized in that: The TXT value corresponding to the controller domain name is generated based on a hash value obtained by performing a hash calculation on the timestamp + the hardware feature code of the controller.

4. The DNS-based zero-trust network authorization method according to claim 3, characterized in that: The SPA message sent by the client to the controller is encrypted with a SPA shared key, and the SPA shared key is a TXT value corresponding to the domain name of the controller.

5. The DNS-based zero-trust network authorization method according to claim 4, characterized in that: The controller determines whether the SPA shared key in the cache exists. If so, the SPA shared key is used to decrypt the SPA message sent by the client. If not, the DNS server is queried again to obtain the TXT value corresponding to the controller domain name as the key to decrypt the SPA message.

6. The DNS-based zero-trust network authorization method according to claim 1 or 5, characterized in that: The SPA message sent by the client to the gateway is encrypted with a SPA shared key, and the SPA shared key is a TXT value corresponding to the controller domain name.

7. The DNS-based zero-trust network authorization method according to claim 6, characterized in that: The gateway determines whether the SPA shared key in the cache exists. If so, the SPA shared key is used to decrypt the SPA message sent by the client to the gateway. If not, the DNS server is queried again to use the TXT value corresponding to the controller domain name as the key to decrypt the SPA message.

8. A system for implementing the DNS-based zero-trust network authorization method according to claim 1, characterized in that: Including client, DNS server, controller, gateway; The DNS server is connected to the client and the controller in communication, respectively, and is used to obtain a request sent by the client to the DNS server for querying a TXT value corresponding to a domain name of the controller, identify a source IP address of the client according to the request and send it to the controller, the controller opens a firewall rule of the SPA knocking port for the client, and if the source IP address of the client meets the firewall rule of the SPA knocking port, the client is allowed to perform knocking verification, and the DNS server synchronizes the TXT value corresponding to the domain name of the controller and returns it to the client; The client is connected to the controller for sending SPA messages and login authentication to the controller; The controller is in communication with the DNS server and is used to obtain the SPA key to decrypt and authenticate the SPA message when the SPA key expires; The client is connected to the gateway for communication, and is used to send a SPA message to the gateway, and establish a tunnel after the SPA message is authenticated; The gateway is in communication connection with the DNS server and is used to obtain the SPA key to decrypt and authenticate the SPA message when the SPA key fails.

9. The DNS-based zero-trust network authorization system according to claim 8, characterized in that: The controller manages and configures the DNS server.

10. The DNS-based zero-trust network authorization system according to claim 8, characterized in that: The communication connection between the controller and the DNS server includes: the controller determines whether the SPA shared key in the cache exists; if so, the SPA shared key is used to decrypt the SPA message sent by the client; if not, the DNS server is queried again for the TXT value corresponding to the controller domain name as the key to decrypt the SPA message; the communication connection between the gateway and the DNS server includes: the gateway determines whether the SPA shared key in the cache exists; if so, the SPA shared key is used to decrypt the SPA message sent by the client to the gateway; if not, the DNS server is queried again for the TXT value corresponding to the controller domain name as the key to decrypt the SPA message.

Images