SYSTEMS AND METHODS FOR PERMITTING / BLOCKING INTERNET PROTOCOL (IP) CONNECTIVITY BASED ON ORIGINATING DOMAIN NAME SERVER (DNS) REQUESTS ON iOS DEVICES

Abstract

Systems and methods are disclosed for regulating Internet Protocol (IP) connectivity on iOS devices based on the origin of connection requests. The disclosure utilizes two native iOS components—a content filter and a DNS proxy—to monitor and control outgoing IP traffic. The content filter evaluates whether destination IP addresses are present in an allow list. If not, the DNS proxy determines whether the request corresponds to a permitted domain name resolved via DNS. If resolved successfully, the IP address is added to the allow list, permitting the connection. Otherwise, the connection is blocked or reset. The DNS proxy can aggregate responses from multiple DNS resolvers and cache resolved addresses for a time-limited period. These functionalities are deployed via Mobile Device Management (MDM), providing enterprise-level enforcement. The system protects against unauthorized or suspicious traffic, such as direct-by-IP attempts, thereby improving security and control over network access on managed iOS devices.

Description

SYSTEMS AND METHODS FOR PERMITTING / BLOCKING INTERNET PROTOCOL (IP) CONNECTIVITY BASED ON ORIGINATING DOMAIN NAME SERVER (DNS) REQUESTS ON iOS DEVICESREFERENCE TO PRIOR APPLICATION

[0001] This application claims priority to and the benefit of U.S. Provisional Application No. 63 / 667,953, filed on July 5, 2024. The application cited in this paragraph is incorporated by reference as if set forth fully herein.BACKGROUND OF THE DISCLOSUREField

[0002] The disclosure relates generally to systems and methods for permitting or blocking internet connections on a network and, more specifically, on a network device running iOS.Description of the Related Art

[0003] The Transmission Control Protocol / Internet Protocol (TCP / IP) is a networking protocol, which has become ubiquitous with the internet. TCP / IP provides end-to-end communication between users on the internet. Users may send and receive information with each other regardless of geographic location or the type of host and / or interconnected network being used. TCP / IP defines how data should be encapsulated into packets, addressed, transmitted, routed and received. The packets contain header information that include both the source and destination addresses, which are expressed in numerical formats known as IP addresses. The packets are routed through the internet until they are received by a host having an IP address that matches the destination address. This enables users tosend and receive information with each other through their respective host computers.

[0004] Since IP addresses are expressed in a numerical format, the Domain Name Service (DNS) was formed to use "human- readable" addresses or "domain names." The DNS allows these names to be resolved to unique IP addresses. DNS consists of a worldwide hierarchy of servers containing network names / addresses databases.

[0005] Sometimes an upstream DNS resolver is used to assist in resolving a DNS query. For example, when all user queries are sent to the same upstream DNS resolver, this allows the resolver to create user profiles by collecting data based on the history of user behavior, which can be a privacy concern.

[0006] Sometimes selection of an upstream DNS resolver is made at the end-user device level. This can lead to vulnerabilities and susceptibility in the overall network, can lead to inconsistencies in protocols for the different user devices of the network, and / or can result in unnecessary packet requests that ultimately will be rejected by the destination endpoint .

[0007] Solutions to the issues presented above for systems that operate on a gateway are discussed in detail in U.S. Pat. No. 10, 686,753, which is commonly owned with the present application. This application is incorporated by reference in its entirety as if set forth fully herein.

[0008] However, there is an additional need for solutions on devices that run the iOS operating system. Methods and systems addressing these issues for iOS devices are disclosed herein.SUMMARY OF THE DISCLOSURE

[0009] The present disclosure is directed to systems, methods, and devices for regulating Internet Protocol (IP) connectivity on iOS devices by determining whether outgoing connection attempts originate from permitted domain name resolutions. The disclosure leverages native iOS components to enable enhanced security and policy enforcement at the device level .

[0010] In one aspect, a method is provided for regulating IP connectivity on an iOS device. The method includes initiating an outgoing IP connection request from an application on the device, and filtering, by a content filter operating on the device, the request to determine whether the destination IP address is present in an allow list. If the address is present, the request is permitted. If the address is not present, a DNS proxy operating on the device determines whether the request is associated with a permitted domain name resolved via a DNS query. If the DNS query is permitted and results in a resolved IP address, the IP address is added to the allow list and the request is permitted. Otherwise, the request is blocked or reset .

[0011] In another aspect, a system is provided for implementing the above-described method. The system includes a content filter configured to intercept outgoing IP connection requests, a DNS proxy configured to evaluate and resolve DNS queries, and a memory storing an allow list. The system permits connection requests for IP addresses on the allow list and blocks or resets those that are not, unless resolved and validated via a permitted DNS query.

[0012] In yet another aspect, an iOS device is provided that includes a processor, memory, a content filter, and a DNS proxy.The memory stores an allow list of IP addresses . The content filter intercepts outgoing IP connection requests and determines whether to permit or block them based on the allow list . The DNS proxy evaluates whether an unresolved request is associated with a permitted domain name , and i f so , resolves the domain and updates the allow list accordingly . The device is optionally provisioned via a Mobile Device Management (MDM) system.

[0013] These and other aspects , features , and advantages of the disclosure will be readily understood from the following detailed description taken in conj unction with the accompanying drawings and claims .BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The features and advantages of the various exemplary embodiments will become apparent from the following detailed description when considered in conj unction with the accompanying drawings . Where possible , the same reference numerals and characters are used to denote like features , elements , components , processes , steps or portions of the various embodiments . It is intended that changes and modi fications can be made to the described and shown exemplary embodiments without departing from the true scope and spirit of the inventive embodiments described herein as defined by the claims .

[0015] FIG . 1 is a flow diagram showing a method according to an embodiment of the present disclosure .

[0016] FIG . 2 is a flow chart illustrating a method for regulating IP connectivity on an iOS device according to an embodiment of the present disclosure .DESCRIPTION OF THE DISCLOSURE

[0017] The ubiquity of the internet has led to an assumption that any device can access any destination, any port, and any service. As connectivity has reached this high level of saturation, so has criminal opportunity. This cat-and-mouse game between organized cybercrime and IT security efforts is becoming an ever more granular process.

[0018] Exemplary embodiments relate to methods and systems which permit passage of Internet Protocol (IP) connectivity when originating requests were resolved by the Domain Name Server (DNS) query, and to otherwise block IP connectivity as a default. This process can operate on iOS devices using native components.

[0019] Throughout this description, preferred embodiments and examples illustrated should be considered as exemplars, rather than as limitations on the present disclosure. As used herein, the term "invention," "device," "method," "disclosure," "present invention," "present device," "present method," or "present disclosure" refers to any one of the embodiments of the disclosure described herein, and any equivalents. Furthermore, reference to various feature (s) of the "invention," "device," "method," "disclosure," "present invention," "present device," "present method, " or "present disclosure" throughout this document does not mean that all claimed embodiments or methods must include the referenced feature (s) .

[0020] It is also understood that when an element or feature is referred to as being "on" or "adjacent" to another element or feature, it can be directly on or adjacent the other element or feature or intervening elements or features may also be present. It is also understood that when an element is referred to as being "attached, " "connected" or "coupled" to another element, it can be directly attached, connected or coupled tothe other element or intervening elements may be present. In contrast, when an element is referred to as being "directly attached, " "directly connected" or "directly coupled" to another element, there are no intervening elements present.

[0021] Although the terms first, second, etc., may be used herein to describe various elements, components, or steps, these elements, components, or steps should not be limited by these terms. These terms are only used to distinguish one element, component, or step from another element, component, or step. Thus, a first element or component discussed below could be termed a second element or component without departing from the teachings of the present disclosure. As used herein, the term "and / or" includes any and all combinations of one or more of the associated list items.

[0022] The terminology used herein is for describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises," "comprising," "includes," "including," "has," "having," and similar terms, when used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0023] Even though DNS has existed for a long time, applications do not need to use DNS. Specifically malicious applications have a preference to go direct-by-IP address so that they can avoid the breadcrumbs left behind when using DNS. The following example is illustrative. An attacker may attemptto connect to the machine with the IP address https: / / 216.239.38.120, which is the IP address associated with the website at https: / / www.google.com. If the connection is attempted on the local network, or with the ISP or a cloud DNS provider, using the IP address only without a DNS query, then the connection attempt merits further scrutiny. Throughout this application, for ease of reference, a connection attempt of this kind (i.e., direct-by-IP without a DNS query) is referred to as "a stranger." If the connection attempt by the attacker is made on the local network, the ISP and / or the cloud DNS provider with a DNS query, then the attempt may have been logged such that there is a breadcrumb trail leading back the attacker, making the attacker vulnerable to forensic investigations after the fact. Thus, the clear preference for attackers is the attempt to connect with IP addresses only, without making a DNS query.

[0024] He re, a stranger is a system attempting to connect to an IP address that was not discovered via DNS. In the above example, the system attempting to access https: / / 216.239.38.120 is a stranger up until the connection is attempted using https: / / www.google.com (a DNS query) at which point the DNS server indicates that www.google.com translates to 216.239.38.120. At this point, the system attempting the connection is no longer deemed to be a stranger for a period of time referred to as the Time To Live (TTL) . After the TTL expires, the system becomes a stranger again until it attempts to connect using a DNS query.

[0025] As previously noted, this process is the subject matter of U.S. Pat. No. 10, 686,753, which is commonly owned with the present application. Embodiments of the present disclosure include systems and methods of denying connection attempts by strangers on iOS devices. In a method according to oneembodiment of the present disclosure, two native components of iOS devices are utilized: the content filter and the DNS proxy.

[0026] The content filter runs continuously in the background; all device egress traffic passes through it, regardless of the application attempting egress.

[0027] To mitigate latency in the DNS process, a DNS proxy may be used. A DNS proxy server forwards DNS requests to other recursive servers and receives replies that are sent back to devices on the network, often called DNS clients. Because DNS proxies also cache the results of previous queries, they can help to improve the speed of resolving DNS requests. In this case, the DNS proxy specifies which DNS server an iOS device is to use, including multiple resolvers in aggregate.

[0028] In general, applications that run continuously in the background are not a fit for an application store ecosystem. Instead, these two payloads / applications are only deliverable via Mobile Device Management (MDM) , which is the administration of mobile devices, such as smartphones, tablet computers, and laptops. This means that an application leveraging these two components may be enterprise-friendly, but not consumer- accessible .

[0029] FIG. 1 is a flow diagram showing a process 10 of accepting / denying a connection between an iOS device and an outside system. The process 10 comprises the following steps. An iOS device makes an outgoing IP protocol connection attempt in step 1. Next, the content filter checks to see if the destination IP address is in an allow list in step 2, such that the connection is allowable. If the content is allowed, then it is determined whether the connection is a stranger or not in step 3. If the connection is allowed, then the destination IP address is not a stranger, and the device is allowed to make anoutgoing IP protocol connection. If the destination IP address is not on the allow list, then the connection might be a stranger. In this case, the DNS proxy checks to see if the DNS query is allowed in step 4. If it is allowed, then the query is resolved, the IP address is added to the allow list, and the connection is allowed in step 5. If the query is not allowed, the connection is a stranger, and a TCP-reset occurs or the connection (UDP / other) is blocked.

[0030] In addition to being able to specify the DNS server to use, the DNS proxy can use an array of available DNS servers, all of which must offer a non-blocked answer in order for the query to be permitted.

[0031] FIG. 2 is a flow chart illustrating a method 20 for regulating Internet Protocol (IP) connectivity on an iOS device according to an embodiment of the disclosure. This particular exemplary method comprises the following steps. An outgoing IP connection request from an application executing on the iOS device is initiated in step 21. A content filter operating on the iOS device filters the outgoing IP connection request to determine whether a destination IP address is present in a predetermined allow list in step 22. The outgoing IP connection request is permitted when the destination IP address is in the allow list in step 23. If the destination IP address is not in the allow list, a DNS proxy operating on the iOS device determines whether the outgoing IP connection request is associated with a permitted domain name resolved via a DNS query in step 24. The destination IP address is added to the allow list if the DNS query is permitted and results in a resolved IP address in step 25. The outgoing IP connection request is blocked or the connection is reset if the DNS query is not permitted in step 26.

[0032] Various systems may be used to implement the methods and algorithms disclosed herein . For example , a system for regulating IP connectivity on an iOS device comprises the following components . A content f ilter is configured to operate on the iOS device and intercept outgoing IP connection requests from one or more applications . A memory stores an allow list of IP addresses . A DNS proxy is configured to intercept DNS queries from the iOS device , determine whether a DNS query is permitted based on predefined criteria, resolve permitted DNS queries to IP addresses , and update the allow list in the memory with resolved IP addresses . The content filter is further configured to permit an outgoing IP connection request when the destination IP address is in the allow list and block or reset the outgoing IP connection request when the destination IP address is not in the allow list and not associated with a permitted DNS query .

[0033] Various devices may also be used to implement methods and algorithms according to embodiments of the present disclosure . For example , an iOS device configured to regulate IP connectivity comprises the following components . A memory is communicatively connected to a processor . The memory stores an allow list of IP addresses . A content filter is executable by the processor and configured to intercept outgoing IP connection requests initiated by applications operating on the device . A DNS proxy is executable by the processor and configured to receive DNS queries from the device , determine whether a DNS query is permitted based on predefined rules , resolve permitted DNS queries to destination IP addresses , and update the allow list with the resolved IP addresses . The content filter is further configured to allow outgoing IP connection requests to destination IP addresses in the allow list , and block or reset outgoing IP connection requests todestination IP addresses not in the allow list and not associated with permitted DNS queries .

[0034] The various exemplary inventive embodiments described herein are intended to be merely illustrative of the principles underlying the inventive concept . It is therefore contemplated that various modi fications of the disclosed embodiments will without departing from the inventive spirit and scope be apparent to persons of ordinary skill in the art . They are not intended to limit the various exemplary inventive embodiments to any precise form described . Other variations and inventive embodiments are possible in light of the above teachings , and it is not intended that the inventive scope be limited by this speci fication, but rather by the claims following herein .

[0035] Although the present disclosure has been described in detail with reference to certain preferred configurations thereof , other versions are possible . Embodiments of the present disclosure can comprise any combination of compatible features shown in the various figures , and these embodiments should not be limited to those expressly illustrated and discussed . Therefore , the spirit and scope of the disclosure should not be limited to the versions described above . Moreover, it is contemplated that combinations of features , elements , and steps from the appended claims may be combined with one another as i f the claims had been written in multiple dependent form and depended from all prior claims . Combination of the various devices , components , and steps described above and in the appended claims are within the scope of this disclosure . The foregoing is intended to cover all modi fications and alternative constructions falling within the spirit and scope of the disclosure .

Claims

CLAIMSWE CLAIM :1 . A method for regulating Internet Protocol ( IP ) connectivity on an iOS device , the method comprising : initiating an outgoing IP connection request from an application executing on the iOS device ; filtering, by a content filter operating on the iOS device , the outgoing IP connection request to determine whether a destination IP address is present in a predetermined allow list ; permitting the outgoing IP connection request when the destination IP address is in the allow list ; when the destination IP address is not in the allow list , determining, by a DNS proxy operating on the iOS device , whether the outgoing IP connection request is associated with a permitted domain name resolved via a DNS query; adding the destination IP address to the allow list i f the DNS query is permitted and results in a resolved IP address ; and blocking the outgoing IP connection request or resetting the connection i f the DNS query is not permitted .2 . The method of claim 1 , wherein the DNS proxy aggregates responses from a plurality of DNS resolvers , and the DNS query is permitted only i f each resolver provides a non-blocked response .3 . The method of claim 1 , wherein the DNS proxy caches resolved IP addresses for a time period defined by a time-to-live ( TTL ) value , and allows outgoing IP connection requests to the cached addresses during the TTL period .4 . The method of claim 1 , wherein blocking the outgoing IP connection request comprises issuing a TCP reset for TCP connections or silently dropping packets for non-TCP connections .5 . The method of claim 1 , further comprising delivering the content filter and DNS proxy to the iOS device via a Mobile Device Management (MDM) platform .6 . The method of claim 1 , wherein the content filter monitors all egress traf fic from the iOS device , regardless of the source application .7 . The method of claim 1 , wherein an outgoing IP connection request is classi fied as originating from a " stranger" when the associated IP address has not been previously resolved via a permitted DNS query .8 . A system for regulating Internet Protocol ( IP ) connectivity on an iOS device , comprising : a content filter configured to operate on the iOS device and intercept outgoing IP connection requests from one or more applications ; a memory storing an allow list of IP addresses ; a DNS proxy configured to : intercept DNS queries from the iOS device , determine whether a DNS query is permitted based on predefined criteria, resolve permitted DNS queries to IP addresses , and update the allow list in the memory with resolved IP addresses ; wherein the content filter is further configured to :permit an outgoing IP connection request when the destination IP address is in the allow list ; and block or reset the outgoing IP connection request when the destination IP address is not in the allow list and not associated with a permitted DNS query .9 . The system of claim 8 , wherein the DNS proxy is further configured to query a plurality of upstream DNS resolvers , and permit a DNS query only when all resolvers provide non-blocked responses .10 . The system of claim 8 , wherein the DNS proxy includes a caching mechanism for storing resolved IP addresses for a predetermined time-to-live ( TTL ) , and the content filter permits connection requests to such addresses during the TTL period .11 . The system of claim 8 , wherein the content filter issues a TCP reset for unpermitted TCP connection requests and drops nonTCP connection requests silently .12 . The system of claim 8 , wherein the content filter and DNS proxy are deployed to the iOS device using a Mobile Device Management (MDM) system .13 . The system of claim 8 , wherein the content filter identi fies connection attempts to IP addresses not previously resolved via DNS as originating from strangers , and classi fies them for blocking or further action .14 . An iOS device configured to regulate Internet Protocol ( IP ) connectivity, comprising : a processor ;a memory communicatively coupled to the processor, the memory storing an allow list of IP addresses ; a content filter executable by the processor and configured to intercept outgoing IP connection requests initiated by applications operating on the device ; a DNS proxy executable by the processor and configured to : receive DNS queries from the device , determine whether a DNS query is permitted based on predefined rules , resolve permitted DNS queries to destination IP addresses , and update the allow list with the resolved IP addresses ; wherein the content filter is further configured to : allow outgoing IP connection requests to destination IP addresses in the allow list , and block or reset outgoing IP connection requests to destination IP addresses not in the allow list and not associated with permitted DNS queries .15 . The iOS device of claim 14 , wherein the content filter and DNS proxy are deployed to the iOS device using a Mobile Device Management (MDM) system .

Images