Method for detection of DNS spoofing servers using machine-learning techniques

Abstract

The present disclosure is related to the network communication technology field and relates to a method for the classification and recognition of the Domain Name System (DNS) server, using machine-learning techniques. The classification process assigns a given DNS server as belonging to a preset of classes. For example, it enables to label a DNS server as either benign or malicious. On the other hand, the recognition process seeks the identification of the DNS server behavioral profile, which, consequently, can be used to assess the DNS server trustworthiness before DNS responses can be reliably used, e.g. identification of well-known and trusted DNS servers. Hence, the present patent, by the means of detecting the DNS server RFC adherence improves user security through the classification and recognition of DNS characteristics. Therefore, security solutions can use the DNS server characteristics to assess its trustworthiness before DNS responses can be reliably used.

Claims

1. A method for detection of spoofed DNS servers using machine-learning techniques, the method comprising: sending, by a Message Handler module, specially crafted DNS queries to be used for evaluation of DNS server DNS protocol Request for Comments (RFC) adherence; parsing, by the Message Handler module, DNS responses from the evaluated DNS server; extracting, by a Feature Extractor module, features from received DNS responses to be used for recognition or classification purposes; recognizing, by a DNS Server Recognition module, DNS servers to be used for external solutions; classifying, by a DNS Server Classification module, DNS servers to be used for external solutions; and wherein the DNS queries used for evaluation of DNS server DNS protocol Request for Comments (RFC) adherence are categorized among: i) adhere to RFC standard; ii) does not adhere to RFC standard; or iii) no response is received during a timeout interval predefined.

2. The method of claim 1, wherein the sending of the specially crafted DNS queries to be used for evaluation of DNS server DNS protocol RFC adherence comprises: building a set of DNS query messages in which each DNS query evaluates the DNS server adherence to a DNS protocol RFC specification; and sending the set of DNS query messages over a communication link to the DNS server.

3. The method of claim 2, wherein the parsing of the DNS responses from the evaluated DNS server comprises: receiving, over the communication link, a set of DNS server responses; and parsing the received set of DNS server responses according to the DNS protocol RFC specification.

4. The method of claim 1, wherein the extracting of the features from the received DNS responses to be used for recognition or classification purposes comprises: determining, by the Feature Extractor module, the features to be extracted according to a machine-learning model; extracting, by the Feature Extractor module, the features according to the machine-learning model; and preprocessing, by the Feature Extractor module, the extracted features according to the machine-learning model.

5. The method of claim 1, wherein the recognizing of the DNS servers to be used for external solutions comprises: applying, by the DNS Server Recognition module, a machine-learning model to recognize the DNS servers; determining, by the DNS Server Recognition module, the recognized DNS servers according to the applied machine-learning model; and assembling, by the DNS Server Recognition module, the set of determined DNS servers.

6. The method of claim 1, wherein the classifying of the DNS Servers to be used for external solutions comprises: applying, by the DNS Server Classification module, a machine-learning model for classification of DNS Servers; determining, by the DNS Server Classification module, a DNS Server type according to the applied machine-learning model; and assembling, by the DNS Server Classification module, a set of DNS Server types.

7. The method of claim 1, wherein the DNS Server is recognized by applying a machine-learning model for recognition purposes.

8. The method of claim 7, wherein the machine-learning model is given as input a set of DNS Server features and outputs a related recognized DNS Server.

9. The method of claim 8, wherein the machine-learning model used for recognition determines the DNS Server recognized.

10. The method of claim 1, wherein a DNS Server type is determined by applying a machine-learning model for classification purposes.

11. The method of claim 10, wherein the machine-learning model is given as input a set of DNS Server features and outputs a DNS Server type.

12. The method of claim 11, wherein the machine-learning model used for classification determines a DNS Server group.

13. The method of claim 1, wherein features of the DNS Server are determined by applying a feature extraction process.

14. The method of claim 13, wherein the feature extraction process is given as input a set of DNS server replies and outputs a DNS Server feature set.

15. The method of claim 14, wherein the feature set is computed by building a feature set by copying message field values or by further processing to establish the feature values.

16. The method of claim 14, wherein messages to be used for the feature extraction process are determined by a Message Handler process, which builds a set of DNS queries, sends the DNS queries to a DNS server, and receives a set of DNS replies, which are used for classification and recognition process.

17. The method of claim 1, further comprising detecting spoofed DNS Servers by machine-learning.

18. The method of claim 1, wherein messages used for at least one of the recognizing and the classifying are collected over the communication link.

19. The method of claim 1, wherein a user determines the spoofed DNS server based on the classifying of the DNS servers.

20. The method of claim 1, wherein the detection of the spoofed DNS server applies a set of machine-learning models for at least one of the recognizing and the classifying.

Description

BRIEF DESCRIPTION OF DRAWINGS

(1) The objectives and advantages of the current invention will become clearer through the following detailed description of the example and non-limitative drawings presented at the end of this document:

(2) FIG. 1 shows the typical application scenario for the present invention.

(3) FIG. 2 shows the information flow for the present method.

(4) FIG. 3 shows the behavior of each component of the presented method.

(5) FIG. 4 shows the proposed access point characteristic detection method.

(6) FIG. 5 shows a feature vector extracted from a DNS server.

(7) FIG. 5 shows an illustrative embodiment of the present invention.

(8) FIG. 6 shows an illustrative embodiment of the present invention.

DETAILED DESCRIPTION

Advantages of the Invention

(9) Based on the prior art problems, we can enumerate the following advantages of present invention:

(10) The present invention detects DNS spoofing servers without relying on third-party mechanisms. Hence, the device using the present invention is able to detect potentially malicious DNS servers without connecting to a secondary DNS server neither using third-party tools.

(11) The present invention is able to detect the software used for the execution of the DNS server. Therefore, it improves user security, because, the user can be aware of the tools used to set the DNS server. Hence, such information can be used, for instance, to detect common tools used for spoofing DNS servers.

(12) The present invention is able to detect a DNS spoofing server regardless of the domain it is spoofing. The present invention performs its detection based on the DNS behavior, rather than the DNS responses content. Therefore, the detection can be performed even if an attacker changes the spoofed domains.

(13) The present invention is able to detect DNS spoofing servers within LAN or WAN scope. The technique extracts the DNS server behavior remotely, therefore, it does not require that the DNS server is executed in LAN scope.

(14) The present invention does not require a signature database to perform its detection. The proposed technique relies on the DNS server behavior and a machine-learning model to detect DNS spoofing servers.

(15) The present invention is able to detect a DNS server spoofing responses of another DNS server. For instance, the technique is able to detect a DNS server with a behavior different from the server it was previously connected. Therefore, the present method is able to detect DNS spoofing servers during a Man-In-The-Middle attack for instance.

(16) The present invention does not require a dedicated hardware to fulfill its goals. The detection process can be readily embedded in resource-constrained devices with little or no battery impact. In Addition, the detection is made by software, requiring only access to the communication channel with the DNS server.

(17) The present invention does not require changes in DNS protocol neither a dedicated architecture to perform its detection. Hence, the proposed technique is able to detect DNS spoofing servers directly in the device executing the invention.

(18) An already known limitation of the invention is that a skilled attacker may use a different DNS server to spoof its responses. For instance, an attacker may execute an application typically used for benign DNS servers used to reply spoofed responses. In such a case, the present invention would detect the DNS server as benign, i.e. running using a benign DNS server application. It is important to note that this is uncommon, since the setup of a benign DNS server demands time and prior knowledge. Nonetheless, in general, attackers use well-known DNS spoofing tools to perform such attack. Hence, the present invention would be able to detect them. Another challenge on the present invention includes training dataset maintenance. If an attacker creates a new tool for DNS spoofing with a high variation from traditional tools, the trained model can fail to detect. The new tool should behave very different when compared with previous tools, since the trained model consider small modification in the behavior.

(19) New Features of Invention

(20) Current security solutions for networked devices are unable to evaluate the DNS server trustworthiness without using third party such as public key infrastructure or secondary DNS server, before performing domain name resolutions. Hence, user devices may be redirected to malicious domains in which are subjected to all sort of attacks, such as connection eavesdropping, download of malicious content, stealing of credentials and sensitive information, among others. Therefore, the present invention tackles the security gap when devices are performing domain name resolutions. This because the present invention enables security solutions to evaluate the DNS server RFC adherence, which, consequently, provides a better metric to classify and recognize a DNS server. Hence, security solutions can better evaluate the DNS server trustworthiness, thus, improving user security. To achieve such goal, the present invention actively classifies and recognizes DNS server behavior according to the messages replied from it after specially crafted queries were sent.

(21) Once all steps of the invention are successfully completed, the method of the present invention provides the device enriched information regarding the DNS server trustworthiness. As an example, the method of the present invention is able to recognize whether the DNS server application is well-known and trusted or unknown and potentially spoofed server. This method also adds the possibility to classify the software used for setting a DNS server, e.g. software usually used for benign purposes such as dnsmasq or bind9, or even malicious purposes such as Ettercap or dnsspoof.

(22) Therefore, when using this invention, a device will be able to detect malicious and consequently spoofed DNS servers without relying in third-party mechanisms. Hence, the present invention provides value to the market, as it can be readily used in current and future devices without any hardware changes, and with small computational resource demands.

(23) The attached drawings will be described in detail with mention to the reference numbers in them whenever as possible. The specific examples used throughout the specification are used only for clarification purposes and are not intended to limit the applicability of the present invention.

(24) An application scenario of the present invention is shown in FIG. 1. The scenario includes a device (101) and a DNS server (102). The device communicates with the DNS server using a wired or wireless communication link. Both device and DNS server communicate using a common and shared protocol, as defined in the DNS protocol specification. The device and DNS server may be in the or in different networks. The device must be able to communicate with the DNS server. Overtime, the device may perform domain resolutions to a DNS server. To achieve such goal, the device sends a DNS query message (103) to the DNS server. In counterpart, the DNS server replies it by sending a DNS response (104). In the present invention, it is expected that the DNS server reply to the received DNS queries over time. If the query is not answered in a period, a timeout expires, and it is assumed as no answer.

(25) FIG. 2 illustrates the present invention information flow. The present invention is executed in a device. The information flow starts with the device calling the present invention method (201). The invention calling can be executed after a specific event is triggered. For instance, the device may be connected to a new network, or the used DNS server may have changed its address. Hence, a typical usage scenario for the invention is regarding DNS server changes, since the device may desire to reevaluate the newly connected DNS server. After the present invention is called, the Message Handler module is executed (202).

(26) The goal of the message handler module is to send and receive DNS query and DNS response messages to the DNS server. Therefore, the message handler module sends a set of DNS queries to the DNS server. Each DNS query is specially crafted to validate a specific Request-For-Comment (RFC) specification of the DNS protocol. Consequently, each DNS query must generate a DNS response by the DNS server as a counterpart. For example, a specially crafted DNS query can be a query to a “onion” domain, which, according to RFC 7686 must be replied with a NXDOMAIN by the DNS server. Hence, the message handler module is executed until all the specially crafted DNS queries were performed or a time interval has passed. The time interval expiration goal is to determine whether the DNS server replies to a specific DNS query or not. For instance, a spoofed DNS server may not reply to a DNS query made using TCP protocol, which according to RFC 7766 all servers must provide support. After the execution of all specially crafted DNS queries, gathering of all DNS replies, or time interval has expired, the messages (203) are forwarded to a Feature Extraction module (204).

(27) The goal of the feature extraction module is to build the feature vector to be used for classification and recognition purposes. To this end, the feature extraction module receives as input a set of DNS responses and outputs a feature vector. Hence, the feature extraction module must be able to interpret the DNS message network protocol. The feature extraction module, for each feature that compounds the feature set, performs the extraction of feature value over the DNS response or a set of DNS responses. In other words, the feature extraction module may extract a feature directly from a single DNS response, or after the analysis of several DNS responses. As an example, a feature that requires the analysis of several DNS responses is the Time-To-Live (TTL) value analysis, which according to the RFC 1035 must be decremented only for non-authoritative name servers. Feature values varies according to the analyzed DNS response. A feature value may be represented using a numerical or categorical value. An example of numerical value includes, but are not limited to, the standard deviation of TTL values. An example of categorical values includes, but are not limited to, adheres RFC standard, does not adhere to RFC standard, or no response from server. After the extraction of all features, the feature set is forwarded (205) to the DNS Server Recognition module (206) and the DNS Server classification module (207).

(28) The DNS Server recognition module receives as input a feature set, and outputs a related DNS server recognized. To fulfill its goal, the DNS Server recognition module applies a machine-learning model that recognizes similarities between its input and a set of known examples in the training data. End-device energy consumption remains unaffected during the model training process, since this step is normally performed in an external device and then ported as an executable binary to the end-device. The recognizer may rely on clustering, classification, distance-based or other machine-learning techniques. For example, a recognizer may use a distance-based algorithm to return the most similar DNS server for a given input. In addition, since the proposed solution will be executed in an end-device, the recognizer must be energy efficient during the classification. Distance or decision based algorithm present low complexity, O(n log n), as examples but no limited as possible candidates for recognizer. Before the message enters to the machine-learning module, the DNS Server recognition module translates the feature set for a proper machine-learning input. As an example, the feature set translation may comprise none, all, or other of the following tasks: normalization, standardization, feature selection, feature reduction, among other pre-processing techniques. For instance, before applying a distance-based machine-learning model, the DNS Server Recognition module may perform feature normalization and feature reduction techniques. After the application of the machine-learning model, the recognized DNS Server is forwarded (208) to a Report module (209).

(29) The DNS Server Classification module applies a machine-learning model that classifies an input into a class. The class refers to a group of a given examples that presents the same properties. For example, a classifier may label an input according to the software used by the DNS server, in such a case the property is the software used by the DNS server. Before applying the machine-learning module, the DNS Server Classification module translates the feature set to a proper machine-learning input. As an example, the feature set translation may comprise none, all, or other of the following tasks: normalization, standardization, feature selection, feature reduction, among other preprocessing techniques. For instance, before applying a classifier machine-learning model, the DNS Server Classification module may perform a feature reduction technique. After the application of the machine-learning model, the labeled DNS Server is forwarded (208) to a report module (209).

(30) Finally, the report module goal is to gather the established DNS server recognized and classified and report it to the corresponding client. As an example, the client may be a security solution used by the device.

(31) The present invention, as shown in FIG. 3, provides a method for detection of spoofed DNS servers using machine-learning techniques comprising:

(32) sending, by a Message Handler module (301), specially crafted DNS queries (302) to be used for evaluation of DNS server (303) of its DNS protocol RFC adherence;

(33) parsing (304), by a Message Handler module, DNS responses (305) from the evaluated DNS server;

(34) extraction of features, by a Feature Extractor (306) module, from the received DNS responses trough the feature extraction method (307), converting them into a feature vector (308) to be used for recognition or classification purposes;

(35) recognition of DNS servers, by a DNS Server Recognition module (309), to be used for external solutions (311);

(36) classification of DNS servers, by a DNS Server Classification module (310), to be used for external solutions (311).

(37) The flowchart of the proposed method for detection of spoofed DNS Servers is illustrated in FIG. 4. The device starts the process after the triggering of an event (401). Examples of events that could trigger the proposed detection method includes, but are not limited to, changes of DNS address, connection to a new DNS address, periodic DNS server validation, among others. Then, the DNS server address are gathered from the device (402). In such a case, all information related to the communication needed between the device and the method must be gathered, in order to enable the proper communication between the entities. Afterwards, the set of specially crafted DNS queries are selected and built (403). Each specially crafted DNS query is used to validate a specific RFC specification from the DNS protocol. Then, the set of DNS queries can be performed. To this end, the invention performs the selected DNS queries (404) and wait for the related DNS server response (405) or a timeout expire (406), until all queries were performed (407). Each performed DNS query can generate a related DNS response or no response. Therefore, an expiration period must be used to ensure that the query has generated a response or not. For the sake of simplicity, in the flowchart, such process is shown sequentially, in which each DNS query is performed after another. However, the invention may also be implemented to perform such task in parallel, performing all queries and waiting for their response only once. When all queries are properly made, the extraction of features can be performed. To achieve such goal, for each DNS response (408) a related feature value must be extracted (409). A feature value comprises the DNS server behavior for the related DNS query made to it. Therefore, each DNS response generates a specific feature value. The feature extraction process is performed until all DNS responses have their feature values obtained (410). When all feature values are extracted, a feature vector is built (411), which then is used for recognition and/or classification purposes. For the sake of simplicity, in the flowchart, such process is shown sequentially, in which the recognition is performed before the classification process. However, the invention may also be implemented to perform such tasks in parallel, or even in the opposite order, performing first the classification task then the recognition task.

(38) If the recognition process is performed (412), it starts with the selection of a proper machine-learning model from the recognizer (413). Proper recognizer's machine-learning models are algorithms used for recognizing DNS server behaviors. With the proper recognizer machine-learning model, the corresponding set of features are selected (414). This process aims to building the feature set according to each recognizer machine-learning model. This process occurs because each model may rely in a different feature set, established according to each model obtainment process. The corresponding set of features building process includes none, all, or some of the process of feature extraction, selection, normalization, standardization, reduction and/or any other preprocessing task needed to properly apply the recognizer machine-learning model. Finally, the recognizer machine-learning model is applied to the built feature set (415). The recognizer machine-learning model outputs a recognized DNS server, which is stored (416) until all recognizers and classifiers are applied. If all recognizers are applied, the classification process begins (417), otherwise the next recognizer is selected, and the process starts again.

(39) If the classification process is going to be performed (418), a classifier is selected between a set of classifiers (419). Similar to the recognition process, a corresponding feature set is built for the selected classifier (420). The feature set building process includes none, all, or some of the process of feature extraction, selection, normalization, standardization, reduction and/or any other preprocessing task needed to properly apply the classifier machine-learning model. With the classifier feature set properly built, the classifier can be applied for the detection of the DNS server type (421). After applying the classifier machine-learning model, its output, the DNS server type, is stored until all classifiers are successfully applied (422). Finally, if all classifiers are applied, the report process can be performed; otherwise, the classification process is executed again, until all classifiers are applied (423).

(40) The report of the recognized DNS server and type is performed when all classifiers and/or recognizers are applied to the selected DNS server (424). The report process starts with the gathering of all detected DNS server recognized and types, obtained when applying the recognizers and/or classifiers. Afterwards, the obtained recognized DNS server and types are reported to the client that started the present invention detection process.

(41) DNS Queries Used to Evaluate the DNS Server

(42) As aforementioned described the DNS server is evaluated whether it follows the RFC specification or not. Hence, a set of queries must be made to it before a decision can be established. In the invention, these queries are called as crafted queries. In essence, a crafted query is similar to a general query. Nevertheless, objectives are different. While general queries are created to resolve a domain name, to verify the geographical location associated to a domain, among others, the crafted queries are created to validate the RFC specification. When we validate a RFC specification, we verify if the DNS protocol is correctly implemented. In the DNS spoofing tools, normally, for easiness, developers do not respect all the DNS protocol implementation. As an example of a general query, a client would like to access Samsung web site. The client will perform a query to the DNS server asking for the IP address to access Samsung website. In this case, a query is a request to resolve “samsung.com” domain and the response from DNS server would be the IP address that belongs to “samsung.com” domain, such as 23.200.54.105.

(43) Table 1 below shows examples of queries used to evaluate the DNS server RFC adherence. Based on the query number 8 of Table 1, as an example of a crafted query, the client will request a domain with all characters in uppercase such as “SAMSUNG.COM”, based on the RFC 1035, the DNS server should response also with all characters in uppercase, such as “SAMSUNG.COM” belongs to 23.200.54.105. We verified that this behavior is not followed in the DNS spoofing tools.

(44) Table 1 show some examples of the queries, but are not limited, that may be performed to create the feature vector:

(45) TABLE-US-00001 TABLE 1 DNS Queries used to evaluate the DNS Server Query Number RFC Query Expected Response 1 1035 Query with Response with RD flag set Recursion Desired (RD) flag set 2 1035 Query with RD There must be a response flag set, and with RD flag OPCode = 2 3 1035 Query with RD Response with Z flag unset flag set, and Z flag set 4 1035 Query with RD Response with RD flag unset flag unset 5 1035 Pointer Record Response with RD flag unset (PTR) Query with RD flag unset 6 1035 Query with Response must be code equal special 5 (refused) characters 7 1035 Query with more Response must be code equal than 63 5 (refused) characters 8 1035 Case Response must have an insensitive answer with all chars upper query 9 1035 Inverse query Server must reply with not implemented, code equal 4 10 1035 Case Server must reply with not insensitive implemented, code equal 4 inverse query 11 6891 Query with Same OPT must be in Option Codes response (OPT) 12 6891 Query with two Server must reply with code OPT equal 1 13 6891 Query with OPT Server must reply with code Name set as 1 equal 1 14 6891 Query with OPT Server must not reply with version set as code equal 0 FF 15 7686 Query for Server must reply with .onion query refused, code equal 5 16 1035 Query for Server must reply with a domain list of nameservers nameservers 17 1035 Query for Server must reply with a domain start of list of Start of Authority zone authority (SOA) 18 1035 Query for Server must reply with a domain list of SOA canonical name 19 1035 Query for IP Server must reply with code PTR equal 0, and there must be an answer 20 1035 Query for Server must reply with code HostInformation equal 0 or 3 (HINFO) 21 1035 Query for Well- Server must reply with a Known Services list of SOA (WKS) 22 7766 Query for TCP There must be a reply with DNS code equal 0 23 4033 Query for There must be a reply with DNSSEC additional records, a flag in additional records must be set 24 1035 Check Both queries must return inconsistencies the same IP address between query 1 and 8

(46) The feature vector needs at least eleven DNS answers to perform the classification. This is not a limitation from our system, since the more DNS queries are answered the better the classification.

(47) FIG. 5 shows an example of an extracted feature vector obtained after the feature extraction of a DNS server (501). For the sake of simplicity, only a subset of possible features is shown in the figure, however, other features can be extracted for the detection process. Examples of features that can be extracted from a DNS server include but are not limited to the number of performed queries, number of received responses, RFC adherence, and protocol support, among others. Therefore, feature values can be obtained directly from the message field value, for example, a flag in DNS response packet. In contrast, other feature values can only be obtained after a computational process, for example number of received DNS responses, among others.

(48) An illustrative embodiment of the present invention is shown in FIG. 6, in which an end-device (601) verify the behavior of a malicious DNS server (602) based on its RFC adherence. First, the end-device (601) connects to a new AP, receiving a new DNS server address to be used. Then, DNS server to query is received for domain server address. The DNS server adherence to the RFC specification is evaluated and achieved by sending a set of specially crafted DNS queries (603) to the DNS server. After the set of queries is performed, with the DNS responses (604), the end-device builds a feature vector (605) comprising the DNS server adherence to the RFC specification. The feature vector feeds a machine-learning classifier (606) that classifies the DNS Server as either malicious or benign (607). Finally, the classification is sent to the end-device as a pop-up message (608) to be displayed.

(49) Although the present disclosure has been described in connection with certain preferred embodiments, it should be understood that it is not intended to limit the disclosure to those particular embodiments. Rather, it is intended to cover all alternatives, modifications and equivalents possible within the spirit and scope of the disclosure as defined by the appended claims.