Enterprise security policy enforcement based on random numbers

Abstract

The technology described in this disclosure includes receiving, by a domain name service (DNS), a name resolution request from a client computing device and providing, by the DNS, a random number to the client computing device, where the service is configured to authorize a connection request from the client computing device based at least in part on processing the random number. The disclosure also describes technology including a method of verifying a connection request from a client computing device, the method including receiving a connection request, the connection request including a random number. The technology also includes determining that the random number is a valid random number. The technology also includes authorizing the connection request and disabling the random number based at least in part on determining that the random number is a valid random number.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to U.S. Patent Application No. 17 / 169,086, filed February 5, 2021, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to the implementation of network security policies, and more specifically, to network security policies based on random numbers implemented by a domain name service. Background Technology

[0004] Dynamic Policy-Based Routing (DPBR) is a technology that allows enterprises to specify how to manage traffic flows from client computing devices to an application on a per-server basis. For example, an employee might launch a browser or local application on a mobile client computing device to connect to, for instance, abc123.com. The mobile client computing device can then issue a Domain Name Service (DNS) request to resolve the abc123.com domain to an address, such as translating the abc123.com domain name into an Internet Protocol (IP) address, which the mobile client computing device can use to route traffic to the abc123.com domain.

[0005] However, enterprises connecting mobile client computing devices to their networks may want to regulate these flows by, for example, capturing DNS requests in security appliances or the cloud. In some examples, an enterprise might install policies in the client agent to allow the agent to capture and regulate traffic flowing to abc123.com. For instance, the client agent could capture DNS requests by snooping on UDP port 53, and when resolving abc123.com, and when a policy specifies capturing traffic flowing to abc123.com, the enterprise could install rules or even routes in the client core to direct all traffic to the IP address associated with abc123.com to the agent, so that the agent can apply security policy rules or other policy rules to the traffic. Enterprises can dynamically configure the client agent by, for example, downloading new or updated policy rules into the client agent.

[0006] DNS servers receive requests via unauthenticated UDP channels, thus lacking the option to verify the requesting client's identity. Even if the DNS server is an enterprise server serving enterprise clients, it cannot provide customized instructions to (through) an enterprise firewall if it is suited to a particular client / server combination. Furthermore, responses from enterprise DNS servers can be cached by clients, and clients can even find the server's address through other means, allowing clients to bypass any firewall (the DNS server can be otherwise configured to send traffic to that firewall).

[0007] A solution that uses a client agent to enforce security policy rules can be vulnerable. For example, such a solution might rely on the client agent to inspect all DNS traffic sent via User Datagram Protocol (UDP) port 53. Thus, DNS traffic is sent unimpeded through UDP port 53 so the client agent can inspect it. In the example of abc123.com just discussed, the client agent captures DNS requests for abc123.com sent via UDP port 53, forwards the DNS requests to the internet for name resolution, and then maps the received fully-qualified domain name (FQDN) to an enterprise policy maintained by the client agent. When the FQDN matches the enterprise policy, the client agent updates the network stack to redirect the flow; otherwise, the flow goes to a specific IP address instead of the client agent. This strategy is suboptimal for several reasons.

[0008] DNS over HTTPS (DoH) and DNS over TLS (DoT) can provide end-to-end encryption between the client computing device requesting the translation and the DNS service itself. As a result, the DNS request may be ambiguous, and the client agent may not be able to easily check the FQDN (although sophisticated implementations may route DNS traffic back from the DoH / DoT service to the client computing device). The DNS server here can know the client's identity and thus provide a customized response. However, what DoT or DoH doesn't address is that the client can still learn the server's address using external knowledge through other methods and can still communicate directly with the server, bypassing enterprise security infrastructure. Furthermore, DNS responses are cached, and the client may not adhere to the optimal dates given by the DNS server.

[0009] Furthermore, if the web service is multi-homed, such as a load balancer providing interfaces to multiple websites hosted behind that load balancer, the client proxy may struggle to separate the domains of the multiple websites. For example, if abc123.com and 123abc.com are both hosted by one or more load balancers, then abc123.com and 123abc.com either both point to the client proxy or neither points to the client proxy, because their names abc123.com and 123abc.com resolve to the same IP address—the IP address of the load balancer between abc123.com and 123abc.com.

[0010] Furthermore, using the client agent method, the application of enterprise policies is distributed among various client agents on client computing devices connected to the network. Therefore, all client agents are informed of the DPBR policy, and the "policy file" is downloaded or accessible from the web. When the enterprise formulates updated policies, because the updated policies are distributed to all client agents, there may be a time lag in implementing the updated policies, even if immediate action is expected. Attached Figure Description

[0011] Detailed description is given below with reference to the accompanying drawings. In the drawings, the leftmost number(s) of the reference numerals indicate the drawing in which the reference numeral first appears. The same reference numerals are used in different drawings to denote similar or identical items. The systems depicted in the drawings are not drawn to scale, and the components in the drawings may not be drawn to scale relative to each other.

[0012] Figure 1 This is an architecture diagram illustrating an example network in which the DNS service can determine, at least in part, to apply security policies to flows associated with DNS requests made by client computing devices via the corporate network, based on indications of protected services in DNS requests.

[0013] Figure 2 An example format of an IPv6 destination address provided by a DNS service is shown, which includes a routing part and a random number part.

[0014] Figure 3 This is a flowchart illustrating an example process executed by a client computing device to initiate and execute a connection with a protected service, the protected service including a connection request that includes a random number provided by a DNS service.

[0015] Figure 4 This is a flowchart illustrating an example process performed by a DNS service to resolve a request from a client computing device for an address of a protected service, with the response including a random number.

[0016] Figure 5 This is a flowchart illustrating an example process executed by an intermediate service to process a connection request provided by a client computing device, the connection request including a random number provided by a DNS service.

[0017] Figure 6 An example computer architecture is shown, which is capable of executing program components to implement the functions described herein. Detailed Implementation

[0018] Overview

[0019] Various aspects of the invention are set forth in the independent claims, and preferred features are set forth in the dependent claims. A feature of one aspect may be applied to each aspect alone or in combination with other aspects.

[0020] This disclosure describes a technique for implementing random number-based network security policies using DNS, which is, for example, part of an enterprise infrastructure and collaborates with the enterprise's security policy implementation to provide specific responses to clients that help the enterprise implement security measures.

[0021] These technologies include: DNS receiving name resolution requests from client computing devices, and DNS providing random numbers to client computing devices, wherein the service is configured to authorize connection requests from client computing devices based at least in part on processing the random numbers. For example, DNS may provide random numbers to client computing devices in the form of random address numbers.

[0022] These technologies also include a method for verifying a connection request from a client computing device, the method comprising: receiving a connection request including a random number. These technologies also include: determining that the random number is a valid random number. These technologies also include: authorizing the connection request and disabling random numbers based at least in part on determining that the random number is a valid random number.

[0023] Furthermore, the techniques described herein can be executed by a system and / or device having a non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors, perform the methods described herein.

[0024] Example Implementation

[0025] In some examples, for dynamic policy-based routing, a client agent (e.g., a Virtual Private Network (VPN) client agent running on a client computing device) selects which traffic to capture to apply a security policy by matching the service name indication in the client's DNS request against a list of policies (provided to the client agent from a central authority). Based on the found match, the client agent can reprogram the client computing device's network stack to redirect traffic to itself. The client agent then tunnels this redirected traffic to the security function. Because the service name indication in the DNS request for traffic from the client computing device does not match one of the policies provided from the central authority, traffic that has not been so redirected is allowed to be routed directly from the client computing device to the named service. This client agent-based approach can have several drawbacks, including a highly decentralized nature of policy decisions within the operational network.

[0026] In some of the techniques described herein, such policy decisions can be made in association with DNS requests issued by a client computing device. A DNS service, or a service associated with a DNS service, can determine, at least in part, that a security policy (if any) should be applied to the flow associated with the DNS request based on an indication of a protected service in the DNS request. Based on the security policy, the DNS service, or a service associated with a DNS service, can provide a random number to the client computing device in response to the DNS request. The client computing device can include the random number in its connection request to the service, and the service evaluating the connection request can process the random number to determine what policy to apply to the connection request. Furthermore, the random number can be an address pointing to, for example, a firewall, which uses the random portion of the address to find out where to forward traffic (e.g., to find out which server the traffic is forwarded to after inspection). Additionally, the random number can then be disabled so that it cannot be reused by, for example, a device capable of snooping on DNS request / response traffic. "Random number" is a term generally familiar to security experts, but may be unfamiliar to IT professionals. Roger Needham used the term "random number" in the context of information technology. He explained that a "random number" can be a token added to a message that will later be retuned in the response message, thus proving that the response was (partially) generated by that message. Random numbers are generally unpredictable and used only once.

[0027] The techniques disclosed herein may include capturing traffic from computing devices (e.g., mobile computing devices) in security functions. For example, a DNS server may work with an enterprise security system and provide addresses that will securely route client traffic through the system. These addresses may have a "random number portion" that makes them unique and usable only once. Furthermore, the random number portion can help downstream components identify the traffic so that it can be further routed to where it needs to go.

[0028] DNS responses can result in at least four different types of connections from client computing devices: For the first type, the response allows the client computing device to contact the server directly each time. In this case, the DNS server may simply provide the client computing device with the server's regular address (without involving a random number). For the second type, the DNS server may allow the client computing device to communicate directly with the server, but only once. The DNS server may coordinate with the server and agree on a random address, which the server will only accept from the client computing device this time. For new conversations, the random address will no longer be valid. For the third type, the DNS server wants to route traffic from the client computing device through the enterprise security infrastructure. The DNS server agrees on a random address with the security infrastructure and provides the agreed address to the client computing device. The client computing device uses this address to connect to the security infrastructure, and the security infrastructure, knowing this address, will also know how to forward traffic to the intended server. Because the client computing device sends its traffic using an encrypted tunnel anyway, further encapsulation in the VPN may not be necessary. For the fourth type, most client-server traffic is transmitted over an authenticated and encrypted TLS connection. In rare cases where traffic is not automatically protected, the security infrastructure may want the traffic to be sent through a VPN tunnel. In order to combine one or more of the other three options to use the fourth type, the client computing device may have a component (client agent) that can intercept traffic destined for the VPN and send it through the VPN, thereby separating the VPN traffic from the traffic according to the first, second and third types.

[0029] Therefore, client proxies (e.g., VPN client proxies) may not be necessary for policy-based dynamic routing. These technologies enable enterprises to control and direct the capture of traffic from client computing devices (e.g., mobile client computing devices used by enterprise employees) without the direct involvement of those employees.

[0030] For dynamic policy-based routing, in many examples, the client agent selects which traffic to capture by matching client DNS requests against a list of policies downloaded to the agent. Depending on whether a match is found, the agent can reprogram the network stack to route that traffic to itself. The agent can then tunnel the traffic to a security feature. Alternatively, traffic can be allowed to be routed directly to a specified service.

[0031] The DNS server (part of the enterprise) should securely know the identity of the client computing device. Traffic on unencrypted port 53 is not permitted because it can be generated anywhere and intercepted by anyone. Therefore, DoH or DoT can be used, for example, since the DNS server verifies the client computing device's identity before responding to a request. Alternatively, a DNS server that cannot verify the client computing device's identity can route all traffic from the client computing device through the company's security infrastructure. Methods for capturing traffic can rely on combining a central DNS server (capable of capturing end-to-end encrypted traffic combined with a central enterprise policy service) and (optionally) one or more centrally hosted destination services. According to some described techniques, when a client computing device requests name resolution from a DNS service, the DNS service may sometimes collaborate with the enterprise policy manager to determine how to route traffic from the client computing device (e.g., directly or via an enterprise security feature). If necessary, the DNS service can establish a security feature and then send a short-lived address (random number address) in the DNS response. For a limited time, the random number address may allow the client computing device, and only the client computing device may be allowed, to access the service via the security feature.

[0032] Therefore, for example, flows that need to be regulated by security functions can be captured. DNS requests can be identified by security functions, and then, if flows are to be captured, the requested name can be mapped (optionally via a secure tunnel) to a dynamically assigned IP address (from the destination function) and a route (installed on the client computing device pointing to the destination function). This simplifies the processing performed by the client computing device and provides a robust and flexible solution.

[0033] More specifically, network-based functions can work in conjunction with network-based DNS, attitude and policy services, zero or more (online) security services, and optional client proxies to tunnel traffic to the security function. One technique may include capturing DNS requests from client computing devices to servers in a central network function. The identity of the client computing device may also be captured. Policies can determine whether flows that might originate from a specific client or from clients with similar representations to that server will be captured by the security function. If the policy service indicates that flow capture is not required, DNS may return the public IP address of the requested server in its response to allow the client computing device to connect directly to the server over the Internet.

[0034] When capturing traffic, DNS may return an address via a protection tunnel to route to enterprise security features, where traffic can be inspected before being forwarded to the server. Alternatively or additionally, an address may be returned that a virtual private cloud ingress point, load balancer, or other multihomed service can use to deliver traffic to the desired service. This allows the ingress point to avoid interpreting service names.

[0035] The DNS server for enterprise devices can be an enterprise DNS server that uses enterprise policies or interacts with an enterprise policy server to provide DNS responses. DNS requests and responses can be end-to-end encrypted to minimize the possibility of tampering, for example, by DoH or DoT. The identity of the client computing device can be captured by the DNS server, allowing the use of user-specific or client-specific policies (or, in some examples, policies specific to client categories). By using enterprise policies (which may be client-specific), the DNS server can determine how traffic between the client and the (cloud) server should be handled and responded to appropriately.

[0036] When a client is allowed to communicate directly with a server, the DNS server can simply return the server's IP address. Alternatively, for sensitive enterprise servers that should only be addressed by authorized clients, the DNS server can return a random address to those requesting authorized clients. The DNS server can also return a random address indicating an enterprise security feature, or routed through a Virtual Private Cloud (VPC) entry point or load balancer. After passing through this feature, traffic can be forwarded to the requested server. This routing can use a tunnel between the client and the security feature. In this case, the random address may not be a routable address (to prevent its use outside the tunnel). The DNS server and the security feature can agree on these random addresses beforehand, allowing the security feature to identify addresses used for security and server forwarding purposes. The random address can be client-specific. It can be used as a one-time license for that client to access the service. Once a client starts using the random address, it can be disabled, preventing other clients from connecting using the same address.

[0037] A random address can be an address used for a specific purpose and valid for a limited time. A name server can map a name to a random address that can only be used once by a specific client. Alternatively, a name server can map a random address that can be used by multiple clients in a specific category, for example, for five minutes. Random addresses can be obtained without guessing. Without the help of a name server, a useful random address cannot be obtained.

[0038] IPv6 addresses can be adapted for use as random number addresses. An IPv6 address is 128 bits in size, with only half of the bits used to route packets to their destination (the routing portion). The other half can be used to identify the service and / or purpose at that destination (the random number portion). This purpose could be, for example, a connection from a specific authorized client to a service. Or it could be a connection from a client to a service via some security function. Random number addresses in the latter category can be designed not to be used for direct connections. A random number address intended to route traffic via a network-based security function can be routed only to that security function, which can use the random number portion to determine what security function should be provided and where the traffic should subsequently be forwarded. Random number addresses can also be used to tell intermediate functions (e.g., load balancers) how to forward traffic to the correct service, such as in a VPC.

[0039] If random addresses are used to directly address services, some coordination can be employed between the DNS server that provides them and the service being addressed. Alternatively, random addresses can be used to reach a gateway, which forwards traffic to the correct service. In the latter case, in some examples, only the gateway may be involved in the allocation and interpretation of random addresses.

[0040] This coordination can be explicit, meaning the service (or gateway) and the DNS server can exchange information to achieve coordination, or it can be implicit (using an algorithm shared by the service and the DNS server). An example of such an algorithm could be two entities sharing a key and an initial address to be given. They can independently compute the next address by applying a function that takes the shared key and the previous address as input. This function may not need to be strongly cryptographic, still performing genuine verification during the TLS handshake and subsequent client authentication. Instead, the function can be implemented relatively cheaply, and therefore also resistant to distributed denial-of-service (DDoS) attacks.

[0041] On the other hand, if a random number address is used to guide the client through security features before forwarding traffic to the destination service, a more explicit protocol can be implemented between the security features and the DNS server. The DNS server, acting as a manager of enterprise security profiles, can identify what security requirements should be used for a particular client-server connection. The DNS server can establish this within the security feature infrastructure and create a random number address to be used for that connection. The DNS server can then return a DNS resolution to the requesting client to include that same random number address.

[0042] Therefore, traffic can be captured within security features (such as the cloud) as a side effect of resolving the names of (cloud) applications via a centralized DNS service. This DNS service can be part of a cloud-based security feature. The DNS service can provide randomized addresses, which has the advantages of ensuring that addresses are valid for a specific purpose and may only be valid for a specific client, allowing addresses to also serve as indicators of how traffic is handled and forwarded for security purposes, and limiting address lifetimes, thus allowing for better control over address caching. Client routing can be configured on client computing devices that direct traffic to a pre-established tunnel and DNS that resolves the names of cloud applications, pointing to the IP address space associated with that tunnel.

[0043] Figure 1 This diagram illustrates the architecture of an example network 100, where DNS service 102 can determine, at least in part, to apply a security policy to a flow associated with a DNS request issued by client computing device 104 via enterprise network 105, based on an indication of protected service 106 in a DNS request. For example, DNS service 102 can refer to enterprise policy service 108 to determine a security policy, at least in part, to be applied to a flow associated with a DNS request issued by client computing device 104 via enterprise network 105, based on an indication of protected service 106 in a DNS request.

[0044] DNS service 102 may respond to a DNS request from client computing device 104 with an indication that a security policy will be applied to the flow associated with the DNS request from client computing device 104. For example, DNS service 102 may resolve a domain name in a DNS request to an address associated with intermediate service 110. Intermediate service 110 may be a security service or other service that operates as a gateway to protected service 106.

[0045] Furthermore, DNS service 102 may respond to DNS requests issued by client computing device 104 with a random number. The random number is an arbitrary number that can only be used once in the communication. The random number is typically a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in a replay attack. In the context of network 100, the random number may be a number processed by intermediate service 110 when determining authorization for a connection request from client computing device 104 to protected service 106. That is, client computing device 104 includes, at least in part, the random number received from DNS service 102 as part of DNS service 102's response to the DNS request in its connection request to protected service 106, based on the processing of the random number. Intermediate service 110 verifies the connection request from client computing device 104 to protected service 106 by at least partially determining whether the random number corresponds to a valid connection request issued by client computing device 104 to protected service 106.

[0046] In one example, based at least in part on a DNS request from client computing device 104, DNS service 102 may provide a random number to client computing device 104 as at least part of a response to the DNS request from client computing device 104, and may also provide the random number to intermediate service 110. Intermediate service 110 can then use the random number provided by DNS service 102 to verify a connection request from client computing device 104 to protected service 106, for example, by partially comparing the random number provided by DNS service 102 with the random number provided by client computing device 104 as part of the connection request from client computing device 104 to protected service 106.

[0047] In another example, based at least in part on a DNS request from client computing device 104, DNS service 102 may provide a random number to client computing device 104 as at least part of its response to the DNS request from client computing device 104, but not to intermediate service 110. DNS service 102 and intermediate service 110 may coordinate to agree on a random number. This coordination can be explicit. For example, DNS service 102 and intermediate service 110 may exchange information to coordinate and agree on a random number. As another example, coordination can be implicit, for example, by using algorithms known to both DNS service 102 and intermediate service 110. DNS service 102 and intermediate service 110 each use a common algorithm to independently compute the next random number by applying a function that takes a shared (secret) key and the previous random number as input. For example, intermediate service 110 may have an associated random number generation and / or storage function 112. This function may not be strongly encrypted. For example, verification can still be performed in the Transport Layer Security (TLS) handshake and subsequent client authentication.

[0048] In some examples, the random number may be used by intermediate service 110 (e.g., a security service) to determine what policy to apply to traffic from client computing device 104 to protected service 106. For example, there may be a more explicit protocol between DNS service 102 and intermediate service 110. For instance, DNS service 102, acting as a manager of enterprise security profiles, can identify what security requirements to apply to the connection between client computing device 104 and protected service 106. DNS service 102 can provide intermediate service 110 with an indication of the security requirements and a random number. When client computing device 104 makes a connection request to intermediate service 110 to protected service 106, intermediate service 110 can process the random number received in the connection request to determine what security policy to apply to the connection between client computing device 104 and protected service 106.

[0049] In another example, DNS service 102 may determine, at least in part, that a security policy should not be applied to flows associated with DNS requests made by client computing device 104 via corporate network 105, based on an indication in the DNS request for unprotected service 114. For example, DNS service 102 may refer to enterprise policy service 108 to determine, at least in part, that a security policy should not be applied to flows associated with DNS requests made by client computing device 104 via corporate network 105, based on an indication in the DNS request for unprotected service 114.

[0050] In this example, DNS service 102 can resolve the domain name in the DNS request to an address associated with the unprotected service 114. DNS service 102 can provide the client computing device 104 with the address associated with the unprotected service 114. DNS service 102 may not provide the client computing device 104 with a random number as part of the connection request from the client computing device 104 to the unprotected service 114. For example, since security policies are not applied to flows to the unprotected service 114, it is not necessary for the client computing device 104, which issued the connection request to initiate the connection to the unprotected service 114, to provide a random number.

[0051] In some examples, the client computing device 104 may also include a client agent 116, which regulates access to at least some of the protected services. In some examples, the enterprise may install policies in the client agent 116 to enable it to capture traffic to at least some of the protected services. The enterprise can dynamically configure the client agent 116, for example, by downloading new or updated policy rules into it.

[0052] In a specific example using example network 100, client computing device 104 issues a DNS request (1) via enterprise network 105. The DNS request includes the domain name of protected service 106, which is to be resolved into an IP address by DNS service 102. The DNS request may be formatted and defined, for example, according to RFC 1035 "Domain Names - Implementation and Specification" of November 1987. The DNS request continues via enterprise network 105 to DNS service 102 at (2).

[0053] The connection between the client computing device 104 and the DNS service 102 can be a secure end-to-end encrypted connection. For example, a secure end-to-end connection could be a DoH connection according to RFC 8484 "DNS Queries over HTTPS (DoH)" ("DNS Queries over HTTPS") of October 2018. DoH is a protocol for sending DNS queries and receiving DNS responses over HTTPS. According to DoH, each DNS query-response pair is mapped to an HTTP exchange. DoH uses normal HTTP content negotiation mechanisms to establish default media format types for requests and responses, selecting alternatives that endpoints might prefer. DoH also integrates itself with HTTP features such as caching, rebooting, proxying, authentication, and compression. This integration with HTTP provides a suitable transport for both existing DNS clients and local network applications seeking DNS access.

[0054] As another example, the connection between client computing device 104 and DNS service 102 can be a secure end-to-end encrypted connection, which is a DoT connection according to RFC 7858 "Specification for DNS over transportlayer security (TLS)" ("Transport Layer Security DNS Specification") of May 2016. DoT uses DNS over TLS on a known port. By establishing a connection on a known port, the client and server expect and agree to negotiate a TLS session to secure the channel.

[0055] DNS service 102 generates a DNS response including an IP address corresponding to intermediate service 110 and a random number, which is used by client computing device 104 as part of a connection request to protected service 106. DNS service 102 may generate a response formatted and defined according to RFC 1035. DNS service provides (3) a DNS response, which is provided (4) to client computing device 104 via enterprise network 105.

[0056] In some examples, DNS service 102 also provides (3a) random numbers to intermediate service 110. In other examples, intermediate service 110 generates random numbers independently in coordination with DNS service 102, such that the random numbers generated independently by intermediate service 110 correspond to the random numbers included by DNS service 102 in the DNS response sent to client computing device 104.

[0057] In some examples, DNS service 102 includes a random number as part of an address (e.g., an IP address) provided by DNS service 102 to client computing device 104. For example, the IP address may be an IPv6 address formatted according to RFC 4291 "IP Version 6 Addressing Architecture" of February 2006. DNS service 102 may include the random number as the lower 64 bits of the IPv6 address, while the higher 64 bits of the IPv6 address may be used by network 100 for routing.

[0058] Client computing device 104 includes (5) a random number as part of a connection request to protected service 106, which is provided via enterprise network 105 (6). The destination address included in the connection request by client computing device 104 is the address of intermediate service 110. This is because DNS service 102 has already provided the address of intermediate service 100 to client computing device 104 in response to a DNS request issued by client computing device 104 to resolve the name of protected service 106.

[0059] Intermediate service 110 receives a random number as part of a connection request from client computing device 104 to connect to protected service 106. Intermediate service 110 evaluates the received random number as part of the connection request to determine whether the connection request to protected service 106 is permitted. For example, intermediate service 110 may compare or otherwise evaluate the random number received as part of the connection request with a random number received by intermediate service 102 from DNS service 102 (based at least in part on a DNS request provided by client computing device 104) to resolve the name of protected service 106. As another example, intermediate service 110 may compare or otherwise evaluate the random number received as part of the connection request with a random number generated independently by intermediate service 110 or by a related random number generation service 112. As part of the evaluation of the received random number, intermediate service 110 may evaluate whether the received random number has been previously used, and therefore any subsequent use of the random number after its initial use will be invalid. For example, intermediate service 110 can store a record of previously used random numbers, and intermediate service 110 can compare the received random number with its record of previously used random numbers.

[0060] When intermediate service 110 determines that a random number received from client computing device 104 as part of a connection request to protected service 106 indicates that the connection request is valid, intermediate service 110 provides (7) a connection request to protected service 106. Protected service 106 responds (8) to the connection request, for example, by providing at least an acknowledgment of the connection request to intermediate service 110. The intermediate service then provides (9) a response to be provided (10) to client computing device 104 via enterprise network 105, which may include an acknowledgment. Client computing device 104, having received the response, connects to protected service 106, for example, by initiating a data traffic flow to protected service 106.

[0061] In another example, the DNS request (1) provided by the client computing device 104, and the DNS request (2) provided to the DNS service 102 via the enterprise network 105, are DNS requests to resolve the name of the unprotected service 114. The DNS service 102 provides the DNS request to the client computing device 104 via the enterprise network. Figure 1 (Not shown) A response is given that resolves the name of the unprotected service 114 to the address of the unprotected service 114. Thereafter, the client computing device 104 provides a (11) connection request to the unprotected service 114 via the Internet 118. The unprotected service 114 acknowledges the connection request to the client computing device 104, which then connects to the unprotected service 114, for example, by initiating a data traffic stream to the unprotected service 114.

[0062] In some examples, in response to a DNS request provided by client computing device 104, DNS service 102 uses a random number as part of the IPv6 target address provided by DNS service 102, corresponding to intermediate service 110. Figure 2 Example format 200 of this IPv6 destination address, including a random number, is shown. (Reference) Figure 2 Example format 200 includes a routing section 202 and a random number section 204.

[0063] The routing portion 202 includes the most significant eight octets (octets 8 to 15) of the example format 200. The eight octets of the routing portion 202 of the IPv6 format 200 are sufficient to route packets from the client computing device 104 to the intermediate service 110. The random number portion 204 includes the least significant eight octets (octets 0 to 7) of the example format 200. The eight octets of the random number portion 204 of the IPv6 format 200 are determined by the DNS service 102 and used by the client computing device 104 to identify the service and / or purpose of the connection request to the intermediate service 110. For example, the eight octets of the random number portion 204 of the IPv6 format 200 can identify the purpose of connecting the client computing device 104 to the protected service 106. As another example, intermediate service 110 may be a security service, and the eight octet random number portion 204 of IPv6 format 200 may identify security features for intermediate service 110 to be applied to traffic originating from client computing device 104 and destined for protected service 106.

[0064] DNS service 102 can generate a routing portion 202 in IP address format to avoid direct connections to the protected service 106. For example, DNS service 102 can generate a routing portion 202 in IP address format 200 for connections intended to be mediated by network-based security functions (such as intermediate service 110 performing the security functions) so that traffic is routed only to that security function and not to the protected service 106 as the initial destination. The security function can process the random number portion 204 of IP address format 200 to determine which security function to perform and, after performing the security function, which destination service (e.g., the protected service 106) to forward the traffic to.

[0065] In other examples, intermediate service 110 may perform other types of functions besides security functions. For example, intermediate service 110 may perform load balancing functions. In this example, the intermediate service may process the random number portion 204 of IP address format 200 to determine how to forward traffic to the appropriate service in, for example, a Virtual Private Cloud (VPC) that includes multiple services.

[0066] Figure 3 This is a flowchart illustrating example process 300, executed by client computing device 104 to initiate and execute a connection to protected service 106. For example, protected service 106 may be protected by enterprise security features executed by intermediate service 110.

[0067] At 302, client computing device 104 sends a DNS request to the DNS service. Client computing device 104 sends a DNS request to DNS service 102, wherein client computing device 104 includes the domain name of the protected service 106 in the DNS request. At 304, client computing device 104 receives a response from DNS service 102, which corresponds to the DNS request. In one example, the response includes an IPv6 address, which includes a routing portion and a random number portion.

[0068] In other examples, client computing device 104 receives a response in which the random number is not part of the received address, but rather an appendix to the received address. That is, in these other examples, when client computing device 104 makes a connection request to protected service 106, client computing device 104 does not include the random number as part of the target address, but may include the random number in a different field of the DNS request response instead of the received address.

[0069] At 306, the client computing device 104 provides a connection request, including an address received from DNS service 102 (and a separate random number, if DNS service 102 does not provide a random number as part of the address). The connection request is routed to intermediate service 110, at least in part, due to the address to intermediate service 110 provided by DNS service 102.

[0070] At 308, client computing device 104 receives a response to a connection request provided by client computing device 104. In some examples, client computing device 104 participates in a handshake exchange to establish a connection with protected service 106. At 310, client computing device 104 sends data traffic over the established connection.

[0071] Regarding process 300, in some examples, because DNS service 102 embeds a random number in the IP address it provides, client computing device 104 may not even be aware that the response from DNS service 102 includes a random number. Furthermore, when client computing device 104 sends a connection request and includes an IP address (with the embedded random number) provided by DNS service 102, client computing device 104 may not even be aware that the IP address includes a random number. Additionally, for example, when client computing device 104 sends traffic to protected service 106 via a connection, client computing device 104 may not even be aware that the routing portion 202 of the IP address is used to route traffic to the address of intermediate service 110, and that a random number is included as a random number portion 204 of the IP address.

[0072] Figure 4 This is a flowchart illustrating example process 400, which is performed by DNS service 102 to resolve a request from client computing device 104 for an address of protected service 106. At 402, DNS service 102 receives a DNS request from client computing device 104. The DNS request includes an indication of the domain name of protected service 106.

[0073] At 404, DNS service 102 determines at least one enterprise security policy associated with client computing device 104 and protected service 106. For example, a network administrator may have used a network management platform and / or portal to configure enterprise security policies. In some examples, a network administrator using a network management platform and / or portal in this manner may not be significantly different (if any) from using a network management platform and / or portal to configure enterprise security policies for download to client agent 116 (which can be executed by client computing device 104).

[0074] At 406, DNS service 102 sends a response to client computing device 104 in response to a DNS request sent from client computing device 104. DNS service 102 includes in the response an address to be routed to intermediate service 110. DNS service 102 also includes a random number corresponding to the determined enterprise security policy, and includes an indication of the protected service 106 within the random number. In some examples, DNS service 102 provides a random number as part of an IPv6 (or other format) address. That is, DNS service 102 can provide a routing portion 202 of the IPv6 address, which can be used to route data traffic from client computing device 104 to intermediate service 110. Additionally, DNS service 102 can provide a random number portion 204 of the IPv6 address, which can include an indication of the determined enterprise security policy and an indication of the protected service 106.

[0075] Figure 5 This is a flowchart illustrating example process 500, executed by intermediate service 110 to process a connection request provided by client computing device 104. At 502, intermediate service 110 receives a connection request from client computing device 104 including a random number. For example, client computing device 104 may include a random number as part of a destination IPv6 (or other format) address in the connection request. That is, client computing device 104 may provide a routing portion 202 of the IPv6 address, which can be used to route data traffic from client computing device 104 to intermediate service 110. Additionally, client computing device 104 may provide a random number portion 204 of the IPv6 address, which includes an indication of a determined enterprise security policy and an indication of a protected service 106. In response to a DNS request from client computing device 104, client computing device 104 may have already received an IPv6 address with a routing portion 202 and a random number portion 204 from DNS service 102.

[0076] At 504, intermediate service 100 determines that the random number included in the connection request from client computing device 104 is valid. For example, DNS service 102 may have already provided the random number to intermediate service 110 when responding to a DNS request from client computing device 104. Furthermore, intermediate service 110 may not have previously processed the same random number. For example, the random number may not be a previously used random number tracked by intermediate service 110. However, intermediate service 110 can determine that the time of receiving the connection request including the random number from the client computing device is within the time period associated with intermediate service 110 receiving the random number from the DNS request. On the other hand, if intermediate service 110 determines that the random number included in the connection request from client computing device 104 is not valid, then for the connection request received at operation 502 of process 500, the intermediate service may not proceed to operation 506 of process 500.

[0077] At 506, intermediate service 110 determines the service (if any) corresponding to the random number. More specifically, intermediate service 110 determines that the random number corresponds to protected service 106. For example, the random number may include an index on a table of protected services, and intermediate service 110 indexes the table with the included index to obtain the value of an index entry from an index entry in the table, the index entry being an indication of protected service 106. The intermediate service may populate the index entry with the indication of protected service 106 based at least in part on notification of the random number from DNS service 102.

[0078] At 508, intermediate service 110 determines a security policy (if any) indicated by a random number. For example, when generating a random number, DNS service 102 may inform intermediate service 110 of the random number and at least one security policy applied to a connection request including the random number. Intermediate service 110 may store an indication of at least one security policy in such a way that it can determine at least one security policy upon receiving a connection request including the random number. As another example, intermediate service 110 may implicitly apply one or more security policies to a connection request, even if the security policy is not explicitly indicated by or otherwise corresponds to a random number.

[0079] At 510, intermediate service 110 provides a connection request to the service, having determined that the random number corresponds to the service (protected service 106) because the connection request is permitted according to the security policy. At 512, intermediate service 110 disables the random number included in the connection request, preventing it from being subsequently reused. This, for example, prevents an eavesdropper from a connection request from client computing device 104 from accessing protected service 106 by reusing the random number included in the connection request from the client computing device. For example, intermediate service 110 may track used random numbers so that it determines subsequent connection requests containing the same random number are invalid.

[0080] Figure 6 An example computer architecture of computer 600 is shown, which is capable of executing program components to achieve the above-mentioned functions. Figure 6 The computer architecture diagrams illustrated illustrate the architecture of server computers, workstations, desktop computers, laptop computers, tablet computers, web applications, e-readers, smartphones, network switches, or other computing devices, and can be used to execute any of the software components presented herein. In some examples, computer 600 may correspond to the network infrastructure devices discussed herein.

[0081] Computer 600 includes a baseboard 602, or "motherboard," which may be a printed circuit board to which many components or devices can be connected via a system bus or other electrical communication paths. In one illustrative configuration, one or more central processing units (CPUs) 604 operate in conjunction with a chipset 606. The CPU 604 may be, for example, a standard programmable processor that performs the arithmetic and logic operations necessary for the operation of computer 600.

[0082] The CPU 604 performs operations by transitioning from one discrete physical state to the next, where state transitions are achieved by manipulating switching elements that distinguish and change these states. Switching elements typically include electronic circuitry, such as flip-flops, that maintains one of two binary states, and electronic circuitry, such as logic gates, that provides an output state based on a logical combination of the states of one or more other switching elements. These basic switching elements can be combined to create more complex logic circuits, including registers, adders / subtractors, arithmetic logic units, floating-point units, and so on.

[0083] Chipset 606 provides an interface between CPU 604 and the remaining components and devices on substrate 602. Chipset 606 may provide an interface with RAM 608, which is used as main memory in computer 600. Chipset 606 may further provide an interface with a computer-readable storage medium, such as read-only memory (ROM) 610 or non-volatile RAM (NVRAM), for storing basic routines that facilitate booting computer 600 and transferring information between various components and devices. ROM 610 or NVRAM may also store other software components necessary for the operation of computer 600 according to the configuration described herein. Figure 6 As shown, ROM 610 or NVRAM can also store data that can be used by computer 600 to generate and / or process authentication information in messages exchanged between computer 600 and other devices. In other examples, this data may be stored elsewhere, such as in RAM 608.

[0084] Computer 600 can operate in a networked environment, using logical connections to remote computing devices and computer systems via a network. For example, chipset 606 may include functionality for providing network connectivity via a network interface controller (NIC) 612 (e.g., a Gigabit Ethernet adapter). NIC 612 enables computer 600 to connect to other computing devices via a network. It should be understood that multiple NICs 612 may be present in computer 600 to connect the computer to other types of networks and remote computer systems. In some instances, NIC 612 may include at least one ingress port and / or at least one egress port. Input / output controllers 616 may be provided for other types of input / output.

[0085] Computer 600 can be connected to storage device 618, which provides non-volatile storage for the computer. Storage device 618 can store, for example, operating system 620, programs 622, and data 624. Storage device 618 can be connected to computer 600 via storage controller 614, which is connected to chipset 606. Storage device 618 may include one or more physical storage units. Storage controller 614 can be connected to physical storage units via a serial attached SCSI (SAS) interface, a serial advanced technology attachment (SATA) interface, a fiber channel (FC) interface, or other types of interfaces used for physical connection and data transfer between the computer and physical storage units.

[0086] Data 624 may include, for example, a protected service table, which intermediate service 110 may index using an index included in a random number to obtain indications of protected services from index entries in the table, to which intermediate service 110 forwards traffic via a connection from a client computing device that provides the random number. Intermediate service 110 may populate index entries with indications of various protected services, at least in part, based on random number notifications from DNS service 102. Data 624 may also, or alternatively, include a list of previously used random numbers, such that, for example, intermediate service 110 may reject connection requests that include random numbers indicated by data 624 as having been previously used.

[0087] Computer 600 can store data on storage device 618 by changing the physical state of physical storage units to reflect the stored information. In different embodiments of this specification, the specific changes in physical state can depend on various factors. Examples of such factors include, but are not limited to, the technology used to implement the physical storage units, whether storage device 618 is characterized as primary or secondary storage, etc. For example, computer 600 can store information in storage device 618 by issuing instructions via storage controller 614 to change the magnetic properties of a specific location within a disk drive unit, the reflection or refraction properties of a specific location in an optical storage unit, or the electrical properties of a specific capacitor, transistor, or other discrete component in a solid-state storage unit. Other changes to the physical medium are possible without departing from the scope and spirit of this specification; the foregoing examples are provided merely for convenience. Computer 600 can further read information from storage device 618 by detecting the physical state or characteristics of one or more specific locations within the physical storage units.

[0088] In addition to the aforementioned storage device 618, computer 600 may access other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data, including data used to generate and / or process evidentiary information. Those skilled in the art will understand that a computer-readable storage medium is any available medium that provides non-transitory storage of data and can be accessed by computer 600.

[0089] In summary, the techniques described in this disclosure include: receiving a name resolution request from a client computing device by a Domain Name Service (DNS), and providing a random number to the client computing device by the DNS, wherein the service is configured to authorize connection requests from the client computing device at least in part based on processing the random number. This disclosure also describes techniques including a method for verifying connection requests from a client computing device, the method comprising: receiving a connection request, the connection request including a random number. These techniques further include: determining that the random number is a valid random number. These techniques further include: authorizing the connection request and disabling the random number at least in part based on determining that the random number is a valid random number.

[0090] Although the invention has been described with reference to specific examples, it should be understood that the scope of the invention is not limited to these specific examples. Since other modifications and variations made to adapt to specific operational requirements and environments will be apparent to those skilled in the art, the invention is not to be considered limited to the examples chosen for disclosure purposes, and covers all changes and modifications that do not constitute a departure from the true spirit and scope of the invention.

[0091] While this application describes embodiments with specific structural features and / or methodological actions, it should be understood that the claims are not necessarily limited to the specific features or actions described. Rather, the specific features and actions merely illustrate some embodiments that fall within the scope of the claims of this application.

Claims

1. A method applied to the Domain Name System (DNS), comprising: The DNS receives a name resolution request from the client computing device, the name resolution request being associated with a destination; The routing policy determines that traffic sent from the client computing device to the destination should be handled by a service. Generate a random number associated with the service; as well as The DNS provides the random number to the client computing device so that traffic sent from the client computing device using the random number is routed to the service, wherein the service is configured to authorize connection requests from the client computing device based at least in part on processing the random number.

2. The method according to claim 1, wherein, The service is an intermediary service configured to authorize connection requests from the client computing device to the destination based at least in part on processing the random number.

3. The method according to claim 2, wherein, The intermediate service is configured to perform network security functions.

4. The method according to claim 1, wherein, The service is either a Virtual Private Cloud (VPC) entry point or a load balancer.

5. The method according to claim 1, wherein, The service is a destination service configured to authorize connection requests from the client computing device to the destination service based at least in part on processing the random number.

6. The method according to claim 1, further comprising: The DNS determines at least a first enterprise security policy associated with the combination of the client computing device and the connection request; as well as Based at least in part on receiving the name resolution request, a response is provided to the client computing device, the response including a routing portion and a random number portion corresponding to the at least first enterprise security policy.

7. The method according to claim 6, wherein, Determining that the at least first enterprise security policy includes interaction with an enterprise policy service.

8. The method according to claim 6, wherein, The name resolution request is a first name resolution request, the service is a first protected service, and the routing portion is a first routing portion indicating an intermediate service, the intermediate service being located between the client computing device and the first protected service. The method further includes: The DNS receives a second name resolution request from the client computing device, the second name resolution request including the name of a second protected service; The DNS determines at least a second enterprise security policy associated with the combination of the client computing device and the second protected service; and Based at least in part on receiving the second name resolution request, the client computing device is provided with a response for accessing the second protected service, the response including a second routing portion and a second random number portion, the second random number portion corresponding to the at least second enterprise security policy, and the second routing portion corresponding to the second protected service.

9. The method according to any one of claims 1 to 8, wherein: Providing the random number to the client computing device by the DNS includes providing the random number as part of the IPv6 address to the client.

10. A method for verifying a connection request from a client computing device, comprising the following operations: The intermediate service receives the connection request from the client computing device to connect to the destination, the connection request including a random number address associated with the intermediate service; Determine that the connection request is allowed; The connection request is authorized at least in part based on the determination that the connection request is permitted; Forward the connection request to the destination; as well as Disable the random number generator.

11. The method of claim 10, further comprising: The intermediate service applies security policies to the connection request based at least in part on the random number address.

12. The method according to claim 10, wherein: The intermediate service is at least one of a Virtual Private Cloud (VPC) entry point or a load balancer.

13. The method of claim 10, wherein: The determination and authorization operations are performed by the destination.

14. The method according to any one of claims 10 to 13, wherein: The connection request includes a destination IPv6 address, which includes a routing portion and a random number portion, the random number portion containing the random number address.

15. A Domain Name System (DNS), comprising: One or more processors; as well as One or more non-transitory computer-readable media storing computer-executable instructions, which, when executed by the one or more processors, cause the one or more processors to perform the following operations: Receive a name resolution request from a client computing device, the name resolution request being associated with a destination; The routing policy determines that traffic sent from the client computing device to the destination should be handled by a service. Generate a random number associated with the service; as well as The random number is provided to the client computing device so that traffic sent from the client computing device using the random number is routed to the service, wherein the service is configured to authorize connection requests from the client computing device based at least in part on processing the random number.

16. The DNS of claim 15, further comprising: Determine at least a first enterprise security policy associated with the combination of the client computing device and the connection request; as well as Based at least in part on receiving the name resolution request, a response is provided to the client computing device, the response including a routing portion and a random number portion corresponding to the at least first enterprise security policy.

17. The DNS according to claim 16, wherein, Determining the operation of at least the first enterprise security policy includes interacting with the enterprise policy service.

18. The DNS according to claim 16, wherein, The name resolution request is a first name resolution request, the service is a first protected service, and the routing portion is a first routing portion indicating an intermediate service, the intermediate service being located between the client computing device and the first protected service. The operation further includes: Receive a second name resolution request from the client computing device, the second name resolution request including the name of a second protected service; Determine at least a second enterprise security policy associated with the combination of the client computing device and the second protected service; and Based at least in part on receiving the second name resolution request, the client computing device is provided with a response for accessing the second protected service, the response including a second routing portion and a second random number portion, the second random number portion corresponding to the at least second enterprise security policy, and the second routing portion corresponding to the second protected service.

19. The DNS according to any one of claims 15 to 18, wherein: Providing the random number to the client computing device includes providing the random number as part of an IPv6 address to the client computing device.

20. A Domain Name System (DNS) comprising a module for implementing the method according to any one of claims 1 to 14.

21. A computer program product comprising instructions that, when executed by a computer, cause the computer to perform the steps of the method according to any one of claims 1 to 14.

22. A computer-readable medium comprising instructions that, when executed by a computer, cause the computer to perform the steps of the method according to any one of claims 1 to 14.

Images