Patent Application
20240297837
The present invention relates generally to internet security, and more particularly to methods and systems for detecting and alerting on Domain Name System (DNS) related risk of tampering with internet data transfer.
Domain name system (DNS) servers are used in the internet to translate domain names into various attributes related to hosts over the internet such as internet protocol (IP) addresses. One problem related to the DNS server system is that hackers may fraudulently change records returned thereby. For example, by changing the IP address associated with a domain name, a hacker can redirect internet traffic from a legitimate website to a phony website, even if the proper domain name is used. The phony website can then be used for various kinds of malicious activity such as: man-in-the-middle type attacks, credential theft, and spreading malware.
A common means of coping with the above problem is Domain Name System Security Extensions (DNSSEC), which is a suite of extension specifications for securing DNS related data exchanged in IP networks. However, internet users cannot be confident that responses to their DNS queries are always being DNSSEC verified.
In U.S. patent application Ser. No. 20/070,083670 internet user's computer stores domain names and corresponding IP addresses of all websites visited with the computer. Each time a website is accessed, the IP address received from the DNS server is compared to the IP address stored in the database. If the IP addresses are identical, then the newly received IP address is likely legitimate. If the IP addresses are different, then the newly received IP address is likely fraudulent, and the user can be warned before loading the website.
In U.S. patent application Ser. No. 20/200,341966, a DNS data collector that can be either part of a local network or part of an external network is implemented. The DNS data collector receives and collects logs from DNS transactions collected from various sources that include DNS resolvers, DNS servers, and DNS aggregator, which can be part of a local network or can be part of an external network. The DNS data collector determines if the DNS logs are missing any data related to the DNS transactions. The missing DNS data is looked up and the DNS logs are completed. Completed DNS logs can then be sent for analysis, such as for DNS traffic threats.
However, in the above references, as well as in the known art, missing is a solution for internet-global detection of false DNS records that may constitute a threat to data transfer associated with given one or a plurality of hosts.
Accordingly, it is a principal object of the present invention to provide a method for alerting on incorrect DNS records returned by DNS servers over the internet and related to data transfer associated with given one or more hosts. Thus, in accordance with an embodiment of the present invention, the disclosed method comprises the following steps:
In some embodiments, acquiring the DNS server list comprises the steps of:
In some embodiments, acquiring the DNS server list comprises the steps of:
In some embodiments, the given one or more hosts pertain to a client organization, and acquiring the DNS server list comprises extracting from one or more authoritative DNS servers of the client organization identities of DNS servers that affect data transfer to said given one or more client organization's hosts.
In some embodiments, acquiring the DNS server list includes employing proxy devices so as to allow the computer system to reach remotely located DNS servers.
In some embodiments, scrutinizing the DNS servers in the DNS server list includes employing proxy devices so as to reach remotely located DNS servers.
In some embodiments, acquiring the DNS server list comprises including in the list DNS servers according to one or more of the following criteria:
In some embodiments, detecting the incorrect query response comprises a retry process.
In some embodiments, acquiring the expected result list comprises querying trusted DNS servers.
In some of these embodiments, querying the trusted DNS servers comprises querying authoritative DNS servers.
In a typical embodiment, each DNS query refers to one of the following DNS records: A, AAAA, MX, CNAME, NS, SRV, and TXT.
In some embodiments, repeatedly sending the queries comprise employing one or more of the following scheduling schemes: a random schedule, a pseudorandom schedule, a query dependent schedule, a priority based schedule and an Artificial Intelligence (AI) based schedule.
In some embodiments, employing the priority based schedule comprises prioritizing the DNS servers according to one or more of the following properties thereof:
In some embodiments, the above method further comprises prioritizing the issued alerts based on applying one or more of the following prioritizing criteria with relation to the incorrectly responding DNS server:
In accordance with an embodiment of the present invention, there is also provided a computer system adapted to perform the above method.
The present invention will be more fully understood from the following detailed description of the embodiments thereof, taken together with the drawings in which:
Embodiments of the present invention provide methods and systems for detecting and alerting on risk of tampering with internet data associated with one or more given hosts, either physical or virtual. The tampering discussed herein is typically performed by malicious parties and comprises affecting DNS records returned from DNS servers as explained in the following. However, the disclosed techniques are also applicable to other causes of incorrect DNS records besides tampering, such as technical and human faults.
Referring to
As shown in
System managers 120a, 120b . . . 120m represent management entities realized by either dedicated software programs, human administrative activity or a combination thereof. They exchange information with system 102 concerning security threats to user devices 124a-to-k and to hosts pertaining to client organizations 112a-to-m. The exchanged information relates to DNS servers 124a, 124b, . . . 124k, k being any whole number. This information and its relation to DNS servers 124a-to-k is described in detail with reference to
The above description has focused on the specific elements of communication environment 100 that are essential for understanding certain features of the disclosed techniques. Conventional elements and connectivity that are not needed for this understanding have been omitted from
Referring now to
Flowchart 200 begins with an acquiring step 204, in which system 102 attempts to acquire a “DNS server list” comprising identifications of as many deemed reliable DNS servers as possible over the internet that may affect data transfer of users 104a-to-n related to client systems 112a-to-m. In embodiments of the present invention, system 102 acquires the DNS server list by applying either one or an applicable combination of the following means and inclusion criteria:
In typical embodiments system 102 keeps updating the DNS server list by occasionally applying either one or an applicable combination of the above means. The aforementioned term “identifications” typically relates to the IP address and/or the name of the relevant DNS servers.
Next, in an acquiring step 208, system 102 acquires a “reference association list”. This list typically relates to one or more hosts pertaining to at least one client organization whose owner, or operator, requests a detection and alert service, such as explained above, from system 102. A typical reference association list comprises an association between:
Normally, acquiring a reference association list involves some administrative activity that involves the client organization owner, or operator, and the operator of system 102. It should be noted that in a typical embodiment, system 102 is adapted to process a plurality of reference association lists according to this and the following method steps description. The above expected results may be provided to system 102 by system managers 120a-to-m. In some embodiments system 102 acquires at least part of the expected query responses by querying commonly deemed trusted DNS servers. Such trusted servers may pertain to some well-known organizations, or may be relevant authoritative DNS servers. For reaching the authoritative DNS servers of e.g. www.example.com, system 102 first queries the DNS root about com's DNS server IP address and then queries com's DNS server about example.com's DNS server address. In some embodiments, the order of steps 204 and 208 may be interchanged,
The following table provides example DNS record types that may be included in the above query list and are prone to be tampered with in order to maliciously affect data transfer over the internet that may be associated with the hosts and users of client organizations 112a-to-m. For each record type, the table shows an example expected query response of a user query and an example adverse outcome that would result if an attacker tampers with the queried record thereby causing a falsified/incorrect query response to be returned instead of the expected one. In the table, the domain “example.com” refers to the domain name of an example client organization, i.e. one of the systems 112a-to-m. The attacker's actions and their consequences are provided in bold letters.
Flowchart 200 proceeds to an optional optimization step 212, which comprises creating a reduced instance of the DNS server list by directing it to the specific hosts included in a given reference association list. An apparent reduction criterion may be including only the DNS servers that are expected to serve users of the hosts included in the given reference association list. Such user distinction is achieved in some embodiments based e.g. on the users' geolocation and/or organizational affiliation.
In a scrutinizing step 216, system 102 scrutinizes the servers in the DNS server list by repeatedly sending to each of them each of the queries included in the query list. In typical embodiments, repeating the queries may involve various scheduling schemes and combinations thereof including but not limited to the following:
a random schedule, a pseudorandom schedule, a query dependent schedule e.g. higher frequency of queries related to more sensitive hosts, higher frequency of queries related to DNS servers that affect more users of a specific client organization, a priority based schedule e.g. higher frequency of queries related to more frequently accessed hosts, and Artificial Intelligence (AI) including machine-learning based schedules.
In some embodiments, employing priority based schedule comprises prioritizing the DNS servers according to one or more of the following properties thereof:
Next, in a comparing step 220, the software program in system 102 compares each query response obtained while scrutinizing the DNS servers with its expected query response included in the reference association list so as to detect incorrectly responding DNS servers. As long as no incorrect response is detected, flowchart 200 keeps returning through a decision step 224 to scrutinizing step 216, which keeps running. Once an incorrect response is detected, system 102 logs its details in a logging step 228. Flowchart 200 then returns to scrutinizing step 216 and also proceeds to an analysis step 232. In this analysis the software program in system 102 tries to find out trends and possible common denominators between the detected incorrect responses. The outcome of this analysis is an alert report produced in step 240 for delivery to one of the system managers 120a-to-m. In some embodiments the system manager is alerted immediately upon each anomaly detection. The analysis of step 232 also serves to improve step 216 scrutinizing scheduling in step 236. In typical embodiments, proxy devices such as the aforementioned 128, are used for querying DNS servers in step 204 as well as in step 216. In some embodiments, in these steps detecting an incorrect query response comprises a retry process, i.e. it is bases on more than a single incorrect response.
Back to step 232, its purpose is to prioritize the faults detected in step 220 so as to produces effective alert reports in step 240 as well as helpful improvements in step 236. One or more of the following prioritizing criteria are employed in various embodiments of the present invention:
The disclosed method typically comprises an obvious complementing step, which is attempting to pinpoint the cause of a detected fault and preferably also to mitigate it. This step is not shown in flowchart 200 since it mostly involves administrative rather than technical activity. This activity may include complaining to the owner of the faulty DNS server, trying to identify any malicious party that might be responsible for the detected fault possibly based on the incorrect response properties, etc.
Flowchart 200 is an example flowchart, which was chosen purely for the sake of conceptual clarity. In alternative embodiments, any other suitable flowchart can also be used for illustrating the disclosed method. Method steps that are not mandatory for understanding the disclosed techniques were omitted from
It will thus be appreciated that the embodiments described above are cited by way of example, and that the present invention is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present invention includes both combinations and sub-combinations of the various features described hereinabove, as well as variations and modifications thereof which would occur to persons skilled in the art upon reading the foregoing description and which are not disclosed in the prior art.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/IL2022/050673 | 6/22/2022 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 63216643 | Jun 2021 | US |
