Abstract
This paper provides a detailed discussion of Domain Name System (DNS) and DNS tunneling including the DNS tunneling framework, and DNS encoding mechanisms. Furthermore, works on the evaluation of DNS tunneling tools, and tunneling through Wi-Fi are discussed in detail. Finally,clear presentations of negative and positive aspects on DNS tunneling are detailed in the paper.
Introduction
This section explains the effective roles of DNS tunnelling in providing network security. For example, email protocol SMTP provides security to emails and updates the user on the presence of malicious code patterns.
Owing to its nature, SMTP is able to “forge From”, “Return-Path” and “reply” to fields in the header. As a result, several problems associated with this nature are evident.
For instance, phishing and spoofing of proposed systems normally validate the identity of an email sender (authentication of emails), including DKIM and SPF. These two protocols used DNS modelling as a method of adding security policy layer to the SMTP protocol (Bianco 6). Moreover, it is used in other aspects that aim at updating malicious code patterns.
Sender policy framework (SPF)
SPF classic was created by Meng Wong as an extension to SMTPT to solve the security weakness associated with SMPT. For instance, the current SMTP-based email system does not have the capacity to provide verification of the sender’s identity [3] [4] [5].
Previously, this protocol was known as the Sender Permitted from (SPF) but was later changed to Sender Policy Framework (SPF). It uses DNS to store its protocol policy. The domain published a TXT or SPF record in the DNS. Noteworthy, the records are just arbitrary texts developed into the DNS record. In addition, the network administrator, rather than the system itself, insert the texts (Fry 79).
SPF classic created by Wong is useful in the identification of the servers from which an email is coming from. These remote servers are permitted to send mails on a specific domain of internet. For instance, the @domain.com is added as a TXT record into the DNS info (Zelkowitz 56). The SPF record acts by identifying the IPs that are allowed to send outgoing email from a given domain.
On the other side, the destination MTA receives the email and completes a process of checking the client’s IP address. In this case, a number of outcomes are possible. For a mail coming from the authorized users, it should be safe. Secondly, for emails coming from the unauthorized server, it is possible to be forged.
For instance, “cs.nctu.edu.tw”, “cs.nctu.edu.tw” and “csmailer” are the authorized servers. As evident by the example, they proceed in this pattern- “csmaile, csmailgate, csmail” and are the authorized mail servers. The administrator controls emails from these servers, which means that they are authorized mail. Otherwise, other mails could be forged and have a higher probability of being SPAM mails (Bianco 13).
Types of DNS records applied in SPF
Prior to the development of DNS software, implementations applied TXT records in their implementations. However, regulations on section RFC 488 3.1.1 of the current RFC require all SPF to contain SPF records of both types of RR. Therefore, the use of TXT records has not been denounced. The following DNS records are used in SPF (Zelkowitz 41)
A: maps name of the IP address
Mail.example.com IN A 192.0.2.3
MX: indicates the servers that are responsible of handling the emails in that specific domain
Example.com IN MX 10 mail.example.com example.com IN MX 100 mailhandler.com
PTR: maps the IP to the specific name
Example 6.1.36. in-addr.arpa IN PTR example.com
TXT: is an arbitrary text string with a length of up to 255 characters
An example of SPF record [1]
Example.com IN TXT “v=spfl a mx ptr include:isp.com -all”
This SPF record is described in the pattern shown in the pattern shown in the following table:
Figure 1: SPF Record (Bianco 6)
Table 3: Evaluation results
How the system works
The following figure illustrates the mechanism through which the SPF system works
It is showing how information (mail is sent from the sender’s server) to the recipient’s PC. The following steps are involved:
- Step1: after the sender sends the mail from his PC, the server at the sender’s end sends the mail from a domain such as [email protected]
- Step 2: the recipient server carries out a DNS query on the yahoomail.com and obtains a list of the authorized IP addresses.
- Step 3: in this stage, the recipient server compares the actual or intended IP address from the first step with a list of the IP addresses returned from the DNS server in the second step. This list then returns the authorized IP addresses in the form of SPF records
- Step 4: this is the last step and involves authorization of the email address if the IP address specified is on that list. In case it does not appear on the list, then the email from that address will be considered as spoofed.
Domain Keys Identified Mail (DKIM)
As an enhanced version of Domain Keys, Domain Keys Indentified Mail (DKIM) complements SPF records (Zelkowitz 121). In DKIM, the signature calculation on all parts of the message serves as the key differentiator with other solutions. Each of the domains consists of pairs of domain keys, a private key (email signature key) and public key (verification key) used in the process of verifying the users’ digital signatures (Kozierok 183).
This framework aims at permitting the signing domain to declare a message’s responsibility. In this way, it provides protection to the message signer’s identity as well as the integrity of the message conveyed. At the same time, it retains the internet email functionality (Kozierok 181).
The following provides a basic summary of the idea behind the functioning of DKIM:
The sender signs emails, with the header, the body and the selected fields.
The recipient of the message or their agents can verify the signatures provided on the headers by simply querying the domain of the signer directly. Alternatively, they can retrieve the appropriate public key. From this task, they can now confirm whether the person or party holding the private key for the sender attested to the message. It is worth noting that the public key of the sender is stored and managed by a sub domain of the DNS (Kozierok 189).
If the verification of the signature fails, then the mail will be dropped automatically. The figure below provides an example of the DKIM process using yahoo domain keys. It shows positive verification results (Kozierok 192)
As shown in the figure above, DKIM process involves a number of steps. These are specific below:
- Step 1: The server on the sender side signs message private key and include a signature as the new header. It appears as follows: “Domain Key-Signature”.
- Step 2: the server on the recipient side uses DNS TXT record to find the public key. The text appears as: “query DNS”
- Step 3: the server at the recipient side makes an attempt to verify the signature of message developed by the sender server in step 1 above. The key returned from the DNS server as indicated in step 2 above.
- Step 4: If the server is able to verify the signature, the mail is automatically authorized. In case it is not verified, the mail will be spoofed.
Updating malicious code patterns
Antivirus software may be provided to a customer’s computer 201 by the security vendor. The antivirus software will comprise of a scan engine 203. In addition, it will contain malicious code patterns 204 and an update client 205.
In this case, scan engine 203 has a computer-readable program and hardware logic that is used to scan data for the malicious codes. It then compares the content of the information to the code patterns of the malicious data using an algorithm of matching pattern.
If a match between the two is found, then the data is considered to have been infected with a virus or malicious programs. In such a case, there must be a number of steps involved in cleaning the data. The ultimate aim is to prevent the malicious code from proliferating. For instance, the program could quarantine, remove or disinfect the data. In addition, it must first alert the user or administrator of the presence of the infections prior to performing any task.
Malicious code patterns are updated periodically to ensure that the latest information on the known malicious programs or codes is detected and the user or administrator updated. It is also worth noting that the process of updating malicious code patterns could be generated and then divided into a number of portions. The portions are included in the DNS records.
An update client is composed of a computer-readable program code that is used to update the malicious code patterns. In general, there are multiple private update server computers, including private DNS server and public DNS server computers. The update client may be configured in a manner that will allow it receive the codes and validate their integrity. To validate the integrity of the malicious codes, the update server checks the digital signatures. For example, it performs checksum.
How does the system work?
Updating is typically a task done by DNS transaction from the private DNS (or even a public DNS) server computer. This is the computer that the update client sends the DNS queries with an aim of obtaining DNS records. It is also known as the resource records and includes some malicious code patterns that have been embedded in it. This points out to DNS tunnelling in which a FQDN format shown below can be used in accessing the contents of the DNS records.
In this case, this field is optional in the format and is used to verify whether the computer from which the request is coming is subscribed to the update service.
C this field indicates the chunk number. The DNS upload sometimes lacks adequate room to hold the whole update. In this way, server 223 may decide to divide the typical update into smaller chunks. These chunks may be dividend, transmitted, and re-assembled within the client computer.
The update client plays the biggest role in this case. As shown above, the chink number always begin with a capital “C”. A sequence number that typically starts from “0” follows the “C”. It is also worth noting that the chunk number might be used to indicate a Special Index Chunk. This chunk provides the most recent number. For instance, it may be indicated by P0, P1, and P2 and so on.
V is used to indicate the version of a malicious code pattern or its component.
[P|E|C] This field must always start with C, E or P, which means component, engine or patterns in that order. However, this depends on the portion of the malicious program that is to be updated. In case of pattern field, P must be the first character. The component ID or the name that is used to identify the patterns, component or the engine that is to be updated. The following is an example of the component ID or name that is being updated.
this optional field is used for updating the patterns or any other component that is specific to a given geographical location.
this field is also optional and is used for the identification of a given product for which the product will be given.
Frupdate.trendmicro.com- this character is the FQDN of the DNS record and is varied with different computer servers. For example,
- c0.v439100.p4.frupdate.trendmicro.corn
- c1.v439100.p4.frupdate.trendmicro.com
- c2.v439100.p4.frupdate.trendmicro.com
Rather than adding, deleting or modifying any of these patterns, it is necessary to release a new update. This can be done with FQN using the component version number, which is incremental. “v439300.p4.frupdate.trendmicro.com” is a good example of the component version number.
The private DNS server computer, as a response to the DNS query, sends DNS results, including the data obtained from the DNS records. It is worth noting that the update client has the capacity to extract data from the results given by DNS in order to update the malicious patterns in the client’s interface.
The update may be divided into a number of chunks in order to enhance its delivery and to assemble in the client computer. For example, this occurs when the incremental pattern is quite large such as 5KB. The following loop provides an example of a response to DNS query as provided by a DNS server computer:
{
– Number of chunks that constitute this pattern: 10 bytes Checksum of this pattern: 128 bytes using MD5 hash format Digital signature for the pattern: 48 bytes if signed by DSA (Optional Field)
– Decryption key: 10 bytes (OPTIONAL field)
}
In this case, the decryption key is an optional key and is sometimes used to ensure that only the subscribing client computers receive the update patterns.
In this case, the number of chunks that constitute the whole pattern is equal to 10 bytes. In addition, with an MD5 hash format digital signature, the pattern has 48 bytes when assigned by DSA. This is preferable in protecting the integrity of the pattern because it allows downloading of the pattern chunks from a DNS server.
Description key is an optional field and has 10 bytes. On the other hand, the first chunk “c0” is the unique index chunk that is used, in this case, to provide the latest version number of the malicious patterns. In fact, the regular Index Chink provides information for downloading suspected code patterns. Consequently, the process may be repeated several times in order to ensure that the entire pattern of 204 chunks has been checked.
The decryption key is optional. It is sometime used to ensure that only the subscribing client computers 201 receive the intended pattern updates. 4-After that, the DNS query-response process is done repeatedly.
The next step involves caching of the public DNS server computer by which the results of the DNS are forwarded. This is important because it allows the patterns to be available from the servers. It also makes the patterns readily available for downloading from a number of sources.
Conclusion
Although DNS channelling has been used in the wrong way, it is an important tool in providing security to internet users, especially in email service. This section has provided an in-depth explanation of the effective roles of DNS tunnelling in providing network security.
It has been shown that the number of internet users has risen significantly to over 2.7 billion in 2013. However, most of them depend on the service providers to ensure them of email security. Therefore, the need to use DNS Tunnelling is clearly defined.
Works Cited
Bianco, David. A traffic-analysis approach to detecting DNS tunnels. 2006. Web.
Fry, Charles. Security monitoring, proven methods for incident detection on enterprise networks. Sebastopol, CA: O’Reilly Media, 2009. Print.
Kozierok, Charles. The TCP/IP Guide. San Francisco, CA: Press, 2010. Print.
Zelkowitz, Marvin. Advances in Computers: Web Technology. New York: Academic Press, 2010. Print.